1. Co to jest
1.1. Prosty i lekki proces wytwarzania
1.2. Organizacja czasu oparta o stałe, niezmienne kwanty czasu
1.2.1. stałe okresy czasu przeznaczone na stworzenie oprogramowania - Sprint
1.2.2. ramy czasowe chronią zespół przed ingerencją z zewnątrz
1.2.3. długość sprintu wybierana na podstawie jak często jest potrzebna zmiana
1.3. Jasno zdefiniowane role, i obszary odpowiedzialności
1.4. Przejrzyste narzędzia/artefakty
1.5. Proste i spójne reguły
1.6. Tworzy pole dla zastosowania praktyk lean
1.7. Podpory SCRUM
1.7.1. Proces empiryczny
1.7.1.1. Planowanie na początku każdego sprintu
1.7.1.1.1. Zwiększa kontakt z rzeczywistością
1.7.1.2. Reakcja na zmiany
1.7.1.3. Możliwość rewizji planu w trakcie wykonania
1.7.2. Iteracyjność
1.7.3. interdyscyplinarne - samoorganizujące się zespoły
1.7.4. Kontrola przez:
1.7.4.1. przejrzystość
1.7.4.1.1. na tym opiera sie kontrola
1.7.4.1.2. burn down/up
1.7.4.2. sprawdzanie i dostosowywanie
1.7.4.2.1. jako metoda osiągnięcia celu
2. Role - Wszystkie 3 należą do Scrum Team
2.1. Product Owner
2.1.1. Wie co robić
2.1.1.1. Skąd, to już poza scrumem
2.1.2. zarządza backlogiem
2.1.2.1. pilnuje priorytetów
2.1.2.2. w ten sposób pośrednio zarządza pracą zespołu
2.1.3. Zajmuje się zarządzaniem ryzykiem
2.1.3.1. minimalizuje niespodzianki
2.2. Zespół(Team)
2.2.1. Wie jak robić
2.2.2. zespół musi zawierać wszelkie kompetencje potrzebne do stworzenia systemu
2.2.3. Idealnie 7 osób
2.2.3.1. Jeżeli więcej, zwykle zespół naturalnie dzieli się na podzespoły
2.3. Scrum Master
2.3.1. Pilnuje koszerności procesu
2.3.2. Uczy jak lepiej wykonywać swoje role w SCRUMie
2.3.3. Likwiduje przeszkody/impedimenty
3. Artefakt
3.1. Etap(Inkrement)
3.2. Backlog Produktu
3.2.1. Pozwala na reagowanie na zmiany
3.2.2. Atrybuty
3.2.2.1. Untitled
3.2.2.2. Untitled
3.2.2.3. Wartość
3.2.3. Relacje
3.2.3.1. Sprint
3.2.3.2. Specyfikacja
3.2.3.2.1. musi być zrozumiała dla obu stron
3.2.3.3. Funkcja
3.2.3.4. Zadanie
3.2.3.5. Historia użytkownika
3.2.3.5.1. Jako użytkownik robię x
3.2.3.5.2. w taki i taki sposób
3.2.3.5.3. po to żeby zrobić y
3.2.4. Reguły
3.2.4.1. Wszystko na backlog!
3.2.4.2. Nie wszystko musi być zrobione
3.2.4.3. Jeżeli coś jest ciągle na backlogu, ale nigdy nie zostaje zrobione
3.2.4.3.1. To sa to prawdopodobnie "fusy", które nie są potrzebne
3.2.4.4. Szacowania to szacowania
3.2.4.4.1. nie konkretne zobowiazania
3.2.4.5. Product Owner rządzi!
3.3. Sprint Backlog
4. Różne
4.1. Proces wytwarzania
4.1.1. Idea
4.1.1.1. Planowanie
4.1.1.1.1. wytworzenie
4.2. Inne frameworki
4.2.1. Six sigma
4.2.1.1. Wspomaganie managera projektu
5. Zdarzenia
5.1. Sprint
5.1.1. Przebiega w izolacji
5.1.2. dowolne środki prowadzą do celu
5.1.3. Pewien rodzaj umowy
5.1.3.1. Zespół zobowiązuje się do dostarczenia częsci oprogramowania
5.1.3.2. Klient ufa zespołowi że dostarczy oprogramowanie
5.2. Planowanie sprintu
5.3. Codzienny scrum
5.3.1. Liczy się komunikacja zespołu
5.3.2. Wymusza komunikację
5.3.3. Likwiduje niewiadome
5.3.3.1. Trzeba się przyznać że nie było postępów
5.3.4. Nie wymaga narzędzi
5.3.4.1. co upraszcza komunikację
5.3.4.2. i nie daje wrażenia że jest to do celów raportowych
5.4. Przegląd sprintu
5.4.1. Zespół, Product Owner, i inni przyglądają się wynikom sprintu
5.4.2. moment na sprawdzenie i dostosowanie procesu
5.4.3. Wyniki
5.4.3.1. Zrzucenie na backlog nieskończonych itemów
5.4.3.2. Zmiana zespołu
5.4.3.3. Decyzja o wdrożeniu
5.4.3.4. Reorganizacja backlogu
5.4.3.5. Zakończenie projektu
5.5. Retrospekcja/Retrospektywa
6. Nie obejmuje
6.1. Praktyk inżynierskich
6.2. Kompetencji ludzi
6.3. Wydawania (deploymentu) produktu
6.3.1. Każdy Sprint powinien kończyć się projektem który można wypuścić
6.3.1.1. ale nie koniecznie należy go wypuszczać do klienta