SCRUM

56 WZORCÓW W STRUMIENIU WARTOŚCi

Bezpłatny fragment

Język wzorców w strumieniu wartości

Sekwencja strumienia wartości

¶1 Wizja

¶2 Lista przeszkód

¶3 Strumień wartości

¶4 Projektowanie oparte na zestawach

¶5 Wykres spalania sprintu

¶6 Tablica scrumowa

¶7 Mapa drogowa produktu

Rytmy: wzorce czasu

¶8 Sprint

¶9 Organizacyjny puls sprintu

¶10 Plan wydań

¶11 Zakres wydań

Wartość i ROI

¶12 Rejestr według ROI

¶13 Po pierwsze wartość

¶14 Bezkosztowa zmiana

¶15 Pieniądze za nic

Sekwencja rejestru produktu

¶16 Rejestr produktu

¶17 Element rejestru produktu

¶18 Grzejnik informacji

¶19 Prosięce kalkulacje

¶20 Niewielkie elementy

¶21 Gradient ziarnistości

¶22 Punkty estymacji

¶23 PBI o stałym terminie

¶24 Wakacyjny PBI

¶25 Specyfikacja ramowa

¶26 Udoskonalony rejestr produktu

¶27 Definicja gotowości

Uwagi na temat prędkości

¶28 Wczorajsza pogoda

¶29 Bieżąca średnia prędkość

¶30 Łączna prędkość

¶31 Specjalistyczne prędkości

¶32 Zaktualizowana prędkość

¶33 Cel sprintu

¶34 Rejestr sprintu

¶35 Element rejestru sprintu

¶36 Zespoły, które wcześniej kończą pracę, szybciej przyspieszają

¶37 Etap produkcyjny

¶38 Deweloperski plan pracy

¶39 Podążaj za Księżycem

¶40 Widoczny status

¶41 Najpierw zależności

¶42 Dobre gospodarowanie

¶43 Polowanie na krety

¶44 Definicja ukończenia

¶45 Sprint zespołowy

¶46 Wdrażanie reaktywne

¶47 Regularny przyrost produktu

¶48 Warstwy przygotowania wersji

¶49 Wymierne ulepszenia

¶50 Krok po kroku

¶51 Obszary wartości

¶52 Odnogi strumienia wartości

¶53 Miara Szczęścia

¶54 Scrumowanie Scruma

¶55 Największa wartość

¶56 Pożegnanie z produktem

Przypisy

JĘZYK WZORCÓW W STRUMIENIU WARTOŚCI

Podczas gdy język wzorców w organizacji produktowej (patrz s. 11) buduje relacje między ludźmi i zespołami w organizacji scrumowej, język wzorców w strumieniu wartości tworzy relacje między etapami tworzenia produktu a artefaktami reprezentującymi części procesu. Zespół scrumowy buduje strumień wartości, aby ustalić rytm i działania związane z rozwojem. Wartość płynie zasadniczo od ¶1 Wizji, przez ¶16 Rejestr produktu, a stamtąd do ¶34 Rejestru sprintu i ostatecznie do ¶47 Regularnego przyrostu produktu. Istnieje wiele innych wzorców, które udoskonalają te większe komponenty strumienia wartości w trakcie trwania procesu.

Poniższy graf przedstawia wykres języka wzorców w strumieniu wartości i pokazuje zależności między wzorcami języka.

Sekwencja strumienia wartości

Scrum dotyczy zarówno tworzenia procesu, jak i budowania produktu. Metoda lean promuje pewne porzekadło: „Stwórz właściwy proces, a zbudujesz właściwy produkt”. Najbardziej fundamentalnym procesem jest „inspekcja i adaptacja”, które to organizacje mogą wykorzystać do kierowania zarówno produktem, jak i procesem. Używamy metafory koryta rzeki jako ścieżki, wzdłuż której produkt płynie od ¶1 Wizji aż do użytkowników końcowych. Myślimy o wizji, ¶16 Rejestrze produktu i ¶34 Rejestrze sprintu jak o korycie tego strumienia – są to artefakty Scruma. Są to jednak również granice czasu, które odzwierciedlają przepływ rozwoju od koncepcji do realizacji.

Strumień wartości jest tylko sekwencją działań, które wytwarzają wartość. Przedsiębiorstwo może zaprojektować strumień wartości, aby zbudować produkt, zaoferować usługę lub w inny sposób stworzyć wartość. Podstawowy strumień wartości Scruma koncentruje się na zapewnieniu ¶47 Regularnego przyrostu produktu dla użytkowników końcowych. Działania, które wytwarzają wartość dla użytkowników końcowych, tworzą ją również dla interesariuszy, dla zespołu deweloperskiego (np. duma z budowania czegoś wspaniałego, większa szansa na rozwój zawodowy) i innych. Każde z nich można uznać za strumień wartości, nawet jeśli wszystkie mogą pochodzić z tego samego większego wysiłku w zakresie rozwoju produktu.

Jest to jedna sekwencja (docelowo archetypiczna), która podkreśla główne wzorce wzdłuż głównych punktów procesu tworzenia i udoskonalania strumienia wartości. Pominęliśmy kilka mniejszych wzorców, aby pomóc zachować perspektywę pełnego obrazu. Przypominamy, że sekwencja jest archetypowa – być może w niektórych przypadkach trzeba będzie użyć wzorców w innej kolejności niż tu opisana.

Mgła Wspaniałe dzieła zaczynają się od nieokreślonej tęsknoty społeczności i od prób rozwiązania dużych problemów lokalnie lub indywidualnie, a dążąc do wielkich czynów, społeczność ta zadowala się raczej małymi, lokalnymi korzyściami.

¶1 Wizja Te tęsknoty formują wizję przyszłego pożądanej przyszłości – wielkiej rzeczy, którą stworzy zespół scrumowy. Każdy, kto będzie brał udział w procesie, musi dzielić tę wizję. Jedna osoba, właściciel produktu, wciela w życie wizję, biorąc odpowiedzialność za nią i za wartość, która jest wynikiem ukończenia produktu.

