Agile i co dalej ? Czyli krótki poradnik dla tych, którzy rozpoczynają projekt w metodykach zwinnych cz. 2
W poprzednim artykule wspominaliśmy o kontrastowych podejściach do Agile oraz o warunkach, jakie należy spełnić, aby sprawniej pracować, bez zbędnego nakładu pracy.
Z drugiej części cyklu artykułów o Agile dowiesz się:
- Jak identyfikować wartości w projekcie?
- W jaki sposób sprawdzać, czy realizujesz wyznaczone wartości?
- Dlaczego nie warto ograniczać metod realizacji projektów?
Dzięki metodyce Agile, tworzysz produkt o największej wartości
Ten slogan jest silnie związany z kwestią omawianą w poprzednim artykule, czyli jak pracować sprawniej, bez zbędnego nakładu pracy – odnosi się bezpośrednio do zarządzania zakresem projektu. Aby móc skierować prace programistyczne na elementy najbardziej wartościowe, powinieneś znać poniższe zasady:
Warunek 1: Miej świadomość jakie wartości posiada Twój projekt
Wartością dla projektu może być ROI, ale równie dobrze może być nią też eliminacja ryzyka. Jeśli nie ma pewności (o tym jak ją zyskać napiszę za chwilę), że klienci będą korzystać z danej funkcji, to czy warto realizować w całości tę, na której teoretycznie mógłbyś najwięcej zarobić?
Pracuj nad identyfikacją wartości dla każdego interesariusza projektu – i bezpośrednio do elementów z tej listy odnoś cele zadań, nad którymi pracują developerzy. Priorytetyzuj te wartości, aby dać zespołowi jasną informację o czym powinni pamiętać rozwijając produkt.
Warunek 2: Regularnie sprawdzaj, czy realizujesz wyznaczone wartości
Sposobów jest wiele – jednym i bardzo istotnym jest regularne dostarczanie wytworzonych funkcji użytkownikom. Zbieraj feedback poprzez obserwację tego, jak pracują z systemem. Gromadź informacje zwrotne już od samego początku – unikniesz w ten sposób inwestowania czasu i pieniędzy w nietrafione rozwiązania. Osiągniesz to poprzez umożliwienie wdrażania nawet małych elementów systemu lub pojedynczych funkcji – takie podejście zagwarantuje Ci, że użytkownik końcowy będzie nie tylko mógł na bieżąco dostarczać Ci feedback o funkcjonowaniu systemu, ale również nie będziesz poświęcał dodatkowej energii i kosztów na utrzymanie zalegającego kodu.
Drugim sposobem (choć najlepiej, jeśli korzystasz z obu jednocześnie) jest wyznaczenie sobie odpowiednich mierników jakościowych. Zakładam, że jeżeli nie masz pewności, jak długo zamierzasz korzystać z danego rozwiązania, to nie chcesz ponosić kosztów związanych z zapewnieniem najlepszej prędkości ładowania strony. Ustal więc odpowiednie poziomy jakościowe, wydajnościowe lub funkcjonalne dla każdego z etapów projektu. Tworzysz rozwiązanie, które powinno być intuicyjne? Może odpowiednim miernikiem byłoby wybranie grupy testerskiej, nieznającej produktu i zlecenie im pracy z nowymi funkcjami? Pozwoli Ci to odpowiednio priorytetyzować zadania, nad którymi będą pracować developerzy. Jaką wartość będzie dla Ciebie miała najbardziej rozbudowana funkcja, skoro Twoi użytkownicy nie będą wiedzieli jak z niej skorzystać? Pamiętaj, że podstawą filozofii Agile jest empiryzm – najpierw przetestuj pomysły, zamiast zakładać, że już od początku wiesz najlepiej, jak powinno wyglądać gotowe rozwiązanie.
Warunek 3. Nie mów o tym “jak” mów o tym “co”
Wspominałam już o tym aspekcie, mówiąc o wyobrażaniu sobie efektu prac. Nie ograniczaj mnogości sposobów na realizację jakiejś funkcji, tylko dlatego, że już to kiedyś widziałeś albo zasłyszałeś. Nie bez powodu nad wdrażaniem projektów pracują zespoły – nie od dziś wiadomo, że co X głów to nie jedna. Korzystaj z tego, że jest Was wiele i mnóż tę korzyść, pozwalając zespołowi na uczestnictwo we wczesnych fazach projektowania rozwiązania. To oni będą zadawać kluczowe pytania dla wyboru architektury. Może się zdarzyć, że mieli już okazję pracować nad podobnym rozwiązaniem przy innych projektach i wiedzą, na co należy zwracać uwagę. Będą mogli wskazać, które rozwiązanie będzie bardziej czasochłonne, a które bardziej skalowalne.
Znowu dostarczanie zespołowi szczegółowej dokumentacji, a następnie zapraszanie ich na „burzę mózgów” i oczekiwanie na deszcz propozycji rozwiązań, także mija się z celem – z tego samego powodu, dla którego najpierw oglądając film, a później czytając książkę, wyobrażasz sobie postaci jako filmowych aktorów i przypominasz sobie sceny z ekranu. Raz zobaczone rozwiązanie trudno jest “odwidzieć” i przestawić się na myślenie o alternatywnych drogach. Zachęcam do lektury prac Theodore Levitt’a, który świetnie ujął to, co próbuję przekazać w owym artykule:
People don’t want to buy a quarter-inchdrill.
They want a quarter-inch hole.
Powtarzam więc ostatni raz: skup się na potrzebie, nie zakładaj z góry gotowego rozwiązania.
Z ostatniej części cyklu artykułów o metodyce Agile, która pojawi się w przyszłym tygodniu na blogu, dowiesz się:
- W jaki sposób metodyka Scrum napędza pracę zespołu?
- Na jakich elementach projektu należy się skupić, pracując w Scrumie?
