Zachwalanie podejścia zwinnego twierdzeniem że jest ono odporne na zmienne wymagania to bzdura. O wiele lepsze jest powiedzenie, że jest ono odporne na niedokładne i nieprecyzyjne wymagania. Ale zacznijmy od początku.
Wymagania, a potrzeba biznesowa
Wielokrotnie pisaliśmy już o naszym ulubionym trio w hierarchii rzeczy które nadają się do roboty (patrz: PBI). Na samym szczycie są potrzeby biznesowe. Jako takie nie definiują one rozwiązań, a jedynie nasze potrzeby, czyli to co musimy bądź chcemy zrobić, żeby osiągnąć określone rezultaty. I to właśnie te rezultaty zwykle stanowią kwintesencję naszej potrzeby biznesowej. Na tym poziomie naprawdę interesuje nas tylko i wyłącznie cel, a nie środki. Nasza potrzeba biznesowa może być zrealizowana jako funkcjonalność dostępna w naszej aplikacji komórkowej, webowej, jako serwis odpowiadający na wysłanie SMS-a, czy cokolwiek innego. Ważne, że działa.
Piętro niżej znajdują się konkretne wymagania, czyli zdefiniowany sposób na osiągnięcie danej potrzeby biznesowej. Wymaganie nie powinno definiować konkretnego rozwiązania, ale z całej palety możliwości może wybierać oczekiwany sposób jego realizacji. I znów, nie znaczy to, że ten sposób jest wyryty w kamieniu i nie może ulec zmianie. Liczy się tak naprawdę spełnienie wymagania, a nie zrealizowanie konkretnego zestawu czynności i zadań. Czyli, jeżeli wymyśliliśmy sobie, że jakaś funkcjonalność będzie dostępna w naszej aplikacji komórkowej, a na etapie realizacji wymagania dochodzimy do wniosku, że trzeba to (też) zrealizować w aplikacji webowej, to jest to okej. Zwykle jednak na poziomie wymagania wiemy, gdzie pojawi się nasze rozwiązanie, nawet jeżeli nieznane są nam wszystkie szczegóły.
Kolejny krok w precyzowanie prac do realizacji to zadania. Zadania jasno opisują co powinno być zrealizowane, gdzie i jak. Nie ma tu miejsca na interpretację, a jedynie na wykonanie konkretnego kawałka pracy. Można zaryzykować stwierdzenie, że zadania mogą być wykonywane bezmyślnie i wszystko będzie dobrze tak długo, jak tylko zadanie zostanie wykonane zgodnie z tym, co zostało z nim zapisane. Różnice pomiędzy dwoma ostatnimi typami prac znaleźć możecie w tekście „Wymagania, a nie zadania„.
Co z tą zwinnością?
Od zawsze powtarzamy, że w każdym podejściu opartym o filozofię agile zajmujemy się wymaganiami, a nie zadaniami. To zespoły realizujące pracę wybierają, w jaki sposób zrealizują one wymagania. Nie powinniśmy z góry narzucać konkretnego rozwiązania. Oczywiście, pewne sugestie i warunki brzegowe czy ograniczenia mogą i będą określone, ale w naszej zwinnej pracy wymagania zdefiniowane od A do Z (czyli de facto zadania) powinny należeć do rzadkości.
Możemy powiedzieć, że epiki bardzo często zawierają opis potrzeb biznesowych, a User Stories bardzo często zawierają opis konkretnych wymagań. Tutaj odsyłam też do tekstów o kryteriach akceptacji, a także różnicach pomiędzy kryteriami akceptacji i Definition of Done. Z jakiegoś powodu te dwa ostatnie często są mylone, do tego stopnia, że aż nagraliśmy o tym film na naszym kanale na YouTube.
Wracając jednak do wymagań i potrzeb biznesowych – ponieważ nie są one ściśle określone, znaczy to, że można je interpretować i realizować na wiele różnych sposobów. I tu pojawia się zarówno wyzwanie jak i rozwiązanie tego problemu. Bo skoro można coś zinterpretować na wiele różnych sposobów, to często będziemy popełniać błędy i mylnie odczytywać niektóre przesłanki. Na szczęście, każda metodyka spod znaku agile uwzględnia sposób radzenia sobie z tym wyzwaniem. Adresują to prace w krótkich iteracjach i częstym wspólnym weryfikowaniu efektów naszej pracy i tego, czy odpowiadają one prawdziwym oczekiwaniom.
Mówiąc inaczej, pracując zwinnie chcemy bardzo często omawiać już zrealizowane fragmenty prac po to, żeby upewnić się, że to co powstało spełnia także te wymagania, które nie zostały zapisane w kryteriach akceptacji bądź też były zapisane w niejasny sposób. To jedyna droga do tego, żeby upewnić się, że coś zostało zrealizowane właściwie. Bo wtedy dopiero jesteśmy pewni, co znaczy „właściwie”.
Zmienność czy nieokreśloność
Problem pojawia się w sytuacji, w której podejście zwinne wykorzystywane jest do uzasadnienia bałaganu – czy to po stronie wytwórcy, klienta, czy też zamawiającego. Podejście zwinne, na przykład Scrum, świetnie sobie radzi z odkrywaniem kolejnych wymagań w trakcie i uszczegółowieniem ich na etapie realizacji jakiegoś rozwiązania. W gruncie rzeczy jest to bardzo proste.
Po pierwsze, zaczynamy od wspólnego zrozumienia potrzeb biznesowych oraz wspólnego upewnienia się, że wymagania są zrozumiałe i mniej-więcej wiemy jak powinny być zrealizowane. Ten proces różnie się nazywa, ale z naszego punktu widzenia będzie to pewnego rodzaju refinement. Chcemy upewnić się, że na tak zwanych „grubych klockach” jesteśmy po tej samej stronie i rozumiemy się w ten sam sposób. Czujemy o co chodzi, nawet jeżeli nie znamy wszystkich szczegółów.
W kolejnych krokach pracy zwinnej będziemy brać te kawałki, które są najlepiej zrozumiałe, bądź te które są najbardziej pilne i najbardziej wrażliwe lub też te narażone na największe pomyłki. Będziemy je kawałki jak najszybciej realizować i wspólnie potwierdzać sobie, że to jest to, o co nam chodzi. Ponieważ te kawałki są małe, to ewentualne odstępstwa od oczekiwań nie są dla nas kosztowna i bolesne. Szybko i sprawnie jesteśmy w stanie wrócić na właściwą ścieżkę, bogatsi o nowe doświadczenia. Brzmi znajomo? Tak działa każda metodyka, którą możemy określić mianem zwinnej.
Niestety, to podejście nie zadziała, jeżeli ktoś próbuje wymusić na nas zmiany pierwotnych założeń bądź fundamentalnych decyzji. I nie mówię tu o absurdalnym przypadku kiedy klient chciał aplikacją na komórkę, a potem okazuje się że chodziło mu jednak o aplikacje na smartwatcha. Chodzi o coś bardziej prozaicznego, czyli „nie wiem, czego chcę”.
Nieprecyzyjne określone wymagania
Podejście agile, a także Scrum i wszystkie nasze ulubione i sprawdzone sposoby pracy sprawdzą się także w sytuacji, w której klient faktycznie nie wie czego chce i odkrywa swój produkt razem z nami. Wszyscy są wtedy świadomi, że ten proces będzie długi i często będziemy wycofywać się wcześniej obranych ścieżek. Jeżeli jesteśmy na to gotowi, a klient chce za to zapłacić to super. Działajmy zwinnie i budujmy wspólnie nowy produkt.
Gorzej jednak, gdy klient udaje, że wie czego chce, a następnie zmienia zdanie bez jakiegokolwiek uzasadnienia. Czasami może być to spowodowane tym, że zobaczył co zostało wytworzone i faktycznie nie odpowiada to jego oczekiwaniom. To dobrze, bo to znaczy, że zaczynamy się lepiej rozumieć. Czasami jednak jest to związane z próbą zrzucenia na nas winy za swoje nieprzemyślane decyzje. To jest problem, bo może on używać „argumentu agile” („agile znaczy zwinnie, więc musicie być przygotowani na moje zmiany decyzji”) do tego, żeby nic z tym nie robić po swojej stronie.
Nie da się pracować w żaden sposób i w żadnej metodyce z kimś, kto ciągle zmienia zdanie. Jeżeli jednego tygodnia mamy iść w lewo, w kolejnym tygodniu – w prawo, a 3 tygodnie później jednak mamy się cofać po to, by koniec końców stwierdzić, że w ogóle czegoś nie będziemy robić albo z powrotem wrócimy do pierwotnego rozwiązania, to żaden sposób pracy nie spowoduje że będzie to wydajne i efektywne.
To, co daje nam podejście zwinne, to wspólna praca nad produktem i stałe przybliżanie się do wizji, punktu docelowego czy też Celu Produktu. Jeżeli punkt do którego zmierzamy cały czas się przesuwa, to nigdy do niego nie dotrzemy. Nigdy nie zbudujemy czegoś naprawdę wartościowego i wyjątkowego.
Nieokreślone, ale stabilne wymagania
Dlatego warto powiedzieć to wszystkim – i dostawcom, i zamawiającym że bez precyzyjnego określenia potrzeb biznesowych i fundamentalnych wymagań naszego produktu, jakakolwiek praca nie ma sensu.Nawet jeżeli robimy coś nowego i innowacyjnego, musimy przyjąć jakieś założenia i musimy poruszać się w jakichś ramach. Albo najważniejsze i fundamentalne decyzje muszą już być podjęte, albo musimy je podjąć wspólnie (patrz: Product Owner). Nie chodzi tutaj o wszystkie najdrobniejsze szczegóły, ale musimy wiedzieć, czym jest nasz produkt i jakie są jego wyjątkowe i najważniejsze cechy. Nawet jeśli nie wiemy, jak zostaną one osiągnięte, to bez tego „zamrożenia” kluczowych aspektów nie dotrzemy nigdzie.
Nie używajmy „argumentu agile” jako uzasadnienia dla naszych nieprzemyślanych decyzji, braku planów, braku koncepcji czy wizji. Zacznijmy budować zwinne na silnych i dobrze zdefiniowanych fundamentach. I oczywiście, nie znaczy to, że musimy wiedzieć absolutnie wszystko. Ale musimy wiedzieć na tyle, żeby nasze błądzenie było poszukiwaniem najlepszego rozwiązania, a nie dopiero poszukiwaniem problemu do rozwiązania.
Bardzo bym chciał, żeby istniała jakaś jedna konkretna granica, przy której można powiedzieć, że zbyt luźno zdefiniowane wymagania stają się przeszkodą. Na pewno zbyt dokładnie określone zadania zabijają zwinność i wypaczają to podejście. Z tej strony jest prosto – nie chcemy mieć w backlogu „zadań do realizacji”, które nie pozwalają na jakikolwiek stopień swobody w ich wykonaniu. Po raz kolejny powtórzę: wymagania, a nie zadania.
Jeżeli jednak chodzi o ściśle zdefiniowane ramy i fundamenty, to musimy tutaj działać na podstawie naszych doświadczeń i wiedzy eksperckiej. Warto jednak pamiętać, że zwinność nie może być używana jako argument dopuszczający chaotyczne decyzje i brak zdecydowania u osób definiujących wymagania i potrzeby. Przede wszystkim liczy się efektywność i wartościowy produkt. Jestem przekonany, że brak wiedzy o tym, czym jest ta wartość, przeszkodzi nam w sukcesie.
