Agile i co dalej? Czyli krótki poradnik dla tych, którzy rozpoczynają projekt w metodykach zwinnych cz. 1

Aby usprawnić zarządzanie projektami w dobie szybkiego rozwoju technologii, coraz więcej firm decyduje się na pracę w metodykach zwinnych. Agile pozwala odpowiedzieć na pytanie, jak zakończyć projekt, trzymając się założonego budżetu oraz w jaki sposób tworzyć rozwiązania zgodne z potrzebami klientów.

Przygotowaliśmy cykl artykułów o Agile, z których dowiesz się:

• Jak się przygotować, aby wyciągnąć z projektów wykonywanych w metodykach zwinnych jak najwięcej?
• Co zrobić, aby sztandarowe hasła agile’owego marketingu przekuć na realne korzyści dla produktu?
• O czym należy pamiętać, aby rzeczywiście usprawnić pracę wykorzystując Agile?
• Jakie działania sprawią, że będziesz mógł rozwijać produkt o jak największej wartości?
• Co jest gwarantem realnego zwiększenia produktywności zespołów w metodykach zwinnych?

---

Różne podejścia do zarządzania projektami Agile 

W kontekście przyswajania zwinności nadal bardzo wyraźnie widoczne są dwa kontrastowe podejścia. Z jednej strony, zespoły developerskie i propagatorzy sztandarowej zwinności, wszem i wobec chwalą się przeprowadzaniem projektów w metodykach zwinnych, transformacją organizacyjną oraz podpisywaniem nowych kontraktów na realizację projektów agileowych. Z drugiej strony klienci wciąż nie są pewni, czy praca w metodykach zwinnych przyniesie im korzyści. Mają obawy czy brak szczegółowo spisanego zakresu projektu, nie będzie powodował wzrostu kosztów lub ciągłej zmiany harmonogramu wdrożeń. 

Entuzjazm zespołów z jednej strony i opór czy obawy interesariuszy z drugiej, mogą prowadzić do wypaczeń metodyki, która przecież została stworzona głównie z myślą o klientach. 

Jak pracować sprawniej, bez zbędnego nakładu pracy – czyli zwinne zarządzanie projektami 

Najlepszy slogan sprzedażowy zwinności i jednocześnie korzyść, która jest obwarowana największą ilością warunków do spełnienia.

Warunek 1: Kliencie! Nie spędzaj zbyt wiele czasu nad wyobrażaniem sobie finalnego efektu prac 

To trudne, bo niestety dąży do tego ludzki mózg (bądź sponsor Twojego projektu) i kiedy staramy się komuś opowiedzieć nad czym pracujemy, to już w głowie mamy zarys finalnego produktu. Jak więc należy postępować? 

• Skup się na określeniu, jakie funkcje ma pełnić produkt w Twojej organizacji, jakie potrzeby Twoich klientów będzie realizować. 
• Priorytetyzuj role i potrzeby tak, aby mieć jasny pogląd na to, co powstanie najpierw (od czego można zacząć / co sprawdzić, żeby mieć pewność, że chcę wchodzić w projekt dalej). Tworząc sklep internetowy nie zakładaj od razu, że powinien mieć wbudowaną porównywarkę cen. Może na początek wcale jej nie potrzebujesz? Dopiero na późniejszych etapach pracy, zastanów się nad jej wdrożeniem – może warto zintegrować się z już istniejącym rozwiązaniem, podpiąć analitykę i zobaczyć, ilu klientów z niego korzysta? Zanim zdecydujesz się wydać dodatkowe pieniądze na development Twojego wymarzonego narzędzia, odpowiedz sobie na powyższe pytania. 

Warunek 2: Nie marnuj czasu na zbędną analizę 

Uwaga – przez zbędną analizę rozumiem rozważania nad czymś, co “możliwe, że kiedyś, może za rok, pojawi się w produkcie”. Zapewniam Cię, że nie pojawi się… a nawet jeśli się pojawi, to nie w takiej formie, w jakiej założyłeś pół roku temu. Nie przywiązuj się do wybranych przez siebie rozwiązań. Z doświadczenia projektowego wiem, że często okazuje się, że Twoje poprzednie decyzje na tyle wpływają na architekturę, że wybrane we wcześniejszym czasie rozwiązanie okazuje się albo niepotrzebne albo zbyt czasochłonne. Wtedy analizujesz na nowo, czyli podwajasz koszty (a miałeś robić mniej, prawda?).

