Zarządzanie projektami ze Scrumem 9788324685295, 0321605780

Table of contents :
Spis treści
Słowo wstępne Jeff Sutherland
Słowo wstępne Brett Queener
Przedmowa
Podziękowania
O autorze
Rozdział 1. Rola właściciela produktu
Właściciel produktu
Pożądane cechy właściciela produktu
Wizjoner i wykonawca
Lider i gracz zespołowy
Komunikator i negocjator
Inspirujący i zaangażowany
Dostępny i wykwalifikowany
Praca z zespołem
Współpraca z mistrzem młyna
Praca z klientami, użytkownikami oraz innymi interesariuszami
Skalowanie roli właściciela produktu
Główny właściciel produktu
Hierarchia właścicieli produktu
Wybór odpowiednich właścicieli produktu
Powszechne błędy
Właściciel produktu o zbyt małych uprawnieniach
Przepracowany właściciel produktu
Właściciel produktu o podzielonych obowiązkach
Odległy właściciel produktu
Zastępczy właściciel produktu
Komitet właścicieli produktu
Spostrzeżenia
Rozdział 2. Tworzenie wizji produktu
Wizja produktu
Pożądane cechy wizji
Wspólna i jednocząca
Obszerna i angażująca
Krótka i zwięzła
Minimalna wersja produktu nadająca się do wypuszczenia na rynek
Prostota
Brzytwa Ockhama
Mniej znaczy więcej
Prosty interfejs użytkownika
Potrzeby klientów i atrybuty produktu
Narodziny wizji
Wykorzystanie projektów osobistych
Wykorzystanie metodologii Scrum
Prototypy i makiety
Persony i scenariusze
Opakowania poglądowe i recenzje w prasie branżowej
Model Kano
Wizja i mapa produktu
Minimalna wersja produktu i warianty produktu
Powszechne błędy
Brak określonej wizji
Tworzenie wizji profetycznych
Paraliż analityczny
Przekonanie o tym, co jest najlepsze dla klientów
Duże jest piękne
Spostrzeżenia
Rozdział 3. Praca z rejestrem produktu
Cechy rejestru produktu
Wystarczająco szczegółowy
Szacunkowy
Nowo powstający
Zawierający priorytety
Porządkowanie rejestru produktu
Odkrywanie i opisywanie elementów
Odkrywanie elementów
Opisywanie elementów
Ustalanie struktury rejestru
Ustalanie priorytetów rejestru produktu
Wartość
Wiedza, niepewność i ryzyko
Zdatność do wypuszczenia na rynek
Zależności
Przygotowanie do planowania sprintu
Wybór celu sprintu
Przygotowanie wystarczającej liczby elementów dokładnie na czas
Dekompozycja elementów
Zapewnianie klarowności, możliwości testowania i wykonalności
Dostosowywanie wielkości elementów
Punkty
Poker planistyczny
Postępowanie w przypadku wymagań niefunkcjonalnych
Opisywanie wymagań niefunkcjonalnych
Zarządzanie wymaganiami niefunkcjonalnymi
Skalowanie rejestru produktu
Wykorzystuj jeden rejestr produktu
Działania porządkowe na szeroką skalę
Uwzględnienie odrębnych spojrzeń na rejestr
Powszechne błędy
Ukryte specyfikacje wymagań
Lista życzeń do Świętego Mikołaja
Określanie wymagań
Zaniedbywanie porządkowania
Uzupełnianie rejestrów
Spostrzeżenia
Rozdział 4. Planowanie wydania
Czas, koszt i funkcjonalność
Zamrożona jakość
Wczesne i częste wydania
Cykle kwartalne
Szybkość
Wykres spalania wydania
Wykres spalania
Belka spalania
Plan wydań
Prognozowanie szybkości
Tworzenie planu wydania
Planowanie wydań w dużych projektach
Wspólna linia bazowa dla szacunków
Planowanie przyszłościowe
Systematyzacja
Powszechne błędy
Brak wykresu spalania lub planu
Właściciel produktu na siedzeniu pasażera
Rozbudowane wydania
Kompromisy związane z jakością
Spostrzeżenia
Rozdział 5. Współpraca w trakcie spotkań planujących sprint
Planowanie sprintu
Definicja pojęcia „gotowe”
Codzienne zebrania scrumowe
Rejestr sprintu i wykres spalania
Przegląd sprintu
Retrospekcja sprintu
Zebrania w trakcie większych projektów
Wspólne planowanie sprintu
Codzienne zebranie scrumowe dla wszystkich zespołów
Wspólne przeglądy sprintu
Wspólna retrospekcja sprintu
Powszechne błędy
Znikający właściciel produktu
Pasywny właściciel produktu
Zmienne tempo pracy
Zasłona dymna
Raportowanie elementów wykresu spalania
Spostrzeżenia
Rozdział 6. Przejście do roli właściciela produktu
Bycie doskonałym właścicielem produktu
Poznaj siebie
Rozwijaj się
Zdobądź trenera
Upewnij się, że sponsoring pochodzi z właściwego poziomu
Jeszcze nie skończyłeś
Tworzenie doskonałych właścicieli produktu
Doceń wagę roli
Wybierz odpowiednich właścicieli produktu
Upoważniaj i wspieraj właścicieli produktu
Wspieraj wdrażanie roli właściciela produktu
Spostrzeżenia
Źródła
Skorowidz

Citation preview

Tytuł oryginału: Agile Product Management with Scrum: Creating Products that Customers Love Tłumaczenie: Katarzyna Żarnowska ISBN: 978-83-246-8529-5 Authorized translation from the English language edition, entitled: AGILE PRODUCT MANAGEMENT WITH SCRUM: CREATING PRODUCTS THAT CUSTOMERS LOVE; ISBN 0321605780; by Roman Pichler; published by Pearson Education, Inc, publishing as Addison Wesley. Copyright © 2010 by Roman Pichler. All rights reserved. No part of this book may by reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A., Copyright © 2014. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: [email protected] WWW: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/zaprsc_ebook Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

 Poleć książkę na Facebook.com  Kup w wersji papierowej  Oceń książkę

 Księgarnia internetowa  Lubię to! » Nasza społeczność

Opinie na temat książki

Zarządzanie projektami ze Scrumem. Twórz produkty, które pokochają klienci „Do tej pory właściciele produktu nie mieli zbyt wielu źródeł, w których mogliby poszukać pomocy, chociaż ich zadanie w zwinnym projekcie jest najtrudniejsze. Ta książka naprawia to niedopatrzenie. Wskazówki Romana Pichlera dotyczące obowiązków właściciela produktu są skuteczne i praktyczne. Jego rady, odpowiednio zastosowane, przyniosą korzyść każdemu właścicielowi produktu oraz każdemu zespołowi pracującemu według zwinnych metodyk”. — Mike Cohn, autor książek: Succeeding with Agile, Agile Estimating and Planning, User Stories Applied „Scrum nic nie mówi na temat tego, jak właściciel produktu może zmaksymalizować jego wartość. Większość menedżerów produktu i pracowników marketingu nie wie, jak wykorzystywać do tego przyrostową naturę Scruma. Roman swoją książką Zarządzanie projektami ze Scrumem. Twórz produkty, które pokochają klienci doskonale wypełnił tę lukę”. — Ken Schwaber, współtwórca procesu Scrum „Niewiele napisano na temat sytuacji, w których spotykają się ze sobą zwinne metody i zarządzanie produktem, ale Roman niezwykle przyczynia się do rozwiązania tego problemu. Książka daje jasne wskazówki oraz doskonałe przykłady tego, jak stać się zwinnym menedżerem produktu oraz dobrym właścicielem produktu, a także jak być liderem z wyraźną wizją. Ta pozycja jest niezbędna na liście lektur wszystkich menedżerów produktu, którzy pierwszy raz mają do czynienia z metodologią Scrum, wszystkich właścicieli produktu oraz wszystkich menedżerów produktu, którzy chcą jak najlepiej wykorzystać zwinne metodologie”. — Greg Cohen, główny konsultant w firmie 280 Group oraz dyrektor Silicon Valley Product Management Association

„Zawsze chętnie słucham tego, co ma do powiedzenia Roman. W tej książce dzieli się on nie tylko swoim doświadczeniem („Powszechne błędy” to doskonała sekcja), ale także przykładami z życia innych właścicieli produktu. Ta kombinacja pozwala mu na szersze spojrzenie i umożliwia dzielenie się tą wizją również z nami. Dzięki, Romanie!”. — Linda Rising, niezależna konsultantka i współautorka książki Fearless Change: Patterns for Introducing New Ideas „Nowa i niesamowita książka Romana Pichlera skupia się na produkcie oraz roli właściciela produktu, aplikując metodologię Scrum do całego łańcucha wartości. Jego doświadczenie w roli coacha zapewnia zrównoważone, praktyczne i możliwe do zastosowania rozwiązania odpowiednie dla każdej sytuacji, jaka może wydarzyć się w trakcie cyklu życiowego produktu. Ta książka to przewodnik po zwinnym zarządzaniu produktem dla wszystkich praktyków!”. — Markus Andrezak, menedżer działu Outsourced Product Development w firmie mobile. international „Książka Romana Pichlera jest dla właścicieli produktu łatwym i wszechstronnym kompendium dotyczącym roli właściciela produktu w metodologii Scrum. Pokazuje ona znaczenie wizji i roli lidera, a także minimalnych wymagań rynkowych oraz krótkich cykli wydań. Jest źródłem wiedzy dla nowych właścicieli produktu i dobrych rad dla kierowników, by mogli wybrać osoby odpowiednie na to stanowisko”. — Andrea Heck, menedżer projektów związanych z przejściem do zwinnych metodologii „Rola właściciela produktu jest w metodologii Scrum niezwykle ważna, a nowa książka Romana pomoże osiągnąć sukces osobom na tym stanowisku”. — Craig Larman, współautor książek Scaling Lean & Agile Development oraz Practices for Scaling Lean & Agile Development „Rozsądne podejście Romana do tematu pozwala wrócić do korzeni metodologii Scrum, opartych na fundamentalnych koncepcjach stojących za byciem właścicielem produktu. Skupienie się na pracy zespołowej jest miłym antidotum na skoncentrowane na procesie poglądy Scruma, a pokazanie, w jaki sposób zmienia się rola właściciela produktu, jest wyzwaniem dla status quo tradycyjnego

projektu. Dzięki swojej dociekliwości Roman jest w stanie spożytkować swoje doświadczenie i doświadczenie innych osób, pokazując poprzez prawdziwe przykłady sukcesów i porażek, jak rola właściciela produktu powinna funkcjonować, by dało się rozwiązać najczęściej pojawiające się problemy. Książka ta, naszpikowana praktycznymi poradami, jest przeznaczona dla każdego, kto chce zarządzać projektem lub być właścicielem produktu i wypuszczać na rynek udane produkty”. — Simon Bennett, globalny lider kompetencji i właściciel produktu w firmie EMC Consulting „Zarządzanie projektami ze Scrumem. Twórz produkty, które pokochają klienci Romana Pichlera jest niezbędnym źródłem informacji dla zwinnych menedżerów produktu, właścicieli produktu, analityków biznesowych oraz każdego, kto chciałby zostać doskonałym menedżerem produktu. Roman dzieli się praktycznymi wskazówkami i wytycznymi dotyczącymi wszystkich aspektów zwinnego planowania, zarządzania rejestrem produktu oraz niezbędnych czynności związanych z tworzeniem wizji, określaniem wartości i współpracą. Zarządzanie projektami ze Scrumem. Twórz produkty, które pokochają klienci pomaga zwiększyć świadomość dotyczącą złożoności i wieloaspektowości zwinnego zarządzania produktem. Każdy członek zwinnego zespołu odniesie korzyści po przeczytaniu tej książki, ponieważ w każdym zespole wszyscy powinni myśleć jak menedżerowie produktu”. — Ellen Gottesdiener, prezeska/założycielka firmy EBG Consulting „Rozwijanie oprogramowania zwinnymi metodami polega na przyrostowym przetwarzaniu wymagań w działające elementy przy wykorzystaniu krótkich iteracji. Zarządzanie projektami ze Scrumem. Twórz produkty, które pokochają klienci odpowiada na jedno z najważniejszych pytań, jakie zadają sobie organizacje pracujące nad tworzeniem produktu: czy budujemy odpowiedni produkt? Albo, jak ujął to Roman: czy tworzymy produkty, które klienci pokochają? Książka Romana jest długo oczekiwanym łącznikiem wizji ze znaczącymi i możliwymi do przetrawienia wymaganiami. Zapewnia właścicielom produktu oraz kierownikom wykonawczym gruntowny wstęp do struktury Scruma, co pozwoli im na zredukowanie kosztów produkcji oraz czasu niezbędnego do wprowadzenia na rynek ekscytującego oprogramowania”. — Jochen Krebs, mentor przyrostów oraz autor książki Agile Portfolio Management

„Roman dostarczył nam książkę na temat zwinnego zarządzania produktem, która w sposób czytelny opisuje istotę, wyzwania i pułapki związane z rolą właściciela produktu. Na podstawie praktycznych przykładów, dzięki podkreśleniu powszechnych błędów oraz refleksji na końcu każdego rozdziału Roman sprawia, że zadania właściciela produktu stają się dostępne i wykonalne. To książka, która powinna być lekturą obowiązkową w każdej organizacji chcącej wprowadzić metodykę Scrum”. — Jessica Hildrum, była dyrektor generalna największej norweskiej firmy szkoleniowej pracującej według zwinnych metodyk „W sercu każdego udanego zespołu deweloperów pracującego według metodyk zwinnych znajduje się zaangażowany menedżer z wizją i możliwościami. Pichler przedstawia w swojej książce prostą, bezpośrednią definicję roli, dzięki której każdy zespół scrumowy osiągnie imponujące rezultaty. Jeśli chcesz poznać tajniki pełnienia obowiązków na najważniejszym stanowisku w zwinnej metodologii, ta książka jest dla Ciebie. Jest ona niezbędna dla każdego nowego właściciela produktu!”. — Steve Greene, wiceprezes, zarządzający programem i zwinnym rozwojem w firmie salesforce.com

Dla Melissy

Spis treści

Słowo wstępne — Jeff Sutherland ................................................................... 15 Słowo wstępne — Brett Queener .................................................................... 17 Przedmowa ...................................................................................................... 21 Podziękowania ................................................................................................ 25 O autorze ......................................................................................................... 27 Rozdział 1. Rola właściciela produktu ............................................................ 29 Właściciel produktu .................................................................................... 30 Pożądane cechy właściciela produktu ...................................................... 32 Wizjoner i wykonawca ......................................................................... 32 Lider i gracz zespołowy ........................................................................ 32 Komunikator i negocjator ................................................................... 34 Inspirujący i zaangażowany ................................................................ 34 Dostępny i wykwalifikowany .............................................................. 35 Praca z zespołem ......................................................................................... 36 Współpraca z mistrzem młyna .................................................................. 38 Praca z klientami, użytkownikami oraz innymi interesariuszami ....... 39 Skalowanie roli właściciela produktu ....................................................... 41 Główny właściciel produktu ............................................................... 41 Hierarchia właścicieli produktu ......................................................... 42 Wybór odpowiednich właścicieli produktu ...................................... 45

9

10

SPIS TREŚCI

Powszechne błędy ........................................................................................46 Właściciel produktu o zbyt małych uprawnieniach .........................46 Przepracowany właściciel produktu ...................................................47 Właściciel produktu o podzielonych obowiązkach ..........................48 Odległy właściciel produktu ................................................................48 Zastępczy właściciel produktu .............................................................49 Komitet właścicieli produktu ..............................................................50 Spostrzeżenia ................................................................................................50 Rozdział 2. Tworzenie wizji produktu ............................................................53 Wizja produktu ............................................................................................54 Pożądane cechy wizji ...................................................................................55 Wspólna i jednocząca ...........................................................................56 Obszerna i angażująca ..........................................................................56 Krótka i zwięzła .....................................................................................57 Minimalna wersja produktu nadająca się do wypuszczenia na rynek .......................................................................58 Prostota .........................................................................................................61 Brzytwa Ockhama .................................................................................62 Mniej znaczy więcej ..............................................................................62 Prosty interfejs użytkownika ...............................................................63 Potrzeby klientów i atrybuty produktu ....................................................64 Narodziny wizji ............................................................................................66 Wykorzystanie projektów osobistych ................................................66 Wykorzystanie metodologii Scrum ....................................................67 Techniki tworzenia wizji .............................................................................68 Prototypy i makiety ...............................................................................68 Persony i scenariusze ............................................................................69 Opakowania poglądowe i recenzje w prasie branżowej ...................70 Model Kano ............................................................................................71 Wizja i mapa produktu ...............................................................................72 Minimalna wersja produktu i warianty produktu ..................................73 Powszechne błędy ........................................................................................75 Brak określonej wizji .............................................................................75 Tworzenie wizji profetycznych ...........................................................75 Paraliż analityczny ................................................................................76 Przekonanie o tym, co jest najlepsze dla klientów ...........................76 Duże jest piękne .....................................................................................77 Spostrzeżenia ................................................................................................78

SPIS TREŚCI

11

Rozdział 3. Praca z rejestrem produktu ......................................................... 79 Cechy rejestru produktu ............................................................................ 80 Wystarczająco szczegółowy ................................................................. 80 Szacunkowy ........................................................................................... 81 Nowo powstający .................................................................................. 81 Zawierający priorytety ......................................................................... 81 Porządkowanie rejestru produktu ............................................................ 81 Odkrywanie i opisywanie elementów ...................................................... 83 Odkrywanie elementów ....................................................................... 84 Opisywanie elementów ........................................................................ 85 Ustalanie struktury rejestru ................................................................ 86 Ustalanie priorytetów rejestru produktu ................................................. 87 Wartość .................................................................................................. 88 Wiedza, niepewność i ryzyko .............................................................. 89 Zdatność do wypuszczenia na rynek ................................................. 90 Zależności .............................................................................................. 91 Przygotowanie do planowania sprintu .................................................... 92 Wybór celu sprintu ............................................................................... 92 Przygotowanie wystarczającej liczby elementów dokładnie na czas .............................................................................. 93 Dekompozycja elementów .................................................................. 95 Zapewnianie klarowności, możliwości testowania wykonalności ..................................................................................... 97 Dostosowywanie wielkości elementów .................................................... 98 Punkty .................................................................................................... 98 Poker planistyczny ............................................................................... 99 Postępowanie w przypadku wymagań niefunkcjonalnych ................. 102 Opisywanie wymagań niefunkcjonalnych ...................................... 102 Zarządzanie wymaganiami niefunkcjonalnymi ............................. 103 Skalowanie rejestru produktu ................................................................. 104 Wykorzystuj jeden rejestr produktu ................................................ 104 Działania porządkowe na szeroką skalę .......................................... 105 Uwzględnienie odrębnych spojrzeń na rejestr ............................... 105 Powszechne błędy ..................................................................................... 106 Ukryte specyfikacje wymagań ........................................................... 106 Lista życzeń do Świętego Mikołaja ................................................... 107 Określanie wymagań .......................................................................... 107

12

SPIS TREŚCI

Zaniedbywanie porządkowania ........................................................107 Uzupełnianie rejestrów ......................................................................108 Spostrzeżenia ..............................................................................................108 Rozdział 4. Planowanie wydania ...................................................................111 Czas, koszt i funkcjonalność ....................................................................112 Zamrożona jakość ......................................................................................115 Wczesne i częste wydania .........................................................................115 Cykle kwartalne ..........................................................................................118 Szybkość ......................................................................................................119 Wykres spalania wydania .........................................................................120 Wykres spalania ...................................................................................120 Belka spalania ......................................................................................122 Plan wydań .................................................................................................124 Prognozowanie szybkości ..................................................................126 Tworzenie planu wydania ..................................................................127 Planowanie wydań w dużych projektach ...............................................128 Wspólna linia bazowa dla szacunków ..............................................129 Planowanie przyszłościowe ...............................................................129 Systematyzacja .....................................................................................130 Powszechne błędy ......................................................................................131 Brak wykresu spalania lub planu ......................................................131 Właściciel produktu na siedzeniu pasażera .....................................132 Rozbudowane wydania .......................................................................132 Kompromisy związane z jakością .....................................................132 Spostrzeżenia ..............................................................................................133 Rozdział 5. Współpraca w trakcie spotkań planujących sprint ...................135 Planowanie sprintu ....................................................................................136 Definicja pojęcia „gotowe” .......................................................................137 Codzienne zebrania scrumowe ................................................................138 Rejestr sprintu i wykres spalania .............................................................139 Przegląd sprintu .........................................................................................140 Retrospekcja sprintu ..................................................................................142 Zebrania w trakcie większych projektów ...............................................143 Wspólne planowanie sprintu .............................................................143 Codzienne zebranie scrumowe dla wszystkich zespołów ..............144 Wspólne przeglądy sprintu ................................................................144 Wspólna retrospekcja sprintu ...........................................................145

SPIS TREŚCI

13

Powszechne błędy ..................................................................................... 145 Znikający właściciel produktu .......................................................... 146 Pasywny właściciel produktu ............................................................ 146 Zmienne tempo pracy ........................................................................ 147 Zasłona dymna .................................................................................... 147 Raportowanie elementów wykresu spalania ................................... 148 Spostrzeżenia ............................................................................................. 148 Rozdział 6. Przejście do roli właściciela produktu ....................................... 151 Bycie doskonałym właścicielem produktu ............................................ 152 Poznaj siebie ........................................................................................ 152 Rozwijaj się .......................................................................................... 152 Zdobądź trenera .................................................................................. 154 Upewnij się, że sponsoring pochodzi z właściwego poziomu ...... 154 Jeszcze nie skończyłeś ........................................................................ 155 Tworzenie doskonałych właścicieli produktu ....................................... 155 Doceń wagę roli .................................................................................. 156 Wybierz odpowiednich właścicieli produktu ................................. 156 Upoważniaj i wspieraj właścicieli produktu ................................... 157 Wspieraj wdrażanie roli właściciela produktu ............................... 158 Spostrzeżenia ............................................................................................. 159 Źródła ............................................................................................................ 161 Skorowidz ..................................................................................................... 167

14

SPIS TREŚCI

Słowo wstępne Jeff Sutherland

Właściciel produktu to stanowisko stosunkowo nowe w większości firm, wymagające zwięzłej i zrozumiałej prezentacji, przedstawionej w niniejszej książce. Kiedy wybierano pierwszego właściciela produktu, pełniłem obowiązki wiceprezesa w firmie Object Technology, odpowiedzialnej za wdrożenie pierwszego produktu stworzonego za pomocą metodologii Scrum. Nowy produkt mógł pogrążyć firmę lub wznieść ją na wyżyny, a ja miałem sześć miesięcy, by dostarczyć narzędzie, które zmieniłoby rynek. Poza pracą nad produktem z małym, starannie dobranym zespołem musiałem również wdrożyć wszystkich pracowników firmy w proces produkcyjny. Biorąc pod uwagę, że do dnia wypuszczenia produktu na rynek zostało tylko kilka miesięcy, stało się jasne, że o sukcesie lub porażce zadecyduje minimalny zestaw odpowiednich właściwości. Okazało się, że nie mam czasu na rozmowy z klientami i uważną obserwację konkurencji, aby precyzyjnie określić, nad którymi właściwościami powinniśmy pracować na początku i jak rozbić je na mniejsze elementy w rejestrze produktu. Przekazałem już moje obowiązki inżynierskie pierwszemu mistrzowi młyna, Johnowi Scumniotalesowi, ale teraz potrzebowałem właściciela produktu. Miałem dostęp do wszelkich źródeł osobowych 15

16

SŁOWO WSTĘPNE JEFF SUTHERLAND

w firmie, więc wybrałem do tej roli najlepszą osobę, jaką znałem: Dona Roednera. Jako pierwszy właściciel produktu Don musiał wziąć odpowiedzialność za wizję produktu, biznesplan, a także zająć się zwrotem z inwestycji, harmonogramem, planem wydań oraz, co najważniejsze, ustalić dokładne priorytety elementów rejestru produktu. Don połowę swojego czasu spędzał z zespołem, a połowę z klientami. Jego zadaniem było dostarczenie odpowiedniego produktu, podczas gdy ja pracowałem z resztą firmy nad nazwą i marką produktu, strategią marketingową oraz komunikacją, a także planowaniem sprzedaży i szkoleniami. Jednocześnie uczestniczyłem w codziennych zebraniach Scruma i zajmowałem się usuwaniem przeszkód w pracy zespołu. Don musiał wziąć na siebie rolę ważniejszą niż obowiązki menedżera marketingu produktu. Nagle stał się właścicielem nowej linii biznesowej. W tym samym czasie był zaangażowany w prace zespołu inżynieryjnego, codziennie pomagając zespołowi i motywując jego członków. Jednoczesne osadzenie w zespole i na rynku było skokiem na głęboką wodę. Kwestie zaangażowania dobrego właściciela produktu oraz jego odpowiedzialności za sukces są w tej książce dobrze zilustrowane, ale rzadko można je spotkać w firmach produkcyjnych lub zespołach IT. Potrzebowaliśmy pełnego obrazu doskonałego właściciela produktu oraz wytycznych dotyczących wypełniania przez niego obowiązków, a Roman Pichler dał nam odpowiedni przewodnik. Jeff Sutherland, współtwórca metodyki Scrum

Słowo wstępne Brett Queener

W przemyśle oprogramowania powstał nowy ruch: ruch zwinny. W ciągu ostatnich dwóch dziesięcioleci wielu klientów, partnerów oraz pracowników rozczarowało się sposobem rozwoju technologii dla przedsiębiorstw. Stosowane rozwiązania miały często niską jakość, długo trwało, zanim znalazły się na rynku, nie były innowacyjne i nie mogły pomóc w rozwiązywaniu realnych problemów biznesowych. Salesforce.com, poprzez skupienie się na sukcesie klientów i pracowników, aspiruje do bycia inną niż pozostałe firmy zajmujące się produkcją oprogramowania. Wiedzieliśmy, że tradycyjne metody dostarczania oprogramowania nie zdadzą egzaminu. Musieliśmy od nowa przemyśleć cały model, odrzucić błędne założenia i znaleźć inne wyjście. Zadawaliśmy sobie pytania: czy jesteśmy w stanie za każdym razem dostarczyć oprogramowanie najwyższej jakości? Czy jest sposób na to, by nasi klienci dostawali wartościowe produkty wcześnie i często? Czy możliwe jest tworzenie innowacji w miarę rozrastania się firmy? Okazuje się, że tak.

17

18

SŁOWO WSTĘPNE BRETT QUEENER

Jako główny właściciel produktu w firmie Salesforce.com musiałem znaleźć sposób na to, by moi menedżerowie produktu mogli efektywnie łączyć potrzeby klientów i biznesu bezpośrednio z pracą deweloperów w wysoce dynamiczny i responsywny sposób. Wykorzystanie Scruma pozwala, by to menedżerowie produktu byli odpowiedzialni za dostarczanie wartości klientom. Dzięki temu zespół może najpierw budować najbardziej krytyczne aspekty oprogramowania i dostarczać je klientom tak szybko, jak to tylko możliwe. Scrum zapewnia także elastyczność niezbędną do szybkiego reagowania na zmieniające się warunki rynkowe i presję konkurencji, a także ułatwia dostarczanie innowacji wynikających z pracy deweloperów. Zwinne zarządzanie produktem za pomocą metodyki Scrum prezentuje różnice pomiędzy właścicielem produktu a tradycyjnym menedżerem produktu i zwraca uwagę na większą ilość obowiązków tego pierwszego. Książka w jasny sposób wyjaśnia kontrasty roli tradycyjnej i roli zwinnej. Wiele osób próbowało objaśniać rolę właściciela produktu, ale nikt dotąd nie był w stanie uchwycić jej sedna w sposób, w jaki zrobił to Roman Pichler. Niniejsza książka opisuje zwinne teorie i praktyczne metody zwinnego zarządzania produktem, które pomogą właścicielom produktu, zespołowi scrumowemu oraz kierownikom wykonawczym w dostarczaniu innowacji. Roman posiłkuje się prawdziwymi przykładami z pracy wielu firm, takich jak na przykład wysoce innowacyjna Salesforce.com, podając równocześnie przystępne wyjaśnienia dotyczące budowy i dostarczania minimalnych funkcjonalności niezbędnych w innowacjach. Objaśnia również powszechne pułapki i błędy, które popełnia wielu właścicieli produktu. W dzisiejszym dynamicznym i konkurencyjnym środowisku wymagania i oczekiwania naszych klientów są większe niż kiedykolwiek. W Salesforce.com zwinne podejście zapewniło doskonałe rezultaty, umożliwiając naszym właścicielom produktu dostarczanie większej ilości wartościowych innowacji. Jeśli interesuje Cię sukces na podobną

ZARZĄDZANIE PROJEKTAMI ZE SCRUM

19

skalę, ta książka jest dla Ciebie. Precyzyjnie dobrane narzędzia, techniki i porady są doskonałym drogowskazem, który pomoże Ci odnieść sukces w dostarczaniu produktów klientom. Brett Queener, starszy wiceprezes działu produktów w firmie Salesforce.com

20

SŁOWO WSTĘPNE BRETT QUEENER

Przedmowa

Na temat rozwoju oprogramowania zwinną metodą oraz zarządzania produktem napisano wiele wspaniałych książek. Jednak do dziś nie istniało wyczerpujące kompendium wiedzy na temat tego, jak funkcjonuje zarządzanie produktem w kontekście tej metodologii. Wygląda to tak, jakby praktycy zwinnej metody obawiali się podjęcia tego tematu, a eksperci zarządzania produktem wciąż głowili się nad tym, jak rozpracować ten nowy obszar. Ponieważ coraz więcej firm wykorzystuje metodę Scrum, coraz pilniejsze staje się znalezienie odpowiedzi na pytanie, jak praktykować zarządzanie produktem w procesie Scrum. Niniejsza książka próbuje odpowiedzieć na to pytanie. Kiedy po raz pierwszy zetknąłem się ze zwinnymi praktykami w 1999 roku, uderzyła mnie ścisła współpraca pomiędzy pracownikami technicznymi i biznesowymi. Wcześniej wydawało mi się, że tworzeniem oprogramowania zajmują się raczej „techniczni” niż biznesmeni. Kiedy w roku 2001 pracowałem przy moim pierwszym zwinnym projekcie jako coach, największym wyzwaniem była pomoc menedżerom produktu w przejściu do świata zwinnej metodyki. Od tamtej pory w firmach, dla których pracowałem jako konsultant, zagadnienia związane z obowiązkami właściciela produktu były dużym wyzwaniem i czynnikiem decydującym o sukcesie nie tylko samego 21

22

PRZEDMOWA

produktu, ale także metody Scrum. Oto, co mówią Chris Fry i Steve Greene [2007, 139], którzy byli odpowiedzialni za przejście do zwinnej metodologii w Salesforce.com: Na początku projektu wielu ekspertów mówiło nam, że rola właściciela projektu jest kluczowa dla sukcesu naszej zwinnej transformacji. Mimo że intuicyjnie rozumieliśmy, o co chodzi, nie wiedzieliśmy, jak wielkich zmian doświadczą właściciele produktu.

Dlaczego zwinne zarządzanie produktem jest inne od klasycznego Zwinne zarządzanie produktem oparte na procesie Scrum różni się od klasycznego podejścia na kilku płaszczyznach. Tabela P.1 w skondensowanej formie pokazuje najważniejsze różnice1. Metody zwinne, w tym Scrum, działają według starej prawdy: zmiana jest jedyną stałą. „Jeśli nawet badania przeprowadzone wewnątrz firmy nie pokazują produktu jako nieaktualnego, inne badania z pewnością to zrobią” — napisał Theodore Levitt w artykule Marketing Myopia opublikowanym w 1960 roku. Clayton M. Christensen [1997] uważa, że niszcząca innowacja pojawi się w końcu w każdej dziedzinie. Nie wiadomo tylko, jak szybko i jak często będzie się to działo. Firmy, które nie zdołają szybko się przystosować, znikną z rynku, nawet jeżeli obecnie przynoszą duże zyski. Na szczęście empiryczna natura Scruma powoduje, że jest to dobra metoda do radzenia sobie z nowością i innowacją, a także ze złożonymi sytuacjami, w których siłami dominującymi są zmiany i nieprzewidywalność. Jeśli Twoją działalność charakteryzują zmiany, Scrum będzie Twoim silnym sojusznikiem. 1

Zauważ, że wykorzystuję nazwy stanowisk Scruma używanych przez Schwabera [2009].

DLACZEGO ZWINNE ZARZĄDZANIE PRODUKTEM JEST INNE OD KLASYCZNEGO

23

Tabela P.1. Klasyczne i nowe podejście w zarządzaniu produktem Podejście klasyczne

Podejście nowe

Odpowiedzialność za powołanie produktu do życia dzielona jest pomiędzy kilka stanowisk: marketera produktu, menedżera produktu i menedżera projektu.

Jedna osoba — właściciel produktu — jest odpowiedzialna za produkt i kierowanie projektem. Więcej na temat nowej roli dowiesz się z rozdziałów 1. i 6.

Menedżerowie produktu są oddzieleni od zespołów deweloperskich: zajmują się innymi procesami, pracują w innych miejscach budynku.

Właściciel produktu jest członkiem zespołu scrumowego i ściśle współpracuje z mistrzem młyna oraz zespołem. Więcej na ten temat dowiesz się z rozdziałów 1., 3. i 5.

Przed rozpoczęciem projektu przeprowadza się szczegółowe badania rynku, planowanie produktu oraz analizę biznesową.

Prace wstępne przeprowadzane są w minimalnym zakresie i ograniczają się do stworzenia wizji, która opisuje ogólny wygląd i działanie produktu. Więcej na ten temat dowiesz się z rozdziału 2.

Definicja produktu tworzona jest przed rozpoczęciem prac: wymagania są określane i zatwierdzane na wczesnym etapie.

Produkt odkrywany jest stopniowo, wymagania krystalizują się w trakcie tego procesu. Nie istnieje definicja ani specyfikacja rynku czy produktu. Rejestr produktu jest dynamiczny, a jego elementy ewoluują na podstawie opinii klienta i użytkownika. Więcej na ten temat dowiesz się z rozdziału 3.

Opinia klientów przychodzi późno, w trakcie testów na rynku, już po wypuszczeniu produktu.

Wczesne i częste wydania oraz przeglądy sprintu generują przydatną opinię zwrotną od klientów i użytkowników, przyczyniając się do stworzenia produktu, który pokochają klienci. Więcej na ten temat dowiesz się z rozdziałów 4. i 5.

24

PRZEDMOWA

Co można znaleźć w tej książce i kto powinien ją przeczytać Ta książka przeznaczona jest dla wszystkich zainteresowanych zwinnym zarządzaniem produktem, w szczególności dla tych, którzy pracują jako właściciele produktu lub właśnie przechodzą do pełnienia obowiązków wynikających z tej roli. Książka omawia stanowisko właściciela produktu oraz niezbędne praktyki dotyczące zarządzania produktem. Należą do nich: wizja produktu, uzupełnianie rejestru produktu, planowanie i śledzenie wydań, odpowiednie wykorzystanie zebrań scrumowych oraz przejście do nowej roli. Ten przewodnik pozwala na efektywne zastosowanie zwinnych technik zarządzania produktem w metodyce Scrum. Nacisk położony jest tu na oprogramowanie — od prostych aplikacji do bardziej złożonych produktów, takich jak na przykład telefony komórkowe. To opracowanie nie jest elementarzem zarządzania produktem. Nie jest też elementarzem Scruma. Z pewnością nie jest również panaceum na problemy z zarządzaniem produktem. Tak naprawdę jest wiele aspektów zarządzania produktem, których w tej książce nie poruszyłem. W zamian za to skoncentrowałem się na koncepcjach zarządzania i praktykach charakterystycznych dla Scruma. Zakładam, że czytelnik jest obeznany z zasadami metodyki Scrum oraz posiada praktyczną znajomość zasad zarządzania produktem. Opis metodologii Scrum można znaleźć w opracowaniach Kena Schwabera i Mike’a Beedle’a [2002] oraz Schwabera [2004]. Mam nadzieję, że ta książka pomoże Ci stworzyć produkt, który pokochają klienci — produkt, który przyniesie korzyści użytkownikom i będzie rozwijany w sposób zrównoważony.

Podziękowania Ta książka swój kształt zawdzięcza wsparciu wielu osób. Najserdeczniejsze podziękowania otrzymują ode mnie wszystkie osoby (w kolejności alfabetycznej), które przeglądały gotowe rozdziały, dzieliły się swoimi opowieściami oraz służyły radą: Lyssa Adkins, Geir Amsjø, Markus Andrezak, Gabrielle Benefield, Robert Bogetti, Thomke Buhl, Marty Cagan, Sabine Canditt, John Clifford, Alistair Cockburn, Mike Cohn, Jens Coldeway, Kaustabh Debbarman, Pete Deemer, Chris Fry, Steve Greene, Roland Hanbury, Kevlin Henney, Ben Hogan, Clinton Keith, Andreas Klinger, Hans-Peter Korn, Jochen Krebs, Craig Larman, Bill Li, Lowell Lindstrom, Catherine Louis, Rodrigo Luna, Artem Marchenko, Jason Martinez, Ralph Miarka, Philip Missler, Bent Myllerup, Jeff Patton, Tobias Pichler, Brett Queener, Cesário Ramos, Dan Rawsthorne, Simon Roberts, Stefan Roock, Rene Rosendahl, Johanna Rothman, Kenneth Rubin, Martin Rusnak, Hans-Peter Samios, Bob Schatz, Andreas Schliep, Ken Schwaber, Christa Schwanninger, Karl Scotland, Martin Shaw, Lisa Shoop, James Siddle, Michele Sliger, Preston Smith, Dieter Stefanowitz, Jeff Sutherland, Mads Troels Hansen, Bas Vodde, Geoff Watts, Harvey Wheaton, Rüdiger Wolf, Elizabeth Woodward oraz Lv Yi. Jestem szczególnie wdzięczny Mike’owi Cohnowi. Jego cierpliwa pomoc i wsparcie były w trakcie pisania tej książki nie do przecenienia. Bardzo Ci dziękuję, Mike! Specjalne podziękowania kieruję do Jeffa

25

26

PODZIĘKOWANIA

Sutherlanda i Bretta Queenera za napisanie takich wspaniałych przedmów. Dziękuję też Kenowi Schwaberowi za nauczenie mnie metodologii Scrum. Jestem też dozgonnie wdzięczny mojej rodzinie. Dzięki mojej żonie, Melissie Pichler, mogłem poświęcić tej książce wystarczającą ilość czasu i uwagi, Melissa również omawiała ze mną pomysły, przeglądała kolejne rozdziały, a także pomagała w projektowaniu okładki. Dziękuję Ci, Kochanie! Dziękuję również mojemu synowi Leo oraz córce Yasmin za chodzenie wokół mnie na paluszkach, kiedy pisałem książkę. Szczególnie dziękuję pięcioletniemu Leo, który po przeczytaniu kilku linijek wyraził swoją opinię, mówiąc: „Tato, to jest dziwne”. Podziękowania przekazuję również dla Rebekki Traeger za doskonałą pracę redakcyjną oraz dla zespołu z wydawnictwa Pearson, na który złożyły się następujące osoby: Chris Guzikowski, Raina Chrobak, Sheri Cain, Anna Popick i Barbara Wood — dziękuję za ich pomoc i ciężką pracę.

O autorze

Roman Pichler jest jednym z głównych ekspertów zwinnego zarządzania produktem. Przez wiele lat uczył i trenował właścicieli produktu, pomagając firmom w efektywnym wykorzystywaniu praktyk zarządzania produktem. Oprócz tego jest autorem bestsellerowej książki Scrum — Agiles Projektmanagement erfolgreich einsetzen. Roman jest częstym gościem na międzynarodowych konferencjach. Jako certyfikowany trener Scruma brał udział w stworzeniu programu szkoleń dla certyfikowanych właścicieli produktu Scruma. Więcej informacji o autorze można znaleźć na stronie www.romanpichler.com.

27

28

O AUTORZE

Rozdział 1

Rola właściciela produktu

Pracowałem kiedyś nad nowym produktem z branży aptekarskiej, który miał zająć miejsce swojego poprzednika. Nowy system miał za zadanie przysporzyć więcej korzyści klientowi oraz przeskoczyć osiągnięcia konkurencji. Po ponad dwóch latach pracy nad rozwojem produktu został on wypuszczony na rynek, ale pokładane w nim nadzieje okazały się płonne. Co poszło nie tak? Gdzieś pomiędzy pomysłem a premierą produktu zgubiła się wizja. Dział marketingu produktu przeprowadził badanie rynku, stworzył koncepcję produktu i przekazał ją menedżerowi produktu. Menedżer produktu stworzył specyfikację wymagań, którą wręczył menedżerowi projektu, a on z kolei przekazał ją zespołom wykonawczym. Zabrakło jednej osoby odpowiedzialnej za całość wysiłków zmierzających do stworzenia dobrego produktu oraz wspólnej wizji dotyczącej jego wyglądu i działania. Każda osoba zaangażowana w projekt miała inne spojrzenie i odmienną wizję. Jak można było rozwiązać ten problem? Należało mianować jednego pracownika właścicielem produktu, czyli osobą odpowiedzialną za produkt. W tym rozdziale opowiem o stanowisku właściciela produktu, a także opiszę jego kompetencje i obowiązki oraz sposoby ich wykonywania. 29

30

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Właściciel produktu W Przewodniku po Scrumie [Schwaber, 2009, 6] Ken Schwaber pisze o właścicielu produktu jako jedynej osobie odpowiedzialnej za zarządzanie rejestrem produktu i upewnienie się, że praca wykonana przez zespół ma odpowiednią wartość. Autor podkreśla też, że właściciel produktu utrzymuje rejestr produktu i udostępnia go wszystkim zainteresowanym. Ta definicja brzmi niegroźnie, dopóki nie rozważy się związanych z nią implikacji. Właściciel produktu zarządza wysiłkami produkcyjnymi w celu stworzenia produktu i wygenerowania odpowiednich korzyści. To często polega na tworzeniu wizji produktu, porządkowaniu rejestru produktu, planowaniu wydań, angażowaniu w interakcje klientów, użytkowników i innych interesariuszy, zarządzaniu budżetem, przygotowywaniu produktu do wprowadzenia na rynek, uczestnictwie w spotkaniach scrumowych oraz współpracy z zespołem. Właściciel produktu gra kluczową rolę nie tylko w powoływaniu do życia nowych produktów, ale także w zarządzaniu ich cyklem produkcyjnym. Jedna osoba odpowiedzialna za produkt w trakcie wszystkich wydań zapewnia ciągłość projektu i redukuje potrzebę przekazywania obowiązków oraz zachęca do myślenia długoterminowego. Badania przeprowadzone w przedsiębiorstwie SAP AG ujawniły więcej korzyści: pracownicy pełniący funkcję właścicieli produktu byli bardziej pewni siebie, bardziej skłonni do wywierania wpływu, bardziej widoczni, lepiej zorganizowani oraz lepiej zmotywowani w nowej roli [Schmidkonz, 2008]. Bycie właścicielem produktu nie jest pracą indywidualną. Właściciel produktu jest częścią zespołu scrumowego i ściśle współpracuje z innymi jego członkami. Podczas gdy mistrz młyna wraz z zespołem wspierają właściciela produktu, dbając wspólnie o rejestr produktu, sam właściciel jest odpowiedzialny za upewnienie się, że wszystkie niezbędne prace zostały wykonane.

WŁAŚCICIEL PRODUKTU

31

Można pokusić się o porównanie roli właściciela produktu do ról bardziej tradycyjnych (na przykład menedżera produktu lub menedżera projektu). Żadne porównanie nie odda jednak rzeczywistości. Właściciel produktu to nowe, wieloaspektowe stanowisko, które łączy władzę i odpowiedzialność, uprzednio tradycyjnie rozdzielone pomiędzy inne osoby, w tym klienta lub sponsora, menedżera produktu i menedżera projektu. Kształt tego stanowiska jest uzależniony od kontekstu: zależy między innymi od natury produktu, etapu cyklu produkcyjnego oraz rozmiaru projektu. Na przykład właściciel produktu odpowiedzialny za nowy produkt składający się z oprogramowania i elementów mechanicznych musi posiadać inne kompetencje niż osoba pracująca nad aplikacją internetową. Podobnie właściciel produktu pracujący nad dużym projektem scrumowym będzie potrzebował innych umiejętności niż współpracujący tylko z jednym lub dwoma zespołami. W przypadku produktów komercyjnych właściciel produktu zazwyczaj reprezentuje klienta, tak jak menedżer produktu lub marketer. Prawdziwy klient przyjmuje tę rolę w sytuacji, kiedy produkt jest tworzony dla konkretnej organizacji. Może to być na przykład klient zewnętrzny, który potrzebuje nowego rozwiązania dla hurtowni danych, lub wewnętrzny (dział marketingu), zgłaszający zapotrzebowanie na aktualizację strony internetowej. Pracowałem już z klientami, użytkownikami, menedżerami biznesowymi, menedżerami produktów i projektów, analitykami biznesowymi oraz architektami, którzy z powodzeniem przyjmowali rolę właściciela produktu. Rolę tę potrafi odgrywać nawet dyrektor generalny. Za przykład może posłużyć Ript, narzędzie planowania wizualnego, które pozwala użytkownikom na wycinanie tekstu z jednej aplikacji i wklejanie go do drugiej. Oprogramowanie zostało wymyślone przez Gerry’ego Laybourna, dyrektora generalnego firmy Oxygen Media, który w trakcie prac nad pierwszym wydaniem przyjął rolę właściciela produktu [Judy, 2007].

32

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Pożądane cechy właściciela produktu Wybranie odpowiedniego właściciela produktu jest niezbędne w każdym projekcie scrumowym. Właściciele produktów, z którymi pracowałem, a którzy odnieśli sukces, mieli cechy wymienione poniżej. Właściciel produktu to nowo stworzone stanowisko, a ludzie zwykle potrzebują czasu i wsparcia w trakcie podejmowania nowych obowiązków i nabywania niezbędnych umiejętności. Zazwyczaj wyzwaniem jest znalezienie pracowników z wystarczająco dużym zasobem wiedzy i z doświadczeniem, które pozwoliłoby im dobrze wykonywać swoją pracę. Więcej na temat przejścia pracownika na nowe stanowisko i rozwijania jego umiejętności jako właściciela produktu napiszę w rozdziale 6.

Wizjoner i wykonawca Pisarz Jonathan Swift twierdził, że „wizjonerstwo jest sztuką widzenia rzeczy niewidzialnych”. Właściciel produktu jest wizjonerem, który może przewidzieć ostateczny wygląd produktu i podzielić się tą wizją. Jest on również wykonawcą, który nadzoruje prace nad tą wizją aż do ich ukończenia. Obejmują one: opis wymagań, ścisłą współpracę z zespołem, akceptację lub odrzucanie rezultatów prac oraz sterowanie projektem poprzez śledzenie i przewidywanie postępów. Jako przedsiębiorca właściciel produktu wspiera kreatywność, zachęca do wprowadzania innowacji, nie boi się zmian, dwuznaczności, dyskusji, konfliktów, żartów, eksperymentów oraz podejmowania ryzyka poprzedzonego zebraniem odpowiednich informacji.

Lider i gracz zespołowy Jack Welch, były dyrektor generalny i członek rady nadzorczej firmy GE, powiedział, że „dobry lider biznesowy potrafi stworzyć wizję, odpowiednio ją wyartykułować, odpowiadać za nią z pasją oraz być bezwzględnym w egzekwowaniu jej wdrażania”. Właśnie takim liderem

POŻĄDANE CECHY WŁAŚCICIELA PRODUKTU

33

jest właściciel produktu. Jako jednostka odpowiedzialna za sukces produktu kieruje on wszystkimi zaangażowanymi w prace i doradza im, a także upewnia się, że podejmowane są wszelkie niezbędne trudne decyzje. Przykładowo: czy data wprowadzenia produktu na rynek powinna zostać przesunięta, czy też zostanie zmniejszona liczba funkcjonalności? Właściciel produktu musi też być graczem zespołowym, ściśle współpracującym z innymi członkami zespołu scrumowego, niemającym jednak nad nimi formalnej władzy. W odniesieniu do produktu jego właściciel jest primus inter pares, pierwszym wśród równych sobie. Trudno jest zmierzyć się z dualną naturą właściciela produktu jako lidera i gracza zespołowego. Właściciel produktu w żadnym wypadku nie powinien dyktować decyzji, jednocześnie nie może być niezdecydowany lub stosować polityki wolnej ręki. Osoba taka powinna zachowywać się jak pasterz, przewodząc procesowi innowacji, nadzorując projekt i szukając konsensusu w procesie podejmowania decyzji. Wspólne podejmowanie rozwiązań dotyczących produktu zapewnia zaangażowanie zespołu, wpływa na kreatywność i wiedzę jego członków, czego rezultatem są lepsze decyzje. Praca w takim stylu wymaga cierpliwości, ponieważ członkowie zespołów często nie zgadzają się ze sobą i kłócą się, zanim ze wspólnych pomysłów stworzą nowe rozwiązanie. Więcej użytecznych informacji na temat wspólnego podejmowania decyzji oraz technik facylitacji znajdziesz w książce Sama Kanera i współautorów [1996]. Przedsiębiorczy zespół Czasem koncentrujemy się na konkretnych osobach, uważając je za niezwykłych przedsiębiorców lub wyróżniających się liderów — do takich należą Bill Gates, Steve Jobs oraz inni liderzy-celebryci. W rzeczywistości bardzo niewiele innowacji można przypisać geniuszowi pojedynczej osoby. Nawet jeżeli właścicielem produktu był ten właśnie geniusz, on też potrzebował zespołu, który powołałby pomysł do życia. Żaden geniusz przedsiębiorczości nie jest w stanie podjąć samych dobrych decyzji. Badania neurobiologiczne dowodzą, że nawet osoby o największych kwalifikacjach pracujące na najlepszym stanowisku w najlepszym możliwym

34

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

czasie podejmą złe decyzje, jeśli będą robić to same. Sydney Finkelstein i współautorzy przypisują to funkcjonowaniu ludzkiego poznania [2009]. Sugerują oni wykorzystanie choćby jednej dodatkowej osoby jako punktu odniesienia. W zespole znajdzie się zwykle wielu partnerów, na których można przetestować swoje pomysły przed podjęciem decyzji. Ed Catmull, prezes Pixaru, twierdzi [2008, 68]: Jeśli podsuniesz przeciętny pomysł świetnemu zespołowi, oni go poprawią albo wyrzucą do kosza i wymyślą coś lepszego. Mądrość wielu jest lepsza od geniuszu jednego.

Komunikator i negocjator Właściciel produktu musi być efektywnym komunikatorem i negocjatorem. Indywidualny pracownik komunikuje się między innymi z klientami, użytkownikami, programistami i inżynierami, marketerami, pracownikami działu sprzedaży, usług, eksploatacji oraz z zarządem. Właściciel produktu jest głosem klienta, komunikuje jego potrzeby i wymagania, jest także ogniwem łączącym pracowników biurowych z technologami. Czasem niezbędne jest powiedzenie stanowczego „nie”, a czasem negocjowanie kompromisu.

Inspirujący i zaangażowany Właściciel produktu musi posiadać wystarczające kompetencje i wystarczający poziom odpowiedzialności menedżerskiej, by zarządzać procesem produkcyjnym i odpowiednio komunikować się z interesariuszami. W firmie mobile.de, która jest największym niemieckim sprzedawcą samochodów, to właśnie wyższe kierownictwo wybiera właścicieli produktu, zapewnia wsparcie i zajmuje się problemami, które wymagają eskalacji. Ta bliska współpraca pozwala zespołowi kierowników na lepsze zrozumienie postępu prac w indywidualnych projektach i wczesne zamknięcie tych nierokujących sukcesu1.

1

Komunikacja prywatna z Philipem Misslerem, dyrektorem generalnym mobile.de, z 18 czerwca 2009 roku.

POŻĄDANE CECHY WŁAŚCICIELA PRODUKTU

35

Inspirujący właściciel produktu jest niezbędny, by powołać produkt do życia. Musi mieć odpowiednie kompetencje do podejmowania decyzji w całym procesie — od szukania odpowiednich członków zespołu do decydowania o tym, która funkcjonalność wejdzie w skład wydania. Właścicielem produktu musi być ktoś, komu można zaufać w sprawie budżetu i kto potrafi stworzyć atmosferę pracy sprzyjającą kreatywności i tworzeniu innowacji. Musi to być osoba zaangażowana w wysiłki produkcyjne. Właściciel produktu ma szansę odnieść sukces, jeśli jest pewien siebie, entuzjastyczny, pełen energii oraz godny zaufania.

Dostępny i wykwalifikowany Właściciel produktu, żeby dobrze wykonywać swoją pracę, musi być dostępny i posiadać odpowiednie kwalifikacje. Jest to zazwyczaj praca na pełny etat. Ważne jest, by właściciel produktu miał wystarczającą ilość czasu na wykonanie swoich obowiązków. Jeśli będzie przepracowany, ucierpi na tym postęp projektu, a produkt może nie być optymalny. Odpowiednie kwalifikacje zwykle wymagają dogłębnego zrozumienia potrzeb klienta oraz rynku, pasji dotyczącej user experience2, a także umiejętności komunikowania potrzeb i opisywania wymagań, zarządzania budżetem, prowadzenia projektu oraz poczucia komfortu w pracy z samoorganizującym się zespołem, którego członkowie mają różnorodne kwalifikacje. Właściciel produktu w firmie PatientKeeper Jeff Sutherland, współtwórca metodologii Scrum oraz były dyrektor technologiczny firmy PatientKeeper, ważnego producenta zintegrowanych systemów informatycznych dla służby zdrowia, wyjaśnia, jakie kwalifikacje powinien posiadać pracujący w tej firmie właściciel produktu.

2

User experience (z ang. doświadczenie użytkownika) to termin opisujący całość wrażeń, jakich doświadcza użytkownik podczas korzystania z produktu interaktywnego — przyp. tłum.

36

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

[Właściciel produktu] musi być ekspertem w swojej dziedzinie, najlepiej lekarzem praktykującym kilka dni w tygodniu w jednym z głównych bostońskich szpitali, inżynierem, który sam napisał kilka własnych aplikacji, specjalistą od user stories, przypadków użycia i tworzenia wymagań oprogramowania, w szczególności tych dotyczących służby zdrowia. Musi doskonale radzić sobie z klientami i sprzedawcami w kwestii egzekwowania wymagań oraz rekrutacji lekarzy-ekspertów do testowania prototypów nowych funkcjonalności, brać odpowiedzialność za biznes, dochód, stosunki z klientami i działem sprzedaży, z uwzględnieniem funkcjonalności, tworzenia user stories oraz wszystkich innych specyfikacji produktu, w tym analizy potrzeb klienta. Naszym właścicielom produktu pomagają jedynie deweloperzy oraz inni pracownicy z zespołu. Pierwsze osoby zatrudnione na tym stanowisku nie mogły sobie poradzić. Pomogły im dopiero wielokrotne szkolenia, wsparcie i znalezienie odpowiedniego kandydata3.

Praca z zespołem Jak wspomniałem wcześniej, właściciel produktu jest członkiem zespołu scrumowego i współpracuje z zespołem oraz z mistrzem młyna. Sam zespół jest niewielki, samoorganizujący się, a jego członkowie posiadają różnorodne umiejętności. Powinny być w nim reprezentowane wszelkie stanowiska, które pomogą powołać produkt do życia. Wszyscy członkowie zespołu scrumowego powinni pracować w symbiozie, tworząc zwartą i zaufaną grupę. Nie może być podziału na nich i na nas. Jesteśmy tylko my. Aby zespół scrumowy mógł rozwinąć skrzydła, należy zminimalizować wszelkie zmiany w trakcie danego wydania produktu oraz pomiędzy kolejnymi wydaniami. Aby ludzie stali się prawdziwym zespołem — takim, którego członkowie ufają sobie, wspierają się wzajemnie i pracują efektywnie — musi minąć trochę czasu. Zmiana składu zespołu powoduje konieczność rozpoczęcia procesu budowania więzi od nowa, co wpływa negatywnie na produktywność i samo3

Z postu Jeffa Sutherlanda zawierającego listę trenerów Scruma na Yahoo!, stworzonego 2 października 2008 roku, oraz na podstawie komunikacji z Jeffem z 16 grudnia 2008 roku.

PRACA Z ZESPOŁEM

37

organizację. Należy również stworzyć trwałą więź pomiędzy zespołem scrumowym a produktem. Każdy produkt powinien być rozwijany przez jeden lub kilka przypisanych do niego zespołów. To nie tylko wspomaga nauczanie, ale też upraszcza proces przydzielania do konkretnych zadań osób i zasobów. Ponieważ właściciel produktu, mistrz młyna i zespół muszą ściśle ze sobą współpracować, należy zgromadzić wszystkich w jednym miejscu. Popatrz na przykład mobile.de. Umieszczenie właścicieli produktu wraz z mistrzem młyna i resztą zespołu w jednym pomieszczeniu ma pozytywny wpływ na produktywność i morale4. Jeśli właściciel produktu nie może na stałe pracować we wspólnym pomieszczeniu z zespołem, należy pamiętać o organizacji jak największej liczby bezpośrednich spotkań. Właściciele produktu pracujący zdalnie mogą wiele zyskać, pracując razem z zespołem przez kilka dni w trakcie każdego sprintu. Właścicielom produktu pracującym w tym samym budynku, jednak w innym niż zespół pomieszczeniu sugeruję zapoznać się z zasadą jednej godziny: „Właściciele produktu powinni spędzać z zespołem w ich pokoju co najmniej jedną godzinę dziennie”. Pokój, gdzie rezyduje zespół, powinien sprzyjać kreatywnej i wspólnej pracy. Musi to być środowisko, które wspomaga komunikację i interakcję, sprawia, że praca jest przyjemna, i pozwala na prezentację kluczowych artefaktów w postaci radiatora informacji (wizja, rejestr elementów produktu o wysokim priorytecie, diagram architektury oprogramowania, rejestr sprintu oraz wykresy spalania wydania). W pokojach zespołów powinny być warunki do pracy zespołowej, prywatności oraz do pracy w małych grupach.

4

Komunikacja prywatna z Philipem Misslerem z 22 czerwca 2009 roku.

38

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Współpraca z mistrzem młyna Tak jak zespół sportowy potrzebuje trenera, by móc grać spójnie na najwyższym poziomie, tak każdy zespół scrumowy potrzebuje mistrza młyna5. Mistrz młyna wspiera właściciela produktu oraz zespół, chroni zespół i proces oraz podejmuje interwencje, aby utrzymać odpowiednie tempo pracy i upewnić się, że zespół jest zdrowy i zmotywowany oraz że nie został zaciągnięty żaden dług technologiczny6. Role właściciela produktu i mistrza młyna uzupełniają się wzajemnie: właściciel produktu jest odpowiedzialny za stworzenie odpowiedniego produktu, mistrz młyna odpowiada głównie za prawidłowe wykorzystanie metodologii Scrum. Oba aspekty przedstawia rysunek 1.1. Tylko tworzenie produktu z wykorzystaniem odpowiedniego procesu może zagwarantować sukces.

Rysunek 1.1. Wykonywanie odpowiednich działań w odpowiedni sposób

5

6

Profesjonalne zespoły rugby mają kilku trenerów, z których każdy jest odpowiedzialny za inny element gry. Dług technologiczny i odpowiednie tempo pracy omówione są szczegółowo w rozdziałach 4. i 5.

PRACA Z KLIENTAMI, UŻYTKOWNIKAMI ORAZ INNYMI INTERESARIUSZAMI

39

Ponieważ stanowiska właściciela produktu i mistrza młyna zaprojektowane są tak, by się równoważyły, zajmowanie ich obu przez tę samą osobę nie daje dobrych efektów. Ten sam pracownik nigdy nie powinien być jednocześnie mistrzem młyna i właścicielem produktu.

Praca z klientami, użytkownikami oraz innymi interesariuszami Klient, czyli osoba dokonująca zakupu produktu, i użytkownik, czyli osoba korzystająca z produktu, określają jego sukces lub porażkę. O sukcesie można mówić tylko wtedy, kiedy produkt zostanie kupiony przez wystarczającą liczbę użytkowników, a oni uznają go za przydatny. Zauważ, że klient i użytkownik mogą być różnymi osobami. Mogą nawet mieć odmienne potrzeby. Posłużę się przykładem elektronicznego arkusza kalkulacyjnego. Do potrzeb użytkowników można zaliczyć łatwość obsługi i wysoką produktywność. Natomiast firma, kupując produkt, może mieć na względzie ogólne koszty oraz bezpieczeństwo danych. Aby stworzyć udany produkt, właściciel produktu, mistrz młyna oraz zespół muszą bardzo dokładnie poznać potrzeby użytkowników oraz wiedzieć, jak najlepiej je zaspokoić. By to osiągnąć, najlepiej jest zaangażować klientów i użytkowników zarówno na wczesnym etapie procesu, jak i w jego trakcie. Doskonałą metodą uczenia się od klientów jest pytanie ich o zdanie na temat prototypów, zapraszanie wybranych osób na przegląd sprintu oraz wczesne i częste udostępnianie oprogramowania. Zespoły powinny mieć na uwadze, że produkt jest jedynie środkiem do celu, nie samym celem. Ma on pomóc klientowi i przynieść firmie oczekiwane korzyści. Jak powiedział Theodore Levitt: „Ludzie nie potrzebują ćwierćcalowego wiertła, oni potrzebują ćwierćcalowej dziury”. Najlepsze rozwiązanie możesz znaleźć tylko, jeśli skupisz się na kliencie.

40

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Właściciele produktu powinni również zaangażować innych interesariuszy, na przykład pracowników działów marketingu, sprzedaży i usług. Powinni na wczesnym etapie regularnie zapraszać ich na przeglądy sprintów. Spotkania pozwalają tym pracownikom przyjrzeć się rozwojowi produktu, wejść w interakcję z zespołem scrumowym oraz dzielić się wątpliwościami i pomysłami, a także zadawać pytania. John M. Bryson [2004] podaje przegląd technik pomocnych w identyfikacji i analizie interesariuszy. Marketer produktu a menedżer projektu Niektóre firmy oddzielają od siebie strategiczne i taktyczne aspekty zarządzania produktem, zatrudniając osobnych pracowników na stanowiskach marketera produktu i (technicznego) menedżera projektu. Działania marketera produktu wychodzą na zewnątrz. Jego głównym zajęciem jest poznawanie rynku, tworzenie mapy produktu oraz dbanie o skumulowane zyski ze wszystkich wydań. Działania menedżera projektu skupione są zaś na wewnętrznych aspektach zarządzania produktem i koncentrują się wokół szczegółowych opisów funkcjonalności, ustalania priorytetów oraz współpracy z zespołem deweloperskim. W metodologii Scrum to właściciel produktu bierze na siebie wszystkie te obowiązki. Podczas wykonywania prac związanych z zarządzaniem produktem właściciel produktu może otrzymać wsparcie od menedżera portfolio, wiceprezesa lub nawet samego dyrektora generalnego, w zależności od wielkości firmy oraz wagi projektu. Po pomoc związaną z wyceną i komunikacją marketingową właściciel produktu może się zwrócić do marketera produktu i do starszych sprzedawców. W sprawach technicznych pomóc mogą mistrz młyna oraz zespół. Połączenie dwóch aspektów zarządzania produktem na jednym stanowisku powoduje zwiększenie autorytetu i odpowiedzialności. Unika się w ten sposób przekazywania obowiązków innym osobom, oczekiwania i opóźnień, a także problemów z komunikacją i pomyłek. Zapewne zauważyłeś, że nie wspomniałem o roli menedżera projektu w zespole scrumowym. Powód jest następujący: obowiązki menedżera projektu nie są już wykonywane przez jedną osobę. Zostały podzielone pomiędzy innych członków zespołu scrumowego. Na przykład właściciel produktu jest odpowiedzialny za zarządzanie zakresem i datą wydania, budżetem, informowanie o postępach i kontakt z interesariuszami. Zespół zajmuje się identyfikacją, zarządzaniem i określaniem czasu realizacji zadań. Menedżer projektu jest w tej sytuacji zbędny. Nie oznacza to, że osoby pełniące funkcję menedżerów projektu są już niepotrzebne.

SKALOWANIE ROLI WŁAŚCICIELA PRODUKTU

41

Wręcz przeciwnie. Byli menedżerowie projektu są zazwyczaj doskonałymi mistrzami młyna. Znam również zakończone sukcesem przypadki przyjęcia przez menedżerów projektu roli właściciela produktu.

Skalowanie roli właściciela produktu Zanim opiszę praktyki stosowane przez właścicieli produktu w dużych projektach scrumowych, chciałbym Cię ostrzec: unikaj dużych projektów. Zacznij od niewielkich i szybko stwórz produkt o minimalnej funkcjonalności, jak zostało to pokazane w rozdziale 2. Jeśli projekt musi być duży, skaluj go ostrożnie, powoli dodając po jednym zespole. Zaczynanie projektu ze zbyt dużą liczbą osób powoduje zbytnie skomplikowanie produktu, sprawiając, że przyszłe aktualizacje będą czasochłonne i drogie7.

Główny właściciel produktu Duże projekty w metodologii Scrum składają się z wielu małych zespołów. Każdy zespół potrzebuje właściciela produktu, ale jeden właściciel produktu może opiekować się niewielką liczbą zespołów. To, ile zespołów powinno znajdować się w pieczy właściciela produktu, nie powodując jego przemęczenia lub zaniedbywania obowiązków, zależy od kilku czynników. Należą do nich: świeżość produktu, poziom jego skomplikowania oraz znajomość tematu wśród członków zespołu. Moje doświadczenie podpowiada, że właściciel produktu zwykle nie jest w stanie w sposób odpowiedzialny zajmować się więcej niż dwoma zespołami jednocześnie. Jeśli jest więcej zespołów, potrzebna będzie współpraca kilku właścicieli produktu. Powstaje dylemat: właściciel produktu to jedna osoba, ale w przypadku dużego projektu 7

Pogląd ten został uchwycony w pozycji Conway’s Law [Conway, 1968]. Mówi on o tym, że struktura organizacji rozwijającej produkt wpływa na architekturę samego produktu. Jeśli początkowo przy projekcie pracują trzy zespoły, najprawdopodobniej architektura produktu będzie się składała z trzech głównych podsystemów.

42

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Scruma potrzeba kilku właścicieli. Rozwiązaniem jest mianowanie jednej osoby, która zajmie się kreowaniem i implementacją wizji produktu. W ten sposób wprowadzisz hierarchię współpracujących właścicieli produktu, z głównym właścicielem produktu na czele. Struktura jest podobna do tej w kuchni restauracyjnej, gdzie kilku kucharzy pracuje razem pod przewodnictwem jednego8. Główny właściciel produktu (ang. Chief Product Owner) jest liderem pozostałych. Dba on o to, by potrzeby i wymagania były konsekwentnie przekazywane zespołom, a postęp całego projektu był optymalny. Umożliwia również wspólne podejmowanie decyzji, zachowując prawo do ostatniego słowa w przypadku niemożności osiągnięcia porozumienia. Jeśli projekt z jednego zespołu rozrasta się do wielu, wtedy pierwszy właściciel produktu zostaje głównym właścicielem produktu.

Hierarchia właścicieli produktu Hierarchia właścicieli produktu będzie inna dla małego zespołu z głównym właścicielem produktu na czele, a inna dla złożonej struktury z kilkoma poziomami współpracujących właścicieli produktu. Przyjrzyj się obu opcjom, zaczynając od tej prostszej. Organizacja projektu opisanego na rysunku 1.2 składa się z trzech zespołów i trzech właścicieli produktu. Każdy właściciel produktu zajmuje się jednym zespołem. Właściciele produktu tworzą osobny zespół, a pracownik B pełni funkcję głównego właściciela produktu. Mimo że istnieje główny właściciel produktu, hierarchia jest płaska. Oto przykład, jak zastosować takie rozwiązanie: jeden z moich klientów zatrudnia zespół właścicieli produktu odpowiedzialnych za portal i aplikacje. Czterech właścicieli produktu oraz główny właściciel produktu ściśle ze sobą współpracują. Każdy z nich zajmuje się osobną aplikacją. 8

Najwyższy w strukturze właściciel produktu nie zawsze nazywany jest „głównym właścicielem produktu”. Ken Schwaber używa określenia „ogólny właściciel produktu” [2007], a Craig Larman i Ben Vodde nazywają go po prostu „właścicielem produktu” [2009].

SKALOWANIE ROLI WŁAŚCICIELA PRODUKTU

43

Rysunek 1.2. Prosta hierarchia właścicieli produktu

Główny właściciel produktu zajmuje się całym produktem, czyli portalem wraz z aplikacjami. Rysunek 1.3 przedstawia odpowiednią dla większych projektów scrumowych opcję, opartą na rozwiązaniu zaczerpniętym ze Schwabera [2007, 70 – 73]. Organizacja projektu częściowo przedstawiona na rysunku 1.3 składa się z czterech warstw oraz dziewięciu właścicieli produktu9. Każdy właściciel produktu wspiera kolegów z niższych zespołów. Właściciel produktu z najwyższego poziomu jest głównym właścicielem produktu, odpowiedzialnym za cały projekt oraz za sukces produktu. Struktura właścicieli produktu jest teraz dość rozbudowana. Należy zauważyć, że złożona struktura powoduje, iż poszczególni właściciele produktu wykonują określone obowiązki. Główny właściciel produktu jest odpowiedzialny za prace nad projektem oraz za koordynację współpracy z klientami i innymi interesariuszami. Właściciele

9

Schwaber [2007, 71] sugeruje, żeby każdy właściciel produktu był częścią zintegrowanego zespołu scrumowego, razem z mistrzem młyna oraz członkami zespołu. Każdy zintegrowany zespół scrumowy wspiera zespoły znajdujące się niżej w hierarchii. Na rysunku 1.3 zintegrowany zespół scrumowy „Gry” wspiera zespoły „Tetris” oraz „Szachy”.

44

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Rysunek 1.3. Złożona hierarchia właścicieli produktu

produktu niższego rzędu są bardziej skupieni na przydzielonych im funkcjonalnościach lub podsystemach i ściśle współpracują z zespołami programistów. Schwaber [2007, 72] zauważa, że: Właściciel produktu planuje, układa, dystrybuuje i śledzi pracę wykonywaną na poziomie swoim oraz na wszystkich poniższych. Im wyższy poziom, tym trudniejsza jest praca właściciela produktu. Przejęcie odpowiedzialności za pracę na poziomie produkcyjnym zazwyczaj wymaga piastowania stanowiska wiceprezesa lub dyrektora.

SKALOWANIE ROLI WŁAŚCICIELA PRODUKTU

45

Wybór odpowiednich właścicieli produktu Znalezienie odpowiedniej osoby, która mogłaby odgrywać rolę właściciela produktu, jest wyzwaniem w przypadku, gdy potrzebujesz tylko jednej osoby. Jak wybrać odpowiednich właścicieli produktu dla dużych projektów? W odpowiedzi na to pytanie pomaga poznanie różnych metod tworzenia struktur zespołów pracujących przy dużych projektach. Istnieją dwa sposoby organizacji zespołów pracujących nad przyrostami produktu: jako zespół tworzący właściwości lub jako zespół tworzący komponenty [Pichler, 2008; Larman i Vodde, 2009]. Zespół tworzący właściwości ma za zadanie implementację spójnego zestawu wymagań, takich jak motywy lub właściwości. Rezultatem jest element przecinający wszystkie główne warstwy architektury oprogramowania. Zespół tworzący komponenty pracuje nad komponentami lub podsystemami. Struktura wszystkich zespołów jest ortogonalna: zespoły tworzące właściwości zorganizowane są wokół rejestru produktu, a zespoły tworzące komponenty wokół architektury oprogramowania. Wszystkie zespoły mają wady i zalety. Zespoły tworzące komponenty odpowiedzialne są za integralność architektoniczną oraz możliwość ponownego wykorzystania. Niestety, zazwyczaj nie są w stanie wykorzystać rejestru produktu wyrażonego w formie user stories lub w formie przypadków użycia, ponieważ potrzebują dokładnych wymagań technicznych. Muszą również zintegrować wyniki pracy, by powstał przyrost produktu. W ten sposób generowane są koszty. Zespoły tworzące właściwości mogą natomiast pracować równolegle. Napotykają mniej problemów z integracją i mogą korzystać z wymagań zawartych w rejestrze produktu. Wyzwaniem może być natomiast integralność architektoniczna oraz możliwość ponownego wykorzystania. Praktyczna zasada mówi, że organizacje powinny wykorzystywać zespoły tworzące właściwości zawsze, kiedy to możliwe, a zespoły tworzące komponenty tylko, jeśli to konieczne. Ponieważ właściciel produktu zespołu tworzącego komponenty musi pomóc w tłumaczeniu rejestru produktów na język techniczny, naj-

46

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

lepszy do pełnienia tej funkcji będzie architekt lub starszy programista, a nie menedżer produktu. Jeśli projekt składa się z trzech zespołów tworzących właściwości oraz z jednego zespołu tworzącego komponenty, do odegrania ról właścicieli produktu potrzebnych jest trzech menedżerów produktu i jeden architekt, zakładając, że jeden z właścicieli produktu będzie głównym właścicielem produktu.

Powszechne błędy Wprowadzenie roli właściciela produktu dla wielu organizacji oznacza wejście na nowy grunt. Ale droga do efektywnego zarządzania produktem usiana jest przeszkodami. Ta część rozdziału pomoże Ci uniknąć najbardziej powszechnych błędów.

Właściciel produktu o zbyt małych uprawnieniach Projekt zarządzany przez właściciela produktu o zbyt małych uprawnieniach jest jak samochód ze zbyt słabym silnikiem: samochód jedzie, ale kiedy droga staje się wyboista, robi to z trudnością. Właściciel produktu o zbyt małych uprawnieniach nie ma odpowiedniego autorytetu. Powodów może być kilka: menedżerowie nie poświęcają właścicielowi produktu wystarczająco dużo uwagi, sponsoring pochodzi z niewłaściwego źródła lub od niewłaściwej osoby, zespół menedżerów nie ufa w pełni właścicielowi produktu lub z trudem zgadza się na to, by ktoś inny podejmował decyzje. W konsekwencji właściciel produktu walczy o to, by efektywnie wykonywać swoją pracę, by odpowiednio zgrać zespół scrumowy, interesariuszy i klientów lub by wykluczyć pewne wymagania z kolejnego wydania. Właściciel produktu, z którym pracowałem nad nowym produktem, musiał każdą poważniejszą decyzję konsultować ze swoim przełożonym, szefem linii biznesowej. Nic dziwnego, że powodowało to opóźnienia i podkopywało zaufanie zespołu. Należy upewnić się, że właściciel produktu posiada wystarczające uprawnienia, a także wsparcie i zaufanie odpowiednich osób.

