Metodyka Agile – nowoczesne zarządzanie projektem? cz.2. Wady i zalety

W poprzedniej części poradnika o metodyce Agile dowiedziałeś się, czym jest zarządzenie zwinne oraz z jakich elementów się składa. Poznałeś też różnice pomiędzy nim a metodologią waterfall.

W poniższym artykule dowiesz się, jakie są wady i zalety Agile oraz jak pomóc zespołowi we właściwym zastosowaniu go w procesie produkcyjnym.

;

Nie każdy projekt nadaje się do wdrożenia za pomocą metodologii Agile.

Niektóre niezbędne czynności, takie jak okresowe zmiany procedur lepiej przeprowadzić w bardziej tradycyjny sposób.

Pamiętaj, że dobry projekt Agile powinien opierać się na takich zasadach jak:

1. Dostarcz wysokiej jakości produkt, ale nie próbuj “dowozić” wszystkich funkcjonalności jednocześnie.
2. Spodziewaj się, że wymagania zmienią się lub ewoluują.
3. Daj swobodę utalentowanym członkom zespołu.
4. Szanuj innych członków zespołu i dopilnuj, by pomiędzy nimi panowała dobra atmosfera.
5. Bądź otwarty na nowe pomysły.
6. Daj możliwość nabycia nowych umiejętności od pracowników z innych działów.
7. Pozwól samodzielnie zarządzać projektem jego uczestnikom. Unikaj bycia “fixerem”.
8. Pilnuj, by na codziennych spotkaniach (tzw. dailies) byli obecni wszyscy uczestnicy projektu – zawsze.

Nie musisz wybierać pomiędzy klasycznym modelem a Agile. Możesz z powodzeniem stworzyć hybrydę – część zadań zorganizuj w nowej motodyce (np. opracowanie nowych produktów marketingowych), a część wykonaj w tradycyjny sposób (np. reorganizacja pracowników w nowy dział produktu).

Projekt Agile powinien posiadać zdefiniowany czas trwania poszczególnych sprintów oraz liczby funkcjonalności do opracowania.

Te ustalenia pozwalają stworzyć strukturę sprintów. Każdy projekt jest inny, więc jego struktura powinna być dopasowana do konkretnego zadania do wykonania.

Przykładowe sposoby strukturyzacji sprintów:

1.Ustal czas spekulacji oraz adaptacji na 1 tydzień.

Z biegiem czasu nauczysz się jak zarządzać czasem podczas tych etapów, aby dostosować go do potrzeb i możliwości zespołu.

Wyjątkiem jest etap Spekulacji następujący na samym początku projektu – potrzebujesz więcej czasu, aby ustalić wszystkie funkcjonalności we wszystkich sprintach, więc możesz dodać to tego czasu kilka dodatkowych dni.

2. Aby móc ustalić, ile czasu potrzebujesz na ukończenie sprintu, stwórz listę elementów do wykonania, wraz z estymacją, ile czasu zajmie każdy z nich.

Następnie stwórz logiczną hierarchię ważności tych cech produktu, aby udało ci się je zmieścić w przewidzianym sprincie.

Cechy wytwarzanego produktu mogą być posortowane według:

• priorytetu biznesowego
• dostępnych możliwości technicznych
• dostępnych zasobów
• obszaru biznesowego

Czas potrzebny na wykonanie każdego elementu nie musi być precyzyjnie ustalony. Możesz użyć określeń taki jak mała liczba czasu, średnia lub duża wraz z przewidywaną liczbą godzin dla każdej kategorii. Możesz dostosować te estymacje podczas etapu Spekulacji.

3. Na podstawie liczby dostępnych osób w zespole oraz rozmiaru rozwijanych cech w produktu w każdym sprincie, możesz określić wielkość każdego sprintu.

Ustal ją i postaraj się, aby każdy sprint miał tę samą długość. Pomoże to twojemu zespołowi trzymać się harmonogramu oraz zachować rytm pracy.

4. W pierwszym sprincie zgrupuj cechy, które posiadają najwyższy priorytet w projekcie.

5. Wiele zespołów najlepiej radzi się podczas krótkich i ściśle ustalonych sprintów.

6. W trakcie trwania pierwszego sprintu testuj różne możliwości lepszego dostosowania pracy do potrzeb i możliwości zespołu.

Możesz zwiększyć lub zmniejszyć liczbę cech planowanych do zrealizowania w danym sprincie. Pamiętaj jedynie, aby ogólna długość sprintów i całego projektu pozostała taka sama.

Historie użytkowników to jeden ze sposobów na lepsze zrozumienie wymagań i potrzeb użytkownika. Pomagają one również w wypracowaniu kreatywnego podejścia do omawianego tematu.

Dzięki nim zespół odpowiedzialny za stworzenie produktu może przyjąć bardziej prokliencką postawę, zamiast skupiania się stricte na “taśmie produkcyjnej”.

Historia użytkownika to inne określenie cechy danego produktu. Jedyną różnicą pomiędzy tymi dwoma określeniami jest podejście – skupiamy się na końcowym celu danego działania, a nie odczłowieczonej funkcji.

