Coraz większe zainteresowanie wśród programistów zyskują tzw. metodyki zwinne (ang. agile) zarządzania projektami. I nic dziwnego, gdyż badania przeprowadzone w USA wykazały, że projekty wykorzystujące to podejście uzyskują lepszy współczynnik ROI, czyli zwrot z zainwestowanych pieniędzy.

Najpopularniejszą metodyką zwinną w programowaniu jest Scrum – podejście stworzone przez Kena Schwabera w 1995 roku. Schwaber jest jednocześnie współtwórcą organizacji Scrum.org, która zajmuje się uczeniem metodyk zwinnych i standaryzacją wiedzy o Scrum-ie. To właśnie w Scrum.org miałem przyjemność poznać tę metodykę i zdobyć swój certyfikat Professional Scrum Master.

Dwie najważniejsze cechy Scrum-a to iteracyjność i przyrostowość. Iteracyjność oznacza, że w Srum-ie pracuje się w powtarzalnych cyklach, które trwają zazwyczaj 1-4 tygodni. Każdy z cykli składa się z:

  • Planowania
  • Właściwej pracy (projektowanie, implementacja, testowanie)
  • Demonstracji wykonanego przyrostu
  • Analizy iteracji, by wyciągnąć wnioski z dotychczasowej pracy.

Przyrostowość oznacza, że po każdym zakończeniu cyklu dostępny jest gotowy i działający produkt, który co cykl jest rozszerzany o nowe funkcjonalności (nazywane właśnie przyrostem).

W Scrum-ie istnieje pojęcie Backlogu, który jest rejestrem wszystkich zadań do wykonania w danym produkcie. W każdym cyklu wybiera się z niego zadania, które zostaną wykonane w danej iteracji i zamienione na przyrost.

Ogromną zaletą Scrum-a jest dostarczanie szybkiego feedbacku osobom odpowiedzialnym za stronę biznesową projektu. Po pierwsze wyraźnie widać szybkość postępów prac, dlatego łatwo jest kontrolować wydatki i organizować inne działania w firmie. Po drugie każda implementowana funkcjonalność jest od razu dostępna do testowania i sprawdzenia, czy spełnia oczekiwania biznesu, a w razie potrzeby modyfikowana i poprawiana.

Scrum-a najłatwiej jest docenić, gdy zna się jego poprzednika – Waterfall.  Podejście to wywodziło się z tradycyjnej myśli zarządzania projektami i zakładało projektowanie całej aplikacji na początku i budowanie od razu całości projektu przy jednoczesnym testowanie dopiero na końcu. Taki sposób organizacji pracy dawał zupełnie nieprzewidywalne rezultaty co do czasu wykonania zadania oraz nie pozwalał na wczesne sprawdzenie, czy dany pomysł działa tak dobrze, jak pierwotnie myśleli jego twórcy. W efekcie Waterfall doprowadził mnóstwo projektów do epickiej porażki, często ściągając na firmę nie tylko dodatkowe koszty z powodu nieprzewidzianej pracy programistów, ale także kary umowne za niedotrzymanie terminu oddania aplikacji i dużo niższą jakość powstałych programów.