Scrum nie jest uniwersalnym rozwiązaniem

Wielu projektów IT nie udaje się zrealizować w planowanym czasie i budżecie. Na domiar złego okazuje się, że w trakcie prac zmieniły się potrzeby biznesu. Metodyki agile dają nadzieję uniknięcia tych problemów, ale oznaczają także pewne koszty i ryzyko.

Do niedawna metodyki zwinne kojarzone były głównie z projektami start-upowymi. Obecnie coraz więcej organizacji – w tym również większych graczy, takich jak: banki, ubezpieczyciele, firmy medyczne czy logistyczne – prowadzą projektyw w ten sposób bądź rozważają podobną ich realizację. Jednak zmiana podejścia projektowego w kulturze, w której przez lata dominował tradycyjny, kaskadowy model wytwarzania oprogramowania, jest trudna.

W agile łatwiej o zmianę zakresu

Dla wielu firm model kaskadowy ma istotne wady – produkcja oprogramowania trwa długo

a użytkownicy widzą efekty i zaczynają używać rozwiązania dopiero pod koniec projektu. Wcześniej niemożliwe bywa nawet zweryfikowanie, czy ich wymagania zostały właściwie zrozumiane i spełnione. Zakres, harmonogram i budżet projektu ustalany jest przed jego rozpoczęciem. Jeżeli w trakcie realizacji wymagań pojawi się potrzeba dodania nowych funkcjonalności, decyzja o ich akceptacji może spowodować zmianę wcześniejszych ustaleń. Czasem rodzi to konflikty pomiędzy użytkownikiem, wykonawcą i sponsorem projektu, dlatego zmiany nie są pożądane.

Zobacz również:

Podejście zwinne ma na celu szybsze przekazanie kolejnych części rozwiązania końcowemu użytkownikowi. Liczy się to, aby od początku projektu rozmawiać z użytkownikami o ich faktycznych potrzebach. W krótszych cyklach łatwiej jest też zarządzać dynamicznie zmieniającymi się wymaganiami – wystarczy na daną iterację zaplanować elementy, które w ostatnim czasie zyskały priorytet z punktu widzenia użytkownika. Takie podejście wydaje się idealnym rozwiązaniem wspomnianych problemów, dlatego firmy coraz częściej decydują się na jego realizację.

Moda na Scrum bywa kosztowna

Najpopularniejszym obecnie podejściem zwinnym jest scrum. Zespół pracujący w ten sposób ma wspólny cel: wyprodukować w danej iteracji – tutaj zwanej sprintem – pewien zbiór funkcjonalności reprezentowanych przez tzw. historyjki (user stories), które można zaprezentować użytkownikowi końcowemu. Historyjki użytkownika to krótkie opisy wymagań do danej funkcjonalności oraz przypadków jej użycia i definiowane są wspólnie w zespole na początku trwania projektu. Powstaje wtedy rejestr produktu (product backlog), czyli dokument zawierający opis zakresu. Historyjki są następnie uszczegóławiane przed sprintem, w którym mają być wykonane.

Celem scrum jest między innymi uproszczenie pracy. Nie oznacza to jednak, że Scrum jest łatwy we wprowadzeniu. Panująca moda oraz szereg publikacji zachwalających jego zalety zachęcają firmy do stosowania tego podejścia, mimo że nie mają one wystarczającego zasobu informacji i doświadczenia w zrealizowaniu takiej zmiany. Nieumiejętne podejście do przestawienia produkcji na scrum może się okazać kosztowne i nieefektywne.

Scrum wymaga solidnego przygotowania

Scrum zakłada, że zespół projektowy zdolny jest do samoorganizowania się, a wszyscy jego członkowie rozumieją swoją rolę i aktywnie uczestniczą w planowaniu i realizacji sprintów. Tymczasem nie w każdej firmie jest to możliwe – szczególnie jeśli do tej pory kultura metodyk zwinnych nie była przez daną organizację praktykowana. Z jednej strony zespoły nie potrafią zarządzać własną pracą, z drugiej strony menedżerowie wciąż starają się kontrolować swoich pracowników według dotychczasowych zasad, co utrudnia sprawne realizowanie założeń tego podejścia.