Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00368 007149 14485559 na godz. na dobę w sumie
Agile. Wzorce wdrażania praktyk zwinnych - książka
Agile. Wzorce wdrażania praktyk zwinnych - książka
Autor: Liczba stron: 408
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-2318-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Poznaj metody wdrażania praktyk zwinnych i twórz perfekcyjne oprogramowanie!

Metody zwinne mają pomóc Ci w tworzeniu oprogramowania dostarczającego więcej walorów biznesowych -- dzięki nim powinieneś robić to nie tylko szybciej i taniej, ale też bezpiecznie i bezstresowo. Okazuje się jednak, że wiele organizacji ma problemy z implementowaniem i pełnym wykorzystaniem tych metod. Jeśli nie chcesz dołączyć do tego grona, powinieneś skorzystać z tej książki -- zaprezentowano w niej najlepsze praktyki doskonalące proces wytwarzania oprogramowania, a poza tym wskazano konkretne powody wyboru zalecanych praktyk.

Książka 'Agile Adoption Patterns A Roadmap to Organizational Success ' w sposób wyczerpujący, a jednocześnie zrozumiały prezentuje proces definiowania optymalnej strategii wdrażania praktyk zwinnych. W podręczniku zanalizowane zostały także najważniejsze przeszkody na drodze do implementacji metod zwinnych, obok których zaprezentowano sprawdzone rozwiązania tych problemów. Z tego przewodnika dowiesz się, jak wybrać praktyki najlepsze dla Twojej firmy i Twojego środowiska technicznego oraz jak przyrostowo wdrażać metody zwinne. Nauczysz się efektywnego tworzenia oprogramowania niezależnie od Twojej roli w projekcie -- lidera, programisty, architekta lub klienta.

Oto podręcznik efektywnego wdrażania praktyk zwinnych, które bez trudu zaimplementujesz do swojego projektu!

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

Darmowy fragment publikacji:

Agile. Wzorce wdra¿ania praktyk zwinnych Autor: Amr Elssamadisy T³umaczenie: Miko³aj Szczepaniak ISBN: 978-83-246-2318-1 Tytu³ orygina³u: Agile Adoption Patterns: A Roadmap to Organizational Success Format: 168x237, stron: 408 Poznaj metody wdra¿ania praktyk zwinnych i twórz perfekcyjne oprogramowanie! • Jak wykorzystywaæ wzorce wdra¿ania praktyk zwinnych? • Jak stosowaæ praktyki b³yskawicznego i efektywnego gromadzenia informacji zwrotnych? • Jak integrowaæ grupy praktyk zwinnych, podnosz¹c ich ³¹czn¹ skutecznoœæ? Metody zwinne maj¹ pomóc Ci w tworzeniu oprogramowania dostarczaj¹cego wiêcej walorów biznesowych — dziêki nim powinieneœ robiæ to nie tylko szybciej i taniej, ale te¿ bezpiecznie i bezstresowo. Okazuje siê jednak, ¿e wiele organizacji ma problemy z implementowaniem i pe³nym wykorzystaniem tych metod. Jeœli nie chcesz do³¹czyæ do tego grona, powinieneœ skorzystaæ z tej ksi¹¿ki — zaprezentowano w niej najlepsze praktyki doskonal¹ce proces wytwarzania oprogramowania, a poza tym wskazano konkretne powody wyboru zalecanych praktyk. Ksi¹¿ka „Agile Adoption Patterns A Roadmap to Organizational Success” w sposób wyczerpuj¹cy, a jednoczeœnie zrozumia³y prezentuje proces definiowania optymalnej strategii wdra¿ania praktyk zwinnych. W podrêczniku zanalizowane zosta³y tak¿e najwa¿niejsze przeszkody na drodze do implementacji metod zwinnych, obok których zaprezentowano sprawdzone rozwi¹zania tych problemów. Z tego przewodnika dowiesz siê, jak wybraæ praktyki najlepsze dla Twojej firmy i Twojego œrodowiska technicznego oraz jak przyrostowo wdra¿aæ metody zwinne. Nauczysz siê efektywnego tworzenia oprogramowania niezale¿nie od Twojej roli w projekcie — lidera, programisty, architekta lub klienta. • Wzorce wdra¿ania praktyk zwinnych • Praktyki sprzê¿enia zwrotnego • Praktyki techniczne i pomocnicze • Zautomatyzowane testy programisty • Programowanie w parach • Anga¿owanie spo³ecznoœci • Projekty ewolucyjne • Wdra¿anie praktyk zwinnych • Wymagania sterowane testami • Iteracja zwinna • Grupa praktyk komunikacyjnych Oto podrêcznik efektywnego wdra¿ania praktyk zwinnych, które bez trudu zaimplementujesz do swojego projektu! SPIS TREŚCI Słowo wstępne Lindy Rising Słowo wstępne J.B. Rainsbergera Przedmowa Podziękowania O autorze Część 1. Przemyślenia o wytwarzaniu oprogramowania Rozdział 1. Uczenie się jest wąskim gardłem Hipotetyczny eksperyment Spojrzenie na metodyki zwinne przez pryzmat koncepcji „uczenie się jest wąskim gardłem” Cykle rozpoznawania i reagowania na zmiany Cykl — warunek konieczny, ale nie wystarczający Dlaczego to jest takie ważne? Od teorii do praktyki Nie lekceważ tego wąskiego gardła Podsumowanie Rozdział 2. Osobista zwinność jako warunek skutecznego stosowania praktyk zwinnych Dlaczego należy wdrażać praktyki zwinne? Kiedy można mówić o udanym wdrożeniu? Problem — wiele nieudanych wdrożeń metodyk zwinnych Przyczyna — wszystko zależy od okoliczności Model Responsibility Process™ Chcę być bardziej odpowiedzialny. Jak tego dokonać? Moi współpracownicy utknęli. Co powinienem zrobić? Prawdziwa zwinność Skuteczne zespoły składają się z odpowiedzialnych członków Rozpoznawanie i reagowanie na zmiany wymaga odpowiedzialności Skuteczne wdrażanie zwinnych metodyk wytwarzania rozpoczyna się od jednostki Osobista zwinność Od teorii do praktyki 21 25 27 35 39 41 43 43 45 45 47 49 50 52 53 54 54 54 55 55 57 57 57 57 58 59 59 60 10 SPIS TREŚCI Część 2. Przygotowywanie strategii wdrażania praktyk zwinnych Rozdział 3. Walor biznesowy Ograniczanie czasu wprowadzania produktu na rynek Poprawa użyteczności produktu (wartości na rynku) Podniesienie jakości produktu trafiającego na rynek Podniesienie elastyczności Podniesienie widoczności Ograniczenie kosztów Wydłużanie czasu życia produktu Walory biznesowe są celami organizacyjnymi Od teorii do praktyki — określanie walorów biznesowych Twojej organizacji Rozdział 4. Problemy Problemy biznesowe Jakość produktu przekazanego klientowi jest nie do przyjęcia Dostarczanie klientowi nowych funkcji trwa zbyt długo Zaimplementowane funkcje nie są wykorzystywane przez klienta Oprogramowanie okazało się nieprzydatne dla klienta Budowa oprogramowania jest zbyt droga My kontra oni Klient żąda od nas wszystkiego, w tym zlewu kuchennego Problemy związane z procesami Klient? Jaki klient? — Wiara w bezpośrednie i regularne sugestie klienta jest nieuzasadniona Zarząd jest zaskoczony — brak widoczności Niewystarczające zasoby — praktycy oprogramowania należą do wielu jednocześnie pracujących zespołów Ruchome projekty Setki (lub tysiące) błędów zarejestrowanych przez narzędzie śledzące Potrzeba fazy „hartowania” na końcu cyklu wydawania Integracja ma miejsce zbyt rzadko (ponieważ jest kłopotliwa) Utrudnienia jako bodziec do działania Od teorii do praktyki — potrafisz znaleźć jakieś problemy? Rozdział 5. Wdrażanie praktyk zwinnych Praktyki Wzorce kojarzenia praktyk zwinnych z walorami biznesowymi Wzorce kojarzenia praktyk zwinnych z problemami Wypracowywanie własnej strategii wdrażania praktyk zwinnych Co dalej? Od teorii do praktyki — budowa własnej strategii wdrażania praktyk zwinnych Część 3. Katalog wzorców Rozdział 6. Wzorce wdrażania praktyk zwinnych Czym jest wzorzec? Efektywne stosowanie wzorców Uczestnicy scenariuszy 61 63 63 64 64 65 65 65 66 66 67 69 70 70 70 70 71 71 71 72 72 73 73 74 74 74 75 75 76 76 77 77 78 82 88 90 91 93 95 95 97 99 Rozdział 7. Cel Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 8. Cykl Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Część 3.1. Informacje zwrotne Rozdział 9. Iteracja Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 10. Spotkanie początkowe Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła SPIS TREŚCI 11 101 101 101 102 102 102 103 103 104 104 105 105 105 106 106 106 107 107 108 108 109 111 111 112 112 113 113 114 115 116 117 119 119 119 120 120 121 121 121 122 122 12 SPIS TREŚCI Rozdział 11. Lista zaległych zadań Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 12. Gra w planowanie Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Dodatkowe źródła Rozdział 13. Poranne spotkania Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 14. Stan wykonania Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 15. Demonstracja Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania 123 123 124 124 125 125 126 127 128 128 129 129 129 130 130 131 132 132 133 135 135 135 136 136 137 137 138 139 140 141 141 141 142 142 142 143 143 144 145 147 147 147 148 148 148 Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 16. Retrospektywa Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 17. Częste wydania Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 18. Praca w jednym miejscu Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 19. Samoorganizujący się zespół Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła SPIS TREŚCI 13 149 150 151 151 153 153 153 154 154 155 156 157 158 158 159 159 160 160 161 161 161 162 162 162 163 163 163 164 164 165 165 166 166 167 169 169 170 170 170 171 172 172 173 173 14 SPIS TREŚCI Rozdział 20. Zespół międzyfunkcjonalny Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 21. Klient jako część zespołu Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 22. Poruszające dokumenty Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 23. Historia użytkownika Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 24. Przypadek użycia Walor biznesowy Scenariusz Kontekst Przyczyny stosowania 175 175 176 177 177 178 178 179 180 180 181 181 181 182 182 183 183 185 186 186 189 189 189 190 190 191 191 192 192 193 195 195 195 196 196 196 197 198 198 199 201 201 201 202 202 Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 25. Radiator informacji Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Część 3.2. Praktyki techniczne Rozdział 26. Zautomatyzowane testy programisty Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 27. Wytwarzanie kończone testami Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Dodatkowe źródła Rozdział 28. Wytwarzanie poprzedzane testami Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła SPIS TREŚCI 15 202 203 203 204 204 205 205 205 206 206 206 206 207 208 209 211 213 213 214 215 215 216 217 220 222 223 225 225 225 226 226 227 227 227 228 229 229 229 230 231 231 232 233 234 234 16 SPIS TREŚCI Rozdział 29. Refaktoryzacja Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 30. Integracja ciągła Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 31. Prosty projekt Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 32. Testy funkcjonalne Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Testy podsystemu zarządzania towarami Zalety zautomatyzowanych testów funkcjonalnych Wdrażanie Ale Problemy implementacyjne Problemy architekturalne Odmiany Dodatkowe źródła 235 235 235 236 236 237 237 238 239 239 241 241 241 242 242 243 244 246 248 248 249 249 249 250 250 251 251 253 253 254 255 255 255 256 256 258 258 260 262 263 264 266 268 269 Rozdział 33. Wspólna własność kodu Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 34. Programowanie w parach Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Część 3.3. Praktyki pomocnicze Rozdział 35. Instruktor Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 36. Angażowanie społeczności Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła SPIS TREŚCI 17 271 271 271 272 272 273 273 274 274 274 275 275 275 276 276 277 277 278 279 279 281 283 283 283 284 284 284 285 285 286 286 287 287 287 288 288 288 289 290 291 291 18 SPIS TREŚCI Rozdział 37. Koła czytelnicze Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 38. Warsztaty Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 39. Szkolenia Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Część 3.4. Grupy praktyk Rozdział 40. Iteracja zwinna Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 41. Grupa praktyk komunikacyjnych Walor biznesowy Scenariusz Kontekst 293 293 293 294 294 295 295 296 297 297 299 299 299 300 300 300 301 301 302 302 303 303 303 304 304 304 305 306 307 309 311 312 312 312 313 313 314 315 315 316 317 317 317 318 Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 42. Projekt ewolucyjny Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 43. Wytwarzanie sterowane testami Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Rozdział 44. Wymagania sterowane testami Walor biznesowy Scenariusz Kontekst Przyczyny stosowania Skutki stosowania Wdrażanie Ale Odmiany Dodatkowe źródła Część 4. Studia przypadków Rozdział 45. Witryna internetowa BabyCenter Wdrażanie praktyk zwinnych przez zespół BabyCenter — pierwszy kwartał 2007 roku Wypracowywanie strategii wdrażania praktyk zwinnych Wnioski Ocena wdrażania praktyk zwinnych przez zespół BabyCenter — pierwszy kwartał 2008 roku SPIS TREŚCI 19 319 319 320 321 321 322 323 323 324 325 325 326 327 328 329 329 331 331 332 332 333 334 334 336 337 337 339 339 340 340 341 342 342 343 344 345 347 349 350 350 355 355 20 SPIS TREŚCI Rozdział 46. Firma X Wdrażanie praktyk zwinnych przez firmę X — pierwsze dwa kwartały 2007 roku Kontekst tego raportu Bieżące cele biznesowe Widok z perspektywy okopów Sugerowane praktyki na resztę 2007 roku Dłuższa perspektywa Wnioski Wdrażanie praktyk zwinnych przez firmę X — ocena końcowa Aktualna sytuacja Część 5. Dodatki Dodatek A. Związki między walorami biznesowymi i praktykami zwinnymi Dodatek B. Związki praktyk zwinnych i problemów Dodatek C. Czerpanie maksymalnych korzyści ze wzorców wdrażania praktyk zwinnych Dodatek D. Materiały dodatkowe Bibliografia 359 359 360 360 361 366 371 371 371 371 375 377 379 381 385 387 ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 77 Rozdział 5 WDRAŻANIE PRAKTYK ZWINNYCH Do tej pory koncentrowaliśmy się na walorach i problemach biznesowych. Na końcu obu dotychczasowych rozdziałów tej części wykonałeś ćwiczenia, w ramach których opracowałeś listę walorów biznesowych (z przypisanymi priorytetami) oraz listę problemów wymagających rozwiązania (także z priorytetami). Jeśli nie sporządziłeś tych list, wróć do odpowiednich podrozdziałów i wykonaj te ćwiczenia teraz. Bogatszy o znajomość priorytetów swoich klientów i najważniejszych utrudnień napotykanych przez Twoją firmę, będziesz gotowy do identyfikacji praktyk, których wdrożenie powinieneś rozważyć właśnie z myślą o eliminacji tych przeszkód i uzyskiwaniu możliwie wysokiej wartości w wyniku swoich działań. W tym rozdziale spróbuję wskazać Ci kierunek, jak właściwie wybierać praktyki pod kątem ewentualnego wdrażania we własnej organizacji. Postaram się też zasu- gerować Ci sposoby oceny Twojej dotychczasowej pracy, która — mimo że z natury rzeczy będzie subiektywna — pozwoli Ci osiągnąć należytą „zwinność” w podejściu do problemu wdrażania. Chciałbym, żebyś traktował ten materiał jako zbiór wskazówek, jak wyznaczać własne priorytety i jak sporządzać własną listę praktyk do wdrożenia. Jeśli szukasz gotowych recept — wymienionych praktyk A, B i C — z pewnością nie znajdziesz ich w tej książce. (A jeśli znajdziesz je gdzie indziej, zachowaj ostrożność, ponieważ tak reklamowanym materiałom z reguły nie można ufać). PRAKTYKI Istotą tej książki jest prezentacja wzorców wdrażania zwinnych praktyk wytwarzania oprogramowania, czyli praktyk zwinnych sporządzonych w formie wzorców kon- centrujących się na problemie wdrażania. W tym rozdziale spróbujemy wspólnie wybrać praktyki najlepiej pasujące do kontekstu Twojej organizacji. Identyfikacja właściwych praktyk w dużej mierze zależy od pracy wykonanej w poprzednich rozdziałach, kiedy zachęcałem Cię do przypisania swoich walorom biznesowym i problemom priorytetów — na tej podstawie wybierzemy praktyki, których wdro- żenie powinno podnieść walory biznesowe i ograniczyć obserwowane problemy. 78 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH WZORCE KOJARZENIA PRAKTYK ZWINNYCH Z WALORAMI BIZNESOWYMI Zacznijmy od istoty tego rozdziału. Na rysunkach od 5.1 do 5.7 przedstawiono diagramy ilu- strujące związki poszczególnych walorów biznesowych z praktykami, które powinny te walory rozszerzać. Prezentowane związki (odwzorowania), jak wszystkie wzorce opisywane w tej książce, powstały przez połączenie doświadczeń zgromadzonych podczas wielu prób wdrażania praktyk zwinnych. Każda z tych praktyk odpowiada wzorcowi, który zostanie szczegółowo udokumen- towany w dalszej części tej książki. Nie powinieneś się więc przejmować, jeśli na tym etapie część spośród nich jest dla Ciebie niezrozumiała. Przeanalizujmy teraz diagram z rysunku 5.1, abyś lepiej zrozumiał, jak czytać podobne ilustracje walorów biznesowych. Strzałki pomiędzy praktykami reprezentują zależności — oznacza to, że na przykład refaktoryzacja zależy od zautomatyzowanych testów programisty. Istotne znaczenie ma także układ pionowy — im wyżej znajduje się dana praktyka, tym większy jest jej wpływ na odpowiedni walor biznesowy. Oznacza to, że na przykład iteracje mają większy wpływ na walor krótkiego czasu dostarczania produktu na rynek (pozwala ten czas bardziej skrócić) niż zauto- matyzowane testy programisty, a praktyka wytwarzania poprzedzonego testami jest bardziej efektywna od praktyki wytwarzania kończonego testami. Możesz więc wykorzystywać te dia- gramy do określania, które praktyki zasługują na szczególną uwagę jako potencjalne rozwiązania do wdrożenia. Nie należy jednak traktować tych diagramów jako czegoś więcej niż sugestie. Mimo że wszystkie proponowane praktyki mają pozytywny wpływ na odpowiednie walory bizne- sowe, bliższa analiza szczegółowych rozwiązań może wykazać, że niektóre z nich nie znajdują zastosowania w przypadku Twojej organizacji. Rysunek 5.1. Praktyki skracające czas dostarczania produktu na rynek ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 79 Wykonywanie niewielkich kroków i — tym samym — błyskawiczne odkrywanie niepowodzeń jest najbardziej efektywną metodą oceny skuteczności poszczególnych praktyk. Warto eliminować usterki możliwie wcześnie, ponieważ im wcześniej je odkrywamy, tym mniej nas kosztują i tym mniejsze jest ryzyko rozpoczęcia budowy na niepewnych fundamentach. Właśnie dlatego takie praktyki, jak iteracja czy integracja ciągła (ang. continuous integration), mają tak dobry wpływ na czas wprowadzania produktu na rynek. Obie te praktyki zależą jednak od innych praktyk. Wyobraźmy sobie, że chcemy skrócić czas przekazywania produktu na rynek, wdrażając praktykę zautomatyzowanych testów i trio iteracyjnego, czyli iteracji, stanu wykonania (ang. done state) oraz listy zaległych zadań iteracji (ang. iteration backlog). Na rysunku 5.2 pokazano praktyki zwiększające użyteczność produktu. Jak dotąd najbardziej efektywną spośród znanych praktyk w tym obszarze jest metoda włączania klientów do zespołu (ang. customers part of team). Warto więc sprawdzić jej skuteczność w pierwszej kolejności. Jeśli już teraz stosujesz zautomatyzowane testy programistów lub metodę kończenia iteracji prezenta- cjami wersji demonstracyjnych, powinieneś rozważyć wdrożenie praktyki testów funkcjonalnych. Rysunek 5.2. Praktyki podnoszące użyteczność produktu Mimo że w obszarze jakości produktów niepodzielnie rządzą praktyki wytwarzania sterowanego testami i wymagań sterowanych testami, obie te metody zależą od innych praktyk (patrz ry- sunek 5.3). Powinieneś więc rozważyć przyjęcie za punkt wyjścia jednej z praktyk zaliczanych do grupy zautomatyzowanych testów programisty (najlepiej wytwarzanie poprzedzone testami) 80 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Rysunek 5.3. Praktyki podnoszące jakość produktu oraz praktyki programowania w parach. Bezpośrednio po nich warto wprowadzić technikę re- faktoryzacji. Programowanie w parach powinno Ci pomóc w szybkim i bezbolesnym wdrażaniu tych wyjątkowo trudnych praktyk. Kiedy już nabierzesz wprawy w korzystaniu ze zautomaty- zowanych testów programisty, skoncentruj swoją uwagę na pełnowartościowym wytwarzaniu sterowanym testami i rozważ implementację testów funkcjonalnych. Istnieją dwa ogólne rodzaje elastyczności, o których można mówić w kontekście wytwarzania oprogramowania — elastyczność zespołu oraz elastyczność techniczna (patrz rysunek 5.4). Elastyczność zespołu decyduje o jego zdolności do rozpoznawania i reagowania na zachodzące zmiany. Warunkiem właściwego reagowania na zmiany, przez dobór odpowiedniego oprogra- mowania, jest elastyczność techniczna. Oznacza to, że musimy zadbać zarówno o elastyczność zespołu, jak i o elastyczność techniczną. W pierwszej kolejności powinieneś wdrożyć praktyki zautomatyzowanych testów programisty, samoorganizującego się zespołu oraz trio iteracyjnego, czyli iteracji, stanu wykonania i listy zaległych zadań. O ile testowanie zapewni Ci osiągnięcie właściwej elastyczności technicznej, pozostałe wymienione praktyki podniosą elastyczność Twojego zespołu. ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 81 Rysunek 5.4. Praktyki zwiększające elastyczność Lista zaległych zadań i radiatory informacji to pierwsze, jednocześnie stosunkowo łatwe działania na rzecz poprawy widoczności (patrz rysunek 5.5). W zależności od potrzeb w zakresie zwiększania widoczności możesz obrać albo stosunkowo prostą drogę z praktykami iteracji, stanu wykonania i wersji demonstracyjnych, albo trudniejszy, ale też bardziej efektywny model z testami funkcjo- nalnymi i wymaganiami sterowanymi testami. Rysunek 5.5. Praktyki poprawiające widoczność 82 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Koszty można ograniczać na dwa sposoby — możesz albo zadbać o uproszczenie konserwacji kodu, albo po prostu pisać mniej kodu (ograniczając się do implementowania najważniejszych funkcji). Wdrażanie kolejno praktyk zautomatyzowanych testów, refaktoryzacji, uproszczonych projektów i projektowania ewolucyjnego jest właściwym sposobem ograniczania kosztów utrzy- mania (konserwacji). Praktyki listy zaległych zadań, iteracji i stanu wykonania skutecznie zmniejszają ilość pisanego kodu (patrz rysunek 5.6). Rysunek 5.6. Praktyki redukujące koszty Czas życia produktu jest odwrotnie proporcjonalny do kosztów jego konserwacji oprogramowania. Istnieją dwa sprawdzone sposoby ograniczania kosztów utrzymania: (1) sporządzenie siatki bez- pieczeństwa złożonej z testów i efektywne wprowadzanie zmian w systemie z jednoczesnym ograniczaniem ich kosztów oraz (2) szerzenie wśród członków zespołu wiedzy o projekcie danego systemu. Kluczem do skutecznej realizacji pierwszego z tych zadań jest wdrożenie praktyki zauto- matyzowanych testów programisty; drugie zadanie można zrealizować przez programowanie w parach i wspólną własność kodu. WZORCE KOJARZENIA PRAKTYK ZWINNYCH Z PROBLEMAMI Jak już wspomniano, istnieją dwa główne typy problemów: biznesowe oraz związane z procesem. Problemy biznesowe są w istocie przeciwieństwem walorów biznesowych, stąd identyczne wzorce kojarzenia odpowiednich praktyk zwinnych: ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 83 Rysunek 5.7. Praktyki wydłużające czas życia produktu (cid:132) jakość produktu przekazanego klientowi jest nie do przyjęcia — jakość produktu trafiającego na rynek; (cid:132) dostarczanie klientowi nowych funkcji trwa zbyt długo — czas wprowadzania produktu na rynek; (cid:132) zaimplementowane funkcje nie są wykorzystywane przez klienta — użyteczność produktu; (cid:132) oprogramowanie okazało się nieprzydatne dla klienta — użyteczność produktu; (cid:132) budowa oprogramowania jest zbyt droga — ograniczenie kosztów. Dla pozostałych problemów istnieją odrębne odwzorowania we wzorce wdrażania praktyk zwin- nych (pokazane na rysunkach od 5.8 do 5.15). Najlepszym rozwiązaniem łagodzenia skutków występowania problemu określanego jako my kontra oni jest prowadzenie możliwie częstych konwersacji na temat rzeczywistej natury realizo- wanego projektu (patrz rysunek 5.8). Warto zacząć od poprawy widoczności przez tworzenie radiatorów informacji prezentujących najważniejsze aspekty wytwarzania. Powinieneś też (we współpracy z całym zespołem i klientami) sporządzić listę zaległych zadań i przypisać im odpo- wiednie priorytety. Spróbuj wykorzystać te praktyki do poprawy widoczności i budowy zaufania. Kiedy będziesz gotowy, rozważ wykonanie dalszych kroków na rzecz poprawy zaufania — dbaj o częste dostarczanie produktów przez wdrożenie praktyk iteracji, wersji demonstracyjnych i stanu wykonania. Musisz zrozumieć, że kiedy klient żąda od Ciebie niemal wszystkiego, nie chodzi o jego rzeczywi- ste oczekiwania, tylko o brak wiary w możliwość punktualnego dostarczenia właściwych funkcji i obawę przed kosztownymi procesami renegocjacji raz podpisanych umów (co jest typowe dla 84 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Rysunek 5.8. Praktyki rozwiązujące problem „my kontra oni” tradycyjnych projektów informatycznych). Najlepszym sposobem rozwiązania tego problemu jest włączenie klientów do prac zespołu projektowego (patrz rysunek 5.9). Spróbuj zaangażować ich w proces sporządzania listy zaległych zadań i przypisywania tym zadaniom priorytetów. Rysunek 5.9. Praktyki rozwiązujące problem żądania wszystkiego przez klienta Jeśli bezpośrednie uzyskiwanie od klienta jego opinii i sugestii jest niemożliwe, możesz ograniczyć negatywne skutki tego stanu rzeczy, zmniejszając liczbę błędów komunikacyjnych (patrz rysunek 5.10). Można to zrobić przez przygotowanie testów funkcjonalnych i stopniowe dochodzenie ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 85 Rysunek 5.10. Praktyki rozwiązujące problem niemożności bezpośredniego i regularnego uzyskiwania informacji od klienta do praktyki wymagań sterowanych testami, gdzie sporządzony przez klienta dokument opisujący wymagania jednocześnie pełni funkcję wykonywalnej specyfikacji. Prawidłowe wdrażanie tej konkretnej praktyki jest wyjątkowo czasochłonne, zatem warto przystąpić do tego procesu moż- liwie wcześnie i wykazywać należytą cierpliwość. W międzyczasie warto sporządzić listę zaległych zadań i podejmować próby pracy przyrostowej z iteracjami kończonymi tworzeniem wersji demonstracyjnych. Aby uniknąć niepotrzebnego zaskakiwania kierownictwa organizacji, powinieneś zrobić dwie rzeczy: (1) starać się budować swoje aplikacje w sposób przyrostowy oraz (2) informować swoich przełożonych o rzeczywistych postępach prac. Pierwszy cel można osiągnąć dzięki definiowaniu stanu wykonania możliwie bliskiego stanowi produktu gotowego do wdrożenia, po czym przystą- pieniu do realizacji iteracji. Do komunikowania prawdziwych postępów prac można wykorzysty- wać radiatory informacji oraz wersje demonstracyjne prezentowane na końcu każdej iteracji. Zjawisko brakujących zasobów ludzkich (stanowiących wąskie gardło) wynika z dążenia do spe- cjalizacji. Programowanie w parach jest zdecydowanie najbardziej efektywną metodą dzielenia się wiedzy i — tym samym — zdobywania cennych specjalizacji przez pozostałych członków zespołu (patrz rysunek 5.12). Z czasem stosowanie tej praktyki doprowadzi do sytuacji, w której wielu członków zespołu będzie potrafiło rozwiązywać problemy, które wcześniej były domeną zaledwie jednego eksperta. Innym krokiem w dobrym kierunku jest wdrożenie praktyki zauto- matyzowanych testów programistów, które umożliwiają członkom zespołu pracę na nieznanym sobie kodzie bez ryzyka uszkodzenia wcześniej zaimplementowanych i sprawdzonych rozwiązań (dzięki istnieniu zabezpieczającej sieci testów). Oznacza to, że istnienie tych testów i możliwość bezpiecznej pracy na cudzym kodzie może skutecznie niwelować skutki niedoboru specjalistów. 86 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Rysunek 5.11. Praktyki rozwiązujące problem zaskoczenia zarządu (braku widoczności) Rysunek 5.12. Brakujące zasoby — specjaliści od budowy oprogramowania są członkami wielu zespołów jednocześnie stosujących różne praktyki Projekty sprawiają wrażenie ruchomych, niestałych w wyniku braku jasno zdefiniowanych prio- rytetów. Priorytety należy przypisywać wymaganiom, sporządzając i stale utrzymując listę zadań do wykonania. Aby mieć pewność, że taka lista precyzyjnie odpowiada potrzebom klienta, warto włączyć przedstawiciela tego klienta do prac zespołu i utworzyć zespół międzyfunkcjonalny zdolny do kompleksowej realizacji tych wymagań. W ten sposób umożliwisz zarówno sobie, jak i swoim klientom lepsze zrozumienie wymagań, ich priorytetów i pętli zwrotnej decydującej o możliwie szybkim wprowadzaniu korekt. ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 87 Rysunek 5.13. Praktyki rozwiązujące problem ruchomych projektów Musisz sobie poradzić z setkami błędów. W pierwszej kolejności powinieneś wdrożyć praktykę zautomatyzowanych testów programisty, wspartą praktyką programowania w parach, aby ograni- czyć liczbę nowych błędów wprowadzanych do systemu i przystąpić do stopniowej budowy sieci bezpieczeństwa (złożonej z testów). Warto następnie wdrożyć iteracje ze stanem wykonania, aby odnaleźć jak najwięcej błędów. Nigdy nie odkładaj na później tak kłopotliwych zadań jak integracja — staraj się rozwiązywać problemy możliwie szybko. Rysunek 5.14. Praktyki rozwiązujące problem setek (lub tysięcy) usterek zarejestrowanych w systemie śledzenia błędów 88 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Konieczność stosowania fazy „hartowania”, „utwardzania” jest symptomem kumulacji kilku ważnych defektów. Wstrzymaj wszystkie bieżące prace i skoncentruj swoje wysiłki na dodaniu niezbędnych testów, aby zyskać możliwość wytwarzania kodu z wykorzystaniem zautomatyzowa- nych testów programisty. W ramach każdej iteracji sformułuj dobry stan wykonania (możliwie bliski stanu gotowego do wdrożenia), aby możliwie wcześnie eliminować trudne do odnajdowa- nia błędy. Rysunek 5.15. Praktyki rozwiązujące problem konieczności stosowania fazy „utwardzania” na końcu każdego cyklu wydawania WYPRACOWYWANIE WŁASNEJ STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Zgromadzone do tej pory informacje o wartościach i problemach biznesowych możesz wykorzy- stać do identyfikacji praktyk, które powinieneś wdrożyć we własnej organizacji. (cid:132) Wybierz właściwe praktyki, kierując się wyłącznie walorami biznesowymi swoich produktów. W tym scenariuszu przyjmujemy, że Twoja organizacja nie napotyka żadnych poważnych utrudnień. Chcesz po prostu udoskonalić swój obecny proces wytwarzania oprogramowania przez zwiększenie walorów biznesowych produktów dostarczanych przez Twój zespół. Wykorzystaj odwzorowania pokazane na rysunkach od 5.1 do 5.7, aby wybrać praktyki, które będą miały największy wpływ na walory biznesowe Twojej organizacji. ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 89 (cid:132) Wybierz praktyki z myślą o ograniczeniu negatywnych skutków problemów, których waga zależy od priorytetów odpowiednich walorów biznesowych. Ten model ma na celu eliminację przeszkód z jednoczesnym dążeniem do maksymalizacji walorów biznesowych. Priorytety przypisywane tym problemom powinny zależeć od walorów biznesowych szczególnie ważnych dla Twoich klientów. Oznacza to, że w pierwszej kolejności powinieneś sporządzić listę problemów (z priorytetami), po czym wybrać odpowiednie praktyki do wdrożenia — możesz posłużyć się odwzorowaniami pokazanymi na rysunkach od 5.8 do 5.15. (cid:132) Wybierz praktyki eliminujące najbardziej widoczne problemy. Taka postawa jest dość popularna, choć sam jestem daleki od jej propagowania. Opisany model można by porównać do gaszenia pożarów — zamiast koncentrować się na walorach biznesowych, próbujemy bezrefleksyjnie eliminować największe przeszkody. To nieskuteczne podejście jest udziałem zbyt wielu zespołów technicznych, które decydują się na przypisywanie priorytetów swoim zadaniom bez uwzględniania opinii i sugestii klienta. (Sam popełniałem w przeszłości podobne błędy). Informacje (praktyki) zawarte na rysunkach w poprzednich podrozdziałach uporządkowano we- dług efektywności. Oznacza to, że pierwsza praktyka na każdym rysunku jest najbardziej efektyw- nym sposobem podnoszenia określonego waloru biznesowego lub ograniczania skutków występo- wania danego problemu. Warto więc zacząć właśnie od pierwszej praktyki, a po jej skutecznym wdrożeniu wrócić do pozostałych praktyk związanych z interesującym nas walorem lub proble- mem biznesowym. Niezależnie od tego, jak dobierzesz priorytety w ramach swojej listy praktyk do wdrożenia, po- winieneś przeprowadzać sam proces ich wdrażania w sposób iteracyjny. Wyposażony w listę wybranych wcześniej praktyk zwinnych możesz przystąpić do wdrażania ich według następującej procedury. 1. Zacznij od oceny stanu obecnego. Zapoznaj się z istniejącymi materiałami (nawet jeśli mają subiektywny charakter) poświęconymi bieżącym walorom biznesowym, które chcesz rozszerzyć, oraz problemom, których skutki chcesz ograniczyć. 2. Wyznacz cele, które chcesz osiągnąć. O ile chcesz podnieść wybrany walor biznesowy? Na ile chcesz zredukować skutki wybranego problemu? Jakie ramy czasowe przyjąłeś? Spróbuj sformułować początkowe odpowiedzi na te pytania, by następnie modyfikować je wraz z zyskiwaniem konkretnych doświadczeń. 3. Wybierz pierwszą praktykę (lub grupę praktyk) ze sporządzonej wcześniej listy. 4. Zapoznaj się ze wzorcem wdrażania danej praktyki lub grupy praktyk. Spróbuj określić, czy interesujący Cię wzorzec znajduje zastosowanie w Twoim środowisku roboczym (więcej informacji na temat tych wzorców znajdziesz w części 3, zatytułowanej „Katalog wzorców”). Jeśli dana praktyka z jakiegoś powodu nie może być zastosowana w Twoim środowisku, wróć do swojej listy i wybierz następny element podnoszący jakiś walor biznesowy lub ograniczający skutki jakiegoś problemu. 90 CZĘŚĆ 2 (cid:132) PRZYGOTOWYWANIE STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH 5. Kiedy ostatecznie rozstrzygniesz, że dany wzorzec można zastosować w Twoim środowisku, zapoznaj się z jego szczegółowym opisem. Początkowo powinieneś postępować według wskazówek zawartych w podrozdziale „Wdrażanie” odpowiedniego rozdziału. 6. W stałych odstępach czasu staraj się oceniać interesujący Cię walor biznesowy pod kątem ewentualnej poprawy lub problem pod kątem redukcji jego negatywnych skutków. Jeśli nie zanotowałeś poprawy od ostatniej oceny (sprzed wdrożenia danej praktyki w Twoim środowisku), zastosuj wskazówki zawarte w podrozdziałach „Odmiany” i „Ale” rozdziału poświęconego tej praktyce. (Być może powinieneś wcześniej przeczytać rozdział 6., zatytułowany „Wzorce wdrażania praktyk zwinnych”, aby lepiej zrozumieć przebieg procedury wdrażania zwinnych praktyk wytwarzania oprogramowania). 7. Wróć do kroku 1. i ponownie oceń swój walor lub problem biznesowy. Jeśli dany obszar wymaga dodatkowych udoskonaleń (jeżeli nadal nie osiągnięto celu wyznaczonego w kroku 2.), powinieneś rozważyć dodanie innej praktyki lub całej grupy praktyk, aby zbliżyć się do tego celu. Jeśli udało Ci się osiągnąć sformułowane cele, przejdź do następnego elementu listy. Gdzie w opisanej procedurze jest miejsce na działania sterowane testami? Twoje testy powinny się składać na cel sformułowany w kroku 2. W kroku 6. powinieneś ocenić swój proces już po wdrożeniu nowej praktyki. Istotą kroku 6. jest przetestowanie efektywności wdrożonej praktyki lub praktyk w zakresie osiągnięcia wyznaczonego celu. Opisana pętla (wyznaczenie celu, wdroże- nie praktyki i weryfikacja tej praktyki pod kątem skuteczności w dochodzeniu do oczekiwanego celu) jest typową strategią wdrażania sterowanego testami1. CO DALEJ? Po lekturze tego rozdziału jesteś gotowy do opracowania własnej strategii wdrażania zwinnych praktyk wytwarzania oprogramowania z uwzględnieniem konkretnych walorów biznesowych i problemów Twojej organizacji. Tworzenie tej strategii nie jest czynnością jednorazową — powi- nieneś wykazywać zwinność także w trakcie wdrażania nowych praktyk. Oceniaj obserwowane postępy pod kątem spełnienia wyznaczonych celów i stale modyfikuj stosowane procedury. Wraz z zyskiwaniem nowej wiedzy o poszczególnych praktykach i własnym środowisku modyfikuj swoją strategię. Popełnianie błędów jest czymś zupełnie naturalnym — kluczem do sukcesu jest odkrywanie niepowodzeń możliwie szybko i korygowanie błędnych założeń. 1 W świecie praktyk zarządzania opisany model bywa określany mianem cyklu PDCA (od ang. Plan, Do, Check, Act — planuj, wykonaj, sprawdź, działaj). Oryginalna koncepcja PDCA z lat trzydziestych ubiegłego wieku jest co prawda dziełem Waltera Shewharta z Bell Laboratories, jednak prawdziwą popularność zyskała dopiero w latach pięćdziesiątych dzięki pozytywnej opinii guru zarządzania jakością, W. Edwarda Deminga. ROZDZIAŁ 5 (cid:132) WDRAŻANIE PRAKTYK ZWINNYCH 91 W dalszej części tej książki szczegółowo omówimy każdą ze wspomnianych w tym rozdziale praktyk. Dla każdej z nich istnieje specjalny wzorzec, który nie tylko opisuje tę praktykę, ale też rozwiązywane przez nią problemy, udokumentowane scenariusze jej skutecznego zastosowa- nia w przeszłości (z uwzględnieniem specyficznych cech środowisk i popełnionych błędów, abyśmy wiedzieli, na co powinniśmy zwracać szczególną uwagę). OD TEORII DO PRAKTYKI — BUDOWA WŁASNEJ STRATEGII WDRAŻANIA PRAKTYK ZWINNYCH Spróbuj odpowiedzieć na następujące pytania związane z przygotowywaniem strategii wdrażania. (Wykorzystaj odpowiedzi na pytania postawione w rozdziałach 3. i 4.). Rzeczywiste przykłady tworzenia tego rodzaju strategii można znaleźć w rozdziałach 45. i 46. 1. Jakie cele chcesz osiągnąć przez wdrażanie praktyk zwinnych? Czy chcesz ograniczyć negatywne skutki występowania jakiś problemów, czy raczej podnieść walory biznesowe swojego produktu? Odpowiedz konkretnie — jeśli stawiasz sobie więcej niż jeden cel, przypisz im priorytety. 2. Zapoznaj się z dostępnymi materiałami na temat bieżących walorów biznesowych i problemów wymagających rozwiązania. Nie przejmuj się, jeśli istniejące raporty sprawiają wrażenie subiektywnych lub nieścisłych. Spróbuj uzyskać możliwie pełną wiedzę o obecnym stanie Twojej organizacji, zarówno w wymiarze walorów biznesowych, jak i problemów. 3. Wybierz strategię wdrażania nowych praktyk. Wykorzystaj tę strategię do identyfikacji właściwych praktyk. 4. Zapoznaj się z treścią następnego rozdziału, w którym wprowadzono zagadnienia związane ze wzorcami. Po jego lekturze możesz przystąpić do przeprowadzania opisanej powyżej procedury wdrażania pierwszej z wybranych praktyk. Nie zapominaj o konieczności okresowej weryfikacji walorów i problemów biznesowych, aby mieć pewność, że stosowana praktyka przynosi zamierzony efekt. 5. Gratulacje i powodzenia! Właśnie wstąpiłeś na ścieżkę wdrażania zwinnych praktyk programowania!
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Agile. Wzorce wdrażania praktyk zwinnych
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ą: