Blog

Jednym z „produktów” planowania sprintu jest uzgodniony przez zespół scrumowy cel sprintu. Wymóg, by cel ten został nazwany, dodany został do Scruma kilka lat temu. Miało to ułatwiać zespołom działanie – w tym samoorganizację – ale obserwacja zdaje się pokazywać, że stało się dokładnie na odwrót. Cel sprintu rodzi się często w bólach i jest wymęczonym, na siłę skleconym hasłem bez realnego znaczenia. Ma być, no to jest, ale niczemu nie służy.

Kłopot z ustaleniem celu sprintu jest w istocie manifestacją jednego lub wielu problemów, nad którymi trzeba się pochylić. Można rzec, że empirycznie (a jakże!) dowiadujemy się czegoś o naszym produkcie, naszym Scrumie a często i o nas samych. Zanim jednak rozwinę tę myśl, warto przypomnieć, o co chodzi z tym celem sprintu.

„Po co?”

To jest pytanie, na które cel sprintu powinien odpowiadać. „Po co robimy ten sprint?”. Inaczej mówiąc cel sprintu wyjaśnia, dlaczego zdecydowaliśmy się poświęcić czas i wysiłek na robienie akurat tych rzeczy, które podjęte zostały do realizacji z backlogu produktu. Co nam ma to dać? Jakiej wartości się spodziewamy? Co stanie się dzięki temu możliwe? Jaką wiedzę uzyskamy? Czego się nauczymy?

Cel sprintu nie był częścią Scruma od samego początku, ale został dodany w pewnym momencie by – jak napisałem wcześniej – ułatwić pracę zespołu. Jeśli jasno określimy, co jest naszym celem, wtedy staje się możliwe podejmowanie decyzji przez odniesienie się do owego celu. Jeśli mamy dwie możliwości zrobienia czegoś, wybierzemy tą, która cel pozwoli osiągnąć, albo pozwoli to zrobić szybciej / lepiej / taniej (niepotrzebne skreślić). To pierwszy powód, dla którego ten koncept w Scrumie się pojawił.

Jest i drugi, również ułatwiający pracę zespołom: w końcu jasne staje się, że zakres prac w sprincie może się zmieniać, a stały (i niezmienny) jest cel podejmowanych działań. W istocie zakres musi być zmienny, bo przecież nieustannie dokonujemy sprawdzenia stanu spraw i adaptacji planów i działań w oparciu o rezultaty takiej inspekcji. A cel musi być stały, bo to co robimy, robimy „po coś”.

Pojawia się zatem i trzeci sposób, w jaki cel sprintu ułatwia działanie w Scrumie. Otóż jasne staje się, kiedy Product Owner może przerwać już rozpoczęty sprint: wtedy, gdy uzgodniony w czasie sprintu cel już nie ma znaczenia i jego osiągnięcie jest bezcelowe. Przy czym nie chodzi tu o zmianę „priorytetów” – nie możemy przerwać sprintu tylko dlatego, że chcemy zacząć robić ważniejsze rzeczy a do tych bieżących wrócić później. Chodzi o zaprzestanie działań na rzecz celu, który stał się nieaktualny. Przykład: jeśli robiliśmy aplikację na targi, które zostały odwołane, to nie ma sensu jej kończyć. Inny przykład: jeśli robiliśmy produkt dla klienta, który zerwał z nami kontrakt, dalsze budowanie produktu może nie mieć sensu.

Kłopot z ustaleniem celu

Prywatnie sądzę, że twórcy Scruma mieli jeszcze jeden powód, by cel sprintu dodać jako coś obowiązkowego. Jeśli mamy kiepski backlog produktu, w którym nie do końca wiadomo, dlaczego pewne rzeczy poszybowały w górę a inne w dół, zaczyna być trudno odpowiadać na pytania w rodzaju „po co to robimy, czemu akurat to jest ważne”. Konieczność ustalenia jasnego celu sprintu ujawnia problem i marną kondycję Scruma, jakim się posługujemy.

Czy zdarza się wam, że w czasie planowania patrzycie na listę elementów backlogu produktu, które zostały podjęte do realizacji i drapiecie się po głowie zadając sobie pytanie: „co łączy je wszystkie”? Jeśli tak, zapewne backlog produktu ułożony został w sposób nie zapewniający choćby minimum spójności. Z czego może to wynikać?

