Agile PM Metodyki zwinne zarządzania projektami

Slides:



Advertisements
Podobne prezentacje
Agile w praktyce, czyli jak to robimy naprawdę
Advertisements

Kamil Markuszewski Mateusz Mikłuszka
Programowanie Ekstemalne
Projektowanie w cyklu życia oprogramowania
Opis metodyki i procesu produkcji oprogramowania
Role w zespole projektowym
Metodyki prowadzenia projektów - SCRUM
EXtreme Programming » Magdalena Tchorzewska.
Instytucjonalne aspekty współpracy Budowanie kompetencji do współpracy między-samorządowej i międzysektorowej jako narzędzi rozwoju lokalnego i regionalnego.
Na Etapie Inżynierii Wymagań
Lekkie metodyki programowania: Szansa czy zagrożenie?
Zwinne metodyki programowania Copyright, 2006 © Jerzy R. Nawrocki Inżynieria oprogramowania.
J. Nawrocki, Inżynieria oprog. Plan wykładu Praktyki XP Wcześniejsze badania Personal Software Process eXtremme Programming Opis eksperymentu WynikiPodsumowanie.
Dyscyplina i zwinność w projektach informatycznych
Anna Paszkowska-Rogacz
SWOBODNE METODYKI PROJEKTOWANIA SI
Agile Programming a jakość
Wymagania jakości w Agile Programming
Metodyki Lekkie Agile Methodologies
Rational Unified Process
Dalsze elementy metodologii projektowania. Naszym celem jest...
Wykład 2 Cykl życia systemu informacyjnego
C.d. wstępu do tematyki RUP
co daje, kiedy jest potrzebne i jak je zaimplementować mimo oporów?
Continuous Integration
Kompleksowe zarządzanie jakością informacji (TIQM)
COBIT 5 Streszczenie dla Kierownictwa
Zarządzanie projektami
Microsoft Solution Framework
<twoje imię nazwisko>
Magdalena kurzyńska Sławomir Kwasiborski
Scrum – metodyka zwinna inspirowana rugby
Licencjonowanie narzędzi dla programistów
Metodyki zarządzania projektami
Konferencja dla dyrektorów szkół i przedszkoli Europejski wymiar edukacji- rola dyrektora szkoły w realizacji międzynarodowych projektów współpracy szkół
ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI
Metodyka zarządzania projektami w nurcie Agile
Dzień z życia Product Ownera w Tablica.pl
Metodyki wytwarzania i utrzymywania aplikacji
dr hab. inż. Alina Matuszak-Flejszman, prof. nadzw. UEP
Systemy informatyczne
Waterfall model.
ŁUKASZ DZWONKOWSKI Modele zwinne i ekstremalne. Podejście tradycyjne
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Podstawy zarządzania projektami Karta projektu
Michał Sipek Piotr Kapciak
Agile Manifesto Manifest Zwinnego Wytwarzania Oprogramowania
Business Consulting Services © 2005 IBM Corporation Confidential.
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
Artur Milewski SCRUM.
BPR – zarządzanie personelem Podczas reengineeringu / i w trakcie wdrażania systemu zarządzania sukces w zasadniczej mierze zależy od akceptacji zmian.
Karolina Muszyńska. Spis zagadnień Wprowadzenie Znaczenie zarządzania komunikacją dla powodzenia projektu Praktyki zarządzania komunikacją w zespołach.
Logical Framework Approach Metoda Macierzy Logicznej
Gdy drzewa zasłaniają las Andrzej Zińczuk, PAUG,
Wstęp do systemów informatycznych Scrum – praca w małych zespołach.
Tytuł projektu: Partnerstwo Nyskie 2020 – dialog między Partnerami Nazwa partnerstwa: Partnerstwo Nyskie 2020 Podmiot zgłaszający: Gmina Nysa.
Faza 1: Faza zaprojektowania systemu monitoringu projektu: 1. Inwentaryzacja obietnic złożonych sponsorowi we wniosku - przegląd założeń projektu, opracowanie.
Inżynieria oprogramowania Metodologia SCRUM WWW: Jacek Matulewski Instytut Fizyki, UMK.
COBIT 5 Streszczenie dla Kierownictwa
Organizacja zespołu w różnych metodykach zarządzania projektami
Agile Programming a jakość
Gildia Testowa Sposób na koordynację testów w „dużym scrumie”
Plan projektu biznesowego
Scrum z perspektywy testera
Zarządzanie projektami informatycznymi
Zarządzanie projektami
Inżynieria oprogramowania Metodologia SCRUM
Inżynieria oprogramowania Metodologia SCRUM
Zgłoszenie w ramach kategorii Razem
Jerzy Nawrocki Adam Wojciechowski
Zapis prezentacji:

Agile PM Metodyki zwinne zarządzania projektami dr Grzegorz Jokiel

Manifest Agile Manifest Zwinnego Wytwarzania Oprogramowania  Agile Manifesto, Manifesto for Agile Software Development 11-13 lutego 2001 r. Snowbird w USA http://agilemanifesto.org/iso/pl/manifesto.html   programowanie iteracyjno-przyrostowe - alternatywa do tradycyjnych metod typu kaskadowego (waterfall)

Model kaskadowy Winston W. Royce 1970

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.

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

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 https://www.qagile.pl/wp-content/uploads/2017/01/Scrum-Guide-2016-PL.pdf 19 stron

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

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

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.

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

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

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

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

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

Tablica Scrumowa

Wykres wypalania

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

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.

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

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

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ć