Blog

Na zakończenie szkolenia „Scrum w Pigułce” podszedł do mnie jeden z uczestników. Stanęliśmy wspólnie pod dużym schematem frameworku Scrum, który omawialiśmy przez kilka ostatnich godzin. Namyślał się chwilę, po czym spytał czy jego zrozumienie jest poprawne: czy Scrum służy eksperymentowaniu?

Przyjrzyjmy się, dlaczego w ogóle używamy iteracyjnego i inkrementalnego sposobu rozwoju oprogramowania: chcemy minimalizować ryzyko (rynkowe, technologiczne, finansowe itd.), w miarę często sprawdzać potrzeby użytkownika, regularnie powiększać wartość dla klienta. Nakładamy więc na nasz proces pewne ramy: ujmujemy go w iteracje (czyli stałe cykle, nie dłuższe niż miesiąc, służące wykonaniu czegoś działającego, sprawdzeniu tego i dostosowaniu) i zgodnie z zasadami Scrum przynajmniej na koniec każdej iteracji (zwanej Sprintem) dostarczamy przyrost produktu (zwany Inkrementem). Inkrement jest ukończony, przetestowany i gotowy do wydania (nawet jeśli z przyczyn biznesowych nie zawsze będzie rzeczywiście wydawany co Sprint – a w drugą stronę, może być wydawany nawet kilka razy w ciągu Sprintu) i co najważniejsze, klient od razu może go używać.

Ponieważ tworzenie oprogramowania jest złożone i skomplikowane, nie mamy jednak od razu pewności co będzie efektem naszej pracy. Dlatego układamy listę wymagań (Backlog Produktu), żeby nie pracować nad wszystkim na raz, ale by ustalić co ma największą wartość w tym momencie. To są właśnie biznesowe założenia eksperymentu – zobaczmy, czy w czasie tej iteracji uda nam się je spełnić i czego się nauczymy o produkcie i rynku. Pętla inspekcji i adaptacji zapewnia nam stały cykl uczenia i dostosowania.

Sprint jest więc tak naprawdę krótkim projektem, obliczonym na weryfikację biznesowych założeń. Ma zakres: jest nim Backlog Sprintu, czyli wymagania z Backlogu Produktu zabrane przez Zespół Developerski do wykonania, wraz z planem ich implementacji. Ma Cel Sprintu. Ma mechanizmy zadbania o przejrzystość inkrementu (choćby Definicję Ukończenia), żeby wiedzieć co zostało ukończone. Ma ustawiony deadline: to koniec Sprintu, którego nie można w żaden sposób wydłużyć.

Dzięki Scrumowi możemy podejść do klientów w nowy sposób, mówiąc: nie obiecujemy Wam wielomiesięcznych, ryzykownych projektów. W zamian za to otrzymujecie środowisko do eksperymentu. Przez dwa tygodnie będziemy pracować tylko nad wybranym zakresem (najbardziej wartościowe wymagania, od góry Backlogu). Zobaczymy ile z tego zmieścimy w iteracji, a później wspólnie przejrzymy, co skończyliśmy. Zdecydujecie o wydaniu tego lub kontynuacji prac nad nowymi wymaganiami, aż dojdziemy do punktu, w którym uznacie że to, co zostało zrobione, jest wystarczające.

Bez zbędnych wydatków na nieużywane funkcjonalności, bez ryzyka budowania czegoś, czego nie chcecie, bez obiecywania złotych gór, z możliwością zakończenia prac po każdym Sprincie.
Nawet jeśli efekty pracy nie będą zadowalające, najwyżej stracimy jeden Sprint pracy, zamiast wielu tygodni lub miesięcy przeznaczonych na projektowanie lub analizę.

Pamiętajmy jednak, że nieudane eksperymenty to wyłącznie te, w których nie uczymy się o produkcie niczego nowego, a nie te, w których uczymy się czegoś, czego początkowo nie przewidzieliśmy.