Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00304 005318 13089635 na godz. na dobę w sumie
Zwinny samuraj. Jak programują mistrzowie zwinności - książka
Zwinny samuraj. Jak programują mistrzowie zwinności - książka
Autor: Liczba stron: 272
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3483-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).

Podręcznik zwinnego zespołu!

Konkurencja na rynku oprogramowania, oczekiwania klientów oraz tempo życia wymagają zmiany podejścia do wytwarzania aplikacji. Klienci nie chcą już czekać miesiącami na pierwszą wersję zamówionego produktu - chcą zobaczyć cokolwiek już za tydzień! Niemożliwe? A jednak! Jeśli zastosujesz zwinne praktyki, masz szansę błyskawicznie pokazać klientowi działające zręby aplikacji, a w kolejnych (krótkich!) iteracjach kolejne efekty. Zobacz, jaki wpływ na efektywność może mieć zwinność. Sprawdź, jak dobrać ludzi do zwinnego zespołu oraz jak nim zarządzać.

Jonathan w swojej książce zaprezentuje Ci wszystko, co musisz wiedzieć na temat zwinnych praktyk. Dowiesz się, jak ważny jest zespół, co go napędza i jakie role pełnią jego członkowie. Najpierw poznasz największe zagrożenia dla projektu i zalety tablic koncepcyjnych oraz przygotujesz się do rozpoczęcia fazy realizacji. Kolejne rozdziały zawierają niezbędne informacje poświęcone planowaniu, szacowaniu oraz zarządzaniu iteracjami. Dodatkowo na własne oczy zobaczysz, jak ważne są testy jednostkowe, refaktoryzacja oraz ciągła integracja w procesie wytwarzania oprogramowania. Książka ta jest idealnym źródłem informacji dla członków zwinnych zespołów oraz osób, które kolejny projekt chciałyby zrealizować z wykorzystaniem właśnie tej metodologii.

Poznaj nowoczesne metodologie wytwarzania oprogramowania!


Jonathan Rasmusson ma ponad dziesięć lat doświadczenia w branży. Jest przedsiębiorcą i zwinnym trenerem związanym z firmami ThoughtWorks oraz Cortex Business Solutions, a także międzynarodowym konsultantem. Od dawna pomaga innym znaleźć najlepsze rozwiązania i sposoby pracy. Brał także udział w tworzeniu zaawansowanych systemów dla dużych firm, takich jak Microsoft czy British Petroleum.

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

Darmowy fragment publikacji:

Tytuł oryginału: The Agile Samurai: How Agile Masters Deliver Great Software Tłumaczenie: Andrzej Stefański ISBN: 978-83-246-3483-5 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, 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/zwisam Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treĂci PodziÚkowania ...................................................................................... 9 Dobrze CiÚ widzieÊ ............................................................................. 11 CzÚĂÊ I. Wprowadzenie ............................................................ 15 Rozdziaï 1. ZwinnoĂÊ w piguïce ........................................................ 17 1.1. Dostarczaj czegoĂ wartoĂciowego co tydzieñ ............................................... 18 1.2. Jak dziaïa zwinne planowanie? .................................................................. 21 1.3. Zrobione oznacza zrobione ....................................................................... 23 1.4. Trzy proste prawdy .................................................................................. 24 Rozdziaï 2. Poznaj swój zwinny zespóï ............................................ 27 2.1. Czym wyróĝniajÈ siÚ zwinne projekty? ....................................................... 28 2.2. Co napÚdza zwinny zespóï ........................................................................ 30 2.3. Typowe role ............................................................................................. 36 2.4. Wskazówki co do tworzenia Twojego zwinnego zespoïu .............................. 45 CzÚĂÊ II. Inicjacja projektu zwinnego .................................... 49 Rozdziaï 3. Jak zapakowaÊ autokar ................................................. 51 3.1. Co zabija wiÚkszoĂÊ projektów ................................................................... 52 3.2. Zadawaj trudne pytania ............................................................................ 52 3.3. Zrób tablicÚ koncepcyjnÈ .......................................................................... 54 6  Zwinny samuraj 3.4. Jak to dziaïa ............................................................................................. 54 3.5. Tablica koncepcyjna w piguïce .................................................................. 55 Rozdziaï 4. Kontekst projektu ........................................................... 57 4.1. Zapytaj: po co tu jesteĂmy? ....................................................................... 58 4.2. Tworzenie krótkiego podsumowania .......................................................... 60 4.3. Projekt opakowania .................................................................................. 63 4.4. Stwórz listÚ „NIE” ................................................................................... 66 4.5. Poznaj swoich sÈsiadów ............................................................................ 68 Rozdziaï 5. Realizacja ......................................................................... 75 5.1. Pokaĝ rozwiÈzanie .................................................................................... 76 5.2. Zapytaj, co nie da nam spokojnie spaÊ ....................................................... 77 5.3. OkreĂl rozmiar ......................................................................................... 81 5.4. WyjaĂnij dokïadnie, co zamierzasz dostarczyÊ ............................................. 83 5.5. Pokaĝ, co siÚ bÚdzie dziaïo ........................................................................ 90 CzÚĂÊ III. Planowanie zwinnego projektu ............................. 97 Rozdziaï 6. Zbieranie historii uĝytkowników ................................. 99 6.1. Problem z dokumentacjÈ ......................................................................... 100 6.2. Wprowadě historie uĝytkownika .............................................................. 103 6.3. Cechy dobrych historii uĝytkownika ......................................................... 104 6.4. Jak przeprowadziÊ warsztaty zbierania historii .......................................... 112 Rozdziaï 7. Szacowanie: piÚkna sztuka zgadywania .................... 119 7.1. Problem z wysokopoziomowymi szacunkami ............................................ 120 7.2. Zamiana cytryn w lemoniadÚ .................................................................. 121 7.3. Jak to dziaïa? ......................................................................................... 127 Rozdziaï 8. Zwinne planowanie: zmagania z rzeczywistoĂciÈ .... 135 8.1. Problemy z planowaniem statycznym ....................................................... 136 8.2. Stwórz zwinny plan ................................................................................ 138 8.3. BÈdě elastyczny co do zakresu projektu .................................................... 140 8.4. Twój pierwszy plan ................................................................................ 143 Spis treĂci  7 8.5. Wykres malejÈcy .................................................................................... 151 8.6. Zmiana projektu w projekt zwinny .......................................................... 155 8.7. Zastosowanie w praktyce ........................................................................ 156 CzÚĂÊ IV. Realizacja zwinnego projektu .............................. 165 Rozdziaï 9. ZarzÈdzanie iteracjami: dziaïanie .............................. 167 9.1. Jak dostarczaÊ wartoĂciowe rzeczy co tydzieñ ............................................ 168 9.2. Zwinna iteracja ...................................................................................... 169 9.3. Potrzebna pomoc ................................................................................... 170 9.4. Krok 1. Analiza i projektowanie: przygotowanie do pracy ......................... 171 9.5. Krok 2. Programowanie: praca ............................................................... 177 9.6. Krok 3. Testowanie: sprawdzanie pracy .................................................. 178 9.7. Kanban ................................................................................................. 180 Rozdziaï 10. Tworzenie zwinnego planu komunikacji ................. 185 10.1. Cztery rzeczy do zrobienia w kaĝdej iteracji ............................................ 186 10.2. SPH — spotkanie planowania historii .................................................. 186 10.3. Pokaz .................................................................................................. 188 10.4. Zaplanuj nastÚpnÈ iteracjÚ .................................................................... 188 10.5. Jak poprowadziÊ miniprzeglÈd ............................................................... 190 10.6. Jak nie prowadziÊ codziennych podsumowañ .......................................... 192 10.7. Wykorzystaj to, co dziaïa ...................................................................... 193 Rozdziaï 11. Przygotowanie wizualizacji przestrzeni roboczej .... 197 11.1. Oho… Mamy kïopoty! ......................................................................... 198 11.2. Jak stworzyÊ wizualizacjÚ przestrzeni roboczej ......................................... 201 11.3. Pokaĝ swoje zamiary ............................................................................ 203 11.4. Stwórz i ogïoĂ wspólny sïownik dla danej dziedziny ................................ 204 11.5. Uwaĝaj na bïÚdy .................................................................................. 205 CzÚĂÊ V. Tworzenie zwinnego oprogramowania ................ 209 Rozdziaï 12. Testowanie jednostkowe: wiedzieÊ, ĝe dziaïa ........ 211 12.1. Witamy w Vegas! ................................................................................. 212 12.2. Wprowadě testy jednostkowe ................................................................ 214 8  Zwinny samuraj Rozdziaï 13. Refaktoryzacja: spïacanie dïugu technicznego ....... 221 13.1. Wprowadzanie dynamicznych zmian ..................................................... 222 13.2. Dïug techniczny ................................................................................... 223 13.3. Spïacanie przez refaktoryzacjÚ ............................................................... 225 Rozdziaï 14. Programowanie oparte na testach (TDD) ................ 233 14.1. Najpierw napisz testy ............................................................................ 234 14.2. Wykorzystanie testów do opanowania zïoĝonoĂci .................................... 238 Rozdziaï 15. CiÈgïa integracja: utrzymywanie gotowoĂci produkcyjnej ................... 243 15.1. Pokaz .................................................................................................. 244 15.2. Kultura gotowoĂci produkcyjnej ............................................................. 246 15.3. Czym jest ciÈgïa integracja? .................................................................. 247 15.4. Jak to dziaïa? ....................................................................................... 248 15.5. Przygotuj proces publikacji kodu ........................................................... 249 15.6. Stwórz automatycznÈ kompilacjÚ ........................................................... 250 15.7. Pracuj nad maïymi fragmentami ............................................................ 252 15.8. Co dalej? ............................................................................................. 254 Dodatki .................................................................................... 257 Dodatek A. Zasady zwinnoĂci .......................................................... 259 A.1. Manifest Agile ...................................................................................... 259 A.2. DwanaĂcie zasad zwinnoĂci .................................................................... 260 Dodatek B. Zasoby internetowe ...................................................... 261 Dodatek C. Bibliografia .................................................................... 263 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 mu- szÈ podejmowaÊ tysiÈce decyzji i kompromisów kaĝdego dnia. Bez dobre- go kontekstu lub dokïadnego zrozumienia niemoĝliwe jest wybieranie naj- lepszych 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? 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. 4.1. 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ïon- kowie 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. 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 przeprojektowa- nie 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 dy- stanse 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 marketingo- wym, 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 pra- cujÈcej przy wykopach, jedě na budowÚ. Porozmawiaj z osobami odpo- wiedzialnymi 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 popra- cuj 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Ú. 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 inspi- rujÈcego. Moĝe to byÊ coĂ naprawdÚ prostego i zwiÚzïego. Kluczem do tego Êwiczenia jest skïonienie ludzi do rozmowy o tym, dla- czego ich zdaniem znajdujÈ siÚ oni w tym miejscu, a nastÚpnie potwier- dzenie u Twojego klienta, czy rzeczywiĂcie dokïadnie o to chodzi. 4.2. 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 trzy- dzieĂ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 cza- sie. Krótkie podsumowania nie sÈ jednak tylko dla poczÈtkujÈcych przed- siÚbiorców. SÈ one równieĝ wspaniaïym sposobem na zwiÚzïe opisanie nowych projektów programistycznych. 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 za- projektowaÊ 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 faktu- rze 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 profilowa- nych 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, deba- tom i próbom zrozumienia pojawiï siÚ prawdziwy cel powstania pro- jektu, 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 pod- sumowanie 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 produk- cie, 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Ê priory- tety i znakomicie poprawia stosunek sygnaïu do szumu na temat tego, co naprawdÚ siÚ liczy. 62  Kontekst projektu Przyjrzyjmy siÚ teraz szablonowi, który pomoĝe przygotowaÊ Twoje pod- sumowanie. 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 sko- rzysta 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È za- miary;  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óï znaj- dziecie 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. 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ïu- maczy, 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 potrze- bujemy, by szybko przekazaÊ esencjÚ swojego projektu lub pomysïu. Mó- wiÈ one nam, czym i dla kogo jest nasz produkt, a przede wszystkim, dla- czego 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 sza- blonu po kolei. Z krótkim podsumowaniem w dïoni siÚgnijmy do Twojej kreatywnoĂci i zaprojektujmy opakowanie Waszego produktu. 4.3. Projekt opakowania 64  Kontekst projektu Oprogramowanie jest czasami zïem koniecznym dla firm. Zamiast podej- mowaÊ 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 super- marketó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 Two- jego 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 zamie- rzam 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 ob- chodzi. 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 pro- duktu. Zaïóĝmy przykïadowo, ĝe próbujemy przekonaÊ rodzinÚ do korzyĂci wynika- jÈ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. 4.3. Projekt opakowania  65 Widzisz róĝnicÚ? Tak wiÚc pierwszym krokiem przy tworzeniu opakowania Twojego pro- duktu 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 po- wodami do zakupu i silnie przyciÈgajÈcym sloganem jesteĂ juĝ gotowy, by je poïÈczyÊ. 66  Kontekst projektu W tym Êwiczeniu wyobraě sobie, ĝe Twój klient wszedï do sklepu z opro- gramowaniem 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ï dzie- siÚÊ 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. 4.4. Stwórz listÚ „NIE” Podczas ustalania oczekiwañ co do zakresu Twojego projektu powiedze- nie, czego nie zamierzasz zrobiÊ, moĝe byÊ tak samo waĝne, jak powie- dzenie tego, co zamierzasz zrobiÊ. 4.4. Stwórz listÚ „NIE”  67 TworzÈc listÚ „NIE”, jasno okreĂlasz, co jest w zakresie, a co poza zakre- sem 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 opro- gramowaniu, 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 skalo- walnoĂÊ 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. 68  Kontekst projektu MajÈc wyraěnie zdefiniowany zakres, moĝemy iĂÊ do przodu i zobaczyÊ, kto znajduje siÚ w otoczeniu projektu. 4.5. 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 pro- jektu, 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. 4.5. Poznaj swoich sÈsiadów  69 Moĝesz wierzyÊ lub nie, ale Twój projekt ma teĝ sÈsiadów. Tyle ĝe za- miast 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 po- wiedzieÊ 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, pro- wadzÈc zespóï ThoughtWorks wykonujÈcy pewnÈ pracÚ w firmie Microsoft. Poszedïem tam i zaczÈïem projekt, myĂlÈc, ĝe nasza spoïecznoĂÊ projek- towa 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 lu- dzie, 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 bez- pieczeñstwa (ba!).  Jeszcze inna chciaïa zrobiÊ przeglÈd naszej dokumentacji (jakiej do- kumentacji?). 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 pro- jektem jest zawsze wiÚksza, niĝ Ci siÚ wydaje1. 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 pro- jektu. Nieocenieni bÚdÈ przy tym czïonkowie zespoïu pracujÈcy w firmie od dawna i Ăwiadomi wszystkich reguï korporacyjnych oraz puïapek organiza- cyjnych, 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 pro- jektu czy inna osoba, która bÚdzie odpowiedzialna w projekcie za utrzymy- wanie takich zewnÚtrznych relacji, moĝe nastÚpnie opracowaÊ plan zaan- gaĝowania tych grup. 1 The Blind Men and the Elephant [Sch03]. 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, mu- sisz 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? 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ĝowa- nia 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ïo- wie. JeĂli tak jest, powiedz im, ĝe bÚdziesz do ich dyspozycji, gdy bÚdÈ go- towi, 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 pro- jektu 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. 4.5. Poznaj swoich sÈsiadów  73 Wiem, co teraz myĂlisz. Znamy juĝ wystarczajÈco kontekst! Kiedy przej- dziemy 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. 74  Kontekst projektu 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 m Ê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 266  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 Zwinny samuraj I 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 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 funkcje, 61 idea, 60 szablon, 62 tworzenie, 60 kod 252 publikacja, 249 wspóïwïasnoĂÊ, 179 kompilacja automatyczna, 250, 251, oprogramowanie, 251 krótkie podsumowanie, 55, 62, 63 Skorowidz 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  267 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 projekt nazewnictwo, 26 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 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 SPI, Patrz spotkanie planowania historii 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 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 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, zwinny projekt, 27, 28, 29 zwinny zespóï, 27, 28, 29, 38 102, 141, 144, 190, 226 wszystkie, 260
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Zwinny samuraj. Jak programują mistrzowie zwinności
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ą: