Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00344 006664 13245909 na godz. na dobę w sumie
Zarządzanie projektami ze Scrum. Twórz produkty, które pokochają klienci - książka
Zarządzanie projektami ze Scrum. Twórz produkty, które pokochają klienci - książka
Autor: Liczba stron: 168
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-8526-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).

Twoja przepustka do nowoczesnego zarządzania projektami!

Współczesne projekty wymagają niezwykłej elastyczności i błyskawicznego dostosowywania się do panujących warunków. Czasy ogromnych projektów, gdy klient przez wiele miesięcy czekał na produkt, odchodzą w niepamięć. W zwinnych metodologiach zarządzania kluczowe jest regularne dostarczanie kolejnych wersji produktu w krótkich odstępach czasu. Dzięki temu na bieżąco kontrolowany jest kierunek rozwoju, a ewentualna korekta nie przysparza problemów. Już teraz poznaj kluczowe zasady zwinnego zarządzania projektami!

W trakcie lektury tej książki poznasz jedną z najpopularniejszych metodyk - Scrum. Dowiesz się, jakie role definiuje Scrum i jaki jest zakres obowiązków wszystkich osób związanych z projektem. Nauczysz się tworzyć wizję produktu, pracować z jego rejestrem oraz planować wydanie. Kluczowym pojęciem w Scrumie jest sprint. Poznaj jego specyfikę, zasady prowadzenia oraz techniki kontrolowania postępów prac. Koniecznie zwróć uwagę na najczęściej popełniane błędy. Dostarcz produkt na czas, poczuj satysfakcję i odnieś sukces - to się opłaci!

Dzięki tej książce:

Skutecznie zarządzaj projektami!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Agile Product Management with Scrum: Creating Products that Customers Love Tłumaczenie: Katarzyna Żarnowska ISBN: 978-83-246-8526-4 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: helion@helion.pl 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 Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność 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 Kup książkęPoleć książkę 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 Kup książkęPoleć książkę 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 Kup książkęPoleć książkę 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 Kup książkęPoleć książkę 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 Kup książkęPoleć książkę 14 SPIS TREŚCI Kup książkęPoleć książkę 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 priory- tety. 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 od- powiedzialny za zarządzanie rejestrem produktu, mistrz młyna, ze- spół 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 efek- tywnego porządkowania. Dodatkowo przyjrzysz się kilku skompli- kowanym zastosowaniom rejestru, w tym obchodzeniu się z wyma- ganiami niefunkcjonalnymi oraz skalowaniu rejestru produktu dla dużych projektów. 79 Kup książkęPoleć książkę 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 do- głę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 szcze- gół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 zrozu- mieć” — piszą Schwaber i Beedle [2002, 33]. Kierowanie się tymi wytycz- nymi pozwala na utrzymanie zwięzłości rejestru i upewnienie się, że ele- menty, nad którymi zespoły będą prawdopodobnie pracować w następnym sprincie, są na to przygotowane. W konsekwencji wymagania są odkrywa- ne, 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. Kup książkęPoleć książkę 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 roz- miarów elementu pomaga w nadaniu mu odpowiedniego priorytetu oraz zaplanowaniu wydania. Szczegółowe szacunki na poziomie za- dań 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. Ist- niejące elementy są regularnie modyfikowane, dopracowywane, usu- wane lub zmienia się im priorytet. Zawierający priorytety Wszystkie elementy rejestru produktów mają priorytety. Te najważniej- sze, o najwyższym priorytecie, implementowane są jako pierwsze. Można je znaleźć na szczycie rejestru produktu, jak pokazano na rysun- ku 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 zanie- dbany 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. Pa- miętaj, że nie jest konieczne przeprowadzanie ich w podanej kolejności. (cid:374) Nowe elementy są odkrywane i opisywane, a istniejące zmieniane lub usuwane. Kup książkęPoleć książkę 82 ROZDZIAŁ 3.PRACA Z REJESTREM PRODUKTU (cid:374) Poszczególnym elementom rejestru produktu nadaje się priorytet. Najważniejsze elementy znajdują się na górze. (cid:374) Elementy o wysokim priorytecie przygotowywane są na nadcho- dzące planowanie sprintu; rozkłada się je na mniejsze elementy i dopracowuje. (cid:374) 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 upewnie- nie się, iż rejestr produktu znajduje się w dobrym stanie, porządkowa- nie 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 po- rządkowaniem [Schwaber, 2007]; interesariusze są angażowani w miarę potrzeb. Wymagania nie są już przekazywane zespołowi, ich autora- mi 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 po- czucie więzi i wspólnej własności. Niektóre zespoły lubią przeprowadzać porządkowanie po codzien- nym zebraniu scrumowym, innym wystarczą sesje tygodniowe lub dłuższe warsztaty pod koniec każdego sprintu. Porządkowanie odby- wa się również w trakcie przeglądu sprintu, kiedy zespół scrumowy i interesariusze omawiają następne kroki; identyfikowane są nowe Kup książkęPoleć książkę ODKRYWANIE I OPISYWANIE ELEMENTÓW 83 elementy rejestru, a stare usuwane. Upewnij się, że proces porządko- wy 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 wa- runkiem udanego zebrania planującego sprint. Do wspierania tych czynności przyda się doskonałe narzędzie: pa- pierowe 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 elek- troniczne 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 spo- tkaniu 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że- ró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. Kup książkęPoleć książkę 84 ROZDZIAŁ 3.PRACA Z REJESTREM PRODUKTU Odkrywanie elementów Odkrywanie elementów rejestru produktu rozpoczyna się wraz z uzu- pełnieniem rejestru. Najlepiej, kiedy zespół scrumowy i, jeśli to ko- nieczne, interesariusze pracują nad tym wspólnie, wymyślając ele- menty niezbędne do powołania produktu do życia. Mogą przy tym korzystać z idei produktu, jego wizji czy też mapy produktu. W trak- cie 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ć pro- dukt 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żyt- kownikó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ę stop- niowo, 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ólnio- ne 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 trak- cie warsztatów porządkowych, kiedy zespół scrumowy ustala priory- tety i rozkłada elementy rejestru produktu na mniejsze części. Ujaw- niają 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 reje- stru, upewnij się, że wynikające z niego wymagania klienta są zrozu- miałe. Zapytaj, dlaczego jest ono konieczne oraz jakie korzyści przy- Kup książkęPoleć książkę ODKRYWANIE I OPISYWANIE ELEMENTÓW 85 niesie klientom. Nie kopiuj wymagań bezmyślnie do rejestru pro- duktu, 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ł. Wyma- ganie 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 stop- nia, ż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żyt- kowniku korzystającym z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji czy warunki, które muszą być spełnione, by hi- storia 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 sto- ries, 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 za- wartość. Powinny być proste. Wykorzystuj tylko te artefakty, które po- mogą zespołowi scrumowemu w przybliżeniu się do gotowego produktu. Kup książkęPoleć książkę 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 prioryte- tów i ułatwiają dostęp do informacji. Przykładowymi motywami dla telefonu komórkowego będą: e-mail, kalendarz, komunikacja głoso- wa i organizer. Najważniejszą zasadą jest przypisanie na samym po- czą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óżnia- nie w rejestrze elementów ogólnych, takich jak epiki, oraz szczegóło- wych, 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 ze- spół prognoz dotyczących elementów rozmiar tych ostatnich jest zapi- sywany. Zauważ, że strukturę w tabeli 3.1 można wdrożyć niezależnie od narzędzia wykorzystywanego do tworzenia rejestru produktu. Wy- starczy odpowiednio rozłożyć papierowe karty na tablicy lub ścianie biura. Kup książkęPoleć książkę USTALANIE PRIORYTETÓW REJESTRU PRODUKTU 87 Ustalanie priorytetów rejestru produktu Nigdy nie zapomnę dnia, w którym zasugerowałem menedżerce pro- duktu 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 do- stanie to, czego naprawdę potrzebuje. Za ustalenie priorytetów dla każ- dego elementu rejestru produktu odpowiedzialny jest właściciel pro- duktu. Tak jak i inne czynności związane z porządkowaniem, ustalanie priorytetów najlepiej przeprowadzić przy udziale całego zespołu scru- mowego. 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 reje- stru 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 dodat- kowej 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 naj- pierw 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 od- powiedzialnym momentem” [Poppendieck i Poppendieck, 2003]. Kup książkęPoleć książkę 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 ustala- niu 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 przy- szł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 funk- cjonalności umożliwiającej kopiowanie i wklejanie, co nie wpłynęło negatywnie na sukces produktu. Jeżeli element rzeczywiście jest niezbęd- ny, 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 ukry- tymi 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. Kup książkęPoleć książkę 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. Ze- spół 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 wymienio- nych właściwości. Krótko po wypuszczeniu produktu na rynek za- częł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ści- wość jest ważniejsza, byłoby trudniejsze. Celowo wypuszczając okro- joną 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 po- wstają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, nie- pewne i ryzykowne elementy powinny mieć wysoki priorytet. Przy- spiesza 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 po- winny zostać zbadane i przetestowane poprzez zebranie opinii klientów Kup książkęPoleć książkę 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 doty- czą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 środo- wisku, szczególnie w niestworzonym procesie budowy lub niezlokali- zowanym zespole scrumowym. Walka z niepewnymi, ryzykownymi elementami na wczesnym eta- pie może spowodować wczesną porażkę. Wczesna porażka pozwala ze- społ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 trakto- wane 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 oma- wianej 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. Kup książkęPoleć książkę 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 niefunkcjonal- nych. Jeżeli kilka zespołów pracuje razem, zależności między nimi mo- gą 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 roz- dzielanie elementów to dwie powszechne techniki radzenia sobie z za- leżnymi user stories [Cohn, 2004, 17]. Przyjrzyj się dwóm przykłado- wym 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 po- mysł, ponieważ powstała historia będzie bardzo rozbudowana. Dru- gim wyjściem jest podzielenie wymagań w inny sposób. Jeżeli wspólna funkcjonalność („Jako użytkownik chcę mieć możliwość pisania”) zo- stanie zapisana osobno, te dwie historie nie będą już od siebie za- leżne. W ten sposób na dotyczące ich prognozy nie ma już wpływu kolejność wykonywania. Kup książkęPoleć książkę 92 ROZDZIAŁ 3.PRACA Z REJESTREM PRODUKTU Przygotowanie do planowania sprintu Przed każdym spotkaniem planującym sprint muszą zostać przy- gotowane elementy rejestru produktu, nad którymi zespół będzie pracował w następnej kolejności. Przygotowania zaczyna się od wy- brania celu sprintu. Wybór celu sprintu Cel sprintu podsumowuje oczekiwany wynik sprintu. Powinien przy- bliż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żo- wanie pracowników. Cele sprintu przynoszą korzyści z kilku powodów. (cid:374) Tworzą wspólną płaszczyznę pomiędzy właścicielem produktu, mistrzem młyna oraz zespołem: wszyscy pracują, aby osiągnąć jeden cel. (cid:374) Minimalizują zmiany, ograniczając typ wymagań, nad którym ze- spół będzie pracował w danym sprincie. Można to zrobić, wybie- rając elementy z tego samego motywu. Ułatwia to bliską współpracę i pomaga w osiągnięciu określonej szybkości. (cid:374) Ułatwiają komunikację z interesariuszami dotyczącą tego, nad czym pracuje zespół. Kup książkęPoleć książkę 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 doda- wanie elementów na szczycie listy. Być może będziesz zmuszony do dokonania wyboru pomiędzy spójnym celem sprintu a sprawną pra- cą nad projektem. Kiedy cel zostanie już ustalony, wszystkie sto- sowne 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 sku- pieniu 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 zainwe- stować w opisywanie elementów rejestru produktu, oraz utrzymuje spis szczegółowych elementów na odpowiednim poziomie — zapew- nianie większej ilości informacji niż to konieczne jest marnotraw- stwem. Dodając szczegóły tylko do elementów, które najprawdopo- dobniej 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. Kup książkęPoleć książkę 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 ze- społ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 wy- magania minimalizują ilość bieżącej pracy oraz ryzyko otrzymania na koniec sprintu elementów częściowych i wadliwych. Dodatkowo nie- wielkie 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ć. Kup książkęPoleć książkę 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ą wy- magań” [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 reje- strze 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 tema- tu”, „Podanie odbiorcy” oraz „Ustalanie priorytetów”. Istnieją inne user stories, które również muszą zostać zdekompo- nowane, w tym historie złożone oraz historie z rozbudowanymi kry- teriami. 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 ele- mentów, które rozwiązują tę niepewność, tworząc odpowiednią bazę wiedzy, na przykład: „Zbadanie JavaServer Faces jako technologii in- terfejsu użytkownika”. Jeżeli historia opisuje zbyt dużą liczbę funkcjo- nalności, należy je podzielić, by umożliwić przyrostową dostawę funk- cjonalnoś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”. Kup książkęPoleć książkę 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ę kryte- rió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żli- wość kasowania wiadomości tekstowych”. Kryterium akceptacji mówi: „Mogę wybrać jakąkolwiek wiadomość. Mogę usunąć tekst wiado- moś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 teksto- wych, historię odnoszącą się do edytowania wiadomości tekstowych oraz historię dotyczącą zapisywania zmodyfikowanych wiadomości. Kup książkęPoleć książkę 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 ro- zumieją jego semantykę. Wspólne opisywanie wymagań oraz wyra- żanie elementów rejestru produktu w prosty i zwięzły sposób wspo- maga przejrzystość. Element umożliwia testowanie, jeżeli istnieje efektywny sposób sprawdzenia w trakcie bieżącego sprintu, czy wy- maganie zostało spełnione. Historie muszą mieć kryteria akcepto- walnoś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 eksplora- cja elementu wymaga dużego nakładu sił, powinno się ją przeprowa- dzić w osobnym sprincie, na przykład z wykorzystaniem jednorazo- wego prototypu, który pomoże w projektowaniu interfejsu. 4 Bill Wake sugeruje, że historie powinny być niezależne, negocjowalne, wartościo- we, 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 roz- dziale dotyczącym ustalania priorytetów, razem z metodami określania szacunków. Negocjowanie odnosi się do możliwości dostosowania user stories. Historia jest obiet- nicą konwersacji, jak twierdzi Ron Jeffries, a nie twardym wymogiem. Kup książkęPoleć książkę 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 przy- gotowanie. 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ę dostosowy- wanie rozmiaru elementów w rejestrze produktu. Elementy rejestru produktu są szacowane, kiedy odkrywa się nowe lub modyfikuje ist- niejące oraz kiedy zespół orientuje się, że rozmiar elementu się zmie- nił. Potrzebujesz miary, która jest szybka i prosta w użyciu. Moją ulu- bioną są punkty5. Punkty Punkty to miara ogólna i relatywna, dotycząca włożonego wysiłku i roz- miaru 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 od- niesienia. 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. Kup książkęPoleć książkę DOSTOSOWYWANIE WIELKOŚCI ELEMENTÓW 99 Tabela 3.2. Popularne zakresy punktów Punkty Rozmiar koszulki 0 1 2 3 5 8 13 20 gratis, element został już stworzony XS S M L XL XXL XXXL bardzo mały mały średni duży bardzo duży bardzo bardzo duży olbrzymi Nielinearna sekwencja z tabeli 3.2 przyspiesza proces podejmo- wania decyzji przez zespół. Zapobiega długim dyskusjom na temat odpowiednich wartości, które mogą pojawić się w przypadku se- kwencji 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 techni- ki, 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, uzgod- nione wcześniej, wartości punktów. Gdybyś wykorzystywał zakres z ta- beli 3.2, talia zawierałaby osiem kart, a każda z kart — jeden z punktów zakresu. Po rozdaniu uczestnikom kart rozpoczyna się szacowanie. Kup książkęPoleć książkę 100 ROZDZIAŁ 3.PRACA Z REJESTREM PRODUKTU Jeżeli zespół wyznacza wielkość elementów rejestru po raz pierw- szy, wskazane jest określenie znaczenia wartości zakresu. Aby to zro- bić, 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 za- kresem, może zacząć od elementu mającego najwyższy priorytet i stop- niowo schodzić w dół rejestru. Zanim zespół dokona szacunków, właściciel produktu musi ob- jaśnić element wszystkim członkom zespołu, którzy następnie oma- wiają kolejne kroki niezbędne do wdrożenia produktu zgodnie z de- finicją 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ą obraz- kiem 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 najbar- dziej zróżnicowane, argumentuje swój wybór. Następnie przeprowa- dzana 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ą po- dejmowania decyzji jest konsensus, wszyscy członkowie zespołu po- winni 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. Kup książkęPoleć książkę DOSTOSOWYWANIE WIELKOŚCI ELEMENTÓW 101 Szacowanie wymagań niefunkcjonalnych Dla wymagań niefunkcjonalnych, które dotyczą wszystkich wymagań funkcjo- nalnych (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ść pra- cy, tak jak w przypadku odkrywania różnych opcji projektów interfejsu użytkow- nika 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 dostar- czenie 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 przy- rost wiedzy, na przykład: „Stworzenie prototypu lub makiety poma- gają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 reje- stru produktu. Właściciel produktu i mistrz młyna nie powinni do- konywać 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 jed- nak 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 Kup książkęPoleć książkę 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 elemen- tó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 opera- cyjnymi, 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 zgod- nością (na przykład wspieranie protokołu lub możliwość uzyskania certyfikatu). Mają one wpływ na projekt interfejsu użytkownika, archi- tekturę, wybór technologii oraz na ostateczny koszt produktu i długość jego życia. W tej części rozdziału opowiem o opisywaniu niefunkcjo- nalnych 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ć wydaj- ność w sposób przedstawiony na rysunku 3.4. Wymagania dotyczące user experience najłatwiej zapisuje się w po- staci szkiców, scenopisów, diagramów nawigacyjnych interfejsu użyt- kownika i prototypów. Moje doświadczenie sugeruje, że zespoły wolą tego rodzaju artefakty niż wytyczne dotyczące interfejsu użytkowni- ka przedstawione w formie graficznej. Kup książkęPoleć książkę 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 po- kazane na rysunku 3.4. Globalne wymagania niefunkcjonalne po- winny być jak najwcześniej szczegółowo opisane — w trakcie two- rzenia 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 pro- dukt 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 Wymagania ogólne Wymagania szczegółowe Wysiłek Wymagania niefunkcjonalne E-mail Tworzenie e- maila Jako przedsiębiorca chcę mieć możliwość podania tematu e-maila 1 Produkt musi odpowiedzieć na zapytanie w czasie poniżej jednej sekundy Kup książkęPoleć książkę 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 pro- duktu musi spełniać te same wymagania. Z drugiej strony, lokalne wymagan
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Zarządzanie projektami ze Scrum. Twórz produkty, które pokochają klienci
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: