Jak wygląda analiza i proces wytwarzania?

Jest wiele sposobów prowadzenia projektu i analizy. Mamy do wyboru mnóstwo dobrych praktyk. Czesto jednak wychodzi wielka improwizacja. Przedstawiam dwie moje ulubione:) Nie znamy dobrych praktych czy po prostu lubimy dreszczyk projektów bez trzymanki? 😉

Jak mogłaby wyglądać analiza i proces wytwarzania?

Poniżej wybrane trzy modele cyklu wytwarzania oprogramowania: model kaskadowy (klasyczny, wodospad, ang. waterfall), spiralny i przyrostowy.

Model kaskadowy

Model kaskadowy (zwany też klasycznym cyklem życia oprogramowania) zakłada, że każda z faz następuje po zakończeniu poprzedniej. Taka pojedyncza sekwencja doprowadza do końca projektu i utrzymania systemu.
Taki sposób pracy wprowadza systematykę. Wszystko ma ręce i nogi. Rozpoczynając kolejną fazę mamy wszystko, co nam potrzebne do jej przeprowadzenia – np. projektując system znamy już wymagania pozyskane w czasie analizy.
Jest to dobry sposób na systemy, w których od początku wiemy, co powinno powstać (np. regulowane przepisami, wpierające organizację, której struktura szybko się nie zmienia) lub są duże wymagania bezpieczeństwa systemu (potrzebne dobre zaplanowanie). Jeśli jednak wymagania mogą się często zmieniać w trakcie projektu (np. produkty wymyślane przez klienta), lepiej wybrać inną metodę i częściej pokazywać klientowi efekty pracy niż raz i to po zakończeniu 🙂

Model spiralny

Model spiralny zakłada kilka cykli przechodzenia przez fazy projektu. Po planowaniu i analizie bada się ryzyko, następnie konstruuje rozwiązanie i przedstawia klientowi do oceny. W tym ostatnim etapie klient zgłasza uwagi, które stają się podstawą do rozpoczęcia kolejnego cyklu i lepszego dopasowania rozwiązania do jego potrzeb.
Taki sposób pracy zmniejsza ryzyko dalekiego odejścia od oczekiwań klienta. Dobrze nadaje się do systemów, w których zakres nie jest dobrze znany na początku (wiele pomysłów), od jakości i bezpieczeństwa rozwiązania ważniejsze jest jego dopasowanie do potrzeb.

Model przyrostowy

Model przyrostowy zakłada wstępne planowanie projektu, analizę i ogólny projekt architektury, a następnie wprowadzanie kolejnych części systemu. Na początku ustalamy zarys rozwiązania, a później doprecyzowujemy, wykonujemy i przekazujemy klientowi. Pozwala to skupić się na mniejszej części i skupić się dokładniej:)
Zaletami tego podejścia jest uniknięcie tworzenia 10000-stronicowego dokumentu z ustaleniami na początku. Dzięki podziałowi pracy można dodawać nowe funkcje, każdą część wytwarzać oddzielnie (później lub przez inny zespół), dokładniej testować skupiając się na małym wycinku, przekazywać już coś klientowi i nie denerwować go długim oczekiwaniem. Wymogiem jest możliwość podziału rozwiązania na niezależne części.
Można też łączyć metody i działać np. przyrostowo-ewolucyjnie 😉

Czemu nie?

Jak widać jest wiele sposobów prowadzenia projektu i przeprowadzania analizy, choć nie wspomniałam nawet o innych modelach, metodykach, itd. Często jednak wybierana jest inna droga…

Jak wygląda analiza i proces wytwarzania?

Analiza w 1 dzień

Niekiedy w imię oszczędności analiza wykonywana jest w „1 dzień”. Poniżej obrazek wzięty od J. Żelińskiego z dyskusji na Golden Line. Przedstawia on wyniki badań IBM na temat skutków krótkiej analizy w projekcie i kosztowną pętlę odkrywania wymagań.

Zrównoleglenie prac

Moim „ulubionym” modelem jest jednak ten. Zakłada on zrównoleglenie prac. Żeby zaoszczędzić czas i wykorzystać zasoby, przed zakończeniem analizy rozpoczyna się wykonanie (implementacja). Trwa ona równolegle z projektowaniem (o ile ono występuje) oraz wdrożeniem, a nawet po zakończeniu wdrożenia (dostrzeżone problemy jeszcze się naprawia) 😉
Taki styl pracy powoduje, że rozpoczyna się implementację z mglistym pojęciem, brakiem konkretów lub konkretami, które nie są potwierdzone i mogą się zmienić. Często w trakcie projektu wychodzą jednak zmiany, które okazują się burzyć programistyczne struktury. Konieczne jest wtedy budowanie obejść, łatek i konstrukcji tak misternych, że sami twórcy zaczynają się w nich gubić i raczej nie wykorzystają ich w przyszłości, bo mogłoby to przysporzyć więcej problemów niż oszczędności.
 
Głównymi zaletami dwóch ostatnich modeli jest to, że nie pozwalają zespołowi programistycznemu pozostawać w bezczynności. Zapewniają one dużo zadań zarówno podczas wytwarzania jak i po przekazaniu systemu.
Zdarzyło mi się widzieć nie jeden projekt improwizowany, który dzięki swojej „swobodności” stał się tworem trudnym do okiełznania przez kierowników projektów, a dla realizujących doświadczeniem, o którym woleliby zapomnieć i się lepiej pod tym nie podpisywać swoim nazwiskiem. Z kolei nigdy nie spotkałam kogoś, kto wykorzystał dobre praktyki i metodykę i postanowił wrócić do metod improwizowanych. Wiele osób stało się gorącymi zwolennikami np. Scruma po projektach, w których brali udział z jego wykorzystaniem.
Lubisz jazdę bez trzymanki? Czy Twoi ludzie podzielają to wrażenie siedząc jako pasażerowie takiego projektu?
A może spróbujesz dobrych praktyk i zbudujesz coś, czym można się chwalić zarówno innym programistom jak i zadowolonemu klientowi?
 
Źródła:
1. Bobkowska A., Jarzębowicz A., Szejko S. (2009): Inżynieria oprogramowania, Niepublikowane materiały, Politechnika Gdańska.