Z napisaniem tekstu o tym, jak zacząć pracę w Scrum nosiłem się od dawna. Kiedy dołączamy do już istniejącego zespołu, wszystko wydaje się być proste i poukładane. Mamy Product Ownera, Scrum Mastera, są koledzy i koleżanki tworzący Zespół Deweloperski. Ale co, jeśli jesteśmy na samym początku i nie mamy jeszcze nic?
Zaczynamy Scrum…
Od czego powinniśmy zacząć? Dobre pytanie! Na pewno nie od „Sprintu zero”. Przy okazji tego pytania zawsze przypomina mi się jedno z pytań egzaminacyjnych na certyfikaty Scrum. Nie ma czegoś takiego jak Sprint 0. Nie ma żadnego przygotowania do pierwszego sprintu deweloperskiego.
Często padają w tym momencie pytania, „Co z architekturą bazy danych? Co z projektami interfejsów?” Odpowiedź brzmi – nic. One oczywiście powstaną, ale w najlepszym do tego czasie i przy okazji realizowania pozostałych wymagań. Nic nie stoi na przeszkodzie, żeby prace architektoniczne działy się w kolejnych Sprintach. Skomplikowanie budowanych rozwiązań i powstającej architektury będzie zwiększało się z każdą kolejną iteracją.
Bo czy musimy wszystko wiedzieć już na samym początku? Czy powinniśmy znać szczegółowe specyfikacje wszystkich interfejsów, z którymi ma komunikować się nasz system? Czy możemy zaplanować sposób realizacji całego rozwiązania? Odpowiedź jest oczywista, a zmiany są nieuniknione. Po co więc projektować coś, czego możliwe, że nigdy nie użyjemy? I jako co potraktować stracony czas?
Pierwszy Sprint
Skoro wiemy już, że nie ma czegoś takiego jak Sprint 0, po prostu rozpocznijmy właściwą pracę. O tym, w jaki sposób zbudować pierwszy backlog opowiedzieliśmy już na naszym #białkowym kanale na Youtube. A kiedy mamy już spriortetyzowaną listę wymagań możemy zabrać się do pracy, czyli do przekształcania elementów Backlogu Produktu w działający produkt.
Jak mówi praktyka, pierwszy Sprint powinien zakończyć się potencjalnie wdrażalnym przyrostem oprogramowania, zgodnym z Definition of Done. Taki przyrost powinien zawierać przynajmniej jedno w pełni zrealizowane wymaganie. Jak już napisałem wcześniej, nie zastanawiamy się tutaj nad kompletną architekturą, nie robimy podwalin pod „coś większego„. Ruszamy do pracy i działamy. Nie ma na co czekać.
Powstająca architektura i projekty dotyczą aktualnie realizowanego zakresu pracy oraz tego, co już wiemy, że będzie realizowane w najbliższej przyszłości. Uwzględniamy także wymagania niefunkcjonalne, które zwykle lądują w User Stories jako HLAC-i lub w Definition of Done właśnie.
Co nas może spotkać podczas pierwszej iteracji? Konflikty interpersonalne, niezrozumiałość wymagań, brak wspólnego rozumienia wycen czy brak wspólnego, jednakowego rozumienia Scruma. Krótko mówiąc – nieporozumienia. Musimy być na nie przygotowani.
Budowa Zespołów
Zespół to zbiór profesjonalistów, ma być między-funkcjonalny i samoorganizujący się. Nie ma się co oszukiwać, na początku nie będzie różowo. W pierwszej kolejności powinniśmy zadbać o jak największy stopień kross-funkcjonalności. Do tego potrzebne jest zaufanie. Jeśli ludzie się znają (a często tak jest, świat IT nie jest znowu taki duży), to sami będą w stanie podzielić się na dobrze zorganizowane, odpowiedzialne zespoły. Jeśli nie – musimy im pomóc.
Kiedy utworzyliśmy już zespół naszych marzeń, zadbajmy też o aspekt samoorganizacji. Sposobów na powyższe jest bardzo dużo, jednak najważniejsze abyśmy jasno ustalili, które kompetencje leżą w gestii zespołu, a które w gestii osób zarządzających projektem. Raz podjęte decyzje co do podziału obowiązków mogą zostać zmienione (jeśli wymaga tego sytuacja), ale dajmy sobie nieco czasu na „złapanie” stanu bieżącego.
Do obu tych rzeczy można wykorzystać wiele technik i narzędzi. Dobry Scrum Master lub Agile Coach na pewno podpowie sposób poradzenia sobie z tymi zadaniami i odpowiednio je wesprze.
Scrum Start
Nasz zespól przepracował pierwszy Sprint i wytworzyliśmy element działającego oprogramowania. Co dalej? Zakładając, że działamy w Scrum musimy dopełnić „formalności” z nim związanych. Czas więc na przegląd aktualnego stanu backlogu wraz z interesariuszami (Sprint Review) oraz weryfikację, w jaki sposób pracowaliśmy (Retrospektywa). Dopiero po zakończeniu powyższych możemy otworzyć butelki z szampanem na koniec pierwszego Sprintu.
Niezwłocznie po zakończeniu Sprintu pierwszego przechodzimy do rozpoczęcia Sprintu numer dwa. Rozpoczniemy go oczywiście od ustalenia kolejnych prac na spotkaniu Sprint Planning. Od tej pory nasze projektowe życie będzie już mniej urozmaicone, chociaż na pewno nie nudne.
Nasz Scrum może oczywiście przechodzić zmiany. Jeśli czujemy, że zmieniając długość sprintu będziemy pracować wydajniej, zróbmy to. Jeśli zespół nie rozumie co jest do zrobienia w danym wymaganiu, zmieńmy sposób prowadzenia Product Backlog Refinementu. Mniejsze urozmaicenie pracy nie oznacza, że nie będzie co robić. Będziemy jednak mieli już pewien szkielet organizacji naszej pracy, którego będziemy się trzymać.
Jak zacząć pracę w Scrum?
Nie mogę w tym miejscu nie przywołać argumentów tych, którzy napiszą „A gdzie planowanie projektu, gdzie te wszystkie czynności, które odbywają się przed jego uruchomieniem?” Te elementy są oczywiście ważne, ale nie dotyczą bezpośrednio Zespołu Deweloperskiego. Nie dotyczą nawet Scruma, bo nie ma w nim ani jednego zdania dotyczącego aspektu organizacji projektu.
Zastanawiam się zawsze, czy nie jest to najważniejszy czas z punktu widzenia naszego klienta. W etapie przygotowania projektu, najważniejsze dla niego (w zależności od przyjętej metodyki pracy) będzie budżet oraz kamienie milowe związane z dostarczanym produktem. Pozostałe aspekty są raczej drugoplanowe. Może więc warto, aby PM skupił się na właściwym przygotowaniu projektu, a my jako Scrum Team już po wszystkim powiemy:
No to zaczynamy!
I zaczniemy robić to, na czym znamy się najlepiej!
