Metodyki zwinne AGILE

Transkrypt

1 Metodyki zwinne AGILE Cz.1/2 Project Management, CISA, PMP, ITILF v.2/3 PRAKTYK BIZNESU Wrocław, luty 2014

2 Prowadzący doświadczony kierownik projektów i audytor systemów informatycznych. Pracował w branżach: elektrycznej, motoryzacyjnej, informatycznej i obsłudze branży farmaceutycznej oraz ubezpieczeniowej. Najwięcej doświadczeń zawodowych zdobył w firmie Volvo, pracując w międzynarodowych projektach informatycznych, organizacyjnych i kontrolingu biznesowego. Przez półtora roku pracował w projekcie kontroli wewnętrznej koncernu Volvo na poziomie centralnym. Obecnie pracuje w firmie IBM na stanowisku Starszego Kierownika Projektów (ang. Senior Project Manager). Posiada międzynarodowe certyfikaty kompetencyjne: projektowy PMP, audytowy CISA i branżowy ITIL.

3 Agenda: Streszczeniem różnic miedzy projektem a procesem oraz przyczyn uruchamiania projektów. Na tym tle naświetlenie różnicy między podejściem tradycyjnym a Agile Porównanie podejścia klasycznego i zwinnego Przedstawienie Agile Manifesto Krótkie omówienia implementacji Agile

4 Po co są projekty? Bo pojawia się potrzeba zmiany (np.. potrzebujemy nową drogę; przenieśmy obsługę klienta z fizycznych budynków do call center ) Bo zmiana jest skomplikowana w swojej naturze lub do jej wprowadzenie jest potrzebne jest współdziałanie wielu ludzi / elementów (np. przeprowadzka Urzędu Skarbowego) Bo macierzysta jednostka nie chce / nie może być dodatkowo obciążona ona jednorazowymi akcjami (np. spółki miejskie dedykowane do prowadzenia inwestycji, macierzysta organizacja to Urząd Miejski) Bo z jakichkolwiek potrzeb trzeba działać inaczej niż zwykle (np. przerobienie standardowych produktów bankowych na internetowe ) Bo wprowadzenie zmiany napotkać może trudności bądź konflikty interesów (np. projekty optymalizacyjne) Czyli - BO TRZEBA INACZEJ

5 Porównanie specyfiki pracy w projektach z pracą operacyjną Praca w projektach: często działania jednorazowe; metody przybliżeń; estymacje; twórcze rozwiązywanie problemów; kompromisy; negocjacje; zmiany planów; procedury nie mogą być zwykle zbyt sztywne bo obniża to możliwość dostosowania się do zmieniającej się sytuacji; projekty są kosztem dla inwestora a przyszłe zyski są oparte na przewidywaniach; konieczność nieustannej nauki i podnoszenia kwalifikacji zgodnej z przewidywaniami dotyczącymi przyszłości Praca codzienna, operacyjna: im bardziej powtarzalne są zadania, tym większe możliwości optymalizacji a więc cięcia kosztów; ważne jest przestrzeganie procedur i instrukcji; umożliwia ona właścicielowi wypracowanie zysku; jasna struktura odpowiedzialności; zwykle dobrze zdefiniowane możliwości awansu i oczekiwań pracodawcy; możliwość łatwego podnoszenia kwalifikacji zgodnej ze stanowiskiem Uwaga: każda z wymienionych cech jest wartościowana przez pracowników indywidualnie, nie ma obiektywnie lepszej i gorszej pracy jest inna (jedni lubią ptaki inni słonie ale i jedne i drugie są potrzebne).

6 Kryteria wyboru inicjatyw Organizacja/ sponsor przy uruchamianiu projektu powinien brać pod uwagę mapę priorytetów i skupiać się na działaniach mających szansę dać maksymalny efekt (osiągnięcie celów organizacji) przy minimalnym wysiłku (jak najmniejszych zaangażowanych zasobach).

7 Właściwe definiowanie projektów (otoczenie projektu) TOP MANAGEMENT CO JEST WAŻNE : Zdefiniowanie STRATEGICZNYCH CELÓW (np.. Zwiększenie zysku o 20% w ciągu 18 miesięcy) JAK CHCEMY TO OSIĄGNĄĆ: Przełożenie tych celów na ZDOLNOŚCI ich realizacji (np. krytyczne dla osiągnięcia celu jest wytwarzanie innowacyjnych produktów o dobrej jakości i przy minimalizowaniu kosztów wytwarzania oraz obsługi posprzedażnej po analizie: mamy innowacyjne produkty [+] ale kiepskiej jakości [-] i nie panujemy nad kosztami wytwarzania [-] nie mówiąc już o kosztach obsługi posprzedażnej [-]) MANAGEMENT CO JEST WAŻNE :Przełożenie zdolności na OBSZARY organizacji wymagające poprawy, FUNKCJONALNOŚCI umożliwiających tę poprawę oraz określenie ich ważności (np. Obszary :procesy wytwarzania, zarządzania jakością; obsługi posprzedażnej Działy: produkcyjny, jakości, sprzedaży, Funkcjonalności: lean manufacturing, automatyczne raportowanie kosztów, szybkie raportowanie wad dostarczonych produktów i sposobu ich obsługi) JAK CHCEMY TO OSIĄGNĄĆ: Zdefiniowanie projektu / programu projektów mających dostarczyć najważniejsze funkcjonalności lub w inny sposób umożliwić poprawę krytycznych zdolności organizacji dla osiągnięcia celu (np. stabilizacja a potem optymalizacja procesu wytwarzania w dziale produkcyjnym poprzez wdrożenie lean manufacturing, wsparcie kontroli kosztów poprzez wdrożenie systemu ERP, stworzenie dedykowanej aplikacji do wsparcia serwisów w obsłudze posprzedażnej).

8 Rodzaje inicjatyw Inicjatywy dzielimy na: - Portfolio projektów (wszystkie inicjatywy projektowe organizacji) - Programy projektów (dotyczą jednego celu ogólnego, dla którego uruchamia się kilka projektów) - Projekty (traktowane indywidualnie) Projekt, tak jak i każda jego faza składa się z następujących uniwersalnych części: Inicjacja, Planowanie, Wykonanie, Zamykanie To wszystko opakowane powinno być w procesy monitoringu i kontroli

9 Waterfall vs. Agile Podejście klasyczne (Waterfall) i podejście zwinne (Agile) są sposobami prowadzenia projektu. W dalszej części ci przedstawione zostanie skrótowo podejście klasyczne a następnie szerzej zwinne celem zrozumienia różnic. Rozumienie różnic przez kierownictwo firm jest kluczowe dla powodzenia podejścia Agile.

10 Cykl życia projektu podejście klasyczne Kolejność faz projektu (niektóre mogą być redukowane, w zależności od projektu): Definiowania (cele, zakres) Koncepcyjna (ogólny zarys wielu alternatywnych rozwiązań) Konstrukcyjna (dopracowywanie szczegółów jednego wybranego rozwiązania) Wykonawcza (produkcja rozwiązania) Prototypu / Pilota (sprawdzenie rozwiązania) Wdrożenia (oddanie do użytku) Zamknięcia projektu (podsumowania, rozliczenia)

11 Uniwersalne obszary zarządzania projektem 1. Zarządzanie integracją 2. Zarządzanie zakresem 3. Zarządzanie czasem 4. Zarządzanie kosztami 5. Zarządzanie jakością 6. Zarządzanie zasobami ludzkimi 7. Zarządzanie ryzykiem 8. Zarządzanie komunikacją 9. Zarządzanie zakupami Obszary są różnie zarządzane w zależności od metodyk użytych do zarządzania projektem. Pytanie nie brzmi CZY nimi zarządzać ale JAK nimi zarządzać.

12 Planowanie i parametry projektowe Tradycyjne: outrzymanie projektu w równowadze oczas, koszt i dostępność zasobów ograniczają zakres i jakość Tradycyjny PM Plan projektu identyfikuje czas, koszt i dostępność zasobów aby dostarczyć zakres i jakość Zakres i jakość Dostępność zasobów

13 Zmienne zarządzania projektem wg. Agile I spalanie Rejestr Zadań Prędkość obracania Rejestru Zadań w funkcjonalność przyrostową Czas Inne zmienne:jakość, Wartość

14 Zaawansowane projekty informatyczne Innowacyjne projekty informatyczne cechuje duża niepewność, duży poziom zmian, iteracyjność Może być to obsłużone poprzez dobrze zarządzane umiejętności zespołu ale zawsze wymaga to zaufania do zespołu

15 Agile Grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz rozwiązania ewoluują przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto.

16 Agile Manifesto Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać: Ludzi i ich wzajemne interakcje (współdziałanie) ponad procedury i narzędzia. Działające oprogramowanie nad wyczerpującą dokumentację. Współpracę z klientem nad negocjację umów. Reagowanie na zmiany nad realizowanie planu. Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej.

17 Agile - Założenia Osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania Działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie) Podstawową miarą postępu jest działające oprogramowanie Późne zmiany w specyfikacji nie mają destrukcyjnego charakteru na proces wytwarzania oprogramowania Bliska, dzienna współpraca pomiędzy biznesem a developmentem Bezpośredni kontakt jako najlepsza forma komunikacji w zespole i poza nim Ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design) Prostota Samozarządzalność zespołów Regularna adaptacja do zmieniających się wymagań

18 Używane w roku 2012 metodyki Agile Na podstawie: opublikowane w r th Annual State of Agile Development Survey

19 Agile/Scrum Scrum : metoda, przy użyciu której 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. Scrum jest: Lekki, Łatwy do zrozumienia, Bardzo trudny do opanowania. Scrum stanowi ramy wykorzystywane w zarządzaniu procesami wytwarzania złożonych produktów od początku lat 90-tych. Sam w sobie Scrum nie jest procesem czy techniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik.

20 Agile / Scrum c.d. Główne role w projekcie grają: "Mistrz Młyna" (Scrum Master), Właściciel Produktu (Product Owner), Członkowie Zespołu (The Team). Rejestr produktu Rejestr zadań przebiegu Przebieg Działający przyrost oprogramowania

21 Agile/XP (extreme Programming) Tworzenie 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 informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces. Cechy: Iteracyjność Ciągłe modyfikacje architektury Testy podzespołów Stały kontakt z klientem

22 Agile/XP c.d. XP stało się jednym z najbardziej popularnych i kontrowersyjnych metod zwinnych. XP jest zdyscyplinowanym podejściem do dostarczania wysokiej jakości oprogramowania, szybko i płynnie. Promuje ona wysokie zaangażowanie klienta, szybkie sprzężenie zwrotne, ciągłe testowanie i ciągłe planowanie oraz ścisłą współpracę zespołową w celu dostarczania działającego oprogramowania w bardzo krótkich odstępach czasu, zwykle co 1-3 tygodnie. W XP, "Klient" ściśle współpracuje z zespołem programistów w celu określenia i priorytetów poszczególnych jednostek funkcjonalności zwanych "Opowieściami użytkownika (User stories). Zespół deweloperskiego robi oszacowania, plany i dostarcza jednostki funkcjonalności o najwyższym priorytecie zgodne z opowieściami użytkowników, w formie działającego, przetestowanego oprogramowania, na zasadzie iteracji. W celu maksymalizacji wydajności, praktyki XP zapewniają wsparcie poprzez lekkie struktury prowadząc zespół oraz zapewniając wysoką jakość oprogramowania.

23 Agile/XP c.d. Oryginalny przepis na XP bazuje na 4 prostych wartościach: prostocie, komunikacji, informacji zwrotnej i odwadze i 12 praktykach wspierających: Gra w planowanie (Planning Game ) Małe publikacje oprogramowania (Small Releases) Testy akceptacyjne Klienta (Customer Acceptance Tests) Prosta konstrukcja (Simple Design) Programowanie w parach (Pair Programming) Rozwój oprogramowania kierowany przez testy (Test-Driven Development) Refaktoryzacja (Refactoring ) Ciągła integracja (Continuous Integration) Zbiorowa własność kodu (Collective Code Ownership) Standardy kodowania (Coding Standards ) Metafory (Metaphor) jako samoobjaśniające nazwy w kodzie oprogramowania odnoszące się do jego funcjonalności Zrównoważone tempo (Sustainable Pace)

24 Agile/XP c.d.

25 Agile/Lean Software Development Lean Software Development (LSD, szczupły rozwój oprogramowania) jest metodyką iteracyjną (przyrostową). LSD bierze wiele swoich zasad i praktyk z metod Lean Management (szczupłego zarządzania) i praktyk firm takich jak Toyota. LSD skupia zespół na dostarczanie wartości dla klienta i na efektywności "strumienia wartości", na mechanizmach, które zapewniają tę wartość. Główne zasady Lean obejmują: Eliminowanie marnotrawstwa Podkreślanie nauki Decydowaniu się możliwie jak najpóźniej Dostarczaniu jak najszybciej Mobilizowaniu zespołu Budowaniu integralność Widzeniu całości

26 Agile/Lean Software Development c.d. LSD eliminuje marnotrawstwo poprzez takie praktyki jak wybieranie tylko naprawdę użytecznych funkcje dla systemu, priorytetyzację tych wybranych i dostarczanie ich w małych partiach. Podkreśla się szybkość i efektywność przepływu pracy rozwoju oprogramowania i opiera się na szybkiej i rzetelnej informacji zwrotnej od programistów i klientów. Lean wykorzystuje koncepcję produktu pracy który jest "ciągnięty" przez zamówienie klienta. Koncentruje upoważnienia i umiejętności do podejmowania decyzji na poszczególnych osobach i małych zespołach, gdyż badania pokazują, że jest to szybsze i bardziej wydajne niż w hierarchicznym przepływu sterowania. Lean również koncentruje się na efektywności wykorzystania zasobów zespołu, starając się zapewnić, że każdy jest produktywny, jak dużo czasu jak to możliwe. Koncentruje się również na jednoczesnej pracy i jak najmniejszych możliwych zależnościach przepływu pracy wewnątrz zespołu. Lean zaleca mocno aby automatyczne testy jednostkowe były pisane w tym samym czasie co kod.

27 Agile/Kanban Kanban jest metodą zarządzania tworzeniem produktów, kładąc nacisk na ciągłe dostawy jednocześnie nie obciążając nadmiernie zespołu deweloperskiego pracą. Jak Scrum, Kanban jest to proces mający na celu pomóc zespołom współpracować bardziej efektywnie. Kanban opiera się na 3 podstawowych zasadach: Wizualizację tego co robisz dzisiaj (przepływ pracy): widzenie wszystkich elementów we wzajemnym kontekście może być bardzo pouczające Ogranicz ilość pracy w toku: to pomaga zrównoważyć przepływ pracy więc zespół nie zaczyna i nie zobowiązuje się do zbyt dużej pracy w tym samym czasie Zwiększenia przepływu: kiedy coś jest skończone, rozpoczynana jest następna najważniejsza rzecz z rejestru zadań Kanban sprzyja stałej współpracy i zachęca do aktywnej, ciągłej nauki i doskonalenia poprzez określenie najlepszego możliwego przepływu pracy zespołowej.

28 Agile/DSDM (Dynamic Systems Development Method ) Dynamiczna metoda rozwoju systemów DSDM opiera się na kluczowych zasadach, które przede wszystkim dotyczą: potrzeb biznesowych / wartości biznesowej, aktywnego udziału użytkownika, upoważnionych zespołów, częstych dostaw, zintegrowanego testowania i współpracy z zainteresowanymi stronami. DSDM specjalnie przywołuje "przydatność dla celów biznesowych" jako podstawowego kryterium do dostawy i odbioru systemu, skupiając się na użytecznych 80% systemu, które mogą być wdrożone w 20% czasu (zasada Pareto). Wymagania są ustalane na wysokim poziomie na początku projektu. Powtórna praca (rework) jest wbudowana w procesie, a wszystkie zmiany rozwojowe muszą być odwracalne.

29 Agile/DSDM (Dynamic Systems Development Method ) c.d. Wymagania są planowane i dostarczane w krótkich, o stałej długości interwałach czasowych, zwany także iteracjami również wymagania dotyczące projektów DSDM są priorytetyzowane przy użyciu reguł MoSCoW: M Must have requirements wymaganie Musimy to mieć S Should have if at all possible Powinniśmy to mieć jeśli możliwe C Could have but not critical Możemy to mieć ale nie jest krytyczne W - Won t have this time, but potentially later Nie będziemy tego mieć teraz ale może później Wszystkie krytyczne prace muszą być zakończone w projekcie wg DSDM. Ważne jest również, że nie każdy wymóg w projekcie lub interwał czasowy jest uważany za krytyczny. W ramach każdego interwału czasowego, mniej krytyczne pozycje są mają być zawarte, aby w razie potrzeby, można je usunąć, żeby chronić większe wymagania priorytetowe i aby mogły być one dostarczone zgodnie z harmonogramem. Ramy metodyki DSDM są niezależne i mogą być realizowane w połączeniu z innymi metodykami iteracyjnymi takimi jak np. XP

30 Agile/FDD (Feature-Driven Development ) Kierowanie rozwojem oprogramowania poprzez właściwości/funkcjonalności FDD jest kierowanym przez modelowanie, procesem krótkich iteracji. Zaczyna się od ustanowienia ogólnego kształtu modelu. Następnie kontynuuje serię dwu tygodniowych iteracji wg zasady zaprojektowany i zbudowany poprzez funkcjonalność. Funkcje są małe a wyniki "pożyteczne w oczach klienta. Zwolennicy FDD twierdzą że bardziej od innych metod nadaje się do większych zespołów. W przeciwieństwie do innych metodyk zwinnych, FDD opisuje konkretne, bardzo krótkie etapy pracy, które mają być realizowane oddzielnie dla funkcji.

31 Agile/FDD c.d. 1 (Kierowanie rozwojem poprzez właściwości, funkcjonalności) FDD zaleca konkretne praktyki programistyczne, takie jak "Regularne budowanie działającego oprogramowania i Przypisanie własności Komponentu/Klasy W przeciwieństwie do innych metodyk zwinnych, FDD opisuje konkretne, bardzo krótkie etapy pracy, które mają być realizowane oddzielnie dla funkcji. Należą do nich: przegląd domenowy, projektowanie, nadzór rozwiązania, kodowanie, kontrola kodu oraz promowanie zbudowanej wersji.

32 Agile/FDD c.d. 2 (Kierowanie rozwojem poprzez właściwości, funkcjonalności) FDD projektuje resztę procesu rozwoju wokół realizacji funkcji za pomocą ośmiu następujących praktyk (pojęcia w znaczeniu programistycznym) : Modelowanie obiektowe, domenowe Rozwój przez funkcjonalności Przypisanie własności Komponentu/Klasy Zespoły przypisane do pożądanej funkcjonalności Inspekcje Zarządzanie konfiguracją Regularne budowanie działającego oprogramowania Widoczność postępach i wynikach

33 Agile główny czynnik sukcesu Zmiana świadomości i akceptacji innych zasad przez : Kierownictwo firmy Zespół Klienta

34 Porównanie W podejściu tradycyjnym są zdefiniowane fazy projektu, np..: Definiowania, Koncepcyjna, Konstrukcyjna, Wykonawcza, Prototypu / Pilota, Wdrożenia, Zamknięcia projektu. Są one formalnie oddzielone od siebie tzw. Bramkami (gates) lub kamieniami Milowymi (milestones). Definicja faz zależy od branży / biznesu, natomiast obszary zarządzania projektem są uniwersalne. Są to: zarządzanie - Integracją, Zakresem, Czasem, Kosztami, Jakością, Zasobami Ludzkimi, Komunikacją, Ryzykiem i Zakupami. W podejściu alternatywnym (Agile), stawia się na bliską kooperację zleceniodawcy i dostawcy, zamiast formalnych faz projektu stosuje się iteracje. Najważniejsze są następujące pryncypia: Ludzie i ich wzajemne interakcje (współdziałanie), działające oprogramowanie, współpracę z klientem, reagowanie na zmiany. Obszary zarządzania projektem dalej istnieją, chociaż zarządza się nimi w sposób elastyczny i dużo mniej formalny, zależny od od konkretnej metodyki Agile.

35 Waterfall vs. Agile Główną różnicą między podejściem kaskadowym (tradycyjnym) i zwinnym (Agile) jest podejście do zmian. Waterfall nie lubi zmian, angażuje duże środki administracyjne do ich obsługi jeśli już muszą być obsłużone Agile zmiana jest naturalną właściwością pracy i otoczenia

36 Porównanie właściwości Agile Tradycyjne (Ciężkie) Podejście Adaptacyjność Przewidywalność Miara sukcesu Wartość biznesowa Zgodność z planem Rozmiar projektu Mały Duży Styl zarządzania Zdecentralizowany Autokratyczny Perspektywa zmian Dostosowanie Przetrzymanie Kultura Przywództwo-Współpraca Nakaz-Kontrola Documentacja Niska ilość Duża ilość Orientacja Na ludzi Na procesy Cykliczność Liczne cykle Ograniczona Zakres Nieprzewidywalny/ Przewidywalny Odkrywczy Planowanie z góry Minimalne Obszerne Zwrot z inwestycji Wcześnie w projekcie Na koniec projektu Rozmiar zespołu Mały/kreatywny Duży

37 Ograniczenia podejścia kaskadowego Waterfall dobrze się sprawdza w stabilnym i niezbyt skomplikowanym otoczeniu, tam planowanie i podążanie za planem jest jak najbardziej możliwe, ale nie sprawdza się w niestabilnym i/lub złożonym onym otoczeniu. Rozwiązanie tego problemu leży w prostocie. Proste, jasne cele i zasady prowadzą do złożonych i inteligentnych zachowań.

38 Ograniczenia Agile Głównym ograniczeniem jest rozmiar zespołu, Agile ma problem z obsługą dużej ilości osób zaangażowanych w projekt Następnym ryzykiem użycia metody jest założenie zaangażowania Klienta, czyli przy np. jego opieszałości, metoda zaczyna gorzej działać (liczą się szybkie reakcje). Jeśli jest więcej niż jeden Klient różnica zdań co do wymagań musi być dodatkowo obsłużona, co również wydłuża czas reakcji.