Czym jest nasz produkt?

Jedną z przyczyn może być złe „wykrojenie” produktu z większej całości lub „zlepienie” w jednym backlogu potrzeb związanych z kompletnie różnymi produktami. To powoduje, że elementy backlogu będą ze sobą luźno powiązane lub tych związków nie będzie w ogóle. Faktycznie, ciężko wtedy mówić o klarownym celu i rodzą się potworki klasy „zrobić to wszystko” jako odpowiedź na pytanie co jest celem sprintu.

Jak sobie z tym poradzić? Cóż, rozdzielić te tematy na osobne backlogi i zamiast próbować w jednej długiej iteracji pracować nad wszystkimi produktami na raz, realizować krótsze sprinty, każdy poświęcając jednemu produktowi. Tempo budowania / rozwijania tych produktów raczej od tego nie spadnie, a możliwe stanie się uzyskanie backlogów z dużą (lub jakąkolwiek) spójnością.

Schyłek życia produktu

Ale czasami produkt jest dobrze zdefiniowany, a mimo to w backlogu znaleźć możemy przysłowiowy „groch z kapustą”. To może być objaw, że produkt doszedł do fazy, w której tak naprawdę dokonujemy szeregu mało istotnych zmian, bo brak nam odwagi do zatrzymania dalszych prac nad nim. Duży rozrzut tematów, między którymi nie ma związku i brak jasnej odpowiedzi, dlaczego akurat je robimy, to sygnał, że być może… trzeba przestać je robić. Zająć się rozwojem innego produktu, gdzie działania dają realną wartość. I tylko wtedy, gdy pojawi się sensowna konieczność dokonania w starym produkcie większej zmiany, wrócić do prac nad nim – już bez trudu znajdując odpowiedź na pytanie „czemu to robimy”.

Brak przejrzystości…?

Jeśli elementy backlogu produktu opisują komplementarne funkcjonalności, łączy je jakiś aspekt biznesowy, są elementami tej samej większej całości – wtedy mamy łatwo dostrzegalną spójność biznesową. Idealna sprawa, ale nie zawsze możliwa. Przykładem takiej spójności może być lista wymagań jak poniżej:

• Założenie nowego konta poprzez wypełnienie formularza
• Zmiana automatycznie wygenerowanego hasła dostępu
• Reset zapomnianego hasła
• Edycja danych użytkownika
• Zmiana adresu email, z którym związane jest konto użytkownika
• Logowanie i wylogowywanie się

Co łączy te wymagania? Wszystkie dotyczą obsługi kont użytkownika i gdyby stało się tak, że będą realizowane w jednym sprincie, to cel tego sprintu sam się nasuwa: „tworzenie i obsługa kont”.

Bywa wszakże tak, że potrzebujemy wykonać jakieś zmiany w produkcie po to, by możliwe stało się wydanie nowej jego wersji – wtedy mówimy o spójności wydaniowej. Popatrzmy na listę wymagań poniżej:

• Strona wymusza użycie certyfikatu SSL
• W stopce strony umieszczony jest link do „Polityki prywatności”
• W przeglądarce nie obsługującej JavaScriptu pojawia się informacja o wymogu jego włączenia
• Walidacja zgodności ze standardami HTML5 i CSS3 kończy się bez błędów i ostrzeżeń
• Tłumaczenia dla formularza rejestracji na język czeski są kompletne

Z pozoru te wymagania są kompletnie różne, ale jeśli wiemy, że to są jedyne rzeczy, których brak, aby uruchomić czeską wersję naszej strony internetowej, to nagle pojawia się spójność, czyż nie? Cel sprintu staje się oczywisty: „umożliwić wydanie strony po czesku”.

Jeśli i taka spójność wydaniowa nie jest możliwa, można „grupować” zmiany dokonywane w jednej technologii, w jednym komponencie systemu etc. W ten sposób pojawi się coś, co można by określić mianem spójności technologicznej. I wtedy cele sprintu – już nie takie łatwe do ustalenia, ale wciąż lepsze niż „zrobić to wszystko” – mogą przybrać formę na przykład taką: „Usunięcie obsługi nieużywanych protokołów z systemu centralnego banku”.

Jest jeden istotny warunek zapewnienia, że spójność będzie dostrzegalna. Warunkiem tym jest przejrzystość backlogu. Jeśli elementy coś łączy, albo jest jeden cel, dla którego zostały zdefiniowane – to powinno dać się zobaczyć. Product Ownerzy mają rożne sposoby, by to robić, wiele narzędzi ma gotowe mechanizmy. Tagi dopinane do elementów backlogu, konwencja nazywania elementów backlogu, możliwość wyświetlenia backlogu pogrupowanego po „tematach biznesowych”… to tylko kilka opcji.

Bezcelowy sprint

Najgorszą, na szczęście nieprzesadnie częstą sytuacją jest sprint, w ramach którego realizujemy wymagania, które nic nikomu nie dają, niczego nie umożliwiają, nie dają żadnej wiedzy ani wartości, a jedynie są etapem realizacji jakiejś większej całości. Jeśli tak jest, to naszym problemem nie jest cel sprintu ale… zupełnie nie-zwinne działanie. Scrum wymagając ustalenia sensownego celu sprintu (czego nie sposób zrobić w takiej sytuacji) daje nam możliwość dostrzeżenia tego problemu.

„Zrobić to wszystko”

A właściwie dlaczego taki cel – „zrobić to wszystko” – miałby być zły? – pytają często uczestnicy szkoleń, które prowadzę. Cóż, nie jest zły, tylko zwyczajnie marny. Pokazuje bowiem, że nie mamy żadnej lepszej odpowiedzi na pytanie o powód, dla którego podejmujemy kosztowne i wymagające wysiłku działania. Ciężko zresztą takim celem sprintu wesprzeć się w podejmowaniu decyzji.

Jest marny jeszcze z innych powodów. Niespecjalnie motywuje do działania, a wystarczy nie zrealizować choćby jednego elementu podjętego z backlogu produktu do sprintu i natychmiast staje się nieosiągalny. Tymczasem „mocny” cel sprintu to taki, który motywuje do działania, i jednocześnie pozwala na zachowanie elastyczności (niezbędnej do naprawdę zwinnego działania). Popatrzmy raz jeszcze na wymagania z przykładu:

• Założenie nowego konta poprzez wypełnienie formularza
• Zmiana automatycznie wygenerowanego hasła dostępu
• Reset zapomnianego hasła
• Edycja danych użytkownika
• Zmiana adresu email, z którym związane jest konto użytkownika
• Logowanie i wylogowywanie się

Jeśli celem jest „tworzenie i obsługa kont”, Product Owner może po dyskusji z zespołem developerskim uznać, że jest on osiągnięty nawet jeśli nie będzie się dało zmienić adresu email przypisanego do konta. Ba, cel ten – w ograniczonym zakresie – można uznać za osiągnięty nawet wtedy, gdy nie będzie się dało zresetować zapomnianego hasła i trzeba będzie radzić sobie pisząc do administratora systemu, by zrobił to ręcznie.

A cel „wydanie strony po czesku” i związane z nim wymagania?

• Strona wymusza użycie certyfikatu SSL
• W stopce strony umieszczony jest link do „Polityki prywatności”
• W przeglądarce nie obsługującej JavaScriptu pojawia się informacja o wymogu jego włączenia
• Walidacja zgodności ze standardami HTML5 i CSS3 kończy się bez błędów i ostrzeżeń
• Tłumaczenia dla formularza rejestracji na język czeski są kompletne

Można go uznać za osiągnięty mimo braku informacji o konieczności obsługi JavaScriptu, od biedy Product Owner może zaakceptować też rozwiązanie, które nie jest w pełni zgodne z HTML5 i CSS3, jeśli są tylko ostrzeżenia, ale nie ma błędów podczas walidacji. Znów: cel jest „mocny” ale i elastyczny.

„Zrobić to wszystko” daje niewiele możliwości takiego redefiniowania zakresu prac, jakie zostaną wykonane. Właściwie można to zrobić jedynie „przypiłowując” nieco każde lub niektóre z objętych tym celem wymagań, przy czym nie sprzyja to ani zachowaniu przejrzystości, ani nie ułatwia zarządzania backlogiem, do którego te „odpiłowane” rzeczy będą musiały trafić (ciężko je będzie jakkolwiek sensownie zdefiniować, bo w praktyce będzie to łatanie niedoróbek i braków…).