User Story c.d.
Wokół metod zwinnych narasta wiele mitów, szczególnie tych o skuteczności w dużych projektach. Dzisiaj kolejne kilka słów o popularnym narzędziu jakim jest tak zwane "user story" czyli historyjka użytkownika, o…
praca grupowa,
Produkt analizy jako twierdzenie naukowe
Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż…
Koncepcja to nie wymagania!
"Requirements must be based on facts and real-life scenarios." (wymagania muszą być oparte na faktach i realnych scenariuszach). Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.
Kolejna wpadka IT: obiektowość
obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy "świata" i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie - obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).
Niski poziom analizy…
Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem :( Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej "jak wdrożyć to co mamy" a nie "jak rozwiązać problem użytkownika"). Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.