Nie zatrzymuj się na pierwszym wyborze

Zespół developerski może uchronić Cię przed zapatrzeniem w dane rozwiązanie. Przedstaw im swoje pomysły, wizję produktu, jak według Ciebie powinny wyglądać etapy jego wdrażania.

Otrzymasz od nich informacje – czy wybierać rozwiązanie otwarte na późniejsze elementy (może droższe na obecnym etapie, ale tańsze przy dalszym rozwoju produktu), czy opcję “na teraz” (na początku procesu może wydawać się, że jest to lepsze i szybsze wyjście, ale w kolejnych etapach rozbudowa będzie wymagała większego nakładu pracy).

Warunek 3: Świadomie zarządzaj zakresem projektu 

Magia zwinności opiera się na zarządzaniu zakresem projektu – dlatego musisz posiadać umiejętność powiedzenia interesariuszom “NIE” (albo przynajmniej “TERAZ NIE”). Wiele razy słyszałam o sytuacjach, kiedy zgodnie został wybrany zakres na pierwsze wdrożenie, ustalona została jego data i kiedy już wszystko wydawało się być na właściwej drodze do zmniejszenia nakładu pracy, pojawiały się dodatkowe wymagania, wprowadzające zmiany w już ustalonych działaniach – “nie tak to widzieliśmy”, “to działa inaczej, niż założyliśmy”.

Niektóre z tych zmian mogą oczywiście być wyjątkowo istotne, dlatego sukcesem jest również fakt, iż zostały zasygnalizowane jeszcze przed wdrożeniem. Znajdą się jednak takie osoby, które stwierdzą, że wersja pierwsza, bez migających kolorów na przycisku, byłaby wystarczająco dobra.

… i prowadź historię wersji

Najlepiej więc notować założenia odnośnie wersji i wdrożeń aplikacji, aby móc do nich wracać i świadomie decydować się na dodawanie do zakresu pozostałych elementów. Fakt, że pierwsza wersja Twojej aplikacji może nie spełniać 100% oczekiwań użytkownika, to nic złego. Jak powiedział Henry Ford: „Gdybym zapytał ludzi czego potrzebują, powiedzieliby mi, że szybszych koni”. 

Warunek 4: Warto rozmawiać! 

Przy zarządzaniu zakresem projektu, warto konsultować się z zespołem programistów – funkcja, która biznesowo brzmi jak “5 minut roboty”, może być całkiem sporym kawałkiem pracy nad architekturą systemu. Jeśli realizacja jakiejś funkcji jest ryzykowna, to pamiętaj, że minimalizowanie zakresu również przybliża Cię do zmniejszenia nakładu pracy. 

Zespół developerski również powinien brać na siebie część odpowiedzialności za „robienie mniej”. Z tego powodu, drogi Kliencie, rozmawiaj z nim jak najczęściej, angażuj go zanim zlecisz realizację jakiejś funkcji. Może razem uda Wam się wybrać rozwiązanie umożliwiające nie tylko spełnienie potrzeby Twojego biznesu, ale również nie wymagające diametralnych zmian i dużych nakładów pracy. 

Scrum i inne metodyki zwinne dostarczają Ci narzędzi, które ułatwią zarządzanie zakresem.

Masz poczucie, że “eksperymentujesz” z poszczególnymi funkcjami zbyt długo? Może warto zastanowić się nad skróceniem sprintu, aby zmusić siebie i zespół developerski do ograniczenia się do krótszych testów i sprawdzania biznesowych hipotez. W Grupie Unity posiadamy duże doświadczenie w realizacji takich projektów, jeżeli chcesz dowiedzieć się o nich więcej, zachęcam do zapoznania się z naszymi metodami pracy.

W kolejnych częściach cyklu o Agile dowiesz się:

• Jak identyfikować wartości w projekcie i w jaki sposób sprawdzać, czy realizujesz wyznaczone wartości? (Część 2)
• Dlaczego nie warto ograniczać metod realizacji projektów? (Część 3)