Wymagania w projektach zwinnych – działasz Agile czy tylko o tym mówisz

„Działamy teraz Agile” to częsta deklaracja, którą potem szybko i boleśnie weryfikuje codzienność.

Na Stack Overflow, najpopularniejszym w sieci miejscu, gdzie deweloperzy IT poszukują wiedzy, Fiona z Wielkiej Brytanii zadała pytanie, które odzwierciedla wyzwania, z jakimi spotyka się wiele zespołów pracujących w metodykach zwinnych:

"Nasz zespół deweloperski od jakiegoś czasu pracuje w SCRUMie. Mamy spriorytetyzowany backlog, który dzielimy na sprinty i śledzimy na wykresie burndown. W teorii wszystko wygląda świetnie. Problem zaczyna się, gdy menadżerowie, którzy zbierają wymagania, dostarczają nam je na kilka dni przed sprintem. Musimy je przejrzeć i zastanowić się, co jest możliwe do zrobienia, tak pod kątem technicznym, jak i ekonomii realizacji. Wtedy zmodyfikowane wymagania są odsyłane do osób zarządzających. I oczywiście kolejni interesariusze wprowadzają zmiany w detalach. A to zabiera sporo czasu. W międzyczasie nadchodzi data kolejnego sprintu, a zatwierdzonych wymagań nie ma, realizujemy więc to, o czym sądzimy, że jest w miarę stabilne. Gdy ukończymy "pewne" funkcjonalności, to zaczynamy pracę z tymi mniej stabilnymi, ale pojawiające się ciągłe modyfikacje bardzo mocno spowalniają nam pracę. Mam wrażenie, że źle tym zarządzamy, próbując wpasować waterfallowe wymagania w zwinny proces. Co z tym zrobić?"

Dobre praktyki i anty-wzorce

Sytuacja opisana na wstępie jest smutną codziennością wielu organizacji, które na fali popularności metod zwinnych zdecydowały się przejść na tę formę pracy projektowej. Niestety samo wdrożenie pracy w sprintach oraz deklaracja, że teraz jesteśmy "Agile", nie wystarcza. W szczególności zaś problem dotyczy wymagań projektowych. Jak więc podejść do tematu wymagań, by sprawnie realizować pracę w zwinnym środowisku?

Właściciele produktu (Product Owner/PO), którzy wychowali się na metodykach klasycznych, często koncentrują się na doprecyzowaniu wszelkich detali w specyfikacji (a potem trzymają kciuki, że wyspecyfikowali właściwe rzeczy). Wymagania zwinne oczekują natomiast wspólnego zrozumienia potrzeb klienta poprzez PO, architektów/designerów i zespół deweloperski. Taka, można rzec, empatia dla docelowego odbiorcy/klienta naszego produktu zdecydowanie zwiększa wydajność pracy z wymaganiami. PO może w takiej sytuacji skoncentrować się na wymaganiach wysokopoziomowych, podczas gdy szczegółami implementacji zajmuje się zespół deweloperski. I zespół zrobi to właściwie właśnie dzięki dobremu rozumieniu potrzeb i specyfiki klienta oraz użytkowników. Słowem: kiedy mamy to samo w głowach, to spisywanie szczegółowych wymagań po prostu nie jest potrzebne.

Wspólne zrozumienie potrzeb klienta

Wspólne zrozumienie potrzeb klienta nie pojawi się jednak samo. Co zrobić, żeby je zbudować?

a) Postaw na komunikację bezpośrednią. Kiedy realizowane są spotkania z klientem, zaproś na nie reprezentanta designu i zespołu deweloperskiego. Niech poznają wymagania odbiorcy bezpośrednio, a nie przez notatki PO. To nie tylko zbuduje świadomość potrzeb, ale także da możliwość bardzo cennego, natychmiastowego feedbacku dla klienta. Nie mówiąc już o tworzeniu poczucia przejrzystości i zaufania.

b) Zespołowo stwórz i pracuj z personami. Koncepcja person, jako krótkich opisów/modeli zachowań użytkowników systemu, może wydawać się na początku nieco dziwna. Ale praktyka pokazuje, że zrozumienie kilku kluczowych cech użytkowników systemu zdecydowanie przyczynia się do trafnych decyzji indywidualnych i zespołowych.

c) Nie oszczędzaj na zespołowym groomingu. Spotkania z PO i innymi interesariuszami oraz ciągłe dbanie, by wszyscy tak samo rozumieli backlog i jego priorytetyzację, jest fundamentem sprawnej realizacji wymagań.

d) Trzymaj wszystkie wymagania na jednej stronie. Utrzymuj centralny, prosty i przejrzysty backlog dostępny dla wszystkich. Gdy zespół jest w jednej lokacji, może to być po prostu kartka papieru czy tablica naścienna. Kiedy musisz pracować z wieloma lokacjami, rozwiązania takie jak Confluence, Jive czy Lithium przyjdą z pomocą.

Jednocześnie wystrzegaj się anty-wzorców co do tworzenia wymagań. Przykłady?

a) Wymagania są tworzone i spisywane przez właściciela produktu bez zaangażowania zespołu.

b) Cały projekt jest szczegółowo wyspecyfikowany, zanim zacznie się implementacja. To, co jest jak najbardziej prawdziwe w waterfallu, teraz zabija zwinność.

c) Oczekiwane jest, że wymagania będą podpisywane przez wszystkich, zanim w ogóle zacznie się praca.

d) Zespół deweloperski nie wie, kiedy ostatnio zaktualizowano wymagania.

e) W ogóle nie aktualizuje się wymagań ("Przecież zostały podpisane, pamiętasz?").

Jeśli zauważysz któreś z tych zachowań, to "wiedz, że coś się dzieje" i warto pochylić się nad przebiegiem procesu związanego z wymaganiami. Bo jak mawia stare powiedzenie: "zwinności łatwo się nauczyć, ale bardzo trudno ją dobrze zastosować".

Konrad Klepacki - Trener GRUPY ODITK