¶3 Strumień wartości Organizacja skupia się wokół tych tęsknot, z pasją tworząc coś wielkiego oraz generując wartość, mając przy tym na uwadze nie tylko wizję efektu końcowego, lecz także środków, które pozwolą na osiągnięcie marzeń i przemienią nowo powstały strumień produktów w rosnące w siłę poczucie wspólnoty. Strumień wartości to także wysiłek i podstawowe budulce projektu, jak również fundamenty realizacji produktu, które uzupełniają się wzajemnie i wspierają harmonijny przepływ pracy.

¶7 Mapa drogowa produktu Dla kogoś skorego do zmian i otwartego na nowe pomysły, mapa drogowa to kierunek, który może osiągnąć większe dobro i właśnie zaczyna wyłaniać się z mgły. Istnieje kilka potencjalnych ścieżek budowania czegoś wielkiego i generowania wartości zgodnie z wizją. Wizja staje się zbiorem marzeń, przyrostów produktu, zorganizowanych w celu ułatwienia wczesnych decyzji, które w danym momencie poprowadzą najbardziej znaną ścieżką do Całości.

¶8 Sprint W strumieniu wartości opracowywane są przyrosty produktów ujęte w epizodach rozwoju produktu o stałych przedziałach czasowych, zwanych sprintami. Każdy przyrost stanowi ukończony wkład w rozwój wizji. Stałe odcinki dają również możliwość znaczącej poprawy procesów rozwoju strumienia wartości. Naturalny cykl sprintu może być zgodny ze wzorcem ¶39 Podążaj za Księżycem.

¶16 Rejestr produktu Wnikliwość, doświadczenie i okoliczności naprowadzają na najlepsze decyzje przy najbliższych rozwidleniach planu rozwoju. Na podstawie aktualnie najlepszych prognoz biznesowych pojawia się konkretna ścieżka, którą należy kroczyć przez mapę drogową, która w każdym kroku wnosi wartość dodaną. Rejestr produktu uwidacznia wszystkim interesariuszom najbliższą prawdopodobną trajektorię długoterminowej dostawy. Patrz „Sekwencja rejestru produktu” (s. 261).

¶17 Element rejestru produktu Zespół scrumowy dzieli produkt na poszczególne fragmenty zwane elementami rejestru produktu (PBI), na których skupiają się wysiłki związane z budowaniem rezultatów. Deweloperzy akceptują je i rozwijają, aby osiągnąć rezultat zgodny z ¶27 Definicją gotowości, oszacowany przez deweloperów, jak w ¶19 Prosięcych kalkulacjach.

¶33 Cel sprintu Zespół zobowiązuje się do osiągnięcia celu sprintu, który jest „koniecznością” sprintu, rezultatem jego ukończenia. Cel sprintu powoduje skupienie się na pracy zespołowej, co pomaga zespołowi współpracować, zamiast zajmować się wieloma niezależnymi zadaniami.

¶34 Rejestr sprintu Zespół deweloperski planuje, w jaki sposób osiągnie cel sprintu i opracowuje elementy rejestru produktu, które pozwolą im dostarczyć przyrost produktu; tworzy więc plan pracy o nazwie rejestr sprintu.

¶37 Etap produkcyjny Zespół deweloperski pracuje nad osiągnięciem celu sprintu i dostarczeniem przyrostu produktu. Deweloperzy aktualizują rejestr sprintu podczas Codziennego Scruma. Zespół pracuje w dużej mierze nieprzerwanie, Rój: pojedynczy nieustanny przepływ to zespół pracujący nad jednym PBI w danej chwili.

¶46 Wdrażanie reagujące W miarę postępów rozwoju, podczas większych cyklów sprintu pojawiają się małe dostarczenia, które mają na celu zaradzenie sytuacjom awaryjnym i naprawianie błędów lub wygenerowanie wartości w najbardziej oportunistyczny sposób, jak to możliwe, bez czekania na koniec sprintu.

Przegląd sprintu Po zakończeniu sprintu, właściciel produktu i zaproszeni interesariusze oceniają aktualny stan produktu i ustalają, które części można zaliczyć do przyrostu produktu. Praca wykonana podczas ostatniego sprintu musi spełnić ¶44 Definicję ukończenia, zanim zespół scrumowy wdroży przyrost produktu.

Retrospektywa sprintu Zespół ocenia również bieżący stan procesu i poszukuje możliwości rozwoju, wybierając tym samym jedno kluczowe ulepszenie, które zrealizuje w następnym sprincie, i czyniąc go PBI, dzięki czemu Scrum stanie się wehikułem usprawnienia procesu: ¶54 Scrumowanie Scruma.

¶47 Regularny przyrost produktu Zatwierdzone elementy rejestru produktu stanowią spójny przyrost produktu, który właściciel produktu może udostępnić do użytku.

¶48 Warstwy przygotowania wersji Zakres dostarczeń i wykorzystanie przyrostów produktu rozszerza się i kurczy w miarę gdy doświadczenie weryfikuje, który z przyrostów jest rozsądny, a który skazany na klęskę.

¶51 Obszary wartości Strumienie wartości mogą mieć niezależne dopływy, które zespoły będą rozwijać osobno, jednakże rynek wykorzystuje je jako jedną zintegrowaną całość. Przedsiębiorstwo może wewnętrznie dzielić pracę na obszary wartości, z których każdy działa jak niewielka, niezależna jednostka mająca na celu opracowanie części produktu, dla której nie ma alternatywy rynkowej. Wszystkie takie obszary wartości to ucieleśnienie produktu z potencjalnie wieloma strumieniami wartości.

¶52 Odnogi strumienia wartości Efektywne strumienie wartości mogą zwiększać swój rozmiar, lecz problematyczne w takim stanie rzeczy jest to, że wynik może przewyższyć początkowe oczekiwania. Jeśli tak się stanie, pierwotny pojedynczy strumień wartości przekształci się w wiele strumieni, każdy z własnym rejestrem produktu i właścicielem produktu, skupiając uwagę na sobie i opracowaniu nowej wizji dla każdego z osobna.

¶55 Największa wartość Podczas użytkowania produkt zapewnia najwyższą możliwą wartość, a gdy jego rozwój nadal trwa, kierunek produktu zmienia się, aby zapewnić najwyższą wartość.

