11 lutego 2016 6min.
Budujemy samochód #2 – model zwinny
W poprzednim artykule zastanawialiśmy się, dlaczego dobrze opisane projekty często kończą jako nietrafione inwestycje albo powodują duże tarcia na linii klient-dostawca. Chętnych do nadrobienia zaległości odsyłam do części pierwszej.
Zawartość artykułu:
W drugiej części zostaję przy projekcie „szybki samochód”, ale zmienię podejście na zwinne (Agile). Jestem zdecydowanym fanem tej metodyki i możesz odnieść wrażenie, że trochę tendencyjnie podchodzę do sprawy, ale postaram się wszystkie argumenty uzasadnić tak, żebyś sam mógł podjąć decyzję, co będzie lepsze dla Twojego projektu.
Co poszło nie tak
Przy próbie realizacji projektu zaprezentowanej w poprzednim artykule okazało się, że ktoś wpadł na pomysł, żeby przyspieszenie 0-100km/h osiągnąć, strzelając samochodem z armaty. Co prawda w ten sposób można było odhaczyć wymaganie funkcjonalne, natomiast w produkcie końcowym zabrakło tego, co trudno uchwycić na papierze – wartości.
Gdybyś poszedł do salonu samochodowego, z pewnością obyłoby się bez tak przykrych niespodzianek. Decydując się zaś na dedykowane (niezależnie w jakim stopniu) rozwiązanie, stajesz się beneficjentem innowacji. To główna cecha, która rozgranicza produkty z taśmy montażowej od tych tworzonych pod indywidualne wymagania klienta.
Wróćmy zatem do podejścia waterfallowego. Tu szczegółowa specyfikacja projektu powstaje przed rozpoczęciem prac wdrożeniowych. Innymi słowy, zakładasz się o kwotę projektu, że rok przed oddaniem prac wszystko zostało dobrze przemyślane. Czy to rozsądne? Oczywiście, że nie! Ryzyko, które ponosisz, jest ogromne:
- ktoś źle zrozumie zapis,
- zmieni się rynek zbytu,
- zmieni się prawo,
- zmieni się konkurencja,
- zmienią się trendy,
- etc..
W związku z tym każdy błąd w kilkusetstronicowej specyfikacji będzie powodował nawarstwianie się problemów. Efektem będzie utrata wartości.
Miałem przyjemność przeprowadzać kilka analiz biznesowych dynamicznie rozwijających się firm. Dokumentacja potrafiła zdezaktualizować się jeszcze w trakcie procesu. To samo dotyczy samej natury projektu. Jeżeli mówimy o Internecie, trudno przewidzieć moment, w którym nastąpi tąpnięcie. Wystarczy przypomnieć sobie takie marki jak Amazon, Zalando czy Uber.
A co na to zwinność?
Metodologia zwinna (ang. Agile) najłatwiej opisuje się jako mikser, do którego wrzucamy cały proces watefallowy. Kolejnym krokiem jest „rozlanie po równo”, w efekcie czego dostajemy cykle, z których każdy:
- jest planowany z krótkim wyprzedzeniem,
- jest opisany w momencie rozpoczęcia,
- zawiera sensowny do opanowania zakres prac,
- podlega odrębnym testom i przekazaniu klientowi.
Biorąc pod uwagę, jak krótkie są poszczególne cykle (zazwyczaj od 2 do 4 tygodni), nie tylko znacząco skracamy horyzont niepewności, ale także możemy skupić się na bieżącym tle projektowym.
Dodatkowym ważnym elementem, który w ogóle nie musi wystąpić przy wodospadzie, jest tzw. retrospekcja, czyli praca nad poprawą jakości współpracy. To moment, w którym możemy sobie powiedzieć, co poszło nie tak, znaleźć tego przyczynę i w następnej iteracji lepiej spełniać wzajemne oczekiwania.
Co niesie ze sobą Agile?
Mówię to każdemu klientowi, także tym przyszłym – żeby Agile się sprawdził, wszyscy musimy pokochać projekt. Ty, będąc product ownerem, będziesz czynnie uczestniczyć w cyklach produkcyjnych, mając realny wpływ na kształt projektu na każdym jego etapie. Dobrze wybrany wykonawca będzie przeciwwagą do Twoich pomysłów na poziomie biznesowym i wsparciem na poziomie funkcjonalnym.
Drugą ważną kwestią jest mniejsza formalizacja. W Agile nie produkujemy tony niepotrzebnych dokumentów, skupiając się na dostarczaniu wartości. Będąc fanem zdrowych relacji i dynamiki projektu, to dla mnie najważniejsza wartość płynąca ze zmiany metodyki. Mając porównanie, dużo lepiej w XC wypadły projekty, w których zamiast chować się za ścianą papieru, poświęcaliśmy więcej czasu na dyskusje, wyciąganie wniosków i bieżącą pracę.
Jak to ma się do samochodu?
Wróćmy do naszego samochodu. W alternatywnej historii:
- cel biznesowy (0-100km/h w 3 sekundy) będzie postawiony od razu,
- funkcjonalność zostanie doprecyzowana wtedy, kiedy będzie to konieczne,
- wszyscy będą mieli wpływ na kształt funkcjonalności.
Szczególnie ostatni punkt będzie dla Ciebie istotny. Będziesz bowiem mógł odbyć z zespołem burzę mózgów i na wstępie wykreślić pomysły, które nie zbiegają się z Twoją wizją projektową.
Dokładnie tyle wystarczyło w tym wypadku. Dobre relacje projektowe, wspólna chęć zrobienia „czegoś wielkiego” i planowanie wtedy, kiedy występuje taka konieczność. To, co leży u podstaw metodyki zwinnej, niekoniecznie w ogóle musi występować w Waterfallu.
O co się zakładasz w Agile?
Nie jest tak, że Agile nie niesie ze sobą ryzyka. Środek ciężkości przeniesiony jest na Twoje zaufanie do firmy. Co może pójść nie tak:
- nie zbudują się dobre relacje (jałowy projekt),
- problemy z budżetowaniem projektu.
Te dwa problemy są głównym spowalniaczem, jeżeli chodzi o wzrost udziału metodyki na rynku usług. W istocie potrzeba dużo zaufania do firmy, żeby powierzyć jej zwinną realizację projektu. Nawet jeśli w przypadku problemów o wiele łatwiej w Agile taką firmę wymienić, nie oszukujmy się – na zaawansowanym etapie projektu nie jest to wcale takie proste.
Podsumowanie
Jeżeli projekt ma sprawić, że staniesz się beneficjentem innowacji, warto przynajmniej przemyśleć korzyści płynące ze zwinnego podejścia, o ile jest to tylko możliwe. Przy odpowiednim doborze firmy (o tym jeszcze na pewno porozmawiamy), zyskujesz nie tylko wykonawcę, ale przede wszystkim partnera, którego zadaniem nadrzędnym będzie skupienie się razem z Tobą na dostarczonej wartości. Ta chemia powoduje, że zbędna stanie się większość dokumentacji, popularnie zwanych dupochronami.
Agile to także większa kontrola nad projektem i możliwość wpłynięcia na jego kształt w każdym momencie, co przełoży się na efekt dopasowany do bieżących potrzeb.
Czy zawsze polecę Agile? Nie, znam przypadki, gdzie nie ma to większego sensu. Ale o tym wkrótce.