Metodyka SCRUM czyli zwinne zarządzanie projektami - od kuchni

W dzisiejszych czasach często się słyszy pojęcie "Firma x wytwarza oprogramowanie w SCRUMIE". Wiele osób pewnie zastanawia się co to oznacza i co to jest ten cały SCRUM ? ;)

SCRUM jest niczym innym jak zbiór dobrych praktyk i działań, które przyczyniają się do wytworzenia końcowego działającego produktu. Przykładowo firma programistyczna dostaje zlecenie na zbudowanie giełdy z kryptowalutami coś na wzór portalu BitBay. Jeżeli firma nie korzysta ze SCRUMA, to wygląda to mniej więcej tak że ktoś zbiera wymagania i rozpisuje je w punktach w kolejności zadaniowej. Następnie programiści biorą z tak zwanej tablicy poszczególne zadania i je realizują. Czasami jest tak że zadania do poszczególnych osób przypisują przełożeni, którzy często nie wiedzą że zadanie A jest dużo bardziej złożone od zadania B i przypisują je do osób które mogą mieć problem z ich realizacją. Takie podejście w większości przypadków, wiąże się z pewnym ryzykiem. Ryzyko możemy podzielić na:

Te trzy powyższe punkty oznaczają pewną klęskę dla firmy i tutaj przychodzi na pomoc metodyka SCRUM. W praktyce wygląda to tak że najpierw tworzymy kompetentny zespół najczęściej od 3 do 10 osób, który będzie odpowiedzialny za przebieg realizacji wykonywanego oprogramowania. Najważniejszy jest oczywiście zespół który dzielimy na 3 role:

• Product Owner, osoba odpowiedzialna za przekazywanie w sposób jasny i zrozumiały celu, jaki cały zespół musi osiągnąć. Jest to człowiek który reprezentuje klienta i jego wymagania. Tworzenie rejestru produktu to jego zadanie. Tak samo jak podejmowanie kluczowych decyzji i przekazywanie ich do zespołu developerskiego.
• Scrum Master, osoba który pilnuje żeby każdy uczestnik w projekcie rozumiał SCRUMA i stosował jego zasady. Obowiązkiem Scrum Mastera jest wspieranie Product Ownera w zarządzaniu backlogiem oraz wycenia historyjki razem z zespołem developerów(Story Points). Jest kimś w rodzaju stróża i pilnuje żeby cały "młyn się kręcił". Scrum Master może również należeć do Development Team, tylko w przypadku, gdy obejmowane stanowisko nie przeszkadza mu w realizacji zadań przypisanych do Scrum Mastera.
• Development Team, czyli tak zwany zespół developerski składający się z programistów, testerów, analityków oraz architektów. Zadaniem zespołu deweloperskiego jest realizacja przypisanych do siebie historyjek w danym Sprincie.

Mając kompletny zespół musimy określić ramy pracy. Cały przebieg projektu dzielony jest na Sprinty. Sprint jest to krótki cykl, który ma na celu dostarczyć kolejne wersje produktu. Cykle mogą trwać od tygodnia do czterech. Ja osobiście pracuje w cyklach dwutygodniowych i uważam że jest to dobry kompromis między tygodniem a miesiącem ;) Te ramy czasowe ustalane są po to, żeby Product Owner wiedział że jak coś pójdzie nie tak, to nie jest w plecy 5 miesięcy tylko przykładowo dwa tygodnie. Poza tym, pozwala to na szybką reakcję w razie nieoczekiwanych problemów. Przykładowo dorzucenie kolejnego programisty do Development Team w sytuacji gdy zespół nie wyrabia się z realizacją zadań.

Na początku wystartowania Sprintu cały zespół spotyka się i robi planowanie sprintu(Sprint Planning) w którym ustalany jest Sprint Backlog czyli plan zespołu w jaki zamierza realizować cały sprint. Dodatkowo Scrum Master ustala termin codziennych spotkań(Daily Scrum). Zazwyczaj są to codzienne spotkania o tej samej porze, które nie powinno przekraczać 15 minut. Na tych spotkaniach poszczególni członkowie Development Team, opowiadają co zrobili w dniu poprzednim oraz jaki plan mają na dzień aktualny. Podczas "Daily" może również uczestniczyć Product Owner, ale nie jest to konieczne. Gdy mija termin zakończenie sprintu następuje spotkanie podsumowujące(Sprint Review). Podczas spotkania cały zespół omawia co zostało zrealizowane i co o tym sądzą sami zainteresowani jeśli zostaną zaproszeni. Następstwem tego spotkania jest kolejne planowanie Sprintu(Sprint Planning) i tak to się kręci jak w młynie. Dobrą praktyką są retrospektywy (Sprint Retrospective), gdzie zespół ustala co robił źle i jakie działania trzeba wdrożyć żeby było lepiej. Często wygląda to tak, że na tablicy wypisuje się pozytywy i negatywy, a następnie wywiązuje się dialog jak wyeliminować problemy i co zrobić żeby było lepiej.

Ja osobiście jestem programistą i Scrum Masterem jednocześnie. W swojej zawodowej pracy doświadczyłem, że wiele firm szczególnie tych małych nie stać na prowadzenie projektów w ten sposób. Niestety czasami warto podejść do tematu nieco szerzej i spróbować zastosować tą metodykę. Ile razy się słyszy że oprogramowanie tworzone było o kilka miesięcy za długo bez wykwalifikowanego zespołu. Czasami udało się oddać produkt i jakoś to było... Gorzej jak okazywało się że aplikacja już na samym początku została błędnie zbudowana i zmiany które trzeba nanieść wymagają przepisywania całych modułów, włącznie z przebudową bazy danych. Koszty które musi ponieść pracodawca żeby to wyprostować na pewno będą większe niż koszty związane z wprowadzeniem SCRUMA.