Doskonalenie Scruma. Przewodnik dla praktyków. O wyzwaniach, korzyściach i zwinnych zespołach

Spis treści ebooka

 

Przedmowa Kena Schwabera 11

 

Przedmowa Dave'a Westa 13

Wstęp 15

Podziękowania 19

O autorach 21

Rozdział 1. Ciągłe doskonalenie Twoich praktyk scrumowych 23

• Skoncentruj się na siedmiu kluczowych obszarach, aby poprawić swoje praktyki scrumowe 24
  • Zwinny sposób myślenia 24
  • Empiryzm to serce Scruma 24
  • Opanowanie Scruma oznacza usprawnienie pracy zespołowej 25
  • Każdy zespół scrumowy musi skupić się na poprawianiu wartości, jaką dostarcza jego produkt 26
  • Każdy mocny zespół ma wyróżniającą się tożsamość 27
  • Aby się poprawić, zespoły muszą usprawniać swoje procesy 27
  • Organizacja może mieć duży wpływ na wyniki zespołu 28
• Rozwijanie Scruma wymaga od zespołu szlifowania innych zdolności 28
  • Umiejętności nauczania 29
  • Umiejętności facylitatorskie 30
  • Umiejętności trenerskie 30
  • Znakomity poziom wiedzy technicznej 31
  • Służebne przywództwo 31
• Proces ciągłego doskonalenia 33
  • Co stanowi największą niedogodność? 33
  • Analiza przyczyn źródłowych 35
  • Eksperymentowanie z różnymi podejściami 38
  • Sukces czy porażka? 39
• Podsumowanie 40
• Wezwanie do działania 41

Rozdział 2. Tworzenie podstaw silnego zespołu 43

• Tworzenie tożsamości zespołu 43
• Kto jest dobrym członkiem zespołu? 44
• Kto powinien znaleźć się w zespole scrumowym? 46
  • Zespoły deweloperskie muszą wiedzieć o czymś więcej niż tylko o rozwoju 47
• Jak zespoły scrumowe tworzą porozumienia robocze? 48
• Jak wygląda samoorganizacja? 50
  • Wspólne cele 51
  • Jasny zakres odpowiedzialności 52
  • Granice 52
• W jaki sposób współpracują zespoły scrumowe? 54
• W jaki sposób zespoły czynią postępy? 58
  • Charakterystyka zespołów produktywnych i zdolnych do adaptacji 62
• Podsumowanie 63
• Wezwanie do działania 64

Rozdział 3. Dostarczanie ukończonych przyrostów produktu 65

• Jaka jest definicja ukończenia? 66
  • Korzyści wynikające z definicji ukończenia 67
  • Jak stworzyć definicję ukończenia? 68
• Używanie celów sprintu, żeby dotrzeć do etapu ukończenia 70
  • Tworzenie dobrych celów sprintu 70
  • Użycie celów sprintu do przeprowadzenia efektywnego codziennego Scruma 72
• Wcześniejsze ukończenie prac nad elementami rejestru produktu 73
• Ograniczanie pracy w toku 76
  • Mierzenie i analizowanie przepływu 77
• Budowanie z zachowaniem jakości od samego początku 79
  • Automatyzacja i ukończenie 80
  • DevOps 82
  • Przegląd kodu 82
• Metryki jakości 83
• Walka z długiem technologicznym 84
  • Zapewnienie transparentności długu technologicznego 85
  • Uwidocznienie "spłaty" długu technologicznego 86
• Podsumowanie 87
• Wezwanie do działania 88

Rozdział 4. Optymalizacja dostarczanej wartości 89

• Czym jest wartość? 89
• Dostarczanie w szybszym tempie to dobry początek, ale to nie wystarcza 90
• Wartość produktu i zespół scrumowy 91
• Używanie wizji produktu do ożywienia celu, koncentracji i tożsamości zespołu 93
• Mierzenie wartości 94
  • Skupienie elementów rejestru produktów na wynikach użytkowników 96
  • Poprawa wartości dostarczonej podczas sprintu 100
• Inspekcja i adaptacja bazująca na informacjach zwrotnych 101
  • Uczenie się jako wartość 101
  • Efektywne przeglądy sprintu uwzględniają zrealizowaną wartość 101
  • Gromadzenie informacji interesariuszy 102
• Podsumowanie 103
• Wezwanie do działania 104

Rozdział 5. Optymalizacja planowania 105

• Planowanie ukierunkowane na produkt 106
  • Miara sukcesu 107
  • Planowanie empiryczne 107
• Dostosowywanie 109
• Doskonalenie rejestru produktu 111
  • Doskonalenie działającego produktu z minimum funkcjonalności 111
  • Szacowanie 113
  • Podział elementów rejestru produktu w celu skupienia się na wartościowych wynikach 115
• Planowanie sprintu 115
  • Ile pracy można ukończyć w ramach sprintu? 116
  • Ile czasu należy poświęcić na doskonalenie tego sprintu? 118
• Co jeszcze pozostaje do doskonalenia? 119
• Planowanie wydania wersji produktu 119
  • Jak duży powinien być zakres wydania produktu? 120
  • Jaki jest najmniejszy zakres wydania produktu? 120
• Podsumowanie 121
• Wezwanie do działania 121

Rozdział 6. Wspieranie zespołów scrumowych w procesie tworzenia i doskonalenia 123

• Użycie retrospektywy sprintu w celu odkrycia obszarów do poprawy 124
• Identyfikowanie i usuwanie przeszkód 126
  • Śledzenie przeszkód i kwantyfikacja wpływów 129
  • Zwalczanie przeszkód 131
• Rozwijanie zdolności indywidualnych i zespołowych 132
  • Znajdź czas na ciągłe uczenie się i rozwój 133
  • Wykorzystuj wiedzę i doświadczenie dostępne wewnątrz organizacji 134
• Bycie Scrum masterem, który bierze odpowiedzialność 135
  • Miara sukcesu Scrum mastera 136
  • Skuteczni Scrum masterzy zmieniają swoje podejście w zależności od kontekstu 138
• Podsumowanie 142
• Wezwanie do działania 142

Rozdział 7. Wykorzystanie organizacji do doskonalenia 145

• Organizacje muszą ewoluować, aby osiągnąć sukces 145
• Rozwijanie ludzi i zespołów 146
  • Skutki oceny poziomu pracy i wynagrodzenia 146
  • Indywidualne ścieżki kariery 147
  • Strategie sourcingowe i wpływ na zespół 148
  • Zespoły rozproszone 150
• Pozytywne postrzeganie transparentności 151
• Kultura odpowiedzialności w miejsce kultury obwiniania 152
• Odpuszczanie (złudzenia) sprawowania kontroli 152
• Prawdziwa moc żelaznego trójkąta 153
• Finansowanie inicjatyw 155
  • Szacowanie w oparciu o zakres 155
  • Budżetowanie iteracyjne i przyrostowe 156
• Bycie zwinnym nie jest celem 158
• Sprawdź, zanim przejdziesz do skalowania 158
• Podsumowanie 159
• Wezwanie do działania 160

Rozdział 8. Wnioski oraz dalsze kroki 161

• Biznesowa zwinność wymaga nowatorskich rozwiązań 161
• Wezwanie do działania 164

Dodatek A. Samodzielna ewaluacja pozwalająca na określenie Twojego poziomu zaawansowania 165

• Biznesowa zwinność 165
• Efektywny empiryzm z wykorzystaniem Scruma 166
• Efektywna praca zespołowa z użyciem Scruma 170
• Analiza odpowiedzi udzielonych w ramach ewaluacji 171

Dodatek B. Rozpowszechnione i zarazem błędne przekonania na temat Scruma 172

• Scrum nie jest metodyką ani procesem zarządzania 172
  • Scrum nie jest panaceum ani sposobem na przyspieszenie pracy deweloperów 173
  • Właściciel produktu nie skupia swojej uwagi przede wszystkim na dokumentowaniu wymogów 174
  • Rejestr produktu nie stanowi zwinnej wersji tradycyjnego dokumentu z wymogami 174
  • Rejestr produktu nie jest listą wszystkich wniosków 174
  • Codzienny Scrum nie jest spotkaniem, na którym omawia się aktualny stan rzeczy 175
  • Sprint może zakończyć się sukcesem nawet wtedy, gdy nie udało się ukończyć wszystkich zaplanowanych elementów rejestru sprintu 175
  • Scrum master nie jest odpowiedzialny za monitorowanie pracy zespołu deweloperskiego 176
  • Przegląd sprintu to nie protokół odbioru 176
  • Nie trzeba się długo przygotowywać do rozpoczęcia pracy w sprintach 176

pokaż cały spis treści

ukryj recenzje