90 Sprintów dla Rynków Kapitałowych – część 2
Pierwszy artykuł z serii dotyczył zagadnień fundamentalnych, takich jak przydatność procesów Agile w dużych organizacjach. Teraz zajmijmy się sprawami bardziej praktycznymi.
Mit 6: „Planowanie jest nudne”
Rzeczywiście, jest nudne — jeśli próbujesz oszacować wszystkie Stories i zaplanować cały Sprint podczas jednego spotkania. Nawet w przypadku dwutygodniowych Sprintów może to zająć cały dzień. Sesję pielęgnacji backloga produktu przeprowadzamy co tydzień i trwa ona nie dłużej niż dwie godziny. Za pomocą standardowych technik, takich jak planning poker, oceniamy, analizujemy i szacujemy Stories. Skupiamy się na zadawaniu pytań na samym początku i zaznaczaniu zadań, które wymagają odpowiedzi. Wszystkie Stories muszą zostać wyjaśnione z pomocą Product Ownera przed sesją planowania. Dobrym pomysłem jest przegląd pozycji na dwa następne Sprinty. Gdy zespół rozumie wymagania, dana pozycja jest oznaczana jako gotowa do pracy — tylko takie są uwzględniane w Sprincie. Dzięki temu połączona sesja przeglądu i planowania trwa zwykle tylko około godziny.
Mit 7: „Agile nie wymaga pisania dokumentacji”
Tworzenie dokumentacji jest konieczne bez względu na stosowany proces dostarczania oprogramowania. Natomiast w Agile nie należy pisać zbyt wielu szczegółowych dokumentów na samym początku. Dosłownie każdy dokument dotyczący wymagań przygotowany na początku ulegnie później zmianie. Najważniejsze jest obranie odpowiedniego sposobu pracy z tymi zmianami, śledzenia historii i zapewnienie łatwego dostępu do bieżącej wersji. Lepiej niż dokumenty i wiadomości e-mail sprawdza się dobry issue tracker.
- Ogólna koncepcja – proces trafia do Epic
- Następnie jest ona dzielona na szczegółowe Stories
- Zwykle po wdrożeniu pierwszych Stories, pozostałe z tej samej Epic zmieniają się.
- Wyodrębnij opcjonalne dodatkowe funkcje do oddzielnych Stories, które wdrożycie później (lub nigdy)
Całą komunikację związaną ze Story należy umieścić poniżej jako komentarze. Gdy wymagania zmienią się, dodaj notatkę. Robimy tak zamiast wysyłania maili, jako tablicy dyskusyjnej online — efektem jest jednolite, przeszukiwalne repozytorium wymagań z historią zmian, dyskusjami i notatkami. Co więcej, przygotowana tak dokumentacja jest żywa — każde Story ma stan implementacji i testowania. Podobnie jak inne podejścia, Agile obejmuje tworzenie dokumentacji dla użytkowników, dokumentacji technicznej, zaleceń dotyczących wsparcia w środowisku produkcyjnym itd. Różnica polega na tym, że dokumentacji nie tworzy się tygodniami na samym początku procesu.
Mit 8: „Agile oznacza, że wymagania mogą zmienić się w każdej chwili”
Wymagania będą się zmieniać – zawsze tak będzie. Jest to normalna część procesu. Agile zapewnia strukturę umożliwiającą zmienianie wymagań w uporządkowany sposób. Aby pod koniec projektu nie pojawiły się zmiany powodujące, że jakaś część praca pójdzie na marne, konieczne jest wzajemne zrozumienie.
Jednocześnie programiści muszą pamiętać, że stworzenie pierwszej działającej wersji funkcjonalności prawie na pewno spowoduje zmiany w pozostałych Stories. Nasz zespół szybko przekonał się, że użytkownicy biznesowi często chcą mieć wgląd we wczesne wersje funkcjonalności i chętnie angażują się w proces tworzenia oprogramowania. Czasem oznacza to szybkie porzucanie pomysłów i zaczynanie od nowa. Mamy do czynienia z rynkami kapitałowymi: wymagania bywają bardzo złożone i mocno powiązane ze sobą. Pomyłki mogą być bardzo kosztowne, więc warto testować i naprawiać przed faktem.
Gdy otrzymujemy długi opis wymaganego procesu biznesowego, najpierw dzielimy go na mniejsze Stories, które umieszczamy w issue trackerze. Następnie każda z tych Stories jest uściślana, uzupełniana o informacje szczegółowe, w razie potrzeby dzielona na mniejsze, a czasem też zamykana. Każda Story „żyje” — ma swoją historię zmian, komentarze, przykłady i przypadki testowe. Wszystkie te informacje pozostają widoczne w tym miejscu. Początkowo staraliśmy się na bieżąco aktualizować oryginalną dokumentację projektową — z niewielkim powodzeniem. Okazało się, że wystarcza aktualizowanie na bieżąco ogólnego opisu danego Epic i opisów poszczególnych Stories. Zaoszczędzony czas lepiej przeznaczyć na tworzenie dokumentacji dla użytkowników w środowisku produkcyjnym.
Mit 9: „W procesach Agile nie projektuje się architektury”
W rzeczywistości jest to jeden z najtrudniejszych aspektów pracy Agile. Choć nie dzieje się to w sformalizowany sposób, podczas tak zwanego Sprintu 0 można wstępnie zaprojektować architekturę. Należy utworzyć potrzebne diagramy i ogólną wizję. Architekturę trzeba projektować tak, by można było ją dostosowywać do zmian. Podobnie jak w przypadku czystego kodu, istnieje wiele zasad projektowania czystej architektury. Większość wzorców architektonicznych jest dobrze opisana, a także ma swoje zalety i wady. Lepiej nie wymyślać nic nowego. Należy tylko pamiętać o potencjalnych kosztach zmiany części systemu i być przygotowanym na ciągłą refaktoryzację. Architektura nie może być ograniczeniem. Zmiany będą się pojawiać niezależnie od wybranego podejścia. Stosując podejście Agile, projektujemy zawsze z myślą o zmianach.
Mit 10: „Właściciel produktu musi tylko ustalić kolejność w backlogu”
Backlog nigdy nie jest zwykłą listą. Traktowanie go jako listy Stories uporządkowanej zgodnie z priorytetem to podejście bardzo powierzchowne. Nie wahaj się dodać do backloga wymiarów innych niż priorytet. Struktura backloga zależy bardzo mocno od interesariuszy biznesowych. Zawsze są tam jednak obecne główne elementy do wdrożenia w określonej kolejności, rzeczy opcjonalne, które można dodać w wolnym czasie, oraz poprawki błędów i zadania stricte związane z IT. Często nie można wszystkiego zmieścić na jednej liście. Największe problemy, na jakie natrafiliśmy to:
- Zespół zajmował się pozycjami, które nie były priorytetowe, ale trafiły na początek backloga przez pomyłkę.
- Ważna pozycje przepadły na końcu backloga lub zostały odkryte tuż przed planowaniem sprintu. Było za późno na analizę.
- Właściciel produktu czy interesariusze biznesowi stracili orientację w backlogu.
- Niejasne plany na najbliższą przyszłość.
Dzięki doświadczeniu zdobytemu w toku wielu Retrospektyw, udało nam się wypracować metody tworzenia skutecznych backlogów. Oto przykład:
- #NOW to lista pozycji, które zespół ocenia i uwzględnia w planach najbliższych Sprintów. Musi być krótka: najwyżej dwa Sprinty. Pozycje znajdujące się zbyt długo na liście #NOW spadają na listę #NEXT
- #NEXT to pojemnik na pozycje mające najwyższy priorytet w bliskiej przyszłości.
- #WAITING ROOM to lista nowych Stories, błędów, aktywnie ocenianych problemów, wybranych przez Product Ownera i analizowanych przez zespół. Żadne nowe pozycje nie mogą trafić na koniec backloga przez pomyłkę.
- Oddzielna lista #IT4IT, aby nie zanieczyszczać backloga produktu.
Pozycje są grupowane w Epics. Są łączone ze sobą i oznaczane etykietami (np. status, oszacowanie, priorytet, ważność (błędy), kategoria, komponent), aby umożliwić łatwe wyszukiwanie. Jeśli pozycje są grupowane w Epics lub komponentach, można określić „szerokość” backloga wynikającą z liczby różnych obszarów, których dotyka. Uporządkowanie takiego trójwymiarowego backloga może być łatwiejsze: „długość” x „priorytety” x „funkcja”. Bardzo przydatnym narzędziem może tu być Product Canvas Romana Pichlera.