POWSZECHNE BŁĘDY

47

Przepracowany właściciel produktu Przepracowanie nie tylko jest niezdrowe i prowadzi do braku równowagi na poziomie prywatnym. Przepracowany właściciel produktu szybko staje się słabym ogniwem, które spowalnia postęp projektu. Do symptomów przepracowania u właściciela produktu należą: zaniechanie dbania o rejestr produktu, opuszczanie spotkań dotyczących planowania sprintów i przeglądu sprintów, nieodpowiadanie na pytania lub odpowiadanie z dużym opóźnieniem. Przepracowany właściciel produktu stoi w sprzeczności z koncepcją odpowiedniego tempa pracy zawartą w Manifeście Agile. „Procesy zwinnej metodyki promują zrównoważony rozwój. Sponsorzy, deweloperzy i użytkownicy powinni mieć możliwość utrzymania stałego tempa pracy przez cały czas trwania projektu” [Beck i in., 2001]. Istnieją dwa główne powody przeciążenia właściciela produktu: niewystarczająca ilość czasu na wykonanie obowiązków oraz niewystarczające wsparcie ze strony zespołu. Jeżeli właściciel produktu pełni również inne funkcje w organizacji lub zajmuje się zbyt wieloma produktami albo zespołami, problemem może być dostępność. Niewystarczające wsparcie ze strony zespołu wynika z błędnego zrozumienia roli właściciela produktu: mimo że jest on jeden, większość pracy wykonywana jest przez zespół. Zespół i mistrz młyna muszą wspierać właściciela produktu. Aby uniknąć sytuacji, w której właściciel produktu jest przepracowany, spróbuj następującej metody: najpierw uwolnij właściciela produktu od wszystkich dodatkowych obowiązków. Zacznij od założenia, że właściciel produktu pełni swoje obowiązki w pełnym wymiarze godzin oraz że może zajmować się tylko jednym produktem i jednym zespołem. Następnie upewnij się, że zespół w każdym sprincie przeznacza odpowiednią ilość czasu na współpracę z właścicielem produktu. Metodologia Scrum przydziela do 10% czasu zespołu w każdym sprincie na wspieranie właściciela produktu [Schwaber, 2007]. Współpraca nie tylko rozkłada pracę na większą liczbę pracowników, ale także wykorzystuje kolektywną wiedzę i kreatywność zespołu.

48

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Właściciel produktu o podzielonych obowiązkach Niektóre organizacje rozdzielają obowiązki właściciela produktu pomiędzy kilku pracowników, zatrudniając na przykład menedżera produktu oraz właściciela produktu. Menedżer produktu zajmuje się marketingiem produktu oraz wszelkimi aspektami zarządzania produktem, jest właścicielem wizji, jego działania są skierowane na zewnątrz i trzyma on rękę na pulsie rynku. Właściciel produktu kieruje swoje działania do wewnątrz, podtrzymuje zespół na duchu i współpracuje z nim. W takim wypadku osoba nazywana właścicielem produktu jest zaledwie pracownikiem zajmującym się rejestrem produktu. To podejście wzmacnia stare podziały, rozmywa odpowiedzialność oraz powoduje częstsze przekazywanie obowiązków, opóźnienia i inne straty. Zamiast rozdzielać obowiązki właściciela produktu pomiędzy kilku ludzi, organizacje powinny podjąć wyzwanie zorganizowania tego stanowiska w odpowiedni sposób. Za strategiczne i taktyczne aspekty zarządzania produktem powinna być odpowiedzialna jedna osoba. Może to oznaczać zmiany organizacyjne, w tym dostosowywanie stanowisk i ścieżek kariery oraz rozwój osobisty nastawiony na pełnienie wielu obowiązków, co opisuję w rozdziale 6.

Odległy właściciel produktu Odległy właściciel produktu pracuje z dala od zespołu. Odległość może przywoływać na myśl globalizację, kiedy właściciel produktu pracuje na jednym kontynencie, a zespół na drugim. Praca na odległość może też odbywać się na różnych poziomach. Zaczyna się od pracy w tym samym budynku, lecz w różnych pomieszczeniach, a kończy na tym, że właściciela produktu i zespół dzielą kontynenty i strefy czasowe [Simons, 2004]. W przypadku właścicieli produktu znajdujących się w odległych miejscach mogą pojawić się problemy, w tym: brak zaufania, zła komunikacja, błędy w przydzielaniu obowiązków oraz powolny postęp. Powód jest następujący: „Najbardziej wydajną i efektywną metodą przenoszenia informacji pomiędzy członkami zespołu programistycznego jest osobista rozmowa” [Beck i in., 2001].

POWSZECHNE BŁĘDY

49

Unikaj pracy z odległymi właścicielami produktu i umieść cały zespół scrumowy w jednym miejscu. Jak już wspominałem, firma mobile.de doświadczyła poważnego wzrostu morale i produktywności po tym, jak umieściła właściciela produktu, mistrza młyna oraz zespół w tym samym miejscu. Jeśli taka opcja nie jest możliwa, właściciel produktu powinien spędzać w jednym pomieszczeniu z zespołem tyle czasu, ile to tylko możliwe. Zdalni właściciele produktu powinni pojawiać się w firmie przynajmniej na czas planowania sprintu, jego przeglądu czy też spotkań retrospektywnych. Tranzyt od zdalnego właściciela produktu do pracownika w budynku firmy zajmuje dużo czasu. Może to oznaczać, że będziesz musiał zatrudnić i wyszkolić lokalnego właściciela produktu. W niektórych przypadkach konieczne może być również przemyślenie strategii produktu, a także przeorganizowanie miejsca pracy.

Zastępczy właściciel produktu Zastępczy właściciel produktu to osoba pracująca w zastępstwie za właściciela produktu przypisanego do projektu. Zastępczy właściciel produktu zazwyczaj zastępuje przepracowanego, odległego lub częściowego właściciela produktu. W firmie jednego z moich klientów wiceprezes menedżerów produktu został poproszony o przyjęcie stanowiska właściciela produktu w projekcie ważnym dla całej firmy. Mimo że doskonale nadawał się na to stanowisko, miał problem z wygospodarowaniem odpowiedniej ilości czasu dla zespołu. W jego zastępstwie często występował analityk biznesowy. Zastępca właściciela produktu wykonywał większość obowiązków właściciela produktu, nie posiadając jednak jego uprawnień. Właściciel produktu decydował ostatecznie o nadawaniu priorytetów elementom rejestru produktu, planowaniu wydań oraz o akceptacji lub odrzuceniu rezultatów pracy. Wynikiem takiego rozwiązania był wzrost liczby konfliktów, problemy z komunikacją, spowolnienie procesu podejmowania decyzji oraz spadek produktywności i obniżenie morale.

50

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Korzystanie z usług zastępczego właściciela produktu to próba sztucznego opanowania problemów systemowych. Zamiast stosowania prowizorycznych rozwiązań organizacje powinny skupić się na zasadniczych kwestiach. Może to oznaczać zwolnienie właściciela produktu z innych obowiązków, umieszczenie go w jednym pokoju z resztą zespołu oraz mistrzem młyna albo znalezienie nowego właściciela produktu.

Komitet właścicieli produktu Komitet jest grupą właścicieli produktu, w której nikt nie zarządza całością produktu. Nie ma jednej osoby prowadzącej grupę, pomagającej w osiągnięciu wspólnego celu czy też ułatwiającej podejmowanie decyzji. Komitet właścicieli produktu może być zagrożony koniecznością nieustannych spotkań, konfliktami interesów i polityki firmowej. W ten sposób nie osiąga się żadnych postępów, a ludzie zamiast współpracować, walczą ze sobą. Upewnij się, że odpowiedzialna za produkt jest zawsze jedna osoba: ogólny właściciel produktu, który wspiera innych właścicieli produktu i ułatwia podejmowanie decyzji, w tym dotyczących priorytetów rejestru produktu oraz planowania wydań.

Spostrzeżenia Rola właściciela produktu jest podstawą odpowiedniego zastosowania zwinnego zarządzania produktem w metodologii Scrum. Czasy, w których samotny menedżer produktu głowił się w odosobnieniu nad stworzeniem idealnego zestawu wymagań, dawno już minęły. Właściciel produktu jest członkiem zespołu scrumowego i jako taki jest zobowiązany do ciągłej i ścisłej współpracy. W odpowiednim przygotowaniu stanowiska właściciela produktu pomogą Ci odpowiedzi na poniższe pytania.

SPOSTRZEŻENIA

51

Kto w Twojej organizacji reprezentuje klientów i użytkowników? Kto identyfikuje i opisuje potrzeby klientów oraz funkcjonalności produktów? Kto przewodzi czynnościom dotyczącym kreowania wizji, a kto wprowadza te wizje w życie? Jakie znaczenie ma praca zespołowa i wspólne podejmowanie decyzji? Co należałoby zrobić, by wprowadzić stanowisko właściciela produktu w sposób opisany w tym rozdziale?

52

ROZDZIAŁ 1. ROLA WŁAŚCICIELA PRODUKTU

Rozdział 2

Tworzenie wizji produktu

We wczesnych latach 90. przeprowadzanie konferencji telefonicznych nie należało do przyjemności. Uczestnicy musieli odwracać głowy od stołu i krzyczeć do mikrofonu. Kiedy kilka osób mówiło jednocześnie, ich głosy mieszały się i rozmowa zamieniała się w bełkot. Polycom, firma specjalizująca się w tworzeniu rozwiązań telekomunikacyjnych oraz wideo, a także służących do dzielenia się treścią, uznała, że jej klienci chcą, by telekonferencje wyglądały bardziej jak rozmowy bezpośrednie — bez zakłóceń, echa i zniekształceń. Polycom miała wizję produktu, który zawierałby następujące atrybuty [Lynn i Reilly, 2002, 63]: ■ doskonałą jakość dźwięku, pozwalającą na jednoczesną rozmowę kilku osób bez zakłóceń; ■ łatwość obsługi, bez dużej liczby guzików i przewodów; ■ doskonały wygląd, dobrze prezentujący się w głównej sali konferencyjnej. Na tej podstawie w 1992 roku powstał produkt nazwany SoundStation. Kamieniem milowym na drodze do sukcesu tego produktu była wizja. W tym rozdziale omówię techniki tworzenia wizji produktu. Zacznę od treści i jakości efektywnej wizji produktu. 53

54

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Wizja produktu „Czy nie zechciałbyś mi powiedzieć, którędy mam teraz iść?” — pyta Alicja Kota w powieści Lewisa Carrolla Alicja w Krainie Czarów. „To zależy w dużym stopniu od tego, gdzie chcesz dojść” — odpowiada Kot. „Właściwie to wszystko mi jedno” — mówi Alicja. „W takim razie obojętne, którędy pójdziesz” — stwierdza Kot z Cheshire1. Umiejętność stworzenia wizji tego, jak ma wyglądać i działać nowy produkt (lub następna jego wersja), jest niezbędna do odniesienia sukcesu. Wyobrażanie sobie produktu prowadzi do stworzenia jego wizji — jego szkicu2. Wizja jest nadrzędnym celem, pobudzającym zaangażowanych ludzi i wprowadzającym ich w projekt, oraz sensem istnienia produktu. Podobnie jak w przypadku Polycomu wizja opisuje produkt selektywnie, na poziomie ogólnym, koncentrując się na jego esencji, czyli informacjach niezbędnych do stworzenia i wypuszczenia na rynek udanego produktu. Do walidacji i dopracowania produktu przyczynia się prezentowanie jego przyrostów klientom i użytkownikom w trakcie przeglądów przebiegu, a także częste i wczesne wypuszczanie oprogramowania. Efektywna wizja powinna odpowiadać na poniższe pytania. ■ Kto kupi produkt? Kto jest docelowym klientem? Kto będzie wykorzystywał produkt? Kim są docelowi użytkownicy? ■ Jakie oczekiwania będzie spełniał produkt? Jaką wartość daje? ■ Które atrybuty produktu są niezbędne, by oczekiwania zostały spełnione, a produkt odniósł sukces? Jak mniej więcej będzie 1

Lewis Carroll, Alicja w Krainie Czarów, przeł. R. Stiller, Warszawa 1986, s. 52 — przyp. tłum.

2

Mimo że wizja produktu nie jest częścią struktury Scruma, wspominają o niej Schwaber i Beedle [2002, 34]. Ken Schwaber pisze również o wizji w swojej książce Agile Project Management with Scrum: „Wizja opisuje przyczyny powstania projektu oraz oczekiwany rezultat” [2004, 68].

POŻĄDANE CECHY WIZJI

55

wyglądał produkt i do czego będzie służył? W jakich obszarach produkt będzie się wyróżniał? ■ Gdzie plasuje się produkt w konfrontacji z tymi już istniejącymi, tworzonymi zarówno przez konkurencję, jak i wewnętrznie? Jakie są unikatowe cechy produktu? Jaka jest docelowa cena produktu? ■ W jaki sposób firma będzie zarabiać na sprzedaży produktu? Jakie będą źródła dochodu oraz model biznesowy? ■ Czy stworzenie produktu jest wykonalne? Czy firma jest w stanie stworzyć i sprzedać produkt? Jeśli zamierzasz wykorzystać nowy produkt jako trampolinę do zmiany modelu biznesowego, musisz zawrzeć te informacje w wizji. Spójrz na przykład produktów iPod i iTunes firmy Apple. Apple zdominowała rynek muzyki cyfrowej dzięki stworzeniu dobrego produktu, jakim był iPod, wraz z doskonałym modelem biznesowym. Ścisła integracja iPoda z iTunes, sklepem muzycznym online stworzonym przez firmę, nie tylko umożliwia wygodny zakup muzyki przez internet, ale także przywiązuje do siebie klientów. W ten sposób Apple zmieniła zasady gry, sprzedając muzykę po niższych cenach. Firma nie zarabia dużo na samej muzyce, ale krocie na odtwarzaczach MP3. Wizja stworzona dla iPoda z pewnością zawierała wymóg bezproblemowej integracji ze sklepem iTunes, natomiast wizja dla iTunes odwoływała się do modelu biznesowego oraz dodatkowego przychodu uzyskiwanego dzięki sprzedaży iPodów.

Pożądane cechy wizji Wizja powinna przekazywać esencję produktu w sposób zwięzły oraz opisywać wspólny cel, który wyznacza kierunek, a jednocześnie jest wystarczająco szeroki, by zostawić miejsce dla kreatywności.

56

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Wspólna i jednocząca Wszyscy zaangażowani w rozwój produktu — zespół scrumowy, kierownictwo, klienci, użytkownicy oraz inni interesariusze — powinni zgadzać się z kształtem wizji. Peter Senge powiedział: „Wizja jest wspólna tylko wtedy, kiedy wszyscy mają podobny jej obraz oraz zobowiązują się do wzajemnego, nie tylko indywidualnego zaangażowania” [2006, 192]. Wspólna wizja tworzy podwaliny współpracy oraz dopinguje wszystkich w wysiłku tworzenia. Pomaga w efektywnej pracy zespołowej i umożliwia wspólne uczenie się. „Kiedy ludzie naprawdę dzielą wspólną wizję, są ze sobą połączeni, związani wspólnymi aspiracjami” [Senge, 2006, 192]. Jeżeli członkowie zespołu mają swoje prywatne wizje, każdy idzie w swoją stronę, zamiast podejmować wysiłki w kierunku osiągnięcia jednego celu. Doskonałym sposobem na dzielenie wspólnej wizji jest zaangażowanie zespołu scrumowego i interesariuszy w czynności związane z jej tworzeniem.

Obszerna i angażująca Wizja produktu powinna opisywać obszerny i angażujący cel: taki, który kieruje tworzeniem, a jednocześnie zostawia wystarczająco dużo miejsca na kreatywność, a także angażuje i inspiruje pracowników. Marissa Mayer, wiceprezeska odpowiedzialna za wyszukiwarkę oraz user experience w Google’u, mówi o tym, jak Google wpływa na wizję. Nasze zespoły składają się z ludzi, którzy naprawdę pasjonują się danym tematem. Uważam, że to jest interesujące: u nas wciąż nie tworzy się bardzo szczegółowych specyfikacji produktu. Jeśli napiszesz 70-stronicowy dokument opisujący produkt, nie zostawiasz już miejsca na kreatywność. Inżynier powie: „Słuchaj, jest jedna właściwość, na której mi zależy, a którą Ty pominąłeś”. Nie powinieneś usuwać z produktu pierwiastka kreatywności. Podejście oparte na porozumieniu członków zespołu, którzy wspólnie tworzą wizję produktu,

POŻĄDANE CECHY WIZJI

57

zostawiając jednocześnie miejsce na wkład kreatywny, jest bardzo inspirujące i prowadzi do fantastycznych osiągnięć3. Musisz oprzeć się pokusie tworzenia zbyt szczegółowych specyfikacji produktu. Znacznie więcej funkcjonalności można odkryć i zapisać w rejestrze produktu już w trakcie prac nad projektem.

Krótka i zwięzła W przypadku wizji produktu mniej znaczy więcej. Wizja powinna być krótka i treściwa. Powinna zawierać jedynie informacje niezbędne dla sukcesu produktu. Najlepsze produkty opisane w opracowywanym przez dziesięć lat studium Gary’ego S. Lynna i Richarda R. Reilly’ego mają nie więcej niż sześć atrybutów każdy [2002]. Wizja produktu nie jest więc listą właściwości, nie powinna też zawierać niepotrzebnych szczegółów. Ekspert zwinnego zarządzania projektem Jim Highsmith wyjaśnia: „Wymyślenie piętnastu czy dwudziestu cech lub właściwości produktu wydaje się łatwe. Wybranie trzech lub czterech takich, które mogłyby nakłonić kogoś do kupienia produktu, jest trudne” [2009, 97]. Ekspert rozwoju produktu Donald Reinertsen zgadza się z tą tezą, mówiąc: „Produkty, które odniosły największy sukces, mają jasne i proste propozycje wartości. Kupujący zazwyczaj wybiera jeden spośród wielu produktów, kierując się trzema lub czterema kluczowymi czynnikami” [1997, 174 – 175]. Wizja produktu jest zwięzła, jeśli przejdzie test windy stworzony przez Geoffreya A. Moore’a. „Czy jesteś w stanie w czasie jednego przejazdu windą wyjaśnić, do czego służy Twój produkt?” [2006, 152]. Jeśli odpowiedź brzmi „nie”, wizja jest najprawdopodobniej za długa lub zbyt skomplikowana.

3

Inside Google’s New-Product Process, BusinessWeek.com, www.businessweek.com/ technology/ content/jun2006/tc20060629_411177.htm, data dostępu: 30 czerwca 2006 roku.

58

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Minimalna wersja produktu nadająca się do wypuszczenia na rynek Aby stworzyć wizję, zespół scrumowy musi zerknąć w przyszłość i opisać, jak ich zdaniem będzie wyglądał i zachowywał się nowy produkt. Dla każdego, kto nie jest obdarzony takimi zdolnościami, będzie to wyjątkowo trudne. W końcu jedyną pewną rzeczą dotyczącą przyszłości jest to, że jest ona niepewna. Żadna technika badania rynku nie stworzy stuprocentowo oczywistej prognozy. Niemożliwa jest również całkowicie bezpieczna inwestycja. Robert G. Cooper podaje, że liczba niepowodzeń dotyczących nowego produktu kształtuje się w granicach 25 – 45% [2001, 10], niektóre badania podają nawet wyższe prawdopodobieństwo porażki. Rozwoju rynku nie da się przewidzieć, tak jak i reakcji klientów, co pokazuje poniższa historia4. Kiedy firma Expertcity w 1999 roku wypuściła interaktywny system wsparcia technicznego, wszyscy byli pełni nadziei. Badania rynku sugerowały, że produkt odniesie sukces. Niestety, okazało się, że nie dostarczał on tego, czego oczekiwała firma. Zauważono jednak, że użytkownicy wykorzystywali część produktu, umożliwiającą współdzielenie pulpitu komputera, w zupełnie nowy, nieoczekiwany sposób. Klienci używali tej funkcjonalności do zdalnego administrowania komputerami. Firma podjęła odpowiednie kroki i szybko dokonała adaptacji produktu, przetwarzając go w narzędzie do zdalnego administrowania. Zmodyfikowany produkt nazwano GoToMyPC. Odniósł on taki sukces, że w 2003 roku koncern Citrix postanowił dokonać przejęcia Expertcity za 225 milionów dolarów. GoToMyPC jest teraz częścią pakietu Citrix 4

Precyzja w przewidywaniu odpowiedzi rynku uzależniona jest od jego dynamiki oraz stopnia innowacyjności produktu. Dla stałych rynków i produktów o stałym lub przyrostowym stopniu innowacyjności określenie reakcji rynku wydaje się możliwe. Dla innych rynków i produktów jest to trudne, a nawet niemożliwe, tak jak w przypadku innowacji wprowadzanych z zakłóceniami. Christensen [1997,143] twierdzi: „Rynki, które nie istnieją, nie mogą zostać poddane analizie”.

MINIMALNA WERSJA PRODUKTU NADAJĄCA SIĘ DO WYPUSZCZENIA NA RYNEK

59

Online. Oryginalna wizja produktu Expertcity mogła być niewłaściwa, ale umiejętności adaptacyjne umożliwiły firmie przekształcenie ewidentnej porażki w zdecydowany sukces. Ponieważ nasza możliwość przewidywania przyszłości jest ograniczona, największą szansą na sukces jest stworzenie minimalnej wersji produktu nadającej się do wypuszczenia na rynek, czyli produktu z minimalną liczbą funkcjonalności, który spełnia oczekiwania wybranych klientów5. Przyjrzyj się iPhone’owi, wypuszczonemu na rynek w 2007 roku. Niezrównane user experience tego telefonu rozłożyło na łopatki konkurencję, wprowadzając nowe standardy dla smartfonów. Jednym z sekretów jego sukcesu jest wąski zestaw potrzeb klientów, na których skoncentrowała się Apple. Firma nie starała się zadowolić zbyt dużej liczby ludzi jednocześnie, nie kopiowała też właściwości wprowadzanych przez konkurencję, unikając w ten sposób wpadnięcia w pułapkę. Zamiast tego Apple spojrzała świeżym okiem na to, jak powinny wyglądać oraz zachowywać się smartfony, i umyślnie pominęła pewne funkcjonalności. Pierwsza wersja iPhone’a weszła na rynek bez właściwości, które standardowo pojawiały się w wielu innych markach telefonów, takich jak: kopiowanie i wklejanie, możliwość wysyłania wiadomości do wielu odbiorców czy też pakiet rozwoju oprogramowania. Te ograniczenia nie były jednak przeszkodą w osiągnięciu sukcesu. Ograniczenie funkcjonalności pozwoliło firmie Apple na rozwinięcie i wprowadzenie do sprzedaży produktu znacznie szybciej, a także umożliwiło wyprzedzenie konkurencji. Opierając się na sukcesie pierwszej wersji iPhone’a, Apple w 2008 roku wypuściła na rynek model 3G, rozszerzając możliwości oprogramowania telefonu. 5

Termin „minimalna wersja produktu nadająca się do wypuszczenia na rynek” odnosi się do pracy Marka Denne’a oraz Jane Cleland-Huang. W książce Software by Numbers [2004] po raz pierwszy wykorzystali oni termin „minimalny zestaw właściwości nadających się do wypuszczenia na rynek”, by ustalić minimalną liczbę funkcjonalności, która tworzy wartość dla klienta. Pomysł szybkiego dostarczania minimalnego zestawu właściwości i ulepszania produktu w kolejnych przyrostach oparty jest na ewolucyjnej metodzie produkcji Toma Gilba [Gilb, 1988].

60

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Jednocześnie firma weszła na nowy segment rynku, obierając sobie za cel użytkowników biznesowych. Sukces iPhone’a można przeciwstawić historii innego produktu firmy Apple: Apple Newton, który ujrzał światło dzienne w 1993 roku, po pięciu latach prac nad rozwojem. Pamiętasz reklamy Apple’a obiecujące palmtopa, który będzie dokonywał cudów oraz rozpoznawał Twój charakter pisma? Kiedy Newton został w końcu wypuszczony na rynek, okazał się ciężki i nieporęczny. Co gorsza, jego najważniejsza funkcjonalność, czyli rozpoznawanie pisma odręcznego, nie działała prawidłowo. Produkt nie spisywał się dobrze i został w końcu (w 1998 roku) wycofany z rynku. Z perspektywy czasu można ocenić, że Apple zbyt ambitnie podeszła do realizacji planów związanych z Newtonem. Firma wypuściła produkt, który próbował zrobić zbyt wiele i poległ. Stworzenie minimalistycznego produktu ma wiele zalet, co udowadniają Preston G. Smith i Donald G. Reinertsen [1998] oraz Denne i Cleland-Huang [2004]6. Produkt wypuszcza się szybciej, redukując czas niezbędny do jego wejścia na rynek. Koszty stworzenia produktu są niższe, a zwrot z inwestycji większy. Płatności otrzymywane są wcześniej, co poprawia przepływ gotówki, a proces uczenia się zostaje przyspieszony. Dzięki redukcji czasu potrzebnego do wprowadzenia produktu na rynek, zamiast zgadywać potrzeby rynku, jesteś w stanie się w nie wsłuchać i częściej na nie odpowiadać. Sprawne wprowadzenie na rynek produktu o minimalnych funkcjonalnościach łagodzi również ryzyko porażki. Jeżeli produkt nie odniesie sukcesu i trzeba będzie go wycofać z rynku, straty finansowe będą mniejsze. Dzięki temu jesteś w stanie uwzględnić porażkę w swojej strategii, postępując podobnie do Google’a. Marissa Mayer z tej firmy wyjaśnia: „Przewidujemy, że wiele naszych produktów pójdzie do kosza, ale ludzie zapamiętają te, które naprawdę mają znaczenie i potencjał”7. 6

Smith i Reinertsen [1998] nazywają technikę rozbijania innowacji na mniejsze, szybsze etapy innowacją przyrostową.

7

So Much Fanfare, So Few Hits, BusinessWeek.com, www.businessweek.com/magazine/ content/06_28/b3992051.htm, data dostępu: 10 lipca 2006 roku. Art Fry z 3M zauważa,

PROSTOTA

61

Ze względu na to, że przyszłość jest niepewna, wizja powinna uwzględniać następne wersje produktu. Nawet jeżeli dalekosiężnym marzeniem Steve’a Jobsa była dominacja na rynku telefonów komórkowych, nie był to cel dla pierwszego iPhone’a. Wielkie ambicje najlepiej realizować metodą małych kroków. „Jest tylko jeden ruch, który naprawdę się liczy: ten następny” [Gilb, 1988, 97]. Kiedy wizja jest już stworzona, należy przekształcić ją w produkt gotowy do wypuszczenia na rynek, biorąc pod uwagę opinie klientów i użytkowników. Opinie są zbierane w trakcie prezentowania przyrostów produktu w trakcie przeglądów sprintu oraz poprzez częste i wczesne wypuszczanie nowych wersji oprogramowania. W ten sposób zespół scrumowy może szybko przekonać się, czy produkt, nad którym pracuje, jest właściwy. Jeśli nie, wizja jest nieodpowiednia i musi zostać zmieniona. Pamiętaj, że wizja może zostać wdrożona w trakcie kilku wydań. Przyjrzyj się przykładowi pierwszej wersji przeglądarki Google Chrome. Oficjalną wersję 1.0, wprowadzoną w grudniu 2008 roku, poprzedziły wydania niepubliczne oraz wersja beta z września 2008 roku. Plany dotyczące rozwoju produktu można zawrzeć w mapie produktu tak, jak to opisuję w dalszej części tego rozdziału.

Prostota Przy tworzeniu produktu o minimalnej funkcjonalności, który będzie łatwy w użyciu, należy kierować się prostotą. Nie można jednak mylić prostoty z uproszczonym produktem. Jak powiedział Leonardo da Vinci, „prostota jest najwyższą formą wyrafinowania”.

że podobne podejście przedstawia motto „musisz pocałować wiele żab, zanim odnajdziesz swojego księcia”. Przystojny książę będzie wynagrodzeniem za wszystkie żaby.

62

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Brzytwa Ockhama Kierowanie się prostotą to metoda o długiej tradycji. W XIV wieku franciszkański mnich William Ockham postulował, by spośród dwóch rozwiązań o porównywalnych funkcjonalnościach wybierać zawsze to prostsze [Lidwell i in., 2003, 142]. Ta zasada zwana jest brzytwą Ockhama. Prostota nie dotyczy tylko estetyki produktu. Chodzi o esencję, tworzenie wyłącznie tego, co jest niezbędne, oraz o łatwe udoskonalanie i rozbudowę produktu. Prosty, a jednocześnie odpowiedni produkt jest łatwy w użyciu — tak jak iPod firmy Apple. Jego nawigacja oparta na kole z przyciskami jest minimalistyczna, ale zapewnia niezbędne funkcje. Kent Beck i Cynthia Andres twierdzą: „Projekty dążące do prostoty usprawniają zarówno aspekt ludzki, jak i produktywność oprogramowania” [2005, 110].

Mniej znaczy więcej Zdrowy rozsądek zdaje się sugerować, że aby pokonać konkurencję, należy stworzyć lepszy produkt z wieloma funkcjonalnościami. Zazwyczaj uważa się, że więcej właściwości oznacza lepszą jakość i większe zapotrzebowanie na produkt. Firma 37Signals [2006], produkująca wielokrotnie nagradzane, łatwe w użyciu aplikacje internetowe, twierdzi, że nie. Swoje produkty tworzy z zachowaniem zasad prostoty, koncentrując się na niezbędnych aspektach. Aby pokonać konkurencję, rób mniej. Zmniejsz o połowę liczbę funkcjonalności, które uważasz za niezbędne. Zacznij od eleganckiej, odchudzonej aplikacji i pozwól jej nabrać rozpędu. Później możesz dodawać nowe funkcjonalności do solidnych fundamentów. John Maeda — ekspert tworzenia według zasad prostoty, a także profesor MIT — pisze: „Najprostszym sposobem osiągnięcia prostoty jest redukcja. Jeśli masz wątpliwości co do określonego elementu, usuń go” [2006, 1]. Steve Jobs powiedział: „W innowacji nie chodzi o zgadzanie się na wszystko. Należy zgadzać się jedynie na niezbędne ele-

PROSTOTA

63

menty”. Manifest Agile podziela to spostrzeżenie, uznając prostotę za jedną ze swoich 12 zasad i nazywając ją „sztuką maksymalizowania pracy niewykonanej” [Beck i in., 2001]. Kiedy przyjdzie Ci do głowy pomysł na nową właściwość lub odkryjesz nowe wymaganie, zadaj sobie pytanie, czy nowa funkcjonalność jest niezbędna do odniesienia przez produkt sukcesu. Jeśli nie jest, zapomnij o niej. Rezultatem będzie prosty, czytelny produkt, oferujący tylko te właściwości, których potrzebuje klient lub użytkownik.

Prosty interfejs użytkownika Google jest jedną z firm, która celowo przyjmuje prostotę jako główną zasadę user experience. „Google nie tworzy produktów bogatych w funkcjonalności, nasze najlepsze projekty zawierają tylko te właściwości, których użytkownicy potrzebują, by osiągnąć swój cel. Staramy się, żeby nawet produkty, które wymagają dużych zestawów właściwości oraz skomplikowanego projektu wizualnego, wyglądały zarówno na proste, jak i skuteczne. Chcemy, by nasze produkty ewoluowały w nowych kierunkach, zamiast po prostu zwiększać liczbę funkcjonalności”8. Projektowanie prostych interfejsów opłaciło się Google’owi, jak twierdzą William Lidwell i współautorzy: „Podczas gdy inne wyszukiwarki internetowe prześcigały się w dodawaniu do swoich stron usług reklamowych oraz innych doraźnych funkcji, Google pozostał przy prostym i wydajnym wyglądzie. Rezultatem jest najlepiej działająca i najprostsza w obsłudze wyszukiwarka w sieci” [2003, 143]. Bernard Girard, autor książki The Google Way [2009, 34], pisze, że to prostota pomogła AdWords, programowi reklamowemu Google’a, odnieść sukces. Podobnie jak intuicyjny interfejs graficzny Macintosha, dzięki któremu produkty Apple są przyjazne użytkownikowi i łatwe w użyciu, projekt graficzny i przyjazność interfejsu Google AdWords sprawia, 8

Ten principles that contribute to a Googley user experience, www.google.com/corporate/ux.html.

64

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

że produkt ten odnosi taki sukces. Każdy reklamodawca z łatwością może nauczyć się, jak zamieścić reklamę.

Potrzeby klientów i atrybuty produktu Potrzeby klientów i atrybuty produktu są w wizji najważniejsze i potrzebują zwiększonej uwagi. Wybranie odpowiednich potrzeb klienta informuje o tym, jaki rynek lub jego segment będzie Cię interesował. Skupiając się na potrzebach, patrzysz na produkt jak na środek do celu, którym jest służenie klientowi lub użytkownikowi. Atrybuty produktu to z kolei najważniejsze właściwości, jakie musi mieć produkt, by spełniać te potrzeby. Ekran dotykowy to przykład atrybutu produktu. Potrzebą, z której wynika, będzie najprawdopodobniej łatwość obsługi. Atrybuty dzielą się na funkcjonalne i niefunkcjonalne. Cechy funkcjonalne to specyficzne funkcje lub właściwości produktu, jak na przykład możliwość wykonywania lub przyjmowania połączeń telefonicznych. Do atrybutów niefunkcjonalnych należą: wydajność, solidność, styl, wygląd i użyteczność. Atrybuty niefunkcjonalne bywają istotnym czynnikiem różnicującym — mogą one wpływać na doświadczenie użytkownika oraz elastyczność i możliwość utrzymania produktu, które z kolei mają znaczenie dla kosztów produkcji, a także dla długości życia produktu. Atrybuty służą zespołowi jako drogowskaz, ograniczając liczbę możliwych rozwiązań. Poprzez werbalizację potrzeb klientów i stworzenie szczegółowego minimalnego zestawu atrybutów produktu jesteś w stanie połączyć potrzeby z rozwiązaniami technicznymi, stawiając klienta w centrum swoich prac produkcyjnych. Odseparowanie potrzeb od atrybutów pozwala Ci na jednoczesne sprawdzenie, dlaczego produkt jest niezbędny oraz jak powinien wyglądać i co powinien robić. Możesz w ten sposób przetestować różne atrybuty i sprawdzić, które z nich pasują najlepiej. Na przykład ekran dotykowy jest tylko jednym

POTRZEBY KLIENTÓW I ATRYBUTY PRODUKTU

65

ze sposobów zapewnienia łatwości obsługi. Tańszą alternatywą może być mała liczba dużych guzików lub system kontroli głosowej. Po zidentyfikowaniu atrybutów produktu należy ustalić priorytety. Atrybuty spełniające kilka potrzeb są najważniejsze i powinny uzyskać najwyższy priorytet. Ustalenie priorytetów jest szczególnie przydatne, kiedy atrybuty wchodzą ze sobą w sprzeczność. Weź pod uwagę dwa następujące atrybuty: interoperacyjność i sprawność. Możliwość współdziałania z różnymi systemami i urządzeniami zazwyczaj wymaga wysokiego poziomu złożoności architektonicznej. Sprawność z kolei sugeruje zastosowanie architektury prostej i elastycznej. W rezultacie powstaje napięcie — właściciel produktu, mistrz młyna oraz zespół muszą w sposób kreatywny pogodzić elementy nie do pogodzenia i znaleźć najlepsze możliwe rozwiązanie, które spełnia potrzeby klientów. Alistair Cockburn [2005, 147] doradza wykorzystanie następujących czynników ułatwiających ustalanie priorytetów dla atrybutów produktu: ■ poświęć inne dla tego; ■ postaraj się go zatrzymać; ■ poświęć ten dla innego. Aby nadać sprawności wyższy priorytet niż interoperacyjności, musiałbyś poświęcić dla sprawności inne atrybuty. Jednocześnie starałbyś się zatrzymać interoperacyjność. Zestaw papierowych kart jest przydatnym, prostym i tanim narzędziem do ustalania potrzeb i atrybutów. Karty wspomagają pracę grupową, pozwalają na wprowadzanie adnotacji i poprawek. Można je grupować, wieszać na ścianie, przestawiać. Po zakończeniu prac nad wizją można przykleić je do kartonu i powiesić w pokoju zespołu, a kopię umieścić w dokumentacji projektu.

66

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Narodziny wizji Na wczesnym etapie prac każdy produkt otaczają mity i legendy. Nie istnieje idealny przepis na pomysł i stworzenie z niego wizji. W tej części rozdziału omówię dwa podejścia do stworzenia wizji nowego produktu: projekty osobiste i scrumowe. Bez względu na wszystko ogranicz pracę nad wizją do minimum i szybko wypuść pierwszy przyrost produktu lub zaprezentuj go klientom i użytkownikom. Posłuchaj ich opinii i zobacz, czy obrałeś dobry kierunek. Następnie dostosuj się. Wstrzymaj się również z obejmowaniem prac nad wizją zbyt dużą kontrolą i rozbudowanymi procedurami, inaczej zdusisz innowację i kreatywność, a pracownicy będą spędzali czas, wypełniając formularze.