Podczas opowieści musimy skupić się na określeniu, jaką wartość użytkownikowi ma dostarczyć konkretna opracowywana funkcja.

Po pierwsze musisz wczuć się w rolę końcowego użytkownika.
Po drugie określ, w jaki sposób konkretna funkcjonalność rozwiąże twój problem lub zaspokoi twoją potrzebę.

Aby stworzyć historię użytkownika, wystarczy zapisać kilka zdań na kartce papieru.

Szczegóły dotyczące danej funkcjonalności zostaną dodane dopiero na etapie produkcji.

Ten typ podejścia najczęściej jest stosowany w dwóch typach metodologii Agile – Scrum oraz Kanban.

Opowieści można zebrać w większą grupę, zwaną eposem (Epic).

Historie pisane są zazwyczaj przez Product Ownerów albo menedżerów produktu. Następnie zespół omawia na spotkaniu, które opowieści zrealizuje w danym sprincie.

Każda historia powinna zostać zakończona w wybranej iteracji.

Niewłaściwa implementacja Agile lub niedokładne przeszkolenie zespołu może doprowadzić do zniechęcenia współpracowników i mniej efektywnej pracy.

Dlatego też sprawdź, czy kluczowe elementy metodologii są używane prawidłowo:

• podczas codziennych spotkań nie rozwiązuj na nich problemów – powinny one służyć tylko wymianie informacji.
• nie rozwiązuj problemów za zespół – pozwól działać samodzielnie. Członkowie teamu są znacznie bliżej ewentualnego rozwiązania, niż osoba koordynująca pracę.
• project manager, product owner lub inna osoba na stanowisku lidera nie powinna brać czynnego udziału w pracy zespołu. Jego zadaniem jest koordynowanie i usprawnianie pracy.
• rozważ wdrożenie zautomatyzowanego testowania – Agile jest oparte na sprintach, przez co wymaga wielu rund testowania, co może odciągać pracowników od opracowywania ważnych funkcji.
• koncentracja na rozwoju projektu może spowodować niezauważanie błędów istniejących funkcjonalności – oprócz parcia na przód co jakiś czas zespół powinien naprawiać pojawiające się błędy, np. w oprogramowaniu
• pilnuj, by w jednej iteracji (sprincie) nie upchnąć za dużo nowych funkcjonalności – cechy nieopracowane w danym sprincie przechodzą na kolejny, co powoduje zatory i presję.
• uważaj na ryzyko wypalenia członków zespołu – duże tempo wprowadzania zmian powoduje, że członkowie zespołu mogą się czuć przeciążeni.

Popularność grupy metodyk Agile przez lata przyciągnęła nie tylko zwolenników tego typu zarządzania, ale i krytyków.

Według nich Agile posiada następujące wady:

• uboga dokumentacja – w przeciwieństwie do konserwatywnych metod, w zarządzaniu zwinnym zaleca się, by dokumentacja nie przekraczała kilku stron a4. Krytycy uważają, że takie postępowanie utrudnia komunikację w zespole i organizację pracy. Zwolennicy podkreślają, że często da się daną kwestię opisać i rozwiązać w bardziej wydajny sposób, niż tworząc dziesiątki stron dokumentów.
• brak koncentracji – istnieje ryzyko, że samozarządzające się zespoły nie będą odpowiednio skoncentrowane na pracy.
• nadmierne planowanie lub brak planowania – zespoły nieodpowiednio wyszkolone mogą nie wiedzieć, jak zaplanować pracę lub planują ją zbyt dokładnie.
• nieefektywność w dużych organizacjach – wielu krytyków woli podejście hybrydowe, polegające na połączeniu planowania z elastycznością Agile.
• moda na zarządzanie – według niektórych Agile to tylko inne określenie już wcześniej wypracowanych dobrych praktyk zarządzania.
• obawa klientów o niedokładność – przyjmując metodykę Agile istnieje obawa, że klient nie zrozumie braku sztywnych ram oraz uzna, że koszty projektu są trudne do przewidzenia i kontroli.
• niewłaściwe użycie metodologii – entuzjazm ze strony zespołów w połączeniu z obawą i oporem ze strony innych zainteresowanych stron może prowadzić do korupcji metodologii.

Agile to od wielu lat jeden z najpopularniejszych sposobów na zarządzanie projektem.

Narodził się w środowisku programistycznym, ale obecnie wielu praktyków uważa, że niemal każdy rodzaj biznesu może wdrożyć go i używać z sukcesem.

W przeciwieństwie do metody kaskadowej, czyli Waterfall, skupia się na szybkim dostarczaniu produktu, bez konieczności czekania na efekt końcowy.

Czy jest więc bardziej efektywny, niż konserwatywne podejście do project managementu? Niekoniecznie. To, jak Agile zostanie zaimplementowany zależy od jakości przeszkolenia pracowników oraz ich późniejszej motywacji, by stosować wyuczone praktyki.

W wielu dużych organizacjach Agile nie jest najlepszym sposobem na zarządzanie projektem. O wiele lepiej sprawdza się model hybrydowy, który łączy elastyczność z dokładnym planowaniem.