Zaawansowane zarz dzanie projektami
Download
1 / 136

ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI - PowerPoint PPT Presentation


  • 180 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI' - dino


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Zaawansowane zarz dzanie projektami
ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI

Wrocław, 2013/2014

Opracował i prowadzi

dr inż. Jan BETTA

(Zwinne.pptx)


Cele zaj
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, techniki narzędzi PM

C3 Opanowanie umiejętności praktycznego stosowania w/w metod, technik i narzędzi zarządzania rzeczywistym projektem


Plan zaj
PLAN ZAJĘĆ

I. Metodyki klasyczne (przypomnienie)

  • Podstawowe pojęcia PM – przypomnienie

  • 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)

  • Przegląd:ExtremeProgramming, Crystal, Dynamic Systems Development, RapidApplication Development, Scrum

  • ScrumMaster

  • Właściciel produktu

  • Zespół Scrum

  • Zdarzenia w Scrum - sprint, planowanie sprintu

  • Zdarzenia w Scrum - monitorowanie sprintu, sprint ex-post (retrospektywa sprintu)

  • Artefakty Scrum – rejestr produktu, rejestr sprintu, przyrost funkcjonalności produktu

  • Podsumowanie wykładu


R d a tylko cz ii zwinne
ŹRÓDŁA (tylko cz. II. - zwinne)

  • Highsmith J., Agile Project Management, Wydawnictwo MIKOM, Warszawa, 2005

  • Schwaber K., Sprawne zarządzanie projektami metodą Scrum, Microsoft Press, Warszawa, 2005

  • Charvat J., Project Management Methodologies, John Wiley & Sons, New Jersey, 2003

  • Manifesto for Agile Software Development, http://agilemanifesto.org/


Metodyki zwinne przegl d
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 rozpoczął się w 2001 roku, - dokument (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).


D rozpoczął się w 2001 roku, - dokument eklaracja 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 rozpoczął się w 2001 roku, - dokument ponad procedury i narzędzia

  • Działające oprogramowanieponad 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 samymjedną z podstawowych różnic w stosunku do tradycyjnych technik jest podejście do odchyleń w pierwotnym planie.


Metod charakteryzować się zdolnościąyka 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 przeniesionana ś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 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ę Agilezakł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ę przemodelowaniaswoich procesów, poprzez taką modyfikację funkcjonalności lub zmianę sposobudział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 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ę

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


C 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ęzł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 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ę, 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 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ę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 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ę

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 motywacji pracowników i bezstresowa realizacja projektówProgramming (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, motywacji pracowników i bezstresowa realizacja projektówfeedback, 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 motywacji pracowników i bezstresowa realizacja projektó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 motywacji pracowników i bezstresowa realizacja projektówMethodologies- 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 motywacji pracowników i bezstresowa realizacja projektów

  • Redukcja dokumentacji

  • „lessonslearned” (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 motywacji pracowników i bezstresowa realizacja projektów 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 motywacji pracowników i bezstresowa realizacja projektówApplication 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 motywacji pracowników i bezstresowa realizacja projektówdokonuje 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 motywacji pracowników i bezstresowa realizacja projektów

  • 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 rad rys 1 metodologia klasyczna vs rad
Metodologia klasyczna każdy cykl dostarcza funkcjonalną wersję rozwiązaniaRADRys. 1. Metodologia klasyczna vs. RAD

Inicjowanie

Planowanie

Analiza

Projekt

Tworzenie

Testy

Produkt

Analiza

Projekt

Tworzenie

Przywództwo

Inicjowanie

Planowanie

Produkt

Testy

Przegląd klienta

Zespół


Scrum każdy cykl dostarcza funkcjonalną wersję rozwiązaniaMethodology

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 każdy cykl dostarcza funkcjonalną wersję rozwiązania:

  • 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 każdy cykl dostarcza funkcjonalną wersję rozwiązaniaScruma bazuje na empiryzmie.

Podejście iteracyjne i przyrostowe  lepsza przewidywalność i kontrola ryzyk

Zasady kontroli empirycznej procesu: przejrzystość, inspekcja, adaptacja


Przejrzystość każdy cykl dostarcza funkcjonalną wersję rozwiązania: 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 każdy cykl dostarcza funkcjonalną wersję rozwiązaniaPlanningMeeting)

  • Codzienny Scrum (DailyScrum)

  • Przegląd sprintu (Sprint Review)

  • Retrospektywa sprintu (Sprint Retrospective)

    Role: Zespół Scrumowy (Scrum Team)

  • Scrum Master

  • Właściciel Produktu (ProductOwner)

  • Zespół Deweloperski (Development Team)


Scrum każdy cykl dostarcza funkcjonalną wersję rozwiązania 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 każdy cykl dostarcza funkcjonalną wersję rozwiązaniaScrumie: 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 każdy cykl dostarcza funkcjonalną wersję rozwiązania: 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 każdy cykl dostarcza funkcjonalną wersję rozwiązaniaScruma: 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 każdy cykl dostarcza funkcjonalną wersję rozwiązania: łą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.


  • ScrumMaster każdy cykl dostarcza funkcjonalną wersję rozwiązania

  • 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. każdy cykl dostarcza funkcjonalną wersję rozwiązania

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 konflikt interesów – przekonanie goScrumMaster

  • 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 konflikt interesów – przekonanie go

  • 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 konflikt interesów – przekonanie goScrumMaster

  • 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 konflikt interesów – przekonanie golearned

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ął konflikt interesów – przekonanie go

  • 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 konflikt interesów – przekonanie golearned

  • 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 konflikt interesów – przekonanie goScrumMaster

  • 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 konflikt interesów – przekonanie go

  • Nieuwzględnienie kultury firmy

  • Nieuwzględnienie priorytetów

  • Narzucanie metody Scrum wbrew woli kierownictwa firmy

  • Nietrzymanie nerwów na wodzy

    Lessonslearned

  • Nieudana ocena wartości pracy zespołowej w firmie

  • „Scrum dotyczy rzeczy możliwych. Martwy owczarek jest niepotrzebny”


Firma 5. Wilki konflikt interesów – przekonanie go

  • Działalność: zarządzanie funduszami

  • Problem: przegapienie rewolucji technologicznej (internet, komórki, mobilne technologie  samodzielność klientów)

  • Koło ratunkowe CMM (CapabilityMaturity Model – pomyłka)

  • Rozwiązanie skuteczne - Scrum


Atak wilków konflikt interesów – przekonanie go

  • 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 konflikt interesów – przekonanie golearned

  • 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 konflikt interesów – przekonanie go

  • 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 konflikt interesów – przekonanie go

  • 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.


  • Właściciel produktu konflikt interesów – przekonanie go

  • 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. konflikt interesów – przekonanie go

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 (czaso- i 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 rozstrzygania konfliktów

  • 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 rozstrzygania konfliktów

  • 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 rozstrzygania konfliktów

  • 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 rozstrzygania konfliktów 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 rozstrzygania konfliktów 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 rozstrzygania konfliktów

  • 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ń



Lessons akceptacja przez wszystkichlearned

  • 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 akceptacja przez wszystkich

  • 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ść akceptacja przez wszystkichScrum

  • 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 akceptacja przez wszystkich

Lessonslearned

  • 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 akceptacja przez wszystkich

  • 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ść akceptacja przez wszystkichScrum

  • 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 akceptacja przez wszystkichlearned

  • 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 akceptacja przez wszystkich

  • 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ć akceptacja przez wszystkich

  • 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.


  • Zespół akceptacja przez wszystkichScrum

  • 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. akceptacja przez wszystkich

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 akceptacja przez wszystkich

  • 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 akceptacja przez wszystkich

  • 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 wiedzieć, gdzie każdy z nich się znajduje

  • 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 metodykę kaskadowąlearned

  • Dominuje tradycja relacji „przełożony-podwł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 metodykę kaskadową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 metodykę kaskadową

  • 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 metodykę kaskadową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 zespół. Wyjechał na 2 tygodnie, bez możliwości kontaktu.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 zespół. Wyjechał na 2 tygodnie, bez możliwości kontaktu.

  • 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 zespół. Wyjechał na 2 tygodnie, bez możliwości kontaktu.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.


  • Zdarzenia w zespół. Wyjechał na 2 tygodnie, bez możliwości kontaktu.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: pierwszej, czas też 4 godz.

    • 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 pierwszej, czas też 4 godz.

  • 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, pierwszej, czas też 4 godz.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 jestw 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 pierwszej, czas też 4 godz.


  • Zdarzenia w pierwszej, czas też 4 godz.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: pierwszej, czas też 4 godz.

    • 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ą pierwszej, czas też 4 godz.

  • 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 pierwszej, czas też 4 godz.

  • 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 zmian

  • 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 zmian 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 zmian

  • 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) zmian

  • 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ę



  • 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

    Lessonslearned

  • 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 kierownictwa „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 kierownictwa

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 kierownictwaWebPub (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: kierownictwaScrum; 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 kierownictwalearned

  • 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” jedną osobę zaznajomioną

  • 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: jedną osobę zaznajomioną 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 ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność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ą ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność

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: ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność

    • 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 ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność

  • 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 ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność

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 ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność

  • 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 ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność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


  • Artefakty analizy ilościowej w celu podejmowania optymalnych decyzjiScrum – 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 analizy ilościowej w celu podejmowania optymalnych decyzji

  • 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Ę analizy ilościowej w celu podejmowania optymalnych decyzji

i/and

HAPPY PROJECTS!!!

Projekt współfinansowany przez Unię Europejską w ramach środków Europejskiego Funduszu Społecznego


ad