¶56 Pożegnanie z produktem Cykle życia i natury ostatecznie doprowadzają produkt do końca jego przydatności i należy zakończyć go w sposób, który przywróci jego zasoby do natury i uzna godność wszystkich interesariuszy.

¶1 WIZJA

Ranga wzorca: **

Program lądowania na Księżycu zaczął się od wizji

…po wyjściu z Mgły jakaś kluczowa wizjonerska osoba lub grupa musi urzeczywistnić swoją pasję przez konceptualizację, którą można się dzielić i która zachęci ludzi do wspólnej pracy w celu zbudowania czegoś, co podniesie jakość życia w ich środowisku.

Ludzie rozwijają się w ramach ograniczeń, które ukierunkowują ich kreatywność i pracę na wspólne dobro, ale prawdą jest również to, że zbyt szczegółowe ograniczenia mogą zmienić pracowników w służalcze roboty, które ślepo wykonują polecenia, a nie kierują się sercem.

Osiągnięcie doskonałej wizji wymaga zazwyczaj zgranego zespołu, a także porozumienia między zespołem i interesariuszami. Zespół to grupa osób mających odmienne opinie i uczucia, a chociaż wszyscy mogą mieć dobre intencje, każda z nich może konceptualizować i wyrażać oczekiwany wkład na różne sposoby. Stwarza to wrażenie konfliktu między członkami zespołu. Jednak, jeśli opanuje się wstępne zamieszanie, które wpływa na pierwsze wrażenie członków zespołu, zwykle można wykorzystać ich odczucia i koncepcje, sięgające głęboko we wspólną kulturę interesariuszy.

Ta różnorodność perspektyw w zespole ma wielką wartość, ponieważ zwiększa prawdopodobieństwo, że zespół nie przeoczy żadnego świetnego pomysłu. Analizowanie wielu perspektyw i pozyskiwanie wkładu osób z różnych środowisk i o różnych doświadczeniach pomaga bazować na szerokiej gamie możliwości. Różne doświadczenia i pomysły otwierają dodatkowe innowacyjne perspektywy, które mogą być niezwykle cenne. Nieprzedyskutowane, mogą rozdzielić zespół na kilka frakcji.

Aby zespół był naprawdę skuteczny, wszyscy jego członkowie muszą ciągnąć w tym samym kierunku.

Zespół podąża w kierunku wspólnego celu. Gdy wspólny cel jest zbyt szeroko zdefiniowany lub niejasny, zespół ryzykuje, wkraczając w zbyt wiele mniej znaczących kierunków. Wysiłek włożony w te nietrafione eksperymenty kosztuje wiele energii i hamuje prędkość. Jeśli wspólny cel jest zbyt restrykcyjny, nadmiernie ogranicza zespół i pozostawia wiele cennych ścieżek niezbadanych – jest to po prostu marnowanie intelektu i kreatywności.

Cel staje się wspólny, gdy zespół przejmie go na własność. Zespół bierze odpowiedzialność za cel, tylko gdy go współtworzy: wtedy staje się ich celem.

Przyszłość jest z natury nieznana; jakiekolwiek deklaracje co do wyniku lub dalekosiężnych planów są ryzykowne. Zbyt wiele czynników zewnętrznych należy wziąć pod uwagę. Mimo to zespoły potrzebują wspólnego celu, aby stworzyć spójność i bezpośredni wynik.

A zatem:

Osoba, która ucieleśnia pasję do stworzenia nowego produktu, wciela się w rolę Właściciela produktu, wokół którego gromadzą się interesariusze i potencjalni przyszli współpracownicy, aby wspólnie uformować i udoskonalić wizję. Wizja określa, w jaki sposób produkt zapewnia przyszłość, w kierunku której zmierza ujęta w wizji Organizacja Produktu.

Możemy myśleć o wizji jako o dwóch elementach. Pierwszy – który nazywamy tylko wizją – to szeroki kierunek na przyszłość, podczas gdy wizja produktu dzieli ten szeroki kierunek na bardziej szczegółowe komponenty biznesowe. Wizja zapewnia elastyczny, wyraźny wspólny cel, który nada kierunek nowo powstałej grupie, określanej już jako zespół. Wspiera rozumienie systemowe, czyli to, w jaki sposób przewidywany wysiłek produktowy przyniesie korzyści ich życiu, życiu użytkowników końcowych i innych interesariuszy. Kluczowy aspekt wizji dotyczy samego produktu. Wizja produktu wykracza poza niejasne określenie dawania życia i jest dość konkretna. Wizja produktu leży na pograniczu pasji stojącej za pomysłem, zapotrzebowania na pomysł i możliwości zbudowania czegoś wspaniałego. Zazwyczaj wizja produktu (Agile Product Management With Scrum: Creating Products That Customers Love, wyd. 1 [Pic10], s. 24) obejmuje następujące kwestie:

• kluczowe cechy produktu;

• kto będzie korzystał z produktu;

• potrzeby klientów, które produkt będzie spełniał;

• jakie korzyści uzyska producent.

Właściciel produktu ma wizję i postanawia ją zrealizować, tworząc język wzorców w organizacji produktowej, a także definiując ¶3 Strumień wartości. Właściciel produktu wyznacza ścieżkę do wizji jako ¶7 Mapę drogową produktu i współpracuje z interesariuszami, aby zredukować ją do konkretnego, określonego ¶16 Rejestru produktu. Każda z nich pomaga wyjaśnić wizję organizacji produktu, a zwłaszcza zespołom scrumowym, w różnych formach i stopniach. Wizja daje każdemu większe wyczucie kierunku i wspólnego celu. Organizacja produktowa i zespoły mogą z kolei weryfikować rezultaty pod względem wsparcia dla wizji. Zespoły mogą zatem mierzyć postępy w jej realizacji.

Posiadanie skutecznej wizji może pomóc wytyczyć kierunek, zainspirować i zjednoczyć zespół scrumowy, a także pomóc kształtować zachowanie zespołu bez ograniczania jego kreatywności. Doskonała wizja to taka, dzięki której wstajesz z łóżka i masz energię na cały dzień. Aby zrealizować wizję i dostarczyć serię przyrostu produktów interesariuszom, wizja kieruje tworzeniem i wdrażaniem strumienia wartości.

Wizje wraz z upływem czasu ewoluują, a niektóre inicjatywy związane z produktem szybko pokazują, że pierwotna wizja była mylna. Jej podstawy mogą jednak zostać zrealizowane, prowadząc do osiągnięcia czegoś, co czasami jest jeszcze wspanialszą wizją. Ponieważ jesteśmy zwinni, możemy dostosować nasze postępy do wizji, a nawet z czasem dostosować samą wizję.

Katsuaki Watanabe, ówczesny prezes Toyoty, wierzył w wyznaczanie „niemożliwych celów” jako wizji, które kierowały strategicznym kierunkiem Toyoty:

Wiele celów Toyoty pozostaje niejasnych nie bez powodu, umożliwiając pracownikom kierowanie energii w różnych kierunkach i zmuszając specjalistów z rożnych dziedzin do współpracy poza strefą, w której zazwyczaj pracują. Na przykład Watanabe powiedział, że jego celem jest zbudowanie samochodu, który uczyni powietrze czystszym, będzie zapobiegał wypadkom, sprawi, że podczas jazdy ludzie będą zdrowsi i szczęśliwsi, a jeden bak starczy na wycieczkę od wybrzeża do wybrzeża... (Magazyn „Harvard Business Review 86” [OSTD08]).

Pod koniec lat 70. Bill Gates i Paul Allen mieli wizję „komputera na każdym biurku i w każdym domu”. Wizja stała się rzeczywistością, gdy „nastąpił pewien magiczny przełom, a komputer stał się tani i wszystkich było na niego stać”[1]. Teraz, w XXI wieku, Elon Musk pracuje nad swoją wizją „uczynienia ludzkości gatunkiem wieloplanetowym”[2]. Podjął już udane kroki ku zrealizowaniu swojej wizji przez wytwarzanie rakiet wielokrotnego użytku w celu obniżenia kosztów startów[3].

Wielka wizja dąży do pewnej, być może transcendentnej, ¶56 Najwyższej wartości. Na przykład dziennikarze w Holandii założyli nową firmę produkującą czekoladę, Tony’s Chocolonely, dzięki wizji tworzenia tabliczek czekolady bez udziału niewolniczej pracy[4].

¶2 LISTA PRZESZKÓD

Alias: rejestr przeszkód

Ranga wzorca: *

…Zespół scrumowy próbuje rozwijać produkt.

Członkowie zespołu często napotykają problemy, które hamują ich rozwój. Rozwiązywanie ich od razu może nie być możliwe, praktyczne i/lub leżeć w najlepszym interesie organizacji lub zespołu.

Zarówno czynniki wewnętrzne, jak i zewnętrzne mogą spowolnić pracę Zespołu deweloperskiego. Jego członkowie najpewniej będą chcieli rozwiązać problem natychmiast, ale to odrywa ich od dążenia ku ¶33 Celowi sprintu.

Jednocześnie, jeśli nie zajmiesz się czynnikiem zakłócającym pracę od razu, to może się przerodzić się z niewygodnego problemu w problem chroniczny; coś, do czego się przyzwyczajasz i w pewien sposób ignorujesz.

Przeszkody odrywają zespół deweloperski od pracy. Mogą również negatywnie wpływać na poprawę ich wyników. Przykładowo, problemy natury komunikacyjnej w zespole mogą przeszkadzać w dążeniach do rozwoju, a powolne lub przestarzałe narzędzia z pewnością uniemożliwią zespołowi pracę na maksymalnych obrotach.

A zatem:

Wyszczególnij wszystkie nietrywialne problemy na liście przeszkód; porusz ich kwestię z właściwymi osobami w organizacji, aby je wyeliminować. Scrum Master porządkuje listę pod względem ich wagi i wartości.

Każdy członek zespołu scrumowego może dodać przeszkodę do listy i tym samym ją uwidocznić. Zakłada się przy tym, że zespół scrumowy staje się wspólnotą zaufania, gdyż niektóre przeszkody ciężko będzie poruszyć, szczególnie te personalne, związane ze zdrowiem, sprawami rodzinnymi lub konfliktem w zespole. W kwestiach związanych z przeszkodami członkowie zawsze powinni ufać Scrum Masterowi. Scrum Master może zdecydować się rozwiązywać pewne sprawy dyskretnie, aby nie umniejszać godności niektórych osób.

Członkowie zespołu deweloperskiego sami potrafią rozwiązać większość pozycji widniejących na liście przeszkód, ale z pomocą mogą przyjść również osoby z poza zespołu scrumowego. Scrum Master może własnoręcznie uporać się z problemem, który mógłby mieć negatywny wpływ na resztę zespołu, a nie wymaga specjalnej ekspertyzy. Ewentualnie, aby zespół deweloperski mógł lepiej poradzić sobie z niektórymi przeszkodami, może wraz z Właścicielem produktu dodać potrzebne działania do ¶16 Rejestru produktu.

Podczas Retrospektywy sprintu zespół scrumowy z pewnością doda nowe pozycje do listy. To również dobry moment na jej udoskonalenie.

Lista przeszkód to manifestacja ducha kaizen. Pusta lista przeszkód oznacza, że nie przykładasz się dostatecznie dobrze do wyszukiwania nowych pomysłów na rozwój. Jednocześnie zespół musi zająć się przeszkodami odpowiednio wcześnie, aby nie zatrzymać procesu rozwoju. Pozycje na liście nie mogą stać się nieaktualne.

Przykład z życia: zespół narzekał na menedżera, który nie usuwał przeszkód. Zapytałem, czy ich zdaniem menedżer potrafił je zidentyfikować, odpowiedzieli, że prawdopodobnie tak. Poprosiłem ich o wypisanie na kolorowych karteczkach wszystkich przeszkód, z wytłuszczonym nagłówkiem „Przeszkoda” i zaprowadziłem ich do menedżera. Nie było go, więc oblepiłem jego monitor karteczkami, by przypadkiem ich nie przeoczył. Po pół godziny później zawołał mnie do siebie. Spytał, czy przeszkody zostały wypisane przez zespół. Odpowiedziałem, że tak, a on uśmiechnął się i ucieszył, że w końcu wie, na czym ma się skupić.

¶3 STRUMIEŃ WARTOŚCI

Ranga wzorca: **

…Właściciel produktu zdefiniował ¶1 Wizję i szuka możliwości, by wykreować wartość, która jest postrzegana jako coś cennego dla osób lub grup docelowych danego produktu.

Proces rozwoju i ścieżka przebyta od koncepcji po wejście na rynek jest równie ważna dla sukcesu produktu co sam pomysł produktu. W przypadku prostego rozwoju, tak jak niegdyś w rolnictwie, surowce były zawsze pod ręką, a producent (właściciel winnicy) mógł z łatwością przekazać je konsumentowi (głodnemu podróżnikowi). W miarę rozwoju produkcji, procesy zaangażowane w budowanie produktu również ewoluowały (jak produkcja wina). Zdolności siły roboczej niezbędne przy uprawach nie są już wymagane, a wyparła je potrzeba współpracy w przeprowadzaniu innowacji i pozyskiwaniu zasobów na skomplikowane przedsięwzięcia. Intelektualny charakter tych działań wymaga bardziej otwartego systemu, w którym dane wejściowe i połączenia między sieciami rozwoju tworzą gęstą sieć.

Tworzenie skomplikowanego produktu, takiego jak samochód czy oprogramowanie może wymagać zaangażowania wielu zespołów i głębokiego zrozumienia, jak koordynować pracę. Jednak samo zaangażowanie – dobre procesy i dobrzy specjaliści – nie wystarczą.

A zatem:

Właściciel produktu tworzy ekosystem, którego kolejne elementy opierają się na sobie w celu dostarczenia stale wzrastającej wartości rozwijającego się produktu. W sercu tego ekosystemu znajdują się procesy wytwarzające ciągłe i ewoluujące strumienie przyrostów produktu: strumienie wartości.

Za podstawę strumienia wartości uchodzą artefakty (rejestry, części produktu) oraz procesy, które kierują i koordynują tworzenie artefaktów (dzięki wydarzeniom i współpracy). Osoby zaangażowane w strumień wartości są kluczowe w procesie tworzenia, wcielania w życie i modyfikacji działań służących kreowaniu artefaktów.

Strumień wartości jest dynamiczny, a właściciel produktu może dopasowywać go do zmieniającego się środowiska biznesowego, relacji interesariuszy czy charakteru danego przyrostu produktu. Jednak, z perspektywy organizacyjnej, w część rozwojową strumienia wartości w Scrumie angażujemy tylko jedną organizację: Zespół scrumowy. Zespół scrumowy przeprowadza wszystkie czynności deweloperskie, nie przekazując zadań między zespołami.

Toyocie udaje się tworzyć wiele różnorodnych samochodów o wysokiej jakości dzięki wdrażaniu systemu produkcyjnego Toyoty (TPS) (Toyota Production System Beyond Large-Scale Production [Ohn88]). System ten obejmuje światowej klasy procesy, świetne wyszkolenie pracowników oraz walkę z marnotrawstwem. Procesy nie biorą się z niczego: wiele z nich odzwierciedla strukturę ścieżki przebytej od pozyskania surowców po sprzedaż gotowego produktu. Pojawiają się kluczowe pytania: Kto projektuje linię produkcyjną lub maszyny? Kto decyduje o tym, co jest zawarte w instrukcjach obsługi procesów na każdym etapie? Wszystko to zawiera się w procesie tworzenia strumienia wartości.

Firma Tesco zanalizowała swój strumień wartości (od dostawców po punkty sprzedaży) i odkryła możliwości znaczącej poprawy. Dzięki usprawnieniu strumienia wartości „dostarczane elementy przepływały szybciej”, co z kolei przyczyniło się do „obniżenia kosztów i wzrostu sprzedaży zarówno dla Tesco jak i ich dostawców” (Seeing the Whole Value Stream, wyd. 2 [JWBL13]). „Ich sukces polegający na przeprojektowaniu sieci dostaw artykułów spożywczych, pomógł im w ciągu dekady przekształcić się ze średniej wielkości sprzedawcy detalicznego artykułów spożywczych na rynku brytyjskim do trzeciego największego sprzedawcy detalicznego na świecie” (to samo źródło).

¶16 Rejestr produktu, ¶34 Rejestry sprintu i ¶6 Tablice scrumowe, wraz z wieloma innymi wzorcami, pomagają w tworzeniu całości, przez którą przepływa nakład pracy kierujący się ku dostarczeniu. Strumień wartości jest w pewnym sensie organizacyjnymi strukturami i procesami, które zapewniają wsparcie cradle-to-cradle („od kołyski po grób”)[5]. Tym, co również definiuje etapy istnienia wartości od koncepcji po analizę, projektowanie, dostarczenie i bieżący serwis, jest strukturyzacja czasu. ¶47 Regularne przyrosty produktu wypływają z rejestru produktu, rejestrów sprintu i tablic scrumowych. Stanowią one artefakty, które odzwierciedlają pracę spoczywającą na właścicielu produktu i Zespole deweloperskim.

Na jeden zespół scrumowy przypada jeden strumień wartości, co pozwala uniknąć przekazywania zadań między zespołami. Prowadzą one do opóźniania w otrzymywaniu informacji zwrotnych, które w rezultacie generują potrzebę wprowadzenia dodatkowych modyfikacji – szczególnie zgubną formę marnotrawstwa (muda). Aby być skuteczny, zespół scrumowy musi zarówno mieć wgląd w rozwiązania biznesowe wspierane przez właściciela produktu, jak i możliwości deweloperskie Zespołu interdyscyplinarnego. Chociaż towary i usługi mogą pochodzić z innych źródeł i przepływać przez zespół scrumowy, strumień wartości nie rozdziela rozwoju pomiędzy wiele zespołów.

Podczas gdy produkt i wartość poruszają się w dół strumienia, istnieje również analogiczny przepływ „pod prąd”. Tym, co może mieć wpływ na na późniejsze prace wzdłuż strumienia, są nowe wymagania, protokoły usterek i pomysły na produkty wyłaniające się z rynku oraz z samego procesu rozwoju. Wiele działań pod prąd odbywa się podczas zorganizowanych wydarzeń w ramach Scruma, a zwłaszcza podczas Przeglądu sprintu i Planowania sprintu; jednak protokoły usterek i informacje zwrotne mogą pojawić się w dowolnym momencie. Aby zapewnić ¶55 Największą wartość, zespół może przerwać ¶37 Etap produkcyjny, aby naprawić usterki i wzmocnić Dumę z produktu. Większość obszarów strumieni wartości jest proponowanych przez użytkowników końcowych i klientów korzystających z funkcji obsługi klienta, która między innymi dokonuje segregacji wniosków w celu oddzielenia problemów operacyjnych i błędów użytkowników od protokołów usterek i wniosków o rozszerzenie linii produktu. To pierwsza „linia obrony”, a właściciel produktu jest kolejnym etapem, który wybiera i spełnia prośby z wniosków. Większość działań idących z prądem związanych jest z wykonywaniem nieciągłych dostaw zwanych regularnymi przyrostami produktu, jednak w przypadku wysokowydajnych strumieni wartości możliwe jest wykorzystanie jeszcze bardziej przyrostowego ¶46 Wdrażania reagującego, z nieregularnymi dostawami.

Każdy produkt może wspierać wiele strumieni wartości, więc zespół scrumowy może zarządzać kilkoma z nich. Z reguły zespoły scrumowe tworzą wartość dla kilku interesariuszy, a to oznacza, że w grę wchodzi często kilka strumieni wartości. Usługobiorca, użytkownik końcowy i nabywca są oczywistymi interesariuszami, ale zespół scrumowy powinien utrzymywać jeden strumień wartości, który sprawia, że praca staje się coraz mniej stresująca, przyjemniejsza i bardziej satysfakcjonująca.

Istnieje niewielka liczba kluczowych wzorców opisujących mniejsze całości w ramach strumienia wartości. Większość z nich jest opisana w dalszej części tego rozdziału. Niektóre z tych wzorców odzwierciedlają procesy związane z produkcją. Należą do nich:

• ¶7 Mapa drogowa produktu – mapa alternatywnych ścieżek do wartości

• ¶8 Sprint i Rejestr sprintu – ramy czasowe i zawartość przyrostu produktu

• Regularny przyrost produktu – realizacja komponentów Wizji

Oprócz skupiania się na produkcie jako takim, ważne jest, aby pamiętać, że strumień wartości jest żywym systemem, który jest coraz lepszy, i że istnieją wzorce dotyczące procesów usprawniania. Należą do nich:

• Puls kaizen – prowadzenie rozwoju jako alternatywy między analizą a próbami modernizacji,

• Retrospektywa sprintu – wyraźna koncentracja na ulepszaniu procesu w takim samym lub większym stopniu jak na ulepszaniu produktu,

• ¶54 Scrumowanie Scruma – wykorzystanie struktury Scruma jako narzędzia do zarządzania pracą nad doskonaleniem procesu.

Wzorzec ten opisuje strumień wartości jedynie jako ogólną konstrukcję, która idzie w parze z naturą Scruma jako szeroko pojętej struktury. Każdy z poszczególnych produktów ma własne strumienie wartości, które pochodzą z zasobów lub źródeł innowacji i które przyczyniają się do osiągnięcia odpowiedniej wartości produktów. Zespół scrumowy być może będzie chciał użyć odwzorowania strumienia wartości, aby zagłębić się w swój własny strumień wartości. Szczegółowe informacje na temat odwzorowania strumienia wartości można znaleźć w „Toyota Kata” Mike’a Rothera (Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results [Rot10]). Taka analiza może pomóc zespołowi scrumowemu w udoskonaleniu istniejących wzorców scrumowych lub w procesie dodawania nowych wzorców związanych z potrzebami konkretnej firmy.

¶4 PROJEKTOWANIE OPARTE NA ZESTAWACH

Ranga wzorca: **

Jako młody inżynier Toyoty z przyjemnością stawiasz czoła problemom. Ostrożnie identyfikujesz przyczynę problemu, dbając o dokładną analizę pięciu powodów. Następnie myślisz, myślisz i tworzysz genialne rozwiązanie. Opisujesz szczegółowo rozwiązanie i biegniesz, aby podzielić się nim ze swoim mentorem. Zamiast oceniać pomysł pod kątem jego zalet i pogratulować ci, pyta: „Jakie inne alternatywy rozważałeś? Jak to rozwiązanie wypada w porównaniu z tymi alternatywami?”. To cię zaskakuje, ponieważ byłeś przekonany, że zrobiłeś co mogłeś najlepiej. (Z The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer [Lik04], s. 263)

…Zespół scrumowy stworzył wspólnotę zaufania (Wspólnota zaufania). Zespół scrumowy na podstawie ¶16 Rejestru produktu wie, że stale się doskonali. Niektóre ¶17 Elementy rejestru produktu (PBI) z pierwszych Elementów rejestru produktu są gotowe i mogą przejść do ¶37 Etapu produkcyjnego, podczas gdy te z końca są daleko poza aktualnym horyzontem zainteresowań. W międzyczasie znajdą się takie elementy, które mogą być potencjalnym ¶47 Regularnym przyrostem produktu. Kilka z nich może stanowić alternatywę dla innych elementów w rejestrze. Również inne elementy są gotowe, a zespół jest pewien, co chce zbudować, ale bada „sposoby” ich budowania, mając na uwadze kilka pomysłów dla każdego z nich.

Istnieje wiele możliwych rozwiązań złożonego problemu. Często nie można przewidzieć, który jest najlepszy.

Wybranie jednej opcji i kurczowe trzymanie się jej przysporzy wiele pracy, gdy pojawią się nowe informacje, które zmuszają członków zespołu do ponownego rozważenia swojej początkowej decyzji. W dużym systemie, z wieloma podsystemami i wieloma zespołami, taka sytuacja powoduje opóźnienia, zmuszając do zatrzymania pracy, aby zespół scrumowy mógł zastanowić się nad nową decyzją i sprawdzić potencjalne konsekwencje dla reszty systemu.

Chociaż cenimy sobie gotowość na zmiany, warto wyeliminować marnowanie czasu. Z perspektywy czasu łatwo ujrzeć, w którym momencie analizowanie zablokowało inne czynności lub jak zły był kierunek, który początkowo wybraliśmy. Wyzwanie polega na znalezieniu złotego środka.

Przyjrzyj się wykresowi z artykułu na temat iteracyjnego projektowania interfejsu użytkownika autorstwa Jakoba Nielsena, ojca projektowania UI interfejsu (User Interface) i UX (User Experience) (magazyn „IEEE Computer 26” [Nie93]):

Jakość interfejsu jako funkcja liczby iteracji projektu: zmierzona użyteczność zwykle wzrośnie dla każdej dodatkowej iteracji, dopóki projekt nie osiągnie stabilizacji. („IEEE Computer 26” [Nie93]).

We wspomnianym artykule, który uzasadnia wykorzystanie iteracji w celu poprawy jakości produktu, Nielsen stwierdza: „tak naprawdę nie wiemy, co prowadzi do twórczej wyobraźni, niezbędnej dla całkowicie nowego i lepszego projektu interfejsu”. W związku z tym możemy powiedzieć, że sama iteracja jest niewystarczająca dla innowacji. Informacja zwrotna od klientów na temat regularnych przyrostów produktu poprawi produkt, ale nie zmieni zasadniczo koncepcji samego produktu. Organizacje deweloperskie potrzebują więc alternatywnego rozwiązania, które pokieruje ich działaniami, aby uzyskać nowe, niezbędne funkcje biznesowe abstrahując od istniejących ofert.

A zatem:

Opracuj wiele równoległych możliwości, ustalając z góry jedynie najważniejsze ograniczenia.

Aby to osiągnąć, każdy etap rozwoju musi rozwijać wybrany zestaw kilku równoległych alternatyw projektowych. Deweloperzy pracujący nad tą funkcją stale utrzymują bieżące analizy dla każdej alternatywy. Kiedy wszystkie alternatywy będą gotowe w połowie, odbywa się spotkanie, aby wymienić spostrzeżenia i ocenić, które opcje należy wyeliminować, a także omówić nowe opcje, które mogły pojawić się w międzyczasie. Jeśli wyłonił się wyraźny faworyt, równoległa praca zatrzymuje się, a zwycięzcę umieszcza się w planie protokołu. Jeśli nie, zespół (zawsze z udziałem Właściciela produktu) będzie musiał w dalszym stopniu analizować możliwości. Proces selekcji alternatyw wygląda następująco:

Celowe etapy konwergencji i dywergencji – magazyn „Naval Engineer Journal 121” [SDB09]

Gdy członkowie zespołu opracowują każdą opcję w ramach kolejnych iteracji, stopniowo zwiększają dokładność wskaźników wydajności pracy (magazyn „Naval Engineer Journal 121” [SDB09]). Początkowy przyrost pracy może wytworzyć jedynie niewyraźny szkic, drugi może wytworzyć prototyp na szybko, a końcowy przyrost pracy dałby początkową rzeczywistą implementację. Dlatego za każdym razem, gdy właściciel produktu i członkowie zespołu deweloperskiego decydują się na wyeliminowanie niektórych opcji, zwiększają również poziom szczegółowości pozostałych.

Jedna opcja, aby zbadać różne alternatywy projektowe, będzie zmieniać wiele parametrów (np. wybór algorytmu, strukturę danych, układ ekranu). Zespół powinien zwracać szczególną uwagę na liczbę parametrów, które zmieniają w różnych opcjach. Gdy zespoły coraz lepiej rozumieją, jak korzystać z projektowania opartego na zestawach, mogą zwiększać liczbę zmienianych parametrów. Uważaj na to, w jaki sposób opcje się pokrywają. Niezależne opcje zajmą więcej przestrzeni projektowej, ale ustalenie parametru zwiększy wiarygodność wyniku. Jeśli dobrze to zrobisz, zespół może zminimalizować czas realizacji, zmniejszając liczbę eksperymentów. Chodzi o to, że możesz zaprojektować to, czego się nauczysz, zamiast przechodzić od zaskoczenia do zaskoczenia.

Liczba możliwości wzrasta wraz z każdą iteracją, podczas gdy liczba elementów w fazie badania maleje.

W zależności od zakresu ćwiczenia z projektowania opartego na zestawach, wyniki mogą być przekazywane bezpośrednio do sprintu lub brane pod uwagę podczas tworzenia ¶26 Udoskonalonego rejestru produktu

Mając przed sobą zbyt wiele możliwych rozwiązań, zespoły zależne nie mogą zablokować projektów systemów. Nie oznacza to jednak, że praca musi czekać na konkretną decyzję. Pracując w ramach wcześniej ustalonych najważniejszych ograniczeń, zespół może rozpocząć pracę nad projektem podsystemu, pamiętając o tym, że musi on pasować do wszystkich rozwiązań przeznaczonych dla większego systemu. W rzeczywistości zespół może pozostawić niektóre nieopracowane parametry aż do czasu rozpoczęcia etapu produkcji, nigdy nie ustalając ich w fazie projektowania. W niektórych przypadkach możliwe jest nawet zaoferowanie klientowi alternatywnych opcji.

Zbieganie się wzajemnie oddziałujących na siebie elementów („The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster”, magazyn „Sloan Management Review 36” [WLC95], s. 43)

Kluczowe jest ustalenie, kiedy zacząć dążyć do ostatecznego rozwiązania. Ford i Sobek kształtowali proces rozwoju Toyoty przy użyciu rzeczywistych opcji i przeprowadzili 100 symulacji trwającego 900 dni projektu („Adapting Real Options to New Product Development by Modeling the Second Toyota Paradox”, opublikowany w magazynie „IEEE Transactions on Engineering Management 52” [FS05]).

Koniec projektu jakościowego

Czas inicjacji konwergencji

Oczekiwana jakość deweloperskich projektów opartych na punktach oraz szablonach (magazyn „IEEE Transactions on Engineering Management 52” [FS05])

Wartość marginalna projektów opartych na zestawach i punktach

Czas inicjacji konwergencji

Oczekiwana wartość elastyczności deweloperskich projektów opartych na zestawach w odniesieniu do projektów punktowych (magazyn „IEEE Transactions on Engineering Management 52” [FS05])

Ustalenia te sugerują, że optymalny czas na konwergencję znajduje się w pobliżu połowy całego okresu trwania projektu. Autorzy jednak ostrzegają, że jeśli na początku projektu występują opóźnienia, to rozsądne może być wprowadzenie konwergencji nawet nieco później niż w punkcie środkowym. Dlatego też właściciel produktu musi mieć wgląd w ogólny postęp rozbieżnych prac.

Toyota woli, aby ci sami ludzie wspólnie opracowali wszystkie opcje. W ten sposób grupa rozwija wyczucie przestrzeni problemu, które może okazać się pomocne w projektowaniu nowych opcji. Mogą przyspieszyć ten proces, opracowując kilka opcji jednocześnie, a nie w sposób sekwencyjny. To szybkie porównanie opcji w miarę ich budowania przez zespół przyczynia się do stworzenia wspólnego doświadczenia potrzebnego do rozwijania intuicji. Warto również zauważyć, że projektowanie oparte na zestawach pozwala na wykorzystywanie kompetencji z obszarów, które nie były używane do opracowywania produktu od dłuższego czasu. Dzięki temu tworzona jest pamięć korporacyjna, która również może stać się cenna podczas pracy nad przyszłymi produktami.

Design sprint opracowany przez Google charakteryzuje się szybką analizą wielu pomysłów projektowych za jednym zamachem. Autorzy twierdzą, że „daje to zespołom swego rodzaju ściągawkę bez potrzeby tworzenia i wydawania”. Proces rozpoczyna się od odwzorowania problemu i wydzielenia obszaru, na którym należy się skupić, a kończy się testowaniem wysokiej wierności prototypu z klientami. Cały proces trwa tydzień lub krócej[6].

Wreszcie, w tych kluczowych momentach, gdy proces eliminuje opcję, którą jakiś zespół opracował z pasją, musimy wziąć pod uwagę czynnik ludzki: gdy inni oceniają twoją pracę, mogą sprawić ci przykrość, a decyzja o likwidacji może być potraktowana jako obraza. Strata ta stwarza potrzebę pewnego rodzaju „rytuału przejścia”. Robert Heath, autor książki Celebrating Failure, zaleca liderom „opatrzenie porażek pozytywnymi komentarzami. Pogratuluj wszystkim wysiłków, przypomnij im o mocnych stronach i mądrości zdobytej podczas tego doświadczenia. Patrząc z perspektywy, porażka może zrobić tyle samo, by zmotywować drużynę, co zwycięstwo” (patrz Celebrating Failure: The Power of Taking Risks, Making Mistakes, and Thinking Big [Hea09]).

Te komentarze nie będą jednak miały żadnego znaczenia, jeśli nie będą miały miejsca w ramach większej kultury ciągłego uczenia się. Kultura „autopsji bez obwiniania” praktykowana przez Google jest jednym z takich przykładów. Opiera się na doświadczeniu w innych dziedzinach, takich jak opieka zdrowotna i lotnictwo, w których porażka może okazać się śmiertelna. W tych miejscach pracy po awarii uwagę koncentruje się nie na osobach, ale na większym systemie i odkrywaniu przyczyn, przez które ludzie otrzymali szczątkowe lub nieprawidłowe informacje, co z kolei doprowadziło do niepożądanego rezultatu. Lunney i Lueder piszą (Site Reliability Engineering: How Google Runs Production Systems [LL16]), że „nie można naprawić ludzi, ale można naprawić systemy i procesy, aby podczas projektowania i obsługiwania złożonych systemów lepiej wspierać osoby dokonujące właściwych wyborów”. Aby ten wzorzec spełnił swoją rolę, zespół musi w pełni przyjąć ideę zbiorowego doskonalenia.

Zespół właściciela produktu może zastosować to podejście, aby ocenić, które z kilku alternatywnych PBI należy zachować w rejestrze produktu, może użyć go do poszukiwania alternatyw dla elementów wysokiego ryzyka, bądź o wysokiej niepewności lub dla całego regularnego przyrostu produktu. Takie analizowanie projektu może przekroczyć wiele granic w sprincie.

Alternatywnie, zespół deweloperski może zastosować to podejście w ramach sprintu, aby ocenić ryzyko w wielu wariantach implementacji i może wykorzystać uzyskaną wiedzę, aby wybrać jedną alternatywę. Podczas projektowania opartego na szablonach w sprincie, zespół deweloperski powinien ustalić czas oceny danego rozwiązania. Ponieważ podczas procesu pojawia się wiele nowych wymagań (i taki jest zamiar), trudno oszacować, ile zespół osiągnie w danym przedziale czasowym. Dlatego, stosując takie podejście, zespół musi zaakceptować fakt, że istnieje ryzyko, że ocena może nie spowodować gotowego regularnego przyrostu produktu, ale mimo to jest warta poświęconego jej czasu.

Niezależnie od tego, czy wyniki danego projektowania opartego na zestawach wejdą na rynek, czy nie, zespół zyskuje świadomość obecności (lub nie) takich funkcji w produkcie, zwiększając Dumę z produktu.

Przypisy

[1] Bill Gates. Interview. Academy of Achievement, http://www.achievement.org/autodoc/page/gat0int-1, 2010 (dostęp 27.08.2016).

[2] Carl Hofman, „Elon Musk Is Betting His Fortune on a Mission Beyond Earth’s Orbit”, Wired.com, http://www.wired.com/2007/05/ff-space-musk (dostęp 27.08.2016).

[3] Julie Johnson i Dana Hull, „Musk’s SpaceX returns rocket for perfect upright landing”, [w:] The Seattle Times, http://www.seattletimes.com/business/boeing-aerospace/musks-spacexreturns-rocket-for-perfect-upright-landing/ 22 maja 2007, (dostęp 27.08.2016).

[4] Coroczne sprawozdanie Tony’s Chocolonely, https://tonyschocolonely.com/storage/configurationstonyschocolonelycom.app/files/jaarfairslag/2017-2017/tc_jaarfairslag_2016_en_totaal_01.pdf (dostęp 6.06.2018).

[5] Podejście propagujące recykling oraz produkcję w zgodzie z naturą.

[6] Jake Knapp (Google Ventures) i in. „The Design Sprint”, http://www.gv.com/sprint, brak bezpośredniego odnośnika (dostęp 02.11.2017).

Pozostałe rozdziały dostępne w pełnej wersji e-booka.