Wykorzystanie projektów osobistych W firmach takich jak Google deweloperzy zachęcani są do poświęcenia 20% czasu pracy na projekty osobiste. Te prywatne projekty badawcze są źródłem nowych pomysłów przekształcanych w prototypy. Rezultaty uzasadniają inwestycje Google’a: połowa produktów wypuszczonych przez Google na rynek w ciągu ostatnich sześciu miesięcy 2005 roku powstała w ramach projektów osobistych [Mayer, 2006]. Deweloperzy, którzy wymyślili projekt, pracują nad nim aż do wypuszczenia na rynek, jak było w przypadku przeglądarki Chrome. Ben Goodger i Darin Fisher, inżynierowie, którzy wymyślili prototyp, odegrali ważną rolę w procesie rozwoju przeglądarki [Levy, 2008]9. Schwaber [2007, 80] najbardziej ceni sobie następujące podejście do rozwoju nowych pomysłów. Zalecam, aby każdy z pracowników mógł przeznaczyć część swojego czasu pracy na aktywności, które nie mają związku z pracą zespołów 9

Projekt przeglądarki Google był prowadzony przez menedżera produktu Briana Rakowskiego [Levy, 2008].

NARODZINY WIZJI

67

scrumowych, a jednocześnie przynoszą zyski przedsiębiorstwu. Na te czynności powinno zostać przeznaczone 20% czasu. Ludzie powinni łączyć się w grupy wedle zainteresowań i pracować razem. Część tego czasu może być poświęcona wspólnym działaniom pracowników dotyczącym utrzymania i wzmocnienia ekspertyzy funkcjonalnej. Można też pracować nad badaniem i prototypowaniem nowych pomysłów. Żółte przyklejane karteczki firmy 3M oraz Gmail firmy Google powstały właśnie w ten sposób.

Wykorzystanie metodologii Scrum Jeśli stworzenie wizji wymaga większego wysiłku, wykorzystaj do tego metodologię Scrum. Poproś właściciela produktu, mistrza młyna oraz zespół o przeprowadzenie działań niezbędnych dla stworzenia wizji. Całości powinien przewodzić właściciel produktu. Na początku rejestr produktu będzie zawierał elementy wizji, które muszą zostać dostarczone, na przykład „Prototypy testujące projekty interfejsu użytkownika są dostępne” oraz „Przeprowadzanie wywiadów z klientami”. W miarę postępów w pracy rejestr produktów wypełni się atrybutami wyższego rzędu, opisującymi przyszły produkt zgodnie z jego wizją. W każdym sprincie stworzony zostanie przyrost, który o krok przybliży projekt do realizacji wizji, a w konsekwencji do stworzenia gotowego produktu. Jeżeli do stworzenia wizji wystarczy tylko jeden sprint, jego rezultatem będzie wizja. Przyjrzyj się przykładowi Supermassive Games, studia produkującego gry z siedzibą w Wielkiej Brytanii. Firma wykorzystuje sprinty wizyjne do zarządzania wstępnymi pracami deweloperskimi, zwanymi „preprodukcją”. Zespół tworzy szkice i prototypy, które w kolejnych iteracjach przybliżają produkt do wizji produkowanej gry. Prototypy budowane są przy użyciu klocków Lego, rysunków koncepcyjnych i oprogramowania10.

10

Komunikacja osobista z Harveyem Wheatonem, dyrektorem Supermassive Games, z 21 października 2009 roku oraz 2 listopada 2009 roku.

68

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Zespół scrumowy, który przeprowadza prace nad wizją, powinien również pracować nad tworzeniem produktu. Od tej reguły jest kilka wyjątków. W niektórych przypadkach zespół do pracy przy sprintach wizyjnych może zatrudnić specjalistów, na przykład projektantów user experience lub przedstawicieli działu usług. Kiedy wizja będzie gotowa, specjaliści mogą odłączyć się od zespołu i zostać interesariuszami.

Techniki tworzenia wizji W tej części rozdziału przyjrzysz się technikom przydatnym w tworzeniu wizji produktu. Nie będą one wyczerpujące ani dogłębnie opisane. Moim zamiarem jest zapewnienie Ci wystarczającej ilości informacji, żebyś mógł ocenić, które z tych technik przydadzą się w Twoim projekcie. Należą do nich: prototypy i makiety, tworzenie scenariuszy i person, wykorzystanie studiów przypadku i user stories, sekwencjonowanie i scenopisy, opakowania poglądowe i recenzje, a także model Kano.

Prototypy i makiety Na początku nowego projektu często nie zdajesz sobie sprawy, o czym jeszcze nie wiesz. Co gorsza, Twoi klienci i główni użytkownicy często sami również nie zdają sobie sprawy ze swojej niewiedzy. Nie są w stanie z góry powiedzieć Ci, jak produkt ma wyglądać i jak się zachowywać. Tworzenie wizji jest więc procesem odkrywania, pozyskiwania wiedzy i uczenia się, co wymaga eksperymentów. Eksperyment bada związki przyczynowo-skutkowe, dokonując manipulacji do momentu, kiedy zostanie osiągnięty pożądany efekt. Chodzi zarówno o kultywowanie otwartego, dociekliwego i swawolnego umysłu, jak i o rygorystyczne przestrzeganie zasad przeprowadzania procesu. Kluczem do efektywnego eksperymentowania jest szybkie wygenerowanie niezbędnej wiedzy poprzez implementację oraz testowanie prototypów i makiet. Są to generatory nauki i wiedzy. Pomagają w zrozumieniu

TECHNIKI TWORZENIA WIZJI

69

ogólnego wyglądu i sposobu działania produktu, rodzajów technologii i architektury, które mogą zostać wykorzystane, oraz w określeniu, czy pomysł jest możliwy do zrealizowania. Prototypy są zazwyczaj artefaktami jednorazowego użytku, które można stworzyć szybko i tanim kosztem. Papierowe prototypy i szkice często wystarczają do przetestowania pomysłu. Możliwe do wykonania prototypy dotyczące konkretnego zagadnienia nazywane są również „ostrzami”. Jeden z projektów komunikacyjnych, przy których pracowałem, musiał spełnić ambitne wymagania dotyczące użyteczności. Badanie rynku wykazało, że produkty firmy były postrzegane jako mniej przyjazne użytkownikowi niż produkty konkurencji. Zespół stworzył więc prototyp składający się z makiety urządzenia i jednorazowej implementacji Flasha przedstawiającej krytyczne elementy interfejsu użytkownika. Klienci zostali poproszeni o przetestowanie prototypu, a ich opinię dołączono do projektu. W rezultacie powstał nowy produkt o ulepszonym user experience.

Persony i scenariusze Dzięki personom możesz wybrać odpowiednią grupę klientów. Scenariusze pozwalają Ci zaś zrozumieć, w jaki sposób produkty zmieniają ich życie [A. Cooper, 1999]. Persona to „hipotetyczny archetyp” reprezentujący docelowego klienta lub użytkownika. Jest ona wyobrażeniem konkretnego człowieka lub sytuacji. Persony mają imiona. Ich opisy zawierają informacje odnoszące się do sposobu wykorzystywania przez nie produktu, na przykład stanowiska pracy, umiejętności, zainteresowania. Zaplanuj, wykonaj, sprawdź i działaj Zorganizowane eksperymenty są następnym krokiem po czterostopniowym procesie zwanym cyklem Deminga. Najpierw tworzysz hipotezę (planujesz). Następnie dokonujesz jej walidacji (wykonujesz) oraz sprawdzasz rezultaty. Jeśli eksperyment był nieudany, modyfikujesz hipotezę (jeżeli jest to konieczne) i powtarzasz eksperyment, by dopracować rezultat lub wypróbować inne podejście (działasz). Tomasz Edison, twórca pierwszej komercyjnej żarówki elektrycznej,

70

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

był świadom konieczności dokonywania prób i popełniania błędów, by powołać do życia nowy produkt. Jego słynne powiedzenie brzmiało: Nie poniosłem porażki. Po prostu odkryłem dziesięć tysięcy błędnych rozwiązań. Nie jestem zniechęcony, ponieważ każdy błąd jest kolejnym krokiem naprzód.

Po znalezieniu odpowiednich person sprawdzasz, jak produkt, nad którym pracujesz, wpłynie na ich życie. Aby to zrobić, musisz wymyślić scenariusze opisujące sposób osiągnięcia przez personę celu przy użyciu produktu i bez niego. W tym celu tworzysz dwie mapy konsumpcyjne: jedną dla aktywności niezbędnych do realizacji celu bez użycia produktu oraz drugą, przy użyciu produktu [Womack i Jones, 2005]. Wykorzystując scenariusze i mapy konsumpcyjne, możesz określić, czy wybrane atrybuty są niezbędne. Czy przynoszą one korzyści wszystkim personom? Czy jesteś w stanie bardziej zidentyfikować niezbędne atrybuty?

Opakowania poglądowe i recenzje w prasie branżowej Opakowanie poglądowe i recenzja w prasie branżowej to dwie efektywne techniki określające wartość dodaną produktu oraz walory sprzedażowe. Opakowanie poglądowe to makieta pudełka, w którym sprzedawany będzie produkt. W celu stworzenia takiego opakowania zespół scrumowy musi wybrać nazwę produktu, jego graficzną reprezentację oraz trzy punkty, które przyczynią się do sprzedaży produktu. Te informacje są następnie umieszczane z przodu opakowania. Więcej szczegółów można dodać na tylnej ściance pudełka [Highsmith, 2009, 96 – 97]. Aby stworzyć recenzję w prasie branżowej, członkowie zespołu scrumowego muszą określić, co sami chcieliby przeczytać na temat produktu [Cohn, 2009, 232]. Ćwiczenie to jest szybkie i proste do zrealizowania. Można je także wykorzystać jako test sprawdzający, czy występuje wspólna i przez wszystkich zrozumiała wizja produktu.

TECHNIKI TWORZENIA WIZJI

71

Model Kano Model Kano pomaga w wyborze najlepszej funkcjonalności, na podstawie której zostanie stworzony atrakcyjny produkt [Kano, 1984]. Wskazuje on prawdopodobny poziom satysfakcji klienta po wprowadzeniu danego atrybutu. Model ten rozróżnia trzy typy funkcji: podstawowe, wydajnościowe oraz uszczęśliwiające. Aby zrozumieć model Kano, przyjrzyj się temu, jak działa telefon komórkowy. Do podstawowych funkcji telefonu komórkowego można zaliczyć: możliwość jego włączenia i wyłączenia, przyjmowanie i wykonywanie połączeń, a także tworzenie, wysyłanie, otrzymywanie i odczytywanie wiadomości tekstowych. Te elementarne funkcje są niezbędne, by sprzedać produkt, ale szybko wywołują w klientach stagnację zadowolenia. Przykładowo: dodanie kolejnego przycisku włączającego i wyłączającego telefon nie doda mu wartości. Brak podstawowych funkcjonalności powoduje, że produkt jest bezużyteczny. Funkcje wydajnościowe prowadzą do linearnego wzrostu satysfakcji. Rządzą się one zasadą „im więcej, tym lepiej”. Im lżejszy będzie telefon i im szybciej będzie się włączał, tym bardziej usatysfakcjonowani będą klienci. Klienci nigdy nie przestają mieć wymagań wydajnościowych. Nie są one jednak wystarczające, by wyróżnić produkt na rynku. Funkcjonalności uszczęśliwiające, jak sama nazwa wskazuje, uszczęśliwiają i ekscytują klientów. Atrakcyjny wygląd produktu oraz możliwość personalizowania ustawień są przykładami takich właśnie funkcjonalności. Elementy uszczęśliwiające mogą się odnosić do ukrytych potrzeb klienta — takich, których on sam nie jest świadom. To właśnie te funkcjonalności zapewniają przewagę konkurencyjną oraz walory sprzedażowe. Wyzwanie polega na takim połączeniu atrybutów podstawowych, wydajnościowych i uszczęśliwiających, by pożądane korzyści zostały zmaksymalizowane. Pamiętaj, że dobrze jest zastosować model Kano zarówno na etapie tworzenia wizji, jak i rejestru produktu. Podobnie jak w przypadku SoundStation, od której omawiania rozpocząłem ten rozdział, wizje zazwyczaj skupiają się na atrybutach wydajnościowych

72

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

i uszczęśliwiających, nie uwzględniając podstaw. Te z kolei znajdziesz w rejestrze produktów. Zauważ, że model Kano podaje interesujące prognozy: z czasem atrybuty uszczęśliwiające staną się wydajnościowymi, a wydajnościowe podstawowymi. Produkty tracą na konkurencyjności. Aby wciąż być na szczycie, firmy powinny dokonywać regularnych aktualizacji produktów oraz dostarczać nowe funkcjonalności uszczęśliwiające. Ta korelacja jest kolejnym powodem potwierdzającym konieczność szybkiego wypuszczenia pierwszej wersji produktu i rozwijania go za pomocą regularnych aktualizacji.

Wizja i mapa produktu W tym rozdziale dotychczas koncentrowałem się na dużym wyzwaniu, jakim jest wizja nowego produktu. W miarę dojrzewania produktu i wypuszczania nowych aktualizacji wysiłek wkładany w wizję zmniejsza się. Ale nowe wersje produktu również potrzebują celu. Mapa produktu pozwala zespołowi scrumowemu na ujęcie celów kolejnych wersji produktu. Na tym etapie wizja przeistacza się w tworzenie i aktualizowanie mapy produktu. Mapa produktu to artefakt służący do planowania, który pokazuje ewolucję produktu w nowych wersjach, wspomagając dialog pomiędzy zespołem scrumowym i interesariuszami. Mapa ułatwia organizacjom koordynację rozwoju i dat wypuszczania na rynek powiązanych ze sobą produktów, na przykład całego portfolio lub linii produktów. Mapa powinna być prosta i ograniczona do najważniejszych elementów. Każda wersja powinna mieć przypisaną datę wypuszczenia na rynek, segment klientów oraz ich potrzeby, a także trzy do pięciu najważniejszych właściwości. Nie przejmuj się szczegółami. Dla nich znajdzie się miejsce w rejestrze produktu. Pamiętaj, że mapa produktu nie może zastąpić śledzenia reakcji rynku na produkt i wprowadzania niezbędnych zmian. Mapa powinna przedstawiać Twoje wyobrażenia na temat ewolucji produktu oparte na obecnym stanie rynku. Jest to żyjący dokument, który rozwija się i zmienia.

MINIMALNA WERSJA PRODUKTU I WARIANTY PRODUKTU

73

Kiedy produkt zostanie z sukcesem wprowadzony na rynek, stwórz dla niego mapę. Tworzenie pięcioletniego harmonogramu produktu jeszcze zanim pierwsze wydanie trafi na rynek, nie przyniesie korzyści. Będzie to odzwierciedlenie wyobrażeń zamiast planu opartego na rzeczywistości. Do tworzenia harmonogramu zaangażuj wszystkich niezbędnych pracowników. Należą do nich: zespół scrumowy, osoba odpowiedzialna za portfolio produktów, reprezentanci innych zespołów deweloperskich, a także interesariusze. Upewnij się, że Twoja mapa zawiera realistyczne plany. Opierając się na stanie rynku i aktualnym etapie cyklu życiowego produktu, zaplanuj następne sześć do dwunastu miesięcy zamiast dwóch do trzech lat.

Minimalna wersja produktu i warianty produktu W miarę funkcjonowania produktu może on odpowiadać na coraz większą liczbę potrzeb klientów, na przykład poprzez docieranie do różnych segmentów i regionów rynku. Zaspokajanie zróżnicowanych potrzeb sprawia, że tworzenie aktualizacji z minimalną wymaganą liczbą funkcjonalności jest bardzo trudne. Aby wesprzeć wciąż rosnącą liczbę klientów i użytkowników, potrzebnych jest coraz więcej funkcjonalności. Żeby rozwiązać ten problem, możesz posiłkować się wariantami produktów. Każdy wariant skierowany jest do specyficznej grupy i segmentu rynku. Spójrz na przykład Visio, popularnego programu do wizualizacji firmy Microsoft. Edycja z 2007 roku dostępna jest w dwóch wariantach: Office Visio Standard 2007 oraz Office Visio Professional 2007. Pierwszy z nich służy jako „podstawowe narzędzie wizualizacyjne”, podczas gdy wersja dla profesjonalistów rozszerza wariant Visio Standard 2007, „pomagając firmom IT oraz użytkownikom biznesowym w wizualizowaniu, analizie oraz komunikowaniu

74

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

złożonych informacji, systemów i procesów”11. Dwa warianty służą różnym segmentom rynku: użytkownikom domowym i przedsiębiorcom o ograniczonych potrzebach diagramowania oraz specjalistom wymagającym zaawansowanych funkcjonalności planistycznych. Warianty produktu przynoszą korzyści, pamiętaj jednak, że jeśli jest ich zbyt wiele, mogą nadmiernie rozbudować portfolio produktu, zwiększyć koszty wsparcia, a także przytłoczyć klientów. Wyobraź sobie, co by było, gdyby Microsoft oferował cztery wersje Office Visio 2007: Essentials, Standard, Professional oraz Deluxe. Konsumenci byliby zdezorientowani zbyt dużym wyborem i mieliby problemy z podjęciem decyzji o zakupie12. Istnieje jeszcze jedna potencjalna niedogodność: warianty produktu oznaczają, że niektóre funkcjonalności trzeba będzie implementować kilka razy, co spowoduje zwiększenie kosztów związanych ze stworzeniem i utrzymaniem produktu. Rozwiązaniem jest utworzenie zestawu zasobów, z których korzystałyby warianty. Te zasoby zwane są platformą. Na przykład iPhone i iPod Touch firmy Apple zawierają wspólne komponenty. Kiedy już przekonasz się o konieczności wykorzystywania wspólnych elementów, uważaj, by nie wpaść w pułapkę stworzenia perfekcyjnej, gigantycznej platformy. Zacznij od niewielkiej. Rozbudowuj platformę naturalnie, w miarę pojawiania się zapotrzebowania na kolejne warianty, i pilnuj jej funkcjonalności. Rezultatem takiego podejścia będzie refaktoryzacja architektury, która jednak obniża niebezpieczeństwo zbytniej ingerencji inżynieryjnej w platformę.

11

Zobacz http://office.microsoft.com.

12

Zauważ, że w późnych latach 90. Microsoft oferował trzy edycje Visio: Standard, Pro oraz Tech. Od tego czasu firma uprościła portfolio.

POWSZECHNE BŁĘDY

75

Powszechne błędy Stworzenie wizji produktu jest niezbędne, by można go było wypuścić na rynek. Uważaj, aby w trakcie tworzenia wizji nie popełnić żadnego z powszechnych błędów, do których należą: brak określonej wizji, tworzenie wizji profetycznych, paraliż analityczny, absolutne przekonanie o tym, co jest najlepsze dla klientów, oraz pogląd, że duże jest piękne.

Brak określonej wizji Oczywistym, lecz zadziwiająco częstym błędem jest rozpoczęcie prac nad produktem bez określonej wizji. Zdarza się to głównie wtedy, gdy klienci zgłaszają zapotrzebowanie na konkretne właściwości, które zostają włączone do produktu, lecz nie są poddane weryfikacji. W rezultacie powstaje produkt nazywany „funkcjonalną zupą” [DeMarco i in., 2008, 143 – 45]. Unikaj tych antywzorców, upewniając się, że dostępna wizja w sposób jasny opisuje klientów, ich wybrane potrzeby oraz krytyczne atrybuty. Taka wizja pomoże określić, które właściwości powinny zostać zaimplementowane, oraz przyczyni się do powstania użytecznego i wartościowego produktu.

Tworzenie wizji profetycznych Mimo że to wizja rysuje obraz przyszłego produktu, te wyobrażenia mogą się nigdy nie spełnić. Przetwarzanie wizji w produkt jest przedsięwzięciem niosącym ze sobą ryzyko porażki. Pamiętasz, jak wizja firmy Expertcity przekształciła się w produkt, który nie spełniał oczekiwań? Nawet jeśli wizja istnieje, porażka może się wydarzyć. Jednak tak jak w przypadku Expertcity porażka może być kamieniem milowym na drodze do sukcesu. GoToMyPC powstał przecież na podstawie nieudanego pierwszego wydania. Aby zminimalizować potencjalne straty lub szkody spowodowane niedokładnymi prognozami, wybierz niewielki zestaw potrzeb klientów i doprowadź do szybkiego wydania przyrostu produktu. Następnie dokonaj inspekcji i adaptacji.

76

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Paraliż analityczny Jak już wspomniałem wcześniej, nie należy przesadzać z przeprowadzaniem wstępnych badań rynku. Trzeba także uważać, by nie wpaść w pułapkę paraliżu analitycznego, czyli przeprowadzania coraz większej liczby badań, które nie przyczyniają się do postępu prac. Zbyt wnikliwe przeprowadzanie badań rynku nie tylko powoduje stratę czasu i pieniędzy, ale także niesie ze sobą niebezpieczeństwo niemożności dostarczenia atrakcyjnego produktu w określonym czasie. Zrozumienie rynku i troska o klienta są ważne, ale kierowanie się wyłącznie dobrem klienta oraz brak własnej silnej wizji dotyczącej wyglądu produktu nie są drogami do sukcesu. Najczęstszą przyczyną paraliżu analitycznego jest chęć stworzenia inwestycji odpornej na porażki. Firmy kierujące się takim myśleniem zazwyczaj nie tolerują niepowodzeń i prezentują podejście wymagające osiągnięcia sukcesu już przy pierwszej próbie. Kierownictwo przed zatwierdzeniem wizji chce otrzymać dokładne prognozy wydajności produktu w przyszłości, a także szczegółowe dane dotyczące udziału w rynku oraz zyskach. Paraliżu analitycznego można uniknąć, ograniczając do minimum prace nad wizją, dokonując szybkiego wprowadzenia produktu na rynek oraz płynnie adaptując się do reakcji odbiorców.

Przekonanie o tym, co jest najlepsze dla klientów Niektóre firmy skłaniają się w kierunku innego rozwiązania, całkowicie zamykając się na rynek. Polegają wyłącznie na intuicji kierownictwa lub technicznej błyskotliwości deweloperów. Firmy te uważają, że wiedzą najlepiej, co jest dobre dla ich klientów. Ryzykowne jest inwestowanie czasu i pieniędzy firmy w rozwój produktu, którego nikt nie potrzebuje. Najlepszym sposobem na uniknięcie tworzenia innowacji w wieży z kości słoniowej jest włączenie w proces klientów i użytkowników. Można to zrobić, zapraszając ich do uczestnictwa w przeglądach sprintu oraz wcześnie i często wprowadzając nowe wydania na rynek.

POWSZECHNE BŁĘDY

77

Duże jest piękne Stworzenie produktu, który w momencie wypuszczenia na rynek będzie opływał w funkcjonalności, jest doskonałą pożywką dla mediów, jak zauważają Smith i Reinertsen [1998, 67], przytaczając analogię do futbolu amerykańskiego. Wszystkim nam podobają się opowieści o heroicznym sukcesie projektów produkcyjnych. Zespół produkcyjny przyjmuje wyzwanie, jakim jest prawie niemożliwy do ukończenia projekt, i wkłada w prace nad nim nadnaturalny wysiłek. Te projekty są jak długie, prowadzące do przyłożenia podania, które doprowadzają publiczność do szału. Są o wiele bardziej interesujące niż atak pozycyjny, w którym akcja przesuwa się jedynie o 10 jardów na raz. Tego typu wysiłki produkcyjne, mimo że wydają się ekscytujące, mają ciemną stronę: pochłaniają wiele czasu oraz pieniędzy i obarczone są wysokim ryzykiem porażki. „Firmy często popełniają błędy, starając się uzyskać doskonałe rozwiązanie, w którym od samego początku wszystko działa jak należy. W rezultacie powstają przekombinowane, drogie produkty, które nie działają tak, jak powinny” [Anthony i in., 2008, 125]. Spektakularny wysiłek powoduje również, że bardzo trudno jest rozwinąć produkt, opierając się na opiniach klientów i użytkowników, ponieważ duża liczba funkcjonalności przygotowana została wcześniej. Aby uniknąć tego błędu, zacznij od produktu, który odpowiada na wąski zakres potrzeb klientów oraz zapewnia minimalną liczbę niezbędnych funkcjonalności. Często i wcześnie wypuszczaj nowe wydania na rynek, biorąc pod uwagę opinie klientów i użytkowników. Wypuszczaj produkt szybko, obserwuj reakcję rynku i dostosowuj do niej swój produkt.

78

ROZDZIAŁ 2. TWORZENIE WIZJI PRODUKTU

Spostrzeżenia Upewnij się, że cały zespół scrumowy ma tę samą wizję produktu. Wizja powinna być skromna i zogniskowana na przyszłych wersjach produktu. Myśl szeroko, ale zaczynaj ostrożnie. Przetestuj wizję, zapraszając klientów i użytkowników na przeglądy przebiegu oraz szybko wypuszczając kolejne przyrosty produktu. Następnie ulepszaj produkt na podstawie ich opinii. W zastosowaniu omówionych koncepcji wizyjnych pomogą Ci odpowiedzi na poniższe pytania. Czy Twój produkt jest zgodny z ogólnym celem? W jaki sposób osiągane są cele i kto je tworzy? Co należałoby zrobić, by stworzyć wizję na podstawie elementów opisanych w tym rozdziale? W jaki sposób ta wizja usprawniłaby proces tworzenia innowacji w Twojej firmie?

Rozdział 3

Praca z rejestrem produktu

Niewiele jest w Scrumie artefaktów równie popularnych co rejestr produktu. Jest tego powód: rejestr produktu to niezmiernie prosty twór — lista pozostałych do wykonania elementów podzielona na priorytety. Elementy mogą zawierać poznanie potrzeb klientów lub różnych opcji technicznych, opis wymagań funkcjonalnych i niefunkcjonalnych, opis pracy niezbędnej do wypuszczenia produktu na rynek, a także rzeczy takie jak zainstalowanie środowiska lub naprawa defektów. Rejestr produktu zastępuje tradycyjne artefakty dotyczące wymagań, takie jak specyfikacje rynku i produktów. Właściciel produktu jest odpowiedzialny za zarządzanie rejestrem produktu, mistrz młyna, zespół oraz interesariusze również wnoszą swój wkład. Wszyscy razem odkrywają funkcjonalności produktu. Ten rozdział opisuje rejestr produktu, a także techniki jego efektywnego porządkowania. Dodatkowo przyjrzysz się kilku skomplikowanym zastosowaniom rejestru, w tym obchodzeniu się z wymaganiami niefunkcjonalnymi oraz skalowaniu rejestru produktu dla dużych projektów.

79

80

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Cechy rejestru produktu Rejestr produktu ma cztery cechy: jest wystarczająco szczegółowy, szacunkowy, nowo powstający oraz zawiera priorytety (ang. Detailed appropriately, Estimated, Emergent, Prioritized — DEEP, czyli dogłębny1). Przyjrzyj się im dokładniej.

Wystarczająco szczegółowy Elementy rejestru produktu są wystarczająco szczegółowe, jak pokazano na rysunku 3.1. Elementy mające wyższy priorytet opisane są bardziej szczegółowo niż te o niższym priorytecie. „Im niższy priorytet, tym mniej szczegółów, aż do momentu, w którym ledwo można dany element zrozumieć” — piszą Schwaber i Beedle [2002, 33]. Kierowanie się tymi wytycznymi pozwala na utrzymanie zwięzłości rejestru i upewnienie się, że elementy, nad którymi zespoły będą prawdopodobnie pracować w następnym sprincie, są na to przygotowane. W konsekwencji wymagania są odkrywane, rozkładane na czynniki i dopracowywane w trakcie całego projektu.

Rysunek 3.1. Priorytety nadane elementom rejestru determinują poziom detali

1

Akronim DEEP zawdzięczam Mike’owi Cohnowi.

PORZĄDKOWANIE REJESTRU PRODUKTU

81

Szacunkowy Elementy rejestru produktów są szacunkowe. Są one ogólnikowe i często wyrażane za pomocą punktów lub dni idealnych. Poznanie rozmiarów elementu pomaga w nadaniu mu odpowiedniego priorytetu oraz zaplanowaniu wydania. Szczegółowe szacunki na poziomie zadań tworzone są w trakcie planowania sprintu; zadania i dotyczące ich szacunki zapisywane są w rejestrze sprintu.

Nowo powstający Rejestr produktu ma naturalną jakość. Ewoluuje, a jego zawartość często się zmienia. Odkrywane są nowe elementy, które dodaje się do rejestru na podstawie opinii zwrotnych klientów i użytkowników. Istniejące elementy są regularnie modyfikowane, dopracowywane, usuwane lub zmienia się im priorytet.

Zawierający priorytety Wszystkie elementy rejestru produktów mają priorytety. Te najważniejsze, o najwyższym priorytecie, implementowane są jako pierwsze. Można je znaleźć na szczycie rejestru produktu, jak pokazano na rysunku 3.1. Każdy element, który zostanie wykonany, jest usuwany z rejestru.

Porządkowanie rejestru produktu Rejestr produktu, o który nie dba się wystarczająco, zarasta jak zaniedbany ogród. Rejestr potrzebuje regularnej uwagi i troski, trzeba nim ostrożnie zarządzać, czyli porządkować go. Porządkowanie rejestru produktu to proces ciągły, na który składają się poniższe kroki. Pamiętaj, że nie jest konieczne przeprowadzanie ich w podanej kolejności. ■ Nowe elementy są odkrywane i opisywane, a istniejące zmieniane lub usuwane.

82

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

■ Poszczególnym elementom rejestru produktu nadaje się priorytet. Najważniejsze elementy znajdują się na górze. ■ Elementy o wysokim priorytecie przygotowywane są na nadchodzące planowanie sprintu; rozkłada się je na mniejsze elementy i dopracowuje. ■ Zespół skaluje elementy rejestru produktu. Dodawanie nowych elementów do rejestru produktu, zmiana istniejących oraz poprawa szacunków sprawiają, że skalowanie staje się niezbędne. Mimo że to właściciel produktu jest odpowiedzialny za upewnienie się, iż rejestr produktu znajduje się w dobrym stanie, porządkowanie to działanie wspólne. Elementy rejestru są odkrywane, opisywane, rozkładane na czynniki, dopracowywane i oceniane pod względem priorytetu przez całe zespoły scrumowe — proces Scrum zakłada przeznaczenie do 10% czasu zespołu na aktywności związane z porządkowaniem [Schwaber, 2007]; interesariusze są angażowani w miarę potrzeb. Wymagania nie są już przekazywane zespołowi, ich autorami są członkowie zespołu. Właściciel produktu, mistrz młyna oraz zespół angażują się w bezpośrednie rozmowy, zamiast komunikować się za pośrednictwem dokumentów. Wspólne porządkowanie rejestru produktu jest radosne i efektywne. Pomaga stworzyć dialog pomiędzy członkami zespołu scrumowego oraz pomiędzy zespołem a interesariuszami. Usuwa podział między pracownikami „biznesowymi” a „technicznymi”, eliminując zbędne przekazywanie obowiązków. Zwiększa jasność wymagań, równoważy kolektywną wiedzę i kreatywność zespołu scrumowego, tworząc poczucie więzi i wspólnej własności. Niektóre zespoły lubią przeprowadzać porządkowanie po codziennym zebraniu scrumowym, innym wystarczą sesje tygodniowe lub dłuższe warsztaty pod koniec każdego sprintu. Porządkowanie odbywa się również w trakcie przeglądu sprintu, kiedy zespół scrumowy i interesariusze omawiają następne kroki; identyfikowane są nowe

ODKRYWANIE I OPISYWANIE ELEMENTÓW

83

elementy rejestru, a stare usuwane. Upewnij się, że proces porządkowy jest ustalony tak, aby wszelkie aktywności przeprowadzane były w sposób solidny, na przykład podczas warsztatów porządkowych na początku każdego tygodnia. Dobrze uporządkowany rejestr jest warunkiem udanego zebrania planującego sprint. Do wspierania tych czynności przyda się doskonałe narzędzie: papierowe karty. Są tanie i łatwe w użyciu. Wspomagają współpracę — każdy może wziąć jedną i spisać swój pomysł. Można je też układać na stole lub ścianie, sprawdzając spójność i kompletność. Karty i elektroniczne narzędzia do obsługi rejestru produktu, takie jak na przykład arkusze kalkulacyjne, wzajemnie się uzupełniają. Przed warsztatem porządkowym wydrukuj istniejące wymagania na kartach, a po spotkaniu przenieś wszystkie informacje z kart z powrotem do systemu. Przyjrzyj się teraz bliżej czterem krokom procesu porządkowania, zaczynając od odkrywania i opisywania elementów rejestru produktu.

Odkrywanie i opisywanie elementów Odkrywanie i opisywanie elementów rejestru produktu jest procesem ciągłym. Jeżeli jesteś przyzwyczajony do wcześniejszego tworzenia złożonych i szczegółowych specyfikacji wymagań, pamiętaj, że Scrum zachęca do zupełnie innego podejścia. Wymagania nie są już zamrożone na wczesnym etapie, ale odkrywane i opisywane w trakcie całego projektu. W miarę poprawiania się Twojego rozumienia potrzeb klientów oraz ich zaspokajania istniejące wymagania będą się zmieniać lub staną się niepotrzebne. Na ich miejsce pojawią się nowe. W Scrumie odkrywanie produktu nie odbywa się więc wyłącznie na wczesnym etapie rozwoju, lecz pokrywa się z całym projektem. Wielu menedżerów produktu przechodzących do roli właściciela produktu za duże wyzwanie uważa zakaz spisywania wszystkich wymagań na początku projektu, nawet gdyby było to możliwe.

84

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Odkrywanie elementów Odkrywanie elementów rejestru produktu rozpoczyna się wraz z uzupełnieniem rejestru. Najlepiej, kiedy zespół scrumowy i, jeśli to konieczne, interesariusze pracują nad tym wspólnie, wymyślając elementy niezbędne do powołania produktu do życia. Mogą przy tym korzystać z idei produktu, jego wizji czy też mapy produktu. W trakcie uzupełniania rejestru produktu unikaj błędów, próbując wypisać wszystkie możliwe elementy. Podczas pracy nad rejestrem skupiaj się na minimalnej liczbie funkcjonalności, niezbędnej, by powołać produkt do życia. Należy dążyć do prostoty, jak już pisałem w rozdziale 2. W miarę postępu projektu pojawiać się będzie coraz więcej pomysłów, a rejestr rozrośnie się na podstawie opinii zwrotnych klientów i użytkowników. Tworzenie zbyt długich i złożonych elementów rejestru sprawia, że trudno jest utrzymać koncentrację i ustalić priorytety. Idea lub wizja produktu może Ci w tym pomóc. Skup się jedynie na tym, co jest niezbędne, nie przejmując się resztą. Oprzyj się pokusie zbyt szybkiego dodawania wielu szczegółów. Detale dodaje się stopniowo, biorąc pod uwagę priorytety. Elementy o niskim priorytecie są duże i ogólne. Zmienia się to dopiero wraz ze zmianą priorytetu (lub dlatego, że elementy o wyższym priorytecie zostały już wykonane). Wymagania niefunkcjonalne, które reprezentują właściwości całego produktu, są wyjątkiem od tej reguły. Powinny być one wyszczególnione jak najwcześniej, co wyjaśnię w dalszej części tego rozdziału. Kiedy wstępny rejestr produktu jest już gotowy, pojawia się wiele możliwości odkrywania nowych elementów. Ujawniają się one w trakcie warsztatów porządkowych, kiedy zespół scrumowy ustala priorytety i rozkłada elementy rejestru produktu na mniejsze części. Ujawniają się również w trakcie przeglądów sprintu, kiedy interesariusze wyrażają swoje opinie, oraz kiedy klienci i użytkownicy komentują nowe przyrosty produktu. Za każdym razem, kiedy nowe wymaganie wpisywane jest do rejestru, upewnij się, że wynikające z niego wymagania klienta są zrozumiałe. Zapytaj, dlaczego jest ono konieczne oraz jakie korzyści przy-

ODKRYWANIE I OPISYWANIE ELEMENTÓW

85

niesie klientom. Nie kopiuj wymagań bezmyślnie do rejestru produktu, ponieważ w ten sposób tworzy się niespójna i niemożliwa do zarządzania lista pobożnych życzeń. Uważaj istniejące wymagania za podejrzane i potraktuj je jako odpowiedzialność, a nie kapitał. Wymaganie opisuje po prostu funkcjonalność produktu, która na pewnym etapie została uznana za konieczną. W miarę jak zmieniają się rynki i technologie, a zespół scrumowy zyskuje wiedzę na temat spełniania potrzeb klientów, zmieniają się również wymagania, do tego stopnia, że niektóre z nich stają się zbędne.

Opisywanie elementów Scrum nie określa sposobu opisywania elementów rejestru produktu, ale ja preferuję pracę z user stories [Cohn, 2004]. Jak sugeruje nazwa, user story, czyli historia użytkownika, opowiada o kliencie lub użytkowniku korzystającym z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji czy warunki, które muszą być spełnione, by historia była kompletna. User story może być ogólne lub szczegółowe; ogólne historie zwane są epikami. User stories są łatwe do napisania, dekompozycji i dopracowania. Do opisania wymagań możesz oczywiście wykorzystać również inne techniki. Jeśli jednak korzystasz z user stories, nie powinieneś czuć się zobligowany do opisania każdego elementu rejestru jako historii. Przykładowo: wymagania dotyczące użyteczności najlepiej obrazują prototypy lub szkice. Praca z rejestrem produktu nie oznacza, że zespół scrumowy nie może tworzyć innych pomocnych artefaktów, w tym streszczeń user stories, historii modelujących przepływ pracy, diagramów ilustrujących zasady biznesowe, arkuszy kalkulacyjnych przedstawiających złożone obliczenia, szkiców interfejsu użytkownika, scenopisów, diagramów nawigacyjnych oraz prototypów interfejsu użytkownika. Te artefakty nie zastąpią rejestru produktu, ale pomogą opracować i wyjaśnić jego zawartość. Powinny być proste. Wykorzystuj tylko te artefakty, które pomogą zespołowi scrumowemu w przybliżeniu się do gotowego produktu.

