Metodyki Zwinne Agile Project Management - SCRUM © Michał Turek, AGH Kraków

SCRUM - geneza Pomysłodawcy dla podstawowych założeń metodyki (1986) -Hirotaka Takeuchi i Ikujiro Nonaka, publikacja Formalna definicja (1995) - Ken Schwaber Ogólny zarys założeń: Dostarczanie kolejnych, coraz bardziej dopracowanych wyników projektu (iteracyjny przyrost zawartości), Włączanie się przyszłych użytkowników w proces wytwórczy, Samoorganizacja zespołu projektowego.

SCRUM Alliance Możliwość certyfikacji szkoleń SCRUM W Polsce certyfikat Certified Scrum Master można uzyskać po zdaniu egzaminu Egzamin dostępny od 1 października 2009, płatny. Certyfikat: 2 lata

Agile Manifesto - przypomnienie Korzyści i założenia: Ludzie i współpraca ponad proces i narzędzia; Działające oprogramowanie ponad wyczerpującą dokumentacją; Współpraca z klientem ponad negocjacją kontraktu; Reagowanie na zmiany ponad trzymaniem się planu. Priorytety: Osiągnięcie zadowolenia klienta poprzez wczesne i nieprzerwane dostarczanie mu oprogramowania wysokiej jakości.

SCRUM - Role osób w projekcie Scrum Master - szef zespołu SCRUM - odpowiedzialny za egzekwowanie praktyk i zasad Scrum, reprezentowanie zarządców wobec projektu, usuwanie przeszkód, reprezentuje zespół przed Product Owner Product Owner - właściciel produktu - odpowiedzialny za decyzje w sprawie cech funkcjonalnych produktu oraz zarządzanie priorytetami w ich implementacji Scrum Team - członkowie zespołu - każdy, kto należy do zespołu wykonującego czynności związane bezpośrednio z wytwarzaniem programowania (projektanci, programiści, testerzy, administratorzy baz danych, administratorzy systemu, graficy, etc). Pracują na równych prawach - z tym samym zespół jest tworem samoorganizującym się.

SCRUM - Podstawowe pojęcia Sprint - Product Backlog - wykaz prac produktu Sprint Backlog - wykaz prac sprintu Working Increment -

SCRUM - Daily Scrum Szybkie spotkania - Cele i marszruta spotkań: Spotkanie przeglądu sprintu - (sprint review meeting) Spotkanie planowania sprintu - (sprint planning meeting) Cele i marszruta spotkań: Większa kontrola nad projektem i wcześniejsze wykrywanie problemów Skalowalność rozległości zespołu Narzędzia (wykresy, wykazy) dla menedżera projektu (o nich potem)

Product Backlog Hierarchia zaległości produktu: Rola właściciela produktu (Product Owner) Konieczne przejście z hierarchizacji na przypadki użycia UML, Wykorzystanie informacji zwrotnej od końcowego użytkownika oraz nowych informacji biznesowych i technicznych przy tworzeniu zaległości

Sprint Planning Meeting Planowanie sprintu: osoby obecne: plan spotkania: negocjacje: Cel sprintu (sprint goal)powinien być mierzalny, dzięki czemu można łatwo określić, kiedy został osiągnięty.

Stand-Up meetnig W metodyce SCRUM spotkanie Stand-Up także występuje, tutaj nazywamy je scrumem powszednim.

SCRUM - Sprint Review Meeting Spotkanie dokonujące przeglądu sprintu, odbywające się pod jego koniec Prezentacja przyrostu produktu

Sprint - postępowanie Właściciel produktu określa początkowy wykaz prac produktu, plan edycji produktu, budżet itp. Zespół, wraz z szefem Scrum i właścicielem produktu, decydują o czasie trwania iteracji (i tego się trzymają) Planowana jest pierwsza iteracja: określa się wykaz prac sprintu, cel sprintu, zadania - po czym każdy udaje się do swoich zadań

SCRUM - mapa sprintu Daily Scrum Product version Sprint backlog 24 h n dni Product version Sprint backlog Product version Working Increment Product backlog

SCRUM - Release Planning Planowanie liczby wersji: Planowanie liczby sprintów: Określanie wielkości przyrostów produktu: Tworzenie modeli i dokumentacji projektowych do wersji

SCRUM - Spotkania Sprint Retrospective Planowanie udoskonaleń i analiza niepowodzeń

SCRUM - Estimating the Product Backlog Określanie wielkości Project Backlog Określanie zdolności do dostarczenia produktu dla Scrum Team

SCRUM - możliwości potencjalne w realizacji Potentially Shippable Product Incremement - Modele i dokumentacja: Sprintu hartujący: Sprint wzmacniający:

SCRUM - Task Board Tablice zadań dla sprintu: Story, To do, In Process, To Verify, Done

SCRUM - Sprint Burndown Chart „Wykres malejący” Metody graficzne w szacowaniu przebiegu prac w ramach sprintu, Korekty rozmiaru zadania podczas trwania sprintu, Szacowanie wymiarów godzinowych dla zadań w ramach sprintu

SCRUM - Release Burndown Chart Metody graficzne planowania liczby sprintów Punkty abstrakcyjne pracy: godzina, dzień, metapunkt Dni idealne -

SCRUM a XP Diametralne różnice na polu zastosowań: Scrum dotyczy strony zarządzającej, pozostawiając rozwiązania inżynierskie (projektowanie, kodowanie, zarządzanie konfiguracją, testowanie) samoorganizującemu się zespołowi XP dotyczy posunięć inżynierskich i nie dostarcza żadnych specyficznych narzędzi do zarządzania projektem. W praktyce metody często stosuje się razem, Metody (idące w parze) stosuje się jako podstawę do rozwijania kolejnych metodologii

The Agile Manifesto (I) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The Agile Manifesto (II) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.

The Agile Manifesto (III) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The Agile Manifesto (IV) Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The Agile Manifesto (V) Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential.

The Agile Manifesto (VI) The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.