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

Transkrypt

1

2 Tytu orygina u: The Agile Samurai: How Agile Masters Deliver Great Software T umaczenie: Andrzej Stefa ski ISBN: Copyright 2010 Pragmatic Programmers, LLC All rights reserved Copyright 2012 by Helion S.A. 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 bior jednak adnej odpowiedzialno ci ani za ich wykorzystanie, ani za zwi zane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponosz równie adnej odpowiedzialno ci za ewentualne szkody wynik e z wykorzystania informacji zawartych w ksi ce. Wydawnictwo HELION ul. Ko ciuszki 1c, GLIWICE tel , helion@helion.pl WWW: (ksi garnia internetowa, katalog ksi ek) Drogi Czytelniku! Je eli chcesz oceni t ksi k, zajrzyj pod adres 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ść

3 Spis tre ci Podzi kowania... 9 Dobrze Ci widzie Cz I. Wprowadzenie Rozdzia 1. Zwinno w pigu ce Dostarczaj czego warto ciowego co tydzie Jak dzia a zwinne planowanie? Zrobione oznacza zrobione Trzy proste prawdy Rozdzia 2. Poznaj swój zwinny zespó Czym wyró niaj si zwinne projekty? Co nap dza zwinny zespó Typowe role Wskazówki co do tworzenia Twojego zwinnego zespo u Cz II. Inicjacja projektu zwinnego Rozdzia 3. Jak zapakowa autokar Co zabija wi kszo projektów Zadawaj trudne pytania Zrób tablic koncepcyjn... 54

4 6 Zwinny samuraj 3.4. Jak to dzia a Tablica koncepcyjna w pigu ce Rozdzia 4. Kontekst projektu Zapytaj: po co tu jeste my? Tworzenie krótkiego podsumowania Projekt opakowania Stwórz list NIE Poznaj swoich s siadów Rozdzia 5. Realizacja Poka rozwi zanie Zapytaj, co nie da nam spokojnie spa Okre l rozmiar Wyja nij dok adnie, co zamierzasz dostarczy Poka, co si b dzie dzia o Cz III. Planowanie zwinnego projektu Rozdzia 6. Zbieranie historii u ytkowników Problem z dokumentacj Wprowad historie u ytkownika Cechy dobrych historii u ytkownika Jak przeprowadzi warsztaty zbierania historii Rozdzia 7. Szacowanie: pi kna sztuka zgadywania Problem z wysokopoziomowymi szacunkami Zamiana cytryn w lemoniad Jak to dzia a? Rozdzia 8. Zwinne planowanie: zmagania z rzeczywisto ci Problemy z planowaniem statycznym Stwórz zwinny plan B d elastyczny co do zakresu projektu Twój pierwszy plan

5 Spis tre ci Wykres malej cy Zmiana projektu w projekt zwinny Zastosowanie w praktyce Cz IV. Realizacja zwinnego projektu Rozdzia 9. Zarz dzanie iteracjami: dzia anie Jak dostarcza warto ciowe rzeczy co tydzie Zwinna iteracja Potrzebna pomoc Krok 1. Analiza i projektowanie: przygotowanie do pracy Krok 2. Programowanie: praca Krok 3. Testowanie: sprawdzanie pracy Kanban Rozdzia 10. Tworzenie zwinnego planu komunikacji Cztery rzeczy do zrobienia w ka dej iteracji SPH spotkanie planowania historii Pokaz Zaplanuj nast pn iteracj Jak poprowadzi miniprzegl d Jak nie prowadzi codziennych podsumowa Wykorzystaj to, co dzia a Rozdzia 11. Przygotowanie wizualizacji przestrzeni roboczej Oho Mamy k opoty! Jak stworzy wizualizacj przestrzeni roboczej Poka swoje zamiary Stwórz i og o wspólny s ownik dla danej dziedziny Uwa aj na b dy Cz V. Tworzenie zwinnego oprogramowania Rozdzia 12. Testowanie jednostkowe: wiedzie, e dzia a Witamy w Vegas! Wprowad testy jednostkowe

6 8 Zwinny samuraj Rozdzia 13. Refaktoryzacja: sp acanie d ugu technicznego Wprowadzanie dynamicznych zmian D ug techniczny Sp acanie przez refaktoryzacj Rozdzia 14. Programowanie oparte na testach (TDD) Najpierw napisz testy Wykorzystanie testów do opanowania z o ono ci Rozdzia 15. Ci g a integracja: utrzymywanie gotowo ci produkcyjnej Pokaz Kultura gotowo ci produkcyjnej Czym jest ci g a integracja? Jak to dzia a? Przygotuj proces publikacji kodu Stwórz automatyczn kompilacj Pracuj nad ma ymi fragmentami Co dalej? Dodatki Dodatek A. Zasady zwinno ci A.1. Manifest Agile A.2. Dwana cie zasad zwinno ci Dodatek B. Zasoby internetowe Dodatek C. Bibliografia

7 Rozdzia 4. Kontekst projektu Oprogramowanie to jedna z tych unikalnych aktywno ci, w których czy si projektowanie, konstruowanie, sztuk i nauk w jednym. Zespo y musz podejmowa tysi ce decyzji i kompromisów ka dego dnia. Bez dobrego kontekstu lub dok adnego zrozumienia niemo liwe jest wybieranie najlepszych rozwi za w sposób wiadomy i wywa ony. Na pocz tku tworzenia tablicy koncepcyjnej b dziemy próbowali bardzo jasno wyja ni dlaczego kryj ce si za naszym projektem, odpowiadaj c na takie pytania, jak: Dlaczego tu jeste my? Jak mo na to krótko podsumowa? Jak powinna wygl da reklama naszego produktu? Czego nie zamierzamy robi? Kto nas otacza?

8 58 Kontekst projektu Po przeczytaniu tego rozdzia u Ty i Twój zespó b dziecie dok adnie rozumieli, jaki jest cel projektu, b dziecie wiedzieli, dlaczego go tworzycie, i b dziecie w stanie jasno i szybko przekaza to innym. Ale najpierw zacznijmy od zapytania sponsorów: dlaczego tu jeste my Zapytaj: po co tu jeste my? Zanim jakikolwiek zespó projektowy b dzie móg odnie prawdziwy sukces, musi zrozumie dlaczego kryj ce si za tym, co tworzy. Gdy cz onkowie zespo u rozumiej dlaczego, mog : podejmowa lepsze, bardziej wiadome decyzje; w lepszy sposób godzi przeciwie stwa i wypracowywa kompromisy; tworzy lepsze, bardziej innowacyjne rozwi zania, poniewa mog my le samodzielnie. Chodzi tutaj te o to, by sam móg znale my l przewodni oraz wszystko zobaczy na w asne oczy. Id i przekonaj si sam Czym innym jest logicznie zrozumie, dlaczego si tutaj znale li my, a czym zupe nie innym samemu to zobaczy. Aby naprawd dok adnie wej w skór Twojego klienta i zrozumie, czego on potrzebuje, musisz pój i zobaczy to na w asne oczy. Pój i zobaczy oznacza, e cz onkowie Twojego zespo u musz ruszy ty ek i zobaczy miejsce, w którym odbywa si ca a akcja.

9 4.1. Zapytaj: po co tu jeste my? 59 Toyota: mistrzowie sprawdzania na w asne oczy W swojej wspania ej ksi ce Droga Toyoty [Lik04] Jeffrey Liker opisuje histori g ównego in yniera, któremu powierzono przeprojektowanie Toyoty Sienna 2004 pod k tem klientów z Ameryki Pó nocnej. Aby poczu, jak ludzie w Ameryce Pó nocnej yj, pracuj i u ywaj swoich samochodów, on i jego zespó przejechali Toyot Sienna przez wszystkie stany i prowincje USA, Kanad oraz Meksyk. Oto, co odkryli: Kierowcy w Ameryce Pó nocnej cz ciej jedz i pij w swoich samochodach ni kierowcy w Japonii (gdzie przemierzane dystanse s z regu y krótsze). Z tego powodu w ka dej Toyocie Sienna mo esz zobaczy na rodku podstawk i czterna cie uchwytów na kubki w standardzie. Drogi w Kanadzie maj wy sz koron (wypuk o na rodku) ni w Ameryce, dlatego kontrolowanie znoszenia podczas jazdy jest tam bardzo wa ne. Mocniejsze boczne wiatry w Ontario czyni odporno na boczne powiewy du o wa niejszym zagadnieniem do rozwi zania. Je li jedziesz gdzie przy silnym bocznym wietrze, nowa Sienna jest du o bardziej stabilna i atwiejsza do opanowania. Cho g ówny in ynier móg by to wyczyta w raporcie marketingowym, nie przej by si tym tak bardzo i nie zrozumia tak dok adnie, jak teraz po przejechaniu i zobaczeniu tych rzeczy na w asne oczy. Na przyk ad je li tworzysz system uprawnie dla firmy budowlanej pracuj cej przy wykopach, jed na budow. Porozmawiaj z osobami odpowiedzialnymi za bezpiecze stwo. Zobacz baraki. Popatrz na sparta skie warunki, kiepskie po czenie z internetem i ograniczone powierzchnie, na których musz pracowa Twoi klienci. Sp d dzie na budowie i popracuj z lud mi, którzy b d u ywa Twojego systemu dzie i noc. Zaanga- uj si, zadawaj pytania, sta si swoim klientem. Odkryj swoj my l przewodni My l przewodnia to krótkie wyra enie, fraza lub zdanie podsumowuj ce cel lub przyczyn Twojego projektu lub misji. To takie zdanie, wiat o rozja niaj ce drog, na które mo na si powo a w ka dym momencie, które w wirze walki pomo e zdecydowa, czy nale y atakowa, czy mo e utrzymywa pozycj.

10 60 Kontekst projektu W ksi ce Made to stick [HH07] Chip i Dan Heath opisuj histori, w której pracownicy firmy Southwest Airlines zastanawiali si, czy doda sa atk z kurczakiem w czasie jednego z lotów. Gdy pad o pytanie, czy zmniejszy to koszty i cen biletu (my l przewodnia dyrektora generalnego Herbsa Kellehera), sta o si jasne, e dodanie opcjonalnej sa atki z kurczakiem nie ma adnego sensu. My l przewodni Twojego projektu nie musi by nic wielkiego lub inspiruj cego. Mo e to by co naprawd prostego i zwi z ego. Kluczem do tego wiczenia jest sk onienie ludzi do rozmowy o tym, dlaczego ich zdaniem znajduj si oni w tym miejscu, a nast pnie potwierdzenie u Twojego klienta, czy rzeczywi cie dok adnie o to chodzi Tworzenie krótkiego podsumowania Szybko! Decydenci z funduszy venture (VC), do których chcieli cie si dosta przez ostatnie trzy miesi ce, w a nie wsiedli do windy i masz trzydzie ci sekund, eby wy o y im pomys na Twój nowy, wykluwaj cy si startup. Sukces sprawi, e Twoje przedsi wzi cie z apie wiatr w agle. Pora ka oznacza dalsze ycie na makaronie z serem. Taka jest idea krótkiego podsumowania (ang. elevator pitch) sposobu na przekazanie esencji Twojego pomys u w bardzo krótkim czasie. Krótkie podsumowania nie s jednak tylko dla pocz tkuj cych przedsi biorców. S one równie wspania ym sposobem na zwi z e opisanie nowych projektów programistycznych.

11 4.2. Tworzenie krótkiego podsumowania 61 S tysi ce powodów, aby wykona Twój projekt Ostatnio przeprowadzi em to wiczenie z zespo em maj cym zaprojektowa system fakturowania dla nowego dzia u firmy i by em zdumiony liczb przyczyn, które cz onkowie zespo u podali jako powód tworzenia nowego systemu. Niektórzy my leli, e powodem jest redukcja liczby stron na fakturze w celu oszcz dzania papieru. Inni my leli, e mia o to upro ci faktury i dzi ki temu zredukowa obci enie biura obs ugi klienta. Jeszcze inni my leli, e jest to okazja do uruchomienia profilowanych kampanii marketingowych, aby spróbowa sprzeda klientom dodatkowe produkty i us ugi. Wszystkie odpowiedzi by y dobre i ka da z nich osobno t umaczy- aby prowadzenie projektu. Ale tylko dzi ki d ugim dyskusjom, debatom i próbom zrozumienia pojawi si prawdziwy cel powstania projektu, którym by o po prostu uproszczenie faktur i zredukowanie rozmiaru biura obs ugi klienta. Dobre krótkie podsumowanie powinno spe nia kilka funkcji w Twoim projekcie. I. Wprowadzi jasno. Zamiast próby dostarczenia wszystkiego dla ka dego, krótkie podsumowanie zmusza zespó do odpowiedzenia na trudne pytanie czym jest produkt i dla kogo. II. Zmusi zespó do my lenia o kliencie. Skupiaj c si na tym, co ma by zrobione w projekcie i dlaczego, zespo y zyskuj warto ciowy wgl d w to, co jest wa ne w produkcie, a przede wszystkim, dlaczego klient go kupuje. III. Trafia w sedno. Jak laser, krótkie podsumowanie przecina mas py u i dociera do sedna tego, czym jest projekt. Ta jasno pomaga ustali priorytety i znakomicie poprawia stosunek sygna u do szumu na temat tego, co naprawd si liczy.

12 62 Kontekst projektu Przyjrzyjmy si teraz szablonowi, który pomo e przygotowa Twoje podsumowanie. Szablon krótkiego podsumowania dla [docelowy klient] który [opis potrzeby lub okazji] produkt [nazwa produktu] jest [kategoria produktu] który [kluczowa korzy, wa ny powód, by kupi ] w odró nieniu od [g ówna konkurencyjna alternatywa] nasz produkt [opis lub najwa niejsza przewaga]. Nie ma jednego sposobu na wykonanie krótkiego podsumowania. Ja lubi ten, który opisa Geoffrey Moore w ksi ce Crossing the Chasm [Moo91]. dla [docelowy klient] t umaczy, dla kogo jest projekt lub kto skorzysta z jego u ywania; który [opis potrzeby lub okazji] rozszerza problem lub potrzeb, któr chce zaspokoi klient; produkt [nazwa produktu] Nadaje ycia naszemu projektowi, przypisuj c mu nazw. Nazwy s wa ne, poniewa przekazuj zamiary; jest [kategoria produktu] t umaczy, czym w rzeczywisto ci ta us uga jest lub co oferuje produkt. Bycie zwi z ym jest trudne Jednym z powodów tak du ej mocy krótkiego podsumowania jest jego zwi z a forma. Nie my l jednak, e napisanie czego krótkiego jest proste. Mo e trzeba b dzie przej wiele prób, zanim Ty i Twój zespó znajdziecie dobre podsumowanie, dlatego nie martw si, je li nie trafisz za pierwszym razem. Napisanie dobrego podsumowania mo e by bardzo trudn prac, ale wart wysi ku. Napisa bym do Ciebie krótszy list, ale nie mia em czasu. stwierdzi Blaise Pascal w Prowincja kach.

13 4.3. Projekt opakowania 63 który [kluczowa korzy, wa ny powód, by kupi ] t umaczy, dlaczego Twój klient zechce kupi przede wszystkim ten produkt; w odró nieniu od [g ówna konkurencyjna alternatywa] mówi, dlaczego nie u ywamy nadal tego, co ju jest; nasz produkt [opis lub najwa niejsza przewaga] wyró nia i t umaczy, w jaki sposób nasz produkt si wyró nia lub dlaczego jest lepszy ni konkurencyjne rozwi zania. To najwa niejsza rzecz. Od tego zale y, czy otrzymamy pieni dze na nasz projekt. Dwa zdania krótkiego podsumowania obejmuj wszystko, czego potrzebujemy, by szybko przekaza esencj swojego projektu lub pomys u. Mówi one nam, czym i dla kogo jest nasz produkt, a przede wszystkim, dlaczego ktokolwiek móg by chcie go kupi. Mo esz przygotowywa krótkie podsumowanie ze swoim zespo em na wiele ró nych sposobów. Mo esz wydrukowa szablon i kaza wszystkim wype ni go samodzielnie, zanim zbierzesz wszystkich razem. Je li wolisz oszcz dzi kilka drzew, po prostu wy wietl szablon na ekranie i wype nij go razem z grup, przechodz c przez wszystkie elementy szablonu po kolei. Z krótkim podsumowaniem w d oni si gnijmy do Twojej kreatywno ci i zaprojektujmy opakowanie Waszego produktu Projekt opakowania

14 64 Kontekst projektu Oprogramowanie jest czasami z em koniecznym dla firm. Zamiast podejmowa ca e ryzyko i niepewno zwi zan z du ymi projektami, wiele z nich b dzie wola o i do sklepu, zap aci i po prostu kupi to, co jest niezb dne. Cho dok adnie dopasowane pakiety oprogramowania o warto ci milionów dolarów prawdopodobnie jeszcze d ugo nie zagoszcz na pó kach supermarketów, pojawia si interesuj ce pytanie. Gdyby my mogli znale nasze oprogramowanie na pó ce w supermarkecie, jak powinno wygl da jego opakowanie? I jeszcze wa niejsze: czy by my je kupili? Tworzenie opakowania dla Twojego projektu i postawienie pytania, dlaczego kto mia by je kupi, ka e Twojemu zespo owi skupi si na tym, co wa ne dla Twojego klienta, oraz na tym, jakie s dodatkowe korzy ci z Twojego produktu. Lepiej, eby zespó by wiadom obu tych rzeczy podczas tworzenia oprogramowania. Jak to dzia a? Wiem, co teraz my lisz. Nie jestem kreatywny. Nie pracuj w reklamie. Prawdopodobnie nie jestem w stanie stworzy reklamy swojego produktu. Mam dla Ciebie dobr wiadomo. Oczywi cie, e mo esz. A ja zamierzam Ci pokaza w trzech prostych krokach, jak to zrobi. Krok 1: urz d burz mózgów na temat korzy ci wynikaj cych z Twojego produktu Nigdy nie mów klientom o cechach Twojego produktu ich to nie obchodzi. Ludzie s jednak zainteresowani tym, w jaki sposób Twój produkt u atwi im ycie. Innymi s owy: korzy ciami wynikaj cymi z Twojego produktu. Za ó my przyk adowo, e próbujemy przekona rodzin do korzy ci wynikaj cych z kupienia minivana. Mogliby my pokaza im list wszystkich cech. Mo emy te pokaza, w jaki sposób minivan uczyni by ich ycie lepszym.

15 4.3. Projekt opakowania 65 Widzisz ró nic? Tak wi c pierwszym krokiem przy tworzeniu opakowania Twojego produktu jest zebranie Twojego zespo u oraz klientów i przeprowadzenie burzy mózgów na temat wszystkich powodów, dla których ludzie mogliby chcie u ywa tego produktu. Wybierz z nich trzy najwa niejsze. Krok 2: stwórz has o reklamowe Kluczem do dobrego sloganu jest to, by powiedzie tak du o, jak to tylko mo liwe za pomoc bardzo niewielu s ów. Nie musz Ci mówi, na czym skupiaj si poni sze firmy, poniewa ich slogany mówi wszystko: Acura Prawdziwa definicja luksusu. Dla Ciebie. FedEx Spokojna g owa. Starbucks Codzienne chwile przyjemno ci. Czy odczuwasz emocje p yn ce z tych hase? Teraz rozlu nij si. To ca kiem niez e slogany, a Twój nie musi by a tak profesjonalny. Po prostu spotkaj si ze swoim zespo em, ogranicz burz mózgów na temat has a reklamowego do dziesi ciu lub pi tnastu minut i ciesz si z tego, e mo esz po wiczy kreatywn cz swojego mózgu. Pami taj, aden slogan nie jest przes odzony. Krok 3: Zaprojektuj opakowanie Wspaniale! Jeste prawie u celu. Ze swoimi trzema przekonuj cymi powodami do zakupu i silnie przyci gaj cym sloganem jeste ju gotowy, by je po czy.

16 66 Kontekst projektu W tym wiczeniu wyobra sobie, e Twój klient wszed do sklepu z oprogramowaniem i zobaczy opakowanie Twojego produktu le ce na pó ce, a gdy je wzi do r ki, wygl da o tak przekonuj co, e od razu kupi dziesi sztuk dla siebie i swoich przyjació. A teraz szybko, narysuj to opakowanie! Nie musi to by druga Mona Lisa. U yj zwyk ego papieru do flipcharta, kolorowych markerów, papieru, nalepek i cokolwiek jeszcze wpadnie Ci w r ce. Wykrzycz swój slogan. Poka klientom zalety produktu. Po wi pi tna cie minut, aby zaprojektowa opakowanie produktu najlepsze, jakie jeste w stanie. Wspaniale! Widzisz, nie by o to takie trudne. Zabaw si troch przy tym (nie ka dego dnia mo esz u ywa kredek i kre li przekonuj cy obraz produktu). Jest to dobre wiczenie na budowanie zespo u i zabawny sposób, aby krytycznie pomy le na temat pytania dlaczego stoj cego za Twoim oprogramowaniem. Teraz zobaczmy, co mo na zrobi, aby rozpocz ustalanie oczekiwa co do zakresu naszego projektu Stwórz list NIE Podczas ustalania oczekiwa co do zakresu Twojego projektu powiedzenie, czego nie zamierzasz zrobi, mo e by tak samo wa ne, jak powiedzenie tego, co zamierzasz zrobi.

17 4.4. Stwórz list NIE 67 Tworz c list NIE, jasno okre lasz, co jest w zakresie, a co poza zakresem Twojego projektu. Zrobienie tego nie tylko jasno ustali oczekiwania Twojego klienta, ale tak e zapewni, e Ty i Twój zespó skupiacie si na rzeczach naprawd wa nych, ignoruj c wszystko inne. Jak to dzia a? Lista NIE jest wspania wizualizacj, przejrzy cie pokazuj c, co jest w zakresie, a co poza zakresem Twojego projektu. Po prostu siadasz ze swoim klientem i zespo em i podczas burzy mózgów na temat wszystkich ogólnych funkcjonalno ci, które klient chcia by zobaczy w swoim oprogramowaniu, wype niasz puste pola. W zawiera rzeczy, na których chcemy si skupi. Tutaj mówimy: To s wielkie g azy, które b dziemy przesuwa w tym projekcie. Mog to by najwa niejsze funkcjonalno ci (jak raportowanie) lub ogólne cele (jak skalowalno w stylu Amazon). POZA zawiera rzeczy, którymi nie chcemy sobie zawraca g owy. Mog to by rzeczy, które chcemy od o y do kolejnej wersji, lub po prostu takie, które s poza zakresem tego projektu. Na razie jednak nie zamierzamy si nimi przejmowa. Spadaj ze sto u. NIEWYJA NIONE to lista rzeczy, co do których jeszcze nie podj li my decyzji. Jest to bardzo warto ciowa pozycja, poniewa pokazuje prawd o wielu projektach programistycznych. Mog one znaczy wiele rzeczy dla wielu ludzi a tego w a nie chcemy unikn. W ko cu b dziemy chcieli przenie wszystkie nasze NIEWYJA NIONE do cz ci W lub POZA. Pi kno tej wizualnej prezentacji tkwi w tym, jak du o wida na pierwszy rzut oka. Szybko przegl daj c wa ne pozycje znajduj ce si w zakresie po lewej stronie, poza zakresem po prawej i w ko cu niewyja nione na dole, ka dy mo e wyrobi sobie jasny obraz tego, gdzie le granice naszego projektu.

18 68 Kontekst projektu Maj c wyra nie zdefiniowany zakres, mo emy i do przodu i zobaczy, kto znajduje si w otoczeniu projektu Poznaj swoich s siadów Dobrzy s siedzi mog by Twoimi najlepszymi przyjació mi. S pod r k, gdy zatrzasn Ci si drzwi. S pod r k, gdy potrzebujesz wiertarki. No, a zrobi si ca kiem mi o, gdy pomo esz im uruchomi sie bezprzewodow w domu. Pytanie za milion dolarów Przygotowywa em kiedy wspólnie z du kanadyjsk firm tablic koncepcyjn, gdy wiceprezes dzia u zapyta, jak ten nowy system b dzie zintegrowany z istniej cym przestarza ym mainframe em. W pokoju móg by us ysze spadaj c kropl. Wiceprezes, który podpisuje czeki i jest osobi cie odpowiedzialny za sukces tego projektu, nie wiedzia, e nowy system nigdy nie b dzie zintegrowany ze starym. On ma go po prostu zast pi. I to w a nie dlatego stworzyli my list NIE aby unikn du ej zmiany oczekiwa na jakim dalszym etapie projektu. Lepiej zrobi to teraz, ni próbowa zmieni co takiego, gdy projekt jest ju tworzony.

19 4.5. Poznaj swoich s siadów 69 Mo esz wierzy lub nie, ale Twój projekt ma te s siadów. Tyle e zamiast przechowywa zapasowe klucze i po ycza Ci wiertark, zarz dzaj oni bazami danych, robi audyty bezpiecze stwa i zapewniaj dzia anie sieci. Poznaj c swoich s siadów, mo esz na pocz tku zbudowa relacje, które b d owocowa y podczas trwania projektu. Poza tym kulturalnie jest powiedzie od czasu do czasu Cze i nie biec do nich dopiero, gdy Twój dom si pali. I, co najwa niejsze, podstaw ka dej odnosz cej sukcesy spo eczno ci projektowej jest zaufanie. Moja pierwsza du a wpadka projektowa Wszyscy pope niamy b dy. Jeden z moich najwi kszych pope ni em, prowadz c zespó ThoughtWorks wykonuj cy pewn prac w firmie Microsoft. Poszed em tam i zacz em projekt, my l c, e nasza spo eczno projektowa wygl da tak: I przez pewien czas wszystko by o w porz dku. Zespó pracowa w sposób zwinny. Regularnie dostarczali my dzia aj ce oprogramowanie i ycie by o pi kne. Nagle, pod koniec projektu, zacz o si dzia co dziwnego. Grupy i ludzie, których nigdy nie widzia em ani nie spotka em, nagle zacz li si pojawia znik d, stawiaj c dziwne wymagania mnie i mojemu zespo owi. Jedna z grup chcia a sprawdzi nasz architektur (jak gdyby nasza architektura wymaga a sprawdzania!). Inna chcia a si upewni, e wype niamy korporacyjne regu y bezpiecze stwa (ba!). Jeszcze inna chcia a zrobi przegl d naszej dokumentacji (jakiej dokumentacji?).

20 70 Kontekst projektu Kim byli ci wszyscy ludzie? Sk d si wzi li? I dlaczego tak bardzo chcieli pokrzy owa nasze plany? W ci gu jednej nocy nasza mi a ma a spo eczno projektowa zmieni a si z ma ego zespo u sze ciu ludzi w co du o wi kszego i rozbudowanego. Cho chcia em obwinia wszystkich dooko a, e ingeruj w nasze plany, tak naprawd nie doceni em stwierdzenia, e spo eczno zwi zana z projektem jest zawsze wi ksza, ni Ci si wydaje 1. W punkcie Poznaj swoich s siadów b dziesz chcia zrobi map spo- eczno ci zwi zanej z Twoim projektem, namierzy wszystkich i rozpocz budowanie relacji, zanim b dziesz ich potrzebowa. W ten sposób, gdy przyjdzie ten moment, nie b dziecie sobie kompletnie obcy i b d oni w du o lepszej pozycji, by Ci pomóc. Jak to dzia a? Zbierz ca y zespó i zróbcie burz mózgów, na której wynotujecie wszystkich ludzi, z którymi powinni cie si skontaktowa przed uruchomieniem projektu. Nieocenieni b d przy tym cz onkowie zespo u pracuj cy w firmie od dawna i wiadomi wszystkich regu korporacyjnych oraz pu apek organizacyjnych, które b dzie trzeba omin. Gdy ju wiesz, na czym stoisz, porozmawiaj z ka d z grup i ustal, czy mo- esz przypisa do ka dej nazwisko i dane kontaktowe. Twój mened er projektu czy inna osoba, która b dzie odpowiedzialna w projekcie za utrzymywanie takich zewn trznych relacji, mo e nast pnie opracowa plan zaanga owania tych grup. 1 The Blind Men and the Elephant [Sch03].

21 4.5. Poznaj swoich s siadów 71 Kawa, p czki i szczero Je li chodzi o budowanie poprawnych relacji z s siadami, trudno przeceni dobr kaw z p czkiem Kawa, poniewa jest serwowana w mi ym, ciep ym kubku i s siedzi, oprócz tego, e si z niej uciesz, b d Ci kojarzy z uczuciem ciep a. P czki, poniewa gdy b dziesz mówi swoim s siadom, jak bardzo doceniasz to, e masz ich obok siebie, ich cia a b d cieszy y si s odkim smakiem cukru i dzi ki temu s siedzi b d Ci kojarzy ze s odycz. Ale najwa niejszym narz dziem do budowania wspania ych relacji z Twoimi s siadami jest szczero. Aby Twoi s siedzi poczuli si naprawd docenieni i warto ciowi, musisz ich tak postrzega. Wy api oni nieszczere pochwa y w u amku sekundy. Ale prawdziwe uznanie i szczere podzi kowania pozwol szybko ich do siebie przekona. A Ty i Twój projekt wi cej na tym skorzystacie. UCZE : Mistrzu, sporo tych wicze wymaga czasu od sponsorów i udzia- owców. A co je li s oni niedost pni lub zbyt zaj ci, aby odpowiada na tego typu pytania dotycz ce projektu?

22 72 Kontekst projektu MISTRZ: Wtedy mo esz sobie pogratulowa. Za to, e w a nie odkry e najwi ksze ryzyko swojego projektu. UCZE : Co to za ryzyko? MISTRZ: Zaanga owanie klienta. Bez zaanga owanego klienta Twój projekt ma problemy, zanim si jeszcze zacznie. Je li Twoi klienci nie maj czasu, eby powiedzie Ci, dlaczego piszesz dla nich to oprogramowanie, to mo e wcale nie nale y go pisa. UCZE : Czy mówisz, e wtedy powinni my zatrzyma projekt? MISTRZ: Mówi, e aby mie udany projekt, potrzebujesz zaanga owania klientów i udzia owców. I e bez tego jeste zgubiony, niezale nie, czy Ci si to podoba, czy nie. Ucze : Je li co takiego nast pi, co powinienem zrobi? MISTRZ: Musisz jasno, ale dobitnie wyt umaczy klientom, czego b dzie wymaga o przeprowadzenie tego projektu z sukcesem. Ich zaanga owanie i po wi cenie s niezb dne. Mo e to nie jest dobry czas na ten projekt? Prawdopodobnie oni s naprawd zaj ci i po prostu maj za du o na g owie. Je li tak jest, powiedz im, e b dziesz do ich dyspozycji, gdy b d gotowi, a tymczasem masz innych klientów do obs u enia. UCZE : Dzi kuj, Mistrzu. Musz to przemy le. Co dalej? Zanim pójdziemy dalej, zatrzymajmy si i odetchnijmy. Czujesz to? Widzisz, co si tutaj dzieje? Z ka dym kolejnym wiczeniem tablicy koncepcyjnej istota i zakres projektu staj si coraz bardziej zrozumia e. Znamy dlaczego stoj ce za naszym projektem. Mamy dobre krótkie podsumowanie. Wiemy, jak powinno wygl da opakowanie naszego produktu. Ustawiamy wyra ne ograniczniki zakresu projektu. Mamy do dobre rozeznanie w ród naszych s siadów.

23 4.5. Poznaj swoich s siadów 73 Wiem, co teraz my lisz. Znamy ju wystarczaj co kontekst! Kiedy przejdziemy do rzeczy i zaczniemy rozmawia o tym, jak to zbudowa? W a- nie teraz. W rozdziale 5. zaczniemy wizualizowa Twój projekt od strony technicznej i dowiemy si, co b dzie potrzebne do jego zrealizowania. Zatem odwró stron i przygotuj si do dzia ania.

24 74 Kontekst projektu

25 Skorowidz A Acura, slogan, 65 adaptacyjne planowanie, 22 adaptive planning, Patrz adaptacyjne planowanie agile planning, Patrz zwinne planowanie analityk, 39, 91 analiza, 171 na-czas, 172 architektura, wybór, 77 automatyczna kompilacja, 250, 251, 252 oprogramowanie, 251 B Beck, Kent, 102, 218, 241 Bloomberg, Michael, 79 b dy, 205 bud et, 92, 93 C Carnegie, Dale, 190 ci g a integracja, 247, 248, 252 coach, 45 coaching, 45 collective code ownership, Patrz wspó w asno kodu cone of uncertainty, Patrz sto ek niepewno ci CruiseControl, 251 wiczenie Druckera, 42 D deliver by date, Patrz dostarczenie oprogramowania w okre lonym terminie deliver by feature set, Patrz dostarczenie okre lonego zestawu funkcjonalno ci diagram przep ywu, 173 d ug techniczny, 223, 224 Dodds, Keith, 52 dokumentacja, 100, 101 porównanie z historiami u ytkownika, 107 problemy, 100, 101 dostarczenie okre lonego zestawu funkcjonalno ci, 149, 150, 151

26 266 Zwinny samuraj dostarczenie oprogramowania w okre lonym terminie, 149, 150 Droga Toyoty, ksi ka, 59 Druckera, wiczenie, 42 E elastyczno co do zakresu, 21 elevator pitch, Patrz krótkie podsumowanie Evans, Eric, 205 F Feathers, Martin, 231 Feathers, Michael, 216 FedEx, slogan, 65 flexible on scope, Patrz elastyczno co do zakresu Fowler, Martin, 102, 231, 253 G Galton, Francis, 130 Gibbons, Robin, 54 Git, 249 g ówna lista historii, 21, 26, 138, 143 gotowo produkcyjna, 246 H has o reklamowe, 65 Heath, Chip i Dan, 60 historie u ytkownika, 21, 103, 104 cechy, 104, 105 negocjowalne, 106 pomoc w pisaniu, 108 porównanie z dokumentacj, 107 s owa kluczowe, 103 szablon, 111, 112 testowalne, 106 idealne dni, 127 inception deck, Patrz tablica koncepcyjna informacje zwrotne, 19, 190 integracja ci g a, 247, 248, 252 INVEST, 107 iteracja, 21, 26, 138, 169 "0", 178 planowanie, 189 przyk ady, 170 rzeczy do zrobienia, 186 Jobs, Steve, 31 I J K Kanban, 180, 181, 182 Kelleher, Herbs, 60 klient, 26, 36, 91 kontakt, 19 nowe wymagania, 157 w zespole, 31, 37 zaanga owany, 30, 31, 37 zwinny, 36, 37 kod publikacja, 249 wspó w asno, 179 kompilacja automatyczna, 250, 251, 252 oprogramowanie, 251 krótkie podsumowanie, 55, 62, 63 funkcje, 61 idea, 60 szablon, 62 tworzenie, 60

27 Skorowidz 267 Lean, 25 Liker, Jeffrey, 59 L M Made to stick, ksi ka, 60 Manifest Agile, 259 master story list, Patrz g ówna lista historii McConnel, Steve, 120 mened er projektu, 43, 91 metody zwinne, 21, 22, 23 role w projektach, 36 minimal marketable feature set, Patrz minimalny sprzedawalny zestaw funkcjonalno ci minimalny sprzedawalny zestaw funkcjonalno ci, 144 miniprzegl d, prowadzenie, 190 mistrz scruma, 45 MMF, Patrz minimalny sprzedawalny zestaw funkcjonalno ci Moore, Geoffrey, 62 Mott, Randy, 82, 83 my l przewodnia, 59, 60 N negocjowalne historie u ytkownika, 106 O odbudowanie wiarygodno ci u klienta, 32 on-site customer, Patrz klient w zespole opakowanie, projekt, 63, 64, 65, 66 opis produktu, Patrz g ówna lista historii oprogramowanie dostarczanie, 18, 19, 20 P personas, Patrz role plan, tworzenie, 138, 139, 143 planistyczny poker, 131 planowanie, 137, 138 adaptacyjne, 22 priorytety, 147 statyczne, 136 zwinne, 21 PM, Patrz mened er projektu podsumowania codzienne, 192 prowadzenie, 190, 191, 192 pokaz, 188 szybkie przygotowanie, 244 poker planistyczny, 131 powie ci, 115 product owner, Patrz w a ciciel produktu programista, 40, 91 programowanie oparte na testach, 234, 237, 238 praca, 177 w parach, 176 programowanie ekstremalne, 31, 215, 246 nazewnictwo, 26 projekt bud et, 92, 93 czas trwania, 81, 82, 83 elastyczno, 140, 142 klient, 36, 37 koniec czasu, 161 my l przewodnia, 59, 60 opakowanie, 63, 64, 65, 66 prezentacja planu, 90 problemy, 198 rozmiar, 81, 83

28 268 Zwinny samuraj projekt ryzyka, 77, 78, 79, 80 mier, 52 trzy proste prawdy, 24, 25 ustalanie terminów, 149 wpadki, 69 zakres, 66, 67, 144 zespó programistyczny, 38 zmiana w projekt zwinny, 155 zwinny, 27, 28, 29 ród o mieci, 146 projektant interakcji z u ytkownikiem, 44, 91 publikacja kodu, 249 R refaktoryzacja, 221, 224, 225, 226, 227, 229, 230, 231 release, Patrz wydanie repozytoria, 249 role, 174 rozmiar projektu, 81, 83 ryzyka projektowe, 77 rozmowa, 78, 79, 80 S samoorganizacja zespo u, 32, 33 Scrum, 25, 31 mistrz scruma, 45 nazewnictwo, 26 scrum master, Patrz Scrum, mistrz scruma slogany, 65 Acura, 65 FedEx, 65 Starbucks, 65 s ownik, opracowanie, 204 SPH, Patrz spotkanie planowania historii SPI, Patrz spotkanie planowania iteracji spike, Patrz szpilka sposób sparta skiego wojownika, 159 spotkanie planowania historii, 186, 187 spotkanie planowania iteracji, 189 sprint, Patrz iteracja Starbucks, slogan, 65 statyczne planowanie, 136 sto ek niepewno ci, 120, 121 Subversion, 249 Surowiecki, James, 130 system punktowy, 124, 125, 126 szacowanie, 120, 121 bezwzgl dne, 124 dok adne, 121 planistyczny poker, 131 problemy, 120 system punktowy, 124, 125, 126 triangulacja, 127 wzgl dne, 123, 124 szpilka, 130 szybko zespo u, 21, 138, 148 szacowanie, 147, 149 T tablica historii, 199, 200, 201, 202 tablica koncepcyjna, 51, 54, 55, 57, 199, 201 idea, 54 podsumowanie, 93 w pigu ce, 55 tablica wska ników, 87, 88, 89 tablica wydania, 199 TDD, Patrz programowanie oparte na testach

29 Skorowidz 269 team velocity, Patrz szybko zespo u test-driven development, Patrz programowanie oparte na testach tester, 41, 42, 91 testowalne historie u ytkownika, 106 testowanie, 178, 179 testy akceptacyjne u ytkownika, 179 testy jednostkowe, 214, 215, 216, 217, 218 The Pixar Touch, film, 31 ThoughtWorks, 52, 54, 69, 87 triangulacja, 127 trudne pytania, 52 U UAT, Patrz testy akceptacyjne u ytkownika user stories, Patrz historie u ytkownika UX, Patrz projektant interakcji z u ytkownikiem V visual workspace, Patrz wizualizacja przestrzeni roboczej W Wake, Bill, 107 warsztaty zbierania historii, 112 wizualizacja przestrzeni roboczej, 197, 201 tworzenie, 201 wizualizacja rozwi zania, 76 w a ciciel produktu, Patrz klient w a ciciel projektu, 37 wpadki projektowe, 69 wspó w asno kodu, 179 W ciek a Czwórka, 85, 86 bud et, 86 czas, 86 jako, 86 zakres, 87 wydanie, 144 wykres malej cy, 151, 152, 153, 200 wykres rosn cy, 153, 154 wymagania, 102 XP, 25 X Z zasady zwinno ci, 20, 24, 31, 33, 34, 102, 141, 144, 190, 226 wszystkie, 260 zespó, 90 cross-functional, Patrz zespó, wszechstronno miejsce pracy, 30 odbudowanie wiarygodno ci u klienta, 32 odpowiedzialno i samodzielno, 33, 34 rozproszony, 30 samoorganizacja, 32, 33 spotkania, 192, 193 szybko, 21, 138, 147, 148, 149 szybko mniejsza od planowanej, 158 typowe role, 36 utrata cz onka, 160 wspólny j zyk z klientem, 204 wszechstronno, 34, 35, 46 zaanga owani klienci, 30, 31 zwinny, 27, 28, 29, 38

30 270 Zwinny samuraj zespó programistyczny, 36, 38 analityk, 39, 91 klient, 91 mened er projektu, 43, 91 programista, 40, 91 projektant interakcji z u ytkownikiem, 44, 91 tester, 41, 42, 91 zwinna analiza, 171, 172 zwinne metody, 21, 22, 23 zwinne planowanie, 21 zwinno ci, zasady, 20, 24, 31, 33, 34, 102, 141, 144, 190, 226 wszystkie, 260 zwinny projekt, 27, 28, 29 zwinny zespó, 27, 28, 29, 38 Czytaj dalej...