100505111

Przedmowa

ęp

Podziękowania

Jak czytać tę książkę?

Rozdział 1. W tym szaleństwie jest metoda

1.1. (R)ewolucje

Rozdział 3.

3.2. 12 Zasad Agile

ł 4. Rodzina Metod Agile

4.1. Lean Software Development

4.1. 4.1.1. Historia powstania

4.1. 4.1.2. Zasady Lean

4.1. 4.1.3. W. Edwards Deming

4.1. 4.1.4. PDCA – Cykl Deminga

4.2. Kanban

4.3. Programowanie Ekstremalne

4.1. 4.3.1. Role XP

4.1. 4.3.2. Wartości XP

4.1. 4.3.3. Praktyki XP

4.1. 4.3.4. Cykl XP

4.1. 4.4.1. Pięć Procesów FDD

4.1. 4.4.2. Praktyki FDD

4.1. 4.4.3. Diagram kumulacyjnego przepływu

4.1. 4.4.4. Parking Lot Diagram

4.5. Dynamic Systems Development Method

4.1. 4.5.1. Zasady DSDM .

4.1. 4.5.2. Cykl Życia Projektu

4.1. 4.5.3. Role DSDM

4.6. Crystal

4.1. 4.6.1. Cele Crystal

4.1. 4.6.2. Właściwości Crystal

4.1. 4.6.3. Związek Crystal z XP

4.7. Wpływy i przenikanie metod zwinnych

Do przemyślenia

Rozdział 5. Scrum

5.1. Pochodzenie i podstawowe mechanizmy

4.1. 5.1.1. Nowa gra wytwarzania nowych produktów

4.1. 5.1.2. Mechanizmy Scrum .

4.1. 5.1.3. Rozwój Scrum i Organizacje Certyfikujące

5.2. Framework Scrum

4.1. 5.2.1. Filary Scrum

4.1. 5.2.2. Role

4.1. 5.2.3. Artefakty

4.1. 5.2.4. Wydarzenia

4.1. 5.2.5. Zasady

Do przemyślenia

Rozdział 6. O czym Scrum Guide nie powiedział, a chcia

byś to wiedzie

6.1. Wartości Scrum

6.2. Wykresy Spalania

4.1. 6.2.1. Wykres Spalania Sprintu

4.1. 6.2.2. Wykres Spalania Wydania

4.1. 6.2.3. Kiedy reagować, a kiedy nie?

6.3. Sprint Zero

6.4. Scrum of Scrums

6.5. Modyfikacje Scrum

6.6. Oznaki problemów

6.7. Usłużny Lider

6.8. Świnie i kurczaki

6.9. Gdzie jest Menedżer Projektu?

6.10. Scrum Board

6.11. Jak przeprowadzić Retrospekcję Sprintu

4.1. 6.11.1. Rozpoczęcie.

4.1. 6.11.2. Zebranie informacji

4.1. 6.11.3. Wyciągnięcie wniosków

4.1. 6.11.4. Ewaluacja poprzedniej retrospekcji

4.1. 6.11.5. Decyzje i planowanie działań

4.1. 6.11.6. Zakończenie Retrospekcji

6.12. Pielęgnacja Rejestru Produktu .

4.1. 6.12.1. DEEP

4.1. 6.12.2. Kiedy pielęgnować?

6.13. Co z defektami?

6.14. Wyłaniająca się architektura

Do przemyślenia

Rozdział 7. Problemy z wymaganiami

Do przemyślenia

Rozdział 8. Wizja

8.1. Koleżeńska Jednomyślność

8.2. Opakowanie Produktu

8.3. Wypowiedź w Windzie

8.4. Przyszły Komunikat Prasowy

Do przemyślenia

Rozdział 9. Persony

9.1. Budowa Persony

9.2. Typy Person

Do przemyślenia

Rozdział 10. User Story

10.1. Budowa User Story

10.2. Porównanie z IEEE 830

10.3. Wymagania Techniczne

10.4. Epiki i Tematy

4.1. 10.4.1. Epik

4.1. 10.4.2. Temat

10.5. Dobra User Story - Model INVEST

10.6. Góra Lodowa Rejestru Produktu

10.7. Grupowanie

10.8. Metody podzia

4.1. 10.8.1. Role

4.1. 10.8.2. Kroki Workflow

4.1. 10.8.3. Warianty Reguł Biznesowych

4.1. 10.8.4. Główny Wysiłek

4.1. 10.8.5. Prosta – Złożona

4.1. 10.8.6. Różne Typy Danych

4.1. 10.8.7. Różne Metody Wprowadzania Danych/Platformy

4.1. 10.8.8. Różnice w Wydajności

4.1. 10.8.9. Operacje CRUD

4.1. 10.8.10. Wyciągnij Kolec

4.1. 10.8.11. Wystarczająco Dobre/Piękne

Do przemyślenia

Rozdział 11. Szacowanie

11.1. Aspekty Szacowania

4.1. 11.1.1. Unikalność

4.1. 11.1.2. Psychologia

4.1. 11.1.3. Jednostki

4.1. 11.1.4. Precyzja

11.2. Tradycyjne Metody Szacowania

4.1. 11.2.1. COCOMO II, czyli COnstructive COst MOdel.

4.1. 11.2.2. Analiza Punktów Funkcyjnych

4.1. 11.2.3. Wideband Delphi

11.3. Szacowanie w Agile

4.1. 11.3.1. Jak zacząć?

4.1. 11.3.2. Planning Poker®

4.1. 11.3.3. Proste porównanie

4.1. 11.3.4. Affinity

4.1. 11.3.5. Rozmiary koszulek

4.1. 11.3.6. Ponowne szacowanie

4.1. 11.3.7. Na co zwracać uwagę

Do przemyślenia

Rozdział 12. Ustalanie priorytetów

12.1. MoSCoW

12.2. Monopol Money

12.3. 100-Point Method

12.4. Planning Poker dla Wartości

12.5. Analiza Kano

12.6. Relatywne Ważenie

12.7. Selekcja Tematów.

12.8. Punktowanie Tematów

12.9. Priorytety Finansowe

12.10. Mapowanie Story

Do przemyślenia

Rozdział 13. Planowanie

13.1. Planowanie Tradycyjne

13.2. Planowanie w Agile

13.2. 13.2.1. Planowanie Wydania

13.2. 13.2.2. Planowanie Iteracji

Do przemyślenia

Rozdział 14. Agile Coaching

14.1. Dlaczego coaching jest potrzebny?

14.2. Czym jest Coaching?

14.3. Agile Coaching

Do przemyślenia

Rozdział 15. Kontrakty w Agile

15.1. Stopniowany Kontrakt z Ustaloną Cen

15.2. Pakiety Pracy o Ustalonej Cenie

15.3. Money for Nothing and Change for Free

Do przemyślenia

Rozdział 16. Wprowadzanie Agile

16.1. Trochę statystyk

16.2. Kroki wprowadzania zmiany

16.3. Przebieg zmiany

Do przemyślenia

Rozdział 17. Skalowanie Agile

17.1. Co może oznaczać Skalowanie Agile i do czego jest potrzebne?

17.2. Co wiąże się ze Skalowaniem Agile?

17.3. Podstawowe zasady skalowania Scrum

17.4. Large-Scale Scrum – LeSS

17.4. 17.4.1. Podstawy i ogólne założenia

17.4. 17.4.2. LeSS Large

17.4. 17.4.3. LeSS Huge

17.5. Nexus

17.5. 17.5.1. Podstawy i ogólne założenia

17.5. 17.5.2. Działanie

17.6. Scrum at Scale

17.6. 17.6.1. Podstawy i ogólne założenia

17.7. Scaled Agile Framework

17.7. 17.7.1. Podstawy i ogólne zał

17.7. 17.7.2. Poziom Zespołu

17.7. 17.7.3. Poziom Programu

17.7. 17.7.4. Poziom Portfolio

17.8. Model Spotify

17.8. 17.8.1. Podstawy i ogólne zał

17.8. 17.8.2. Organizacja zespołów .

enia

enia

17.8. 17.8.3. Ekosystem wspierający struktur

Do przemyślenia

Scrum w Pigułce

4.1.1.

Historia powstania

Wskutek wydarzeń historycznych nastąpił pewien zbieg okoliczności, który, jak to zwykle bywa, dla jednych osób stanowił źródło frustracji, a dla innych okazję do wykorzystania. W trakcie drugiej wojny światowej Japonia walczyła ze Stanami Zjednoczonymi Ameryki i w końcu tę wojnę przegrała. Warunki niedoboru surowców spowodowane zniszczeniami wojennymi stworzyły środowisko, w którym stosowanie popularnej w tym czasie produkcji masowej było niemożliwe. Jak zatem zbudować niewielką liczbę samochodów, zachowuj ą c równocze ś nie ich nisk ą cen ę ? Przed takim dylematem stan ęł a w 1940 roku mała firma Toyota. Odpowiedź znalazł Taiichi Ohno, uznawany dzisiaj za ojca Toyota Production System. Jeżeli firmy nie stać na produkowanie samochodów na zapas i przechowywanie części w magazynie, należy zbudować system, który zakłada, że produkt zostanie dostarczony do klienta najszybciej jak to jest możliwe od momentu z ł o ż enia zamówienia. G ł ównym nap ę dem tego podej ś cia jest eliminacja straty, czyli wszystkich elementów procesu, które nie przyczyniaj ą si ę do wytworzenia produktu, a tym samym nie dostarczają wartości.

W latach dziewięćdziesiątych ubiegłego wieku praktyki Toyoty zostały uznane za standard wiodący i wdrożone w wielu fabrykach. TPS wpłynął także na powstanie takich dziedzin, jak Lean Software Development i Lean Management.

4.1.2.

Zasady Lean

Podstaw ą Lean s ą zasady (ang. Lean Principles ), które Mary Poppendieck odnios ł a do środowiska wytwarzania oprogramowania. Przyjrzyjmy się im po kolei.

Eliminuj stratę (ang. Eliminate Waste)

Proces wytwarzania produktu powinien jak najszybciej dostarczy ć klientowi warto ść Wszystko, co z punktu widzenia klienta przyczynia się do dostarczenia warto ś ci, jest również wartościowe z punktu widzenia Lean. I odwrotnie – wszystko, co nie przynosi wartości, jest stratą (ang. waste), czy – jak to trafniej można określić w języku polskim – marnotrawstwem. Eliminuj ą c elementy przynosz ą ce straty, podnosimy efektywno ść naszych praktyk.

W nomenklaturze Toyota Production System strata jest okre ś lona japo ń skim s ł owem muda i stanowi jeden z trzech typów zbędnej wariacji w systemie. Dwa pozostałe to mura, czyli nieregularność, i muri, czyli nadmierne obciążenie pracą. Szukanie i eliminowanie straty jest zadaniem ciągłym. Podstawowym narzędziem służącym do określania efektywności procesu i szukania w nim strat jest Mapowanie Strumienia Wartości (ang. Value Stream Mapping).

Tabela 1. Straty w produkcji i odpowiedniki tych strat w wytwarzaniu oprogramowania

Strata w produkcjiStrata w wytwarzaniu oprogramowania

Zapasy (ang. Inventory)Częściowo wykonana praca (ang. Partially Done Work)

Zbędne przetwarzanie (ang. Extra Processing)Dodatkowe procesy (ang. Extra Processes)

Nadprodukcja (ang. Overproduction)Dodatkowe funkcjonalności (ang. Extra Features)

Transport (ang. Transportation)Przełączanie zadań (ang. Task Switching)

Czekanie (ang. Waiting)Czekanie (ang. Waiting)

Ruch (ang. Motion)Ruch (ang. Motion)

Błędy (ang. Defects)Błędy (ang. Defects)

Szukanie strat nale ż y zacz ąć od sprawdzenia listy siedmiu tradycyjnie wymienianych strat procesu produkcji oraz straty dodanej po wprowadzeniu Lean Management do sektora usług.

1. Częściowo Wykonana Praca Częściowo wykonana praca deweloperska zwykle jest zbędna, a ponadto stwarza niepotrzebne ryzyko. Jeżeli kod nie został zintegrowany i przetestowany pod kątem zgodności ze standardami, to może być on źródłem błędów i komplikować dalszy rozwój produktu. Pamiętajmy, że systemy informatyczne to ciągle rozwijane, skomplikowane środowiska pełne zależności, dlatego sytuacje, w których złe praktyki określonego modułu spowodują problemy tylko w nim, w praktyce nie występują.

Jeżeli nie zdążyliśmy wykonać zaplanowanych zadań, a praca nie zostanie dokończona w kolejnej iteracji, co zresztą nadal jest złą praktyką, to ktoś wyrzucił pieniądze w błoto.

Żeby uniknąć takich sytuacji, należy zwrócić uwagę na praktyki planowania i ustalania priorytetów. Należy również pilnować dyscypliny pracy w iteracjach, ponieważ lepiej nie zacząć pracy wcale, niż zostać z częściowo wykonaną pracą na koniec iteracji.

2. Dodatkowe procesy

Klasycznym przykładem w tej kategorii jest tworzenie niezliczonych prezentacji i arkuszy kalkulacyjnych z zestawieniami i raportami, których nikt nie czyta. Przygotowanie dokumentacji tylko po to, aby klient zaakceptował system, czy tworzenie i przypisywanie zada ń w komputerowym systemie zarz ą dzania projektem, ż eby oficjalnie zatwierdzi ć kolejny etap, to strata.

Je ś li to tylko mo ż liwe, nale ż y redukowa ć dokumentacj ę do rozmiarów strony A4 i postaci tabeli lub mapy myśli. Zamiast dokumentacji wymagań i przypadków użycia można stworzyć automatyczne testy akceptacyjne, które staną się żyjącą dokumentacją