Transcript Zwinne
ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI Wrocław, 2013/2014 Opracował i prowadzi dr inż. Jan BETTA (Zwinne.pptx) CELE ZAJĘĆ C1 Uzyskanie przez Słuchaczy wiedzy na temat klasycznych i adaptacyjnych metodyk zarządzania projektami C2 Nabycie przez Nich wiedzy o funkcjonowaniu i stosowaniu właściwych metod, technik i narzędzi PM C3 Opanowanie umiejętności praktycznego stosowania w/w metod, technik i narzędzi zarządzania rzeczywistym projektem PLAN ZAJĘĆ I. Metodyki klasyczne (przypomnienie) 1. Podstawowe pojęcia PM – przypomnienie 2. PM – stan wiedzy (świat, Polska) 2.1 Metodyka PMI 2.2 Metodyka Prince 2 2.3 Wytyczne kompetencji IPMA (ICB/NCB) II. Metodyki zwinne (adaptacyjne) 1. Przegląd: Extreme Programming, Crystal, Dynamic Systems Development, Rapid Application Development, Scrum 2. ScrumMaster 3. Właściciel produktu 4. Zespół Scrum 5. Zdarzenia w Scrum - sprint, planowanie sprintu 6. Zdarzenia w Scrum - monitorowanie sprintu, sprint expost (retrospektywa sprintu) 7. Artefakty Scrum – rejestr produktu, rejestr sprintu, przyrost funkcjonalności produktu 8. Podsumowanie wykładu ŹRÓDŁA (tylko cz. II. - zwinne) 1. Highsmith J., Agile Project Management, Wydawnictwo MIKOM, Warszawa, 2005 2. Schwaber K., Sprawne zarządzanie projektami metodą Scrum, Microsoft Press, Warszawa, 2005 3. Charvat J., Project Management Methodologies, John Wiley & Sons, New Jersey, 2003 4. Manifesto for Agile Software Development, http://agilemanifesto.org/ 1. Metodyki zwinne - przegląd Adaptacyjne zarządzanie projektami (ang. Agile Project Management, APM) to zbiór różnych metodyk, określanych jako zwinne bądź lekkie, i narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnymi projektami głównie informatycznymi (m.in. w zakresie inżynierii oprogramowania). Obecnie – projekty badawcze? Dynamiczny rozwój adaptacyjnego zarządzania projektami rozpoczął się w 2001 roku, dokument Manifesto for Agile Software Development, który zainicjował głębokie przemiany w środowiskach programistycznych, a następnie przeniknął w niektóre obszary zarządzania projektami. Powstanie APM było w dużej mierze reakcją na mało elastyczne metody zarządzania projektami informatycznymi. Manifest Agile (Manifest Zwinnego Wytwarzania Oprogramowania) Jest to deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania. Została opracowana na spotkaniu jakie miało miejsce w dniach 11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA (stan Utah). Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym (sekwencyjnym). Deklaracja programowa twórców tych metod jest nazwana Manifestem Agile (Manifesto for Agile Software Development, 2001). Manifest ten jest skrótowym opisem celu, dla którego zostały one stworzone. „Odkrywamy coraz to lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym to robić. W tej pracy zaczęliśmy szczególnie cenić: Ludzi i wzajemne interakcje ponad procedury i narzędzia Działające oprogramowanie ponad wyczerpującą dokumentację Współpracę z klientem ponad negocjowanie kontraktów Reagowanie na zmiany ponad trzymanie się planu” Zespoły prowadzące projekty o zmiennym zakresie muszą charakteryzować się zdolnością do adaptacji (agility). Sprowadza się to do posiadania umiejętnosci wytwarzania posiadanego produktu i jednoczesnego reagowania na zmiany i oczekiwania biznesowe. Tym samym jedną z podstawowych różnic w stosunku do tradycyjnych technik jest podejście do odchyleń w pierwotnym planie. Metodyka Agile zakłada, że plan projektu jest przewodnikiem do przyszłości, a nie “samą przyszłością”. A zatem odchylenia od planu nie są traktowane jako błędy, ale – przeanalizowane - są podstawą do zmian w planie dalszych faz projektu. Tym samym strony wdrożenia przedkładają wzajemną kooperację, rozumianą jako dostosowywanie się do zmian, nad sztywne trzymanie się kontraktu. To z kolei wymaga odpowiedniego podejścia do kwestii kosztów, które rosną wraz z poszerzeniem zakresu wdrożenia. Z punktu widzenia techniki Agile definiowanie sztywnych ram projektowych w zakresie umowy nie ma sensu. Istnieje bowiem ryzyko, że takie zapisy będą interpretowane w niekorzystny dla sukcesu projektu sposób. Klienci mają bowiem skłonności do niekontrolowanego poszerzania zakresu funkcjonalnonalności często “na zapas”, co z kolei przez dostawcę jest interpretowane jako niekorzystna próba reinterpretacji umowy. Dyskusja o zakresie zostaje więc przeniesiona na ścieżkę wojenną - klient chce jak najwięcej, nawet jeśli nie potrzebuje; dostawca stara się ograniczyć swoje zaangażowanie. Efektem są zakłócenia w przebiegu projektu. Podejście Agile zakłada, że lista procesów i funkcjonalności systemu może zmieniać się z czasem i potrzebami biznesowymi klienta i rekomendacjami firmy wdrożeniowej klienci mogą nie znać na początku projektu wszystkich możliwości systemu a co za tym idzie, mogą dopiero po pewnym czasie wyrazić potrzebę przemodelowania swoich procesów, poprzez taką modyfikację funkcjonalności lub zmianę sposobu działnia firmy, które pozwolą na ograniczenie kosztów wewnętrznych zmiany w zakresie, terminach i kosztach traktowane są przez obie strony jako naturalny element projektu Cechy charakterystyczne Agile Proces wdrożenia metodą adaptacyjną jest iteracyjny i ewolucyjny - umożliwiający przystosowanie do zmian wewnętrznych i zewnętrznych modułowy i wyszczuplający, umożliwiajcąy usuwanie albo dodawanie poszczególnych elementów procesu w zależności od potrzeb interesariuszy koncentrujący się na istotnych funkcjonalnościach, oparty na cyklach zawierających informację zwrotną i wskazówki do wykorzystania w następnym cyklu Członkowie zespołu winni podzielać następujące wartości prostota - dla istotnych czynników sukcesu staramy się znaleźć najprostsze możliwe rozwiązanie komunikacja - dbamy o stały i wysoki poziom komunikacji w zespole, informacja zwrotna (feedback) odwaga - istotna do podejmowania ważnych decyzji pokora - nie jesteśmy wszechwiedzący i trzeba czasem uzupełnić swoją wiedzę Agile Project Management, czyli zarządzanie adaptacyjne, wymaga od obu stron dużej dozy zaufania. Jeżeli partnerzy projektowi chcą pracować w oparciu o jej założenia, można się spodziewać sukcesu. Jednak w przypadku, gdy jedna ze stron ma zastrzeżenia co do sposobu prowadzenia projektu, bezpieczniej jest poprowadzić projekt metodą tradycyjną. Agile Project Management zdecydowanie różni się od podejścia tradycyjnego, inne są również rola i zakres odpowiedzialności kierownika projektu. Dotychczasowe praktyki zarządzania projektem polegające na jednoosobowej odpowiedzialności za projekt, szczegółowym planowaniu, rozdzielaniu zadań i rozliczaniu z postępów prac, ustępują miejsca szerokiej i aktywnej współpracy z klientem, kolektywnej odpowiedzialności za sukces projektu oraz planowaniu i realizacji projektu pod kątem osiąganej wartości oraz adaptacji do zmian. System sześciu zasad APM Wartość dla klienta poprzez innowacyjne produkty Dostarczaj wartość klientowi Zastosuj wytwarzanie iteracyjne oparte na dostarczaniu elementów funkcjonalnych Promuj doskonałość techniczną Przywódczo-partycypacyjny styl zarządzania Zachęcaj do badań Buduj adaptacyjne zespoły Upraszczaj Pozostałe zasady i cele stosowania zwinnych metodyk w ramach zarządzania projektami elastyczność i adaptacyjność projektowania względem dynamicznie zmieniających się potrzeb i oczekiwań klienta (stąd termin zwinne - ang. agile) tworzenie wartościowych i innowacyjnych rozwiązań zarówno dla firmy jak i klientów na każdym etapie projektowania minimalizacja kosztów m.in. dzięki skróceniu harmonogramu procesu wytwarzania koncentracja na członkach zespołu projektowego, wzrost motywacji pracowników i bezstresowa realizacja projektów ścisła współpraca z klientem - preferowany jest kontakt bezpośredni prostota i samoorganizujące się zespoły satysfakcja klienta dzięki szybkiemu i regularnemu dostarczaniu wartościowego produktu minimalizacja ryzyka 16.04. Extreme Programming (XP) Methodology - główny nacisk kładziony jest na sposób prowadzenia prac projektowych związanych z programowaniem: Bazuje na iteracjach, obejmujących proste projektowanie, testowanie i ciągłą integrację Proponuje skuteczne (proste) techniki przyjmowania założeń, działań i ról w projekcie Opiera się na czterech podstawowych zasadach: komunikacja, feedback, prostota i … odwaga Koncentracja na zaspokojeniu potrzeby biznesowej Fazy procesu XP służą planowaniu celów Koncentracja na tworzeniu kodów Mało uwagi na dokumentację Duża przestrzeń dla swobody i kreatywności twórców Skupienie na redukcji kosztów Nie nadaje się dla dużych projektów Główne praktyki XP: Testowanie Programowanie w parach Używanie kart CRC (Class, Responsibility, Collaboration) Możliwość stosowania XP łącznie z innymi metodologiami Crystal Methodologies - rodzina Podział: białe (jasne), żółte, pomarańczowe, brązowe, niebieskie, fioletowe Koncentracja na wartości: „komunikacja, ludzie, produkty i samoadaptacja” Główne elementy metodologii dotyczą: działania oprogramowania i komunikacji interpersonalnej Koncentracja na czynnikach sukcesu projektu oraz zapewnieniu zespołowi warunków pozwalających na kreatywną i ciekawą pracę Zastosowanie do małych projektów Redukcja dokumentacji „lessons learned” (w tym nieformalne doświadczenia) Tworzenie oprogramowania grą zespołową – stałe współdziałanie dla osiągnięcia celu – dostarczenie oprogramowania Dwie zasady Crystal: Wspólne pomieszczenia robocze Komunikacja face-to-face Dynamic Systems Development Methodology Wielka Brytania Używa wielokrotnego prototypowania, aby dostarczyć produkt projektu Czas i zasoby są ustalone Zmienna jest funkcjonalność rezultatów Zazwyczaj jest odwrotnie Nacisk na szybkie znajdowanie rozwiązań Czas jest nadrzędnym celem, przy zachowaniu wymogów jakościowych Prostota, praktyczność i elastyczność rozwiązań dla interesariuszy Rapid Application Development Methodology Tradycyjne metodologie tworzenia oprogramowania: Identyfikacja potrzeb klienta/użytkownika Sformułowanie specyfikacji i wymogów (funkcjonalnych oraz technicznych) Tworzenie oprogramowania Testowanie To wszystko trwa – RAD skraca postępowanie Problem: zmiany w technologii wytwarzania produktu. Konsekwencja: wymagana dynamika/elastyczność podejścia PM RAD dokonuje scalenia/kompresji czterech faz w dynamiczne serie krótkich, iteracyjnych cykli RAD używa krótkich faz w projekcie – wyniki są osiągane szybciej Niemal natychmiastowe wyniki – konkretny produkt (do dopracowania) Tworzenie rozwiązania/produktu, doskonalonego, aż do satysfakcji klienta Cechy metodologii RAD Tworzenie zespołów mniejszych niż przeciętnie Zintegrowany (mieszany) skład zespołów projektowych Analiza, projektowanie, wytwarzanie i testowanie są skompresowane w dynamiczną serię krótkich, iteracyjnych cykli Zadania są wykonywane raczej współbieżnie aniżeli sekwencyjnie Fazy projektu są krótkie, cykliczne i nadzwyczaj dynamiczne Krótsze fazy dają szybsze osiąganie korzyści Kolejne wersje produktu uwzględniają potrzeby klienta - każdy cykl dostarcza funkcjonalną wersję rozwiązania Wersje produktu nie są pełnym prototypem, raczej roboczą wersją RAD bierze pod uwagę zmiany technologiczne i podejmuje szybkie decyzje Metodologia polega na zmianach inkrementalnych, prowadzących do końcowego produktu Zespół projektowy rozumie nieuchronność zmian Metodologia klasyczna Inicjowanie Planowanie Analiza Projekt Tworzenie Testy Produkt RAD Analiza Projekt Tworzenie Inicjowanie Planowanie Testy Przywództwo Zespół Produkt Przegląd klienta Rys. 1. Metodologia klasyczna vs. RAD Scrum Methodology Scrum: Zwinna metodyka zarządzania złożonymi projektami Elementy: role, zdarzenia, artefakty, zbiory reguł Autorzy: Ken Schwaber, Jef Sutherland Cechy: lekka, łatwa do zrozumienia, trudna do opanowania Scrum: jest ramowym zestawem sposobów postępowania, umożliwiających stosowanie różnych technik i procesów umożliwia doskonalenie praktyk zarządczych i inżynierskich Teoria Scruma bazuje na empiryzmie. Podejście iteracyjne i przyrostowe lepsza przewidywalność i kontrola ryzyk Zasady kontroli empirycznej procesu: przejrzystość, inspekcja, adaptacja Przejrzystość: wszystkie aspekty procesu są opisane powszechnie znanymi standardami Inspekcja: rozsądnie częsta, dotyczy artefaktów i postępów na ścieżce prowadzącej do celu Adaptacja: aspekt procesu przekroczył ustalone limity jak najszybsza korekta procesu/materiału Cztery punkty inspekcji i adaptacji Planowanie sprintu (Sprint Planning Meeting) Codzienny Scrum (Daily Scrum) Przegląd sprintu (Sprint Review) Retrospektywa sprintu (Sprint Retrospective) Role: Zespół Scrumowy (Scrum Team) Scrum Master Właściciel Produktu (Product Owner) Zespół Deweloperski (Development Team) Scrum Master: odpowiada za rozumienie i stosowanie teorii Scruma przez Zespół Scrumowy; wspiera Właściciela Produktu, Zespół Deweloperski i całą organizację Właściciel Produktu: maksymalizacja wartości dodanej produktu i pracy Zespołu Deweloperskiego Zespół Deweloperski (projektowy): profesjonaliści, dostarczający na koniec każdego sprintu produktu, gotowego do wydania przyrostu Zdarzenia w Scrumie: służą regularności i ograniczania potrzeby dodatkowych spotkań. Każde zdarzenie to okazja do inspekcji i adaptacji. Sprint: esencja Scruma; 1 miesiąc; wytwarzany przyrost potencjalnie gotowej funkcjonalności; stała długość. Sprint: planowanie sprintu, codzienne Scrumy, okres wytwarzania, przegląd sprintu, retrospektywa sprintu. Planowanie sprintu: spotkanie max. 8 h, cały Zespół Scrumowy; co ma być dostarczone, jaką pracę trzeba wykonać. Codzienny Scrum: codzienne, 15 min. spotkanie, tylko Zespół Deweloperski Przegląd sprintu: spotkanie na koniec Sprintu, inspekcja, ew. dostosowanie Rejestru Produktu Retrospektywa sprintu: Zespół Scrumowy robi inspekcję swych działań, plan usprawnień dla kolejnego sprintu. Po przeglądzie. Artefakty Scruma: wyniki pracy lub jej wartości, aby możliwe były inspekcja i adaptacja: Rejestr Produktu: uporządkowany zestaw wszystkich elementów produktu; jedyne źródło wymaganych zmian. Rejestr sprintu: zbiór elementów Rejestru Produktu wybranych do sprintu plus plan dostarczenia Przyrostu i realizacji celu sprintu. Przyrost funkcjonalności: łączne elementu Rejestru Produktu zakończone podczas sprintu i sprintów poprzednich. Definicja Ukończenia (elementu Rejestru Produktu albo Przyrostu): jednoznaczność rozumienia. Reguły wiążą ze sobą i definiują relacje między rolami, zdarzeniami i artefaktami. Scrum istnieje tylko w swej pełnej postaci – wszystkie role, zdarzenia, artefakty i reguły. 2. ScrumMaster Odpowiednik Kierownika Projektu Odpowiedzialność: proces SCRUM Proces: definiuje zasady, warunki zaspokojenia potrzeb, artefakty i terminologię Rola pasterza – utrzymać stado w całości, a wilki przegonić 23.04. Firma 1. Sytuacja początkowa Firma tworzy oprogramowanie do generowania kodu Zła sytuacja finansowa (wysokie koszty) ScrumMaster w akcji: Propagowanie SCRUM Zwalczanie postaw szkodzących („ciągotki” ku staremu) Zachęcanie właściciela produktu do stosowania SCRUM – konflikt interesów – przekonanie go Wartość roli ScrumMaster Godzenie różnych oczekiwań poprzez sprinty Blokowanie wpływów zewnętrznych podczas sprintu Zmiana priorytetów prac zespołu Szybkie reagowanie na rosnące potrzeby klienta Rola ScrumMaster Różna od roli PM Odpowiada za sukces projektu: Pomoc właścicielowi produktu w wyborze najbardziej wartościowych zaległości; pomoc zespołowi w przetworzeniu ich w funkcjonalności Władza pośrednia, oparta na wiedzy SCRUM Zasady pracy – łatwe, wdrożenie - trudne Trudności Interpretacja Scrum przez pryzmat dotychczasowych doświadczeń Niezrozumienie zasad samoorganizacji, krytycznych sytuacji, widoczności i cyklów inspekcji z adaptacją Niezrozumienie zmiany paradygmatów: Kontrola – przekazywanie uprawnień Kontrakty – współpraca Dokumentacja - kodowanie Firma 2. Niekompetentny ScrumMaster Działalność: pozyskiwanie kultur tkanek ze służby zdrowia – przekazywanie firmom farmaceutycznym Wartość dodana: spis, demografia, rodzaje chorób i ich zaawansowanie Błąd: „jego Scrum”, on zlecał zadania członkom zespołu Lessons learned Teoria codziennego spotkania SCRUM Co zrobiłem od ostatniego Scrum? Co zamierzam zrobić przed następnym Scrum? Co mi przeszkadza w pracy? Zła interpretacja Sprawdzanie, czy członkowie zespołu „to” zrobili Narzucenie im, co mają zrobić przed kolejnym Scrum Sprawdzenie, co może zrobić, aby usunąć przeszkody Pominął Przejście: szef – trener (coach) Przejście: kontrola – ułatwienia Lekceważenie roli samoorganizacji demotywacja członków zespołu Firma 3. Niekompetentny ScrumMaster Działalność: sprzedaż oprogramowania do planowania Stosowane podejście: klasyczne (sekwencyjne) Efekt – wydłużające się terminy Błąd: niezrozumienie roli „owczarka” Lessons learned ScrumMaster nie zrozumiał swej roli „ułatwiacza” zamiast menedżera, roli „owczarka” zamiast „rozkazodawcy” Przejście „władza” – „ułatwiacz” stanowi problem dla wielu Zespół potrzebuje ochrony, pomocy, a nie nakazów i rozliczeń ScrumMaster liderem, a nie kierownikiem Firma 4. Nadgorliwy ScrumMaster Działalność: sprzedaż oprogramowania dla służby zdrowia Problem: konkurencja firm internetowych, pośrednicy klient-służba zdrowia Rozwiązanie – Firma 4.com; internet; portal połączony z istniejącymi w Firmie 4 systemami kilka dużych projektów (m.in. dot. stosunków społecznych) Błędy Nieuwzględnienie kultury firmy Nieuwzględnienie priorytetów Narzucanie metody Scrum wbrew woli kierownictwa firmy Nietrzymanie nerwów na wodzy Lessons learned Nieudana ocena wartości pracy zespołowej w firmie „Scrum dotyczy rzeczy możliwych. Martwy owczarek jest niepotrzebny” Firma 5. Wilki Działalność: zarządzanie funduszami Problem: przegapienie rewolucji technologicznej (internet, komórki, mobilne technologie samodzielność klientów) Koło ratunkowe CMM (Capability Maturity Model – pomyłka) Rozwiązanie skuteczne - Scrum Atak wilków Ingerencja „z boku” – naruszenie zasad Scrum Efekt1: raportowanie prac nie związanych ze Sprintem ani z zaległościami produktowymi Efekt2: pogwałcenie podstawowej reguły Scrum – autonomii zespołu Efekt 3: zrozumienie i ekspiacja osoby odpowiedzialnej za zamieszanie Lessons learned Znaczenie uwidoczniania wszystkiego na bieżąco Zaległości produktowe + priorytety powszechnie dostępne Rola codziennego Scrum w tym uwidocznianiu – ScrumMaster może stosować reguły, a zespół pozostać na właściwej ścieżce Podsumowanie Kto walczy, kto jest kibicem? Świnią czy kurczakiem? Zobowiązania a zaangażowanie? Szynka czy jajka? Podsumowanie roli ScrumMaster Usuwa bariery między projektantami/wykonawcami, a właścicielem produktu Uczy właściciela produktu maksymalizacji zwrotu kosztów i osiągania swych celów przy pomocy Scrum Poprawa życia zespołu poprzez ułatwianie pracy twórczej Poprawa wydajności zespołu – wszelkie akceptowalne sposoby Poprawa inżynierii – aby każdy przyrost funkcjonalności był możliwy do wydania Udostępnianie aktualnych informacji o postępach zespołu wszystkim interesariuszom Zakaz bycia klasycznym kierownikiem Korzystanie z kilku pierwszych Sprintów, aby wdrożyć się w rolę 07.05. 3. Właściciel produktu Realizacja zwrotu wartości zainwestowanej Zaległości produktowe – główne narzędzie kierowania projektem sprint po sprincie, aby maksymalizować zysk Zaległości produktowe – możliwość nadania priorytetów wymaganiom o najwyższej wartości biznesowe; adaptacja produktu do zmian (klient, biznes, konkurencja) Firma 6. Sytuacja początkowa Właściciel rurociągów (gaz, paliwa, ropa) – wynajem (Ameryka Płn.) Bardzo duża firma Tantiemy dla prywatnych właścicieli gruntów Problem: częste zmiany właścicielskie; archaiczna („ręczna”) metoda ustalania adresów aktualnych właścicieli (czasoi kosztochłonna) Inny problem: różne prawo/procedury właścicielskie w różnych stanach Decyzja: Scrum Właściciel produktu w akcji: Ustalił priorytety: proces automatyzacji przed przeniesieniem danych między serwerami Pierwsze sprinty – mniej biznesowej funkcjonalności (rozruch trwa i kosztuje) Aktualizacja bazy o niezbędne dane Automatyzacja zasilania bazy danych, scenariusze rozstrzygania konfliktów redukcja i automatyzacja pracy Satysfakcjonujący przyrost produktu po pierwszym sprincie Dwutygodniowy sprint implementujący ten przyrost zmniejszenie obciążenia pracą członków oddziału ds. własności gruntów o 40% Wartość roli właściciela produktu Odpowiada za zwrot kosztów inwestycji wybór funkcjonalności, rozwiązującej zasadnicze problemy biznesowe Wzywa do wydania innych funkcjonalności, w miarę potrzeb i możliwości Zwrot kosztów inwestycji w krótkim czasie Rola właściciela produktu Ciągła współpraca z zespołem Ciągła współpraca ze ScrumMaster, który jest buforem między nim a zespołem programistów i klientami („ułatwiaczem”) Zwrot kosztów inwestycji w krótkim czasie Firma 7. Przywracanie zarządu do działania Działalność: średniej wielkości sprzedawca oprogramowania; wielu małych klientów Sytuacja: powierzenie stworzenia kolejnej wersji oprogramowania (poprzednia nie była gotowa) Metoda: CPM i Gantt, potem decyzja: Scrum Rozwiązanie skuteczne – Scrum Spotkanie przeglądu sprintu (7 zespołów); udział „top management” firmy Lessons learned Zastąpienie formalnego raportowania – współpracą Kilkugodzinne spotkania z zarządem firmy Spotkania „top management” podsumowująco/oceniające współpracę SUPER! Firma 5. Naprawa problemu XFlow Ukryty w cieniu „X” - właściciel produktu Dlaczego to zrobił? Jak to zrobił? Konflikt inżynierowie (rentowność)wewnętrzni klienci (problemy operacyjne) Czy pomocne byłyby spotkania obu grup? – problem: żadna z nich nie dawała X prawa nadawania priorytetów Rozwiązanie Spotkanie obu grup Komunikacja bezpośrednia – argumentacja Wyjście naprzeciw oczekiwaniom drugiej strony – szukanie kompromisów – zrozumienie podejścia przez obie grupy Skupienie się X na kluczowym podejściu Scrum: najpilniejsze potrzeby, najbliższa przyszłość, krótkoterminowy plan działań Wybór 7 elementów i 3 błędów do naprawy – 30 dni – akceptacja przez wszystkich Po tym sprincie prezentacja wyników klientom wewnętrznym przez inżynierów – niemal zachwyt X proponuję listę priorytetów funkcjonalności na następny sprint - obie grupy ją aktualizują Lessons learned X nie był typowym dla Scrum właścicielem produktu – „utajnianie” tego podejścia X stosował zasadę „Scrum sztuką rzeczy możliwych” Spotkania obu grup „face to face” pokazały zbieżność potrzeb i problemów obu Te grupy wcześniej się nie spotykały – a to jest warunkiem koniecznym postępu w pracach nad projektem Firma 8. Cele firmy Działalność: początkująca firma telekomunikacyjna Charakterystyka: pościg za szerokim pasmem, większą przepustowością – technologicznie, możliwość o 4000% Patenty młodych naukowców z MIT w tej firmie Problemy: konkurenci chcą wykupić, sprzeciw właściciela X (zbyt tania oferta) Użyteczność Scrum Korzystne zestawienie zaległości produktowych Przeciążenie X – poprzednio całodniowe przeglądy, dotyczące nielicznych marnotrawstwo czasu większości Rozwiązanie – codzienne Scrum Problem – zakupy deficytowych komponentów Rozwiązanie – dwóch młodszych inżynierów Lessons learned Zaangażowanie właściciela w rozwoju produktu – rozwiązanie krytycznych problemów Zatrudnienie młodszych inżynierów odciążyło starszych w rozwiązywaniu trudnych problemów Efekt – 3-krotny wzrost wartości firmy po 1 miesiącu od prezentacji wyników Firma 9. Cele systemu transferu funduszy Działalność: instytucja finansowa (w czołówce w USA – wpływ na rynki walutowe) Rozmowy z ludźmi biznesu – wymagania językowe System przelewów – FTS (Found Transfer System) Fakt1: zamiar opracowania nowszej wersji systemu Fakt2: zmiana na kluczowych stanowiskach Użyteczność Scrum Prezentacja Scrum dla trzech kluczowych osób Tworzenie listy zadań do wykonania w cyklu 30-dniowym, uwzględniająca priorytety Przegląd funkcjonalności, kolejnych zadań do wykonania i wybór zadań na następny Sprint Pozytywne podejście zespołu – tylko jedno spotkanie miesięcznie Efekt: w ciągu godziny zespół wybrał istotne zaległości produktowe, też zaległości sprintu Lessons learned Bagatelizowanie metodyki Scrum w oczach zespołu FTS Zespół nie potrzebował języka Scrum – mieli swój Stosowali Scrum, nie używając jego terminologii Bagatelizowanie Scrum uprościło współpracę zespołu FTS z innymi zespołami Podsumowanie Cztery sytuacje – w każdej znalazł się właściciel produktu (świadomie bądź nieświadomie) W każdym przypadku ScrumMaster doprowadzał do i organizował spotkania właściciela produktu z zespołem Powyższa współpraca – świadoma bądź utajniona; zawsze pożyteczna Zespół i właściciel uczą się nawzajem rozumieć - przedtem rozmawiali w różnych językach Właściciel nie nauczy się technologii – raczej zespół podejścia biznesowego Wspólny mianownik obu stron – zaległości produktowe Wspólny język jest krytycznym czynnikiem sukcesu projektu 14.05. 4. Zespół Scrum Odpowiedzialność za zarządzanie rozwojem Zespół wybiera prace do wykonania i kieruje nimi podczas kolejnych sprintów Zmiana wymagań (decyduje zespół) – chodzi o wydanie przyrostu funkcjonalności produktu Narzucanie kierowania z zewnątrz prowadzi do niepowodzenia Firma 10. Sytuacja początkowa Działalność- sprzedaż oprogramowania (wielu małych klientów) Dobre opinie o produktach Grupa programistów – prace nad nowym wydaniem oprogramowania Decyzja o zastąpieniu podejścia klasycznego metodyką Scrum Zespół w działaniu Szkolenie – przygotowanie do pierwszego sprintu Koncentracja na aktywności i zaangażowaniu zespołu Wniosek – zbyt duży zespół (powinno być kilku, a nie kilkunastu członków) Decyzja zespołu – podział na kilka podzespołów (efektywność prac) Zapewnienie spójności, min. powtarzalności Wartość zespołu Zaangażowanie zespołu w realizację, identyfikacja z celem sprintu Wymyślenie sposobu na osiągnięcie celu Tworzenie zespołu w firmie 10. Wydajność metodyki – realizacja zadań w kolejności (priorytety) Jej realizacja przez zespół – samoorganizacja i samozarządzanie Istota – sprint – zespół pracuje na max – prezentacja właścicielowi produktu (działająca funkcjonalność) Ważne dla zespołu – poczucie autonomii Trudność: przejście od zespołu zarządzanego do samozarządzającego. Efekty – wydajność i zadowolenie z pracy odpowiedzialny za powyższe – ScrumMaster Stwierdzenie: ScrumMaster nie jest kierownikiem zespołu ani projektu Przejrzystość wiodącą zasadą – wszyscy muszą wiedzieć, gdzie każdy z nich się znajduje Nauka organizacji kolejnych sprintów: uszczegółowianie zadań, realistyczne planowanie transformacji zaległości produktowych w funkcjonalności Wynik: odkrycie i wykorzystanie nadwyżek czasu i energii Wynik: zadowolenie ze współpracy i pomocy Integracja programistów i testerów Podział na podzespoły optymalizacja przydziału osób do podzespołów (do niezbyt wielu) Scrum – sztuka rzeczy możliwych zalety – częste i regularne dostarczanie funkcjonalności, motywacja zespołu, poprawa warunków pracy, doskonalenie jakości Implementacja empirycznego podejścia przez Scrum na zasadzie inspekcji i adaptacji Porównanie szacunków z wartościami rzeczywistymi – różne sposoby ukrywania prawdy Kłopoty i problemy zespołu: samodzielność, presja czasu (Sprint), model kaskadowy nie spełnia oczekiwań Decyzja Zarządu - Scrum Główne zadania – wdrożenie metodyki określenia zaległości produktowych do najbliższego wydania, wyznaczenie zespołów projektowych, dobór ich członków Wspólne przestrzenie robocze dla zespołów (komunikacja) Eliminacja zbędnych artefaktów- dokumentów wspierających metodykę kaskadową Promowanie osoby ScrumMastera Sytuacja: izolacja członków zespołu: biura, boksy, brak komunikowania się Dodatkowe źródło izolacji – podejście kaskadowe Komunikacja pisemna, zamiast „face to face” Sprinty zmieniły radykalnie tę sytuację Lessons learned Dominuje tradycja relacji „przełożonypodwładny” Wiodąca rola – ScrumMaster (pracuje nad zespołem, ale i nad samym sobą) Zespół musi nauczyć się zarządzania samym sobą ScrumMaster jest odpowiedzialny za proces i usuwanie przeszkód, lecz nie za zarządzanie funkcjonalnością tworzonego produktu Ważna jest współpraca ScrumMaster i zespołu aby osiągnąć najlepsze wyniki Ulepszenia winny dotyczyć całego systemu, a nie podsystemów Inspekcja i adaptacja – niezbędna wiedza, co podlega inspekcji Scrum jest trudny w stosowaniu – wymaga częstych inspekcji i adaptacji. Doświadczenie – zarząd firmy w końcu akceptuje Scrum Boksy usunięto Przestrzeń typu „hol” służy spotkaniom, wymianom Firma 11. Komentarz: Scrum zwiększa wydajność zespołu o rząd wielkości. Decydująca rola – rosnące zaangażowanie zespołu, wzajemna pomoc Sytuacja początkowa Jeden z pierwszych wydawców wiadomości w internecie Przewaga konkurencyjna – silnik analizy leksykalnej błyskawiczny dostęp do informacji według dowolnego kryterium Kolejny atut – zwiększenie stopnia elastyczności silnika, umożliwiająca analizę źródeł wiadomości Powyższe wymagało, by Thomas Sun (odludek) został częścią zespołu (zaprzyjaźnioną „świnią”). Zgodził się. Wykonał zadanie, przetestował rozwiązanie, uspokoił zespół. Wyjechał na 2 tygodnie, bez możliwości kontaktu. W tym czasie problemy, potem awaria silnika analizy leksykalnej wściekłość i rozpacz zespołu – funkcjonalność była już ogłoszona publicznie Sprint był porażką – cel nieosiągalny Rozwiązanie – prywatny detektyw odnalazł Thomasa, on wspomógł zespół, cel sprintu osiągnięty Lessons learned Ogromne pretensje Thomasa do ScrumMastera (naruszenie prywatności) Obie strony konfliktu mają mieszane uczucia; sytuacje takich trudnych wyborów nie są rzadkością Podsumowanie Firma 10. – przed wdrożeniem Scrum grupa osób pracowała indywidualnie, w izolowanych miejscach. Analogia – karanie niegrzecznego dziecka „kątem” Prosimy ludzi o zrobienie czegoś możliwego – przeważnie próbują Prosimy ludzi o zrobienie czegoś nieco powyżej ich możliwości – próbują, o ile nie będą karani za niewykonanie wszystkiego Gdy ludziom oferuje się pomoc, zachęca i docenia – przeważnie dają z siebie wszystko Praca w zespole – efekt synergii (do granicy 7 +/- 2) Zaległości produktowe napędzają mechanizm osiągania najlepszych wyników Sytuacja w firmie 10. ex post zmieniła się na korzyść – ludzie chcą usprawnić, organizację, zespoły, samych siebie i realizację swych zadań. 21.05. 5. Zdarzenia w Scrum - sprint, planowanie sprintu Sprint: esencja Scruma; 1 miesiąc; 30-dniowa iteracja Spotkanie planujące sprint 8 godz., dwie równe czasowo części. Pierwsza – określenie zaległości produktowych, druga – przygotowanie zaległości sprintu Uczestnicy – właściciel produktu i zespół; każdy z nich może zaprosić dodatkową stronę – obserwatora – za wyjątkiem kurczaka Właściciel produktu przygotowuje zaległości produktowe przed spotkaniem. W razie jego nieobecności lub braku przygotowania, zastępuje go w pełni ScrumMaster Cel pierwszej części spotkania – zespół selekcjonuje te części zaległości produktowych, które jest w stanie zamienić w możliwy do wydania przyrost funkcjonalności. Będą one przedstawione właścicielowi produktu podczas przeglądu sprintu (jego zakończenie) Zespół proponuje, ostateczna decyzja co do zaległości produktowych sprintu należy do właściciela produktu Zespół określa, jaka część zaległości produktowych zamierzonych przez właściciela produktu będzie realizowana w trakcie sprintu Ograniczenie 1. części do 4 godzin jest nieprzekraczalne. W razie niewykonania analizy zaległości produktowych, jest ona dokończona podczas sprintu Druga część spotkania planującego ma miejsce zaraz po pierwszej, czas też 4 godz. Obecność właściciela produktu obowiązkowa – mogą być pytania Zespół, całkowicie autonomicznie, opracowuje w 2. części strategię realizacji zamiany zaległości produktowych w przyrost możliwej do wydania funkcjonalności produktu. Inni uczestnicy mogą tylko obserwować lub odpowiadać na pytania członków zespołu Wynik drugiej części spotkania planującego sprint to: Lista zadań (zaległości sprintu) Ocena zadań wraz z przydziałem do nich osób – początek realizacji funkcjonalności Lista może być niekompletna, ale na tyle obszerna, by pokazać wspólnotę zobowiązań zespołu i zapewnić mu pracę przez pierwszą część sprintu. Podczas tego okresu zespół określi pozostałe zadania i doda je do zaległości sprintu Sprint 30 dni – kompromis: można coś zrobić, co zainteresuje właściciela i co jest możliwe do wydania Zespół może w czasie sprintu współpracować z otoczeniem Zespól jest całkowicie samozarządząjący sobą Zespół zobowiązuje się do wykonania zaległości produktowych – zamrożonych na czas sprintu W razie niewykonalności sprintu, ScrumMaster może awaryjnie sprint zakończyć; nowe spotkanie planujące sprint; nowy sprint Zespół może, po konsultacji z właścicielem, usunąć te elementy zaległości, których nie jest w stanie wykonać Zespół może, po konsultacji z właścicielem, dodać inne elementy zaległości produktowych Dwie odpowiedzialności członka zespołu: uczestnictwo w codziennym sprincie, publikowanie wszystkim aktualnych zaległości sprintu Rys. 2. Sprint 6. Zdarzenia w Scrum - monitorowanie sprintu, sprint ex-post (retrospektywa sprintu) Codzienne spotkanie SCRUM Czas – 15 min. Codziennie, ta sama pora, to samo miejsce – najlepiej na początku dnia Obecni wszyscy członkowie zespołu, ewentualne substytuty Punktualność; kara – 1 dolar Każdy zdaje raport – 3 pytania: Co zrobiłeś od wczoraj? Co zrobisz do jutra? Co utrudnia ci efektywne wykonywanie pracy? Jedynie raportowanie Mówi TYLKO JEDNA OSOBA W razie potrzeby, spotkanie zainteresowanych po codziennym SCRUM Kurczaki tylko słuchają Kurczakom nie wolno rozmawiać z członkami zespołu po spotkaniu Świnie i kurczaki naruszające zasady mogą być usunięte z zespołu (świnie), bądź ze spotkania (kurczaki) Spotkanie przeglądu sprintu Ograniczenie – 4 h Cel – zaprezentowanie właścicielowi i udziałowcom wykonanej funkcjonalności – tylko tej zrealizowanej Rozpoczyna prezentacja (jeden z członków): cel sprintu, zobowiązania wykonania zaległości produktowych, tychże ukończonych. Inni członkowie mogą omawiać dobre i złe strony wykonania Odpowiedzi na pytania udziałowców, notowania wymaganych zmian Pytania do udziałowców: ich opinie, zmiany, priorytety zmian Dyskusja właściciel-udziałowcy-zespół dot. przedefiniowania zaległości produktowych Przestrzeń na kreatywność - np. nowe funkcjonalności , priorytety ScrumMaster uzgadnia miejsce i datę następnego przeglądu sprintu i ogłasza je Retrospektywne spotkanie sprintu Limit: 3 h. Członkowie zespołu, ScrumMaster (obowiązkowo), właściciel produktu (opcjonalnie) Początek: co poszło dobrze, co mogłoby być ulepszone (wszyscy) ScrumMaster zapisuje Zespół ustala kolejność rozmów dotyczących ulepszeń ScrumMaster jest „ułatwiaczem” w poszukiwaniu lepszych metod wykorzystania procesu Scrum Elementy zaskarżalne, które mogą być przeniesione do kolejnego sprintu, będące niefunkcjonalnymi zaległościami produktowymi, powinny być zakwalifikowane jako te o wysokim priorytecie Firma 10. Porządkowanie chaosu Planowanie i zarządzanie skomplikowanymi projektami: PERT, Gantt Komplikacja - podział na role: analiza, projektowanie, kodowanie, testowanie, tworzenie dokumentacji Efekt1: wzajemna izolacja osób pracujących nad poszczególnymi funkcjonalnościami Efekt 2: kaskadowe podejście do pracy, brak możliwości współpracy Efekt3: bałagan, błędy w oprogramowaniu (produkcie) Efekt 4: syndrom studenta Efekt 5: wyczerpanie i zniechęcenie członków zespołu Decyzja: Scrum, czas wdrożenia – 2 tygodnie Spotkanie z zespołem – ujawnienie problemów (praca nad dwoma produktami) – jedni nie skończyli zadań, inni czekali na wyniki, obijając się Wniosek – zespół nie był właścicielem swych prac, wykonując odgórne polecenia Propozycja rozwiązania – spotkanie planujące sprint Członkowie zespołu ustalili priorytety Ustalono listę wymagań funkcjonalnych i niefunkcjonalnych Metoda – śledząca kula. Czy zespół mógł utworzyć moduły obsługi kredytów spełniających wszystkie niefunkcjonalne wymagania w zaległościach produktowych? Czy zespół był w stanie to wykonać w ciągu 30 dni? Wymaganie od zespołu – niewielki kawałek funkcjonalności, obsługujący oba produkty (zadowolenie klienta, że to ten sam produkt) Efekty: poczucie sukcesu zespołu, zadowolony klient, wiedza kierownictwa Lessons learned Wymyślanie wszystkiego od razu we wczesnej fazie złożonego projektu jest bardzo trudne Zadania przestają być aktualne wkrótce po ich przydzieleniu Praca sekwencyjna podzieliła zespół trudności w komunikacji i współdziałaniu Szalone tempo w ostatnich 2-3 miesiącach „wypalony” zespół Skupienie się na przyrostach funkcjonalności zapewnia postępy w kierunku ukończenia wydania Iteracyjne i przyrostowe praktyki Scrum dają zespołowi poczucie spełnienia Scrum jest empiryczny; stosuje częstą inspekcję i adaptację Zespoły same znajdują swe własne rozwiązania 28.05. Firma 12. Porządkowanie chaosu Sytuacja początkowa Publikacja profesjonalnych czasopism z różnych dziedzin, również w sieci Problem – opóźnienia (tylko 1 tytuł w terminie); przyczyna – różnice w technologii Pytania do wydawcy: Zapewnienie estetyki w trybie online? Modyfikacja procesów redakcyjnych i produkcyjnych umożliwiających online? Najlepszy mechanizm umieszczania w sieci? Chaos w poszukiwaniach rozwiązania – kontakt z WebPub (firma internetowa) – wykupienie jej – ukierunkowanie jej prac na swe publikacje Kłopoty – istniejąca platforma WebPub wymagała modyfikacji dla wydawania czasopism firmy 12. Podjęte decyzje poprawek w platformie WebPub, nowych formatów niewykonalne terminy publikacji Decyzja: Scrum; kierownictwo 12. ceniło przyrostowe dostarczanie funkcjonalności, konkretnie pokazujące postęp Spotkanie planujące sprint dla zespołu każdego czasopisma (każdy – 9 osób) Sporządzenie zaległości produktowych funkcjonalności Nadanie priorytetów – najwyższe niefunkcjonalne (struktura danych, możliwości wydawnicze WebPub) Lessons learned Zbyt złożone relacje miedzy zespołami wymagają modyfikacji Scrum Złożoność częstotliwość inspekcji ilość okazji do adaptacji Zespoły tworzyły zależne oprogramowania, ich przyrosty funkcjonalności powstające podczas sprintów przeplatały się Rozwiązanie – zmiana składu zespołów – każdy miał jedną osobę zaznajomioną z każdym elementem skomplikowanej sytuacji i posiadającą autorytet Firma 13. Porządkowanie chaosu Sytuacja początkowa Pozyskiwanie informacji z masy danych – łączenie danych (data fusion) Złożoność, różne umiejętności, wytrwałość (projekt rządu USA, po 11.09.2011.) Dane z agencji, nie znających słowa „współpraca” Konieczność utworzenia nowych technologii Dostosowanie algorytmów łączenia danych – wyszukiwanie „igły w stogu siana” Konieczność „dowodu działania” – odpowiadali eksperci od algorytmów, baz danych, technologii łączenia i programiści; efekt – niepowodzenie Decyzja: Scrum; 2-dniowe uczenie metodyki i planowanie sprintu Pierwszy dzień – porażka, nie zrozumieli sprintu, nie stali się samoorganizującym się zespołem; przyczyna – tajne dane agencji rządowych; odmienne dane z różnych źródeł Rozwiązanie – spotkanie: koncepcja (hipotetycznych) zaległości produktowych, lista zaległości, analiza i wybranie prac podczas pierwszego sprintu Zespół uświadomił sobie, że ograniczony czas wymusza ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność 2 godz. – zespół opisał, co może wykonać samoorganizacja zespołu osiągnięta! Scrum zrozumiany Zamiana hipotetycznych zaległości produktowych w rzeczywiste Nowe spotkanie, planujące sprint dla rzeczywistych zaległości produktowych Lessons Learned Wymagana elastyczność i skuteczność ScrumMaster w różnych okolicznościach; firma 13. – związane ręce brakiem informacji Samoorganizacja i współpraca najlepiej rozumiane na prawdziwych przykładach/problemach. W firmie 13. trzeba było przejść od hipotez do rzeczywistości. Firma 14. Zarządzanie gotówką Sytuacja początkowa „14” to jedna z największych instytucji finansowych na świecie 2 lata: 20% projektów programistycznych wykorzystuje Scrum Kolejny projekt: „Aplikacja gotówkowa” – zapisywanie i raportowanie transferów Dwudniowe (wstępne) spotkanie planujące sprint: Pięciu programistów, właściciel produktu, ScrumMaster, kierownik wdrażania systemów Podstawy Scrum Brak listy zaległości produktowych, aby rozpocząć spotkanie planujące sprint Niezrozumienie przez zespół takiej procedury – chcieli „iść do przodu” Konsultant przekonał zespół do wartości listy zaległości produktowych – wyznaczenie linii bazowej Szacowanie zaległości produktowych Wątpliwości zespołu co do sensowności i rzetelności oceny Rozmowy, negocjacje dotyczące tematu Problem – mała dokładność szacunków Podpowiedź: Scrum jest empiryczny – „sztuka rzeczy możliwych” Śledzenie zaległości produktowych każdego sprintu Zakończenie każdego sprintu – uaktualnianie oczekiwań zarządu; podstawa - śledzenie Efekt – trafne oszacowania Analiza – co znaczy „zrobione”? Niezrozumienie znaczenia „szacowanie” Znaczenie testowania funkcjonalności Uaktualnianie szacunków Część pracy przekazana do Działu Jakości Efekt: priorytety zaległości elementów produktowych Zmiany są trudne Rozbieżności w rozumieniu „zrobione” Efekt: czas realizacji z 5 do 7 miesięcy Problem1: dotychczasowe sztywne trzymanie się terminów w „14.” Aktualizacja terminu: w wyniku pierwszego (i dalszych) sprintów Problem2: w „14” wierzono, że można dokładnie przewidzieć przyszłość i że nie trzeba będzie modyfikować przewidywań Lessons Learned Firma winna się przeorganizować, aby skorzystać z metodyki Scrum Kultura zarządzania „14” postrzegała wstępne szacowania czasu/pracochłonności jako umowę Scrum – każde spotkanie podsumowujące sprint pokazuje różnice: Szacunki – rzeczywistość Możliwości zespołu – rzeczywiste wykonanie Dla zarządu okazja do rozwinięcia/złagodzenia oczekiwań Niewiele projektów umożliwia przeprowadzenie obiektywnej analizy ilościowej w celu podejmowania optymalnych decyzji Po każdym sprincie właściciel odpowiada za pokazanie zespołowi zadań o największej wartości dla organizacji Chodzi nie tylko o zamianę zaległości w funkcjonalność, ale i stosowanie się do praktyk inżynierskich/standardów 7. Artefakty Scrum – rejestr produktu, rejestr sprintu, przyrost funkcjonalności produktu Zaległości produktowe Lista zaległości produktowych. Odpowiada właściciel produktu Zaległości nigdy nie są kompletne – dynamicznie się rozwijają Zaległości sprintu Definiują pracę dotyczącą zaległości produktu Jedynie zespół może zmienić zaległości sprintu Przyrost funkcjonalności produktu Wymóg: zespół tworzy przyrost funkcjonalności produktu, możliwy do wydania DZIĘKUJĘ ZA WSPÓŁPRACĘ i/and HAPPY PROJECTS!!! Projekt współfinansowany przez Unię Europejską w ramach środków Europejskiego Funduszu Społecznego