1

Wykorzystanie metodyki AgilePM w projektach informatycznychPIOTR BRZEGOWY

Kilka słów o mnie

2

Projekt – co to jest?

W ciągu ostatnich kilkunastu lat słowo „projekt” stało się bardzo popularne.

Można zaryzykować stwierdzenie, iż projekty otaczają nas ze wszystkich stron, są nieodłącznym elementem naszego życia – tak zawodowego, jak i prywatnego.

Trudno znaleźć przedsiębiorstwo lub organizację, która nie realizowała jakiegoś projektu.

Projekt – co to jest?

Projekt wg PMBOK® Guide 2000: Projekt są to tymczasowe działania podejmowane w celu tworzenia

unikalnych wyrobów lub usług.

Projekt wg PRINCE2: Środowisko zarządzania stworzone w celu dostarczania jednego lub większej

liczby produktów biznesowych stosowane do specyficznych wymagańbiznesu.

Projekt wg podejścia procesowego Projekt jest to jednorazowy proces, składający się z zespołu działań z terminem

rozpoczęcia i zakończenia, podejmowany dla osiągnięcia celu, zuwzględnieniem ograniczeń dotyczących czasu, kosztów i zasobów.

3

Informacje z pola walki...

Metodyki tradycyjne i zwinne

Dwie kategorie metodyk: Tradycyjny Waterfall – np.

metodyka PRINCE2 (PRojects IN Controlled Environments) stworzona w połowie lat siedemdziesiątych.

Zwinne – np. metodyka AgilePM(Agile Project Management) której fundamenty opracowano w 2001 roku

4

Czym jest Agile?

Jest to ogólny opis stylu pracy:

elastyczność

silna współpraca z klientem

zapewniający, że końcowe rozwiązanie zaspokaja potrzeby klienta, a nie potrzeby zespołu projektowego

odsuwanie decyzji o szczegółach na jak najpóźniej – zaczynamy działać w oparciu o niepełne plany

Zainteresowanie metodykami w ujęciu czasowym w ciągu ostatnich 5 lat

Według badania Project Management Institute z 2018 roku, metodyki zwinne stosuje ponad 46% organizacji. Z kolei wg badania Forbes Insights z 2017 roku ponad 92% senior executives uważa, że zwinność jest kluczowa dla sukcesu w biznesie.

Słowa takie jak Agile, SCRUM, Kanban czy XP są modne, cytowane i odmieniane przez wszystkie przypadki.

5

Źródło Agile Project Management

Agile Project Management jest oparty na DSDM Atern

DSDM – najstarsze podejście zwinne, opublikowane w 1995 roku Właścicielem - konsorcjum DSDM, organizacja non-profit ― www.dsdm.org Ustalona i sprawdzona integracja *DSDM®Atern® i **PRINCE2®

*DSDM and Atern are Registered Trade Marks of Dynamic Systems Development Method Limited in the United Kingdom and other countries** PRINCE2® is a registered trade mark of the AXELOS.

Manifest Agiledeklaracja wspólnych zasad dla metodyk zwinnych

Pojęcie Agile pojawiło się w roku 2001 na spotkaniu 17 osób, które napisały manifest wspólnych zasad dla metodyk zwinnych.Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy.W wyniku tych doświadczeń przedkładamy:

Ludzi i interakcje ponad procesy i narzędzia.Działające oprogramowanie ponad obszerną dokumentację.

Współpracę z klientem ponad formalne ustalenia.Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.

Agile nie dotyczy tylko dostarczania oprogramowania. Dotyczy wszystkich rodzajów projektów.

6

Agile vs Waterfall - Struktura projektu

W modelu Waterfall produktwytwarzany jest w ramachzamkniętych, długich etapów, zktórych każdy dedykowany jestjednorodzajowemu działaniu (np.analizowaniu, projektowaniu,kodowaniu).

Weryfikacja rezultatów prac mamiejsce po raz pierwszy dopierona etapie testowania.

W metodykach Agile, produktwytwarza się w krótkich fazach(iteracjach), których każdorazowymrezultatem jest niewielki, ale działającyfragment produktu, któregopoprawność wykonania jest nabieżąco weryfikowana nazakończenie dedykowanej mu iteracji.Modelowym przykładem takiegopodejścia jest częste dostarczanieniewielkich fragmentów działającegooprogramowania.

Agile vs Waterfall - Zarządzanie zmianą

Agile traktuje zmiany jakooczywistą konieczność – i jestwyposażony w mechanizmypozwalające sprawnie jeprzeprowadzać.

Waterfall jest modelemskoncentrowanym na dostarczeniuzaplanowanego pierwotnie rezultatu,tym samym zmiana nie jest dla niegostanem naturalnym ani preferowanym.

7

Agile vs Waterfall - Współpraca

W modelu Waterfall współpracastron ma co do zasady ograniczony, sformalizowany i bardzo niesystematyczny charakter. Podobnie komunikacja, która modelowo ma także bardzo formalny, niesystematyczny i punktowy charakter tj. zachodzi wyłącznie w konkretnie określonych etapach realizacji projektu (np. kamienie milowe) lub podczas wymiany informacji w ramach formalnych struktur zarządzających projektem (np. komitet sterujący).

W Agile współpraca stron, a tym samym ich wzajemna komunikacja, mają charakter stały i bieżący. Istotą współpracy oraz komunikacji jest również ich odformalizowanie oraz „spłaszczenie”, co pozwala na utrzymanie właściwego tempa obieg informacji, c z kolei przekłada się na tempo prac realizowanych na potrzeby produktu.

Podejście lekkie

Pod parasolem pojęcia Agile mieści się wiele metodyk zarządzania projektami i dostarczaniaproduktów. Pierwszą grupą są podejścia lekkie – nastawione w większym stopniu nadostarczanie produktów:

Extreme Programming: Daje techniki wytwarzania oprogramowania Nie posiada pojęcia projektu Jest bardzo mało zarządzania Trzeba łączyć ją z metodykami zarządzania

Lean: Główną zasadą jest eliminacja strat – „Wartością jest to, co klient uzna za wartościowe.” Przykładem myślenia Lean jest twierdzenie, że nie należy wykonywać wszystkich analiz na początku,

bo zajdą zmiany Może być stosowany na poziomie wytwarzania i organizacji

Scrum: Zapewnia znakomite podejście oparte na zespole, Priorytetyzuje pracę, Nie posiada pojęcia projektu Potrzebuje dodatkowego podejścia na poziomie zarządzania projektem (np. DSDM Atern) Często łączony z XP (Scrum zapewnia zarządzanie zespołem, a XP techniki wytwarzania)

8

Podejście pełne

Podejście pełniejsze kładą większy nacisk na zarządzanie projektami

DSDM Atern (Dynamic Systems Development Method) Najstarsza na świecie metodyka Agile, powstała w 1995 roku Jako jedyna w pełni opisuje zarządzanie projektami Agile Jest w ciągłym rozwoju, a DSDM Atern jest jej najnowszą wersją.

Agile Project Management: Na początku projektu tworzony jest plan wysokiego poziomu oparty o

zarys wymagań i rozwiązanie widziane „z lotu ptaka” Projekt jest realizowany w sposób iteracyjny i przyrostowy Kolejny przyrost jest budowany w oparciu o produkt wytworzony w poprzedniej iteracji, Szczegółowy plan każdego kroku jest tworzony przez zespół, a nie

Kierownika Projektu.

Agile vs Waterfall

9

Które podejście zwinne wybrać?

W jakim środowisku pracujemy? Proste czy złożone?

Po prostu wytwarzamy produkty? Bieżąca lista cech/ulepszeń do zbudowania?

czy

Dostarczamy projekty i programy? Pełny cykl życia projektu

Zależności między projektami

Minimalny formalizm czy zorganizowana kultura korporacyjna?

Jak wybrać? Lżejsze podejścia zwinne są odpowiednie dla

prostych środowisk Złożone środowiska potrzebują pełniejszych

podejść Potrzebna jest koncepcja pojęcia „projekt”

Pełny cykl życia

Ograniczenia kultury organizacji

AgilePM jest oparty na DSDM Zwinność z rygorem

Mity

#1 Agile to nowość #2 Agile to brak dokumentacji #3 Agile to brak dyscypliny #4 Agile działa tylko w małych projektach #5 Agile to brak zakresu #6 Agile jest lekarstwem na wszystko #7 Agile to brak planu #8 Agile = Scrum #9 Agile to tylko IT

10

AgilePMZwinne zarządzanie projektami - podstawy

Podstawy – co można negocjować?

11

Podstawy - filozofia

Projekty są powiązane z jasno zdefiniowanymi celami strategicznymi Koncentracja na wczesnym dostarczeniu rzeczywistych korzyści

dla biznesu

Warunki sukcesu Kluczowi interesariusze rozumieją cele biznesowe

Upoważnianie do odpowiedniego poziomu

Współpraca w celu dostarczenia właściwego rozwiązania

Dostarczanie na czas, zgodnie z priorytetami biznesowymi

Interesariusze chcą dostarczyć rozwiązanie odpowiadające swojemu przeznaczeniu

Akceptacja faktu, że zmiana jest nieuchronna

Podstawy – Pryncypia

Pryncypia wspierają filozofię

Uwydatniają postawę i sposób myślenia zespołu

Ustępstwa wobec pryncypiów podważają filozofię i wprowadzają ryzyko

Zastosowanie wszystkich pryncypiów zapewnia maksymalną korzyść

Razem pryncypia pozwalają organizacji wspólnie dostarczyć rozwiązania o najwyższej wartości

12

Podstawy – Pryncypium 1

Koncentruj się na potrzebie biznesowejDecyzje oparte na celu biznesowym Dostarczenie tego, czego potrzebuje biznes, wtedy kiedy tego potrzebuje

Wymaga od zespołu Zrozumienia prawdziwych priorytetów biznesowych

Stworzenia solidnego uzasadnienia biznesowego

Nalegania na ciągłe sponsorowanie i zaangażowanie ze strony biznesu

Gwarancji dostarczenia Minimalnego Użytecznego Podzbioru (Minimum Useable Subset)

Wspierane przez: Role biznesowe

Produkty biznesowe uzgodnione w fazie Podstawy

Kluczowe techniki - MoSCoW i Stosowanie Okienek Czasu

Nadawanie priorytetówTechnika MoSCoW

13

AgilePM Timebox vs Sprint

Podstawy – Pryncypium 2

Dostarczaj na czasWymaga od zespołu Stosowania Okienek Czasu

Koncentracji na priorytetach biznesowych

Dotrzymywania ostatecznych terminów

Wspierane przez: Kluczowe techniki : MoSCoW i Stosowanie Okienek Czasu

Aby zbudować reputację dostarczania na czas i zgodnie z przewidywaniami

14

Podstawy – Pryncypium 3

WspółpracujWymaga od zespołu Zaangażowania odpowiednich interesariuszy w odpowiednim czasie przez cały projekt Zapewnienia, że członkowie zespołu są upoważnieni do podejmowania decyzji w imieniu

tych, których reprezentują Aktywnego angażowania przedstawicieli biznesu Budowy kultury jednego zespołu

Wspierane przez: Role biznesowe Kluczową technikę: Warsztaty Facylitowane (facilitated workshops)

Podstawy – Pryncypium 4

Nigdy nie idź na kompromis w kwestii jakościWymaga od zespołu Ustalenia oczekiwanego poziomu jakości na początku

Zapewnienia, że jakość nie stanie się zmienną

Odpowiedniego planowania, dokumentowania i testowania

Testowania wcześnie i ciągle

Wbudowywania jakości przez ciągłe przeglądy z odpowiednimi osobami

Wspierane przez: Testowanie produktów

Wczesne i integracyjne testowanie

Regularne przeglądy w cyklu życia

Kluczowe techniki : MoSCoW i Stosowanie Okienek Czasu

15

Podstawy – Pryncypium 5

Buduj przyrostowo na solidnych podstawachWymaga od zespołu Dążenia do wczesnego dostarczenia korzyści biznesowych tam, gdzie to jest

możliwe Ciągłego potwierdzania, że budowane jest poprawne rozwiązanie Formalnego dokonywania ponownej oceny priorytetów i zasadności projektu

po każdym przyrościeWspierane przez: Cykl życia - stworzenie solidnej podstawy (Wykonalność i Podstawy) przed

rozwojem przyrostowym (przez Eksplorację i Inżynierię)

Podstawy – Pryncypium 6

Rozwijaj iteracyjnieRozwój Iteracyjny pozwala zespołowi zbliżać się do odpowiedniego rozwiązania. Nic nie jest

idealnie zbudowane za pierwszym razem!Wymaga od zespołu Wykonania wystarczającego projektowania na początku (enough design up front EDUF), by

stworzyć solidne podstawy Budowania produktów za pomocą podejścia iteracyjnego Wbudowania informacji zwrotnej od klienta w każdą iterację Zaakceptowania faktu, że większość szczegółów pojawi się raczej później niż wcześniej Wykorzystania zmian, dobre rozwiązanie nie będzie ewoluowało bez nich Kreatywności, eksperymentowania, nauki i ewoluowania Zmiana jest nieuchronna, zezwól na nią i wykorzystaj jej skutki

Wspierane przez: Iterację i ciągłe przeglądy - zapewnia, że ewoluujące rozwiązanie jest zgodne z rzeczywistymi

potrzebami biznesu.

16

Podstawy – Pryncypium 7

Komunikuj się ciągle i jasnoWymaga od zespołu: Przeprowadzania Codziennych Zbiórek (daily stand-up) Wykorzystywania Warsztatów Facylitowanych Korzystania z „bogatej komunikacji” – modelowania, prototypowania Przedstawiania przyrostów rozwijanego rozwiązania wcześnie i często Utrzymywania zwięzłej i aktualnej dokumentacji Ciągłego zarządzania oczekiwaniami interesariuszy Wspierania nieformalnej komunikacji „twarzą w twarz” na wszystkich poziomachWspierane przez: Zaangażowanie i upoważnianie użytkowników Codzienne Zbiórki i Warsztaty Facylitowane Jasno zdefiniowane role i zaangażowanie użytkowników Modele i prototypy – w celu unaocznienia rozwiązania w początkowym stadium

rozwoju

Podstawy – Pryncypium 8

Demonstruj kontrolęWymaga aby zespół, a zwłaszcza Kierownik Projektu i Lider Zespołu: Używali odpowiedniego stopnia formalizmu dla śledzenia i raportowania Zapewnili, że plany i informacje o postępach były widoczne dla wszystkich Mierzyli postępy poprzez dostarczanie produktów Zarządzali proaktywnie Ciągle oceniali zasadność projektu w oparciu o cele biznesoweWspierane przez: Kluczową technikę : Stosowanie Okienek Czasu Ciągłe przeglądy Produkty planowania Podstawy Zarządzania i Plany Okienek Czasu

17

Pryncypia – Cenne wskazówki

Traktuj odejście od zasad jako ryzyko Złamanie którejkolwiek z zasad stanowi poważne ryzyko dla sukcesu procesu

zwinnego i sukcesu projektu

Na początku projektu otwarcie przedyskutuj z zespołem projektowym Pryncypia. Upewnij się, że wszyscy je rozumieją i akceptują.

Role i obowiązki

Jedna osoba może pełnić więcej niż jedną rolę Rola może być dzielona pomiędzy kilka osób

Sponsor Biznesowy nie powinien być rolą dzieloną Wizjoner Biznesu jest rzadko rolą dzieloną

Wszystkie obowiązki muszą zostać przypisane Role projektowe

zarządzające, kierujące, koordynujące

Role Zespołu Rozwoju Rozwiązania (Solution Development Team -SDT) Stworzenie rozwiązania

Inne role Zgodnie z potrzebami, specjalistyczne

18

Ograniczenia projektu – Co jest istotne?

Zrozum swoje ograniczenia

Uwzględnij zmienne Czy jest elastyczność w głębokości (szczegółach) cech?

Pomyśl o ludziach Czy osoby pełniące wszystkie role poradzą sobie i są zaangażowane w podejście projektowe?

Uwzględnij pryncypia Czy organizacja będzie wspierała ten sposób pracy?

Rzadko jest to czarno-biała decyzja. Ale jest narzędzie, które pomoże podjąć decyzję.

19

Dziękuję