Bycie Agile w 2021 roku
Model Agile – do niedawna kojarzył się głównie z branżą IT, dziś świetnie sprawdza się również w obszarze marketingu, sprzedaży, HR czy edukacji. W ciągu ostatniej dekady termin „Agile” stale zyskuje na popularności, a liczba transformacji zakończonych sukcesem – rośnie. W metodykach zwinnych w centrum stoi jedna prosta zasada: szybkie i realne korzyści biznesowe dla klienta.
Najnowszy raport State of Agile 2021 jasno wskazuje na znaczący wzrost akceptacji metodyki zwinnej w zespołach programistycznych z poziomu 37% w 2020 do 86% w roku 2021.
Przeprowadzone badania wskazują także, że po raz kolejny Scrum jest najpopularniejszym podejściem Agile. 66% respondentów uznało, że jest to metodologia, którą stosują najczęściej. Czy jednak podejście zwinne sprawdzi się w każdym projekcie? Poniżej kryteria, jakie warto wziąć pod uwagę.
1. Znajomość rozwiązania
Każda z metodyk zwinnych oraz klasycznych zakłada, że cel projektu jest dobrze zdefiniowany. Co to znaczy? Ważnym punktem każdego projektu jest analiza biznesowa. Zarówno w przypadku mniej, jak i bardziej złożonych projektów, niezbędne jest zebranie wymagań, które pozwolą określić potrzeby klienta. Kluczową rolę pełni tutaj analityk biznesowy, który monitoruje biznesowe potrzeby klienta i jest z nim w ciągłym kontakcie, a także dostarcza zespołom programistycznym istotnych informacji również w okresie trwania projektu, pomaga w ocenie bieżącej sytuacji i podejmowaniu najważniejszych decyzji. W dzisiejszej postcovidowej rzeczywistości, analityk często staje przed koniecznością współpracy zdalnej z klientem.
W związku z powyższym, tradycyjne metodyki zarządzania powinny być stosowane w projektach posiadających znane sposoby rozwiązania problemu. Jeżeli sposób nie jest znany, należy użyć metodyk zwinnych. Tłumacząc bardziej obrazowo, znajomość rozwiązania, czyli np. tworzenie kolejnej wersji tego samego systemu, wdrażanie kolejnego sklepu internetowego, różniącego się tylko produktami, informatyzacja urzędu z dobrze znaną liczbą systemów i stanowisk jest przesłanką do wykorzystana metodyk tradycyjnych. Natomiast portal typu start-up, ze względu na innowacyjność oraz niepowtarzalność rozwiązania, jest idealnym przykładem wykorzystania metodyk zwinnych.
2. Wielkość projektu a zarządzanie projektami
Zaleca się wykorzystanie metodyk klasycznych do dużych i bardzo dużych projektów. W tym wypadku trudno sobie bowiem wyobrazić, żeby wielomilionowe projekty były realizowane bez znanego celu i sposobu rozwiązania. Metodyki zwinne lepiej nadają się do za projektów mniejszych. Nic nie stoi jednak na przeszkodzie, żeby projekt całościowo zarządzany w sposób klasyczny posiadał moduły tworzone zwinnie. Jest to tzw. model hybrydowy. W takim wypadku cały projekt dzielony jest na podprojekty, z których każdy może być zarządzany przy użyciu innej metodyki.
3. Stabilność wymagań
Tradycyjne metodyki wymagają stabilnych wymagań projektowych, gdyż w trakcie nie dopuszcza się do ich zmian. Każda większa zmiana pociąga za sobą wzrost kosztów i wydłużenie realizacji projektu. W związku z tym, jeżeli wymagania nie są sprecyzowane bądź też, jeżeli z doświadczenia wiemy, że klient ma tendencję do ich modyfikacji, wówczas jedynym wyjściem jest użycie metodyk zwinnych. Obecnie, gdy mamy do czynienia z tak dynamicznym rozwojem technologii, zmian, jakie zachodzą w świecie biznesowym, a klienci mają do wyboru szeroką pulę partnerów biznesowych, zdecydowanie lepiej sprawdzi się zastosowanie metodyki zwinnej w zarządzaniu projektami. Pozwala ona elastycznie reagować na zmiany i reagować na zmieniające się okoliczności.
4. Dostępność klienta
Teoretycznie, w przypadku metodyk tradycyjnych, klient może być dostępny dla zespołu projektowego dopiero podczas odbioru oraz testów akceptacyjnych. W praktyce jednak, udział klienta jest wymagany przynajmniej jeszcze na etapie analizy wymagań (patrz często spotykane w Specyfikacji Istotnych Warunków Zamówienia stwierdzenie „poniższy punkt zostanie uszczegółowiony na etapie analizy”). O ile w metodykach klasycznych nie zakłada się potrzeby kontaktu z klientem przez cały czas „życia” projektu, w metodykach zwinnych klient jest integralną częścią zespołu projektowego i ma za zadanie wspierać developerów. Stąd też jego dostępność jest czynnikiem kluczowym do wyboru metodyki. Osobiście znam jednak przypadki, w których w roli Product Ownera obsadza się pracowników wykonawcy. Są to jednak bardzo rzadkie przypadki, wymagające ogromnego zaufania pomiędzy klientem a firmą zewnętrzną. Definiując odpowiednio zadania w Backlogu, korzystając przy tym z ogólnodostępnych narzędzi typu Jira lub Asana, można odpowiednio nadać priorytety i monitorować status. W dobie tak powszechnej pracy zdalnej z pomocą aplikacji można łatwo organizować spotkania typu Daily lub spotkanie zespołu z klientem. Sprawdzonym narzędziem do komunikacji w takim modelu są np. Slack czy Teams.
5. Tolerancja na zmiany w budżecie oraz zakresie
Projekty realizowane w metodykach klasycznych mają zawsze ściśle określony zakres oraz koszt – są wykonywane jako fix-price. Fixed Price to model, w którym z góry ustalana jest stała cena za projekt już na etapie negocjacji umowy, wraz z zakresem i harmonogramem. Zamawiający ceni sobie fakt, iż całość odpowiedzialności za projekt ponosi, wtedy partner technologiczny, który jest rozliczany z efektu finalnego. W przypadku metodyk zwinnych, ze względu na zmieniające się wymagania oraz priorytety, trudno jest oszacować całkowity koszt projektu. Tutaj dobrym rozwiązaniem będzie opcja Time and Material, która nawiązuje do modelu współpracy, w którym klient płaci za faktycznie wykonaną przez specjalistów pracę. Niesie to za sobą wiele korzyści, gdyż zamawiający ma swobodę co do zmiany specyfikacji projektu oraz dodania nowych elementów.
Stąd też, jeżeli budżet klienta jest stały i nie może zostać zwiększony, na koniec projektu dostarczane są funkcjonalności o największych priorytetach. Innymi słowy, może zostać zmieniony / zmniejszony zakres prac. Świadomość klienta w tym względzie jest kluczowa, a brak zrozumienia tej kwestii zawsze powoduje problemy.
6. Czas dostarczenia
Głównym założeniem metodyk klasycznych jest dostarczenie klientowi gotowego rozwiązania dopiero na koniec projektu. W przypadku metodyk zwinnych pełne, działające rozwiązanie, jest efektem końcowym każdej iteracji. Ponieważ iteracje trwają od 1 do 4 tygodni, istnieje możliwość szybkiego wdrażania produkcyjnego nowych funkcjonalności.
7. Zespół
Kompetencje zespołu projektowego są jednym z najważniejszych czynników wyboru metodyki zarządzania projektami. W idealnym świecie każdy zespół składa się z kompetentnych i doświadczonych osób, jednak w dobie ciągłych problemów z zasobami nie jest to wcale takie oczywiste. W przypadku wyboru metodyki, wiedząc, że mamy do dyspozycji słabszy zespół, wybierzmy metodykę klasyczną. W metodykach zwinnych zespół jest tzw. „samoorganizującym się ciałem”, musi być doświadczony, znać się od dłuższego czasu, posiadać umiejętność estymowania zadań, mieć dobre zdolności komunikacyjne. W przypadku metodyk klasycznych braki zespołu mogą zostać zrównoważone przez nadzorujących projekt kierowników. Mogą oni ewentualnie dokonać zmian w przydziale zadań, w składzie zespołu, co z kolei nie powinno mieć miejsca w zespołach pracujących w projektach realizowanych przy użyciu metodologii zwinnych.
8. Integracja z systemami zewnętrznymi
Punkt ten może początkowo wydawać się niezrozumiały, gdyż obecnie większość systemów integruje się z innymi systemami. Niemniej w przypadku dużych projektów, w których wiele aplikacji tworzonych jest równocześnie i które muszą komunikować się ze sobą, np. przy użyciu szyny danych, lepszym wyborem jest użycie metodologii klasycznej. Dzięki niej będziemy mieli zawsze zdefiniowane sposoby komunikacji i zespól będzie mógł wykonać odpowiednie mock-upy. W przypadku metodyk zwinnych istnieje bardzo duże ryzyko blokowania prac zespołu przez braki po stronie innych modułów. Warto w tym miejscu nadmienić, że często moduły/aplikacje są tworzone przez różne firmy, co tym bardziej nie ułatwia synchronizacji prac.
Bonus: Preferencje klienta
Znajomość metodyk zarządzania projektem przez klienta jest kluczem do jego sukcesu. Realizacja projektu w nieznanej klientowi metodyce spowoduje chaos oraz irytację. Stąd też ze względu na trudności ze zmianą świadomości klienta (przeszkolenie nie zawsze jest możliwe, zespół projektowy to często kilkanaście osób), warto dostosować się do jego preferencji. Wielokrotnie też nie mamy wyboru – metodyka jest narzucona bezpośrednio w wymaganiach klienta.
Podsumowanie
Wiele projektów związanych z tworzeniem oprogramowania wymaga nowoczesnego podejścia, są to projekty, w których potrzeba elastyczności z przybliżonym pojęciem ostatecznego zakresu, czasu i budżetu. Metodyka Agile, np. Scrum najlepiej sprawdza się w przypadku takich właśnie projektów. Z drugiej strony tradycyjne podejście wyróżnia wszystkie czynniki przed podjęciem ostatecznej decyzji. Pozwala to wyeliminować niepotrzebny wysiłek, ale jednocześnie ogranicza kreatywność i możliwość wprowadzania zmian. Niejednokrotnie trudno jest zdecydować, która metodologia zarządzania projektami jest odpowiednia dla twojej firmy, jednak dzięki zrozumieniu, na ile elastyczne są wymagania projektowe, możesz zastosować najbardziej odpowiednią metodę, a następnie dostosować ją do własnych potrzeb. Podsumowując, jeżeli tylko istnieje taka możliwość, warto za każdym razem przeanalizować nowy projekt pod kątem opisanych powyżej kryteriów, tak by wybrać najlepszą dla danego przypadku metodykę.