„Kiedy ma to sens?” W przypadku dzisiejszego wpisu nie jest to jednak pytanie, ale stwierdzenie. Na przykładach niezwiązanych z IT postaram się zaprezentować siłę zwinnego podejścia i jego działanie w praktyce. Za pomysł na post wielkie podziękowania należą się uczestnikom jednego z naszych ostatnich warsztatów!
Kiedy ma to sens
Product Owner podejmuje decyzję o produkcyjnym udostępnieniu budowanego Przyrostu wtedy, kiedy ma to sens. Owe „udostępnienie produkcyjne” to nic innego, jak wdrożenie i umożliwienie użytkownikom korzystania z naszego produktu. Proste? Pewnie, że tak. Wszystko spoczywa w jednych rękach, nie ma więc problemu z odpowiedzialnością za tę czynność czy wypracowywaniem zbiorowego konsensusu.
Skoro sama idea jest prosta, to haczyk musi być gdzieś indziej. Jest nim odpowiedź na pytanie, kiedy dokładnie podejmować tę decyzję? „Kiedy ma to sens” brzmi bardzo enigmatycznie. Nie mówiąc już o tym, że początkującym adeptom zwinnego podejścia ta informacja zupełnie nic nie mówi. Jako wzorowi Scrum Masterzy nie możemy dopuścić do utrzymania takiego stanu rzeczy.
Co ma wpływ na wdrożenie?
To Product Owner decyduje o udostępnieniu/wdrożeniu/wydaniu. I nie musi on udostępniać przyrostu po każdym zakończonym Sprincie, ani nawet czekać na jego koniec. Może to robić raz na kilka iteracji (patrz np. Release Planning), a może zrobić to kilka razy w jednej.
Nie powinniśmy utożsamiać iteracji z wydaniem.
Wiele czynników wpływa na to, że PO podejmuje (bądź nie) decyzję o udostępnieniu funkcjonalności użytkownikom końcowym. Należą do nich zarówno aspekty biznesowe, jak również te czysto techniczne. Do tych pierwszych zaliczyć można maksymalizowanie dostarczanej klientowi wartości, do tych drugich natomiast ryzyko związane z wdrożeniem (np. w przypadku systemów centralnych, z którymi integruje się pół wszechświata). Na dzień dzisiejszy zostawmy z boku aspekty techniczne i zajmijmy się biznesowymi.
Maksymalizowanie dostarczanej wartości jest podstawowym zadaniem Product Ownera. Łatwo mówi się o budowaniu maksymalizacji w kontekście oprogramowania. Nie tylko nie jest to rzecz fizyczna, ale jesteśmy też w stanie plastycznie dopasowywać je do oczekiwań użytkownika, bez konieczności wyrzucania tego, co już zrobiliśmy.
Naprawdę trudno (i ciekawie!) robi się, kiedy rozmawiamy o rzeczach fizycznych. Podejmuję jednak tę rękawicę!
AED, czyli defibrylator
AED (ang. automated external defibrillator) to urządzenie ratujące życie. Jest niepozornym pudełkiem, które w krytycznej sytuacji ma skłonić serce poszkodowanego do normalnej pracy. Wyobraźmy sobie, że pracujemy w firmie zajmującej się produkcją tego właśnie sprzętu, a produkując go, korzystamy z dobrodziejstw zwinnych metodyk. Jak będzie wyglądała nasza praca?
Myli się ten, kto zgodnie z ideą przyrostowego dostarczania produktu pomyśli o oddawaniu AED kawałek po kawałku. Nikt tym nikomu życia nie uratuje, a może tylko wprowadzić niepotrzebne zamieszanie.
To właśnie przykład sytuacji, w której Product Owner nie udostępni poszczególnych przyrostów użytkownikowi końcowemu, a będzie czekał na maksymalizację jego wartości. Tutaj nasze MVP będzie dość spore.
W jaki więc sposób wpleść zwinne metodyki w budowę defibrylatora?
Zacznijmy od identyfikacji właściwych interesariuszy, czyli tych, którzy posiadają skin-in-the-game. Współpracujmy z nimi w codziennej pracy poszukując satysfakcjonujących ich rozwiązań. Jak najbardziej prezentujmy im kawałki ukończonego Przyrostu, za każdym razem prosząc ich o konstruktywny feedback w zakresie już wypracowanego rozwiązania. Ale nie oszukujmy nikogo, że te rozwiązanie nadaje się na rynek.
Tylko kiedy udostępnimy sprzęt użytkownikom?
Bierzcie i używajcie!
Wdrożenie (zwane też wydaniem) powinniśmy robić jak najczęściej. W każdym przypadku udostępnimy produkt wtedy, kiedy będzie miało to sens. Dla AED – po jego zbudowaniu. Czy zaprzeczamy w ten sposób idei zwinnego podejścia? Oczywiście, że nie.
Spłycenie zwinnego podejścia do udostępniania przyrostu po każdej zakończonej iteracji jest mitem. 12 zasad Zwinnego Tworzenia oprogramowania mówi:
„Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej” – Agile Manifesto
Dostarczamy (ang. deliver), zbieramy informację zwrotną i ulepszamy go, aby zmaksymalizować zadowolenie klienta. Robimy więc wszystko zgodnie z założeniami zwinności. Nie ma tutaj jednak mowy o finalnym udostępnieniu produktu dla odbiorcy końcowego.
Zrobimy to, kiedy dostarczenie produktu będzie miało sens i kiedy jego udostępnienie wywoła uśmiech na twarzy naszych interesariuszy. Szukając tego uśmiechu koniecznie pamiętajmy o idei MVP. Im dłużej zwlekamy, tym większe oczekiwania.
Podsumowując, zadaniem Product Ownera jest dbać o zadowolenie klienta i dostarczenie mu tego, czego potrzebuje. I taką rolę może pełnić zgodnie z założeniami zwinnej metodyki bez względu na to, czy pracujemy z oprogramowaniem czy z produktami fizycznymi