86

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Ustalanie struktury rejestru Rejestry produktu dużo zyskują dzięki pogrupowaniu powiązanych elementów w motywy. Motywy pełnią funkcję symbolu zastępczego produktu, tworzą strukturę rejestru, pomagają w ustalaniu priorytetów i ułatwiają dostęp do informacji. Przykładowymi motywami dla telefonu komórkowego będą: e-mail, kalendarz, komunikacja głosowa i organizer. Najważniejszą zasadą jest przypisanie na samym początku do każdego motywu od dwóch do pięciu ogólnych wymagań. Zapewni to wystarczającą ilość informacji, by zrozumieć, co należy zrobić, aby powołać produkt do życia, bez konieczności zawierania zbyt dużej liczby specyfikacji w rejestrze. Motywy tworzą w rejestrze produktu hierarchię, która na tym etapie zawiera zarówno indywidualne elementy, jak i grupy. Przydatne może być również dalsze rozróżnianie w rejestrze elementów ogólnych, takich jak epiki, oraz szczegółowych, jak user stories, co pokazałem w tabeli 3.1. Tabela 3.1. Przykładowy rejestr produktu Motyw

Element ogólny

Element szczegółowy

Wysiłek

E-mail

Stworzenie e-maila

Jako przedsiębiorca chcę mieć możliwość określenia tematu e-maila

1

Motyw w tabeli 3.1 zawiera elementy ogólne. Z czasem będą one rozłożone na bardziej szczegółowe. W miarę dokonywania przez zespół prognoz dotyczących elementów rozmiar tych ostatnich jest zapisywany. Zauważ, że strukturę w tabeli 3.1 można wdrożyć niezależnie od narzędzia wykorzystywanego do tworzenia rejestru produktu. Wystarczy odpowiednio rozłożyć papierowe karty na tablicy lub ścianie biura.

USTALANIE PRIORYTETÓW REJESTRU PRODUKTU

87

Ustalanie priorytetów rejestru produktu Nigdy nie zapomnę dnia, w którym zasugerowałem menedżerce produktu związanego z ochroną zdrowia, żeby ustaliła priorytety dla stosu elementów leżących przed nią. Popatrzyła na mnie szeroko otwartymi oczyma i powiedziała: „Nie mogę. Wszystkie mają wysoki priorytet”. Ustalanie priorytetów wymaga podjęcia decyzji dotyczących wagi poszczególnych elementów. Jeżeli wszystko ma wysoki priorytet, wszystko jest równie ważne. Oznacza to, że tak naprawdę nic nie jest priorytetem, więc istnieje nikłe prawdopodobieństwo, że klient dostanie to, czego naprawdę potrzebuje. Za ustalenie priorytetów dla każdego elementu rejestru produktu odpowiedzialny jest właściciel produktu. Tak jak i inne czynności związane z porządkowaniem, ustalanie priorytetów najlepiej przeprowadzić przy udziale całego zespołu scrumowego. Wyrównuje to kolektywny poziom wiedzy zespołu, a także tworzy więzi. Ustalone priorytety kierują pracą zespołu, skupiając uwagę jego członków na najważniejszych aspektach. Powodują także stopniowe zamrażanie zawartości rejestru. Jak już wspomniałem, elementy rejestru mają ilość szczegółów odpowiednią dla ich priorytetu. To sprawia, że proces jest elastyczny i pozwala na opóźnianie decyzji dotyczących elementów o niższym priorytecie, dając zespołowi scrumowemu więcej czasu na ocenę opcji, zebranie opinii klientów oraz zdobycie dodatkowej wiedzy. W ten sposób podejmowane są lepsze decyzje i tworzone lepsze produkty2. Ponieważ indywidualne elementy rejestru produktu mogą być niewielkie i trudno będzie określić ich priorytet, najlepiej, jeśli najpierw przyznasz priorytety motywom. Następnie ustal priorytety wewnątrz motywów lub, jeśli to konieczne, pomiędzy nimi. W dalszym ciągu tej części rozdziału opiszę następujące czynniki wpływające na 2

Opóźnianie decyzji do ostatniego momentu nazywa się również „ostatnim odpowiedzialnym momentem” [Poppendieck i Poppendieck, 2003].

88

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

ustalanie priorytetów rejestru produktu: wartość, wiedzę, niepewność i ryzyko, zdatność do wypuszczenia na rynek oraz zależności.

Wartość Wartość jest powszechnym czynnikiem wykorzystywanym przy ustalaniu priorytetów. Z pewnością chcesz dostarczyć najbardziej wartościowe elementy na początku. Ale co sprawia, że element rejestru produktu staje się wartościowy? Odpowiedź jest prosta. Element jest wartościowy, jeżeli jest niezbędny w procesie powoływania produktu do życia. Jeżeli taki nie jest, wówczas okazuje się zbędny; zostaje on wyłączony z prac nad bieżącą wersją wydania lub produktu. Zespół scrumowy może zmienić priorytet elementu, umieszczając go na samym dole rejestru produktu lub — co jest najlepszym rozwiązaniem — usuwając go. Drugi sposób zapewnia zwięzłość rejestru oraz lepszą koncentrację zespołu scrumowego. Jeżeli element jest ważny dla przyszłych wersji, pojawi się ponownie. Przed dodaniem elementu do wydania zdecyduj, czy produkt będzie spełniał swoje zadanie bez niego. Jest to pomocne w tworzeniu prostego produktu, który zawiera minimalną liczbę niezbędnych funkcjonalności, jak pokazałem w rozdziale 2. Na przykład Apple wypuściła na rynek pierwszą i drugą generację iPhone’ów bez funkcjonalności umożliwiającej kopiowanie i wklejanie, co nie wpłynęło negatywnie na sukces produktu. Jeżeli element rzeczywiście jest niezbędny, sprawdź, czy istnieje alternatywa, która zapewni te same korzyści przy mniejszym nakładzie wysiłku i czasu lub zredukuje koszt jednostkowy. Mimo że brzmi to jak oczywistość, zespoły są często ograniczone ukrytymi założeniami i nie zawsze dostrzegają wszystkie opcje. Nie rozpatruj tylko nowych wymagań. Zbadaj również te istniejące. Alternatywy pojawiają się często po tym, jak zespół scrumowy dowie się więcej na temat potrzeb klientów oraz tworzonego rozwiązania. Należy upraszczać, kroić i utrzymywać porządek — niczym ogrodnik usuwający chwasty i przycinający krzewy.

USTALANIE PRIORYTETÓW REJESTRU PRODUKTU

89

Jeżeli jest jakaś wątpliwość, trzeba usunąć wymaganie i wypuścić wydanie bez niego — tak jak zrobiła firma Google, wypuszczając Google News, aplikację agregującą wiadomości z całego świata. Zespół deweloperów nie mógł dojść do porozumienia, czy filtrowanie wiadomości powinno odbywać się według daty, czy też lokalizacji. Firma zdecydowała, że w wydaniu nie znajdzie się żadna z wymienionych właściwości. Krótko po wypuszczeniu produktu na rynek zaczęły napływać pytania dotyczące nowych funkcjonalności. Trzysta osób prosiło o filtrowanie według daty, a tylko trzy według lokalizacji — co było jasną wskazówką dotyczącą tego, która funkcjonalność powinna zostać rozwinięta jako pierwsza. Gdyby Google wypuścił produkt z obiema właściwościami, wydanie pochłonęłoby więcej czasu i pieniędzy. Uzyskanie opinii zwrotnej dotyczącej tego, która właściwość jest ważniejsza, byłoby trudniejsze. Celowo wypuszczając okrojoną wersję produktu, Google szybko przekonał się, co należy zrobić.

Wiedza, niepewność i ryzyko „Ryzyko jest niezbędną cechą innowacji produktu. Każda decyzja dotycząca projektu: czy to warunkowa, czy bezwarunkowa pociąga za sobą ryzyko” — piszą Preston G. Smith i Guy M. Merritt [2002, 4]. Ryzyko jest wobec tego częścią rozwoju oprogramowania; żaden powstający produkt nie jest od niego wolny. Z ryzykiem związana jest niepewność. Im więcej niepewności, tym bardziej ryzykowny jest projekt. Niepewność z kolei spowodowana jest brakiem wiedzy. Im mniej wiesz na temat tego, co chcesz stworzyć i jak to zrobić, tym bardziej niepewnie się czujesz. Wiedza, niepewność i ryzyko są zatem połączone. Ponieważ ryzyko i niepewność wpływają na sukces produktu, niepewne i ryzykowne elementy powinny mieć wysoki priorytet. Przyspiesza to zdobywanie nowej wiedzy, niweluje niepewność i redukuje ryzyko. Jeżeli zespół scrumowy nie jest pewien niektórych aspektów zawartych w projekcie interfejsu użytkownika, odpowiednie opcje powinny zostać zbadane i przetestowane poprzez zebranie opinii klientów

90

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

i użytkowników. Jeżeli zespół nie wie, czy powinna zostać zastosowana warstwa dostępu do bazy danych firmy zewnętrznej, wymagania dotyczące transakcji bazodanowych powinny zostać zaimplementowane na wczesnym etapie, tak aby mogły być poddane ocenie różne opcje. Pamiętaj, że ryzyko może się również kryć w infrastrukturze i środowisku, szczególnie w niestworzonym procesie budowy lub niezlokalizowanym zespole scrumowym. Walka z niepewnymi, ryzykownymi elementami na wczesnym etapie może spowodować wczesną porażkę. Wczesna porażka pozwala zespołowi scrumowemu na zmianę kursu, kiedy jest jeszcze taka szansa. Można wtedy zmodyfikować architekturę i technologię albo zmienić skład zespołu. Takie podejście bywa trudne do zaakceptowania dla osób i organizacji przyzwyczajonych do tradycyjnych procesów, w których problemy i przeszkody pojawiają się na późnym etapie i traktowane są jako złe wieści, a nie okazja do nauki i wprowadzania zmian.

Zdatność do wypuszczenia na rynek Wczesne i częste wypuszczanie oprogramowania to doskonały sposób na rozwijanie go tak, by stało się produktem, który pokochają klienci. Powiem o tym w rozdziale 4. Jest to również efektywny sposób na ograniczanie ryzyka. Jeżeli zespół scrumowy jest niepewny tego, czy i jak dana właściwość powinna zostać zaimplementowana, wczesne wydania mogą odpowiedzieć na te pytania, tak jak w przypadku omawianej wcześniej aplikacji Google News. Możliwość wypuszczania przyrostów produktu wcześnie i często powinna wpłynąć na ustalanie priorytetów w rejestrze produktu. Każde wydanie musi zapewniać funkcjonalności, które są użyteczne dla klientów i użytkowników oraz generują pożądane opinie. Pamiętaj, że zazwyczaj nie jest konieczna pełna implementacja motywu; częściowe wdrożenie bywa dla wczesnych wydań wystarczające.

USTALANIE PRIORYTETÓW REJESTRU PRODUKTU

91

Zależności Zależności są stałym punktem rejestru produktu, bez względu na to, czy je lubisz, czy też nie. Wymagania funkcjonalne na przykład często zależą od innych wymagań funkcjonalnych, a nawet niefunkcjonalnych. Jeżeli kilka zespołów pracuje razem, zależności między nimi mogą wpłynąć na ustalanie priorytetów, co omówię bardziej szczegółowo w rozdziale 4. Zależności ograniczają wolność ustalania priorytetów w rejestrze produktu oraz wpływają na ocenę ilości pracy; element, od którego zależą wysiłki innych, musi zostać wdrożony jako pierwszy. Powinieneś w związku z tym postarać się usunąć zależności, kiedy to możliwe. Łączenie kilku zależnych elementów w jeden większy, a także rozdzielanie elementów to dwie powszechne techniki radzenia sobie z zależnymi user stories [Cohn, 2004, 17]. Przyjrzyj się dwóm przykładowym historiom: „Jako użytkownik chcę mieć możliwość pisania wiadomości tekstowych” oraz „Jako użytkownik chcę mieć możliwość pisania e-maili”. Obie historie są zależne, ponieważ wymagają możliwości przetwarzania tekstu. Jeżeli jako pierwszą wdrożysz historię dotyczącą pisania wiadomości, wysiłek włożony w historię dotyczącą e-maili będzie zredukowany i odwrotnie. Pierwszym wyjściem jest połączenie ich w jedną większą historię. Nie jest to zbyt dobry pomysł, ponieważ powstała historia będzie bardzo rozbudowana. Drugim wyjściem jest podzielenie wymagań w inny sposób. Jeżeli wspólna funkcjonalność („Jako użytkownik chcę mieć możliwość pisania”) zostanie zapisana osobno, te dwie historie nie będą już od siebie zależne. W ten sposób na dotyczące ich prognozy nie ma już wpływu kolejność wykonywania.

92

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Przygotowanie do planowania sprintu Przed każdym spotkaniem planującym sprint muszą zostać przygotowane elementy rejestru produktu, nad którymi zespół będzie pracował w następnej kolejności. Przygotowania zaczyna się od wybrania celu sprintu.

Wybór celu sprintu Cel sprintu podsumowuje oczekiwany wynik sprintu. Powinien przybliżyć zespół scrumowy o krok w stronę wydania udanego produktu. Właściciel produktu w projekcie, nad którym pracowałem, wybrał dla pierwszego sprintu następujący cel: „Wysokie drzewa mają głębokie korzenie”. Cel ten bardzo ładnie opisywał zamierzenia sprintu: stworzenie fundamentów dla całego projektu. Dobry cel sprintu jest szeroki, ale realistyczny. Powinien zostawić trochę miejsca dla zespołu na manewry i być aktualny nawet, kiedy zespół nie zobowiąże się do wykonania wszystkich głównych elementów rejestru produktu. Tak jak w przypadku aktywności porządkowych, zespół powinien brać udział w tworzeniu celu. Gwarantuje to jasność przekazu i zaangażowanie pracowników. Cele sprintu przynoszą korzyści z kilku powodów. ■ Tworzą wspólną płaszczyznę pomiędzy właścicielem produktu, mistrzem młyna oraz zespołem: wszyscy pracują, aby osiągnąć jeden cel. ■ Minimalizują zmiany, ograniczając typ wymagań, nad którym zespół będzie pracował w danym sprincie. Można to zrobić, wybierając elementy z tego samego motywu. Ułatwia to bliską współpracę i pomaga w osiągnięciu określonej szybkości. ■ Ułatwiają komunikację z interesariuszami dotyczącą tego, nad czym pracuje zespół.

PRZYGOTOWANIE DO PLANOWANIA SPRINTU

93

Pamiętaj, że wybranie celu sprintu może prowadzić do zmian w priorytetach rejestru produktu, do których należy usuwanie i dodawanie elementów na szczycie listy. Być może będziesz zmuszony do dokonania wyboru pomiędzy spójnym celem sprintu a sprawną pracą nad projektem. Kiedy cel zostanie już ustalony, wszystkie stosowne elementy powinny się znaleźć na szczycie rejestru produktu.

Przygotowanie wystarczającej liczby elementów dokładnie na czas Kiedy cel sprintu zostanie wybrany, należy przygotować wystarczającą liczbę elementów dokładnie na czas3. Temat dużych projektów, które wymagają wybiegania w przyszłość, omówię w dalszej części tego rozdziału. Czynności porządkowe w pierwszym sprincie polegają na skupieniu się na elementach niezbędnych w drugim sprincie, a te w drugim na elementach niezbędnych w trzecim i tak dalej. Podejście to ma kilka korzyści: minimalizuje ilość czasu i pieniędzy, które należy zainwestować w opisywanie elementów rejestru produktu, oraz utrzymuje spis szczegółowych elementów na odpowiednim poziomie — zapewnianie większej ilości informacji niż to konieczne jest marnotrawstwem. Dodając szczegóły tylko do elementów, które najprawdopodobniej zostaną wybrane w następnym sprincie, pozwalasz na rozwój rejestru produktu. Przygotowanie elementów do zebrania planującego sprint wymaga rozłożenia większych elementów na mniejsze czynniki do momentu, w którym są one wystarczająco niewielkie, by zmieścić się w sprincie. Należy również uporządkować elementy tak, by były jasne, dostępne i nadające się do testów. Rysunek 3.2 właściwie ilustruje ten proces. Pamiętaj, że dekompozycja elementów może zająć kilka sprintów, o czym zaraz powiem.

3

Terminy „wystarczająca ilość” i „dokładnie na czas” zostały po raz pierwszy użyte przez Cohna [2008] w dyskusji na temat czynności porządkowych.

94

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Rysunek 3.2. Dekompozycja i porządkowanie elementów rejestru produktu

To, ile elementów trzeba przygotować, zależy od szybkości zespołu oraz oczekiwanej ilości szczegółów. Im większa jest szybkość zespołu, tym więcej elementów musi zostać przygotowanych. Pomocne może być dołączenie kilku dodatkowych elementów, by dać zespołowi możliwość wyboru. Przydadzą się one również w przypadku, gdy prace nad sprintem postępują szybciej niż przewidywano. Lubię pracować nad niewielkimi projektami, które mogą zostać ukończone w ciągu kilku dni, bez względu na długość sprintu. W ten sposób usprawnione jest śledzenie postępu zespołu w trakcie sprintu, a także samoorganizacja: postęp zespołu opiera się nie tylko na pozostałych zadaniach, ale także na liczbie zaimplementowanych funkcjonalności, które zostały przetestowane i udokumentowane. Niewielkie wymagania minimalizują ilość bieżącej pracy oraz ryzyko otrzymania na koniec sprintu elementów częściowych i wadliwych. Dodatkowo niewielkie elementy ułatwiają składanie realistycznych zobowiązań. Te większe mogą zawierać tak wiele zadań, że zespół nie będzie w stanie ich zidentyfikować.

PRZYGOTOWANIE DO PLANOWANIA SPRINTU

95

Dekompozycja elementów Dekompozycja elementów rejestru produktu oznacza zmniejszanie ich gabarytów do momentu, w którym będą mieściły się w jednym sprincie. Ten proces, zwany także „progresywną dekompozycją wymagań” [Reinertsen, 1997], może trwać dłużej niż jeden sprint. Możesz być zmuszony do rozpoczęcia dekompozycji elementu rejestru produktu kilka sprintów wcześniej, szczególnie jeżeli dany element jest duży i skomplikowany. Pozwala to na zebranie opinii klientów, użytkowników i innych interesariuszy przed ustalaniem szczegółów elementu. Przyjrzyj się progresywnej dekompozycji user stories. Jak pokazano na rysunku 3.3, zespół scrumowy umieścił w rejestrze produktu epik „Tworzenie e-maili”. Ponieważ jest on zbyt duży i niejasny, by mógł zostać dostarczony w jednym sprincie, należy rozbić go na kilka ogólnych user stories. Historia „Podanie odbiorcy” jest następnie rozebrana na dwie kolejne ogólne user stories. Dopiero wtedy są one gotowe, by włączyć je do sprintu. Epik jest przykładem historii złożonej, która ma więcej niż jeden cel [Cohn, 2004, 24 – 25]. Aby ją zdekomponować, należy wprowadzić osobną historię dla każdego celu. „Tworzenie e-maili” zostaje więc rozbite na „Podanie tematu”, „Podanie odbiorcy” oraz „Ustalanie priorytetów”. Istnieją inne user stories, które również muszą zostać zdekomponowane, w tym historie złożone oraz historie z rozbudowanymi kryteriami. Historia złożona to taka, która jest zbyt duża, by mogła być dostarczona w jednym sprincie, z powodu jej nieodłącznej niepewności lub zbyt dużej liczby funkcjonalności [Cohn, 2004, 25 – 26]. Jeżeli niepewność jest zbyt duża, wprowadź do rejestru jeden lub kilka elementów, które rozwiązują tę niepewność, tworząc odpowiednią bazę wiedzy, na przykład: „Zbadanie JavaServer Faces jako technologii interfejsu użytkownika”. Jeżeli historia opisuje zbyt dużą liczbę funkcjonalności, należy je podzielić, by umożliwić przyrostową dostawę funkcjonalności. Ta technika zwana jest również „krojeniem ciasta” [Cohn, 2004, 76]. Historia „Walidacja użytkownika” może zostać rozłożona na historie „Walidacja nazwy użytkownika” oraz „Walidacja hasła”.

96

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Rysunek 3.3. Dekompozycja user stories

Historie często wyglądają dobrze, dopóki nie rozważy się kryteriów akceptowalności. Jeżeli jest ich zbyt wiele — więcej niż dziesięć — lub jeżeli wymagania ukryte są w kryteriach, musisz zmienić kompozycję historii. Oto przykład: „Jako użytkownik chcę mieć możliwość kasowania wiadomości tekstowych”. Kryterium akceptacji mówi: „Mogę wybrać jakąkolwiek wiadomość. Mogę usunąć tekst wiadomości. Mogę zapisać zmodyfikowaną wiadomość”. Drugi warunek jest zbędny, a pozostałe, zamiast specyfikacji kryteriów akceptacji, wprowadzają nowe wymagania. Ta historia powinna być podzielona na trzy: na historię odnoszącą się do kasowania wiadomości tekstowych, historię odnoszącą się do edytowania wiadomości tekstowych oraz historię dotyczącą zapisywania zmodyfikowanych wiadomości.

PRZYGOTOWANIE DO PLANOWANIA SPRINTU

97

Zapewnianie klarowności, możliwości testowania i wykonalności Kiedy element jest już wystarczająco mały, musisz upewnić się, że jest klarowny, możliwy do przetestowania i wykonalny4. Wymaganie jest jasne, jeżeli wszyscy członkowie zespołu scrumowego jednakowo rozumieją jego semantykę. Wspólne opisywanie wymagań oraz wyrażanie elementów rejestru produktu w prosty i zwięzły sposób wspomaga przejrzystość. Element umożliwia testowanie, jeżeli istnieje efektywny sposób sprawdzenia w trakcie bieżącego sprintu, czy wymaganie zostało spełnione. Historie muszą mieć kryteria akceptowalności, które pozwolą sprawdzić możliwości testowania. Element jest możliwy do zrealizowania, jeżeli da się go ukończyć w trakcie jednego sprintu, zgodnie z definicją pojęcia „gotowe”. Definicja tego pojęcia omówiona jest w rozdziale 5. Takie kryterium osiągniesz, rozważając zależności od innych elementów, zarówno funkcjonalne, jak i niefunkcjonalne. Jeżeli historia jest ograniczona wymaganiami interfejsu użytkownika, musi być jasne, jak ma wyglądać docelowy przyrost produktu. W innym przypadku zespół powinien przyjrzeć się wymaganiom interfejsu przed implementacją historii. Jeżeli eksploracja elementu wymaga dużego nakładu sił, powinno się ją przeprowadzić w osobnym sprincie, na przykład z wykorzystaniem jednorazowego prototypu, który pomoże w projektowaniu interfejsu.

4

Bill Wake sugeruje, że historie powinny być niezależne, negocjowalne, wartościowe, umożliwiające szacunki i testowanie, a także niewielkie [Wake, 2003]. Kryteria te nazwane zostały INVEST. Zależności oraz wartości zostaną omówione w rozdziale dotyczącym ustalania priorytetów, razem z metodami określania szacunków. Negocjowanie odnosi się do możliwości dostosowania user stories. Historia jest obietnicą konwersacji, jak twierdzi Ron Jeffries, a nie twardym wymogiem.

98

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Dostosowywanie wielkości elementów Szacowanie elementów rejestru produktu pozwala na ogólne określenie ich rozmiaru i ilości pracy niezbędnej do włożenia w ich przygotowanie. Jest to pomocne z dwóch powodów: pomaga w ustalaniu priorytetów oraz pozwala śledzić i prognozować postęp projektu. Zauważ, że w procesie Scrum istnieją dwa odrębne szacunki: ogólne w rejestrze produktu, wskazujące przybliżony rozmiar elementu, a także szczegółowe w rejestrze sprintu, opisujące rozmiar zadania, zwykle podawane w godzinach. W tej części rozdziału omówię dostosowywanie rozmiaru elementów w rejestrze produktu. Elementy rejestru produktu są szacowane, kiedy odkrywa się nowe lub modyfikuje istniejące oraz kiedy zespół orientuje się, że rozmiar elementu się zmienił. Potrzebujesz miary, która jest szybka i prosta w użyciu. Moją ulubioną są punkty5.

Punkty Punkty to miara ogólna i relatywna, dotycząca włożonego wysiłku i rozmiaru danego elementu6. Element wart jeden punkt jest o połowę mniejszy niż ten wart dwa punkty. Element oceniony na trzy punkty wymaga tyle samo pracy co element wart jeden punkt i element wart dwa punkty łącznie. Miara relatywna wykorzystuje to, że rozmiar jest również relatywny; semantyka dużego i małego zależy od punktu odniesienia. Moja myszka komputerowa jest mała w porównaniu do mojego laptopa, ale duża w porównaniu do pamięci USB, która leży obok. Popularny zakres wykorzystywanych punktów pokazuje tabela 3.2.

5

Więcej szczegółów oraz obszerną dyskusję na temat technik określania szacunków znajdziesz u Cohna [2005].

6

Czas mierzony jest osobno, za pomocą szybkości, co omówię w rozdziale 4.

DOSTOSOWYWANIE WIELKOŚCI ELEMENTÓW

99

Tabela 3.2. Popularne zakresy punktów Punkty

Rozmiar koszulki

0

gratis, element został już stworzony

1

XS

bardzo mały

2

S

mały

3

M

średni

5

L

duży

8

XL

bardzo duży

13

XXL

bardzo bardzo duży

20

XXXL

olbrzymi

Nielinearna sekwencja z tabeli 3.2 przyspiesza proces podejmowania decyzji przez zespół. Zapobiega długim dyskusjom na temat odpowiednich wartości, które mogą pojawić się w przypadku sekwencji linearnych. Zespół może rozszerzyć zakres pokazany w tabeli 3.2, dodając 40 i 100 do największych wartości, pod warunkiem że szacunki relatywne będą prawidłowe. Bez względu na wybrany zakres zespół powinien trzymać się sekwencji i czuć się z nią komfortowo. Ponieważ punkty są relatywne i arbitralne, nie można ich porównywać pomiędzy zespołami, chyba że wszystkie zespoły uzgodnią wspólny zakres i semantykę.

Poker planistyczny Punkty są świetne, ale same w sobie nie wystarczą. Potrzebujesz techniki, która umożliwi zespołowi efektywne szacowanie. Taką techniką jest poker planistyczny [Cohn, 2005, 56 – 59]. Polega on na tym, że każdy członek zespołu dostaje talię kart zawierającą wszystkie, uzgodnione wcześniej, wartości punktów. Gdybyś wykorzystywał zakres z tabeli 3.2, talia zawierałaby osiem kart, a każda z kart — jeden z punktów zakresu. Po rozdaniu uczestnikom kart rozpoczyna się szacowanie.

100

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Jeżeli zespół wyznacza wielkość elementów rejestru po raz pierwszy, wskazane jest określenie znaczenia wartości zakresu. Aby to zrobić, wiele zespołów jako pierwszy wybiera element, co do którego niewielkich rozmiarów nikt nie ma wątpliwości. Innym rozwiązaniem jest wybranie najmniejszego, największego oraz średniego elementu i oszacowanie ich po kolei. Jeżeli jednak zespół jest zaznajomiony z zakresem, może zacząć od elementu mającego najwyższy priorytet i stopniowo schodzić w dół rejestru. Zanim zespół dokona szacunków, właściciel produktu musi objaśnić element wszystkim członkom zespołu, którzy następnie omawiają kolejne kroki niezbędne do wdrożenia produktu zgodnie z definicją pojęcia „gotowe”. Po dyskusji każdy członek zespołu dokonuje własnej oceny wielkości elementu, bez sugerowania się tym, kto będzie go rozwijał. Przydziału zadań dokonuje się podczas odpowiedniego codziennego zebrania zespołu scrumowego. Każdy członek zespołu wybiera kartę zawierającą odpowiednie szacunki i kładzie ją obrazkiem w dół na stole. Kiedy już wszyscy wyłożyli swoje karty, należy je jednocześnie odwrócić obrazkami ku górze. Jeżeli szacunki różnią się między sobą, dwóch członków zespołu, których wartości były najbardziej zróżnicowane, argumentuje swój wybór. Następnie przeprowadzana jest kolejna runda. Wszystkie karty wracają do talii, członkowie zespołu po raz kolejny wybierają kartę, która najlepiej odpowiada ich szacunkowi. Nie musi to być ta sama karta co za pierwszym razem. Gra jest kontynuowana, dopóki szacunki się nie pokryją. Zasadą podejmowania decyzji jest konsensus, wszyscy członkowie zespołu powinni czuć się swobodnie. Gdy tylko zespół oszacuje co najmniej dwa elementy, nowe szacunki powinny zostać porównane z istniejącymi, aby upewnić się, że relatywny rozmiar jest odpowiedni. Można to uczynić, grupując elementy w zależności od rozmiaru.

DOSTOSOWYWANIE WIELKOŚCI ELEMENTÓW

101

Szacowanie wymagań niefunkcjonalnych Dla wymagań niefunkcjonalnych, które dotyczą wszystkich wymagań funkcjonalnych (na przykład user experience lub wydajność), nie tworzy się osobnych szacunków. Należy je włączyć do definicji pojęcia „gotowe”. Jeżeli jednak do stworzenia wymagania niefunkcjonalnego potrzebna będzie konkretna ilość pracy, tak jak w przypadku odkrywania różnych opcji projektów interfejsu użytkownika lub refaktoringu architektonicznego, odpowiednie elementy powinny być umieszczone w rejestrze produktu, a ich wielkość określona przez zespół. Włączanie wymagań niefunkcjonalnych do definicji pojęcia „gotowe” nie oznacza, że nie wymagają one żadnej pracy. Wręcz przeciwnie: definicja pojęcia „gotowe” wpływa na szacunki zespołu.

Aby uzyskać w miarę dokładne szacunki, muszą być spełnione trzy warunki: zespół musi wiedzieć, ile pracy trzeba włożyć w dostarczenie danego elementu, członkowie zespołu muszą być w stanie określić zależności od innych elementów, a także musi być dostępna definicja pojęcia „gotowe”. Jeżeli zespół nie jest w stanie oszacować danego elementu, należy dodać go do rejestru, co spowoduje przyrost wiedzy, na przykład: „Stworzenie prototypu lub makiety pomagającej w odkrywaniu opcji interfejsu użytkownika”. Tylko członkowie zespołu, którzy tworzą przyrosty produktu, powinni mieć możliwość dokonywania szacunków elementów rejestru produktu. Właściciel produktu i mistrz młyna nie powinni dokonywać szacunków ani też wpływać na nie (chyba że są członkami zespołu lub zespół poprosi ich o radę). Właściciel produktu musi jednak być obecny na zebraniu. Wiele elementów rejestru produktu będzie miało formę szkicu, a właściciel produktu będzie musiał je objaśnić. Szybkie szacunki Jeżeli zespół ma zbyt mało czasu na poker planistyczny, można wykorzystać następującą technikę szacunkową. Należy podzielić jedną ścianę pokoju zebrań na kilka części, a każdą z nich opatrzyć etykietą zawierającą liczbę z zakresu punktów. Wydrukuj elementy rejestru produktu na kartach i rozłóż je na stole. Poproś każdego członka zespołu o wybranie jednej karty, dokonanie szacunku, a następnie przytwierdzenie karty w odpowiednim miejscu na ścianie, upewniając się, że

102

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

wszystkie karty w danej grupie wyobrażają elementy o jednakowych rozmiarach. Jeżeli ktokolwiek zauważy niepasującą kartę, powinien ją przenieść do właściwej grupy. Dzięki temu procesowi można szybko stworzyć szacunki dla wielu elementów rejestru, wkładając w to minimalny wysiłek. Główną wadą tego procesu jest to, że zespół nie dyskutuje na temat rozmiaru elementów, w związku z tym jakość szacunków będzie niższa niż w przypadku pokera planistycznego.

Postępowanie w przypadku wymagań niefunkcjonalnych Wymagania niefunkcjonalne (nazywane również wymaganiami operacyjnymi, cechami systemu i ograniczeniami) to brzydkie kaczątka rozwoju oprogramowania. Są często zaniedbywane, mimo że opisują ważne właściwości, takie jak: wydajność, solidność, skalowalność, użyteczność, a także wymagania techniczne oraz te związane ze zgodnością (na przykład wspieranie protokołu lub możliwość uzyskania certyfikatu). Mają one wpływ na projekt interfejsu użytkownika, architekturę, wybór technologii oraz na ostateczny koszt produktu i długość jego życia. W tej części rozdziału opowiem o opisywaniu niefunkcjonalnych wymagań w Scrumie i zarządzaniu nimi.

Opisywanie wymagań niefunkcjonalnych Wymagania niefunkcjonalne mogą być wyrażone w postaci ograniczeń [Newkirk i Martin, 2001, 16 – 18]. Możesz na przykład opisać wydajność w sposób przedstawiony na rysunku 3.4. Wymagania dotyczące user experience najłatwiej zapisuje się w postaci szkiców, scenopisów, diagramów nawigacyjnych interfejsu użytkownika i prototypów. Moje doświadczenie sugeruje, że zespoły wolą tego rodzaju artefakty niż wytyczne dotyczące interfejsu użytkownika przedstawione w formie graficznej.

POSTĘPOWANIE W PRZYPADKU WYMAGAŃ NIEFUNKCJONALNYCH

103

Rysunek 3.4. Wymaganie niefunkcjonalne sformułowane jako ograniczenie

Zarządzanie wymaganiami niefunkcjonalnymi W trakcie zarządzania wymaganiami niefunkcjonalnymi najlepiej jest wprowadzić rozróżnienie na wymagania globalne i lokalne. Te pierwsze zwykle odnoszą się do wszystkich wymagań funkcjonalnych i tworzą małą grupę. Przykładem może być ograniczenie wydajnościowe pokazane na rysunku 3.4. Globalne wymagania niefunkcjonalne powinny być jak najwcześniej szczegółowo opisane — w trakcie tworzenia wizji lub dodawania nowych elementów do rejestru produktu. Odkrywanie i dopracowywanie ich na zbyt późnym etapie może mieć negatywny wpływ na podejmowanie wyborów i odniesienie przez produkt sukcesu. Globalne wymagania niefunkcjonalne mogą być zapisane w specjalnym miejscu rejestru produktu, jak przedstawiono w tabeli 3.3. Tabela 3.3. Przykładowy rejestr produktu z wymaganiami niefunkcjonalnymi Wymagania funkcjonalne Motyw

E-mail

Wymagania ogólne

Wymagania szczegółowe

Tworzenie emaila

Jako przedsiębiorca chcę mieć możliwość podania tematu e-maila

Wysiłek

1

Wymagania niefunkcjonalne

Produkt musi odpowiedzieć na zapytanie w czasie poniżej jednej sekundy

104

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Warto również umieścić globalne wymagania niefunkcjonalne w definicji pojęcia „gotowe”. W konsekwencji każdy przyrost produktu musi spełniać te same wymagania. Z drugiej strony, lokalne wymagania niefunkcjonalne dotyczą jedynie specyficznych wymagań funkcjonalnych, na przykład konkretnych wymagań wydajnościowych niezbędnych do odzyskiwania informacji. Jeżeli wymagania niefunkcjonalne wyrażone są za pomocą ograniczeń, możesz dołączyć je do historii, jak sugerują James Newkirk i Robert C. Martin [2001] oraz Cohn [2004]. Może to być rozwiązane za pomocą adnotacji.

Skalowanie rejestru produktu Duże projekty niosą nowe wyzwania. Jednym z nich jest skalowanie rejestru produktu. Aby odnieść sukces, stwórz jeden rejestr produktu, zastosuj działania porządkowe na szeroką skalę, a także weź pod uwagę specyficzny punkt widzenia zespołu.

Wykorzystuj jeden rejestr produktu W trakcie pracy nad dużym projektem Scrum upewnij się, że istnieje tylko jeden rejestr produktu zawierający wszystkie elementy niezbędne, by powołać produkt do życia. Unikaj rejestrów specyficznych dla zespołu lub komponentu, które rozkładają wymagania produktu na podsystemy lub komponenty. Generują one znaczące straty, ponieważ wszystkie składowe pochodzą z rejestru produktu; muszą być one również porządkowane i synchronizowane. Postaraj się przydzielać zespołom zadania wprost z rejestru produktu, dając priorytet zespołom tworzącym właściwości przed zespołami tworzącymi komponenty, jak opisałem w rozdziale 1. Darin Fisher, jeden z inżynierów pracujących przy projekcie przeglądarki Chrome, przedstawia kroki, jakie podjął Google, by umożliwić projektowi pracę z jednego rejestru produktu: „Jeśli chodzi o wymagania, wiele decyzji było podejmowanych

SKALOWANIE REJESTRU PRODUKTU

105

w trakcie zebrań z burzą mózgów, tak żeby zespół mógł omówić właściwości. Mieliśmy również otwartą listę mailingową, poprzez którą ludzie mogli dzielić się interesującymi pomysłami. Staraliśmy się skupić na właściwościach i ich minimalistycznej formie. Następnie udostępniliśmy listę całemu zespołowi, a pracownicy sami wybierali to, nad czym chcą pracować”7.

Działania porządkowe na szeroką skalę Elementy rejestru produktu w dużych projektach Scrum są wciąż rozkładane na mniejsze i udoskonalane dokładnie na czas. Ale skala porządkowania się zmienia. Zamiast skupiać się na następnym sprincie, przygotowując rejestr produktu w dużym projekcie, należy myśleć o dwóch lub trzech sprintach naprzód, o czym powiem w rozdziale 4. W konsekwencji szczegółowy rejestr produktu w dużych projektach Scrum jest większy niż ten w mniejszych.

Uwzględnienie odrębnych spojrzeń na rejestr Duże zwinne projekty, które zawierają wiele zespołów tworzących właściwości, mogą wiele zyskać, wykorzystując odrębne spojrzenia na rejestr produktu [Cohn, 2009, 330 – 331]. Każde spojrzenie pokazuje zestaw rejestru produktu. Jeżeli zespół tworzący właściwości pracuje w kolejnych sprintach nad motywem organizera, spojrzenie zespołu na rejestr składa się z odpowiednich zestawów. Spojrzenia mogą powodować konflikty pomiędzy kilkoma właścicielami produktu oraz zespołami pracującymi nad tym samym rejestrem produktu.

7

Wywiad z Darinem Fisherem przeprowadzony przez Colleen Frye na stronie SearchSoftwareQuality.com, data dostępu: 1 października 2008 roku.

106

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Powszechne błędy Mimo że rejestr produktu jest bardzo prostym narzędziem, korzystanie z niego może być trudne. Pamiętaj o występujących powszechnie błędach: specyfikacji wymagań wyglądającej jak rejestr, liście życzeń do Świętego Mikołaja, spychaniu wymagań na zespół, zaniedbywaniu porządkowania rejestru oraz tworzeniu dla jednego zespołu kilku rejestrów.

Ukryte specyfikacje wymagań Specyfikacje wymagań udające rejestr produktu są jak diabeł w przebraniu: ładne, schludne i perfekcyjne. Bywają kuszące, ponieważ odwołują się do naszych pragnień poznania wszystkich wymagań od razu. Taka sytuacja ma jednak ciemną stronę. Rejestr produktu, który ma zbyt wiele szczegółów i jest zbyt złożony, nie wspiera spontanicznego powstawania wymagań. Nie postrzega wymagań jako płynnych i przelotnych, a raczej widzi je jako ustalone i ostateczne; zamraża wszystkie decyzje dotyczące zaspokajania potrzeb klientów na wczesnym etapie projektu. Specyfikacja wymagań przebrana za rejestr produktu jest objawem niezdrowego związku pomiędzy właścicielem produktu a zespołem. Jeżeli natkniesz się na taki rejestr, dowiedz się, czy wizja produktu jest dostępna. Jeżeli tak, opracuj na jej podstawie nowy rejestr produktu i pozbądź się ukrytych specyfikacji wymagań. Jeżeli wizja produktu nie istnieje, stwórz ją. Możesz oczywiście brnąć dalej, siłować się z rejestrem, wydobywać motywy, przepisywać elementy jako user stories oraz zmagać się z przypisywaniem priorytetów poszczególnym elementom. Istnieje jednak marne prawdopodobieństwo, że uda Ci się stworzyć dobry produkt.

POWSZECHNE BŁĘDY

107

Lista życzeń do Świętego Mikołaja Rejestr produktu, który przypomina dziecięcą listę życzeń do Świętego Mikołaja, zawiera wszystko i nic. Taki rejestr nie jest już listą niezałatwionych prac — jest to baza wymagań. Na takiej liście bardzo trudno jest ustalić priorytety, ogranicza ona również możliwości rozwojowe produktu na podstawie opinii użytkowników i klientów, ponieważ zostało zidentyfikowanych zbyt dużo funkcjonalności. Aby określić, które elementy są niezbędne dla stworzenia dobrego produktu, użyj idei produktu lub jego wizji. Resztę wyrzuć.

Określanie wymagań Czasem właściciel produktu sam tworzy rejestr produktu, dostarczając zespołowi gotowy produkt w trakcie zebrania planującego sprint. Takie podejście wzmacnia stary podział na „nich ” i „nas”: właściciel produktu z jednej strony, zespół z drugiej. W ten sposób marnują się wiedza, doświadczenie i kreatywność zespołu, a planowanie sprintu staje się trudniejsze. Upewnij się, że właściciel produktu zawsze angażuje zespół scrumowy w prace porządkowe. Zaplanuj w każdym sprincie jedno lub kilka spotkań warsztatowych służących do uporządkowania rejestru, zaproś na nie cały zespół scrumowy i przypomnij poszczególnym członkom o zarezerwowaniu na te czynności czasu w każdym sprincie. Zawsze pamiętaj o jednej z mantr Manifestu Agile, dotyczącej współpracy: „Ludzie biznesu i deweloperzy muszą ze sobą blisko współpracować codziennie w trakcie trwania całego projektu” [Beck i in., 2001].

Zaniedbywanie porządkowania Większość zebrań planujących sprint, w których brałem udział, była zabawna. Te, które nie były, miały problem z zaniedbanym rejestrem produktu. Kiedy rejestr nie zostanie uporządkowany przed spotkaniem, właściciel produktu i zespół starają się wykonać te czynności naprędce, co pochłania cenny czas i powoduje powstawanie słabych wymagań i zobowiązań bez przekonania. Dodatkowo pod koniec zebrania

108

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

wszyscy są wykończeni. Pamiętaj, że jeśli rejestr produktu nie został prawidłowo uporządkowany, następny sprint nie powinien się rozpocząć. Powinien zostać zawieszony do czasu poprawnego przygotowania rejestru.

Uzupełnianie rejestrów Mój klient miał kiedyś pięciu właścicieli produktu pracujących z jednym zespołem. Ponieważ każdy z nich chciał, by jak największa ilość pracy została zrobiona jak najszybciej, zespół został poproszony o wykorzystywanie wszystkich pięciu rejestrów w każdym sprincie. To trochę uspokoiło właścicieli produktu; wiedzieli oni, że ich wymagania będą uwzględnione w pracy. Sprawiło to również, że byli bardzo nieusatysfakcjonowani: prace znacznie się przeciągały. Zajmowanie się kilkoma produktami jednocześnie może wyglądać dobrze — każdy jest zajęty, toczy się praca nad każdym elementem. Ale nie ma szybkiego postępu. Zespół nie ma spójnego celu sprintu i traci cenny czas na manewrowanie pomiędzy zadaniami. Jeżeli Twój zespół musi pracować nad kilkoma rejestrami, upewnij się, że każdy sprint poświęcony jest tylko jednemu produktowi. Byłoby jeszcze lepiej, gdyby zespół pracował nad jednym produktem przez kilka sprintów, tak by wydanie mogło nastąpić szybciej. Dopiero później należy przejść do następnego produktu. To podejście wymaga ustalenia priorytetów produktów i określenia procesów zarządzania portfolio. Sprawa mojego klienta trafiła w końcu do dyrektora generalnego firmy, który chciał mieć wszystko zrobione „na wczoraj” i trudno mu było ustalać priorytety, jakie prowadziłyby właścicieli produktu.

Spostrzeżenia Uwierz w swoją kreatywność i pozwól, by elementy rejestru produktu pojawiały się spontanicznie. Rejestr powinien być prosty i spójny. Skoncentruj się na elementach, które są niezbędne do powstania

SPOSTRZEŻENIA

109

produktu. Bądź odważny i pozbywaj się elementów niepotrzebnych. W zastosowaniu koncepcji omówionych w tym rozdziale pomogą Ci odpowiedzi na poniższe pytania. W jaki sposób w Twojej firmie odkrywa się i opisuje wymagania? Czy Twój projekt ma cechy DEEP? W jaki sposób porządkujesz swój rejestr produktu? Co należałoby zrobić, by wspólnie odkrywać i opisywać wymagania w każdym sprincie? Jak sobie radzisz z wymaganiami niefunkcjonalnymi? Kiedy i w jaki sposób się je definiuje?

110

ROZDZIAŁ 3. PRACA Z REJESTREM PRODUKTU

Rozdział 4

Planowanie wydania

„Planowanie to pogoń za wartością” — twierdzi Mike Cohn [2005, 5], a planowanie wydań pomaga w rozwoju i wypuszczeniu na rynek dobrego produktu. Planowanie umożliwia dialog pomiędzy zespołem scrumowym a interesariuszami i odpowiada na pytania dotyczące tego, które funkcjonalności i w jakim terminie zostaną stworzone. Planowanie wydań odbywa się w trakcie trwania projektu i jest reakcją zespołu na opinię klientów oraz użytkowników. Przejście od planowania na podstawie dokumentacji i raportów do rozmów i dialogu pozwala zespołowi scrumowemu wykorzystać proste techniki planistyczne, które ułatwiają planowanie i sprawiają, że jest ono bardziej przejrzyste. Mimo że planowanie jest wysiłkiem zespołowym, to właściciel produktu jest odpowiedzialny za podejmowanie odpowiednich decyzji. W tym rozdziale omówię niezbędne koncepcje i techniki planowania wydań. Więcej wyczerpujących materiałów na ten temat znajdziesz w książce Agile Estimating and Planning [Cohn, 2005].

111

112

ROZDZIAŁ 4. PLANOWANIE WYDANIA

Czas, koszt i funkcjonalność Planowanie wydań powinieneś zacząć od podjęcia decyzji dotyczącej tego, który element projektu — czas, koszt czy funkcjonalność — nie może podlegać kompromisom, jeżeli chcesz wykonać dobry produkt. Czy koniecznie musisz się trzymać konkretnej daty wprowadzenia produktu na rynek? Czy budżet jest zamknięty? Czy wszystkie wydania zawarte w rejestrze produktu muszą zostać dostarczone? Trzymanie się zarówno czasu, budżetu, jak i funkcjonalności nie jest możliwe; przynajmniej jeden z tych elementów musi działać jak wentyl bezpieczeństwa. Oto moja rada: czas powinien być ustalony, a funkcjonalności elastyczne. Kurczowe trzymanie się konkretnych funkcjonalności nie jest dobrym pomysłem. Nawet jeżeli istnieje wizja produktu, jego dokładne właściwości oraz funkcjonalności nie są znane wcześniej, a dopiero są odkrywane na podstawie opinii klientów i użytkowników. W miarę poznawania przez zespół scrumowy potrzeb klientów i metod ich spełniania pojawiają się nowe wymogi, które powodują rozwój rejestru produktu. Ustalenie sztywnej listy funkcjonalności uniemożliwi zespołowi dostosowywanie produktu do potrzeb klientów. W rezultacie powstanie słaby produkt — nie taki, jaki pokochają klienci. Określenie daty premiery wydania uzależnione jest od wizji. To ona pomaga ustalić dogodny termin, widełki czasowe, w których należy się zmieścić, by uzyskać określone korzyści. Ustalenie konkretnej daty wydania oszczędza cenny czas. Jeżeli data zostanie przekroczona, okazja minie i wypuszczenie produktu nie będzie już miało sensu. Zauważ, że wybór daty premiery na podstawie rejestru produktu jest trudny, ponieważ to działanie zmusza zespół do zamrożenia wymagań. Takie szacunki są zwykle niewystarczające. Szacunkowe określanie daty wydania na podstawie wymagań może odbiegać od rzeczywistości nawet o 60 – 160% i projekt przewidywany na 20 tygodni może trwać od 12 do nawet 36 [Cohn, 2005, 4]. Ta dobrze znana

CZAS, KOSZT I FUNKCJONALNOŚĆ

113

korelacja zwana jest „rogiem niepewności” (ang. Cone of Uncertainty)1. Możesz uniknąć tych problemów, identyfikując okno możliwości, zamiast próbować oszacować datę wydania. Ustalenie konkretnej daty zapewnia możliwość stworzenia stałego rytmu innowacji. Da się to osiągnąć poprzez wybór tego samego modelu czasowego dla wszystkich wydań. Brzmi niewiarygodnie? Ale to właśnie z powodzeniem zastosowała firma Salesforce.com, główny producent usług na żądanie dotyczących zarządzania relacjami z klientami. Po latach gwałtownego wzrostu w 2006 roku Salesforce.com znalazła się w trudnej sytuacji. Jej możliwość wydawania nowych produktów spadła do zaledwie jednego rocznie, a produktywność gwałtownie się obniżyła. Aby odwrócić zły los, firma postanowiła wprowadzić metodologię Scrum. Chris Fry, wiceprezes rozwoju platformy w Salesforce.com, tak to wyjaśnia2: Decyzja o przyjęciu zwinnej metodyki w Salesforce.com wyrosła z potrzeby stworzenia krótszych, bardziej przewidywalnych wydań. Przez rok nie wypuściliśmy ani jednego większego wydania, chcieliśmy ustalić bardziej przewidywalny harmonogram, tak by wartość była dostarczana klientom regularnie. Od momentu wprowadzenia Scruma Salesforce.com wytworzyła ścisły rytm innowacji. „Cała organizacja przestawiła się z cyklu dwunastomiesięcznego na czteromiesięczny, wypuszczając trzy duże wydania rocznie, wszystkie zgodnie z harmonogramem. W skład prac wchodziły: rozwój oprogramowania, operacje techniczne oraz wewnętrzne systemy IT” — mówi Steve Greene, wiceprezes zarządzania programem i zwinnego rozwoju w Salesforce.com3. Rezultaty były zaskakujące. Salesforce.com doświadczyła niezwykłego, 97-procentowego wzrostu liczby dostarczanych właściwości dzięki wprowadzeniu krótkiego, 1

Róg niepewności został po raz pierwszy zdefiniowany przez Barry’ego Boehma.

2

Wywiad z Chrisem Fry’em, www.agilethinkers.com/chris_fry_salesforcecom_qa/.

3

Komunikacja osobista ze Stevem Greene’em z 16 kwietnia 2009 roku.

114

ROZDZIAŁ 4. PLANOWANIE WYDANIA

stabilnego cyklu wydań. Jednocześnie zdołała zredukować czas niezbędny na opracowanie nowej funkcjonalności o 61%. Szacowanie i planowanie stało się dokładniejsze i bardziej efektywne. Klientom Salesforce.com łatwiej jest teraz planować następne wydania. Bardziej zadowolone są również zespoły deweloperskie [Greene i Fry, 2008]. Ustalenie konkretnej daty oraz wykorzystywanie stabilnych zespołów scrumowych sprawia, że określenie budżetu staje się proste, przy założeniu że czynnikiem decydującym są koszty pracy. Jeśli musisz skalować swój projekt, dokładne przewidywanie budżetu staje się trudniejsze, szczególnie dla projektów rozwijających nowy produkt. Jeżeli istnieje zagrożenie przekroczenia budżetu, właściciel produktu musi wybrać pomiędzy wypuszczeniem produktu z mniejszą liczbą funkcjonalności a wzrostem kosztów poprzez zaangażowanie w projekt większej liczby pracowników, ale tylko jeżeli czas pozwala na zwiększenie produktywności. Firma Apple na przykład, by zmieścić się w ustalonym czasie, podjęła decyzję o podwyższeniu kosztów i zaangażowaniu więcej osób do pracy nad pierwszym projektem iPhone’a. Pamiętaj jednak o prawie Brooksa: „Dodawanie siły roboczej do opóźnionego projektu sprawia, że staje się on jeszcze bardziej opóźniony” [Brooks, 1995, 25]. A co zrobić z projektami o sztywnych ramach budżetowych? Jeśli możesz, unikaj projektów, które mają sztywny budżet i sztywny zakres. Jeżeli nie jest to możliwe, spróbuj podzielić taki projekt na dwie części i pracować nad nimi równocześnie. Celem pierwszego projektu powinno być stworzenie wizji produktu oraz częściowa implementacja wizji w trakcie dwóch lub trzech sprintów. Pod koniec projektu rejestr produktu zmieni się na podstawie opinii zwrotnej klienta. Dzięki temu będziesz w stanie opracować realistyczny plan wydań oraz skalkulować realistyczny budżet dla drugiego projektu, dzięki któremu produkt zostanie powołany do życia. Pamiętaj, że Scrum powoduje zakłócenia w procesie innowacji. Podobnie jak w przypadku każdej innowacji zakłócającej, istniejący klienci mogą nie być skorzy do jej przyjmowania, wydaje im się bowiem, że mają już rozwiązanie, które działa.

ZAMROŻONA JAKOŚĆ

115

Zamrożona jakość Jak już widziałeś, funkcjonalność produktu ewoluuje. Również jego dokładność może w trakcie projektu ulec zwiększeniu, tak jak i wygląd oraz user experience. Ale jakość oprogramowania jest w metodyce Scrum zamrożona. Kryteria jakościowe uwzględnione są w definicji pojęcia „gotowe”. W tej definicji zazwyczaj określany jest wymóg ukończenia pod koniec każdego sprintu możliwego do wdrożenia przyrostu produktu. Tym przyrostem jest przetestowany i udokumentowany element oprogramowania. Zapewnienie jakości oraz środki kontroli są integralną częścią każdego sprintu i nie powinny być przekładane na koniec projektu. Należy się bezwzględnie upewnić, że sprinty dostarczają przyrosty o odpowiedniej jakości. Właściciel produktu nie powinien akceptować rezultatów pracy, które nie spełniają definicji pojęcia „gotowe”, ani zachęcać zespołu do kompromisów dotyczących jakości. Kompromisy dotyczące jakości skutkują bowiem wadliwymi przyrostami produktu, sprawiając, że śledzenie postępu oraz częste i wczesne wydania stają się niemożliwe. Co gorsza, kompromisy dotyczące jakości przynoszą długoterminowe negatywne skutki. Przyczyniają się do powstania długu technologicznego, czyli oprogramowania, które trudno jest rozwinąć i utrzymać [Cunningham, 1992]. Takie działania mogą zniszczyć markę i doprowadzić do niezadowolenia klientów. Kompromisy dotyczące jakości oprogramowania oznaczają zamianę długoterminowego rozwoju na krótkoterminowe zyski. W ten sposób oszukujesz sam siebie.

Wczesne i częste wydania „Naszym najważniejszym priorytetem jest usatysfakcjonowanie klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania” — napisano w Manifeście Agile, zalecając: „Dostarczaj działające

116

ROZDZIAŁ 4. PLANOWANIE WYDANIA

oprogramowanie często, co kilka lub kilkanaście tygodni, najlepiej jak najczęściej” [Beck i in., 2001]. Częste i wczesne oddawanie przyrostów produktu klientom, zamiast jednorazowego wypuszczania gotowego produktu, zapewnia bezcenną informację zwrotną4. Pozwala na ewolucję produktu na podstawie opinii klientów. Zapobiega to implementowaniu przez zespół scrumowy nieodpowiednich właściwości oraz tworzeniu produktu ze zbyt dużą lub zbyt małą liczbą funkcjonalności. W ten sposób tworzony produkt jest odpowiedni. Częste wydania mają dużą moc, ponieważ klienci i użytkownicy mogą wykorzystywać produkt w ich codziennej pracy zamiast oglądania demonstracji w trakcie przeglądów sprintu. Co więcej, wczesne i częste wydania pozwalają zespołowi scrumowemu dotrzeć do większej liczby osób, redukując ryzyko wybrania złej grupy docelowej. Wczesne wydanie oprogramowania ma też inną zaletę: pozwala szybko odkryć braki w wizji, dając możliwość jej ulepszenia lub rezygnacji z projektu na wczesnym etapie. Zespół pracujący nad przeglądarką Google Chrome chciał pierwotnie zlikwidować pasek zakładek. Jednak opinia zwrotna użytkowników pokazała, że niektórzy ludzie korzystają z nawigacji, używając właśnie tego paska. Zespół znalazł nowe rozwiązanie: Chrome uzyskała możliwość importowania ustawień paska zakładek, jeśli zostały one skonfigurowane wcześniej w przeglądarkach Internet Explorer i Firefox. W innym przypadku użytkownicy nie będą mieli paska zakładek, dopóki sami go nie zainstalują. Gdyby nie wczesne wydania przeglądarki, zespół nie odkryłby znaczenia paska zakładek, wypuszczając na rynek niedoskonały produkt. Częste wydania są elementem składającym się na możliwości innowacyjne Google’a, jak zauważył Bernard Girard, autor książki The Google Way: „Szybko wprowadzając 4

Wczesne i częste wydania nie są nowym pomysłem. Rekomendował je już Gilb w swojej ewolucyjnej metodzie dostarczania produktu [Gilb, 1988]. Programowanie ekstremalne również promuje częste wydania, które Beck [2000] nazywa „krótkimi wydaniami”, a Beck i Andres [2005] określają jako „wdrożenie przyrostowe”.

WCZESNE I CZĘSTE WYDANIA

117

produkty na rynek, bez względu na to, czy są one gotowe, czy nie, Google osiąga maksymalne zyski ze swojego wkładu pracy, dystansując potencjalną konkurencję. Strategia Google’a, polegająca na częstym i wczesnym wypuszczaniu produktu na rynek, jest także błyskotliwą i pomysłową strategią marketingową: odstrasza potencjalnych konkurentów, podwyższa koszty wejścia na rynek oraz przytrzymuje użytkowników w strefie wpływów firmy Google” [Girard, 2009, 86]. Wszystko ma jednak swoją cenę, częste wydania również: oprogramowanie musi być wysokiej jakości, a produkt — łatwy do pozyskania i zainstalowania. We wczesnych przyrostach niektóre właściwości mogą być zaimplementowane tylko częściowo. Akceptowalne jest również wypuszczanie funkcjonalności zapewniających użytkownikowi ograniczone korzyści. Ale jakość oprogramowania, zgodnie z definicją pojęcia „gotowe”, musi być najwyższa we wszystkich przyrostach. Pozwala to zespołowi na szybką adaptację produktu w trakcie przyszłych sprintów, a także zapobiega powstawaniu błędów, które niszczą reputację produktu. Zwinne praktyki tworzenia oprogramowania, takie jak budowa oparta na testach i automatyzacja testowania, refaktoring oraz ciągła integracja, umożliwiają stworzenie przyrostów produktu nadających się do wypuszczenia na rynek. Zespoły będą potrzebowały czasu, zanim nauczą się postępować według tych przydatnych praktyk, a stosowanie ich może wymagać zmian środowiskowych i infrastrukturalnych. Jeżeli zainstalowanie lub zdobycie nowych wersji produktu będzie kłopotliwe, klienci odrzucą lub zignorują aktualizacje. Mimo że może to być trudne do osiągnięcia, „każdy większy projekt powinien być rozbity na kilka mniejszych elementów. Nie poddawaj się, nawet jeżeli będziesz musiał zmienić rozwiązania techniczne. Skoncentruj się na rezultatach, nie na technologiach” [Gilb, 1988, 336].

118

ROZDZIAŁ 4. PLANOWANIE WYDANIA

Cykle kwartalne Scrum nie określa, ile powinien trwać projekt. Zazwyczaj zwinne projekty trwają jednak nie dłużej niż trzy do sześciu miesięcy. Jeżeli prace nad Twoim produktem przeciągają się, powinieneś wykorzystać cykle kwartalne, wypuszczając co kwartał co najmniej jedną działającą, przetestowaną oraz udokumentowaną wersję oprogramowania [Beck i Andres, 2005, 47 – 48]. Google wykorzystał cykle kwartalne w trakcie dwóch lat, których potrzebował do stworzenia pierwszej wersji przeglądarki Chrome. Fisher tak opisuje ten proces: „Organizowaliśmy wszystkie prace wokół kwartałów, więc żywy dokument [rejestr produktu] był poddawany przeglądowi co kwartał, na zasadzie: w tym kwartale skupimy się na tym zestawie zagadnień itp. Taki sposób bardzo nam pomógł w rozwoju produktu i upewnieniu się, że na wczesnym etapie był on użyteczny dla pracowników Google’a, od których otrzymywaliśmy opinie zwrotne”5. Inną firmą, która systematycznie wykorzystuje wydania kwartalne, jest PatientKeeper, dostawca produktów ochrony zdrowia. Firma wypuszcza na rynek nowe wersje produktów co trzy miesiące [Sutherland, 2005]. Jest to duże osiągnięcie, ponieważ produkty firmy PatientKeeper są kluczowe dla bezpieczeństwa, potrzebują zatwierdzenia ze strony Agencji Żywności i Leków (ang. Food and Drug Administration, FDA), a także są oddawane do użytku niejednolitym środowiskom szpitalnym. Dzięki temu osiągnięciu firma zyskuje znaczącą przewagę konkurencyjną. Nieprzypadkowo PatientKeeper stała się liderem aplikacji mobilnych związanych z ochroną zdrowia, zostawiając nawet znaczących konkurentów daleko w tyle.

5

Wywiad z Darinem Fisherem przeprowadzony przez Colleen Frye, zamieszczony na SearchSoftwareQuality.com 1 października 2008 roku.

SZYBKOŚĆ

119

Szybkość Szybkość jest wskaźnikiem ilości pracy, jaką może wykonać zespół w trakcie sprintu; pozwala śledzić i przewidywać postęp projektu. Dokładniej można powiedzieć, że szybkość jest sumą wysiłków w trakcie sprintu skutkujących akceptacją wyników pracy przez właściciela produktu. Oto przykład. Na zebraniu planującym sprint zespół zobowiązuje się do dostarczenia trzech historii, na które składa się 12 punktów. Na końcu sprintu właściciel produktu szczegółowo sprawdza przyrost, stwierdzając, że wszystkie wymagania, oprócz jednego, zostały dostarczone zgodnie z definicją pojęcia „gotowe”. Tylko niewielki element dokumentacji historii D nie został ukończony. Ponieważ historia D nie została skończona, punkty odnoszące się do niej nie zostają doliczone do wskaźnika szybkości zespołu, jak pokazano w tabeli 4.1. Suma punktów z zaakceptowanych elementów rejestru wynosi 10. Szybkość zespołu w tym sprincie wyniosła więc 10 punktów. Tabela 4.1. Określanie szybkości Element rejestru produktu

Punkty

Wynik przeglądu

A

1

zaakceptowany

B

3

zaakceptowany

C

1

zaakceptowany

D

2

odrzucony

E

2

zaakceptowany

F

3

zaakceptowany

Jak widać na przykładzie, szybkość najlepiej określić, obserwując umiejętność zespołu do przetwarzania elementów rejestru produktu na przyrosty. „Działające oprogramowanie jest podstawową miarą postępu” — twierdzi Manifest Agile [Beck i in., 2001]. Zauważ, że szybkość może być różna, ponieważ wpływ na nią mają rozmaite

120

ROZDZIAŁ 4. PLANOWANIE WYDANIA

czynniki, w tym dynamika budowania więzi w zespole, przeszkody oraz dostępność. Jeżeli na przykład kilku członków zespołu weźmie wolne, szybkość najprawdopodobniej spadnie. W przypadku nowych zespołów lub produktów prędkość stabilizuje się po dwóch – trzech sprintach [Cohn, 2005, 179]. Szybkość jest specyficzna dla konkretnego zespołu i nie da się jej odnieść do szybkości innych zespołów, chyba że wszyscy wykorzystują punkty o tym samym znaczeniu. Jeżeli zespół 1., rozwijający produkt A, ma szybkość równą 40, a zespół 2., pracujący nad produktem B, ma szybkość 20, nie oznacza to, że pierwszy zespół jest bardziej produktywny. Może on mieć prostsze założenia niż zespół drugi.

Wykres spalania wydania Wykres spalania wydania to podstawowy artefakt służący do śledzenia i przewidywania postępu w metodologii Scrum. Może występować w dwóch postaciach: jako wykres spalania lub belka spalania. Przyjrzyj się najpierw wykresowi spalania.

Wykres spalania Wykres spalania pozwala na śledzenie i przewidywanie postępów projektu [Schwaber i Beedle, 2002, 83 – 88]. Na podstawie szybkości z poprzednich sprintów wykres spalania wydania przewiduje przyszłość, aby zespół scrumowy mógł dostosować produkt i projekt do istniejących wymagań6. Wykres opiera się na dwóch czynnikach: ilości pracy pozostałej w rejestrze produktu oraz czasie. Wykres najlepiej tworzyć i aktualizować w trakcie przeglądów sprintu, kiedy wynik sprintu jest już znany. 6

Kent Beck i Martin Fowler [2000] nazywają to „wczorajszą pogodą”. Zauważ, że ogólne prognozy są akceptowalne, ponieważ postęp jest sprawdzany co kilka tygodni, w trakcie przeglądów sprintu, dając okazję do aktualizacji wykresu spalania wydania oraz dostosowania prognoz.

WYKRES SPALANIA WYDANIA

121

Stworzenie wykresu spalania wydania jest proste. Najpierw rysujesz wykres, wybierając liczbę sprintów jako jednostkę osadzoną na osi x. Na osi y zaznaczasz punkty za historie (lub inną jednostkę mierzącą pracę). Pierwszym elementem jest szacunkowa wartość całego rejestru produktu, obliczona przed rozpoczęciem prac deweloperskich. Kolejny punkt na wykresie ustalisz, określając pozostałą ilość pracy figurującą w rejestrze produktu pod koniec pierwszego sprintu. Następnie rysujesz linię łączącą oba punkty. Ta linia nazywana jest spalaniem. Pokazuje ona tempo realizacji kolejnych punktów z rejestru produktu. Jeżeli przedłużysz linię spalania do osi x, będziesz w stanie przewidzieć orientacyjną datę ukończenia projektu, zakładając, że wkład pracy i prędkość pozostaną na stałym poziomie. Przyjrzyj się przykładowemu wykresowi spalania na rysunku 4.1.

Rysunek 4.1. Wykres spalania wydania

Przedstawia on dwie linie. Linia ciągła odzwierciedla spalanie faktyczne. Pokazuje aktualny postęp oraz pozostałą ilość pracy. Na pierwszy rzut oka widać, że początkowe tempo projektu było wolne. Może to być spowodowane przeszkodami, pojawiającym się ryzykiem, dynamiką kontaktów w zespole lub problemami technicznymi. W trzecim sprincie ilość wykonanej pracy była większa. Mogło to być spowodowane ponownym oszacowaniem elementów rejestru przez zespół lub odkryciem nowych wymagań niezbędnych do realizacji wizji. W czwartym sprincie spalanie nabrało rozpędu — projekt zaczął postępować szybciej. Jeśli przyjrzysz się poprzednim sprintom, będziesz

122

ROZDZIAŁ 4. PLANOWANIE WYDANIA

w stanie stworzyć trend spalania, zaznaczony przerywaną linią na rysunku 4.1. Trend spalania prognozuje postęp w następnych sprintach. Pokazuje, że jeżeli ilość pracy w rejestrze produktu oraz tempo postępu pozostaną stałe, projekt nie zostanie ukończony w trakcie 10 sprintów i będzie opóźniony. Mając tę wiedzę, zespół scrumowy może sprawdzić, dlaczego tak się dzieje. Czy postęp jest zbyt wolny, czy też pracy jest za dużo? Kiedy zespół pozna już przyczynę, będzie mógł podjąć stosowne kroki. Zakładając, że data wydania jest nieprzekraczalna, zespół może zredukować liczbę funkcjonalności lub poprosić o pomoc specjalistę. Wykres spalania musi być wykorzystywany „z głową”, jak mawia mój kolega Stefan Roock. To proste narzędzie, które jest zaprojektowane po to, by stymulować konwersacje i pomagać w badaniach. Rozważnie wybierz okno czasowe i zadecyduj, czy weźmiesz pod uwagę wszystkie sprinty, czy tylko ich część. Musisz wiedzieć, czy którykolwiek ze sprintów wykazywał anomalie, które mogłyby zaburzyć prognozy (na przykład czy członek zespołu chorował, serwer odmówił posłuszeństwa lub też zespół dokonał wyjątkowego postępu), i na tej podstawie dostosować linię trendu. Moim ulubionym narzędziem do tworzenia, aktualizowania i przechowywania wykresu spalania jest kartka papieru przyczepiona do tablicy. Pomaga to w prowadzeniu dialogu i współpracy. Można też uniknąć iluzji dokładności, jaką wywołują raporty elektroniczne. Bez względu na wykorzystywane narzędzie dobrze jest wyeksponować wykres spalania w pomieszczeniu, a także przynosić go na przeglądy przebiegów.

Belka spalania Bardziej wyrafinowaną wersją wykresu spalania jest belka spalania [Cohn, 2005, 221 – 224]. Belka spalania ma wszystkie właściwości wykresu spalania, ale z jednej strony ponownie ocenia elementy oraz wysiłek włożony w pracę, a z drugiej dodawanie i usuwanie elementów rejestru produktu. Jeżeli zespół czyni postęp albo skraca oszacowany

WYKRES SPALANIA WYDANIA

123

czas pracy, góra belki przesuwa się w dół. Jeżeli zespół wydłuży szacowany czas pracy, belka przesunie się w górę. Jeżeli do rejestru zostaną dodane nowe elementy, dół belki obniży się; jeśli z rejestru usunie się elementy lub zastąpi je takimi, które wymagają mniej wysiłku, dół belki podniesie się. Rysunek 4.2 pokazuje przykład belki spalania wydania.

Rysunek 4.2. Belka spalania wydania

Belka na rysunku 4.2 obrazuje tę samą sytuację co wykres spalania na rysunku 4.1. Różnica jest tylko taka, że ten drugi sposób dokładniej pokazuje, co stało się w sprintach trzecim i czwartym. Obniżająca się górna część belek świadczy o tym, że zespół dokonał postępu w obu sprintach. Obniżająca się dolna część belki w sprincie trzecim mówi o tym, że do rejestru zostały dodane nowe elementy. W sprincie czwartym dół belki podniósł się, wskazując na usunięcie elementów z rejestru. Zauważ, że pierwsza belka pokazuje ilość pracy przed pierwszym sprintem. Na rysunku 4.2 są dwie przerywane linie trendu — górna i dolna. Górna reprezentuje trend spalania i tworzona jest w ten sam sposób co wykres spalania. Dolna pokazuje linię zerową.

124

ROZDZIAŁ 4. PLANOWANIE WYDANIA

Plan wydań „Plany są niczym; planowanie jest wszystkim” — twierdził Dwight D. Eisenhower. To spostrzeżenie jest cenne głównie w odniesieniu do planowania wydań. Mimo że zespoły Scruma nie są zobligowane do posiadania planu wydań, muszą te wydania zaplanować. Wiele zespołów scrumowych opiera się na wykresach spalania wydań oraz grupuje elementy rejestru produktu w zestawy, wskazując, które funkcjonalności zostaną dostarczone w poszczególnych wydaniach7. Ale przy dużych projektach, albo takich, które trzeba skoordynować z innymi projektami, partnerami lub dostawcami, najlepiej jest wykorzystywać formalny plan. Plan wydania jest jak ogólna mapa, która prowadzi do celu. Prognozuje wygląd produktu oraz czas, w którym wydanie zostanie wypuszczone. Plan wydania jest zaawansowaną wersją spalania wydania — spalaniem na sterydach. Zapewnia więcej informacji niż spalanie, ale jednocześnie jest bardziej złożony. Plan opiera się na czterech czynnikach: elementach rejestru produktu, pracy pozostałej w rejestrze, szybkości oraz czasie. Plan wydań nie jest zamknięty. Zmienia się wraz z ewolucją rejestru produktu oraz ilości pracy i szybkości. Tak jak w przypadku spalania wydania, plan wydania najlepiej tworzyć i aktualizować wspólnie, w trakcie przeglądu przebiegu. Aby plan spełniał swoje zadanie jak najlepiej, dobrze jest pokazać za pomocą motywów lub tematów funkcjonalność, która będzie dostarczona w każdym wydaniu. Pokazywanie w planie wydania historii zazwyczaj wprowadza zbyt dużo szczegółów. Wyjątkiem są duże projekty, o których opowiem później. Warto również zawrzeć wszelkie informacje niezbędne do koordynacji z innymi oraz uwzględnić znane zmienne wpływające na szybkość, takie jak zmiany składu zespołu lub organizacji projektu. Tabela 4.2 pokazuje przykładowy plan wydania.

7

Zestawy te zwane są również „rejestrami wydań” [Schwaber i Beedle, 2002, 71 – 72].

PLAN WYDAŃ

125

Tabela 4.2. Przykładowy plan wydania Sprint

1

2

3

4

5

6

7

8

prognoza szybkości

–

12 – 32

18 – 28

21 – 28

11 – 18

16 – 23

21 – 28

21 – 28

prędkość rzeczywista

20

25

28

urlopy

beta: konferencje, wiadomości obrazkowe

zależności

wydania

biblioteka obrazów alfa: rozmowy, podstawowe wiadomości tekstowe

wersja 1.0

bieżący sprint

Przykład w tabeli 4.2 pokazuje, że projekt jest aktualnie w trakcie czwartego sprintu i powinien dostarczyć wersję 1.0 po czterech kolejnych sprintach. Każdy sprint trwa dwa tygodnie. Wersja alfa implementująca dwa motywy powinna zostać wypuszczona dla wybranych klientów po czwartym sprincie. Wersja beta z dwoma kolejnymi motywami będzie wypuszczona po szóstym sprincie. Mimo że te wydania zostały nazwane alfa i beta, są one przyrostami produktu zgodnymi z definicją pojęcia „gotowe”. Wersja 1.0 będzie wypuszczona po ośmiu sprintach, czyli czterech miesiącach. W trzecim sprincie oczekiwana jest dostawa. Plan wydania dokumentuje rzeczywistą szybkość i podaje prognozę dla pozostałych sprintów.

126

ROZDZIAŁ 4. PLANOWANIE WYDANIA

Prognozowanie szybkości Prognozowanie szybkości wymaga następujących kroków: jeżeli budowany jest nowy produkt, jeżeli zespół nigdy nie pracował razem lub jego skład znacząco się zmienił, ustala się prędkość na podstawie co najmniej jednego, a najlepiej dwóch lub trzech sprintów. Jak już wspominałem, stabilizacja szybkości może zająć kilka sprintów. Na tej podstawie możesz dokonać prognozy szybkości dla pozostałych sprintów. Według planu wydania w tabeli 4.2 rezultatem byłaby szybkość w granicach od 20 do 28 punktów dla sprintów od czwartego w górę, przy średniej wynoszącej 24 punkty. Możesz także wykorzystać tabelę 4.3 do przewidzenia przyszłej szybkości [Cohn, 2005, 180], tak jak zrobił to zespół scrumowy w przypadku planu wydania z tabeli 4.2. Tabela 4.3. Mnożniki dla szybkości oparte na liczbie skończonych sprintów* Skończone sprinty

Dolny mnożnik

Górny mnożnik

1

0,6

1,60

2

0,8

1,25

3

0,85

1,15

4 i więcej

0,9

1,10

* Z książki Agile Estimating and Planning Mike’a Cohna. Przedrukowane za jego zgodą.

Na podstawie średniej szybkości z trzech pierwszych sprintów w tabeli 4.2 pomnóż 24 przez odpowiedni dolny i górny mnożnik z tabeli 4.3. Rezultatem będzie zakres szybkości pomiędzy 21 a 28 punktów. Po przepracowaniu co najmniej pięciu sprintów możesz stworzyć wiarygodną prognozę [Cohn, 2009, 297 – 300]. Powiedzmy, że jesteś na końcu ósmego sprintu z tabeli 4.2 i chcesz stworzyć prognozę szybkości zespołu w następnym wydaniu. Prędkości w dotychczasowych sprintach są następujące: 20, 25, 28, 26, 16, 20, 26, 26. Musisz pozbyć się ze sprintów danych, które wskazują na anomalie, na przykład

PLAN WYDAŃ

127

faktu choroby połowy zespołu lub kilkudniowej awarii serwera. Następnie posortuj listę w porządku wznoszącym, otrzymując następującą sekwencję: 16, 20, 20, 25, 26, 26, 26, 28. Możesz teraz wykorzystać tabelę 4.4 do określenia przyszłej szybkości z pewnością 90%. Tabela 4.4. Wykorzystaj n-tą najniższą i n-tą najwyższą obserwację z posortowanej listy szybkości, by znaleźć przedział o pewności 90%* Numer obserwacji szybkości

N-ta obserwacja szybkości

5

1

8

2

11

3

13

4

16

5

18

6

21

7

23

8

26

9

* Z książki Succeeding with Agile: Software Develoment Using Scrum Mike’a Cohna. Przedrukowane za jego zgodą.

Ponieważ przeprowadziłeś już osiem sprintów, wybierz drugą obserwację szybkości z początku i końca sekwencji. To daje Ci zakres szybkości w granicach od 20 do 26, ze średnią szybkością równą 23. Masz 90% pewności, że rzeczywista szybkość znajdzie się w tych granicach.

Tworzenie planu wydania Kiedy już stworzysz prognozę szybkości, musisz podzielić pozostałą pracę zawartą w rejestrze produktu przez średnią szybkość lub zakres szybkości, co da liczbę wymaganych sprintów. Następnie musisz oznaczyć zidentyfikowaną liczbę sprintów w kalendarzu i rozważyć czynniki, które mogą wpłynąć na szybkość, a nie zostały uwzględnione

128

ROZDZIAŁ 4. PLANOWANIE WYDANIA

w prognozie szybkości. Mogą do nich należeć: urlopy, wakacje, szkolenia, urlopy zdrowotne oraz planowe zmiany organizacji projektu, takie jak na przykład modyfikacja składu zespołu. Musisz dostosować prognozowaną szybkość dla każdego sprintu osobno. Przyjrzyj się jeszcze raz planowi wydania w tabeli 4.2. Szybkość trzech pierwszych sprintów pokazana jest odpowiednio jako 20, 25 i 28. Średnia szybkość sprintu jest więc równa 24 punktom. Prognozy szybkości stworzone przez zespół scrumowy z wykorzystaniem mnożników z tabeli 4.3 wskazywały na szybkość w granicach od 21 do 28 punktów dla czwartego, siódmego i ósmego sprintu. Plan wydania przewiduje również spadek szybkości w sprintach piątym i szóstym, kiedy kilku członków zespołu będzie miało urlop, a następnie wróci do pracy. Jeżeli praca z rejestru produktu nie będzie mogła zostać dostarczona w wyznaczonym czasie (zakładając, że data wydania jest stała), możesz albo zredukować funkcjonalność, albo zwiększyć budżet i dołączyć do zespołu nowych pracowników (na przykład specjalistów). Moim ulubionym narzędziem do tworzenia planu wydania jest tablica umieszczona w pokoju zespołu. Niektóre tablice mają nawet kółka ułatwiające przeniesienie ich do innego pomieszczenia. Plan wydania można oczywiście przechowywać w formie elektronicznej, na przykład w arkuszu kalkulacyjnym. Bez względu na wykorzystane narzędzie plan powinien być transparentny i ułatwiać dialog pomiędzy zespołem scrumowym a interesariuszami.

Planowanie wydań w dużych projektach Planowanie wydań w dużych projektach wymaga podjęcia dodatkowych działań. Należą do nich: ustalanie wspólnej linii bazowej dla szacunków, przeprowadzanie planowania oraz, jeśli to konieczne, systematyzacja prac.

PLANOWANIE WYDAŃ W DUŻYCH PROJEKTACH

129

Wspólna linia bazowa dla szacunków Kiedy kilka zespołów dokonuje obliczeń szacunkowych w jednym rejestrze produktu, muszą się one porozumieć w sprawie wspólnej linii bazowej, zakresu punktów oraz znaczenia każdej liczby. Jeśli tego nie zrobią, zrozumienie ilości jednostek pracy zawartych w rejestrze produktu będzie bardzo trudne. Jeżeli projekt rozwija się w sposób naturalny, zwykle pojawiają się wspólne szacunki. Pierwszy zespół tworzy pierwotną wersję obliczeń, na podstawie której pracują następne zespoły. Jeżeli od początku trwania projektu w pracę zaangażowanych jest kilka zespołów, reprezentanci każdego z nich powinni przeprowadzić warsztaty, na których ustalone zostaną wspólny zakres oraz semantyka.

Planowanie przyszłościowe Pomoc zespołom w odniesieniu sukcesu przy jednoczesnym optymalizowaniu postępu całego projektu wymaga sporo pracy. Pierwszą rzeczą, jaką należy zrobić, jest spojrzenie o dwa lub trzy sprinty do przodu, co pomaga w wytypowaniu elementów rejestru produktu, nad którym zespół będzie pracował [Cohn, 2005, 206; Pichler, 2008, 146]. Wymaga to wcześniejszej dekompozycji i oczyszczenia elementów rejestru produktu; po wykonaniu tej operacji bardziej szczegółowe elementy znajdą się na szczycie rejestru. Następnym krokiem jest identyfikacja zależności pomiędzy zespołami, którą można określić, zadając następujące pytania: czy zespoły muszą pracować nad tą samą właściwością lub tym samym komponentem? Czy któryś zespół jest dostawcą dla innego zespołu? Jeśli tak, czy jest możliwe dostarczenie danego elementu i wykorzystanie go w tym samym sprincie? Aby wyeliminować problematyczne zależności, konieczna może okazać się zmiana priorytetów w rejestrze produktu. Na przykład zamiast wyznaczać dwa zespoły do pracy w następnym sprincie nad jednym podsystemem, możesz rozważyć przeniesienie niektórych wymagań do dalszych sprintów, koncentrując się na innych elementach. Dostosujesz tym samym priorytety rejestru. Po

130

ROZDZIAŁ 4. PLANOWANIE WYDANIA

rozwiązaniu problematycznych zależności musisz przyjrzeć się ilości pracy dla każdego z zespołów. Czy w następnym sprincie zespół może być przepracowany? Czy możliwości zespołu mogą nie być wykorzystane w pełni? Jeżeli odpowiedź na którekolwiek z powyższych pytań brzmi „tak”, należy wrócić do rejestru produktu i dostosować priorytety. Zanim osiągniesz optymalną równowagę pomiędzy potrzebami poszczególnych zespołów a wymaganiami projektu, będziesz prawdopodobnie musiał przeprowadzić powyższe etapy kilkakrotnie. Kolejnym krokiem jest dodanie historii do następnych dwóch lub trzech sprintów. Zauważ, że to ćwiczenie nie wpływa na możliwości zespołu. Przewidywanie wymagań nie oznacza, że zespół zobowiąże się do ich wykonania. Konsekwencją jest większa ilość pracy. Niestety, nie istnieje żadna alternatywna możliwość. Brak perspektywicznego myślenia jest jak bieganie po lesie w ciemnościach bez latarki. Istnieje duże prawdopodobieństwo, że wpadniesz na drzewo i zrobisz sobie krzywdę.

Systematyzacja Systematyzacja jest ostatecznością. Powinieneś korzystać z tej techniki tylko, jeżeli wszystkie inne możliwości zawiodły. Systematyzacja rozdziela elementy, które powinny być razem. Rozkłada jeden element rejestru produktu na kilka sprintów [Larman, 2004, 251 – 253]. Oto, jak działa systematyzacja: powiedzmy, że zatrudniasz dwa zespoły: A i B. Zespół A ma dostarczyć zespołowi B komponent, na którym ten drugi będzie pracował. Wykorzystując planowanie przyszłościowe, odkrywasz, że wykonanie obu zadań w jednym sprincie jest niemożliwe. Także rozłożenie wymagań na mniejsze elementy okazuje się trudne. Ostatnią deską ratunku jest systematyzacja pracy. Prosisz zespół A o zaimplementowanie komponentu w następnym sprincie, a zespół B o rozwinięcie go w kolejnym. Brzmi to dobrze, ale stwarza podstawowy problem: co będzie stworzone, kiedy zespół A skończy pracę? Jak można się upewnić, że komponent dalej będzie działał tak, jak powinien, kiedy zespół B zacznie

POWSZECHNE BŁĘDY

131

go rozwijać? Ponieważ częściowo ukończona praca nie warunkuje przyznania żadnych punktów, wysiłek zespołu A nie zostanie odzwierciedlony na wykresie spalania wydania, co spowoduje, że postęp prac będzie trudno zauważyć. Co gorsza, trzeba będzie zapewne wykorzystać bufory zasilające, by upewnić się, że zespół A będzie w stanie dostarczyć komponent w określonym czasie [Cohn, 2005, 208]. Bufor zasilający zapewnia wyjście awaryjne, w przypadku gdyby zespół A musiał poświęcić na stworzenie komponentu więcej czasu niż przewidywano. Możesz zredukować konieczność systematyzacji, wykorzystując kiedy to tylko możliwe zespoły tworzące właściwości zamiast zespołów tworzących komponenty.

Powszechne błędy Podczas planowania wydania w trakcie projektu scrumowego unikaj następujących błędów: braku wykorzystania wykresu spalania wydania lub planu wydania, pasywnego właściciela produktu, który nie angażuje się w proces planowania wydania, rozbudowanych wydań, które dostarczają dużą liczbę funkcjonalności za jednym razem, oraz kompromisów związanych z jakością.

Brak wykresu spalania lub planu Spotkałem się już zarówno z organizacjami przyzwyczajonymi do tworzenia szczegółowych planów przed rozpoczęciem projektu, jak i z takimi, które nie praktykowały żadnego planowania wydań. Brak długodystansowego myślenia jest niebezpieczny — łatwo wpaść w pułapkę. W ten sposób trudno jest ocenić postęp projektu i dokonać właściwych adaptacji produktu i projektu. Należy zawsze mieć wykres spalania wydania lub plan wydania. Można go powiesić w pomieszczeniu zespołu oraz na stronach dokumentacji projektu, tak by był widoczny dla każdego.

132

ROZDZIAŁ 4. PLANOWANIE WYDANIA

Właściciel produktu na siedzeniu pasażera Właściciel produktu powinien aktywnie angażować się w planowanie wydań, zamiast obarczać tym obowiązkiem mistrza młyna lub zespół. Planowanie wydania jest ćwiczeniem, które należy wykonywać wspólnie, tak jak doglądanie rejestru produktu. Wymaga to pełnego uczestnictwa właściciela produktu. W zasadzie właściciel produktu powinien przewodzić aktywnościom związanym z planowaniem wydań. Jako osobie odpowiedzialnej przede wszystkim za sukces produktu, właścicielowi produktu powinno zależeć na aktywnym prowadzeniu projektu.

Rozbudowane wydania Informacją, którą przede wszystkim powinieneś z tego rozdziału zapamiętać, jest ta mówiąca o wypuszczaniu wydań wcześnie i często. Unikaj rozbudowanych wydań, które są wypuszczane na rynek dopiero, kiedy implementacja wszystkich funkcjonalności zostanie zakończona. W ten sposób trudne lub niemożliwe staje się uwzględnienie opinii klientów i użytkowników, a szanse na stworzenie produktu, który pokochają ludzie, znacznie maleją. Jest też inna wada. Rozbudowane wydania oznaczają, że zespół po raz pierwszy wdraża oprogramowanie tuż przed wypuszczeniem na rynek. To powoduje stres, który z kolei może wpłynąć na opóźnienia.

Kompromisy związane z jakością Właściciel produktu może czuć pokusę, by wypuścić na rynek większą liczbę funkcjonalności kosztem jakości. W przeszłości mógł to być powszechny sposób na szybsze osiągnięcie postępu. Można trochę oszczędzić, przeprowadzić mniej testów oraz opóźnić tworzenie dokumentacji. Problem polega na tym, że kompromisy związane z jakością prowadzą do stworzenia produktu, który jest trudniejszy i droższy w utrzymaniu i rozwoju. To prawda, że zespół jest w stanie zrobić więcej. Ale za parę miesięcy już tak nie będzie. Oszczędzanie na jakości powoduje również, że zespół może nie być dumny z wykonanej pracy. Podważa to dobre praktyki rzemieślnicze i inżynieryjne. Zespoły

SPOSTRZEŻENIA

133

muszą stworzyć definicję pojęcia „gotowe”, która podaje kryteria konieczne do spełnienia w każdym przyroście, a właściciel produktu musi zastosować te kryteria w każdym przeglądzie sprintu — nie wolno akceptować pracy zrobionej tylko częściowo lub źle. Możesz uprościć planowanie wydań, wprowadzając ramy czasowe i ustalając stabilne tempo innowacji.

Spostrzeżenia Po co czekać na oficjalne wprowadzenie produktu na rynek, żeby sprawdzić, jak zareagują odbiorcy? Wypuszczaj oprogramowanie wcześnie i często, pamiętając o wysokiej jakości. Ucz się od pierwszych klientów i użytkowników, uwzględniając ich opinię w oprogramowaniu. Wypuść oprogramowanie na rynek. Upewnij się, że jest ono odpowiedniej jakości. Jakie będą konsekwencje ustalenia sztywnych ram czasowych oraz jakościowych przy elastycznych wymaganiach dotyczących funkcjonalności? Jakie są zalety wczesnego i częstego wypuszczania oprogramowania? Co należy zrobić, by to osiągnąć? Co należy zrobić, by uporządkować projekty w cykle kwartalne? Jaka jest szybkość Twojego zespołu? Wykorzystujesz wykres czy plan spalania wydania? Kto go tworzy i aktualizuje?

134

ROZDZIAŁ 4. PLANOWANIE WYDANIA

Rozdział 5

Współpraca w trakcie spotkań planujących sprint To nieprawda, że artyści tylko czekają, aż wpadną im do głowy genialne pomysły, które następnie bez żadnego wysiłku przekształcają w niezwykłe arcydzieła. Innowacja wymaga oddania, ciężkiej pracy i dyscypliny. Tak jest w przypadku znanego amerykańskiego malarza i fotografa Chucka Close’a. Jego techniką rozpoznawczą jest malowanie z fotografii. Dzieli on swoje obrazy na małe kwadraty, które wypełnia plamkami przypominającymi piksele. Z bliska widzowie rozpoznają pojedyncze kształty, ale kiedy patrzy się na obraz z daleka, małe piksele zlewają się w portret. Close tak objaśnia metody swojej pracy [Oberkirch, 2008]: Buduję moje obrazy przyrostowo, po kawałku, pracując w sposób podobny do pisarza. Pozytywną stroną pracy metodą przyrostową jest brak konieczności codziennego zaczynania od zera. Dzisiaj wykonałem konkretną pracę. Pracę, która jest namacalna. Nie muszę czekać na inspirację. Nie ma lepszych i gorszych dni. Każdego dnia dobudowuję coś na bazie pracy z poprzedniego dnia. 135

136

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

Na szczęście Scrum zapewnia środki do pracy przyrostowej, które pozwalają na powołanie produktu do życia krok po kroku, poprzez dodawanie w każdym sprincie nowych elementów bazujących na poprzednich. Struktura sprintów ustalana jest na zebraniach. Każdy sprint rozpoczyna zebranie planujące, codzienne zebrania scrumowe zapewniają stały rytm iteracji, a przegląd sprintu i retrospekcja zamykają cykl. Zebrania są cenną okazją do interakcji, dzielenia się spostrzeżeniami i współpracy. Gerry Laybourne, właściciel produktu w firmie Ript (produkującej oprogramowanie do planowania wizualnego), twierdzi [Judy, 2007]: W ciągu roku prac nad oprogramowaniem ominąłem tylko jedno z naszych zebrań, odbywających się co dwa tygodnie. W pozostałych uczestniczyłem z prostego powodu: były niezwykle przyjemne i pozwalały mi się dużo nauczyć. Ten rozdział przeznaczony jest dla właścicieli produktu. Opowiem w nim o zaangażowaniu w zebrania scrumowe, a także podam wskazówki dotyczące efektywnej współpracy z zespołem.

Planowanie sprintu Planowanie sprintu pozwala zespołowi zaplanować pracę i zaangażować się w cel sprintu, kładąc tym samym fundamenty pod samoorganizację. Twoim obowiązkiem jako właściciela produktu jest upewnienie się, że jeszcze przed zebraniem planującym sprint rejestr produktu jest odpowiednio przygotowany, każdy element ma swój priorytet, a te najpilniejsze elementy — także wszystkie szczegóły. Będziesz również musiał uczestniczyć w zebraniu planującym sprint, by objaśnić wymagania i odpowiedzieć na pytania. Twoim zadaniem jest wyjaśnienie zespołowi, co musi zostać zrobione. Zespół sam podejmuje decyzję, ile może zostać zrobione i w jaki sposób. Nie możesz mówić zespołowi, ile pracy powinno być wyko-

DEFINICJA POJĘCIA „GOTOWE”

137

nane w trakcie sprintu, czy też ustalać w imieniu jego członków konkretnych zadań. Jest to wyłączny obowiązek zespołu. Powinien on także zadeklarować tylko tyle pracy, ile realistycznie da się wykonać. Ograniczenie ilości pracy w sprincie do realnych możliwości zespołu stwarza zrównoważone tempo: „Sponsorzy, deweloperzy oraz użytkownicy powinni stale utrzymywać równe tempo” [Beck i in., 2001]. Próby osiągnięcia zbyt ambitnych celów w jednym sprincie nie mają sensu, ponieważ powodują spadek energii w następnym. Scrum preferuje równe, jednolite tempo pracy oparte na rejestrze produktu. Niezawodność jest cenniejsza od fałszywych ambicji, jest ona niezbędna do tworzenia realistycznych prognoz. Zbyt duża presja uniemożliwia zabawę i zaburza kreatywność. Pamiętaj o tym, że zobowiązanie nie jest gwarancją. Zespoły mogą nauczyć się składać realistyczne zobowiązania dopiero po dwóch lub trzech sprintach. Na dodatek rozwój oprogramowania jest pełen niewiadomych, niepewność i ryzyko są przypisane pracy nad innowacjami. Prawo Murphy’ego mówi, że jeżeli coś może pójść źle, to pójdzie. Może pojawić się ryzyko, a problemy nie zawsze zostaną szybko rozwiązane. Zdarza się, że nie uda się osiągnąć celu sprintu — powinien to być jednak wyjątek. Jeśli do tego dojdzie, wykorzystaj retrospekcję sprintu do znalezienia przyczyny oraz identyfikacji metod naprawczych.

Definicja pojęcia „gotowe” W jaki sposób zespół będzie wiedział, że wykonał swoją pracę? W jaki sposób Ty, będąc właścicielem produktu, będziesz w stanie zdecydować, czy dany element został wykonany poprawnie? Wyjściem jest opracowanie definicji pojęcia „gotowe”, czyli opisu kryteriów, które musi spełnić każdy przyrost. Kryteria zwykle mówią o tym, że określone elementy rejestru produktu muszą zostać przetworzone do postaci działającego oprogramowania, które musi być dokładnie przete-

138

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

stowane i adekwatnie udokumentowane. Wymagania muszą być implementowane konsekwentnie, a następnie testowane i dokumentowane w tym samym sprincie. Wyjątkiem od tej reguły jest sprint poświęcony wizji, gdzie celem nie jest budowa działającego oprogramowania, ale zgromadzenie wiedzy tworzącej wizję produktu. Te sprinty mają własną definicję pojęcia „gotowe”. Przed pierwszym sprintem powinieneś spotkać się z mistrzem młyna i zespołem w celu stworzenia definicji pojęcia „gotowe”, zawierającej elementy niezbędne do osiągnięcia w każdym przyroście. Niektóre projekty zawierają w definicji pojęcia „gotowe” konkretne cele, na przykład konieczność przeprowadzenia testu jednostkowego. Kiedy kształt definicji jest już uzgodniony, należy zapisać ją na kartce i powiesić w widocznym miejscu.

Codzienne zebrania scrumowe Codzienne zebrania scrumowe pozwalają zespołowi na zarządzanie jego pracą oraz bezustanne identyfikowanie przeszkód. Jako właściciel produktu powinieneś w miarę możliwości uczestniczyć w tych spotkaniach. Są one doskonałą okazją do oszacowania postępu prac oraz określenia, czy zespół nie potrzebuje pomocy. Może to wymagać od Ciebie udzielania odpowiedzi na pytania, sprawdzania wyników pracy lub pomocy w usuwaniu przeszkód. Możesz również dzielić się wiedzą oraz informować zespół, nad czym pracujesz i co masz w planach. Twoja praca dostarcza cennych informacji dotyczących aktywności na poziomie wydania oraz w całym projekcie. Uczestnicząc w codziennych zebraniach scrumowych, pamiętaj, by nie przeszkadzać zespołowi w jego działaniach samoorganizacyjnych. Nie twórz i nie przydzielaj zadań, nie komentuj, głośno czy poprzez gestykulację, postępu indywidualnych pracowników. Jeśli masz wątpliwości dotyczące postępu prac, podziel się nimi w sposób kon-

REJESTR SPRINTU I WYKRES SPALANIA

139

struktywny, najlepiej zadając pytania1. Jeśli obawiasz się, że cel sprintu nie zostanie osiągnięty, możesz powiedzieć: „Zauważyłem, że na wykresie spalania zostało jeszcze sporo zadań. Czy Was to martwi?”. Zadanie tego pytania spowoduje, że zespół będzie świadomy problemu, ale działanie pozostanie w jego gestii. Przeszkody Zignorowane problemy rozrastają się jak grzyby po deszczu. Dlatego proces Scruma kładzie nacisk na zarządzanie przeszkodami — rozpoznawanie i rozwiązywanie problemów, które hamują postęp i szkodzą projektowi. Członkowie zespołu zgłaszają problemy w trakcie codziennych zebrań scrumowych, a mistrz młyna upewnia się, że zostaną one rozwiązane najszybciej jak się da. Nawet jeżeli usuwanie przeszkód wydaje się spowalniać projekt, niweluje ono opóźnienia spowodowane wystąpieniem znacznie większych problemów. Pascal Denis pisze: „Problemy to skarby. Pozwalają uczyć się i rozwijać” [2006, 19].

Rejestr sprintu i wykres spalania Na rejestr sprintu składają się wszystkie aktywności niezbędne do osiągnięcia celu sprintu. Zespół tworzy rejestr sprintu w trakcie zebrania planującego sprint i aktualizuje go regularnie, co najmniej raz dziennie. W trakcie tych aktualizacji zespół może dodawać nowe aktywności lub usuwać zbędne, zapisuje również ilość pracy pozostałą do wykonania dla każdego zadania. Ja preferuję pracę z tablicą umieszczoną w widocznym dla wszystkich miejscu. Wykres spalania umożliwia zespołowi dostrzeżenie postępu i prawdopodobieństwo osiągnięcia celu sprintu. Dzięki temu zespół jest w stanie modyfikować swoją pracę.

1

Zadawanie pytań w celu przekazania informacji nazywane jest „metodą sokratejską”. Jej nazwa wywodzi się od imienia greckiego filozofa Sokratesa, który wykorzystywał pytania w nauczaniu filozofii.

140

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

Rejestr sprintu oraz wykres spalania służą głównie zespołowi, ułatwiając samoorganizację. Artefakty pomagają właścicielowi produktu określić, czy zespół jest w stanie sprostać swoim zobowiązaniom, ale nie jest to mechanizm wspomagający składanie raportów interesariuszom. Jeśli interesariusze, na przykład klienci lub kierownictwo, są zainteresowani postępami w sprincie, powinni wziąć udział w codziennym zebraniu scrumowym jako obserwatorzy oraz w przeglądzie sprintu jako aktywni uczestnicy.

Przegląd sprintu Przegląd sprintu pomaga w tworzeniu udanego produktu. Daje zespołowi scrumowemu szansę na współpracę z interesariuszami, okazję do sprawdzenia stopnia rozwoju produktu oraz możliwość podjęcia decyzji o jego dalszych losach. Nie trzeba zdawać się jedynie na przypuszczenia, że wszystko idzie zgodnie z planem. Do grupy interesariuszy mogą należeć przedstawiciele marketingu, sprzedaży i usług, a także klienci i użytkownicy. Dokładnie pamiętam rozmowę, jaką odbyłem z klientem firmy Primavera Systems, tworzącej oprogramowanie do zarządzania projektem, programem i portfolio. Klient ten uczestniczył w przeglądach sprintu. Zebrania były dla niego bardzo cenne, podobała mu się ich przejrzystość oraz fakt, że mógł mieć wpływ na rozwój produktu. Pamiętaj, że zebranie musi zostać przygotowane sprawnie. Powinno być ono nieformalne. Zespoły nie mogą pokazywać formalnych prezentacji, należy również unikać wspierania się slajdami. Zebranie nie odbywa się po to, by imponować lub robić wrażenie, ale by zapewnić przejrzystość, a także dokonać inspekcji i adaptacji produktu. Jeśli jesteś właścicielem produktu, masz za zadanie rozpocząć zebranie, porównując przyrost do celu sprintu i sprawdzając w ten sposób, czy cel został osiągnięty, a postęp poczyniony. Upewnij się, że dokładnie zapoznałeś się z przyrostem produktu oraz zaakceptowałeś lub odrzuciłeś każdy element rejestru produktu, nad którym praco-

PRZEGLĄD SPRINTU

141

wał zespół. Najlepszą metodą jest przeprowadzenie kilku testów. Pamiętaj: akceptuj tylko te elementy rejestru, które są zgodne z definicją pojęcia „gotowe”, a w przypadku korzystania z user stories spełniają założone kryteria. Nigdy nie akceptuj elementów nieskończonych lub wadliwych. Tego typu elementy otrzymują zero punktów i są z powrotem wpisywane do rejestru produktu. Pamiętaj, że prowadzenie spisu częściowo wykonanej pracy powoduje rozmycie przejrzystości postępu oraz prowadzi do anomalii w wykresie spalania danego wydania. Twoja informacja zwrotna dla zespołu powinna zawsze być konstruktywna i jasna. Szanuj wysiłek i dobrą wolę. Bądź szczery i prostolinijny. Jeśli jesteś zadowolony z efektów, pochwal zespół. Jeśli jesteś zawiedziony, poinformuj go o tym. Omawiając wyniki sprintu, pamiętaj, że osiągnięcie celu jest pracą zespołową. Zwracaj się więc do całego zespołu, nie do pojedynczych osób. Okaż szacunek swoim kolegom z zespołu scrumowego, bądź świadomy swoich intencji i czynów i zastanów się, jak możesz pomóc zespołowi w dalszej pracy2. Po określeniu postępu poproś interesariuszy o wyrażenie zdania na temat nowego przyrostu. Czy podoba im się to, co widzą? Jakich adaptacji trzeba dokonać, by produkt odniósł sukces? Czy wizja jest nadal aktualna? Czy brak jest jakichś funkcjonalności, czy może jest ich za dużo? Czy właściwości są zaimplementowane w odpowiedni sposób? Czy wygląd powinien zostać poprawiony? Jeśli tak, dlaczego? Na tym etapie odkrycie nowych wymagań lub stwierdzenie, że niektóre elementy rejestru produktu są niepotrzebne, nie jest niczym niezwykłym. Pamiętaj, że opinia interesariuszy pozwoli Waszemu zespołowi zobaczyć przyrost ich oczami, co zmniejszy ryzyko grupowego myślenia. Aby otrzymać doskonałe informacje zwrotne, musisz spełniać oczekiwania interesariuszy. Należy im wyjaśnić, że przyrost produktu we wczesnej fazie może tylko w niewielkim stopniu przy2

Szacunek jest tak istotny w metodzie Scrum, że stanowi jedną z pięciu wartości [Schwaber i Beedle, 2002, 147 – 154]. Pozostałe cztery to: zobowiązanie, koncentracja, otwartość oraz odwaga.

142

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

pominać gotowy produkt, że nowe pomysły i wymagania powinny wspierać wizję oraz że na implementację nowych pomysłów czasem trzeba czekać kilka sprintów, w zależności od priorytetów. Przegląd dokładnie na czas Jako właściciel produktu nie musisz czekać do przeglądu sprintu, by wyrazić opinię na temat rezultatów pracy. Pomocny w tej sytuacji może być przegląd dokładnie na czas (z ang. just-in-time). Daje to zespołowi okazję do dostosowania rezultatów w trakcie sprintu, jeśli będzie taka konieczność. Przegląd dokładnie na czas działa najlepiej, kiedy elementy rejestru przeznaczone do wykonania w danym sprincie są wystarczająco niewielkie, by zespół mógł ukończyć je w ciągu kilku dni.

Retrospekcja sprintu Retrospekcja sprintu pozwala zespołowi scrumowemu na inspekcję rezultatów, identyfikację problemów oraz ich przyczyn, a także pracę nad poprawą jakości i efektywności pracy. Główną ideę retrospekcji trafnie podsumowuje niemieckie powiedzenie: „Refleksja jest pierwszym krokiem w kierunku poprawy”. Jako właściciel produktu powinieneś regularnie brać udział w retrospekcji sprintu. Pozwala to na dzielenie się pomysłami na ulepszenie pracy oraz umocnienie związku z resztą zespołu scrumowego. Szczególnie zapadła mi w pamięć jedna z retrospekcji sprintu u mojego klienta. Przegląd sprintu ujawnił niezgodność oczekiwań pomiędzy właścicielem produktu a zespołem. W konsekwencji właściciel produktu odrzucił większość rezultatów pracy. Członkowie zespołu zdenerwowali się, ponieważ byli pewni, że wykonali dobrą robotę, a właściciel produktu poczuł się przez nich zawiedziony. Kolejną retrospekcję sprintu wykorzystaliśmy do oczyszczenia atmosfery i analizy tego, co się stało, dochodząc do sedna problemu. Dzięki konstruktywnej dyskusji zespół scrumowy zdołał ustalić dwa rozwiązania:

ZEBRANIA W TRAKCIE WIĘKSZYCH PROJEKTÓW

143

właściciel produktu spróbuje znaleźć więcej czasu dla zespołu, a zespół pomoże właścicielowi produktu w aktualizacji rejestru. Bez obecności na zebraniu retrospekcyjnym właściciela produktu zespół miałby trudności w zidentyfikowaniu odpowiednich środków zaradczych. Tworzenie zrównoważonych usprawnień wymaga przyznania przez członków zespołu, że nawet bardzo dobrzy mogą być jeszcze lepsi dzięki skoncentrowaniu się na usuwaniu przeszkód i dążeniu do znalezienia przyczyn niepowodzeń. Wszelkie usprawnienia muszą być możliwe do wykonania i powinny zostać wdrożone w trakcie kolejnego sprintu. Jeżeli niezbędne są większe usprawnienia, takie jak zakup i zainstalowanie nowego serwera produkcyjnego, należy je dodać do rejestru produktu.

Zebrania w trakcie większych projektów Mimo że przy większych projektach harmonogram zebrań pozostaje taki sam, należy go dostosować do nowych potrzeb. W tej części rozdziału omówię niezbędne poprawki.

Wspólne planowanie sprintu Przeprowadzenie zebrania planującego sprint dla wielu zespołów wymaga dodatkowej pracy. Te dodatkowe starania dotyczą przeprowadzania bardziej wnikliwych aktualizacji oraz planowania, jak opisałem w rozdziałach 3. i 4. Duże projekty swoją siłę czerpią z tego, że zespoły (lub chociaż ich reprezentanci) spotykają się na początku każdego zebrania planującego sprint, by omówić cel sprintu, do którego realizacji wszyscy dążą. Kiedy już zespoły przeprowadzą wszystkie działania dotyczące planowania sprintu, powinny zebrać się ponownie, by ustalić, które z wymagań całego projektu zostaną zrealizowane.

144

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

Codzienne zebranie scrumowe dla wszystkich zespołów Zebranie dla wszystkich zespołów pozwoli na codzienną koordynację działań w trakcie sprintu. Przedstawiciele zespołów spotykają się zaraz po codziennych zebraniach scrumowych, by przedyskutować stan prac, zaplanowane czynności oraz zależności pomiędzy zespołami [Schwaber, 2007, 72]. Pamiętaj, że spotkania te mają naturę taktyczną. Nie mogą zastąpić prac przygotowawczych do sprintu, na przykład dokładnego planowania.

Wspólne przeglądy sprintu Efektywny przegląd sprintu przeprowadzony z jednym lub dwoma zespołami, a także klientami, kierownictwem i innymi interesariuszami, jest wystarczającym wyzwaniem. Przy pięciu, dziesięciu lub większej liczbie zespołów znacznie trudniej jest zapanować nad postępem projektu i zdecydować o następnych krokach. Firma Primavera znalazła doskonały sposób na zarządzanie przebiegiem sprintu, w którym często uczestniczyło nawet 15 zespołów. Bob Schatz, były wiceprezes działu rozwoju w tej firmie, wyjaśnia: „Nasze przeglądy sprintu można najlepiej porównać do jarmarków naukowych. Każdy zespół ustawiał stanowisko, przy którym prezentował wyniki swojej pracy. Użytkownicy, interesariusze oraz inne osoby z firmy formowały małe zespoły. Każdy recenzent zaczynał od innego stanowiska. Przeprowadziliśmy 15-minutowe iteracje przy każdym ze stanowisk. Panowała energetyczna, pełna podekscytowania atmosfera” [Schatz, 2009]3. Zgromadzenie zespołów i interesariuszy razem w jednym pomieszczeniu to doskonały sposób na interakcję i zachęcenie wszystkich do dzielenia się spostrzeżeniami. Jeżeli w budynkach firmy nie jest to możliwe, zastanów się nad wykorzystaniem innego miejsca, na przykład sali konferencyjnej, na przynajmniej co drugi przegląd.

3

Zauważ, że właściciele produktu pomogli w prezentacji wyników pracy recenzentom.

POWSZECHNE BŁĘDY

145

Wspólna retrospekcja sprintu Nawet przy dużych projektach Scruma zespoły odnoszą korzyści z retrospekcji oraz wprowadzania własnych metod naprawczych. Ale to nie wystarczy. Aby uzyskać optymalne rezultaty, zespoły powinny zidentyfikować najczęstsze metody naprawcze oraz podzielić się swoimi spostrzeżeniami. Pomogą w tym wspólne retrospekcje sprintu. Najbardziej wydajnym sposobem jest zaangażowanie reprezentantów zespołów. Ułatwia to wymianę poglądów pomiędzy zespołami, ale nie wpływa na kreatywność i wiedzę wszystkich osób pracujących przy projekcie. Alternatywą jest zebranie retrospekcyjne wspólne dla wszystkich zespołów. Takie zebranie jest kosztowne (może zająć pół dnia lub więcej) ale wykorzystuje kolektywną mądrość wszystkich członków zespołów, a także pozwala im na interakcje, wzmacniając tym samym więzy wewnątrz grup. Doskonałym sposobem na zarządzanie wspólną retrospekcją jest wykorzystanie technologii otwartej przestrzeni [Owen, 1997], w której członkowie projektu sami organizują się wokół problemów oraz identyfikują metody naprawcze. Zauważ, że obie opcje da się z powodzeniem łączyć. Firma może wybrać opcję organizowania zebrań reprezentantów zespołów jako podstawową formę spotkań, a wspólną retrospekcję z zaangażowaniem członków wszystkich zespołów organizować po każdym trzecim sprincie.

Powszechne błędy Będąc właścicielem produktu, powinieneś zbudować ścisłą i pełną zaufania współpracę z mistrzem młyna oraz zespołem, by uniknąć następujących częstych błędów: znikający właściciel produktu, pasywny właściciel produktu, zmienne tempo pracy, zasłona dymna oraz raportowanie elementów wykresu spalania.

146

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

Znikający właściciel produktu Znikający właściciel produktu pojawia się na zebraniu planującym sprint, a później znika, by pojawić się na przeglądzie sprintu. Nie współpracuje z zespołem lub robi to w ograniczonym zakresie, kontakt telefoniczny lub e-mailowy jest utrudniony. Czasem mistrz młyna lub jeden z członków zespołu przejmuje jego rolę, zostając zastępczym właścicielem produktu, co ułatwia zespołowi dalszą pracę, ale nie pozwala na rozwiązanie tego problemu. Rola właściciela produktu jest niezbędna dla sukcesu produktu. Musisz więc nadać swoim obowiązkom najwyższy priorytet. Powinieneś spędzać wystarczająco dużo czasu w jednym pomieszczeniu z zespołem, odpowiadać na pytania, dokonywać przeglądu wykonanej pracy oraz usuwać wszelkie przeszkody.

Pasywny właściciel produktu W pomieszczeniu panował tłok. Właściciel produktu, mistrz młyna, zespół, użytkownicy oraz kilku menedżerów liniowych obserwowało ekran komputera. Tester starał się jak najlepiej wytłumaczyć zasady działania przedstawianej funkcjonalności. Właściciel produktu wyglądał na zakłopotanego i powoli odsuwał się od ekranu. Co jakiś czas kiwał głową, mówiąc: „Tak”. Po dziesięciu minutach prezentacja była skończona. Mistrz młyna spojrzał na właściciela produktu i zapytał: „Czy jesteś zadowolony z tego, co widziałeś?”. Właściciel produktu jeszcze raz kiwnął głową i powiedział: „Dobra robota”, a następnie wstał i wyszedł z pokoju. Inni członkowie zespołu scrumowego patrzyli na siebie w milczeniu. „Czas zacząć zebranie” — powiedział mistrz młyna. Wolałbym, żeby ta historyjka była wymyślona. Co więcej, wolałbym być jej świadkiem tylko jeden raz. Niestety, wielokrotnie widziałem właścicieli produktu, którzy w trakcie przeglądów przebiegu zachowywali się jak pasywni widzowie. Ale spotkanie to nie przedstawienie, które się ogląda. Jego celem jest ustalenie, co musi zostać

POWSZECHNE BŁĘDY

147

zrobione, by powstał udany produkt. Jako właściciel produktu musisz aktywnie uczestniczyć w zebraniu, by upewnić się, że produkt ewoluuje w odpowiednim kierunku.

Zmienne tempo pracy „Pomiędzy sprintami nie ma przerw. Nowy zaczyna się już następnego dnia” — wyjaśniam. Uczestnik spotkania podnosi rękę i pyta: „Ale kiedy zespół ma czas, żeby ochłonąć?”. „Nie ma czasu” — odpowiadam. Patrzę na posępne twarze, niektórzy potrząsają głowami. Kontynuuję: „Musicie się upewnić, że zespół jest w stanie wziąć na siebie odpowiednią ilość pracy — tylko tyle elementów rejestru, ile realnie może przerobić na przyrost produktu, bez przepracowania”. Tworzenie produktu jest jak maraton. Jeśli chcesz skończyć projekt, musisz utrzymać stałe tempo pracy. Wielu właścicieli produktu popełnia błąd, naciskając na zespół, by więcej pracował. Może to spowodować chwilowy wzrost tempa pracy, którego nie da się jednak utrzymać. Takie działanie jest nieproduktywne. Sprinty przeobrażają się w miniaturowe marsze śmierci, ludzie szybko się wypalają, chorują lub odchodzą. Jeśli jesteś właścicielem produktu, musisz szanować możliwości zespołu bez względu na rozmiar rejestru produktu. Jeśli postęp jest zbyt wolny, należy zebrać cały zespół i wspólnie poszukać kreatywnego, zdrowego rozwiązania, zamiast zmuszać pracowników do zostawania po godzinach.

Zasłona dymna Jednym z moich ulubionych wspomnień z dzieciństwa są wizyty w wesołym miasteczku. Pewna atrakcja wywarła na mnie szczególnie duże wrażenie: był to labirynt ze ścianami wyłożonymi lustrami, które tworzyły iluzje. Przegląd przebiegu, gdzie pokazywane są kolorowe slajdy lub prezentowane rezultaty, które nie pokrywają się z definicją pojęcia „gotowe”, jest takim właśnie labiryntem. Tworzona iluzja przesłania faktyczny stan rzeczy. Wszystko jest zasłoną dymną. By stworzyć

148

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

odpowiedni stopień przejrzystości, należy zachęcić zespoły do przeprowadzania przeglądów sprintu w realnej atmosferze, bez względu na to, kto w nich uczestniczy. Zespoły mogą prezentować tylko te rezultaty, które są zgodne z definicją pojęcia „gotowe”.

Raportowanie elementów wykresu spalania Niektóre firmy wykorzystują wykresy spalania jako raporty lub dokumenty dla starszego kierownictwa. W obu przypadkach wykorzystywanie tego artefaktu jest nieuzasadnione. Jego podstawowym celem jest pomoc zespołowi w codziennej ocenie postępów oraz w odpowiednim dostosowaniu kolejnych kroków. Wykres spalania nie jest raportem statusu. Wykorzystanie go do takiego celu czyni z wykresu spalania mechanizm kontroli. Prośby kierownictwa o możliwość wglądu w ten dokument są oznaką braku zaufania. Jako właściciel produktu możesz rozwiązać tę sytuację, zapraszając interesariuszy na przegląd przebiegu oraz codzienne zebrania. Do komunikowania postępów należy używać jedynie wykresu spalania dotyczącego wydania lub harmonogramu wydania. Jeśli podstawowym problemem jest konieczność wprowadzenia większej liczby inspekcji, należy zastanowić się nad skróceniem sprintów.

Spostrzeżenia Jako właściciel produktu powinieneś prowadzić swój zespół. Twoje zachowanie ma znaczenie. Duże znaczenie. Przyglądaj się swoim poczynaniom i intencjom. Bądź graczem zespołowym. Bądź otwarty i wspieraj swoich kolegów. Jednocześnie musisz też być twardy i nie bać się wyrażać trudnych opinii w trakcie zebrań. W ocenie swojego zachowania się pomogą Ci odpowiedzi na poniższe pytania. W jaki sposób możesz wspierać zespół w trakcie spotkań planujących sprint bez ingerowania w prawo zespołu do samoorganizacji?

SPOSTRZEŻENIA

149

Co możesz wnieść do codziennych zebrań scrumowych? W jaki sposób możesz ściśle współpracować z zespołem? W jaki sposób możesz sprawić, by przeglądy sprintu były bardziej efektywne? Czy uczestniczysz w retrospekcjach sprintu? Jeśli nie, co należałoby zmienić, byś mógł to robić? Jakie byłyby z tego korzyści?

150

ROZDZIAŁ 5. WSPÓŁPRACA W TRAKCIE SPOTKAŃ PLANUJĄCYCH SPRINT

Rozdział 6

Przejście do roli właściciela produktu

Kiedy poznałem Paula, właściciela produktu pełniącego swoją funkcję po raz pierwszy, zapytał mnie: „Co ja tak naprawdę mam robić i ile czasu mi to zajmie?”. Paul wyjaśnił, że chciał się tylko upewnić co do swoich obowiązków. Był szczególnie zmartwiony czasem, jaki będzie musiał poświęcić, a także niewystarczającym wsparciem od swojego szefa. Paul to nie wyjątek. Wielu nowych właścicieli produktu nie jest pewnych swoich obowiązków, a także samego procesu przejścia do odgrywania nowej roli. Pełnienie tej funkcji po raz pierwszy niesie ze sobą wiele wyzwań i często wymaga zmian zarówno osobistych, jak i organizacyjnych. Te zmiany często są trudne, a niekiedy nawet bolesne. W tym rozdziale porozmawiam bezpośrednio z czytelnikami, którzy dokonują przejścia do roli właściciela produktu, oraz z menedżerami zajmującymi się przyjęciem metodologii Scrum. Więcej wyczerpujących opisów praktyk dotyczących przejścia do nowej roli w metodologii Scrum znajdziesz w opracowaniach Schwabera [2007] oraz Cohna [2009].

151

152

ROZDZIAŁ 6. PRZEJŚCIE DO ROLI WŁAŚCICIELA PRODUKTU

Bycie doskonałym właścicielem produktu Aby zostać doskonałym właścicielem produktu, trzeba przygotować się na poświęcenia, które mogą zabierać wiele czasu. Ta część książki pomoże Ci w przejściu do roli właściciela produktu i ugruntowaniu swojej pozycji.

Poznaj siebie Pierwszym krokiem do stania się doskonałym właścicielem produktu jest zrozumienie, kim jesteś i o jakim rozwoju zawodowym myślisz. Zastanów się nad swoimi umiejętnościami i zdolnościami, a także porównaj je z obowiązkami właściciela produktu. Zidentyfikuj te aspekty stanowiska, które mogą sprawiać Ci trudności. Jak już wspomniałem w rozdziale 1., rola właściciela produktu jest wieloaspektowa. Bardzo trudne, a czasem niemożliwe jest znalezienie nowego właściciela produktu, który posiadałby wszystkie niezbędne umiejętności. Musisz więc być przygotowany na odkrycie braków we własnej wiedzy i w umiejętnościach. Przykładowo: Jan ma duże doświadczenie w kontaktach z klientami oraz przy tworzeniu map produktu, ale brakuje mu umiejętności pisania dobrych user stories oraz tworzenia planów wydań. Anna natomiast umie rozpisywać wymagania i zna się na planowaniu wydań, ale brak jej umiejętności tworzenia wizji. Oboje będą musieli skupić się na doskonaleniu swoich umiejętności i pracować nad słabościami. Lyssa Adkins, autorka książki Coaching Agile Teams, stworzyła listę porad dla nowych właścicieli produktu, którą zaprezentowałem w tabeli 6.11.

Rozwijaj się Ocena własnego potencjału rozwoju pozwoli Ci wybrać odpowiednie metody treningowe. Przyszłym właścicielom produktu zwykle przydają się szkolenia dla właścicieli produktu w metodologii Scrum, na których 1

Komunikacja prywatna z Lyssą Adkins z 29 czerwca 2009 roku.

BYCIE DOSKONAŁYM WŁAŚCICIELEM PRODUKTU

153

Tabela 6.1. Wytyczne dla właścicieli produktu Co robić

Czego nie robić

Mów, co musi zostać zrobione.

Nie mów, jak to musi być zrobione ani ile czasu to zajmie.

Stawiaj zespołowi wyzwania.

Nie tyranizuj zespołu.

Zainteresuj się stworzeniem zespołu o wysokiej wydajności.

Nie koncentruj się wyłącznie na celach krótkoterminowych.

Ćwicz myślenie skoncentrowane na celach biznesowych.

Nie trzymaj się kurczowo oryginalnego zakresu projektu.

Chroń zespół przed hałasami z zewnątrz.

Nie stresuj zespołu opowiadaniem o możliwych zmianach, dopóki nie są one konieczne.

Wprowadzaj zmiany pomiędzy sprintami.

Nie pozwól, by zmiany wkradły się niepostrzeżenie w trakcie sprintu.

w szybkim tempie mogą przyswoić niezbędną wiedzę. Ale nie chodzi tylko o informacje. Nowy właściciel produktu powinien przyjąć etos pracy według zwinnej metodyki i zacząć żyć według wartości Scruma: poświęcić się produktowi i zespołowi, skoncentrować się na obowiązkach właściciela produktu, być otwartym, szanować ludzi, z którymi pracuje, oraz mieć odwagę, by robić to, co należy, w odpowiedni sposób [Schwaber i Beedle, 2002, 147 – 154]. Bądź graczem zespołowym i ufaj kolegom z zespołu scrumowego. Daj sobie czas, by przyzwyczaić się do nowej roli. Nie da się wykonywać swojej pracy perfekcyjnie od samego początku, popełnianie błędów jest częścią procesu uczenia się. Bądź cierpliwy, ale nigdy beztroski. Kiedy zaczniesz już wykonywać obowiązki właściciela produktu, będziesz w stanie wyraźniej dostrzec swoje mocne i słabe strony. Skorzystaj z retrospektywy sprintu, by otrzymać dotyczącą Twojej pracy informację zwrotną od mistrza młyna i zespołu.

154

ROZDZIAŁ 6. PRZEJŚCIE DO ROLI WŁAŚCICIELA PRODUKTU

Zdobądź trenera Oprócz uczestnictwa w szkoleniach oraz czytania książek dotyczących procesu Scrum właściciel produktu grający tę rolę po raz pierwszy może dużo zyskać z coachingu. Trener jest jak lustro pozwalające nowemu właścicielowi produktu na dojrzenie efektu, jaki wywołują jego własne słowa i czyny. Podobnie było z Paulem, właścicielem produktu wspomnianym na początku rozdziału. Kiedy zacząłem z nim pracować w charakterze trenera, nie był przyzwyczajony do ścisłej współpracy z deweloperami. Czuł się niekomfortowo w trakcie przeglądów sprintu, wygłaszając zbyt surowe opinie lub nie odzywając się wcale. Paul nie był świadom swojego zachowania, dopóki nie zwróciłem mu na nie uwagi. Wspólnie przemyśleliśmy, jak sprawić, by te spotkania były bardziej efektywne i przyjemne dla wszystkich. Najbardziej przydatna dla Paula okazała się zasada mówiąca o tym, żeby być krytycznym w stosunku do problemów, a nie do ludzi. Po naszej dyskusji Paul zaczął rozwiązywać problemy w sposób konstruktywny i zauważać dobrą wolę i wysiłek wkładany przez zespół. Innym modelem coachingowym, który sprawdza się w takich sytuacjach, jest model nauki rzemiosła. Przyjrzyj się przykładowi jednego z moich klientów. Sarah, kierowniczka działu biznesu, rozpoczęła pracę na stanowisku właściciela produktu przed pierwszym wydaniem nowego produktu. Szybko zdała sobie sprawę, że nie będzie miała wystarczającej ilości czasu do wypełniania tych obowiązków długoterminowo. Krótko po rozpoczęciu projektu Sarah zaangażowała jako asystenta Toma, jednego ze swoich pracowników. W ten sposób Tom miał czas, by wszystkiego się nauczyć. Kiedy pierwsze wydanie zostało szczęśliwie wdrożone, Sarah mogła płynnie przekazać obowiązki właściciela produktu Tomowi.

Upewnij się, że sponsoring pochodzi z właściwego poziomu Aby efektywnie wykonywać pracę właściciela produktu, musisz mieć niesłabnące zaufanie i wsparcie ze strony kierownictwa. W zależności od organizacji oraz sytuacji odpowiednim poziomem może być wi-

TWORZENIE DOSKONAŁYCH WŁAŚCICIELI PRODUKTU

155

ceprezes ds. zarządzania produktem, kierownik działu biznesu, zespół liderów lub dyrektor generalny. By osiągnąć niezbędne wsparcie i uwagę kierownictwa, musisz poinformować je o wadze swojego stanowiska oraz o zasięgu upoważnień i odpowiedzialności. Bez sponsoringu pochodzącego z odpowiedniego poziomu nie zdobędziesz odpowiednich upoważnień, a w konsekwencji trudno Ci będzie dobrze wykonywać swoją pracę.

Jeszcze nie skończyłeś Po kilku miesiącach pracy na nowym stanowisku, kiedy największe przeszkody zostały już pokonane, możesz poczuć się pewniej. To świetnie, że udało Ci się dotrzeć do tego etapu, ale nie poprzestawaj na tym. Rozwijaj się, ciągle rozmyślając o swojej pracy. Słuchaj, co na temat Twojej pracy mają do powiedzenia koledzy z zespołu scrumowego, a także pracuj nad uzupełnianiem luk w wiedzy i umiejętnościach. Doskonałym sposobem na robienie postępów jest przyłączenie się do społeczności właścicieli produktu, gdzie można wymieniać się pomysłami, doświadczeniem oraz na podstawie warsztatów tworzyć dobre praktyki2.

Tworzenie doskonałych właścicieli produktu Mimo że każdy właściciel produktu musi wziąć odpowiedzialność za wykonywanie swojej pracy, jest kilka rzeczy, które może zrobić menedżer zajmujący się implementacją metody Scrum, by stworzyć właścicielowi produktu odpowiednie warunki rozwoju. Ta część rozdziału opisuje to, co Ty jako lider lub menedżer powinieneś zrobić.

2

Cohn [2009, 70 – 79] szczegółowo omawia działalność społeczności, które wspierają adaptację metody Scrum.

156

ROZDZIAŁ 6. PRZEJŚCIE DO ROLI WŁAŚCICIELA PRODUKTU

Doceń wagę roli Kierownictwo musi docenić autorytet i odpowiedzialność przypisaną roli właściciela produktu oraz wpływ, jaki ta rola może mieć na całą organizację. Jest to nie tylko niezbędne, by zwinna metodologia zarządzania produktem mogła zadziałać, lecz także, by sukcesem zakończyła się każda adaptacja metody Scrum. Zgadza się z tym Schwaber [2007, 85]. Do niedawna odbierałem związek pomiędzy zarządzaniem produktem a jego rozwojem jako jedną z wielu zmian, które dokonują się podczas adaptacji metody Scrum. Teraz jestem pewien, że jest to najważniejsza ze zmian, podpora całego procesu adaptacji. Jeśli ta zmiana zakończy się sukcesem, metoda Scrum będzie wykorzystywana i przyniesie nowe zyski. Jeśli zmiana się nie uda, Scrum nie zagrzeje miejsca w przedsiębiorstwie.

Wybierz odpowiednich właścicieli produktu Właścicieli produktu należy wybierać ostrożnie. Jako menedżer musisz wziąć pod uwagę nie tylko pożądane cechy charakteru właściciela produktu (opisane w rozdziale 1.), ale także inne czynniki, w tym sam produkt, branżę oraz rozmiar projektu. Najlepszy właściciel produktu dla jednego projektu może być znacznie mniej odpowiedni dla drugiego. Co więcej, każda firma musi znaleźć własny pomysł na obsadzenie stanowiska właściciela produktu. W Salesforce.com menedżer produktu pełni funkcję właściciela produktu i pracuje w tym samym dziale. W firmie mobile.de stanowiska właścicieli produktu obsadzone są pracownikami z zespołów biznesowych. Każdy zespół jest odpowiedzialny za kilka produktów lub za właściwości produktów3. Wszystko, co dotyczy Scruma, należy najpierw przetestować, a dopiero 3

Komunikacja prywatna z Brettem Queenerem, starszym wiceprezesem ds. produktów w firmie Salesforce.com, z 9 czerwca 2009 roku, oraz z Philipem Misslerem, dyrektorem technologicznym w mobile.de, z 18 czerwca 2009 roku.

TWORZENIE DOSKONAŁYCH WŁAŚCICIELI PRODUKTU

157

później oceniać. Po przeprowadzeniu kilku projektów Scruma optymalne podejście do obsadzenia roli właściciela produktu powinno wyklarować się samo.

Upoważniaj i wspieraj właścicieli produktu Właściciele produktu, którzy odgrywają tę rolę po raz pierwszy, potrzebują czasu, zaufania i wsparcia, by móc rozwinąć się na nowym stanowisku. Jest bardzo prawdopodobne, że nowy właściciel produktu będzie popełniał błędy dotyczące zarówno braku angażowania interesariuszy, jak i powodowania zakłóceń w sprincie. Jest to część procesu uczenia się. Jako doświadczony menedżer powinieneś pomóc mu zminimalizować liczbę błędów, zapewniając odpowiednie szkolenia oraz coaching. „Odpowiednie szkolenia oraz wczesne zagłębienie się właścicieli produktu w pryncypia zwinnych metodyk, tworzenie rejestru produktu, projektowanie user stories oraz tworzenie szacunków i planów jest kluczem do sukcesu każdego zespołu pracującego według zwinnych metodyk. Poza wstępnym szkoleniem niezbędne jest objęcie właściciela produktu opieką coachingową w trakcie wdrażania go w nowe obowiązki, aby nowe procesy zakorzeniły się w kulturze pracy” — piszą o swoich doświadczeniach w Salesforce.com Fry i Greene. Radzą oni również firmom, by „sięgnęły po pomoc profesjonalistów. Zewnętrzni trenerzy robili to już kiedyś i będą w stanie rozpoznać przeszkody wcześniej niż Ty. Mogą również pomóc Ci w uczeniu się od innych organizacji, które dokonały podobnego przejścia” [2007, 139]. Poza zapewnieniem odpowiedniego szkolenia możesz pomóc właścicielowi produktu, dając mu odpowiednie uprawnienia oraz upewniając się, że ma on wystarczającą ilość czasu, by właściwie wykonać swoją pracę. Właściciel produktu, który nie ma wystarczających uprawnień, by móc decydować, czy dana właściwość wejdzie w skład wydania, bardzo szybko straci wiarygodność w oczach członków zespołu scrumowego oraz interesariuszy. Pamiętaj, że praca w charakterze właściciela produktu jest zwykle pełnoetatowa. Jeżeli osoba peł-

158

ROZDZIAŁ 6. PRZEJŚCIE DO ROLI WŁAŚCICIELA PRODUKTU

niąca tę funkcję będzie przepracowana, ucierpi na tym cały projekt. Uwolnienie właściciela produktu od innych obowiązków pozwoli mu na skoncentrowanie się w pełni na projekcie.

Wspieraj wdrażanie roli właściciela produktu Wspieranie wdrażania roli właściciela produktu wymaga stworzenia niezbędnych procedur organizacyjnych, aby możliwe było kształcenie nowych właścicieli produktu. Wykracza to poza zapewnienie organizacji niezbędnej wiedzy. Należy stworzyć wszechstronny program rozwoju oraz powołać do życia społeczność właścicieli produktu. Doskonałym sposobem na stworzenie takiego programu jest oparcie go na kolektywnej wiedzy właścicieli produktu oraz włączenie samych zainteresowanych w jego budowanie. W tym celu można przeprowadzać regularne warsztaty właścicieli produktu, które pomogą zidentyfikować dobre praktyki oraz metody naprawcze. Czasem do ugruntowania roli właściciela produktu niezbędne są zmiany w organizacji. Popatrz na przykład CSG Systems, firmy tworzącej oprogramowanie do zarządzania interakcjami z klientem. Mauricio Zamora, dyrektor wykonawczy, tak wyjaśnia podejście firmy [Leffingwell, 2009]: Najpierw tłumaczyliśmy wszystkim różnice pomiędzy tradycyjnym zarządzaniem produktem, rolą właściciela produktu w zwinnej metodyce oraz rolą architekta. Następnie musieliśmy przekonać kierownictwo, że stanowisko właściciela produktu wymaga więcej uwagi. Przejrzystość, którą zapewnia zwinna metoda, pozwala na dostrzeżenie i naprawienie coraz wyraźniejszych błędów dotyczących tego stanowiska. Na końcu musieliśmy dokonać przeglądu i reorganizacji tytułów stanowisk w firmie oraz wprowadzić kompensacje, ponieważ nowe stanowisko właściciela produktu nie wpisywało się w istniejącą strukturę firmy.

SPOSTRZEŻENIA

159

Do innych zmian należą: stworzenie nowych ścieżek kariery i dostosowanie istniejących, modyfikacja kryteriów wyboru pracowników, stworzenie nowych programów rozwoju oraz, dla niektórych firm, wprowadzenie nowych struktur organizacyjnych.

Spostrzeżenia Efektywne wykorzystywanie stanowiska właściciela produktu to nie tylko kamień milowy w pracy ze zwinnymi metodami zarządzania produktem. Jest to również proces nauczania, który przechodzą zarówno osoby pełniące tę funkcję, jak i cała organizacja. Osobom dokonującym przejścia do roli właściciela produktu pomogą w tym odpowiedzi na poniższe pytania. Które aspekty roli będą dla Ciebie najtrudniejsze? W jaki sposób możesz posiąść niezbędną wiedzę, która zapewni Ci dobry start? Kto może pomóc Ci rozwinąć się na stanowisku właściciela produktu? Czy w Twojej firmie pracują też inni właściciele produktu, z którymi możesz się kontaktować? Wyższa kadra kierownicza odgrywa kluczową rolę w wyborze i szkoleniu właścicieli produktu, ale także we wprowadzaniu metody Scrum do organizacji. Poniższe pytania powinni przeczytać liderzy, którzy zamierzają wprowadzić stanowisko właściciela produktu w swojej organizacji. Jaki wpływ rola właściciela produktu będzie miała na organizację? Co jest najważniejsze dla większości właścicieli produktu, którzy odnieśli sukces?

160

ROZDZIAŁ 6. PRZEJŚCIE DO ROLI WŁAŚCICIELA PRODUKTU

Jak możesz pomóc właścicielom produktu w wykonywaniu ich obowiązków? W jaki sposób firma może wspierać efektywne wdrożenie roli właściciela produktu?

Źródła

37Signals, 2006, Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application. https://gettingreal.37signals.com/. Anthony S.D., Johnson M.W., Sinfield J.V., Altman E.J., 2008, The Innovator’s Guide to Growth: Putting Disruptive Innovations to Work, Harvard Business School Press. Beck K., 2000, Extreme Programming Explained: Embrace Change, Addison-Wesley. Beck K., Andres C., 2005, Extreme Programming Explained: Embrace Change, Addison-Wesley. Beck K., Beedle M., Bennekum van A., Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffries R., Kern J., Marick B., Martin R.C., Mellor S., Schwaber K., Sutherland J., Thomas D., 2001, The Manifesto for Agile Software Development, http://agilemanifesto.org/ i http://agilemanifesto.org/principles.html. Beck K., Fowler M., 2000, Planning Extreme Programming, Addison-Wesley.

161

162

ŹRÓDŁA

Brooks F.P., 1995, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley. Bryson J.M., 2004, What to Do When Stakeholders Matter: Stakeholder Identification and Analysis Techniques, „Public Management Review”, vol. 6, nr 1, s. 21 – 53. Carroll L., 1986, Alicja w Krainie Czarów, przeł. R. Stiller, Alfa (pierwotnie opublikowana w 1865 r.). Catmull E., 2008, How Pixar Fosters Collective Creativity, „Harvard Business Review”, wrzesień, s. 64 – 72. Christensen C.M., 1997, The Innovator’s Dilemma: When Technologies Cause Great Firms to Fail, Harvard Business School Press. Cockburn A., 2005, Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley. Cohn M., 2004, User Stories Applied: For Agile Software Development, Addison-Wesley. Cohn M., 2005, Agile Estimating and Planning, Prentice Hall. Cohn M., 2008, Writing the Product Backlog Just Enough and Just in Time, Scrum Alliance, www.scrumalliance.org/articles/87-writingthe-product-backlog-just-enough-and-just-in-time. Cohn M., 2009, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley. Conway M.E., 1968, How Do Committees Invent?, „Datamation”, kwiecień, s. 28 – 31. Cooper A., 1999, The Inmates Are Running the Asylum: Why HighTech Products Drive Us Crazy and How to Restore Sanity, Sams Publishing. Cooper R.G., 2001, Winning at New Products: Accelerating the Process from Idea to Launch, Perseus.

ZARZĄDZANIE PROJEKTAMI ZE SCRUM

163

Cunningham W., 1992, The WyCash Portfolio Management System, OOPSLA 1992 Experience Report, http://c2.com/doc/oopsla92.html. DeMarco T., Hruschka P., Lister T., Robertson S., Robertson J., McMenamin S., 2008, Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior, Dorset House. Denne M., Cleland-Huang J., 2004, Software by Numbers: Low-Risk, High-Return Development, Sun Microsystems Press. Dennis P., 2006, Getting the Right Things Done: A Leader’s Guide to Planning and Execution, Lean Enterprise Institute. Finkelstein S., Campbell A., Whitehead J., 2009, Think Again: Why Good Leaders Make Bad Decisions and How to Keep It from Happening to You, Harvard Business School Press. Fry Ch., Greene S., 2007, Large Scale Agile Transformation in an OnDemand World, materiały zaprezentowane w ramach konferencji AGILE 2007, 13 – 17 sierpnia, IEEE, s. 136 – 142. Gilb T., 1988, Principles of Software Engineering Management, Addison-Wesley. Girard B., 2009, The Google Way: How One Company Is Revolutionizing Management as We Know It, No Starch Press. Greene S., Fry Ch., 2008, Year of Living Dangerously: How Salesforce.com Delivered Extraordinary Results through a »Big-Bang« Enterprise Agile Revolution, prezentacja przedstawiona w trakcie Scrum Gathering, Chicago, kwiecień. Highsmith J., 2009, Agile Project Management: Creating Innovative Products, Addison-Wesley. Judy K.H., 2007, CEO and Team: Collective Product Ownership at Oxygen Media, prezentacja przedstawiona w trakcie Scrum Gathering, London, listopad.

164

ŹRÓDŁA

Kaner S., Lind L., Toldi C., Fisk S., Berger D., 1996, Facilitator’s Guide to Participatory Decision-Making, New Society Publishers. Kano N., 1984, Attractive Quality and Must-Be Quality, „Journal of the Japanese Society for Quality Control”, kwiecień, s. 39 – 48. Larman C., 2004, Agile and Iterative Development: A Manager’s Guide, Addison-Wesley. Larman C., Vodde B., 2009, Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley. Leffingwell D., 2009, The Product Owner in the Agile Enterprise, „Agile Journal”, 6 kwietnia. Levitt T., 1960, Marketing Myopia, „Harvard Business Review” vol. 38, nr 4, s. 45 – 56. Levy S., 2008, Inside Chrome: The Secret Project to Crush IE and Remake the Web, „Wired”, nr 16 (październik), www.wired.com/techbiz/it/magazine/16-10/mf_chrome. Lidwell W., Holden K., Butler J., 2003, Universal Principles of Design, Rockport Publishers. Lynn G.S., Reilly R.R., 2002, Blockbusters: The Five Keys to Developing Great New Products, HarperCollins. Maeda J., 2006, The Laws of Simplicity, MIT Press. Mayer M., 2006, Nine Lessons Learned about Creativity at Google, prezentacja na Uniwersytecie Stanforda, maj. Moore G.A., 2006, Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers, Collins Business Essentials. Newkirk J., Martin R.C., 2001, Extreme Programming in Practice, Addison-Wesley.

ZARZĄDZANIE PROJEKTAMI ZE SCRUM

165

Oberkirch B., 2008, Working in Close, 43 Folders, listopad, www.43folders.com/2008/01/11/working-close. Owen H., 1997, Open Space Technology: A User’s Guide, BerrettKoehler Publishers. Pichler R., 2008, Scrum — Agiles Projektmanagement erfolgreich einsetzen, dpunkt.verlag. Poppendieck M., Poppendieck T., 2003, Lean Software Development: An Agile Toolkit for Software Development Managers, Addison-Wesley. Reinertsen D.G., 1997, Managing the Design Factory: A Product Developer’s Toolkit, Free Press. Schatz B., 2009, The Sprint Review: Mastering the Art of Feedback, www.scrumalliance.org/articles/124-the-sprintreview-mastering-theart-of-feedback,. Schmidkonz Ch., 2008, Product Owner at SAP — A New Job Title Developed, prezentacja na ObjektForum, Stuttgart, wrzesień. Schwaber K., 2004, Agile Project Management with Scrum, Microsoft Press. Schwaber K., 2007, The Enterprise and Scrum, Microsoft Press. Schwaber K., 2011, Przewodnik po Scrumie, tłum. T. Włodarek, K. Terlecka, B. Baraszkiewicz i in., www.scrum.org/Portals/0/Documents/ScrumGuides/Scrum_ Guide_PL.pdf, październik. Schwaber K., Beedle M., 2002, Agile Software Development with SCRUM, Prentice Hall. Senge P.M., 2006, The Fifth Discipline: The Art and Practice of the Learning Organization, Random House. Simons M., 2004, Distributed Agile Development and the Death of Distance, „Cutter Consortium Executive Report, Sourcing and Vendor Relationships”, vol. 5, nr 4.

166

ŹRÓDŁA

Smith P.G., Merritt G.M., 2002, Proactive Risk Management: Controlling Uncertainty in Product Development, Productivity Press. Smith P.G., Reinertsen D.G., 1998, Developing Products in Half the Time: New Rules, New Tools, John Wiley and Sons. Sutherland J., 2005, Future of Scrum: Parallel Pipelining of Sprints in Complex Projects, Proceedings of the Agile Development Conference, s. 90 – 102. Wake B., 2003, INVEST in Good Stories, and SMART Tasks, sierpień, www.xp123.com/xplor/xp0308/index.shtml. Womack J., Jones D.T., 2005, Lean Solutions: How Companies and Customers Can Create Value and Wealth Together, Simon and Schuster.

Skorowidz A Apple, 55, 59, 62, 74, 88, 114 atrybuty produktu, 64

B błędy, 46 Brzytwa Ockhama, 62 budżet, 112

G główny właściciel produktu, 41 Google, 60, 63, 66, 89, 116, 118

H hierarchia właścicieli produktu, 42, 43

I C Chief Product Owner, Patrz główny właściciel produktu Chrome, 104 Chucka Close, 135 cykle kwartalne, 118 czas, 112

D Darin Fisher, 104 data premiery wydania, 112 dekompozycja elementów, 95 dekompozycja epików, 96

E efektywna wizja produktu, 54 epiki, 85, 141 Expertcity, 58, 59

F FDA, 118 funkcjonalność, 112

interfejs użytkownika, 63

J John Maeda, 62

K Ken Schwaber, 30 klarowność, 97 komitet właścicieli produktu, 50 koszt, 112

M makiety, 68 mapa produktu, 72 marketer produktu, 40 menedżer produktu, 31 projektu, 31, 40 metodologia Scrum, 15 minimalna wersja produktu, 58, 59, 73 mistrz młyna, 36, 82

167

mnożniki dla szybkości, 126 mobile.de, 37 Model Kano, 71 funkcje wydajnościowe, 71 funkcjonalności uszczęśliwiające, 71 podstawowe funkcje, 71 możliwość testowania, 97

O odległy właściciel produktu, 48 Office, 73 ogólne historie, Patrz epiki określanie wymagań, 107 opakowanie poglądowe, 70

P paraliż analityczny, 76 pasywny właściciel produktu, 146 persony, 69 plan wydania, 124, 127 planowanie sprintu, 136, 143 wydania, 111 przyszłościowe, 129 pojęcie „gotowe, 137 poker planistyczny, 99 Polycom, 53 potrzeby klientów, 64 prawo Brooksa, 114 primus inter pares, 33 prognozowanie szybkości, 126 prostota, 61

168

SKOROWIDZ

prototypy, 68 przegląd sprintu, 140, 144 przepracowanie, 47 punkty, 98

R refaktoryzacja architektury, 74 rejestr produktu, 79, 86, 104, 124 cechy, 80 nowo powstający, 81 odkrywanie elementów, 84 opisywanie elementów, 85 porządkowanie, 81 skalowanie, 104 szacunkowy, 81 ustalanie struktury, 86 wystarczająco szczegółowy, 80 zawierający priorytety, 81 rejestr sprintu, 139 ustalanie priorytetów, 87 retrospekcja sprintu, 142, 145 Robert G. Cooper, 58 rola właściciela produktu, 29 Roman Pichler, 27 ryzyko, 89

S Salesforce, 18, 113, 157 scenariusze, 69 scrum, 22, 67, 72, 79, 82, 124, 146, 144 skalowanie roli właściciela produktu, 41 smartfon, 59 spalanie belka spalania, 122 wydania, 121 sponsoring, 154

sprint, 92, 93, 115, 119, 135 planowanie, 136 wybór celu, 92 systematyzacja, 130 szkic produktu, 54 szybkość, 119

T techniki facylitacji, 33 Theodore Levitt, 39 trener, 154

U ukryte specyfikacje wymagań, 106 uprawnienia, 46 user experience, 35, 59, 63, 68 user stories, 68, 152, 157

V Visio, 73

W waga roli, 156 warianty produktu, 73 wartość, 88 wielkość elementów, 98 William Ockham, 62 wizja produktu, 54, 72, 112 cechy, 55 krótka i zwięzła, 57 obszerna i angażująca, 56 techniki tworzenia, 68 wspólna i jednocząca, 56 wizje profetyczne, 75 właściciel produktu, 15, 18, 30, 32, 34, 35, 45, 46, 82, 87, 132, 140, 151, 152, 156

o podzielonych obowiązkach, 48 o zbyt małych uprawnieniach, 46 odległy, 48 przepracowany, 47 zastępczy, 49 wspólna linia bazowa dla szacunków, 129 wydania częste, 115 wydanie wczesne, 115 wykonalność, 97 wykres spalania, 131, 139, 148 wydania, 120 wymagania funkcjonalne, 91 wymagania niefunkcjonalne, 101, 102, 103

Z zakresy punktów, 99 zależności, 91 zamrożona jakość, 115 zasłona dymna, 147 zastępczy właściciel produktu, 49 zdatność do wypuszczenia na rynek, 90 zebrania scrumowe, 138, 144 zespół, 36, 82, 85, 87, 88, 99, 114, 119 złożona hierarchia właścicieli produktu, 44 zmienne tempo pracy, 147 znikający właściciel produktu, 146 zrównoważone tempo, 137 zwinne zarządzanie produktem, 22