Na miejsca, gotowi, start – Skalowanie Agile

Na początku wyścigu zwykle słyszy się: „Na miejsca, gotowi, start". Na poziomie zespołu „Ready to Develop" – czyli „gotowe do wytwarzania" – oznacza, że User Story jest gotowa do przekazania zespołowi i włączenia do kolejnego Sprintu. Ready to Develop jest często postrzegane jako uzupełnienie Definition of Done. Dla porównania: Definition of Done ma sens zarówno w odniesieniu do pojedynczego zespołu, jak i wtedy, gdy kilka zespołów dąży do wspólnego celu. W praktyce „ready" nie da się tak łatwo przenieść na większy projekt jak „done". W większych projektach zwinnych „Ready" często wymaga dwóch różnych kryteriów: „Ready to Develop" i „Ready to Go".

Pięć prostych kryteriów dla skalowania zwinności

Najpopularniejsze kryteria Ready są wbudowane w „Ready to Develop". Ready to Develop jest stosowane na poziomie zespołu. Kryteria są następujące:

• Story jest dobrze zdefiniowana.
• Story spełnia kryteria INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
• Story wymaga kryteriów akceptacji.
• Dla każdej Story powinien być dostępny zewnętrzny ekspert (spoza zespołu) z danej dziedziny.
• Nie ma zewnętrznych zależności, które uniemożliwiłyby ukończenie Story.

Na podstawie tych pięciu kryteriów można dobrze ocenić, czy w kolejnym Sprincie można od razu zacząć pracę nad daną User Story, czy też potrzebne jest jeszcze więcej groomingu. Zespoły naturalnie wolą prace, które można od razu podjąć, od tych, które są słabo zdefiniowane.

Team of Teams i kolejny poziom

Taką samą preferencję ma tzw. Team of Teams (przykładem jest Agile Release Train w SAFe). Aby jednak Team of Teams mógł określić, czy jest gotowy do rozpoczęcia pracy, potrzebuje kryteriów na wyższym poziomie. Kryteria „Ready to Go", których najczęściej używam, są następujące:

1.) Zespoły zsynchronizowały swój rytm wytwarzania. Wyrównanie rytmu zespołów i znalezienie wspólnego rytmu to bardzo dobre działanie zapewniające komunikację i integrację.

2.) Istnieje wystarczająco zadbany Backlog. Należy zidentyfikować i przygotować tyle pracy, by móc rozpocząć pracę i wspierać zespoły – nie więcej. Backlog nie musi być kompletny (ani w pełni rozpisany), zanim praca się rozpocznie.

3.) Architektura i standardy zostały wystarczająco zdefiniowane. W SAFe np. tworzy się tylko tyle designu i architektury, by zespoły otrzymywały pomoc i wskazówki dokładnie wtedy, gdy ich potrzebują.

4.) Rozpoznane ograniczenia zostały zidentyfikowane. Ograniczenia dotyczą zazwyczaj takich kwestii jak terminy, ograniczone budżety i dostępne pojemności, ale czasem też ograniczeń fizycznych lub technicznych. W każdym zespole każda osoba musi znać ograniczenia, w których ramach się porusza.

5.) Niezbędna infrastruktura została zapewniona. Infrastruktura to podstawowe struktury, narzędzia i usługi potrzebne do dostarczenia określonej wartości. Jeśli chcesz dostarczać oprogramowanie, niezbędna infrastruktura może być czymś tak prostym jak stanowisko i gniazdko elektryczne – albo czymś tak złożonym jak serwery, routery, sieci i narzędzia deweloperskie.

6.) Zespoły i role zostały skompletowane. Upewnij się, że Scrum Teamy są obsadzone wszystkimi niezbędnymi rolami i odpowiednio zorganizowane (przy założeniu, że nie pracujesz z już istniejącymi zespołami). Ponadto wszystkie dodatkowe role powinny być zidentyfikowane i wyjaśnione. Jeśli nie skupi się odpowiednio na organizowaniu i obsadzaniu zespołów, może to szybko pójść nie tak.

Zacznijcie skalowanie zwinności!

Ready to Go i Ready to Develop mają różne cele, a więc też różne kryteria. Kiedy przy linii startowej pada „…gotowi", przejdź w myślach przez wszystkie kryteria „Ready to Go", by sprawdzić, czy naprawdę jesteście gotowi do rozpoczęcia dużego projektu. Gdy przekroczysz tę przeszkodę, możesz zająć się drugim zestawem kryteriów – „Ready to Develop". Uwzględniając oba te czynniki, będziesz mógł znacznie lepiej ruszyć do sprintu, gdy padnie strzał startowy.

Ten tekst pochodzi z bloga SPaMCAST i został przez nas przetłumaczony.