{"id":55,"date":"2013-04-14T16:18:42","date_gmt":"2013-04-14T16:18:42","guid":{"rendered":"http:\/\/serwer1477166.home.pl\/autoinstalator\/wordpress\/?p=55"},"modified":"2014-03-06T22:59:33","modified_gmt":"2014-03-06T22:59:33","slug":"warsztat-pmi-szacowanie-w-zwinnych-zespolach","status":"publish","type":"post","link":"https:\/\/ijbd.eu\/?p=55","title":{"rendered":"Warsztat PMI – Szacowanie w zwinnych zespo\u0142ach"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
\n
Opublikowany 2013\/04\/16<\/div>\n
\n
\n

W zesz\u0142ym tygodniu mia\u0142em przyjemno\u015b\u0107 uczestniczy\u0107 w warsztatach zorganizowanych przez PMI PC kt\u00f3re prowadzi\u0142 Piotr Burdylo<\/a>. Tematem warsztatu by\u0142o szacowanie w zwinnych zespo\u0142ach. Od jakiego\u015b czasu interesuj\u0119 si\u0119 projektami, kt\u00f3rych celem jest stworzenie oprogramowania i zwinnymi (agile<\/em>) metodami zarz\u0105dzania. Warsztaty sk\u0142oni\u0142y mnie do napisania tego artyku\u0142u, w kt\u00f3rym przedstawiam r\u00f3\u017cnice pomi\u0119dzy zwinnym a klasycznym prowadzeniem projektu tak, jak je obecnie rozumiem.<\/p>\n

Piotr rozpocz\u0105\u0142 warsztaty od prezentacji istotnych element\u00f3w podej\u015bcia zwinnego do zarz\u0105dzania projektami. Zwinna definicja projektu to tymczasowe przedsi\u0119wzi\u0119cie prowadzone w celu dostarczenia unikalnego produktu lub us\u0142ugi. Jak wida\u0107 jest taka sama jak w podej\u015bciu klasycznym (PMI\/PMBOK). W podej\u015bciu zwinnym zwraca uwag\u0119 koncentracja na celu \u2013 produkcie projektu, kt\u00f3ry ma by\u0107 osi\u0105gni\u0119ty w sko\u0144czonym czasie. Piotr zwraca\u0142 uwag\u0119, \u017ce w klasycznym tr\u00f3jk\u0105cie zale\u017cno\u015bci \u2013 zakres \u2013 czas \u2013 koszty, wszystkie elementy s\u0105 ruchome ale zamiany zakresu cz\u0119sto s\u0105 ignorowane przez \u201eklasyk\u00f3w\u201d. Detaliczna definicja produktu na pocz\u0105tku projektu i szczeg\u00f3\u0142owo zaplanowana realizacja grozi wytworzeniem produktu, kt\u00f3rego zamawiaj\u0105cy ju\u017c nie potrzebuje. PMI jako kl\u0119sk\u0119 projektu definiuje wytworzenie produktu, kt\u00f3rego nikt nie potrzebuje. Trudno zatem uwa\u017cne zarz\u0105dzanie zakresem, tak aby tworzony produkt spe\u0142nia\u0142 potrzeby (biznesowe) stoj\u0105ce za uruchomieniem projektu, uznawa\u0107 za odst\u0119pstwo od wytycznych PMI.<\/p>\n

Piotr omawia\u0142 rol\u0119 w\u0142a\u015bciciela produktu (product owner<\/em>), maj\u0105cego interes w powstaniu produktu spe\u0142niaj\u0105cego jego wymaganiami i dysponuj\u0105cego \u015brodkami do jego wytworzenia. Bliska wsp\u00f3\u0142praca w\u0142a\u015bciciela produktu z zespo\u0142em projektowym, szybko\u015b\u0107 podejmowania decyzji i budowanie wsp\u00f3lnej wizji produktu maj\u0105 kluczowe znaczenie dla ostatecznego sukcesu. Trudno oprze\u0107 si\u0119 wra\u017ceniu, \u017ce Piotr opisywa\u0142 zachowanie idealnego sponsora projektu. Piotr pokazywa\u0142 w jaki spos\u00f3b trudno\u015bci w komunikacji przek\u0142adaj\u0105 si\u0119 na zarz\u0105dzanie zakresem projektu. W\u0142a\u015bciciel produktu ma wizj\u0119 ale ma te\u017c trudno\u015bci w jej zakomunikowaniu zespo\u0142owi. Cz\u0119sto w\u0142a\u015bciciel produktu nie jest jego u\u017cytkownikiem, reprezentuje wi\u0119c swoje wyobra\u017cenia tego, co u\u017cytkownicy chc\u0105 mie\u0107. Wyobra\u017cenia takie bywaj\u0105 b\u0142\u0119dne. Wyzbycie si\u0119 l\u0119ku przed b\u0142\u0119dami i akceptacja rozwoju produktu przez budowanie kolejnych prototyp\u00f3w daje lepszy produkt ko\u0144cowy. Akceptujemy ryzyko odrzucenia pierwszych wersji produktu i rozpocz\u0119cia pracy od nowa \u2013 bez produktu ale z lepszym wyobra\u017ceniem jaki produkt ma by\u0107. W zamian za to unikamy ryzyka dostarczenia produktu zgodnego z pocz\u0105tkow\u0105 specyfikacj\u0105 i niezgodnego z faktycznymi wymaganiami. A to przecie\u017c oznaka fiaska projektu wed\u0142ug PMI.<\/p>\n

Nale\u017cy zwr\u00f3ci\u0107 uwag\u0119 na ryzyko zwi\u0105zane z budow\u0105 perfekcyjnego WBS na pocz\u0105tku projektu, kiedy \u015bwiadomo\u015b\u0107 ostatecznego wyg\u0142adu produktu jest niska. Opisany w nim produkt b\u0119dzie mia\u0142 si\u0119 nijak do po\u017c\u0105danego rezultatu. Nie ma powodu inwestowa\u0107 w opracowanie szczeg\u00f3\u0142\u00f3w, kt\u00f3re nigdy nie powstan\u0105, bo to tylko starta czasu i innych zasob\u00f3w. Oczywi\u015bcie og\u00f3lna wizja produktu powinna nabiera\u0107 szczeg\u00f3\u0142\u00f3w w miar\u0119 skracania czasowej perspektywy. To co robimy w najbli\u017cszym tygodniu powinno by\u0107 wzajemnie uzgodnione co nie oznacza, \u017ce wszystko musi by\u0107 detalicznie udokumentowane. W zwinnym zarz\u0105dzaniu du\u017ce znaczenie ma zaufanie cz\u0142onk\u00f3w zespo\u0142u i zaufanie do w\u0142a\u015bciciela produktu. Zaufanie to jest budowane przez dostarczanie kolejnych wersji produktu. Opisane wy\u017cej podej\u015bcie to nic innego jak planowanie iteracyjne (Rolling Wave Planning<\/em>), technika znana z PMBOK.<\/p>\n

Piotr podnosi\u0142 kwesti\u0119 skuteczno\u015bci formalizm\u00f3w w projektach, kt\u00f3rych produktem jest oprogramowanie. Pod koniec ubieg\u0142ego wieku pojawi\u0142 si\u0119 trend szczeg\u00f3\u0142owego dokumentowania pisanego oprogramowania. W rezultacie projekty, kt\u00f3re mia\u0142y robi\u0107 software a produkowa\u0142y dokumentacj\u0119 i op\u00f3\u017anienia. Przypomnia\u0142o mi to opowie\u015b\u0107 kolegi, kt\u00f3ry budowa\u0142 detektor cz\u0105stek elementarnych w du\u017cym eksperymencie (CERN \/ DELPHI). Niezb\u0119dne do funkcjonowania detektora by\u0142o oprogramowanie do odczytu danych, kt\u00f3re pisa\u0142 przez kilka miesi\u0119cy osobny zesp\u00f3\u0142 licz\u0105cy kilkana\u015bcie os\u00f3b wykorzystuj\u0105ce najnowsze techniki in\u017cynierii oprogramowania i zarz\u0105dzania projektami. Projekt utkn\u0105\u0142 na etapie definicji i dokumentowania funkcjonalno\u015bci produktu, tymczasem kolega potrzebowa\u0142 oprogramowania bo w\u0142a\u015bnie zaczyna\u0142 testy detektora. W desperacji zaprosi\u0142 do wsp\u00f3\u0142pracy innego koleg\u0119 i we dw\u00f3ch zakodowali w dwa dni (i jedn\u0105 noc) niezb\u0119dn\u0105 im funkcjonalno\u015b\u0107. Oprogramowanie nie musi by\u0107 \u0142adne, musi mie\u0107 wymagan\u0105 w funkcjonalno\u015b\u0107 wtedy, kiedy jest ona potrzebna.<\/p>\n

Zwinne zarz\u0105dzanie nie jest dla w\u0142a\u015bcicieli produktu, kt\u00f3rzy nie wiedz\u0105 czego chc\u0105 i boj\u0105 si\u0119 podejmowa\u0107 decyzje. Czy podej\u015bcie do zarz\u0105dzania zakresem, w kt\u00f3rym pierwsze\u0144stwo ma produkt nad dokumentacj\u0105 jest sprzeczne z filozofi\u0105 PMI? Moim zdaniem nie. Projekt tworzy unikalny produkt lub us\u0142ug\u0119. Trudno oczekiwa\u0107, \u017ce unikalny produkt projektu b\u0119dzie mia\u0142 detaliczn\u0105 dokumentacj\u0119 na wej\u015bciu. Jedn\u0105 w cech zarz\u0105dzania projektu wed\u0142ug PMI jest przecie\u017c stopniowy rozw\u00f3j produktu (progressive elaboration<\/em>).<\/p>\n

W trakcie warsztat\u00f3w Piotr poprowadzi\u0142 dwa \u0107wiczenia z szacowania w oparciu o technik\u0119 znan\u0105 jako Planning Poker (http:\/\/en.wikipedia.org\/wiki\/Planning_poker<\/a>). Uczestnicy warsztat\u00f3w podzieleni na zespo\u0142y szacowali z\u0142o\u017cono\u015b\u0107 projektu budowy aplikacji z\u0142o\u017conej z 20 scenariuszy u\u017cycia (user story<\/em>). W zespole pracowa\u0142o by\u0142o 3-4 \u201eprogramist\u00f3w\u201d i \u201ew\u0142a\u015bciciel produktu\u201d. Pierwsze \u0107wiczenie wykorzystywa\u0142o \u201eklasyczne\u201d karty Planning Poker. Drugie polega\u0142o na uporz\u0105dkowani scenariuszy u\u017cycia od naj\u0142atwiejszego do najtrudniejszego (do budowy). Scenariusze porz\u0105dkowano przyklejaj\u0105c odpowiadaj\u0105ce im karteczki post-it na blacie biurka. To \u0107wiczenie mo\u017cna by\u0142o wykona\u0107 przyklejaj\u0105c karteczki do \u015bciany, ale wtedy trzeba by wsta\u0107 od pokerowego stolika.<\/p>\n

Podstaw\u0105 obydwu technik jest teza, \u017ce cz\u0142owiek dobrze radzi sobie z wyznaczaniem relacji wi\u0119kszy – mniejszy, trudniejszy \u2013 \u0142atwiejszy, l\u017cejszy \u2013 ci\u0119\u017cszy je\u017celi por\u00f3wnuje ze sob\u0105 obiekty. Znacznie gorzej wychodzi szacowanie wielko\u015bci danego obiektu wzgl\u0119dem skali. Ka\u017cdy wie, \u017ce st\u00f3\u0142 jest ci\u0119\u017cszy ni\u017c krzes\u0142o, ale ci\u0119\u017car sto\u0142u i ci\u0119\u017car krzes\u0142a poda\u0107 trudno. Dlatego te\u017c \u0142atwiej szacowa\u0107 zaczynaj\u0105c od uporz\u0105dkowania obiekt\u00f3w przypisuj\u0105c im umowne jednostki warto\u015bci. Maj\u0105c uporz\u0105dkowane obiekty wyznaczamy warto\u015b\u0107 kliku z nich i na tej postawie kalibrujemy skal\u0119 naszego oszacowania. W przypadku aplikacji mo\u017cna to zrobi\u0107 koduj\u0105c wybrane scenariusze u\u017cycia w prototypie.<\/p>\n

Planning Poker wykorzystywany przez Piotra by\u0142 dla mnie narz\u0119dziem nowym. W technice tej u\u017cywa si\u0119 kart do g\u0142osowania oznaczonych (poza pewnymi wyj\u0105tkami ) liczbami z ci\u0105gu Fibonacciego. Ci\u0105g Fibonacciego zaczyna si\u0119 od dw\u00f3ch jedynek, za\u015b ka\u017cdy kolejny element jest sum\u0105 dw\u00f3ch poprzednich. Poniewa\u017c wiele rzeczy w naturze na proporcje b\u0119d\u0105ce stosunkiem liczb Fibonacciego, wykorzystanie ich do szacowania jest dobrym pomys\u0142em. Ka\u017cdy cz\u0142onek zespo\u0142u g\u0142osuje za pomoc\u0105 zakrytej karty. Na dany znak karty odkrywane s\u0105 r\u00f3wnocze\u015bnie. Je\u017celi pokazane warto\u015bci bardzo si\u0119 r\u00f3\u017cni\u0105 nast\u0119puje kr\u00f3tka dyskusja. Osoba prezentuj\u0105ca skrajne oszacowanie uzasadnia dlaczego tak uwa\u017ca por\u00f3wnuj\u0105c z\u0142o\u017cono\u015b\u0107 szacowanego zadania do zada\u0144 ju\u017c oszacowanych. W ten spos\u00f3b zesp\u00f3\u0142 oceniaj\u0105c kolejne zadania buduje r\u00f3wnocze\u015bnie skal\u0119 trudno\u015bci. Szacowanych dzia\u0142a\u0144 by\u0142o 20, czas wykonania oszacowania wynosi\u0142 20 minut. Wiadomo, \u017ce najtrudniejsze jest pierwsze oszacowanie, dla u\u0142atwienia pracy zespo\u0142u Piotr wyceni\u0142 pierwsze zadanie z listy na 2 punkty w \u201epokerowej\u201d skali. Ten prosty manewr przy\u015bpiesza prac\u0119 zespo\u0142u bez szkody dla rezultatu \u2013 wszak istot\u0105 \u0107wiczenia jest ustalenie proporcji. Jak pisa\u0142em wy\u017cej kalibracj\u0119 skali wykonujemy osobno. W moim zespole w miar\u0119 szacowania kolejnych zada\u0144 spada\u0142 rozrzut oszacowa\u0144 a ewentualne rozbie\u017cno\u015bci uzgadniano coraz szybciej. Naturalne jest pytanie co b\u0119dzie je\u017celi nie uda si\u0119 uzgodni\u0107 oszacowa\u0144? Zadanie ma limit czasu wykonania, przekroczenie limitu oznacza zapewne, \u017ce zesp\u00f3\u0142 nie ma jeszcze wsp\u00f3lnego zrozumienia zakresu \u2013 Piotr zgrabnie powiedzia\u0142, \u017ce zesp\u00f3\u0142 nie zalicza zadania. Co robi\u0107 w takiej sytuacji to ju\u017c temat na inny warsztat.<\/p>\n

W zwinnym zarz\u0105dzaniu projektami najbardziej podoba mi si\u0119 \u015bcis\u0142a wsp\u00f3\u0142praca w\u0142a\u015bciciela produktu z zespo\u0142em produkt tworz\u0105cym. Dzi\u0119ki tej wsp\u00f3\u0142pracy sponsor projektu dostaje produkt lepiej spe\u0142niaj\u0105cy jego potrzeby, nawet je\u017celi ostateczny rezultat r\u00f3\u017cni si\u0119 sporo od pocz\u0105tkowych wymaga\u0144. Istot\u0105 ka\u017cdej metodyki zarz\u0105dzania projektami jest pomoc w stworzeniu produktu u\u017cytecznego dla zamawiaj\u0105cego projekt, nie za\u015b konsekwentna realizacja realizacja programu bez wzgl\u0119du na u\u017cyteczno\u015b\u0107 jego rezultat\u00f3w. Je\u017celi zarz\u0105dzanie \u201eklasyczne\u201d rozumie\u0107 jako konsekwentn\u0105 realizacj\u0119 ustalonego na pocz\u0105tku projektu zakresu, to niew\u0105tpliwie zarz\u0105dzanie zwinne lepiej reprezentuje ide\u0119, kt\u00f3ra zapocz\u0105tkowa\u0142a budow\u0119 metodyk zarz\u0105dzania projektami takich jak PMBOK czy Prince2. Chodzi\u0142o bowiem o tworzenie produkt\u00f3w unikalnych i u\u017cytecznych, nie o planowe marnowanie zasob\u00f3w.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Opublikowany 2013\/04\/16 W zesz\u0142ym tygodniu mia\u0142em przyjemno\u015b\u0107 uczestniczy\u0107 w warsztatach zorganizowanych przez PMI PC kt\u00f3re prowadzi\u0142 Piotr Burdylo. Tematem warsztatu by\u0142o szacowanie w zwinnych zespo\u0142ach. Od jakiego\u015b czasu interesuj\u0119 si\u0119 projektami, kt\u00f3rych celem jest stworzenie oprogramowania i zwinnymi (agile) metodami zarz\u0105dzania. Warsztaty sk\u0142oni\u0142y mnie do napisania tego artyku\u0142u, w kt\u00f3rym przedstawiam r\u00f3\u017cnice pomi\u0119dzy zwinnym a […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[5],"tags":[],"class_list":["post-55","post","type-post","status-publish","format-standard","hentry","category-relacje"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4qwq1-T","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts\/55","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=55"}],"version-history":[{"count":2,"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts\/55\/revisions"}],"predecessor-version":[{"id":74,"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts\/55\/revisions\/74"}],"wp:attachment":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=55"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=55"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=55"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}