Ten artykuł stanowi kontynuację omówienia ankiety na temat Scruma, rozpoczętego w poprzednim tekście – jeśli ktoś jeszcze się z nim nie zapoznał, zachęcam do przeczytania go najpierw, choć nie jest to niezbędne do zrozumienia tego, o czym piszę poniżej.
Można też spróbować swych w ankiecie, która będzie dostępna bezterminowo i stanowi kopię oryginalnego testu. Oczywiście logicznym będzie zrobienie tego przed kontynuacją lektury.
A teraz pora zająć się zestawem trzech kolejnych pytań.
Pytanie 4
W sytuacji, gdy Zespół Scrum nie potrafi uzgodnić wspólnej Definicji Ukończenia, decyzja o jej zawartości należy do Developerów, Product Ownera, Scrum Mastera, kierownictwa organizacji czy interesariuszy?
Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:
- Developerów – 32.5%
- Product Ownera – 30.3%
- Scrum Mastera – 1.7%
- Kierownictwa organizacji – 28.6%
- Interesariuszy – 6.9%
Poprawna odpowiedź: decyzja należy do Developerów.
Potencjalne pułapki i nieporozumienia
Warunkiem uzyskania wartości dla interesariuszy jest wytworzenie w pełni ukończonego produktu, czyli Przyrostu. Za wartość odpowiada Product Owner, który do tego, jak sama nazwa odpowiedzialności wskazuje, jest właścicielem tego produktu. Naturalnym wydawać się może, że właściciel ma prawo decydować o pożądanym poziomie jakości, a skoro ten wyznaczany jest właśnie Definicją Ukończenia, Product Owner ma ostateczne zdanie co do jej zawartości.
Omówienie pytania i prawidłowej odpowiedzi
Definicja Ukończenia jest wspólna dla całego Zespołu, natomiast nad spełnieniem wymogów jakościowych opisanych nią pracują Developerzy. I tylko oni mają realne możliwości oceny, jaki poziom jakości są w stanie osiągnąć.
Zawarcie w Definicji wymogów, których Developerzy nie będą w stanie spełnić, nie spowoduje nagłego podniesienia ich kompetencji. W najlepszym razie przez długi czas nie uda się wytworzyć żadnego Przyrostu. Bardziej prawdopodobne jest jednak, że produkt, który nie został w pełni ukończony, będzie mimo to używany, a wtedy Definicja Ukończenia, której nikt nie będzie się trzymał, zamiast zapewniać przejrzystość, wprowadzać będzie wszystkich w błąd, dodatkowo przejrzystość tę redukując (bo ktoś może łudzić się, że skoro jest spisana, to obowiązuje).
Z drugiej strony zakaz dodania czegoś do Definicji, gdy domagają się tego Developerzy, jest pozbawiony sensu. Definicja określa minimum wymaganej jakości i zawsze można go przekroczyć. Inaczej mówiąc, Developerzy w takiej sytuacji i tak będą robić to, co uznają za niezbędne, mimo usunięcia niektórych zapisów z Definicji. W ten sposób, zamiast przejrzystości odnośnie do tego, jaka jest jakość Przyrostu, pojawi się rozziew między stanem deklarowanym a faktycznym.
Jeśli Zespół nie potrafi dojść do porozumienia, pozostawienie decyzji odnośnie do Definicji Ukończenia Developerom zapewni przejrzystość tego, jak zamierzają oni produkt budować. Jawny rozdźwięk między tym, czego oczekują interesariusze, organizacja lub Product Owner, a co zawiera Definicja, nie pozwoli przejść nad tym brakiem porozumienia do porządku dziennego ani zagrzebać go pod dywanem. Ułatwi też poszukiwanie wyjścia z patowej sytuacji.
Pytanie 5
Kto decyduje o użyciu nowej wersji produktu (jego wydaniu)?
Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:
- Product Owner – 55.5%
- Interesariusze – 12.2%
- Cały Zespół Scrum – 30.6%
- Developerzy – 1.3%
- Scrum Master – 0.4%
Poprawna odpowiedź: decyduje cały Zespół Scrum.
Potencjalne pułapki i nieporozumienia
Product Owner jest tym, do kogo należy produkt w Scrumie. Skoro od niego zależy, jaki produkt powstaje, wydaje się zrozumiałe, że musi mieć pełną swobodę decyzyjną, czy i kiedy zostanie użyty, o ile tylko spełnione są warunki zawarte w Definicji Ukończenia.
Omówienie pytania i prawidłowej odpowiedzi
Historycznie istniał w definicji Scruma zapis, że Product Owner decyduje o użyciu Przyrostu. Został usunięty i nie zastąpiono go żadną inną regułą lub choćby rekomendacją. Nie bez przyczyny.
Jest oczywiste, że Developerzy dostarczają informację, czy w ogóle powstał Przyrost – nowa wersja nadająca się do użycia. Jeśli nie, żadne dywagacje na temat udostępnienia czegokolwiek interesariuszom (np. użytkownikom) nie mają sensu.
Jeśli istnieje Przyrost, decyzja o jego użyciu wydaje się zależeć wyłącznie od oceny jego wartości, czyli np. listy funkcji produktu i cech, jakie posiada. Wszystko, co zostało do tej pory zrealizowane, powinno nadawać się do użycia – o ile Definicja Ukończenia nie jest mocno wybrakowana i nie pozwala glejtować znakiem jakości niedoróbek lub bubli.
Często jest jednak tak, że użycie wczesnej wersji produktu, choćby miała ona najwyższą jakość, rodzi różne ryzyka i korzystać można z niej wyłącznie w ograniczony sposób. Product Owner może nie zdołać samodzielnie dokonać oceny potencjalnych skutków użycia najnowszego Przyrostu w takim przypadku, zwłaszcza jeśli wymaga to zrozumienia np. konsekwencji jakiegoś działania użytkownika, które doprowadzi do trwałego uszkodzenia cennej infrastruktury.
Ktoś powie, że taki produkt nie jest w pełni ukończony i nie powinien być traktowany jako Przyrost. To nie takie proste. W Scrumie produkty buduje się iteracyjnie i przyrostowo, więc to normalne, że często Przyrosty, choć mają wymaganą jakość, nadają się do użycia jedynie potencjalnie.
Co istotne, Scrum Master też ma prawo domagać się rezygnacji z użycia produktu, jeśliby miało to doprowadzić w jakiś sposób do spadku przejrzystości, spowodować utratę empirycznej kontroli nad procesem albo po prostu zaszkodzić interesariuszom.
Żaden rozsądny Product Owner nie zgodzi się na użycie Przyrostu, jeśli Developerzy lub Scrum Master zgłaszają obiekcje – w szczególności dlatego, że jeśli to zrobi, w przyszłości żadnych zastrzeżeń może nie usłyszeć, choć uniknąłby dzięki temu produktowej katastrofy.
Gdy o użyciu produktu decyduje cały Zespół, wszyscy czują na sobie odpowiedzialność za jej podjęcie i skutki, które potencjalnie może spowodować. Sprzyja to powstaniu partnerskiej relacji między Developerami, Scrum Masterem i Product Ownerem, którzy robią coś wspólnie dla interesariuszy. Takie poczucie wspólnoty może się nie wytworzyć, jeśli np. Developerzy będą mieli wrażenie, że budują produkt dla Product Ownera, który może z nim zrobić, co chce, gdy tylko development się zakończy.
A jeśli Przyrost zostanie użyty wbrew opinii całego Zespołu (np. na skutek presji kierownictwa lub kluczowych interesariuszy), z potencjalnymi negatywnymi skutkami radzić będą musieli radzić sobie nie ci, którzy podjęli fatalną decyzję. Jest to rewelacyjny sposób na popsucie relacji między Zespołem a jego otoczeniem (a może i w samym Zespole), a także na pozbawienie ludzi poczucia wpływu, a przez to i zaangażowania. Nie warto tego robić.
Pytanie 6
Kiedy nowa wersja produktu może zostać wydana, czyli udostępniona użytkownikom?
Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:
- Za każdym razem, gdy powstanie Przyrost – 56.7%
- Po zakończeniu developmentu w Sprincie – 1.3%
- Po Przeglądzie Sprintu – 6.1%
- Po zakończeniu Sprintu – 3.9%
- W dowolnym momencie – 32.0%
Poprawna odpowiedź: można to zrobić za każdym razem, gdy powstanie Przyrost.
Potencjalne pułapki i nieporozumienia
Jedynym zdarzeniem w Scrumie, w którym uczestniczą interesariusze, jest Przegląd Sprintu. Do tego Developerzy mogą pracować nad zmianami w produkcie do ostatniej chwili przed rozpoczęciem Przeglądu, nie ma też wymogu wytworzenia więcej niż jednego Przyrostu w Sprincie. Stąd częsty wniosek, że produkt udostępnia się zawsze po Przeglądzie Sprintu, a technicznie już po zakończeniu iteracji, czyli w kolejnym Sprincie.
Omówienie pytania i prawidłowej odpowiedzi
W Scrumie użycie produktu nie wiąże się z żadną cezurą czasową, ale z powstaniem Przyrostu, który spełnia wymogi jakościowe opisane Definicją Ukończenia. Jeśli istnieje taki Przyrost, o ile brak przeciwwskazań do udostępnienia go użytkownikom, można to zrobić bezzwłocznie.
Czy „zakończenie developmentu w Sprincie”, „zakończenie Sprintu” lub „dowolny moment” nie są synonimem tego, co napisałem powyżej? Nie, ponieważ development może zakończyć się bez wytworzenia Przyrostu, Sprint może dobiec końca w trakcie, gdy development wciąż trwa, a „dowolny moment” oznaczałby całkowity brak ograniczeń, czyli również wymogu zakończenia prac nad produktem i spełnienia wymogów zapisanych w Definicji Ukończenia.
Z kronikarskiego obowiązku dodam, że nie ma żadnego powodu, by z użyciem Przyrostu czekać do Przeglądu Sprintu lub zakończenia Sprintu. Takie oczekiwanie może wynikać z zasad organizacji pracy Zespołu lub ustaleń z interesariuszami, ale w Scrumie użyty może być każdy Przyrost, a te mogą powstawać nawet co minutę (wszystko w rękach Developerów).
Uwaga na boku, związana głównie z obszarem rozwoju oprogramowania: w tej domenie termin wydanie produktu może być synonimem przekazania produktu do użycia, ale nie musi. Wszystko zależy od tego, jak oba te terminy definiuje konkretna organizacja.
Zdarza się więc, że wydanie oznacza automatycznie udostępnienie użytkownikom nowej wersji produktu. Bywa, że wydawanie polega na umieszczeniu lub instalacji produktu w określonym miejscu (np. na serwerze), do którego użytkownicy mogą sięgnąć, o ile ktoś im na to pozwoli (niekoniecznie od razu po wydaniu). A czasami w oprogramowanie wbudowane są mechanizmy konfiguracyjne, które pozwalają włączyć lub wyłączyć jakąś funkcjonalność, a wtedy użytkownicy mogą korzystać z wydanej wersji produktu, niekoniecznie mając dostęp do wszystkich jej możliwości.
Jeśli wydanie nie jest tożsame z rozpoczęciem użycia nowej wersji produktu, może dojść do wydania rozwiązań, które nie są ukończone i nie stanowią Przyrostu. Tak rozumiane wydanie stanowi wtedy jeden z etapów procesu developerskiego, który wciąż trwa i wymaga kontynuacji. Nie jest to rozsądna strategia, ale póki w ręce użytkowników nie trafia niedziałający produkt i nikt nie traktuje tej nieukończonej wersji jako Przyrost, można tak zrobić (szczerze odradzam).
Zdarza się też, że udostępnienie użytkownikom nowej wersji oprogramowania jest jednym z kryteriów jakościowych zawartych w Definicji Ukończenia. Zwracam uwagę, że chodzi nie tyle o wydanie produktu w jakiejś formie, ile o faktyczne rozpoczęcie jego użytkowania. Czy oznacza to, że w takim przypadku zapada decyzja o użyciu produktu nim jeszcze powstanie Przyrost?
Formalnie być może tak, ale zawsze of formalizmów ważniejszy jest stan faktyczny – Przyrost powstanie w trakcie procesu przekazania produktu użytkownikom, więc nie dojdzie do sytuacji, w której korzystają oni z czegoś, co Przyrostem nie jest.
Czy możliwe jest, że Definicja Ukończenia pójdzie jeszcze dalej i wymagać będzie, by Zespół nie tylko udostępnił produkt użytkownikom, ale też zebrał dane potwierdzające, że produkt ten działa i jest wykorzystywany? I że dopiero po potwierdzeniu wartości w sposób empiryczny można uznać, iż powstał Przyrost?
Zetknąłem się z takimi Definicjami, ale przyznaję, że uważam je za wyjście poza Scrum (co nie musi być złe, sama idea mi się podoba). Definicja Ukończenia jest kryterium jakości strukturalnej, czyli wyjaśnia, jaki produkt nadaje się do użycia. Nie wyjaśnia natomiast, jaki produkt jest wartościowy. Stąd moje wątpliwości, tym bardziej że logika podpowiada nieubłaganie, iż nawet bezwartościowy produkt może nadawać się do użycia, jeśli jest dobrze zrobiony, tyle tylko, że nikt nie będzie chciał z niego korzystać.
Ciąg dalszy
Kolejne pytania z ankiety omówione zostały w następnym artykule.