Blog

Czas na Agile

No i stało się. Nadszedł ten dzień, kiedy szef poinformował Cię, że czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie do Agile robione metodą skoku na głęboką wodę, to możesz poczuć się jak szeregowiec Cage, główny bohater filmu “Edge of Tomorrow”. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/ miała kolejnego podejścia w przypadku porażki projektu. Dla całego zespołu zmieni się część rzeczywistości dotycząca pracy, a może nawet zmieni się sam zespół. Zmiana będzie dotyczyła wielu aspektów pracy, na potrzeby tego artykułu musimy więc zawęzić zakres omawianych tematów. Proponuję, żebyśmy tym razem skupili się na temacie wymagań. Pracując z metodami Agile przez ostatnie 8 lat powiem Ci, że możemy również bezpiecznie założyć, że podejściem, które będzie Ciebie dotyczyło to framework Scrum. Zgodnie z koncepcją nauki sztuk walki, Shu-Ha-Ri najpierw potrzebujesz poznać podstawy.

Co zmienia Agile?

Z punktu widzenia wymagań, Agile wprowadza kilka znaczących zmian. Przyjrzyjmy się im po kolei.

Po pierwsze, wchodzi w życie to co jeży włosy na karku analityków biznesowych i testerów, czyli zasada pochodząca z Agile Manifesto, która mówi, że zmiana wymagań jest mile widziana. Oczami wyobraźni można zobaczyć jak klient ciągle zmienia zdanie i zespół nigdy nie jest w stanie dostarczyć dobrego produktu. Od razu mogę zapewnić, że tak nie będzie. Zmiany wymagań nie mogą być zupełnie nieograniczone i zachodzić w dowolnym momencie. Zespół pracuje w iteracjach określanych nazwą Sprint i wymagania przyjęte do realizacji na ten czas nie mogą zostać zastąpione innymi, bo ktoś zmienił zdanie. Dlaczego? Ponieważ taka zmiana powoduje, że szacowanie i planowanie wykonane na spotkaniu „Planowanie Sprintu” można od razu wyrzucić do kosza. Tym samym wyrzucamy do kosza umowę między Właścicielem Produktu, a Zespołem na to, co miało być dostarczone na koniec Sprintu. Wymagania w trakcie pracy można doprecyzować, ale to nie oznacza, że można „odwracać kota ogonem”. Możliwa jest natomiast negocjacja zakresu, kiedy zespół lub klient dowiedzą się czegoś nowego. I tutaj zwykle pojawiają się pierwsze konflikty IT z biznesem. „No, ale jak to, przecież mieliśmy być Agile, a teraz nie można dowolnie zmieniać wymagań, planów i zasobów?”. W tym momencie Scrum Master rusza na pomoc i edukuje biznes oraz chroni Zespół przed wpływami.

Agile stawia na reagowanie na zmiany ponad negocjację kontraktów, więc trzeba umożliwić implementację informacji zwrotnej, którą otrzymamy przynajmniej na „Przeglądzie Sprintu”. Metody zwinne są często wybierane przez organizacje, żeby lepiej reagować na potrzeby rynku i stać się bardziej konkurencyjnymi. Co to oznacza w praktyce? Możemy dobrze zaplanować okres od jednego do dwóch miesięcy i należy spodziewać się zmian w dalszych Sprintach. W niektórych organizacjach może być tak, że maksymalny stały horyzont planowania to będą maksymalnie 2 Sprinty tygodniowe. W odniesieniu do wymagań oznacza to, że szczegółowa estymacja zakresu bardziej odległych Sprintów nie ma sensu i byłaby stratą czasu. Praca nad wymaganiami odbywa się tutaj zgodnie z zasadą „Just In Time” zaczerpniętą z Lean i następuje w etapach. W związku z tym Rejestr Produktu będzie przypominał swoim kształtem górę lodową. Na czubku góry będziemy mieli małe elementy (np. User Story) opracowane wystarczająco i gotowe do implementacji w kolejnych 1-2 Sprintach. Elementy zaplanowane na kolejne iteracje będą tym większe i bardziej ogólne, im ich implementacja jest oddalona w czasie. Rejestr Produktu ciągle się zmienia i niektóre elementy mogą nigdy nie zostać zaimplementowane, a inne zupełnie się zmienić.

Skąd wiadomo, czy User Story jest opracowana wystarczająco, żeby ją zaimplementować w Sprincie? Właściciel Produktu i Zespół Developerski wspólnie uzgadniają ten standard i określają go jako Definicje Gotowości. Powinny się znaleźć tutaj takie elementy jak: zgodność z szablonem, Warunki Satysfakcji, kroki demonstracji, makieta ekranu, szkic przepływu danych itp. Jednak w żadnym wypadku „User Story” nie powinna narzucać rozwiązania i zawierać szczegółów technicznych.

Zdecydowanie mniej negatywnych myśli przywodzi na myśl fakt zbliżenia klienta lub przedstawiciela biznesu do zespołu. Stały i bezpośredni kontakt z biznesem to elementy, które na pewno wpływają korzystnie na jakość wymagań. Klient, czy użytkownik końcowy, to źródło informacji zwrotnej, dzięki której zespół buduje to co jest potrzebne i ma wartość.

Jak już wcześniej wspomniałem, nie ma czasu ani potrzeby na dogłębną analizę wymagań i projektowanie z góry. Opracowujemy tyle ile potrzeba i kiedy potrzeba. Pojawiają się zatem pytania o to, skąd wiemy jaki poziom szczegółowości jest potrzebny i jak planować dalszą przyszłość…