Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00514 009826 10436457 na godz. na dobę w sumie
Scrum. Praktyczny przewodnik dla początkujących - książka
Scrum. Praktyczny przewodnik dla początkujących - książka
Autor: Liczba stron: 424
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-8250-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).

Twój przewodnik po Scrumie!

Tempo prac nad współczesnymi projektami wymusiło wypracowanie nowych metodyk pozwalających w zwinny sposób zarządzać projektami. Jedna z nich — Scrum — zdobyła szczególną popularność. Jasne zasady, dobrze dobrane role w projekcie oraz przemyślany sposób jego prowadzenia zdecydowały o tym sukcesie. Jeżeli chcesz w swoim projekcie wprowadzić ten sposób zarządzania, trafiłeś na doskonałą książkę.

Dzięki niej zrealizujesz swoje plany szybko i bez zbędnych kłopotów. W trakcie lektury dowiesz się, czym charakteryzuje się ta metodyka oraz jak ją wprowadzić w Twojej organizacji. Dzięki kolejnym rozdziałom nauczysz się określać prędkość zespołu, przydzielać role oraz ustalać długość sprintu. Dalsze strony zawierają cenne informacje praktyczne na temat godzin pracy, planowania wydań oraz prowadzenia retrospektyw. Ostatnia część książki została poświęcona zaawansowanym technikom. Dowiesz się, jak dokumentować w projekcie scrumowym, kosztorysować oraz formułować umowy. Książka ta jest wciągającym kompendium wiedzy, niezbędnym dla każdego korzystającego ze zwinnych technik zarządzania projektem opartych na metodyce Scrum.

Dzięki tej książce:

Poznaj potencjał metodyki Scrum!

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

Darmowy fragment publikacji:

Tytuł oryginału: The Scrum Field Guide: Practical Advice for Your First Year Tłumaczenie: Arkadiusz Romanek ISBN: 978-83-246-8250-8 Authorized translation from the English language edition, entitled: THE SCRUM FIELD GUIDE: PRACTICAL ADVICE FOR YOUR FIRST YEAR; ISBN 0321554159; by Mitch Lacey; published by Pearson Education, Inc, publishing as Addison Wesley. Copyright © 2012 by Mitchell G. Lacey. All rights reserved. No part of this book may by reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A. Copyright © 2014. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/scrump Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność SPIS TRE(cid:165)CI Przedmowa Jima Highsmitha Przedmowa Jeffa Sutherlanda Wst(cid:218)p Podzi(cid:218)kowania O autorze Rozdzia(cid:239) 1. Scrum: proste, ale nie (cid:239)atwe Historyjka Scrum Czym jest Scrum? Zastosowanie Scruma Kiedy Scrum jest dla mnie dobry? Zmiana jest trudna Klucze do sukcesu Bibliografia Cz(cid:218)(cid:258)(cid:202) I Przygotowania Rozdzia(cid:239) 2. Budowanie zaanga(cid:285)owania Historyjka Model Zmiana wymaga czasu Uświadomienie pilności zadania Stworzenie wpływowej koalicji liderów Stworzenie wizji/namalowanie obrazu przyszłości Przedstawienie wizji przyszłości Upoważnienie innych do działania w imię wizji przyszłości Planowanie i tworzenie warunków dla osiągnięcia krótkoterminowych korzyści Konsolidacja usprawnień Zinstytucjonalizowanie nowego podejścia 15 17 21 25 27 29 29 35 35 36 43 44 47 48 51 53 53 60 60 61 61 62 62 63 63 64 64 5 Kup książkęPoleć książkę 6 Spis tre(cid:258)ci Klucze do sukcesu Bądź cierpliwy Zapewnienie materiałów informacyjnych Bibliografia Rozdzia(cid:239) 3. Wykorzystanie konsultantów do optymalizacji wydajno(cid:258)ci zespo(cid:239)ów Historyjka Model Ustanowienie puli konsultantów zespołów Budowanie zespołu Klucze do sukcesu Odpowiedzialność Eksperymentuj Bądź ostrożny, unikaj przeciążenia Uwzględnij potencjalne przestoje Konsultanci zespołów nie są zamiennikami zespołów dedykowanych Bibliografia Inne źródła Rozdzia(cid:239) 4. Okre(cid:258)lenie pr(cid:218)dko(cid:258)ci zespo(cid:239)u Historyjka Model Problem z danymi historycznymi Światełko w tunelu szacowania w ciemno Poczekać i zobaczyć (korzystanie z rzeczywistych danych) Zakłócenie procesu zbierania danych Klucze do sukcesu Bibliografia Rozdzia(cid:239) 5. Przydzielanie ról w Scrumie Historyjka Model Wybór ról Mieszanie ról Gdy (a nie jeśli) decydujesz się na połączenie ról Klucze do sukcesu Rozdzia(cid:239) 6. Okre(cid:258)lenie d(cid:239)ugo(cid:258)ci sprintu Historyjka Model Czas trwania projektu Klient/grupa interesariuszy Zespół scrumowy Ustalenie długości Twojego sprintu Uważaj się za ostrzeżonego Życie po quizie 64 65 65 65 67 67 72 73 75 80 81 81 82 82 82 83 83 85 86 91 91 92 96 98 100 102 103 103 107 108 110 112 113 115 115 118 119 120 121 122 124 125 Kup książkęPoleć książkę Spis tre(cid:258)ci 7 Bibliografia Historyjka Model Klucze do sukcesu Sprinty dłuższe niż cztery tygodnie Wydłużenie sprintu Rozdzia(cid:239) 7. Sk(cid:200)d mamy wiedzie(cid:202), (cid:285)e to ju(cid:285) koniec? Wprowadzenie Burza mózgów Sesja kategoryzacyjna Sesja sortowania i konsolidacji Tworzenie definicji ukończenia A co z pracą nieukończoną? 126 126 127 127 129 129 131 132 132 134 135 136 137 137 138 Rozdzia(cid:239) 8. Argument za posiadaniem Mistrza M(cid:239)yna na pe(cid:239)nym etacie 139 139 142 148 149 149 150 150 151 152 152 152 Usuwanie przeszkód/rozwiązywanie problemów Zażegnywanie nieporozumień/kłótni i funkcjonowanie w roli matki zespołu Raportowanie wyników zespołu Działania na rzecz ułatwiania pracy i niesienie pomocy potrzebującym Edukowanie organizacji i zachęcanie do zmian organizacyjnych W skrócie Klucze do sukcesu Bibliografia Historyjka Model Klucze do sukcesu Bibliografia Inne źródła Cz(cid:218)(cid:258)(cid:202) II Podstawy i praktyka Rozdzia(cid:239) 9. Dlaczego dobre praktyki in(cid:285)ynieryjne s(cid:200) tak wa(cid:285)ne w Scrumie Historyjka Dobre praktyki inżynieryjne oprogramowania Wdrażanie TDD Refaktoryzacja Ciągła integracja — aby zawsze znać status systemu Programowanie w parach Automatyczne testy integracyjne i akceptacyjne Klucze do sukcesu Nie ma złotego środka Jak zacząć? Przekonaj zespół Definicja ukończenia 153 155 155 159 160 161 163 164 166 167 168 168 169 169 Kup książkęPoleć książkę 8 Spis tre(cid:258)ci Uwzględnienie dobrych praktyk inżynierii oprogramowania w Rejestrze Produktu Szkolenia/coaching Połącz wszystko w całość Bibliografia Inne źródła Rozdzia(cid:239) 10. Godziny pracy Historyjka Model Zespoły i ich miejsce pracy Zespoły rozproszone i współpracownicy w niepełnym wymiarze czasu pracy Klucze do sukcesu Rozdzia(cid:239) 11. Planowanie wyda(cid:241) Historyjka Model Wstępny szkic mapy drogowej Stopień przekonania do wyników Dołączenie dat i dostosowanie według potrzeb Utrzymanie planu wydania na długości całego cyklu życia projektu Ustalenie szczegółów zakończenia projektu Klucze do sukcesu Informowanie — zawczasu i regularnie Aktualizacja planu po każdym sprincie Postaraj się ukończyć najpierw elementy o najwyższym priorytecie Dokładniejsze oszacowania dla większych elementów Dostarczanie działającego oprogramowania Scrum i planowanie wydania Bibliografia Rozdzia(cid:239) 12. Dekompozycja historyjek i zada(cid:241) Historyjka Model Konfiguracja Dekompozycja historyjki Dekompozycja zadania Klucze do sukcesu Bibliografia Inne źródła Rozdzia(cid:239) 13. B(cid:239)(cid:218)dy pod kontrol(cid:200) Historyjka Model Klucze do sukcesu Bibliografia Inne źródła 169 169 170 170 171 173 173 176 176 178 180 183 183 187 188 189 190 193 194 196 196 196 196 196 197 197 197 199 199 202 202 203 206 209 210 210 211 211 213 215 216 216 Kup książkęPoleć książkę Rozdzia(cid:239) 14. Utrzymanie sprawno(cid:258)ci a Scrum Historyjka Model Dedykowanie czasu Dane zbierane w czasie… Model z zespołem dedykowanym Klucze do sukcesu Wymiana członków zespołów Koniec końców… Bibliografia Rozdzia(cid:239) 15. Przegl(cid:200)d Sprintu Historyjka Model Przygotowanie do spotkania Przebieg spotkania Klucze do sukcesu Wykorzystaj swój czas na stworzenie dobrego planu Prowadź dokumentację zagadnień związanych z podjętymi decyzjami Poproś o akceptację Postępuj odważnie Inne źródła Rozdzia(cid:239) 16. Retrospektywy Historyjka Praktyka Doceń znaczenie retrospektyw Zaplanuj efektywną retrospektywę Przeprowadzenie Retrospektywy Sprintu Klucze do sukcesu Pokaż im „dlaczego?” Stwórz odpowiednie środowisko Organizuj je wtedy, gdy są potrzebne Traktuj retrospektywy tak, jak byś traktował bardzo ważne osoby Bibliografia Cz(cid:218)(cid:258)(cid:202) III Pierwsza pomoc Rozdzia(cid:239) 17. Produktywny Codzienny Scrum Historyjka Model Pora dnia Terminowe rozpoczęcie i zakończenie spotkania Identyfikuj ukryte przeszkody Koniec z myślą o początku Spis tre(cid:258)ci 9 217 217 220 220 221 221 224 224 224 225 227 227 231 232 233 233 234 234 235 235 235 237 237 240 240 241 242 245 245 245 246 246 246 247 249 249 252 253 253 255 257 Kup książkęPoleć książkę 10 Spis tre(cid:258)ci Klucze do sukcesu Zachowaj kadencję spotkań Stój, nie siadaj… Praca zespołowa Bądź cierpliwy Rozdzia(cid:239) 18. Czwarte pytanie Codziennego Scruma Historyjka Model Klucze do sukcesu Bibliografia Rozdzia(cid:239) 19. Programowanie w parach — utrzymanie zaanga(cid:285)owania cz(cid:239)onków zespo(cid:239)u Historyjka Model Luźne parowanie Mikroparowanie Klucze do sukcesu Bibliografia Rozdzia(cid:239) 20. Dodawanie nowych cz(cid:239)onków do zespo(cid:239)u Historyjka Model Ćwiczenie Klucze do sukcesu Zaakceptuj spadek prędkości Wybierz mądrze Ryzykowny biznes Bibliografia Rozdzia(cid:239) 21. Gdy dochodzi do zderzenia kultur Historyjka Model Klucze do sukcesu Zdobądź kontrolę nad swoim przeznaczeniem Pracuj z tym, co masz Trzymaj kurs Bibliografia Inne źródła Rozdzia(cid:239) 22. Sprint — procedury awaryjne Historyjka Model Usunięcie przeszkód Skorzystanie z pomocy 257 257 258 258 260 261 261 264 265 266 267 267 269 270 272 274 275 277 277 279 282 282 283 283 283 284 285 285 291 296 296 297 298 299 299 301 301 303 304 304 Kup książkęPoleć książkę Zmniejszenie zakresu zadań Anulowanie sprintu Klucze do sukcesu Bibliografia Cz(cid:218)(cid:258)(cid:202) IV Zaawansowane techniki survivalu Rozdzia(cid:239) 23. Zrównowa(cid:285)one tempo Historyjka Model Skrócenie iteracji Monitorowanie wykresów spalania Wydłużenie czasu pracy zespołowej Klucze do sukcesu Bibliografia Rozdzia(cid:239) 24. Dostarczanie dzia(cid:239)aj(cid:200)cego oprogramowania Historyjka Model Historyjka rdzenia Liczba użytkowników Zacznij od elementu o najwyższym stopniu ryzyka Rozwinięcie i weryfikacja Klucze do sukcesu Zmiana sposobu myślenia Przeróbki Skup się na kompletnych, weryfikowanych scenariuszach Inne źródła Rozdzia(cid:239) 25. Optymalizacja i pomiar warto(cid:258)ci Historyjka Model Prace nad funkcjonalnościami Straty Impulsy testowe Warunki wstępne Błędy/bugi Strukturyzacja danych Wykorzystanie danych Klucze do sukcesu Edukowanie interesariuszy Praca z interesariuszami Określanie trendów i identyfikowanie wzorców Inne źródła Spis tre(cid:258)ci 11 305 305 306 307 309 311 311 315 318 319 320 321 322 323 323 327 327 328 329 330 331 331 332 333 334 335 335 337 338 338 339 340 341 342 342 342 342 343 343 343 Kup książkęPoleć książkę 12 Spis tre(cid:258)ci Rozdzia(cid:239) 26. Kosztorysowanie z wyprzedzeniem Historyjka Model Specyfikacje funkcjonalne Historyjki użytkownika Szacowanie historyjek Priorytetyzacja historyjek Ustalenie prędkości Wyliczenie kosztów Stworzenie planu wydań Klucze do sukcesu Bibliografia Rozdzia(cid:239) 27. Dokumentacja w projektach scrumowych Historyjka Model Po co prowadzimy dokumentację? Co mamy dokumentować? Kiedy i jak dokumentujemy? Dokumentowanie w projekcie zwinnym Zaczynanie projektu przy braku wyczerpującej dokumentacji Klucze do sukcesu Bibliografia Rozdzia(cid:239) 28. Outsourcing i offshoring Historyjka Model Poznaj rzeczywiste koszty Radzenie sobie z rzeczywistością Klucze do sukcesu Wybierz odpowiedni zespół outsourcingowy Przydzielanie pracy w sposób jak najmniej bolesny Trzymaj się ram Scruma Zbuduj kulturę jednego zespołu Bądź przygotowany na podróżowanie Zatrudnij koordynatora projektu/zespołu Nigdy nie korzystaj z zespołów offshore, gdy… Bibliografia Inne źródła Rozdzia(cid:239) 29. Ustalanie priorytetów i szacowanie w du(cid:285)ych rejestrach Historyjka Model Zespół Interesariusze 345 345 350 350 350 351 352 353 353 353 354 355 357 357 360 361 362 362 365 366 367 368 369 369 372 372 375 377 377 378 378 379 380 381 381 382 382 383 383 386 387 387 Kup książkęPoleć książkę Spis tre(cid:258)ci 13 Klucze do sukcesu Wcześniejsze zaplanowanie spotkań jest niezbędne Podkreśl znaczenie dyskusji i zdefiniuj limity czasowe Parking dla konfliktów Przynieś dodatkowe karty/papier na historyjki, które powstaną w sali konferencyjnej Przypomnij, że zmiana jest nieuchronna Bibliografia Rozdzia(cid:239) 30. Formu(cid:239)owanie umów w Scrumie Historyjka Model Umowy tradycyjne i zmiana zamówienia Timing Zakresy oraz zmiany Klucze do sukcesu Dostępność klienta Okno akceptacji Priorytetyzacja Klauzule mówiące o wygaśnięciu umowy Zaufanie Bibliografia Dodatek A Przewodnik po Scrumie Role Mistrz Młyna Właściciel Produktu Zespół Deweloperski Artefakty Rejestr Produktu Rejestr Sprintu Wykres spalania Spotkania Planowanie Sprintu Codzienny Scrum Przegląd Sprintu Retrospektywa Sprintu Składamy wszystko w całość Skorowidz 390 390 391 391 392 392 392 393 393 397 397 401 403 406 407 407 407 408 408 409 411 412 412 412 413 413 413 415 415 415 416 416 417 417 418 419 Kup książkęPoleć książkę 14 Spis tre(cid:258)ci Kup książkęPoleć książkę Rozdzia(cid:239) 1 SCRUM: PROSTE, ALE NIE (cid:146)ATWE Scrum jest zwinnie zwodniczy. To jedna z tych metod, które wydają się najłatwiejsze do opanowania, a okazują się najtrudniejsze do właściwego wdrożenia. Używam tu zwrotu „właściwe wdrożenie”, ponieważ wrodzona prostota Scruma może nas zwieść i sprawić, że zaczniemy uważać tę metodykę za rozwiązanie, które łatwo zastosujemy w naszym otocze- niu, podczas gdy w rzeczywistości, zanim wszystko zacznie działać tak, jak należy, mogą mi- nąć lata. Reguły Scruma wydają się przeczyć wszystkiemu, czego nauczyliśmy się podczas wielu, wielu lat realizowania projektów w systemie kaskadowym. Bez wątpienia oduczenie się złych nawyków i przystosowanie się do nowej rzeczywistości musi zająć trochę czasu. W dodatku umieszczonym na końcu tej książki wyjaśniam, jak działają mechanizmy na- pędzające Scrum. Jeśli nie znasz Scruma i nie masz zielonego pojęcia, jak wygląda praca w tej metodzie, proponuję zacząć od zapoznania się ze wspomnianym dodatkiem. Jeśli natomiast masz już podstawową wiedzę na ten temat, zapewne dobrze wiesz, że system jest stosunkowo prosty. Tak prosty, że wielu ludzi szybko stwierdza, iż niczego więcej się już nie nauczą, i od razu zaczyna modyfikować zasady systemu tak, aby lepiej dopasować go do swojego środowiska projektowego. Zbyt często okazuje się jednak, że w konsekwencji takich działań gubią właściwą drogę, zniechęcają się pierwszymi niepowodzeniami, a potem szukają pomocy. Ta książka ma być rzuconym im kołem ratunkowym. Historia opisana na następnych stronach poka- zuje, jak szybko można doprowadzić do sytuacji, w której Scrum „rozłazi się w szwach”, jeśli reguły metody zostaną wdrożone bezrefleksyjnie i przy braku solidnych podstaw — to zna- czy bez pełnego zrozumienia podstawowych pojęć tak zwanych zwinnych metod zarządza- nia projektami odpowiadających za skuteczność metody takiej jak Scrum. Historyjka Jeff był trenerem metod zwinnych, którego zadaniem było wspieranie wdrożeń Scruma w dużej firmie programistycznej. Któregoś dnia otrzymał e-mail od Suzy, kierowniczki programu w podległym mu oddziale. „Jeff, proszę cię o pomoc. Pracujemy ze Scrumem już przez mniej więcej sześć miesięcy, ale jakość naszego kodu nie poprawia się tak, jak bym chciała. Myślę, że potrzebujemy cię, żebyś porozmawiał z zespołem na temat programowania parami. W następny poniedziałek zaczynamy nasz tydzień planowania. Czy mógłbyś nas wtedy odwiedzić?”. Mężczyzna odchylił się na oparcie fotela. Omówienie programowania parami było stosun- kowo prostym zadaniem. Mógłby zabrać na spotkanie Julie, przyjaciółkę, świetnego dewelopera 29 Kup książkęPoleć książkę 30 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe i doświadczonego praktyka zwinnych metod projektowania. Nie ma sprawy. A jednak dwa słowa z tego listu sprawiły, że usłyszał w głowie głośny dźwięk dzwonka alarmu. Cały tydzień planowania? Zgodnie ze wszystkimi regułami Scruma wymagane są dwa spotkania planowania sprintu, każde z nich nie dłuższe niż cztery godziny. Tymczasem w tym zespole planowanie trwa tydzień? Coś mówiło Jeffowi, że czeka go więcej pracy, a nie tylko wykład z programo- wania parami. Zapowiadał się całkiem interesujący poniedziałek. Gdy Jeff i Julie pojawili się na spotkaniu, Suzy i jej zespół składający się z ośmiu ludzi czekali już na nich w sali konferencyjnej. Suzy przygotowała krótkie wprowadzenie. Potem Jeff i Julie przedstawili się, a następnie szybko przeszli do rozmowy na temat kwestii związa- nych z jakością kodu, które tak niepokoiły Suzy. Na reakcję zespołu nie trzeba było długo czekać. Najpierw głos zabrał główny tester, Mike: — Kod jest kiepski, bo nie mamy czasu, żeby go porządnie przetestować. Deweloperzy pracują nad nim aż do ostatniego dnia naszego czterotygodniowego sprintu. Sprint tworze- nia kodu i jego testowania to ma być sprint tworzenia kodu oraz testowania. Tymczasem testy albo zostają wciśnięte na koniec sprintu albo przerzucamy je do sprintu integracyjnego. Julie przerwała Mike’owi: — Przepraszam… powiedziałeś „sprintu integracyjnego”? — Julie spojrzała na Suzy, któ- ra kiwnęła głową. — Och! Nie powiedziałam wam o naszych modyfikacjach, prawda? Otóż tak… wiemy, że Scrum wymaga przygotowania nowego wydania co cztery tygodnie. Jednak to nie jest moż- liwe w przypadku pracy, jaką wykonujemy. Chodzi o to, że przed przejściem na Scruma sta- raliśmy się wydawać nową wersję oprogramowania co kwartał i skończyło się kompletną katastrofą! Dlatego zmodyfikowaliśmy system tak, żeby lepiej dopasować go do naszego pro- cesu i rzeczywistości — wyjaśniła Suzy, po czym podeszła do tablicy i zaczęła rysować. — Zaczynamy od tygodnia planowania sprintu, po którym następują cztery tygodnie sprintu rzeczywistego, gdy deweloperzy piszą kod, a testerzy tworzą historyjki testowe. Po tym prze- prowadzamy naszą integrację. Następnym etapem jest wdrożenie. Oczywiście zwykle dodaję tygodniowy bufor bezpieczeństwa… tak na wszelki wypadek — wyjaśniała. Kiedy skończyła, niemal cała tablica została pokryta notatkami dotyczącymi harmono- gramu prac zespołu. Jeff i Julie spojrzeli po sobie, a potem skierowali oczy na Suzy. Reszta zespołu wyglądała na znudzoną. Jeff zadał oczywiste pytanie: — Suzy, czy wasze sprinty naprawdę trwają osiem albo dziewięć tygodni? Kup książkęPoleć książkę Historyjka 31 — No tak… — odpowiedziała. — Wyglądasz na zaskoczonego. Wiem, że to nie przypo- mina klasycznego Scruma, ale w naszym przypadku się sprawdza. Myślę o jeszcze jednym tygodniu na pisanie specyfikacji i plany testów. Mamy problem z wyrobieniem się z tym na czas. Teraz robimy to w tygodniu buforowym, ale naprawdę nie lubię rezygnować z naszej poduszki bezpieczeństwa. — OK, jeszcze do tego wrócimy — stwierdziła Julie. Spojrzała na Jeffa, który podniósł ręce do góry, jakby chciał spytać: „Co zamierzasz z tym zrobić?”. Potem Julie zwróciła się do Mike’a: — Mówiłeś, że nie macie czasu na testowanie… Zanim Julie usłyszała odpowiedź Mike’a, wtrącił się Wyatt: — Nie słuchaj go. Mają mnóstwo czasu na testy. To my nigdy nie mamy wystarczająco dużo czasu. Robimy, co możemy, żeby w każdy sprint wcisnąć jak najwięcej kodu. A może my potrze- bujemy wszystkich czterech tygodni? To czasochłonny proces. — Wyatt rzucił spojrzenie w kierunku Mike’a i kontynuował: — Od kiedy zaczęliśmy stosować Scrum, ty i reszta teste- rów przez cały czas tylko marudzicie, że nie macie czasu. Może problem leży w samym me- chanizmie Scruma? Jeff i Julie wymienili spojrzenia. Suzy przerwała Wyattowi: — Ludzie! Dajcie spokój. Nie jesteśmy tu po to, żeby narzekać na Scrum. Naszym celem jest poprawa jakości kodu. — Przerwała i wzięła głęboki oddech. — Powtarzam to od sześciu miesięcy — zwróciła się do Jeffa i Julie, przewracając oczami. Jeff skinął głową: — Widzę, że jesteś sfrustrowana. I widzę też, że Wyatt i Mike są równie mocno sfrustro- wani. Czy mogę poznać więcej szczegółów i porozmawiać o tym z zespołem? Zobaczę, czy uda mi się zidentyfikować źródło problemu. Suzy skinęła głową pełna entuzjazmu. Jeff zaczął od pierwszego pytania standardowej oceny. — W porządku… Zarówno Scrum, jak i reguły programowania ekstremalnego zalecają zastosowanie codziennych punktów kontrolnych. W tym przypadku mówię o Codziennym Scrumie. Co o nich myślicie? — Jeff zwrócił się do zespołu. Mike wybuchnął śmiechem: — Codzienne spotkania? Żartujesz sobie? Nie mamy na nie czasu. Spotykamy się dwa ra- zy w tygodniu na godzinę. I nawet to nie wychodzi nam za dobrze. — OK. Mike, opowiedz mi o tych spotkaniach — poprosił Jeff. — No cóż… przede wszystkim za każdym razem odtwarzamy takie same dialogi. Dewelope- rzy twierdzą, że pracują nad zadaniami, a my mówimy, że budujemy historyjki testowe. Cóż za wspaniałe wieści! Potem spędzamy mniej więcej 20 minut, dyskutując o naszej liście błę- dów. Sprowadza się to do odczytania listy i stwierdzenia: „Ten błąd wynika z projektu” lub „Załatwimy to podczas kolejnego sprintu”. Oczywiście nigdy nie eliminujemy tych błędów. To po prostu jeden wielki dysfunkcyjny bałagan. Dało się zauważyć, że w Suzy wzbiera gniew. Dlatego Jeff dał jej możliwość wypowiedze- nia się: — Dzięki. Suzy, chciałabyś coś powiedzieć? — Mike ma rację w jednej kwestii. W naszym przypadku codzienne spotkania by się nie sprawdziły. Musimy organizować je co drugi dzień. Mam zbyt wiele zajęć, żeby uczestniczyć Kup książkęPoleć książkę 32 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe w nich co dzień, a niektórzy członkowie zespołu pracują także przy innych projektach. Wiem, że to nie jest idealne rozwiązanie, ale właśnie tak musimy robić. Wkurza mnie, że zespół się ze mną nie zgadza, uważając spotkania odbywające się dwa razy w tygodniu za zbyt wielkie ob- ciążenie. Słyszałeś, co mówił Mike. Wszyscy narzekają na spotkania, harmonogram, brak czasu! A ja nic nie poradzę, że kierownictwo zmusza nas do przygotowywania częstszych wydań. Co więcej, powtarzam wszystkim, że to jest mój projekt. To ja ustalam plan i ja je- stem od tworzenia struktury. Powiedz im, Jeff. Ja jestem Mistrzynią Młyna. Powinni robić to, co każę. Prawda? — Suzy domagała się wsparcia. Jeff niezobowiązująco wzruszył ramionami i ugryzł się w język. Zaczynał zdawać sobie sprawę, że ten zespół tak naprawdę nie rozumie zasad Scruma. Popatrzył na Julie i rzucił jej jedno z tych spojrzeń, które znaczyły: „Oni zupełnie nie łapią, o co tu chodzi”. Julie myślała podobnie, potwierdzając jego ocenę lekkim skinieniem głowy. Jeff przeszedł do dalszej anali- zy sytuacji: — OK, rozumiem, co mówisz. Póki co nie zapędzajmy się za daleko. Wydaje mi się, że wasz problem wynika z tego, że codzienne spotkania wcale nie są codziennie, nic nie wnoszą i trwają za długo. Z tym możemy sobie jakoś poradzić. Ale zostawmy na chwilę ten temat i przejdźmy na wyższy poziom procesu myślowego. Powiedzcie mi, skąd wziął się pomysł ośmiotygodniowego sprintu? Znów odezwał się Wyatt: — Pracuję w tej firmie ponad dziesięć lat i wierzcie mi, widziałem już wszystkie nowe, chwi- lowe mody, jakie istnieją. Pojawiają się i znikają. Tym razem jednak dałem się przekonać i zacząłem wierzyć, że Scrum jest inny. Co za żart! Wszystko zaczęło się od tego, że szefostwo domagało się od nas coraz częstszych wydań. Przeszliśmy na system wersji pojawiających się kwartalnie. I powiem ci, że przejście z rocznych okresów na kwartalne było bolesne, ale ope- racja zakończyła się sukcesem. Tyle że szefom było za mało, prawda? — Wyatt przerwał na chwilę i rozejrzał się po pokoju, szukając wsparcia u innych członków zespołu. — Któregoś dnia podczas lunchu spotkaliśmy z Suzy mojego znajomego, który pracuje w innym dziale. Opowiedział nam, w jaki sposób jego zespół korzysta ze Scruma i jak udaje im się przygoto- wywać kolejne wersje oprogramowania co cztery tygodnie. Wszyscy byli zadowoleni. Jakość oprogramowania wystrzeliła w kosmos. Szefowie firmy od lat nie byli tak usatysfakcjonowani, a klienci podchodzili do całego zagadnienia wprost ekstatycznie. A tamten nasz znajomy był podobnym do mnie sceptykiem, wiesz? Pomyślałem więc, że jeśli on twierdzi, że to działa, to system naprawdę musi się sprawdzać. Spędziliśmy z Suzy i moim znajomym całe popołudnie, rozmawiając na temat Scruma. Metoda wydawała się dość prosta, ale widzieliśmy, że będziemy musieli rozwiązać kilka problemów. Po pierwsze: codzienne spotkania. Kto ma na nie czas? Prostym rozwiązaniem okazało się organizowanie ich dwa razy w tygodniu. Potem stwier- dziliśmy, że cykl trwający cztery tygodnie w naszym przypadku się nie sprawdzi. W końcu ledwo udawało nam się zamykać projekty w cyklu kwartalnym, więc zdecydowaliśmy się po- dwoić te cztery tygodnie. I tak pojawił się pomysł sprintu ośmiotygodniowego. Na tej podstawie podzieliliśmy etapy procesu. Wystarczyło tylko przeprowadzić małe skalowanie. Przecież Scrum jest kolejnym procesem typu przyrostowego. Jeff i Julie znów rzucili sobie wymowne spojrzenia. Wyatt kontynuował: Kup książkęPoleć książkę Historyjka 33 — Widzę to spojrzenie. Ale mówię wam, że znamy nasz zespół i produkt. Nie ma mowy, żebyśmy mogli zastosować Scrum w wersji podstawowej. Zrobiliśmy to, co zrobiłby każdy zespół pracujący nad oprogramowaniem. Dostosowaliśmy system do naszych potrzeb. Nasza modyfikacja najlepiej pasuje do tego, co robiliśmy w przeszłości. — Tak — potwierdziła Suzy. — Chodzi mi o to, że Scrum jest przecież metodą zarządza- nia projektem przez menedżerów, tyle że prowadzącą na skróty. Jeff odchylił się na oparcie fotela, na którym siedział. W takiej sytuacji przygotowane przez niego pytania oceny do niczego się nie nadawały. Nie wiedział, co mógłby teraz po- wiedzieć. Z pomocą pospieszyła Julie: — Powiedz mi, Wyatt, czy ustaliliście wspólną definicję ukończenia? — Oczywiście, że tak. Po pierwszym tygodniu odbywa się spotkanie oceny projektu. Pod koniec piątego tygodnia docieramy do kamienia milowego ukończenia kodu. Na ostatnim etapie integracji wiemy, że zakończyliśmy etap testowania i pełnej integracji. Kiedy osiągamy te kamienie milowe, umieszczamy efekt naszej pracy na stronie internetowej. Naprawdę nie- trudno zrozumieć nasze modyfikacje. — Tak. Są proste. Rozumiem — powiedziała uspokajająco Julie. — Wyjaśniliście nam, jak wygląda wasz proces. Podsumujmy: odbywacie spotkania planowania dwa razy w tygodniu, zdecydowaliście się na ośmiotygodniowe (czasami dziewięciotygodniowe) sprinty i macie punkty oceny na niektórych kluczowych etapach, dzięki którym sprawdzacie poziom goto- wości produktu. Jak to się sprawdza w praktyce? Dobrze się bawicie? Czy kod uległ znacznej poprawie? — No cóż, kod nie jest taki zły… — powiedział Wyatt. — Nie jest zły? — zaoponowała Suzy. — Jest okropny! — To nie nasza wina, że jest okropny! Testujemy go, ale, jak powiedziałem, po prostu nie mamy dość czasu! — krzyknął Mike. Reszta ludzi pospuszczała głowy. Nie zamierzali brać udziału w tym starciu. — Nie obwiniam cię, Mike, chociaż mógłbym. Nie. Prawdziwym problemem jest sam Scrum — powiedział Wyatt. — To głupia metoda. I nie działa. — Tylko nie zaczynajcie od nowa — jęknęła Suzy. — Ile razy jeszcze będziemy o tym dyskutować? To powtarza się przy okazji każdej retrospektywy. — Mówisz o retrospektywie? — przerwał jej Wyatt. — To tylko osobliwa nazwa dwu- dniowej sesji narzekań i marudzenia. Retrospektywy niczego nie zmieniają. Scrum niczego nie zmienia. A nie! Odwołuję to. Scrum zmienia jedną rzecz. Sprawia, że wszyscy jesteśmy nieszczęśliwi. — To był też twój pomysł. Dlaczego zgodziłeś się na wdrożenie metody, jeśli teraz tylko ją sabotujesz? — pytała rozeźlona Suzy. Jeff wstał. Nadszedł czas, aby przestać zadawać pytania i zrobić coś, żeby ten zespół zaak- ceptował prawdę. — Słuchajcie, to nie niczyja wina i nie jest to też wina metody. Dla mnie, i jestem pewien, że Julie się ze mną zgodzi, wygląda na to, że wy w ogóle nie robicie Scruma. Robicie to, co zawsze, tyle że teraz wciskacie całą pracę w ośmiotygodniowy cykl. Takie zarządzanie projektem przypomina Scrum tylko z nazwy. Wyatt i Suzy zaczęli się kłócić, ale Julie podniosła rękę, aby uspokoić zwaśnione strony. Kup książkęPoleć książkę 34 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe — Pozwólcie mi zadać jedno pytanie. Adresuję je do całego zespołu. Wyatt, Suzy, Mike, proszę was o niezabieranie głosu. — Julie spojrzała po kolei na każdego członka zespołu. — Czy ten nowy sposób zarządzania sprawił, że wasze życie stało się nie do zniesienia, czy mo- że zawsze tak było, tylko do tej pory nie wydawało się to takie oczywiste? — spytała. Wszyscy pozwieszali głowy. Gdy ludzie zastanawiali się nad odpowiedziami, dotykali niemalże brodami piersi. sprawy ze skali problemu. — Już wcześniej była kicha — zabrzmiał jakiś głos z tyłu sali. — Tak jest — przyznał inny członek zespołu. — Wcześniej nie zdawaliśmy sobie tylko Gdy wszyscy uświadomili sobie powagę sytuacji, w pomieszczeniu zapadła głucha cisza. Wyatt westchnął i powiedział: — Macie rację. Wcześniej wcale nie było lepiej. Po prostu nie było to takie oczywiste. Problem pojawiał się tylko raz na kwartał. A teraz cierpimy co osiem tygodni. Głos zabrał Mike: — Wiecie co? Jeśli spojrzeć wstecz na ostatnie sześć miesięcy, okazuje się, że odkryliśmy wiele rzeczy, które możemy poprawić i które trzeba naprawić, ale nic z tym nie zrobiliśmy. Naprawdę nic. Całe spotkanie podsumowała Suzy: — Chłopaki, jestem naprawdę zmęczona. Czy możemy to przełożyć i zebrać się ponow- nie w przyszłym tygodniu? Ludzie z zespołu pokiwali głowami. Oni naprawdę byli zmęczeni. Suzy opuściła salę konferencyjną ze świadomością, że sprawy nie idą w dobrym kierun- ku. Przez cały weekend i pierwsze dni następnego tygodnia zastanawiała się, jak może wpłynąć na poprawę sytuacji. Zaprosiła Jeffa i Julie na kolejne spotkanie, podczas którego — miała taką nadzieję — uda się tchnąć nowego ducha w członków zespołu i podnieść morale ludzi. — Przykro mi — przyznała, otwierając spotkanie. — Wiedziałam, że nie wszystko nam się układa, ale nie zdawałam sobie sprawy, że jest aż tak źle. Najpierw miałam nadzieję, że Jeff i Julie pomogą nam w kwestii dopracowania programowania parami, bo wydawało mi się, że to rozwiąże nasze problemy z jakością. Okazuje się jednak, że nie dostrzegałam naszych rze- czywistych potrzeb. I za to przepraszam. Źle do tego podeszliśmy. Problemem nie jest Scrum, ale to, w jaki sposób próbujemy wdrożyć metodę. Chciałabym prosić wszystkich o zgodę, żeby zacząć wszystko od zera. Myślę, że Jeff i Julie mogą nam w tym pomóc — powiedziała Suzy. Wyatt skinął głową i spojrzał na zespół. — Wiem, że czasami zachowuję się jak palant. Jestem tu już tak długo, że chwilami wy- daje mi się, że jestem właścicielem tej firmy. Nie jestem. Wiem, że stać mnie na więcej. Przestanę narzekać i naprawdę przyłożę się do roboty, ale zrobię to tylko pod jednym warunkiem. — Jakim? — spytał Jeff. — Że weźmiemy się do tego na poważnie. Nie chcę już nigdy słyszeć o dostosowywaniu. I potrzebujemy trenera. Kogoś, kto pokaże nam, co mamy robić. Metoda nie jest nawet w przy- bliżeniu tak prosta, na jaką wyglądała. Podniósł się Mike. — I ja mam warunek. Rozwiążemy problemy. Naprawdę je rozwiążemy, nikogo za nie nie obwiniając. — Wyciągnął rękę do Wyatta. — Myślisz, że damy radę? Wyatt spojrzał na Mike’a, potem na jego rękę, którą po chwili uścisnął i potrząsnął nią. Kup książkęPoleć książkę — Myślę, że jesteśmy gotowi na to wyzwanie. Oczywiście jeśli Jeff może nam pomóc… Scrum 35 — zażartował z lekkim szyderstwem w głosie, unosząc brwi i spoglądając na Jeffa. Wszyscy wybuchli śmiechem. To był pierwszy prawdziwy śmiech, jakiego nie słyszano w zespole od dłuższego czasu. Nowy początek. Wszyscy zgromadzili się przy stole, wyrażając głośno swoją gotowość do podjęcia kolejnej próby ze Scrumem. Tym razem mieli zrobić to naprawdę. Jeff i Julie opuścili salę konferencyjną, czując, że udało im się wiele osiągnąć. Wiedzieli jednak, że nadal pozostało sporo do zrobienia. — Co masz zamiar z tym zrobić, Jeff? — spytała Julie. — Przede wszystkim zaczniemy od omówienia, czym jest Scrum. Najpierw wyjaśnię im, jakich zmian mentalnych będzie wymagać od nich nowy system. Opowiem im o wartościach i regułach Scruma — odpowiedział Jeff. — Nie zapomnij pokazać im, jak wygląda zarządzanie ryzykiem i identyfikacja problemów. — Nie zapomnę. Zacznę od podstaw, a potem pokonamy wszystkie przeszkody, w miarę jak będą się pojawiać. Oznacza to, że czasami czeka nas prawdziwa walka. Wierzę jednak, że to się uda. Bez pracy nie ma kołaczy, prawda? Scrum Scrum wydaje się prosty. Jednak ludzie często nie rozumieją, że aby właściwie wdrożyć cały system, trzeba całkowicie zmienić sposób myślenia o tworzeniu oprogramowania. A to nie jest łatwe. Trzeba będzie stanąć do walki. Radzić sobie z napotkanymi przeszkodami. Zespół z naszej historyjki przekonał się o tym na własnej skórze, a jeśli już chwyciłeś za tę książkę, to prawdopodobnie masz podobne doświadczenia. Żeby zrozumieć, dlaczego coś tak prostego może być tak trudne, przyjrzymy się teraz nieco regułom Scruma. Czym jest Scrum? Jednym z moich ulubionych teleturniejów telewizyjnych od zawsze był quiz Jeopardy!1. Wciąż marzę o specjalnej edycji przeznaczonej dla deweloperów oprogramowania, w której mogły- by pojawić się takie kategorie jak: Metodologia i reguły metod, Typowe przyczyny błędów w opro- gramowaniu, Słynni architekci oprogramowania lub Głupie cytaty mądrych ludzi. Przycho- dzą mi do głowy dziesiątki pytań, które mogłyby trafić do tych kategorii. Na przykład: „Kogo uważa się za autora powiedzenia: Bądź miły dla nerdów. Istnieje duże prawdopodobieństwo, że będziesz pracować dla jednego z nich?”. Wyobrażam sobie inne pytanie z kategorii Meto- dologie i reguły metod: „Nazwa tej metody zarządzania projektami programistycznymi wy- wodzi się z terminologii rugby, a jej podstawowa reguła zakłada wydanie nowej wersji opro- gramowania co 2 – 4 tygodni”. Jedna z akceptowalnych odpowiedzi miałaby oczywiście formę pytania: Czym jest… Scrum? A zatem czym tak naprawdę jest Scrum? Scrum tak naprawdę nie jest metodyką ani ze- stawem praktyk programistycznych. Jest to natomiast lekki szkielet systemu stworzony z myślą o zarządzaniu projektem programistycznym i procesem rozwoju produktu. Oto jak definiują Scrum Ken Schwaber i Jeff Sutherland [SCHWABER 01]: 1 Polska wersja teleturnieju, emitowana w latach 1996 – 2003, nosiła nazwę Va banque — przyp. tłum. Kup książkęPoleć książkę 36 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe Scrum (rzecz.): metoda, przy użyciu której ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać pro- dukty o najwyższej możliwej wartości. Scrum jest: (cid:81) lekki, łatwy do zrozumienia, (cid:81) (cid:81) bardzo trudny do opanowania. Scrum stanowi ramy wykorzystywane w zarządzaniu procesami wytwarzania złożo- nych produktów od początku lat dziewięćdziesiątych. Sam w sobie Scrum nie jest proce- sem czy techniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik. Scrum pomaga odkrywać nieefektywności praktyk zarządczych i technik inżynierskich tak, by można było je doskonalić2. Scrum bazuje na iteracyjnych cyklach zwanych sprintami. Każdy sprint rozpoczyna się spotkaniem nazywanym Planowaniem Sprintu, a kończy demonstracją produktu, który po- tencjalnie nadaje się do pracy. System charakteryzuje się wysokim poziomem interakcji uczestni- ków i transparentnością działań — zarówno w ramach zespołu, jak i poza nim. Krótkie cykle oraz cecha systemu zakładająca ścisłą współpracę sprawiają, że Scrum idealnie nadaje się do zastosowania przy szybko zmieniających się projektach i wszędzie tam, gdzie często docho- dzi do modyfikacji zgłoszonych wcześniej założeń lub (i) pojawiają się nowe potrzeby. Scrum został zbudowany na bazie pięciu podstawowych wartości i przewiduje istnienie trzech ról, trzech artefaktów i trzech (lub czterech) typów spotkań. Więcej szczegółów na temat sposobu funkcjonowania Scruma znajdziesz w dodatku A, zatytułowanym „Przewodnik po Scrumie”. Zastosowanie Scruma Chociaż Scrum może wydawać się systemem prostym do zastosowania w środowisku pro- jektowym, tak naprawdę stanowi spore wyzwanie. Dlaczego? Ponieważ wymaga czegoś więcej niż tylko wprowadzenia odpowiednich mechanizmów i naciśnięcia przycisku start. Do po- prawnego wdrożenia Scruma konieczne jest istnienie zespołów, które są gotowe na: (cid:81) Podjęcie wysiłku zrozumienia istoty podstawowych wartości Scruma. (cid:81) Zaakceptowanie (często ogromnej) zmiany sposobu myślenia i nastawienia. (cid:81) Przygotowanie się na zmiany oraz ciągłe adaptowanie się do nowej sytuacji. (cid:81) Reagowanie na pojawiające się problemy i działanie na rzecz ich rozwiązywania. (cid:81) Włączenie do swoich działań zasad zwinnego projektowania. 2 Fragment pochodzi z oficjalnego polskiego tłumaczenia (wersja z lipca 2011 r.) przewodnika Scrum dostępnego pod adresem: http://www.scrumguides.org (dostęp w sierpniu 2013 r.). Autorami przekładu są: Tomasz Włodarek, Katarzyna Terlecka i Bogdan Baraszkiewicz — przyp. tłum. Kup książkęPoleć książkę Scrum 37 Scrum bazuje na warto(cid:258)ciach Każda metoda, która zasługuje na zastosowanie, bazuje na zasadach i wartościach. Każda z oryginalnych praktyk określanych wspólnym mianem zwinnych — XP, Scrum, DSDM, Crystal i FDD — a także Kanban i Lean — wyróżnia się zestawem fundamentalnych wartości, które nas prowadzą, zapewniają jasną wizję wtedy, gdy opadają nas wątpliwości, i co naj- ważniejsze, pomagają zrozumieć, dlaczego robimy to, co robimy. Historia przywołana w tym rozdziale opisuje sytuację, w której zespół programistów próbuje zastosować mechanizmy Scruma bez zastanowienia się nad tym, dlaczego tak postępuje. Bohaterom historyjki brako- wało zrozumienia wartości, na których bazuje metoda: skupienia, szacunku, zaangażowania, odwagi i otwartości [SCHWABER 02]. Skupienie „Skupić się” oznacza skoncentrować się, poświęcać czemuś uwagę. Jeśli efektem pracy zespołu ma być sprawny element przyrostu funkcjonalności, tworzący go ludzie muszą się skupić na tym, aby zrobić wszystko, co pozwoli im zrealizować ten cel. Skupienie oznacza skoncentro- wanie się tylko na tym jednym, właśnie realizowanym projekcie. Może to oznaczać wydzielenie określonego czasu zespołu, gdy cała grupa nie zagląda do poczty e-mail, nie korzysta z ko- munikatorów, telefonów komórkowych i nie uczestniczy w innych spotkaniach. Skupienie na tym, co najważniejsze, oznacza robienie wszystkiego, co konieczne, aby umożliwić ze- społowi skoncentrowanie się na pracy z myślą o jak największej efektywności na przestrzeni całego sprintu. Szacunek Wszyscy znamy powiedzenie, że na szacunek trzeba sobie zapracować i nikt nie otrzymuje go z urzędu. W przypadku Scruma to stwierdzenie jest wyjątkowo prawdziwe. Szacunek do kolegów, lub jego brak, może decydować o fiasku lub sukcesie projektu. Skuteczne w swoich działaniach zespoły scrumowe muszą składać się z ludzi darzących się wzajemnym zaufa- niem, gotowych do wspólnego pokonywania wszystkich przeszkód. Jeśli jeden członek ze- społu angażuje się w rozwiązanie problemu, to samo czynią inni. W naprawdę efektywnym zespole scrumowym nie ma konfliktów na linii my versus oni. W opisywanej na początku tego rozdziału historii wyraźnie rysuje się konflikt pomiędzy testerami oprogramowania i programi- stami. Przedstawiciele tych grup najwyraźniej zaczęli tracić do siebie szacunek. Na szczęście udało się nie dopuścić do pogorszenia się konfliktu, o czym świadczy fakt, że w końcu wszy- scy podejmują wspólną decyzję o daniu sobie jeszcze jednej szansy. Zaanga(cid:285)owanie Zaangażowanie jest zapewnieniem lub obietnicą wykonania pewnej pracy. Te zobowiązania należy traktować poważnie, przy zapewnieniu jak największej ilości informacji. Zespół anga- żuje się i zobowiązuje wobec organizacji i wzajemnie — wobec innych członków grupy — podczas każdego spotkania planowania sprintu. Pod koniec spotkania wszyscy członkowie zespołu powinni znajdować się na tym samym poziomie zrozumienia tego, co zespół zobo- wiązuje się wykonać podczas sprintu. Kup książkęPoleć książkę 38 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe Odwaga Odwaga to gotowość stawienia czoła trudnościom na przekór swoim lękom. Jednym z naj- lepszych sposobów wspierania członków zespołów i organizacji, a także podejmowania ak- tywności promujących odważne decyzje, są aktywne działania podejmowane z myślą o po- konywaniu lęków. Zespół, który okazuje zrozumienie i nie lęka się szczerej dyskusji, albo organizacja, która udowadnia, że jest gotowa wysłuchać wszystkich (także tych negatyw- nych) opinii, podchodząc do przekazywanych informacji obiektywnie — takie postawy po- zwalają promować odważne zachowania osób, które nie obawiają się mówić to, co myślą. Pamiętaj, że gdy zespołowi brakuje odwagi, aby robić to, co uważa za słuszne, mało prawdo- podobne, iż zrobi to, co powinno być zrobione. Otwarto(cid:258)(cid:202) Otwartość pozwala nam przyjmować nowe idee. Poziom otwartości zespołu najwyraźniej widać podczas retrospektywy następującej po sprincie. Gotowość zaakceptowania nowych pomy- słów, spostrzeżeń i sposobów podejścia do pewnych spraw pomaga nam rozwijać się w or- ganizacji uczącej się, a także tworzyć bardzo efektywne zespoły. Scrum wymaga zmiany sposobu my(cid:258)lenia Albert Einstein powiedział kiedyś: „Nie możemy rozwiązywać problemów, odwołując się przy tym do schematów myślenia, z których te same problemy wyniknęły”. Wśród największych przeszkód stojących na drodze do skutecznego wdrożenia systemu Scrum (lub każdej innej metody należącej do grupy zwinnych metod zarządzania projektami) wymienia się nieumiejęt- ność zmiany nastawienia — to znaczy niezdolność do odwołania się do nowego sposobu myślenia podczas rozwiązywania problemów. W rezultacie zarówno Scrum, jak i wszystkie inne zwinne praktyki wymagają otwarcia się na nowe koncepcje — co najmniej przez pierw- sze 3 – 6 miesięcy. Gdy pracowałem nad moim pierwszym projektem scrumowym, musiał minąć prawie rok, zanim naprawdę zrozumiałem, o co tak naprawdę chodzi w tej metodzie. Przez ten rok zrozumiałem, że Scrum jest potężnym narzędziem, które jednak w niewła- ściwych rękach może się okazać niebezpieczne. Czy widziałeś kiedyś, drogi Czytelniku, którykol- wiek z odcinków serialu Home Improvement3? Główny bohater serialu, Tim „The Toolman” Taylor, zwykł wpadać w spore kłopoty, gdy zaczynał korzystać z jakiegoś lśniącego nowością narzędzia, ale nie stosował odpowiednich środków bezpieczeństwa i używał go niezgodnie z przeznaczeniem, lub po prostu zabierał się do pracy, która przerastała jego możliwości. Podobnie jest ze Scrumem. Jeśli nie stosuje się metodyki zgodnie z instrukcją, zwłaszcza na początku przygody ze Scrumem, można szybko pogrążyć każdy projekt. Przekonało się o tym (zbyt) wiele zespołów posiadających tylko podstawową wiedzę, ludzi, którzy uznali: „My wiemy lepiej. Tu jest inaczej. Wszystko przemyśleliśmy”. Weź sobie do serca moją radę: Zanim zdecydujesz o dostosowaniu Scruma do swoich po- trzeb, poznaj wszystkie tajniki systemu. Jeśli zdecydujesz się na wdrożenie, użyj Scruma zgodnie z przeznaczeniem, w wersji podstawowej. Poświęć swój czas na dowiedzenie się wszystkiego, co musisz wiedzieć. Wygospodaruj nieco miejsca w mózgu, tak aby pozwolić tej wiedzy rozrastać 3 W Polsce serial nadawany przez TVP1 pod tytułem Pan złota rączka — przyp. tłum. Kup książkęPoleć książkę Scrum 39 się, i… pozwól, aby ta wiedza „naciągnęła”, niczym woda w filiżance herbaty. Rozmawiając z programistami, używam innego języka. Mówię im: „Zarezerwujcie trochę przestrzeni adre- sowej w pamięci swojego mózgu”. Nie próbuj jeszcze (podkreślam: nie rób tego!) łączyć Scruma z innymi narzędziami, które znasz. Jeszcze nie czas. Dopiero po osiągnięciu mistrzostwa w posługiwaniu się jednym narzędziem możesz nauczyć się używać go sprawnie w innym oto- czeniu (z innymi narzędziami). Teraz skup się przede wszystkim na Scrumie i odwołaj się do zdyscyplinowania, dając metodzie szansę, nawet (i zwłaszcza) wtedy, gdy stwierdzisz, że masz przed sobą zadanie trudne i wymagające. Zdziwisz się, stwierdzając, jak niewiele musisz zmienić w systemie Scruma i jak poważne zmiany zajdą w sposobie Twojego patrzenia na pracę. Być może stwierdzisz, że moja rada jest sprzeczna z pierwszą zasadą wartości Manifestu Agile, która brzmi: Ludzie i interakcje ponad procesami i narzędziami. Wręcz przeciwnie! To osoby i interakcje pozwalają Ci nauczyć się korzystania ze Scruma (lub innej zwinnej prak- tyki) i trzymanie się tej zasady ułatwia podjęcie świadomej decyzji na bazie własnych prak- tycznych wniosków. Scrum prowadzi najkrótsz(cid:200) (cid:258)cie(cid:285)k(cid:200), a nie t(cid:200) ustalon(cid:200) Najdłuższa ścieżka realizacji projektu jest określana mianem ścieżki krytycznej (lub tzw. rate- -limiting path). Tworzymy plan zakładający podążanie po ścieżce krytycznej, a jego realizacja zakłada wypełnienie kolejnych zadań, to znaczy dotarcie z punktu A do punktu B. W tym czasie na naszej drodze pojawiają się kłopoty i problemy: na przykład okazuje się, że na etapie pla- nowania zainteresowane strony nie zawsze wiedzą, czego dokładnie chcą, albo dochodzi do zmiany celów biznesowych w miarę rozwoju produktu, w reakcji na czynniki wewnętrzne i (lub) zewnętrzne, takie jak działania konkurencji, albo przychodzi nam radzić sobie z sytu- acjami, które często negatywnie wpływają na proces rozwoju produktu. Tego rodzaju zda- rzenia mają miejsce w niemal każdym projekcie, a nie tylko w projekcie programistycznym. W przypadku tradycyjnej metody planowania mimo pojawiających się problemów nadal jesteśmy zmuszeni pokonać drogę z punktu A do punktu B, godząc się przy tym na poniesienie ofiary: poświęcając jakość, funkcjonalność i rezygnując z zadowolenia klienta. Gdy w końcu docieramy do punktu B, sprawdzamy, co udało nam się uratować, a potem zaczynamy two- rzyć plan dotarcia do punktu C — do miejsca, które w międzyczasie okazało się prawdziwym celem, ale do którego nie mogliśmy udać się od razu, bo nie pozwalał na to nasz dotychcza- sowy plan (patrz rysunek 1.1). RYSUNEK 1.1. (cid:165)cie(cid:285)ka realizacji projektu w tradycyjnej metodzie planowania Kup książkęPoleć książkę 40 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe W ramach Scruma przygotowujemy się na wystąpienie zdarzeń takich jak to wspomnia- ne wyżej. Wiemy, że coś takiego się stanie. Zamiast tworzyć plan „doskonały”, który ma maksymalnie łagodzić konsekwencje zmian, przyjmujemy za pewnik, że przyjdzie nam za- akceptować zmianę. Dlatego tworzymy mechanizmy, które umożliwiają odpowiednią reak- cję już na etapie realizacji projektu, tak aby nie trzeba było koniecznie dotrzeć do B, tylko ru- szyć bezpośrednio w kierunku C. Ten cel jest realizowany poprzez zaplanowanie codziennych, cotygodniowych i comie- sięcznych spotkań z ludźmi na różnych poziomach hierarchii projektu (członkami zespołu, kadrą zarządzającą, klientami). To dzięki nim wiemy, że jesteśmy na dobrej drodze i budu- jemy właściwą funkcjonalność odpowiadającą oczekiwaniom. Zamiast liczyć na wszech- ogarniające definicje wymagań tworzone na etapie gromadzenia danych, informacje na te- mat oczekiwań zbieramy w trakcie realizacji projektu, korygując je i ulepszając na bieżąco. Dzięki temu projekt można dostosować do potrzeb biznesu i zewnętrznych warunków ryn- kowych, zapewniając sobie jak najkrótszą drogę do sukcesu (patrz rysunek 1.2). RYSUNEK 1.2. Planowanie (cid:258)cie(cid:285)ki w Scrumie Sukces nie oznacza braku kosztów. W modelu planu idealnego często mamy wrażenie (często nieprawdziwe), że znamy dokładną datę zakończenia projektu. Jakże trudno zrezy- gnować z tego uspokajającego oszustwa. W rzeczywistości przecież wszyscy wiemy, że albo dochodzi do opóźnień, albo do zmiany oczekiwanej funkcjonalności (niezależnie od tego, czy drobnej, czy poważnej), albo do pogorszenia się jakości produktu — a wszystko to w imię osiągnięcia określonej funkcjonalności w określonymi dniu. W końcu wszystkie te ofiary kosztują. Koszty liczone są w wartościach takich jak stracony czas, spadek jakości lub niepotrzebnie wydane pieniądze. W ramach Scruma nie obiecujemy dostarczenia określonego zestawu funkcji w określonym czasie. Zarówno data zakończenia projektu, jak i zestaw funkcji mogą się zmieniać. W przy- padku niektórych projektów obiecujemy dostarczenie w określonym terminie przybliżonej funkcjonalności. Robimy to poprzez wstępne blokowanie kosztów (kwoty, jaką klient może wydać na każdy sprint) i trzymanie się ustalonego harmonogramu (wskazując, kiedy projekt zo- stanie zakończony, w oparciu o liczbę planowanych sprintów). Następnie szacujemy, ile funkcji da się przygotować w ramach tych ograniczeń. Ponieważ w projektach Scruma zawsze najpierw wykonuje się prace o najwyższym priorytecie, funkcje, których nie udaje się wprowadzić przed końcem projektu, zawsze mają niską wartość i są prawdopodobnie mniej istotne dla powodzenia całego projektu. Kup książkęPoleć książkę Scrum 41 W przypadku projektów, w których zestaw funkcjonalności jest ważniejszy niż termin zakończenia prac, możemy zablokować zmienną funkcjonalności i pozwolić sobie na oscyla- cję daty (a tym samym kosztów). Tym samym obiecujemy dostarczenie produktu o określo- nej liczbie funkcji w przybliżonej dacie lub zakresie dat. W przypadku wystąpienia zmian (dodawania nowych funkcji lub modyfikacji istniejących funkcji w konsekwencji lepszego rozumienia zadań produktu) klient wie, że musi dokonać wyboru między dostarczeniem uzgodnionej funkcjonalności w ustalonym czasie lub wprowadzeniem do harmonogramu zmian, które mają uwzględnić czas potrzebny na osiągnięcie pożądanej funkcjonalności. Takie podejście oznacza duże odchylenie od tradycyjnego sposobu pracy, w którym funkcje definiowane są z góry, a następnie członków zespołów prosi się o oszacowanie czasu i ogranicze- nie kosztów niezbędnych do realizacji postawionych celów, często tylko po to, aby w toku prac jeszcze bardziej ograniczyć koszty i zmniejszyć czas przeznaczony na realizację projek- tu, bez zmian w zakresie zestawu funkcji. Na rysunku 1.3 przedstawiamy podsumowanie różnic pomiędzy dwoma podejściami. RYSUNEK 1.3. Ró(cid:285)nice metod planowania Warto zwrócić uwagę na konieczność ogromnej zmiany mentalności. Z tego powodu tak ważne jest zaufanie i zastosowanie wartości omówionych w tym rozdziale. Scrum pozwala wykrywa(cid:202) punkty zapalne Scrum unaocznia problemy, zarówno te, które dawno temu zostały zamiecione pod dywan i zapomniane, jak i te, o których istnieniu niektórzy ludzie nie wiedzieli. A zatem ukazuje także nowe punkty zapalne. Wykrywane problemy nie ograniczają się przy tym do programowa- nia i pracy zespołowej. Na przykład jedno z najczęściej słyszanych przeze mnie pytań brzmi: „Jak mamy płacić naszym ludziom?” lub „Jak długo należy wykonywać zestaw testów akceptacyj- nych?”. W tradycyjnym modelu deweloper może otrzymywać wynagrodzenie na podstawie kodu przekazanego na czas i spełniającego określone warunki jakościowe. Jak przekłada się to na in- terdyscyplinarny zespół, który nie jest oceniany na podstawie indywidualnych wskaźników dotyczących obszarów funkcjonalnych? Przyjęcie Scruma oznacza konieczność poradzenia sobie z wyzwaniami z kategorii norm organizacyjnych, zmuszając kierownictwo do dokona- nia trudnych wyborów: rozwiązania problemów lub ich zignorowania. Zaletą Scruma jest jednak to, że gdy te zachowania i schematy już zostaną, trudno będzie je zignorować. Kup książkęPoleć książkę 42 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe Scrum najlepiej sprawdza si(cid:218) w parze Scrum to metoda zarządzania projektem. Definiuje zasady, ale nie zawiera konkretnych rozwiązań technicznych, które pozwalają dostarczyć potencjalnie gotowe do działania opro- gramowanie co 2 – 4 tygodni. Do tego potrzebujesz prawdziwego księcia z bajki o Scrumie: programowania ekstremalnego, choćby pod postacią metodyki takiej jak XPrince. Podczas gdy Scrum i XP mają wiele wspólnego (np. XP ma grę planowania, w Scrumie prowadzi się spotkania planowania), XP zawiera kilka różnych metod, które pięknie uzupełniają Scrum — takich jak ciągła integracja, testy poprzedzające i programowanie w parach. Wdrożenie Scruma pomaga zespołom, a świetne efekty przynosi połączenie Scruma i XP. To nie znaczy, że powinieneś przejść do praktycznych działań w XP przed przygotowaniem solidnej bazy wiedzy o Scrumie — należy ostrożnie podchodzić do wprowadzenia zbyt wiel- kich modyfikacji w tym samym czasie. Gdy zespół zbierze więcej doświadczeń z rolami, ar- tefaktami i spotkaniami, będzie gotowy do rozpoczęcia integracji Scruma z praktykami XP. Uważaj jednak! Zwinne zarządzanie projektem podczas korzystania z kaskadowych praktyk inżynierii często tworzy niestabilne konstrukcje, powodując więcej problemów, niż przynosi korzyści z rozwiązań. Może to potrwać dzień, tydzień lub miesiąc, wszystko zależy od tole- rancji zespołu na zmiany. Jednak gdy już zaczniesz stosować XP, będziesz mieć do czynienia z prawdziwą magią. Oto cechy XP, które uważam za obowiązkowe w przypadku moich projektów: (cid:81) Zrównoważone tempo. Czterdziestogodzinny tydzień pracy przy stałej efektywności wynoszącej 85 (patrz rozdział 23., zatytułowany „Zrównoważone tempo”, gdzie znajdziesz więcej szczegółów). (cid:81) Współdzielenie kodu. Cały zespół pracuje na jednym i tym samym kodzie. Nie ma on jednego właściciela (patrz rozdział 21., „Gdy dochodzi do zderzenia kultur”). (cid:81) Programowanie w parach i TDD (ang. test-driven development). TDD nazywane jest: „Najpierw testy”. Chodzi o to, aby przed stworzeniem kodu napisać test, sprawdzający funkcjonalność. System bazuje na standardowym modelu kolorów: czerwonym (jeśli test zostanie zakończony niepowodzeniem), zielonym (wynik pozytywny). Następnie należy dokonać poprawek, dzięki którym kod będzie lepszy. Twoim celem zawsze powinien być test zielony (więcej informacji w rozdziale 19., zatytułowanym „Programowanie w parach — utrzymanie zaangażowania członków zespołu”). (cid:81) Ciągła integracja (ang. continuous integration, CI). Dzięki CI w każdym momencie wiemy, jak zachowuje się i w jakim stanie znajduje się baza kodu. Przeprowadzaj ewidencjonowanie kodu co najmniej raz dziennie. Dąż do tego, aby kończąc pracę każdego dnia, iść do domu ze świadomością, że kod ma sygnaturę „zielony”, podobnie jak każdy test TDD. (cid:81) Standardy kodowania. Często zapomina się o tym, że nieutrzymanie dobrych standardów kodowania sieje prawdziwe spustoszenie w kodzie, który ma być współdzielony, jako że każdy członek zespołu charakteryzuje się swoim własnym stylem. Opisz standardy, jakich oczekujesz, i udostępnij je — najlepiej powieś na ścianie, żeby przypominać wszystkim o ich istnieniu. Kup książkęPoleć książkę Scrum 43 (cid:81) Refaktoryzacja. Ponieważ ograniczamy przygotowanie skomplikowanych planów projektu i architektury przed rozpoczęciem pracy (nie rezygnujemy z nich całkowicie!), a system przygotowywany jest tak, aby spełnić konkretne, dzisiejsze potrzeby, kod musi zostać poddany refaktoryzacji. Bez niej zmieniające się wymagania mogą prowadzić do powstawania planów projektów znacznych rozmiarów, które niezbyt dobrze dostosowuje się do potrzeb biznesowych. „Potencjalnie gotowe” (do przekazania klientowi) — te dwa słowa często mogą wywoły- wać bóle głowy i, jak stwierdził na swoim blogu mój przyjaciel Chris Sterling, są one jednym z elementów Scruma, o których często się zapomina [STERLING]. Aby produkt naprawdę uzyskał funkcjonalność dającą firmie możliwość przekazania go klientom, zespoły muszą zmie- nić nie tylko proces zarządzania projektami, ale i sposób opracowywania oprogramowania. W przeciwnym razie wszystkie problemy, jakie zaakcentowałem w historii opisanej w tym rozdziale — słaba jakość kodu, brak czasu na testy oraz trudności z dostarczaniem produktu końcowego — pozostaną naszymi bolączkami i doprowadzą projekt do katastrofy. Zintegrowa- nie praktyk XP z metodami scrumowymi jest najlepszym znanym mi sposobem wprowa- dzenia prawdziwych i trwałych zmian. Kiedy Scrum jest dla mnie dobry? Ustaliliśmy, że wdrożenie Scruma jest zadaniem znacznie bardziej skomplikowanym, niż mogłoby się wydawać na pierwszy rzut oka. A czy w ogóle warto próbować? To zależy. Mam kilku przyjaciół, którzy pracują w branży budowlanej. Często proszę ich o pomoc w niewielkich domowych pracach. W ramach zadośćuczynienia funduję im kolację. Oni cie- szą się, że mogą mnie zobowiązać do jakiejś przysługi. Zauważyłem, że gdy któryś z nich po- jawia się w moim domu, zawsze ma ze sobą mnóstwo narzędzi. Spytałem kiedyś Joachima, czy nosi ze sobą standardowy zestaw, czy specjalnie przygotowuje narzędzia zależnie od zadania, nad jakim pracuje jego zespół. Odpowiedział, że zawsze ma ze sobą podstawowe sprzęty (me- trówkę, ołówek i okulary ochronne), ale to, czy zabiera jakieś inne narzędzia, niemal zawsze zależy od konkretnego zlecenia. Jeśli pracuje nad przygotowaniem szkieletu domu, przygo- towuje swój pas według potrzeb. Kiedy robi stolarkę lub układa płytki, używa innego zestawu. Przy czym narzędzia, dla których nie znalazło się miejsce na pasie, zawsze znajdują się nie- daleko (w samochodzie). Jak ma się to do Scruma? Dla mnie Scrum jest jednym z takich instrumentów wkładanych do pasa z narzędziami. Chcąc uchodzić za dobrego podwykonawcę, każdy powinien korzystać ze Scruma zawsze wtedy, gdy takie działanie jest właściwe. To wcale nie znaczy, że trzeba używać go non stop. Tak jak nie użyłbyś śrubokręta do wbicia gwoździa, tak nie używaj Scruma do realizacji pro- jektu, który nie wymaga zastosowania tego systemu. A zatem pojawia się pytanie: Kiedy po- winniśmy zastosować Scrum? Projekty programistyczne można podzielić na cztery kategorie: proste, skomplikowane, złożone i będące kompletną anarchią (patrz rysunek 1.4). System ten przyjął Ralph Stacey w swojej książce zatytułowanej Strategic Management and Organisational Dynamics [STACEY, wydanie 2.]. Na proste projekty składają się głównie wiadome: Podobne projekty wykonuje się regularnie i często, a to znaczy, że panuje powszechna zgoda w kwestii tego, co jest potrzebne, a użyta technologia jest dobrze rozumiana. Proste projekty są łatwe do wdrożenia i zrozumienia. Kup książkęPoleć książkę 44 Rozdzia(cid:239) 1 (cid:81) Scrum: proste, ale nie (cid:239)atwe RYSUNEK 1.4. Zale(cid:285)no(cid:258)ci pomi(cid:218)dzy wymaganiami, technologi(cid:200) i charakterem projektu Gdy jednak odchodzimy od prostych projektów, sprawy się trochę komplikują. Nasze wyma- gania, nasza technologia — lub zarówno jedno, jak i drugie — mogą nie okazać się tak stabilne, jak się spodziewaliśmy. Być może ludzie nie są pewni, jak ma wyglądać produkt końcowy. Może technologia jest nowa i jeszcze nikt jej nie sprawdził. W tym obszarze — w kategorii projektów skomplikowanych i złożonych — mamy do czynienia z dużą liczbą zmian. O wiele trudniej jest przewidzieć przebieg pracy oraz doprowadzić projekt do końca. Następnie, gdy pozostawiamy za sobą kategorię projektów definiowanych jako złożone i zmierzamy w stro- nę anarchii, stajemy przed prawdziwym wyzwaniem nieznanych wcześniej niewiadomych. Na tym etapie projektów firmy powinny skupić się na radzeniu sobie z problemami, które pojawiają się na drodze, a nie na budowaniu systemu. To wszystko oznacza, że jeśli Twój projekt znajduje się poza granicami obszaru „prosty projekt”, zmiany — wymagań i (lub) technologii — są najzwyczajniej w świecie nieuniknione. Mam praktykę w stosowaniu Scruma i XP do realizacji prostych projektów i w takich przy- padkach najczęściej stwierdzałem, że użycie tych metod jest przesadą. Jednak w miarę od- dalania się od tego, co uzgodnione i pewne, użycie Scruma i XP staje się coraz bardziej uza- sadnione, ponieważ metody te pozwalają łatwiej dostosować się do wymagań biznesowych, które z pewnością ulegną zmianie. Zmiana jest trudna W Scrumie wszystko sprowadza się do zmian. Są ludzie, którzy cieszą się na zmianę. Inni unikają jej jak ognia. Obie reakcje są zupełnie naturalne. Twórcy oprogramowania zwykle starają się unikać zmian. Nie postępujemy tak dlatego, że boimy się zmian, ale ponieważ przyzwyczaili- śmy się do przekazywania klientowi właściwego produktu już za pierwszym razem. W naszej głowie zmiana jest utożsamiana z błędami lub właściwościami, które przeoczyliśmy na etapie rozwoju produktu. Dlatego dla nas żądanie zmiany jest sugestią, że coś się nam nie udało. Często nie rozumiemy, że zmiany są nieuniknione. Nie możemy przewidzieć przyszłości, nie możemy się spodziewać, że z góry przewidzimy nagłe zmiany zachodzące na rynku lub pojawienie się najnowszej wersji oprogramowania wprowadzonego przez konkurenta. Aby odnieść sukces, Kup książkęPoleć książkę Scrum 45 musimy nauczyć się radzenia sobie ze zmianami. Scrum daje nam odpowiednie narz
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Scrum. Praktyczny przewodnik dla początkujących
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ą: