Na łamach Agile Hunters przedstawiłyśmy Wam już “trzy najważniejsze artefakty Scruma” oraz szczegółowo omówiłyśmy dwa z nich: Backlog Produktu i Backlog Sprintu, teraz nadszedł czas na ostatni z artefaktów. Bohaterem dzisiejszego wpisu jest Przyrost. Mówiąc bardzo prosto, to nic innego jak kolejna, prawdopodobnie lepsza, wersja naszego produktu.
Czym jest Przyrost?
W Scrum Guide znajdujemy taką definicję:
Przyrost jest sumą wszystkich elementów Backlogu Produktu zakończonych podczas Sprintu i wartości Przyrostów ze wszystkich Sprintów poprzednich.
Scrum Guide, 2017
Nic dodać, nic ująć – kolejna, rozszerzona lub/i ulepszona wersja naszego produktu. Bardzo ważne jest to, że Przyrost powinien być na koniec Sprintu potencjalnie gotowy do wydania. “Potencjalnie” znaczy tyle, że Właściciel Produktu może zadecydować o jego wydaniu, ale wcale takiej decyzji podejmować nie musi. Ważna jest komplementarność kolejnych wersji naszego produktu (tak aby wspólnie tworzyły one całość) oraz wspomniana możliwość wydania. Publikacja kolejnych Przyrostów jest niezbędna w procesie ciągłego usprawniania produktu. To dzięki kolejnym wydaniu dokonujemy inspekcji i adaptacji, zbieramy informacje zwrotne od użytkowników i dajemy im ostatecznie to, czego potrzebują. Niekoniecznie musi się to zgadzać z tym co zakładaliśmy podczas naszej pierwszej wizji produktu. Ale to nic złego, bo przecież budujemy go stopniowo, a nie zakładamy dokładnego planu np. na rok do przodu. Zebrany feedback pozwala nam spełniać oczekiwania i budować produkty, z których ludzie chcą korzystać. To dzięki niemu powstają takie produkty, na które jest popyt. Dlatego tak ważna jest praca w stosunkowo krótkich okresach czasu, czyli w Sprintach.
Jak często wydawać Przyrost?
Tak jak juz wspomnialam, to Właściciel Produktu decyduje, czy na koniec Sprintu, chce wypuścić, opublikowąc kolejna wersje swojego produktu. Przy podejmowaniu takiej decyzji może wziąć pod uwagę sytuację na rynku, informacje od interesariuszy. Sugestie Zespołu Deweloperskiego i Scrum Mastera, czy gotowość działu marketingu, itd. Jednak to na nim ciąży odpowiedzialność za podjęcie ostatecznej decyzji o wydaniu. Teoretycznie więc można by się pokusić o stwierdzenie, że skoro Przyrost jest faktycznie gotowy do wydania to, żeby skrócić pętle informacji zwrotnej tzw. release powinien dziać się zawsze na koniec każdego Sprintu. Ze zdaniem tym oczywiscie sie zgadzam i uważam, że taka publikacja obnaża wiele miejsc do usprawnień i może wspomagać proces tworzenia nowych funkcjonalności. Ale jest jedno ale! Zacytuję tutaj dwa fragmenty Przewodnika:
Każdego dnia Sprintu samoorganizujący się Zespół Deweloperski powinien wiedzieć jak będzie przebiegała dalsza współpraca by możliwe było osiągnięcie Celu Sprintu i stworzenie przed końcem Sprintu oczekiwanego Przyrostu.
Scrum Guide, 2017
Zespół Deweloperski złożony jest z profesjonalistów, których zadaniem jest dostarczenie, na zakończenie każdego Sprintu, „Ukończonego” i gotowego do potencjalnego wydania Przyrostu (ang. Increment) produktu.
Scrum Guide, 2017
W powyższym fragmentach Przewodnika jest mowa o stworzeniu oczekiwanego Przyrostu, nie ma jednak zdefiniowanego terminu wydania. To bowiem Właściciel Produktu decyduje o tym kiedy go wydawać.
Sprawdźmy to na przykładzie
Posłużę się tutaj rozważaniami na temat fikcyjnego produktu, który budujesz, żeby lepiej wytłumaczyć co mam na myśli. Czy po odkryciu jakiegoś potencjalnego błędu w swoim produkcie w połowie Iteracji i przy Sprintach trwających trzy tygodnie, będziesz czekał do końca Sprintu, aby naprawić palący błąd? Pewnie odpowiesz: to zależy. I z tym się absolutnie zgadzam. Przejdźmy więc dalej. Czy po wstępnej inwestygacji przez Zespół Deweloperski i oszacowaniu przez nich naprawy wspomnianego błędu jako coś dość prostego nie będziesz chciał jako PO negocjować zakresu Sprintu? Pewnie wszystko zależy od rangi problemu, terminów jakie Was gonią etc. Ale moja rekomendacja – wydawaj tak często jak to możliwe. Tak żeby jak najszybciej otrzymywać informację zwrotną z rynku i budować produkt, z którego Klienci chcą korzystać. Nie czekaj na koniec Sprintu, jeśli masz gotową, ukończona funkcjonalność na którą czekają Twoi Użytkownicy. Zadecyduj o wydaniu produkt w trakcie trwania Sprintu. Dzięki temu może się okazać, że wyprzedzisz konkurencję, która przecież nigdy nie śpi.
Ukończone elementy Sprint Backlogu, czyli jakie?
Kilkakrotnie użyłam stwierdzenia, że coś musi być ukończone, żeby mogło zostać wydane. Celowo jednak nie wchodziłam wcześniej w zakamarki tej definicji, by poświęcić jej osobny podrozdział. Definicja Ukończenia, czyli potocznie DoD (Definition of Done) pozwala nam określić kiedy praca nad PBI jest zakończona. Określa ona pewne standardy, przyjęte i przestrzegane przez Zespół Scrumowy, które produkt musi spełniać. Oczywiście jeżeli pracujemy w Organizacji, która ma ogólnie przyjęte standardy, to zespół rozpoczynajacy prace nad budowa produktu, kieruje się tymi wytycznymi. Dodając do nich elementy, których im brakuje.
Kiedy definicja „Ukończenia” Przyrostu jest elementem konwencji, standardów lub wytycznych stosowanych przez organizację wytwarzającą oprogramowanie, wszystkie Zespoły Scrumowe muszą traktować ją jako niezbędne minimum i się jej podporządkować.
Scrum Guide, 2017
Jeżeli DoD w Organizacji nie istnieje to Development Team je wyznacza dla budowanego produktu. Powinno to mieć miejsce we współpracy z PO i SM jako facylitatorem i ekspertem mogącym podzielić się doświadczeniami z innych Scrum Teamów. Co ważne definicja ukończenia to wiecznie żywy artefakt transparentności. Czyli filaru Scruma, który odpowiednio przestrzegany jest, tuż obok Inspekcji i Adaptacji, niezbędny do utrzymania pracy nad produktem w empirycznym środowisku. Raz ustalona definicja ukończenia może i powinna się zmieniać. Na początku pracy nad produktem mozemy ustalic 2-3 reguły, których będziemy przestrzegać i później dodawać do listy kolejne elementy. Świetnym miejscem do dokonywania inspekcji naszego DoD jest Retrospektywa. Polecam nie zapominać też o refleksji na temat budowanego Przyrostu, wyglądu i struktury Backlogu Produktu. Warto zastanowić się od czasu do czasu nad sposobem dobierania elementów do Backlogu Sprintu i ustalania Celu Sprintu. Pamiętajcie, że Scrum opiera się na empiryzmie, dlatego eksperymentujcie i wyciągajcie wnioski.
Podsumowanie
Przyrost budowany w Scrum powinien być stale poddawany inspekcji i adaptacji, tak żeby jak najlepiej odpowiadać na zapotrzebowanie użytkowników końcowych. Ramy postępowania opisane w Przewodniku są w taki sposób, żeby było to możliwe jak najczęściej. Powiększanie naszego produktu powinno dziać się przyrostowo, fragment po fragmencie, Sprint po Sprincie. Nie wahajmy się wydawać częściej niż raz na iterację. Dokonujmy ciągłego adaptowania naszego produktu, tak żeby dostarczać użytkownikom to czego potrzebują. Pamiętajmy również, żeby dokonywać inspekcji naszej Definicji Ukończenia i również i ją poddawać ciągłemu procesowi pielęgnacji.
Sprawdź nasze ostatnie wpisy:
