Ciągłe Odkrywanie w Scrum / Agile
Pisałem już o tym, jak agile / Scrum-owe zespoły produktowe prowadzą Product Discovery i Product Delivery równolegle. Pisałem też o tym, że zespoły w Product Discovery czasem chętnie pracują z timeboxingiem.
W tym artykule chciałbym napisać o rosnącym trendzie w kierunku Continuous Delivery i Continuous Discovery.
Idea Continuous Delivery (pol. ciągłego dostarczania) rozprzestrzenia się coraz bardziej. Wiele zespołów mówiło o tym w ostatnich latach, ale teraz są już zespoły, które naprawdę z tym pracują.
Prawie wszystkie zespoły produktowe pracują dziś z ciągłymi buildami. Zasada polega na tym, że lepiej jest znajdować pojawiające się problemy wcześniej niż późno. Dlatego buildy są zazwyczaj inicjowane od razu po wprowadzeniu zmian.
Niektóre zespoły produktowe wyniosły tę zasadę na zupełnie nowy poziom. Nauczyły się, że problemy z integracją są czasochłonne i że poprzez wczesną i częstą integrację (zamiast jednej fazy przed testowaniem) mogą znacznie poprawić swój całkowity przepływ, minimalizując czas, w którym pracują w izolacji.
Podobnie lepiej jest ciągle uruchamiać automatyczne zestawy testów regresyjnych, aby jak najwcześniej wykrywać nowe problemy (co znacznie zmniejsza liczbę źródeł błędów oraz czas naprawy błędów), zamiast testować wszystko w jednej fazie na końcu cyklu wydania (nawet dwutygodniowego) i odkrywać wszystkie problemy naraz.
Logiczną konsekwencją jest to, że niektóre zespoły teraz regularnie coś wydają (znane jako Continuous Deployment). Oznacza to, że każda logiczna zmiana (lub też grupa zmian) jest dostarczana bezpośrednio w małych „mikro-releasach". Ma to kilka dużych zalet. Pierwsza zaleta polega na tym, że jest to ostateczna strategia przyrostowych releasów, a tym samym główny mechanizm Gentle Deployment – dobre dla naszych klientów i dobre dla nas. Druga zaleta polega na tym, że wyszukiwanie i naprawianie problemów w środowisku produkcyjnym jest znacznie łatwiejsze, gdy zmienia się tylko jedną lub kilka rzeczy na raz.
Jednak wszystko, co do tej pory opisałem, dotyczy Product Delivery. Ale co z Product Discovery?
Od dłuższego czasu opowiadam się za tą samą zasadą, jeśli chodzi o znajdowanie elementów Product Backlogu. Zamiast kilkutygodniowej „fazy Product Discovery", w której tworzy się elementy Product Backlogu, waliduje je, a następnie przekazuje do development, chciałbym zachęcić zespoły do ciągłej Product Discovery, w której stale identyfikujemy, walidujemy i opisujemy nowe elementy Product Backlogu. Niektóre prace discovery zajmują tylko kilka godzin, inne dłużej, ale jest to stały proces znajdowania pomysłów, walidacji i opisu.
W Dual-Track Scrum w ścieżce Discovery są ciągle generowane elementy Product Backlogu, a w ścieżce Delivery te elementy są ciągle budowane, testowane i deployowane.
Mając na uwadze trend Continuous Discovery i Continuous Delivery, wiele zespołów uważa proces Scrum za nieco ograniczający i uznaje model Kanban za bardziej odpowiedni w tym przypadku.
Choć nie wszystkie zespoły niekoniecznie przeszły na Kanban, widziałem wiele takich, które dostosowały Scrum w tym kierunku właśnie z tego powodu. Najczęstszą adaptacją jest bezpośrednie wydawanie funkcji i innych zmian, gdy są gotowe – zamiast wydawania po każdym na przykład dwutygodniowym Sprincie – często są to liczne mikro-releasy w tygodniu. W tym przypadku zespoły używają timeboxingu w Scrum jako możliwości strukturyzowania pracy i promowania regularnych retrospektyw.
Zasadniczo przejście na Continuous Discovery i Continuous Delivery jest naprawdę dobrą rzeczą i wiele najlepszych zespołów, które dotychczas poznałem, z tym pracuje; nawet jeśli tutaj, jak wszędzie, mogą być konieczne kompromisy.
Ten tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony na język polski.
