Agile PM Metodyki zwinne zarządzania projektami

Prezentacja na temat: "Agile PM Metodyki zwinne zarządzania projektami"— Zapis prezentacji:

1 Agile PM Metodyki zwinne zarządzania projektami
dr Grzegorz Jokiel

2 Manifest Agile Manifest Zwinnego Wytwarzania Oprogramowania
 Agile Manifesto, Manifesto for Agile Software Development 11-13 lutego 2001 r. Snowbird w USA programowanie iteracyjno-przyrostowe - alternatywa do tradycyjnych metod typu kaskadowego (waterfall)

3 Model kaskadowy Winston W. Royce 1970

4 Treść Manifestu Agile Ludzi i interakcje od procesów i narzędzi
Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić: Ludzi i interakcje od procesów i narzędzi Działające oprogramowanie od szczegółowej dokumentacji Współpracę z klientem od negocjacji umów Reagowanie na zmiany od realizacji założonego planu. Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

5 12 zasad Agile 1) Satysfakcja klienta - szybkość wytwarzania oprogramowania, 2) Gotowość na zmiany wymagań (nawet późne) 3) Działające oprogramowanie jest dostarczane okresowo - często 4) Bliska, codzienna współpraca biznes - deweloper 5) Samozarządzalność zespołów (wokół zaangażowanych ludzi) 6) Bezpośredni kontakt najlepszy sposób komunikacji w zespole i poza nim 7) Miarą postępu jest działające oprogramowanie 8) Zrównoważony rozwój – sponsorzy, deweloperzy, użytkownicy 9) Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu 10) Prostota - sztuka minimalizowania ilości koniecznej pracy 11) Najlepsze rozwiązania pochodzą od samoorganizujących się zespołów 12) SAMODOSKONALENIE w regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków

6 Scrum geneza Ogólne założenia Hirotaka Takeuchi i Ikujiro Noaka 1986 Definicja - Ken Schwabera i Jeff Sutherland 1996 Scrum: ramy postępowania (framework), dzięki którym ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości 19 stron

7 Idea Scrum lekki łatwy do zrozumienia trudny do opanowania
Nie jest procesem czy techniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, gdzie możliwe jest stosowanie różnego rodzaju procesów i technik. W obręb Scruma wchodzą: Zespoły Scrumowe (Scrum Teams) oraz związane z nimi role, zdarzenia, artefakty i reguły

8 Opis Scrum Praca w określonych przedziałach czasowych -przebiegach (sprint). Efektem przebiegu - dostarczenie użytkownikom kolejnej działającej wersji produktu. Zasada - zmiany wprowadzane w jednym przebiegu muszą być namacalne dla użytkowników (wartość funkcjonalną) Przebieg nie może trwać dłużej niż jeden miesiąc kalendarzowy

9 Wartości Scruma Zaangażowanie Odwaga Skupienie Otwartość Poszanowanie
Dla Zespołu Scrumowego - postępowanie zgodnie z nimi powoduje, że do życia powoływane są filary Scruma – przejrzystość, inspekcja i adaptacja, tworząc atmosferę zaufania pomiędzy wszystkimi współpracującymi osobami.

10 Filary Scruma 1) Przejrzystość - istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Standardy – terminy, język, nazewnictwo 2) Inspekcja – częsta (artefakty i postępy) – wykrywalność i korekta rozbieżności, odchyleń 3) Adaptacja – korekta jak najszybsza

11 4 formalne punkty przeprowadzania inspekcji i okazje do adaptacji (korekty) Zdarzenia w Scrumie:
1) Planowanie Sprintu - Co może zostać dostarczone w ramach Przyrostu (cel Sprintu)? W jaki sposób będzie realizowana praca? 2) Codzienny Scrum – 15 min inspekcja i prognozowanie prac. Co zrobiłem wczoraj? Co zrobię dzisiaj? Czy widzę jakiekolwiek przeszkody do osiągnięcie Celu Sprintu? 3) Przegląd Sprintu – Zespół Scrumowy + Interesariusze max 4 godz. dla mies. Sprintów. Prezentacja Przyrostu ma na celu uzyskanie informacji zwrotnej i pobudzenie współpracy 4) Retrospektywa Sprintu – inspekcja i usprawnienia max 3 godz dla mies. Sprintów

12 Artefakty Scruma Backlog Produktu - uporządkowana lista wszystkiego, co może być potrzebne w produkcie oraz jedyne źródło wymaganych zmian (zakres ale dynamiczny, zmienny otwarty) Backlog Sprintu - zbiór elementów Backlogu Produktu wybranych do Sprintu + plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu . Widoczny, tworzonym na bieżąco obraz pracy, jaką Zespół Deweloperski planuje wykonać w trakcie Sprintu Przyrost jest sumą wszystkich elementów Backlogu Produktu zakończonych podczas Sprintu i wszystkich Sprintów poprzednich

13 Zespół Scrumowy (Role)
1) Właściciel Produktu (Product Owner) odpowiedzialny za Rejestr produktu (Product Backlog) - wykaz wszystkich funkcjonalności pożądanych produktu 2) Zespół Deweloperski (Development Team) samoorganizujące się i międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi od osób nienależących do zespołu optymalizacja elastyczności, kreatywności i produktywności 3) Scrum Master - przywódca służebny Zespołu Scrumowego odpowiedzialny aby Scrum był rozumiany i stosowany

14 Charakterystyka Zespołów Deweloperskich
Samoorganizujące się. Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty Międzyfunkcjonalne posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu Scrum nie uznaje tytułów innych niż Deweloper od tej reguły nie ma wyjątków Scrum nie uznaje podzespołów w Zespole Deweloperskim, od tej reguły nie ma wyjątków Odpowiedzialność za wykonywaną pracę ponosi cały Zespół Deweloperski

15 Tablica Scrumowa

16 Wykres wypalania

17 Programowanie ekstremalne (eXtreme Programming, XP)
Geneza Kent Beck Howard G. „Ward” Cunningham 1987, 1994 Wiki i Portland Pattern Repository

18 Programowanie ekstremalne - idea
Metodyka ( i paradygmat) dla małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu bazującego na obserwacji innych projektów, które odniosły sukces. Podstawą ekstremalnego programowania jest synergia rozmaitych praktyk. Łączne użycie tych praktyk ma zapewniać wyeliminowanie niedogodności każdej z nich.

19 Zalecenie – założenia XP
Iteracyjność - krótkie, przyrostowe kroki programistyczne) - planuje tylko następną iterację. Odpowiada to zasadzie Open Source: "release early, release often" (wczesne i częste wydania) Nie projektować z góry Nie można przewidzieć, jaka architektura będzie najlepsza dla danego problemu. Dlatego należy ją tworzyć w miarę rozszerzania programu Ciągłe modyfikacje architektury Programowanie parami Stały kontakt z klientem

20 Inne metodyki zwinne Lean Software Development
Dynamic Systems Development Method Feature Driven Development Test-driven development

21 Technika MoSCoW M – MUST have this – musi mieć tę funkcjonalność
S – SHOULD have this if at all possible – jeśli jest to możliwe to powinno mieć tę funkcjonalność, C – COULD have this if it does not affect anything else – ta funkcjonalność jest potrzebna, pod warunkiem że nie wpłynie negatywnie na inne i efektywność systemu W – WON’T have this time but WOULD like in the future – nie tym razem, ale w przyszłości tę funkcjonalność można by dołożyć