Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00500 006399 11255538 na godz. na dobę w sumie
Zwinne projekty w klasycznej organizacji. Scrum, Kanban, XP - książka
Zwinne projekty w klasycznej organizacji. Scrum, Kanban, XP - książka
Autor: Liczba stron: 200
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-8843-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).

Klasyczna organizacja też może być zwinna!

Dynamika zmian w dzisiejszym świecie IT wymaga niezwykłej elastyczności i błyskawicznego adaptowania się do nowych warunków. Klasyczne techniki zarządzania projektami nie są w stanie podołać takiemu wyzwaniu, dlatego rynek zdobywają techniki zwinne — Scrum, Kanban i XP. Już dawno udowodniły one swą skuteczność i są świadomie wybierane przy nowych projektach. Zastanawiasz się, czy możesz wprowadzić te techniki w Twojej organizacji? Szukasz skutecznego sposobu realizacji tego zadania? Na te i dziesiątki innych trudnych pytań odpowiada ta niezwykła książka!

Znajdziesz w niej liczne studia przypadków, przygotowane przez ekspertów z bogatym doświadczeniem w codziennej pracy nad zwinnymi projektami. W trakcie lektury poznasz pułapki, jakie na Ciebie czyhają, oraz dowiesz się, jak sprytnie je ominąć. Ponadto przekonasz się, jak wprowadzić Scruma do klasycznej organizacji lub projektu z ustalonym budżetem. Poznasz również takie problemy, w przypadku których Kanban sprawdzi się wyśmienicie. Zwróć także uwagę na rozdział poświęcony przejrzystości w organizacji — to ona leży u podstaw sukcesu zwinnych metodyk. Książka ta jest obowiązkową lekturą dla wszystkich osób interesujących się zarządzaniem projektami, mających ambicję lub obowiązek wprowadzenia zwinnych technik w swojej organizacji.

Dzięki tej książce:

Zarządzaj zwinnie projektami!

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

Darmowy fragment publikacji:

Tytuł oryginału: Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen Tłumaczenie: Dawid Zieliński (wstęp, 1 – 6, dodatki), Sławomir Kupisz (rozdz. 7 – 9), Bartosz Sałbut (rozdz. 10 – 13) ISBN: 978-83-246-8843-2 Copyright © 2012 by dpunkt.verlag GmbH, Heidelberg, Germany. Title of the German original: Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen ISBN 978-3-89864-752-6 Translation copyright © 2014 by Grupa HELION SA. All rights reserved. All rights reserved. No part of this book may be 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 the Publisher. 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/zwipro 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(cid:258)ci Przedmowa 9 13 1 Wst(cid:218)p Jak czyta(cid:202) t(cid:218) ksi(cid:200)(cid:285)k(cid:218) ........................................................................................................................13 1.1. 1.2. Studia projektów ...............................................................................................................................13 1.3. Dodatek ............................................................................................................................................15 2 Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em 17 2.1. Pobudka ...........................................................................................................................................17 2.2. Zespó(cid:239) si(cid:218) formuje ............................................................................................................................18 2.3. W(cid:239)a(cid:258)ciwe zlecenie ............................................................................................................................19 2.4. Od partyzantki do zwinno(cid:258)ci .............................................................................................................20 Kompleks Scruma ............................................................................................................................21 2.5. 2.6. Zwyci(cid:218)stwa i pora(cid:285)ki .........................................................................................................................22 Planowanie Sprintu (cz(cid:218)(cid:258)(cid:202) I) .............................................................................................................23 2.7. 2.8. Planowanie Sprintu (cz(cid:218)(cid:258)(cid:202) II) ............................................................................................................24 2.9. Codzienny M(cid:239)yn ................................................................................................................................25 2.10. Sprint to pr(cid:218)dko(cid:258)(cid:202) wzgl(cid:218)dna .............................................................................................................27 2.11. Planowanie wymiarowe ....................................................................................................................29 2.12. Przegl(cid:200)d Sprintu ...............................................................................................................................29 2.13. Instrukcja piel(cid:218)gnacji oczekiwa(cid:241) .......................................................................................................30 2.14. Retrospekcja Sprintu .........................................................................................................................33 2.15. Metaretrospekcja (klasycznie: podsumowanie) .................................................................................34 2.16. Zwinne warto(cid:258)ci w projekcie .............................................................................................................36 3 Wprowadzanie Scruma u dostawcy us(cid:239)ug internetowych — (cid:285)ycie i praca Mistrza M(cid:239)yna 37 3.1. Szerszy kontekst ...............................................................................................................................37 3.2. Bli(cid:285)sze otoczenie ..............................................................................................................................37 3.3. Dlaczego Scrum? .............................................................................................................................38 3.4. Cele wprowadzania Scruma ..............................................................................................................39 Sytuacja w chwili wymiany trenera ...................................................................................................39 3.5. 3.6. Planowanie Sprintu ...........................................................................................................................40 3 Kup książkęPoleć książkę 4 Spis tre(cid:258)ci Projektowanie .................................................................................................................................. 42 3.7. 3.8. Stosunki spo(cid:239)eczne .......................................................................................................................... 44 3.9. Mistrz M(cid:239)yna .................................................................................................................................... 46 3.10. Narz(cid:218)dzia ......................................................................................................................................... 48 3.11. Zarz(cid:200)dzanie wieloma projektami ....................................................................................................... 49 3.12. Podsumowanie ................................................................................................................................ 51 3.13. Zwinne warto(cid:258)ci w projekcie ............................................................................................................ 52 4 Wprowadzanie Scruma w ImmobilienScout24 53 4.1. Opis sytuacji .................................................................................................................................... 53 4.2. Wprowadzenie Scruma .................................................................................................................... 54 4.3. Przegl(cid:200)d Sprintu ............................................................................................................................... 57 Scrum 2.0 ........................................................................................................................................ 58 4.4. Kanban i spó(cid:239)ka ............................................................................................................................... 60 4.5. Podsumowanie ................................................................................................................................ 61 4.6. 4.7. Zwinne warto(cid:258)ci w projekcie ............................................................................................................ 62 (Niemal(cid:285)e) zwinni w du(cid:285)ym przedsi(cid:218)biorstwie 63 5 Klient ............................................................................................................................................... 63 5.1. 5.2. Sytuacja wyj(cid:258)ciowa ......................................................................................................................... 64 5.3. Nowy model obs(cid:239)ugi dostaw ............................................................................................................ 65 5.3.1. Faza wst(cid:218)pna projektu ........................................................................................................ 65 5.3.2. Przebieg projektu ............................................................................................................... 66 5.4. Wprowadzanie zwinno(cid:258)ci ................................................................................................................. 66 5.5. Usprawnienia ................................................................................................................................... 67 5.6. Trudno(cid:258)ci w nowym modelu obs(cid:239)ugi dostaw .................................................................................... 70 5.7. Do(cid:258)wiadczenia zebrane w toku projektu ........................................................................................... 71 5.7.1. Do(cid:258)wiadczenie: uzgodnienie celów cz(cid:200)stkowych z zarz(cid:200)dem ............................................. 71 5.7.2. Do(cid:258)wiadczenie: umocowanie W(cid:239)a(cid:258)ciciela Produktu ............................................................ 71 5.7.3. Do(cid:258)wiadczenie: niska jako(cid:258)(cid:202) spowalnia ............................................................................. 72 5.7.4. Do(cid:258)wiadczenie: radykalny kontra przyrostowy proces wprowadzania innowacji ................. 73 Podsumowanie ................................................................................................................................ 74 Zwinne warto(cid:258)ci w organizacji produktu ........................................................................................... 75 5.8. 5.9. 77 Powrót na zwinny tor (od mikrozarz(cid:200)dzania do Scruma) 6 6.1. Sytuacja wyj(cid:258)ciowa ......................................................................................................................... 77 6.2. Misja ................................................................................................................................................ 78 6.3. W(cid:239)a(cid:258)ciwy projekt .............................................................................................................................. 78 6.4. Naprzód ........................................................................................................................................... 79 6.5. Pierwsze spojrzenie .......................................................................................................................... 80 6.6. Analiza ............................................................................................................................................. 82 Pierwszy Sprint ................................................................................................................................ 84 6.7. 6.8. Szacowanie ...................................................................................................................................... 84 Kup książkęPoleć książkę Spis tre(cid:258)ci 5 6.9. Planowanie Sprintu ...........................................................................................................................84 6.10. Codzienny M(cid:239)yn ................................................................................................................................85 6.11. Przebieg Sprintu ...............................................................................................................................85 6.12. Przegl(cid:200)d Sprintu ...............................................................................................................................86 6.13. Retrospekcja Sprintu .........................................................................................................................86 6.14. Kilka tygodni pó(cid:283)niej… .....................................................................................................................86 6.15. Kilka miesi(cid:218)cy pó(cid:283)niej… ...................................................................................................................87 6.16. Podsumowanie .................................................................................................................................87 6.17. Zwinne warto(cid:258)ci w projekcie .............................................................................................................88 7.3. 7.4. Programowanie zwinne jako zasadniczy element przedsi(cid:218)biorstwa 7 89 7.1. Gracze ..............................................................................................................................................89 Ekipa formuje si(cid:218) ..............................................................................................................................89 7.2. 7.2.1. Wizja: dok(cid:200)d prowadzi droga? ............................................................................................90 7.2.2. Efekty spotkania .................................................................................................................90 Przygotowania ..................................................................................................................................92 Pierwsze tygodnie .............................................................................................................................92 7.4.1. Bomba w gór(cid:218): powstanie zespo(cid:239)u .....................................................................................92 7.4.2. Przegl(cid:200)d i Retrospekcja Sprintu ...........................................................................................93 7.4.3. Rezultaty Sprintu i szybko(cid:258)(cid:202) pracy ......................................................................................94 7.4.4. Rutyna i przep(cid:239)yw ...............................................................................................................95 7.4.5. Otoczenie ...........................................................................................................................95 Trudno(cid:258)ci .........................................................................................................................................96 Ponad brzegiem talerza .....................................................................................................................98 7.6.1. Wymagania niefunkcjonalne ...............................................................................................98 Zale(cid:285)no(cid:258)(cid:202) od czynników zewn(cid:218)trznych i wspó(cid:239)praca ..........................................................99 7.6.2. 7.7. Retrospekcja i podsumowanie ........................................................................................................100 7.8. Zwinne warto(cid:258)ci w projekcie ...........................................................................................................101 7.5. 7.6. 8 8.1. 8.2. Odnoszenie sukcesów w projektach o sta(cid:239)ym bud(cid:285)ecie 103 Przed rozpocz(cid:218)ciem projektu ..........................................................................................................103 Pocz(cid:200)tek projektu ...........................................................................................................................104 8.2.1. Role ..................................................................................................................................104 8.2.2. Praca w zespole ...............................................................................................................104 8.2.3. Nadgodziny ......................................................................................................................105 8.3. Realizacja projektu ..........................................................................................................................106 8.3.1. Problematyczne planowanie wersji dystrybucyjnych .........................................................106 8.3.2. Pokój ................................................................................................................................106 8.3.3. Podej(cid:258)cie do problemów ..................................................................................................106 8.3.4. Testy ................................................................................................................................107 8.3.5. Wersje dystrybucyjne .......................................................................................................108 8.3.6. Dwóch nowych deweloperów ...........................................................................................108 Zako(cid:241)czenie projektu ......................................................................................................................108 Zwinne warto(cid:258)ci w projekcie ...........................................................................................................110 8.4. 8.5. Kup książkęPoleć książkę 6 Spis tre(cid:258)ci Kanban — pocz(cid:200)tek przygody dla administratorów systemu 9 111 9.1. Ziarno kanbana zostaje zasiane ...................................................................................................... 111 9.2. Przygotowanie propozycji dla zespo(cid:239)u ............................................................................................ 113 9.2.1. A mówimy o tym zespole… ............................................................................................. 113 9.2.2. Wprowadzenie kanbana — czas rozdzieli(cid:202) role ................................................................ 113 9.2.3. Lista narz(cid:218)dzi ................................................................................................................... 114 9.2.4. Plan spotkania z zespo(cid:239)em ............................................................................................... 114 9.3. Zaprezentowanie propozycji zespo(cid:239)owi ........................................................................................... 114 9.4. Startuje nowy zespó(cid:239) kanbanowy ................................................................................................... 118 9.5. Pocz(cid:200)tki zespo(cid:239)u — podsumowanie ............................................................................................... 120 9.6. Nasze do(cid:258)wiadczenia ..................................................................................................................... 120 9.7. Administratorzy pracuj(cid:200) dalej jako zespó(cid:239) kanbanowy ..................................................................... 132 9.8. Nasze do(cid:258)wiadczenia ..................................................................................................................... 132 9.9. Podsumowanie .............................................................................................................................. 132 9.10. Otoczenie ....................................................................................................................................... 132 9.11. Zwinne warto(cid:258)ci w projekcie .......................................................................................................... 133 Zwinne mobile.de 10 135 10.1. Troch(cid:218) historii ................................................................................................................................ 135 10.2. Pocz(cid:200)tek — nag(cid:239)e wprowadzenie Scruma ...................................................................................... 136 10.2.1. Nowe cele ........................................................................................................................ 137 10.2.2. Nowe rozwi(cid:200)zania — Scrum ............................................................................................ 137 10.2.3. Outsourcing, offshoring .................................................................................................... 137 10.2.4. Projekty strategiczne — biegi ........................................................................................... 138 10.2.5. Wprowadzanie Scruma pod okiem trenera ....................................................................... 138 10.2.6. Proces i technika ............................................................................................................. 139 10.2.7. Koordynacja ..................................................................................................................... 140 10.2.8. Role ................................................................................................................................. 141 10.2.9. Podsumowanie ................................................................................................................ 141 10.3. Przecie(cid:285) jest jeszcze kanban .......................................................................................................... 141 10.4. A co z warto(cid:258)ciami? ...................................................................................................................... 144 10.5. Kanban portfelowy ......................................................................................................................... 144 10.6. Organizacja .................................................................................................................................... 146 10.6.1. Nowe cele ........................................................................................................................ 147 10.6.2. Procesy oparte na zaufaniu .............................................................................................. 147 10.7. Epilog ............................................................................................................................................ 148 Zwinno(cid:258)(cid:202) w start-upach internetowych 11 149 11.1. Uwagi ogólne ................................................................................................................................. 149 11.2. Typowa krzywa wzrostu start-upu .................................................................................................. 150 11.3. Jak uwolni(cid:202) si(cid:218) od chaosu — zwinne tworzenie oprogramowania czy metoda wodospadowa ........ 153 11.4. Podobie(cid:241)stwa mi(cid:218)dzy kultur(cid:200) start-upu a kultur(cid:200) zwinnego tworzenia oprogramowania .................. 154 11.5. Nie ma tak lekko, czyli klasyczne problemy start-upów ze stosowaniem zwinnych praktyk ............. 158 11.6. Jeste(cid:258)my zwinni — szesna(cid:258)cie godzin na dob(cid:218) ............................................................................. 158 Kup książkęPoleć książkę Spis tre(cid:258)ci 7 11.7. Problem podwójnych funkcji ...........................................................................................................159 11.8. Scrum kontra kanban — kontra XP .................................................................................................161 11.9. Automatyczne testy i refaktoryzacja ................................................................................................163 11.10. D(cid:239)ugo(cid:258)(cid:202) Sprintów ...........................................................................................................................164 11.11. Wszystko naraz czy polityka ma(cid:239)ych kroków ...................................................................................165 11.12. Podsumowanie ...............................................................................................................................165 167 12 Przejrzysto(cid:258)(cid:202) 12.1. (cid:189)ród(cid:239)em przejrzysto(cid:258)ci jest informacja zwrotna ...............................................................................167 12.2. Wczesne rozwi(cid:200)zywanie problemów ...............................................................................................168 12.3. Architektura ewolucyjna ..................................................................................................................170 12.4. Tempo prac rozwojowych ...............................................................................................................171 12.5. Informacje zwrotne od klientów .......................................................................................................173 12.6. Zaufanie ..........................................................................................................................................174 12.7. Podsumowanie — skuteczne wdra(cid:285)anie zwinnego modelu pracy ...................................................175 Zwinno(cid:258)(cid:202) w it-agile — zasada wyci(cid:200)gania w sprzeda(cid:285)y i zarz(cid:200)dzaniu 13 177 13.1. Zmianban ........................................................................................................................................177 13.2. Do(cid:258)wiadczenia ...............................................................................................................................179 13.3. Kanban sprzeda(cid:285)y ...........................................................................................................................181 (cid:189)ród(cid:239)a Autorzy Skorowidz 187 191 195 Kup książkęPoleć książkę 8 Spis tre(cid:258)ci Kup książkęPoleć książkę 2 Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em Holger Koschek W znaczącym przedsiębiorstwie średniej wielkości dział IT i eksperci dziedzinowi otrzymują szansę na zbudowanie systemu aplikacji na dziewiczym gruncie. Zewnętrzni doradcy do spraw architektury polecają Scruma jako zwinne podejście do zarządzania projektem, a przedsiębiorstwo na to przystaje. Wraz ze wzrostem doświadczenia w Scrumie przedsię- biorstwo stwierdza również, że zwinny projekt to nie bułka z masłem, ale poważny wysiłek — który jednak się opłaca, co obrazują wyniki projektu i motywacja pracowników. 2.1. Pobudka Na spotkanie inaugurujące projekt przybyli wszyscy: zleceniodawca, analitycy biznesowi, odpo- wiedni eksperci dziedzinowi oraz wyznaczony Zespół Deweloperski z bezpośrednim przeło- żonym. Wszyscy w napięciu oczekiwali pomysłów pozwalających osiągnąć ambitny cel, który wielu postrzegało jako niemożliwy do zrealizowania. Rozeszła się również pogłoska, że projekt ma zostać przeprowadzony z wykorzystaniem zwinnych metod zarządzania projektem, a do- kładniej z użyciem Scruma. Ale czym był ten Scrum? Jakie korzyści mógłby przynieść? Naszym zadaniem było udzielenie odpowiedzi na te pytania. Razem z moim współpracownikiem, Jo, mieliśmy w bagażu standardowy zestaw slajdów wprowadzających do Scruma. Jako formę prezentacji wybraliśmy wielokrotnie sprawdzoną zwin- ną wersję klasyka „dobry glina, zły glina”. To zawsze frajda doświadczać reakcji publiczności, gdy Jo wtrąca swoje pierwsze pytanie. Dopiero co zaprezentowałem Rejestr Produktu i wyja- śniłem, jak wymagania funkcjonalne zostaną w nim opisane oraz oszacowane na podstawie wartości biznesowej i innych kryteriów, gdy Jo przerwał: „A gdzie są pojedyncze zadania ko- nieczne do implementacji tych wymagań? Za nimi kryje się przecież wiele różnych szczegółów technicznych. Bez ich znajomości nie jestem w stanie oszacować nakładów potrzebnych do realizacji wymagania funkcjonalnego!”. „To dobre pytanie — odpowiedziałem z wielkim spo- kojem, a niektórzy słuchacze w ostatnim rzędzie zaskoczeni zwrócili uwagę na nasz kiełkujący dyskurs. — Chciałbym odpowiedzieć na to pytanie, czyniąc dwa spostrzeżenia. Po pierwsze: nie szacujemy bynajmniej dokładnego kosztu wymagań funkcjonalnych, ale ich koszt względ- ny (wobec siebie nawzajem). Na tak wczesnym etapie nie jesteśmy w stanie zrobić nic więcej. Po drugie: poszczególne zadania ustala zespół dopiero na początku Sprintu, w którym dane wymagania funkcjonalne powinny zostać zrealizowane”. „Ale czy to nie jest o wiele za późno? Jak rozsądnie planować projekt na podstawie tak skromnych informacji?” — ekscytował się Jo. Następnie zarysowałem temat planowania zwinnego projektu i kierowania nim. To rozbudziło ostatnich śpiochów. Po raz kolejny mieliśmy wrażenie, że Jo trafił w czuły punkt sceptyków. 17 Kup książkęPoleć książkę 18 Rozdzia(cid:239) 2 (cid:81) Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em Przyszedł czas na przekonanie ich — nie tu i teraz, ale w toku projektu. Dlatego zaprosiliśmy wszystkich do przeżycia zwinnego zarządzania projektem na żywo w naszym projekcie. Było ku temu wiele sposobności: Przegląd Sprintu oraz (po konsultacjach z zespołem) Codzienny Młyn stały otworem dla każdego zainteresowanego, a przejrzysta kontrola projektu powinna była całkowicie ujawniać rzeczywisty stan projektu — widoczny dla każdego w dowolnym momencie. To była nowość — nie tylko w tym przedsiębiorstwie. Wiedzieliśmy już z innych treningów zwinności, że przejrzystość i uczciwość przysporzą nam nowych przeciwników. Dowiedzieliśmy się jednak również, że u większości z nich wygrywa ciekawość i zanim zechcą puścić projekt z dymem (do czego tak naprawdę nigdy nie doszło), najpierw go poobserwują. Nasza zwinna pobudka zadziałała po raz kolejny. Wszyscy byli zgodni co do tego, że ten projekt będzie inny. Chcieliśmy obudzić pozytywną ciekawość i złagodzić lęki. Największe obawy miał Zespół Deweloperski — to było dla nas zrozumiałe. Jak mogliśmy przypuszczać, tej grupie nasze zajęcia wprowadzające dostarczyły więcej pytań niż odpowiedzi. Dlatego umówi- liśmy się z zespołem na następny dzień, aby przyjrzeć się Scrumowi z ich perspektywy i wspólnie opracować rozkład jazdy na wystartowanie projektu. Czy Twoje wprowadzenie do Scruma powinno zostawi(cid:252) d(cid:225)ugotrwa(cid:225)e wra(cid:298)enie? Je(cid:286)li tak, rozpraw si(cid:266) jeszcze z klasycznymi uprzedzeniami wobec zwinnych metod pracy i sposobów post(cid:266)powania. W ten sposób, mówi(cid:261)c (cid:298)artobliwie, pozbawisz wiatru (cid:298)agle sceptyków. 2.2. Zespó(cid:239) si(cid:218) formuje Spotkaliśmy się w małym kręgu. Celowo nieformalny nastrój sprzyjał budowaniu atmosfery, w której mogliśmy w pełni poświęcić się odpowiadaniu na pytania o Scruma. Aby powoli za- brać się za trudne tematy, jak na przykład odpowiedzialność zbiorowa, zaczęliśmy od opisu idealnej przestrzeni projektowej — i natychmiast zostaliśmy skonfrontowani z pierwszym problemem. Programiści pochodzili z wielu różnych działów, a każdy dział posiadał własne pomieszczenia. Zespół Deweloperski był więc rozproszony po różnych lokalizacjach. Teoretycznie wszyscy działali w tym samym budynku, ale to nam nie wystarczało. Co robić? Zleceniodawca zrozumiał nasz problem i obiecał, że wyruszy na poszukiwanie odpowiedniej przestrzeni dla projektu. Zespół Deweloperski skorzystał z okazji i dał mu jeszcze jedno zadanie na drogę: zleceniodawca powinien dopilnować, aby dotychczasowe stanowiska pracy zostały na czas trwania projektu zarezerwowane. Podejrzewaliśmy, że stoi za tym strach przed utratą ukocha- nego biurka i „współlokatorów” oraz otrzymaniem przydziału na gorsze stanowisko po za- kończeniu projektu. Gdy ostrożnie wspomnieliśmy o tym jednemu z członków zespołu, do- wiedzieliśmy się o jeszcze jednej przyczynie: jego przełożony oddelegował go do tego projektu jedynie na 70 procent czasu pracy i oczekiwał, że pozostałe 30 procent spędzi on na wykony- waniu innych zadań, w dotychczasowej lokalizacji. Gdy wypytaliśmy o to pozostałych dewelope- rów, okazało się, że poza jednym wyjątkiem wszyscy zostali skierowani do pracy w projekcie jedynie w części etatu. Biorąc pod uwagę strategiczne znaczenie i napięty harmonogram tego pro- jektu, była to nietypowa decyzja, którą mimo wszystko tymczasowo zaakceptowaliśmy. Chcieli- śmy w końcu osiągnąć poczucie bezpieczeństwa, a nie wywoływać dalszy niepokój. Dlatego kontynuowaliśmy opis przestrzeni zespołowej. Objaśniliśmy rolę tablicy z zadaniami, na której Kup książkęPoleć książkę 2.3. W(cid:239)a(cid:258)ciwe zlecenie 19 uwidaczniano (dla wszystkich zainteresowanych) prace wykonywane w bieżącym Sprincie i od- notowywano postępy. Przedstawiliśmy ponownie Codzienny Młyn, podczas którego zespół powi- nien się codziennie synchronizować, i podkreśliliśmy ogromne znaczenie komunikacji w zespole. Zespó(cid:225) zas(cid:225)ugiwa(cid:225) na pocz(cid:261)tku swojej zwinnej podró(cid:298)y na szczególn(cid:261) uwag(cid:266). Certyfikowany kurs na Mistrza M(cid:225)yna ujawni(cid:225) kolejne pytania — poniewa(cid:298) kurs jest dopasowany do Mistrza M(cid:225)yna, jedynie po(cid:286)rednio rozpatruje interesy samego Zespo(cid:225)u Deweloperskiego. Postaw si(cid:266) w sytuacji debiutuj(cid:261)cego w Scrumie zespo(cid:225)u, a stwierdzisz, (cid:298)e zwinne warto(cid:286)ci, dzia(cid:225)anie na w(cid:225)asn(cid:261) odpowiedzialno(cid:286)(cid:252), czynno(cid:286)ci zwi(cid:261)zane z planowaniem i umiej(cid:266)tno(cid:286)ci mi(cid:266)kkie niezb(cid:266)dne do skutecznej pracy zespo(cid:225)owej s(cid:261) na pocz(cid:261)tku raczej obci(cid:261)(cid:298)eniem ni(cid:298) rado(cid:286)ci(cid:261). Na pocz(cid:261)tkowym etapie zespó(cid:225) nie wykszta(cid:225)ci(cid:225) jeszcze zdolno(cid:286)ci rzemie(cid:286)lniczych, których oczekuje si(cid:266) od zwinnych deweloperów. Prawie wszyscy członkowie zespołu znali się już wcześniej i zdawali się dobrze wzajemnie ro- zumieć. Cieszyli się na czekające ich zadania i pasjonujące nowe technologie, które chcieliśmy wypróbować i wykorzystać w tym projekcie. Gdy niezobowiązująco dyskutowaliśmy na temat tych technologii i możliwych architektur oprogramowania, dokonaliśmy zdumiewającego odkry- cia: członkowie zespołu oczekiwali od nas — swoich doradców — gotowych szkiców architekto- nicznych oraz zaleceń odnośnie do technologii, które miały zostać wykorzystane w projekcie. Nie- co zaskoczeni, rozejrzeliśmy się dokoła. Ci, którzy wyrazili to pragnienie, nie byli wcale świeżo upieczonymi absolwentami uniwersytetu, lecz doświadczonymi inżynierami oprogramowania z wieloletnim doświadczeniem. „Jak można się dobrowolnie wykluczyć z tak interesującej dyskusji na tematy techniczne?” — pomyślałem. Nie musiałem zadawać tego pytania na głos, by otrzymać odpowiedź. Właściwie były to dwie odpowiedzi. „Powszechną tutaj praktyką jest in- struowanie deweloperów przez architekta, który podejmuje techniczne decyzje projektowe” — powiedział jeden z deweloperów, a drugi dodał: „A poza tym zostaliście zapowiedziani jako archi- tekci oprogramowania dla naszego projektu. Czy coś się nie zgadza?”. Ależ owszem, wszystko się zgadzało. Natomiast pomysł poprowadzenia projektu zgodnie z zasadami Scruma powstał, ściśle mówiąc, podczas pierwszej dyskusji o architekturze. To wtedy ustaliliśmy, że mamy dwie możliwości: albo zagubimy się w teoretycznych dyskusjach, dopełnianych przez nieskończone ewaluacje oprogramowania i technologii, albo zabierzemy się ostro do pracy, aby w krótkich iteracjach osiągnąć pierwsze rezultaty. Postawiliśmy więc wyznaczonego kierownika projektu przed wyborem pomiędzy podejściem bardziej klasycznym a podejściem zwinnym, mimo że nie wpisywało się to w nasze pierwotne zamówienie na konsultacje. 2.3. W(cid:239)a(cid:258)ciwe zlecenie Zacznijmy jednak od samego początku: naszą wizytę rzeczywiście rozpoczęliśmy jako architekci oprogramowania. Wyposażeni w niezbędną wiedzę technologiczną i architektoniczną oraz sto- sowną porcję doświadczenia, mieliśmy stworzyć wspólnie z klientem nową platformę opro- gramowania, przeznaczoną do realizacji kluczowych procesów przedsiębiorstwa, korzystając przy tym z możliwości pracy na dziewiczym gruncie. Czy nie jest to marzenie każdego doradcy? Niemal nie zważając na istniejące aplikacje i infrastrukturę, mieliśmy opracować świeże po- mysły na nadchodzące lata oraz zaimplementować je, wykorzystując nowoczesne technologie. Kup książkęPoleć książkę 20 Rozdzia(cid:239) 2 (cid:81) Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em Rozmowy z architektami oprogramowania klienta były interesujące i zazwyczaj spełniały swój cel. Mimo to mieliśmy poczucie, że nie jesteśmy dostatecznie szybcy. Wyraźną oznaką nadmiaru teoretyzowania była relacja czasu poświęconego projektowaniu do czasu spędzanego na kodowaniu: po dwóch tygodniach badań nie powstała ani jedna linia kodu oparta na dokumenta- cji. Znajdowaliśmy się w samym środku drugiej fazy modelu kaskadowego — projektowania. Na domiar złego nie mieliśmy zielonego pojęcia o tym, co powinno zostać wykonane w celu funkcjonalnego rozwinięcia platformy. Specyfikacja funkcjonalna projektu (model kaskadowy, fa- za pierwsza: wymagania) była bowiem wynikiem pracy innego działu, którego żadnego przed- stawiciela dotychczas nie poznaliśmy i od którego nie otrzymaliśmy żadnego dokumentu. Dzień, w którym poznaliśmy ekspertów dziedzinowych i porozmawialiśmy o wymaganiach na podstawie specyfikacji funkcjonalnej projektu, wyznaczył pozytywny punkt zwrotny. Dowiedzieli- śmy się wreszcie, czemu miało służyć zbudowanie nowej platformy technicznej. Technologia nie była dla nas celem samym w sobie. Właśnie dlatego ostatecznie ucieszyliśmy się z przeka- zania wizji produktu, która zadziałała na naszą nieśmiało kiełkującą architekturę jak zastrzyk energii. Na podstawie przypadków użycia o wiele łatwiej było nam oceniać i wybierać tech- nologiczne alternatywy. Realizacja pewnych istotnych wymagań funkcjonalnych nieuchronnie się opóźniała, a wymagania niefunkcjonalne, takie jak bezpieczeństwo i wydajność, mogły zostać zdefiniowane dokładniej. Niemniej jednak byliśmy wciąż w drodze. Wprawdzie mogliśmy opisać swoje pomysły ekspertom dziedzinowym, ale nie mogliśmy ich pokazać. Im bardziej abs- trakcyjny był pomysł, tym trudniej było zachwycić ekspertów. A kto nie odczuwa wobec da- nego rozwiązania zachwytu, ten nie opowiada się za nim bezdyskusyjnie. Chcieliśmy wytwo- rzyć coś, co nadawało się do prezentacji, podczas której można by zetrzeć się merytorycznie, wywołując dyskusję lub burzę pomysłów. Zamiast tego mieliśmy jedynie stertę papieru. To po- winno było, a nawet musiało, się zmienić. Zamiast d(cid:225)ugo analizowa(cid:252), planowa(cid:252) i projektowa(cid:252), zespó(cid:225) projektowy powinien raczej zabra(cid:252) si(cid:266) do pracy, gdy tylko uzyska pierwsze wiarygodne wyobra(cid:298)enie na temat oczekuj(cid:261)- cego zadania. Wizja produktu ma wtedy stanowi(cid:252) przydatn(cid:261) wskazówk(cid:266). Opisuje ona „nad- rz(cid:266)dny cel”, jednak(cid:298)e bez wskazywania gotowej drogi i bez narzucania zbyt du(cid:298)ych ograni- cze(cid:276). W ko(cid:276)cu (cid:286)wiat wokó(cid:225) nas zmienia si(cid:266) z dnia na dzie(cid:276). Pomys(cid:225)y i wymagania pojawiaj(cid:261) si(cid:266) i znikaj(cid:261), s(cid:261) modyfikowane, odrzucane i ponownie przyjmowane. Wszystko to ma wp(cid:225)yw na kszta(cid:225)t ko(cid:276)cowego produktu. Istota tego produktu, wyra(cid:298)ona w wizji, przetrwa jednak z regu(cid:225)y dynamik(cid:266) codzienno(cid:286)ci projektu. Im bardziej szczegó(cid:225)owy i daleko id(cid:261)cy jest plan projektu, tym wi(cid:266)cej wymaga(cid:276) trzeba pó(cid:296)niej dostosowa(cid:252) do nowych realiów projektu. Pocz(cid:261)tkowe planowanie by(cid:225)o wi(cid:266)c ostatecznie chybion(cid:261) inwestycj(cid:261). Pieni(cid:261)dze lepiej nale(cid:298)a(cid:225)o zainwestowa(cid:252) w jak najszybsze pozyskanie informacji zwrotnej, otrzyma- nej w wyniku bezzw(cid:225)ocznego zabrania si(cid:266) do pracy. 2.4. Od partyzantki do zwinno(cid:258)ci Aby szybko osiągnąć rzeczywiste wyniki i zminimalizować ryzyko popłynięcia w złym kierunku, Jo i ja zadecydowaliśmy, że przekonamy klientów do wyższości zwinnego sposobu postępo- wania. W tym celu zabraliśmy się do pracy bardzo ostrożnie. Zaczęliśmy od czegoś nieszkodliwe- go, co osobie nieobeznanej z warsztatem zwinnych narzędzi nie od razu rzuca się w oczy: przygo- towaliśmy Rejestr Produktu i wypełniliśmy go wymaganiami funkcjonalnymi i technicznymi, Kup książkęPoleć książkę 2.5. Kompleks Scruma 21 zapisanymi w postaci Historyjek Użytkownika. Od razu dostarczyliśmy również uzasadnienie wprowadzenia Rejestru Produktu. Zwróciliśmy w nim uwagę na dużą liczbę pomysłów, które wykreowaliśmy w ubiegłych tygodniach. Aby nie stracić tych pomysłów i jednocześnie nie musieć od razu ich wszystkich dokładnie wyceniać, powinniśmy najpierw dodać je do Reje- stru Produktu i jedynie zgrubnie oszacować. Naszym odpowiednikiem po stronie klienta był klasyczny kierownik projektu. Wprawdzie rozumiał podstawy użycia Rejestru Produktu, ale skonfrontowany z szacowaniem względnych wielkości zadań, w przeciwieństwie do konkret- nych wartości liczonych w roboczodniach dewelopera, stawał się coraz bardziej niepewny. Być może nie wyjaśniliśmy mu dostatecznie zrozumiale przewagi względnego szacowania i różni- cy pomiędzy oszacowaniem a dokładnym planowaniem nakładu prac. W każdym razie w od- wzorowaniu ukonstytuowanym przez nasz Rejestr Produktu brakowało mu dwóch informacji istotnych przy planowaniu projektu: konkretnych zadań i nakładów koniecznych do ich reali- zacji. Nasza wskazówka, że są one dostarczane przez zespół, była uderzeniem głową w mur klasycznego zarządzania projektem: speszony kierownik projektu zapytał nas, jak w takim ra- zie ma planować projekt bez znajomości tak istotnych parametrów. Ponadto zespół nie został jeszcze skompletowany. Deweloperzy nie byli tak czy owak przyzwyczajeni do samodzielnego definiowania swoich zadań — nie powinni zresztą tego w ogóle wykonywać, ponieważ jest to obowiązek kierowników projektów i głównych architektów. Nasze anteny, ustawione na wy- krywanie kompetencji miękkich, odnotowały mieszankę braku zrozumienia, strachu przed nowością i bliżej nieokreślonego egzystencjalnego lęku, wywołanego poprzez podanie w wąt- pliwość roli zarządzania projektem. Nadszedł czas na zwolnienie obrotów. Nie tylko zespó(cid:225) jest pocz(cid:261)tkowo sceptycznie nastawiony do niekonwencjonalnych warto(cid:286)ci, zasad i praktyk. Równie(cid:298) (cid:286)wie(cid:298)o upieczony Mistrz M(cid:225)yna potrzebuje czasu na odnalezienie si(cid:266) w swojej roli. Rola ta jest cz(cid:266)sto obsadzana kierownikiem projektu lub g(cid:225)ównym architek- tem. Nie jest to szkodliwe, ale nie zawsze bywa pomocne. Dla wielu kierowników projektów zamiana ról wi(cid:261)(cid:298)e si(cid:266) z natychmiastow(cid:261) utrat(cid:261) w(cid:225)adzy. Zamiast kierowa(cid:252) pewn(cid:261) grup(cid:261) deweloperów, staj(cid:261) si(cid:266) „jedynie” arbitrami samoorganizuj(cid:261)cego si(cid:266) zespo(cid:225)u, dbaj(cid:261)cymi o to, by zespó(cid:225) móg(cid:225) pracowa(cid:252) bez (cid:298)adnych zak(cid:225)óce(cid:276). Nale(cid:298)y o tym pami(cid:266)ta(cid:252), je(cid:286)li zamierzamy pomóc niedo(cid:286)wiadczonemu Mistrzowi M(cid:225)yna w osi(cid:261)gni(cid:266)ciu sukcesu w jego nowej funkcji. 2.5. Kompleks Scruma Poszliśmy na ustępstwa. Rozszerzyliśmy Rejestr Produktu o jedną kolumnę, w której dołożyli- śmy do Historyjek Użytkownika pierwsze prace do zrealizowania. Razem z kierownikiem projektu spotkaliśmy się ze współpracownikami, którzy sporządzili koncept projektu, aby przejrzeć ten dokument w poszukiwaniu materii, z której mogłyby powstać kolejne Historyjki Użytkownika. W ten sposób wykreowaliśmy nowy problem, ponieważ Rejestr Produktu za- wierał zarówno funkcjonalne, jak i techniczne Historyjki Użytkownika. Jak można było je roz- różnić? Dlaczego w ogóle powstały techniczne Historyjki Użytkownika? Czy nie sprzeciwia się to zwinnej ideologii, według której liczy się jedynie funkcjonalność? Pytania zadane przez jednego ze współpracowników możemy obalić stwierdzeniem, że otrzymaliśmy dwa zupełnie różne zlecenia: po pierwsze, powinna powstać techniczna platforma do zarządzania procesami biznesowymi; po drugie, na tej platformie powinien zostać osadzony wybrany proces biznesowy Kup książkęPoleć książkę 22 Rozdzia(cid:239) 2 (cid:81) Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em — przykładowy, lecz produktywny. W rezultacie mieliśmy do czynienia z „wymaganiem tech- nicznym” (platforma) i „wymaganiem funkcjonalnym” (proces biznesowy). Dlatego w celu rozróżnienia pomiędzy obydwoma projektami zafundowaliśmy Rejestrowi Produktu kolejną kolumnę. Nasz pierwotny cel, czyli zorganizowanie Rejestru Produktu w najprostszy możliwy sposób, aby pozbawić scrumowych nowicjuszy obaw, nie został przez nas osiągnięty. Fakt, że to nie Scrum był temu winny, lecz złożona natura projektu, wcale nie pomagał nam w dalszej pracy. Nadal byliśmy zdania, że z takimi skomplikowanymi projektami można sobie poradzić jedynie, stosując podejście zwinne. Coraz wyraźniej uwidaczniał się brak możliwości dalszej pracy bez uprzedniego przekaza- nia podstaw Scruma wszystkim osobom, które były zaangażowane w projekt. Tak czy owak, nadszedł czas na ustalenie składu zespołu i zacieśnienie kontaktu z ekspertami dziedzinowy- mi. Szczęśliwym trafem zleceniodawca zwołał trwające pół dnia spotkanie inauguracyjne. Wyciągnęliśmy z szuflady nasz standardowy zestaw folii wprowadzających do Scruma i cie- szyliśmy się na ponowne przedstawienie naszego klasyka „dobry glina, zły glina”, który poja- wił się już na początku tej historii. A jak potoczyło się to dalej? Rzadko mo(cid:298)na dowolnie wybra(cid:252) swój pierwszy projekt realizowany zgodnie z wytycznymi Scruma. Je(cid:286)li rzeczywi(cid:286)cie b(cid:266)dziesz mie(cid:252) wybór, zdecyduj si(cid:266) na przejrzysty projekt o strate- gicznym znaczeniu. Z(cid:225)o(cid:298)ony projekt, taki jak opisany w tej ksi(cid:261)(cid:298)ce, niepotrzebnie pod- niesie próg wej(cid:286)cia do (cid:286)wiata zwinno(cid:286)ci. Z drugiej strony, bardzo (cid:225)atwy projekt-zabawka jest pozbawiony znaczenia. Nawet je(cid:286)li pó(cid:296)niej zostanie oceniony jako sukces, krytycy nadal b(cid:266)d(cid:261) utrzymywa(cid:252), (cid:298)e podej(cid:286)cie zwinne zadzia(cid:225)a(cid:225)o jedynie dlatego, i(cid:298) projekt by(cid:225) tak ma(cid:225)y i przewidywalny. W najgorszym przypadku komunikat o sukcesie zostanie zak(cid:225)ócony przez wie(cid:286)ci docieraj(cid:261)ce z du(cid:298)ych, krytycznych projektów. 2.6. Zwyci(cid:218)stwa i pora(cid:285)ki Jak już wspomniano, zespół domagał się zarówno zachowania dotychczasowych stanowisk pracy, jak i nowych pomieszczeń dla zespołu. Zleceniodawca rzeczywiście spełnił oba życzenia. Byliśmy dumni, gdy pokazywał nam nową przestrzeń biurową, która znajdowała się w przyległym bu- dynku — właśnie zdobyliśmy pierwsze punkty dla zwinności. Fizyczne oddzielenie od reszty przedsiębiorstwa postrzegaliśmy jako zaletę. Zrządzeniem losu „mieszkaliśmy” teraz w bezpo- średnim sąsiedztwie ekspertów dziedzinowych, dla których powinniśmy rozwijać pierwszą aplikację na naszej nowej platformie. Było to praktyczne, ponieważ krótsza droga powinna — zgodnie z naszym planem — zacieśnić współpracę. Uzupełniając: pokoje nie były tak nowoczesne jak w centrali firmy, ale mieliśmy dostatecznie dużo miejsca i potrzebny spokój. Co prawda nasze małe imperium składało się z dwóch pomieszczeń (oraz sali konferencyjnej), ale kierownik pro- jektu natychmiast je podzielił: jeden pokój przypisał sobie wraz z analitykami biznesowymi, a drugi przypadł w udziale nam, deweloperom i architektom. „To nic strasznego” — pomyśleliśmy i roz- poczęliśmy urządzanie naszego nowego biura w duchu zwinności: zbudowaliśmy ścianę dedy- kowaną metodzie metaplanu1 dla tablicy z zadaniami oraz przygotowaliśmy ją do pierwszego 1 Metaplan — metoda dyskusji, podczas której uczestnicy wspólnie tworzą plakat obrazujący jej graficzny skrót — przyp. tłum. Kup książkęPoleć książkę 2.7. Planowanie Sprintu (cz(cid:218)(cid:258)(cid:202) I) 23 Sprintu. Zespół i kierownik projektu z zaciekawieniem obserwowali nasze wybryki. Objaśniliśmy im funkcjonowanie tablicy z zadaniami, powtórzyliśmy raz jeszcze opis wewnętrznej struktury Sprintu i zaprosiliśmy wszystkich do sali konferencyjnej na spotkanie planujące pracę w Sprincie. 2.7. Planowanie Sprintu (cz(cid:218)(cid:258)(cid:202) I) Podczas Planowania Sprintu ostatecznie zemściło się to, że zespół nie brał udziału w sporzą- dzaniu Rejestru Produktu. Elementy Rejestru Produktu zostały już wcześniej spriorytetyzo- wane, przy czym uwzględniono zarówno funkcjonalne, jak i techniczne zależności. Mogliśmy zatem bez przeszkód włączyć się do wspólnego szacowania wielkości poszczególnych ele- mentów. Kierownik projektu, Jo i ja byliśmy w pełni zaznajomieni z tematem — nic dziwne- go, skoro razem zbudowaliśmy Rejestr Produktu. Pięciu pozostałym członkom zespołu mu- sieliśmy wyjaśnić historie stojące za konkretnymi elementami. Jeden z członków zespołu został do niego ściągnięty jako wewnętrzny architekt i powinien być naszym partnerem spa- ringowym przy opracowywaniu architektury systemu. Zadawał wiele dobrych pytań, chciał zrozumieć szczególnie decyzje podjęte w kontekście podstawowej architektury i wniósł sporo świeżych pomysłów, które stawiały wiele elementów Rejestru Produktu w zupełnie nowym świetle. Niestety, jego żądza wiedzy przedłużała Planowanie Sprintu, a poza tym odczuwaliśmy, że pozostali członkowie zespołu rzadko chcieli lub mogli podążać za naszymi dyskusjami (co odpo- wiadało ich zapotrzebowaniu na posiadanie architekta w zespole). Aby całkowicie nie zgubić zespołu, ograniczyliśmy się do wyjaśnienia szczegółów funkcjonalnych. Samo w sobie było to wystarczająco wymagające, ponieważ niektórzy współpracownicy nie byli przyzwyczajeni do zastanawiania się nad zakresem funkcjonalnym. Dotąd otrzymywali jasne techniczne zadania i w razie wątpliwości zwracali się do swoich architektów oprogramowania lub kierowników projektu. Teraz mieli nagle podejmować decyzje dotyczące funkcjonalności albo przynajmniej mieć w tym udział, a na dodatek szacować wielkość elementów Rejestru Produktu, zarówno technicznych, jak i funkcjonalnych. „Wielkość? Dlaczego nie pracochłonność?” — zapytał nas jeden z deweloperów. Ponownie objaśniliśmy względne szacowanie zadań i przeszliśmy do gry w Planowanie Pokerowe2. W momencie, gdy rozdawaliśmy karty, wzbudziliśmy pośród sceptyków prawdziwe zain- teresowanie: gry karciane stanowiły urozmaicenie szarej codzienności projektu. Przytoczyli- śmy reguły gry i od razu przeszliśmy do rzeczy. Szybko znaleźliśmy punkt odniesienia pośród elementów Rejestru Produktu. Otrzymał on wartość równą 2. W związku z tym kolejny wy- brany element Rejestru Produktu powinien zostać oszacowany względem wyłonionego właśnie punktu odniesienia. Chociaż wszyscy zrozumieli zasady gry, nadal trudno było zdecydować się na konkretną wartość wielkości zadania. Kto wie, jak duże mogły być pozostałe elementy Rejestru Produktu. Na podstawie wątpliwości niektórych członków zespołu ustaliliśmy rów- nież, że nie zrozumieli oni jeszcze w pełni elementów Rejestru Produktu. Pierwsza tura Pla- nowania Pokerowego wydobyła na światło dzienne wiele różnych wartości szacunkowych. Gdy zachęciliśmy graczy z najwyższą i najniższą wartością do uzasadnienia swojego oszaco- wania, otrzymaliśmy odpowiedzi, które z trudem można było odróżnić. Kartę z najwyższą 2 Planning Poker (Planowanie Pokerowe) to znak towarowy Mountain Goat Software, Inc. Kup książkęPoleć książkę 24 Rozdzia(cid:239) 2 (cid:81) Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em wartością wyłożył architekt. Wyjaśnił swój wybór, wskazując na techniczne koszty produkcji i realizację pozostałych niefunkcjonalnych wymagań dotyczących bezpieczeństwa, skalowal- ności, rozszerzalności i możliwości ponownego wykorzystania. Projekt techniczny, który nakreślił dla realizacji tego elementu Rejestru Produktu, byłby wspaniałym uzupełnieniem każdego podręcznika o projektowaniu zorientowanym obiektowo. Dla naszego konkretnego problemu projekt ów był jednakże zbyt skomplikowany. „Czy sły- szałeś o regule KISS?” — zapytałem. Pokręcił głową. „Keep it simple, stupid3; oznacza to tyle co: utrzymaj to tak prostym, jak to tylko możliwe — wyjaśniłem akronim. — Nasz plan dzia- łania powinien być jednocześnie tak prosty, jak to możliwe, i zarazem tak złożony, jak to po- trzebne, ale zdecydowanie nie bardziej skomplikowany”. „Ale co, jeśli wymagania się zmie- niają i oczekuje się nowych funkcji, których prosty szkic projektu nie jest w stanie spełnić?” — odparł architekt. „Wtedy rozszerzamy nasz prosty system, przy czym refaktoryzujemy projekt oraz kod. Dzięki testom jednostkowym znajdujemy się w korzystnym położeniu, pozwalającym na sprawdzenie, czy zrefaktoryzowany system zachowuje się tak samo jak przed refaktoryzacją. Testy minimalizują ryzyko niesione przez refaktoryzację”. Pozornie przyjął tę argumentację — ale przypuszczalnie tylko dlatego, że nalegał na to kierownik projektu. Wiedziałem teraz, że powinienem mieć architekta na oku. W rzeczywistości miał on tendencję do konstruowania bardzo złożonych, generycznych szkiców projektowych, przygotowanych na wszelkie ewentu- alności — nawet jeśli były one jedynie domniemane, a nie wskazane — przez co czynił kod niepotrzebnie rozdmuchanym i trudniejszym do zrozumienia. Gra w Planowanie Pokerowe przyniosła całemu zespołowi wiele przyjemności. Tej atmosferze zabawy dali się ponieść również co bardziej nieśmiali koledzy i odważyli się zadawać własne pytania. Najbardziej podobał się wszystkim fakt, że szacowanie zostało przeprowadzone wspólnie. W przeszłości pracochłonność zadań musieli szacować indywidualnie. Ryzyko błędu oszacowania było więc wyższe, a na dodatek, w najgorszym przypadku, można było zostać osobiście pocią- gniętym do odpowiedzialności. Mając za plecami zespół, wszyscy byli odważniejsi i pełni wia- ry. I w ten oto sposób jeszcze przed południem dokonaliśmy wyboru elementów Rejestru Produktu, które zamierzaliśmy zrealizować w pierwszym Sprincie. Elementy były dobrze do- pasowane do siebie pod kątem funkcjonalnym, dzięki czemu byliśmy w stanie szybko sfor- mułować Cel Sprintu. 2.8. Planowanie Sprintu (cz(cid:218)(cid:258)(cid:202) II) Po południu doszliśmy do punktu, na który czekał kierownik projektu. Definiowaliśmy prace (zadania) dla wszystkich elementów Rejestru Produktu, które zostały wybrane do danego Sprintu. Kierownik projektu zaskoczył nas wypowiedzią, że ma już w zanadrzu gotowe odpo- wiednie zadania — w dodatku dla wszystkich elementów Rejestru Produktu. Zdumieni, pozo- stawiliśmy mu pole do popisu i zostaliśmy nagrodzeni generyczną mapą zadań, która ubierała pojedyncze elementy Rejestru Produktu w płaszcz miniaturowego modelu kaskadowego: „anali- za”, „projektowanie architektury”, „implementacja”, „testy integracyjne”, „testy funkcjonalne” — tak (albo przynajmniej analogicznie) brzmiały zadania. Nie podobało się to ani nam, ani (na szczęście) architektom oprogramowania obecnym w zespole. Kierownik zespołu przygotował 3 Na język polski zazwyczaj bywa to tłumaczone jako „nie komplikuj, głupku” — przyp. tłum. Kup książkęPoleć książkę 2.9. Codzienny M(cid:239)yn 25 bowiem w rzeczywistości szczegółowe pomysły na implementację poszczególnych elementów. Naturalnie musieliśmy go co rusz powstrzymywać przed przeholowaniem z regułą KISS. Jo i ja dołożyliśmy do tego pomysły ze wstępnej dyskusji na temat architektury i w ten sposób z po- mocą architekta zdefiniowaliśmy zadania do wyznaczonych elementów Rejestru Produktu, podczas gdy pozostała część zespołu (w tym kierownik projektu) przyglądała się naszym zabiegom i próbowała naśladować nasz tok myślenia. Być może dobrym pomysłem byłoby rozbudzenie w pozostałych członkach zespołu aktywności wobec biegu wydarzeń, ale czas nie był naszym sprzymierzeńcem. Zdecydowaliśmy się na punktualne rozpoczęcie Sprintu kosztem wyrówna- nia poziomu wiedzy w zespole, w nadziei na pomyślne przekazanie informacji w trakcie samego Sprintu. Zobowiązanie się zespołu do osiągnięcia Celu Sprintu w zasadzie odeszło wieczorem w zapomnienie, ale Jo i ja pominęliśmy to wspaniałomyślnym milczeniem. Tuż przed zasłużonym fajrantem ogłosiliśmy zespołowi, że od jutra „…będziemy zajmo- wać się właściwą pracą deweloperską!”. Współpracownicy bardzo się na to ucieszyli. W końcu będą mogli zająć się tym, co sprawia im największą frajdę. Bez zastrzeżeń przyjęli naszą chęć złożenia im porannej wizyty podczas Codziennego Młyna. Być może zadałeś już sobie pytanie, dlaczego w tej opowieści nie pojawił się Właściciel Produktu. Odpowiedź jest zarazem tak prosta, jak i niezadowalająca: ta rola nie została opty- malnie obsadzona. Niektórzy odnieśli wrażenie, że do dwóch typów zadań (zbudowania plat- formy technicznej oraz osadzenia w niej pierwszej funkcjonalności realizującej proces biznesowy) potrzebowaliśmy dwóch Właścicieli Produktu. Rolę prekursora technicznego objął tradycyj- nie architekt oprogramowania, brakowało mu jednak wiedzy dotyczącej dostosowania plat- formy do wymagań funkcjonalnych. Eksperci dziedzinowi byli zajęci definiowaniem pierwszego nowego procesu biznesowego. W tym celu przyglądali się obecnemu procesowi, standaryzując i optymalizując tenże proces oraz dostosowując go do postaci umożliwiającej wsparcie techniczne. Pomoc okazana Zespołowi Deweloperskiemu przez ekspertów dziedzinowych była wzorowa: zawsze znajdowaliśmy partnera do rozmowy, który był w stanie natychmiast odpowiedzieć na nasze pytania. Natomiast decyzje techniczne były często odwlekane w czasie, ponieważ konieczne było oczekiwanie na opinie trudno dostępnych specjalistów. Po części było to osadzone w kulturze pracy obowiązującej w przedsiębiorstwie — ciężar podjęcia decyzji był regularnie przekazy- wany „wyżej”. Patrząc z perspektywy czasu, byłoby lepiej, gdyby równoległe badania w zakre- sie domen — funkcjonalnej i technicznej — odbywały się na przedpolu projektu. W tej kon- kretnej sytuacji zespół projektujący proces czekał wciąż na Zespół Deweloperski i odwrotnie. Wielu deweloperów musi na pocz(cid:261)tku swojego pierwszego zwinnego projektu oprze(cid:252) si(cid:266) ch(cid:266)ci rozwijania najbardziej ogólnego ze wszystkich mo(cid:298)liwych rozwi(cid:261)za(cid:276). B(cid:266)d(cid:261) oni wci(cid:261)(cid:298) wys(cid:225)uchiwa(cid:252) argumentów dotycz(cid:261)cych zgodno(cid:286)ci ze sztuk(cid:261): „Je(cid:286)li teraz nie przewidzimy elastyczno(cid:286)ci rozwi(cid:261)zania, nie b(cid:266)dziemy go w stanie rozbudowa(cid:252)”. Twoj(cid:261) ripost(cid:261) mog(cid:225)o- by by(cid:252): „Czy jeste(cid:286) pewien, (cid:298)e istotnie potrzebujemy tej elastyczno(cid:286)ci?”. Jeden z moich profesorów mawia(cid:225) zawsze: „U(cid:298)ycie poprzedza ponowne u(cid:298)ycie”. Jakie to prawdziwe… 2.9. Codzienny M(cid:239)yn Dopiero kwadrans po dziesiątej wszyscy deweloperzy zgromadzili się w biurze i mogłem wreszcie wezwać ich na Codzienny Młyn. Na pytanie, dlaczego nie została dotrzymana usta- lona na spotkanie godzina dziesiąta (co z mojego punktu widzenia i tak było dosyć późną porą), Kup książkęPoleć książkę 26 Rozdzia(cid:239) 2 (cid:81) Zwinny projekt to nie bu(cid:239)ka z mas(cid:239)em otrzymałem różnorakie niezadowalające odpowiedzi. Zobowiązania w innych projektach, zbyt powolna podróż koleją miejską albo po prostu brak pamięci o terminie spotkania. Nie mogłem zrobić nic więcej poza przypomnieniem wszystkim o znaczeniu tego spotkania. Następnie przytoczyłem reguły gry i oddałem głos pierwszemu współpracownikowi. Stał on niepewnie przed tablicą, przeczytał ponownie wszystkie elementy Rejestru Produktu, które wybraliśmy do tego Sprintu, poświęcił się bez reszty kartkom z zadaniami i w końcu obwieścił: „Nie wiem, którego zadania powinienem się podjąć”. Zanim niepokój zdążył się rozprzestrzenić, przejąłem moderację, przekierowałem uwagę wszystkich na pierwszy element Rejestru Sprintu i zapro- ponowałem współpracownikowi jedno z zadań, które uznałem za odpowiednie. „I co dokład- nie powinienem zrobić w ramach tego zadania?” — zapytał. Odpowiedź na to pytanie przyszła z ust innego współpracownika. Bez namysłu połączyłem pytającego z odpowiadającym — trudno wprowadzić w zespole programowanie w parach w bardziej elegancki sposób. Obaj byli zadowoleni z możliwości wspólnej pracy nad tym zadaniem. Przykład znalazł naśladowców i w ten oto sposób po zakończeniu Codziennego Młyna mieliśmy dwie programistyczne pary oraz troje „samotnych jeźdźców”. Jedynie kierownik pro- jektu był niezadowolony, ponieważ nie odegrał w tym kręgu żadnej roli. Nie chciał pogodzić się z zadaniem usuwania wszelkich przeszkód stających na drodze zespołu. Dużo bardziej na rękę było mu kierowanie projektem i zespołem oraz wpływanie na kształt architektury. Po- wiedziałem kierownikowi projektu, że ostatniemu aspektowi nie można w zasadzie nic zarzucić tak długo, jak długo on, kierownik, zagwarantuje, iż zespół będzie w stanie pracować bez zakłóceń, inaczej mówiąc: przeszkody będą przez niego sprawnie usuwane. Jednak kierownik projektu miał jeszcze jedno ważne zastrzeżenie: to jemu miała przypaść kontrola postępów projektu. W tym celu zdążył już wykorzystać wewnętrzne narzędzie do raportowania czasu pracy. Zamiast zwyczajnie zlecić zadania na wykonan
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Zwinne projekty w klasycznej organizacji. Scrum, Kanban, XP
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ą: