Jak zmieniało się podejście do zarządzania projektami w ostatnich latach?

Dlaczego w firmach zespoły projektowe spotykają się nawet codziennie?

Czy watro pisać rozbudowaną dokumentację techniczną?

W dzisiejszym tekście odpowiemy na te i inne pytania oraz zdradzimy które podejście praktykujemy w naszej firmie.

Waterfall 

Waterfall (z j. angielskiego wodospad) oznacza tradycyjne podejście do realizacji projektów. Nazywany jest często modelem kaskadowym, który przewiduje wdrożenie oprogramowania w oparciu o dokładnie określone, postępujące po sobie etapy:

• planowanie wdrożenia,
• analizę potrzeb,
• projektowanie rozwiązania,
• implementację (prace programistyczne),
• testowanie oraz pielęgnację wdrożonego już systemu.

Podejście to charakteryzuje się dużym stopniem uporządkowania – poszczególne etapy nie nachodzą na siebie, lecz są dokładnie zaplanowane i zabudżetowane.

Rozwój oprogramowania o ten model kaskadowy specyfiką przypomina nieco budowę domu, gdzie również mamy do czynienia z fazami prac projektowych: stawianie fundamentów, dodatkowych pięter, wykończenie wnętrz, a dopiero na samym końcu – odbiór techniczny przez klienta.

Jest to podejście naturalne i właściwe, gdy nasz klient oraz my sami jesteśmy absolutnie zdecydowani, co chcemy zbudować. Jednakże może zdarzyć się, że widząc efekt końcowy, jesteśmy w pewnym stopniu zaskoczeni rezultatem czy też wręcz niezadowoleni. Niestety, z pisaniem i tworzeniem oprogramowania zdarza się tak jeszcze częściej.

Agile

W 2001 roku został sformułowany tzw. Manifest Agile (agile – z j. angielskiego oznacza zwinność), który poniekąd miał być receptą na niedoskonałość projektu metody Waterfall. Składa się on ze zbioru wartości, którymi jego twórcy zalecają kierować się podczas pracy nad oprogramowaniem.

Według nich, istotniejsze dla końcowego sukcesu wdrożenia jest działający produkt niż rozbudowana dokumentacja techniczna.  Efektywna i bieżąca współpraca z klientem przynosi więcej pożytku niż formalny, proceduralny kontakt.

Z tymi zasadami nie sposób się nie zgodzić, dlatego Manifest Agile stał się bazą oraz inspiracją dla wielu tzw. zwinnych metodyk rozwoju oprogramowania (zarówno nowych,
jak i już istniejących).

Scrum

W oparciu o idee realizacji projektów Agile, najpopularniejszą metodą pracy jest Scrum.

Charakteryzuje się on wytwarzaniem nowych produktów w małych przyrostach (tzw. sprintach).  W Scrumie wszystkie tradycyjne fazy budowy oprogramowania (analiza, planowanie, implementacja, testowanie itd.) trwają równolegle i bez przerwy, dzięki czemu zespół projektowy jest w stanie, w razie potrzeby, bardzo szybko i dynamicznie skorygować plan i kierunki jego dalszego rozwoju.

Porównując to do naszego przykładu budowy domu, w Scrumie, po pierwszym sprincie, zamiast wszystkich fundamentów otrzymalibyśmy zapewne fundament pod jeden, mały pokój, wraz ze ścianami i prowizorycznym zadaszeniem – tak, aby w razie potrzeby można było w tym pomieszczeniu zamieszkać. W kolejnych przyrostach dobudowywalibyśmy
(w razie zdefiniowanej potrzeby) kolejne pokoje i usprawnienia. Być może czasami należałoby również co nieco zburzyć (czego Scrum również się nie boi).

Realizacja innowacyjnego projektu nie wszystkim przychodzi w sposób naturalny, ponieważ wejście w projekt, którego efektów końcowych często nie znamy, nie jest zadaniem prostym, dla osób, które w swojej pracy wypracowywały rutynowe działania.

W naszej pracy zwinne podejście do realizacji projektów z możliwością szybkiego dostosowania się do zmian jest podstawą pracy z klientami, a spotkania scrumowe odbywają się niemal codziennie.