-
Notifications
You must be signed in to change notification settings - Fork 0
/
OnEstimates-Czesc-III-Zagrozenia-plynace-z-estymacji.html
1 lines (1 loc) · 15.2 KB
/
OnEstimates-Czesc-III-Zagrozenia-plynace-z-estymacji.html
1
<!DOCTYPE html> <html lang="pl"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1" /> <title>OnEstimates. Część III: Zagrożenia płynące z estymacji · Rafal Makara</title> <meta property="og:title" content=" OnEstimates. Część III: Zagrożenia płynące z estymacji "> <meta property="twitter:title" content=" OnEstimates. Część III: Zagrożenia płynące z estymacji "> <meta property="og:description" content=" Hi! I am Rafal and I am a generalist. I was an software engineer, project manager, product owner, scrum master, chief digital officer. I know about people, collaboration, project management, software development and business operations. "> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@rafalmakara" /> <meta property="og:image" content="https://rmakara.github.io/assets/20171119_header.jpg" /> <meta name="twitter:image" content="https://rmakara.github.io/assets/20171119_header.jpg" /> <meta name="description" content="Każdy kij ma dwa końce"> <link rel="icon" href="https://rmakara.github.io//assets/favicon.ico"> <link rel="apple-touch-icon" href="https://rmakara.github.io//assets/apple-touch-icon.png"> <link rel="stylesheet" href="https://rmakara.github.io//assets/core.css"> <link rel="canonical" href="https://rmakara.github.io//OnEstimates-Czesc-III-Zagrozenia-plynace-z-estymacji"> <link rel="alternate" type="application/atom+xml" title="Rafal Makara" href="https://rmakara.github.io/feed.xml" /> </head> <body> <aside class="logo"> <a href="https://rmakara.github.io//"> <img src="https://avatars0.githubusercontent.com/u/1880231?v=4" class="logo-avatar"> </a> <span class="logo-prompt code">Back to Home</span> </aside> <aside> <p class="goodbye"> This blog is no longer maintained <br/><br/> Subscribe to new articles at <a href="https://www.sorryengineering.com/">https://www.sorryengineering.com/</a> </p> </aside> <p class="menu"> <br /><br /> <a href="/">EN Articles</a> | <a href="/pl">PL Articles</a> <br /> <a href="/about">About me</a> | <a href="/help">How can I help?</a> | <a href="https://www.linkedin.com/in/rafalmakara/">My LinkedIn Profile</a> </p> <div id="content"> <article> <div class="divider"></div> <div class="center"> <a class="prev" href="/Developer-vs-Project-Manager-002-Zarobki">Previous article - Developer vs Project Manager 002: Zarobki</a> </div> <div class="divider"></div> <h1 class="title">OnEstimates. Część III: Zagrożenia płynące z estymacji</h1> <div class="center"> <time class="code">2017-11-19</time> </div> <div class="divider"></div> <h1 id="każdy-kij-ma-dwa-końce">Każdy kij ma dwa końce</h1> <p>Powiedzieliśmy już, że z estymacji płynie bardzo wiele korzyści i główną z nich jest edukacja. Z drugiej jednak strony, wdrażanie nowego elementu niesie za sobą konsekwencje tworzenia nowych ryzyk w innych obszarach systemu złożonego, a taki tworzony jest przez wszystko co ma związek z wytwarzaniem oprogramowania.</p> <p>Patrząc na potencjalne problemy z różnych perspektyw (dev, QA, PM, SM, PO) można dostrzec zupełnie coś innego. Korzystając z tego, że miałem okazję pracować zarówno jako developer, jak i project manager przytoczę elementy, które były dla mnie niezrozumiałe gdy siedziałem tylko po jednej ze stron.</p> <h1 id="plany-biznesowe-i-akcje-marketingowe">Plany biznesowe i akcje marketingowe</h1> <p>Tworzenie softu jest częścią biznesu. Osoby biznesowe traktują proces tworzenia oprogramowania jako element czegoś większego. To sprawia, że estymacje mogą prowadzić do określenia orientacyjnych (lub precyzyjnych) terminów wdrożenia nowych funkcjonalności z którymi mogą wiązać się plany biznesowe firmy. Wyobraźmy sobie np. wdrożenie nowej funkcjonalności obsługi e-faktur i proces zachęcania użytkowników do przejścia z wykorzystywania faktur papierowych na wersje elektroniczne. W celu przeprowadzenia takiego działania milion klientów otrzymujących faktury papierowe ma dostać wraz z kolejną fakturą ulotkę informującą o korzyściach płynących z przejścia na wersje elektroniczną. Takie działanie musi być poprawnie osadzone w czasie i nastąpić po wdrożeniu obsługi e-faktur do oprogramowania. W jaki sposób zsynchronizować jedno z drugim? Estymować, mierzyć i weryfikować. Jeżeli nasze estymacje będą niepoprawne, a wszelkie działania marketingowe oraz proces wytwarzania danego modułu trwa np. 3-4 miesiące to w sytuacji, gdy ulotki zostaną rozesłane do miliona klientów, a system nie będzie gotowy - mamy problem. Informacja o tego typu problemach w większości firm nawet nie trafia do programistów. Warto ich informować, aby generować poczucie odpowiedzialności i zobowiązania.</p> <h1 id="harmonogram">Harmonogram</h1> <p>Współpracując z innymi musimy być przewidywalni, ponieważ muszą oni dostosować wykonywaną przez siebie pracę do nas, a my naszą do nich. Jeżeli niepoprawnie wyestymujemy czasy zamykania kolejnych etapów wytwarzania systemu, czyli innymi słowy stworzymy nierealny harmonogram doprowadzamy do sytuacji w której zaburzamy nie tylko cykl swojej pracy, ale również wszystkie harmonogramy zależne. Książkowym przykładem jest wytwarzanie aplikacji z dużą ilością integracji, które dopiero będą przygotowywane w innym systemie przez firmę trzecią. Każde przesunięcie terminu w wytwarzaniu powoduje nie tylko zmianę harmonogramu prac firmy trzeciej, ale również naszej… a być możę również działów w naszej firmie, których praca ponownie jest zależna od obiecanych przez nas elementów.</p> <h1 id="planowanie-budżetu">Planowanie budżetu</h1> <p>Ze względu na złożoność wytwarzanych aplikacji bardzo ciężko jest wyszacować koszt stworzenia dużego systemu już na początku jego realizacji. Między innymi przez to popularna jest forma rozliczania <a href="https://en.wikipedia.org/wiki/Time_and_materials">time & materials</a>, która opiera się na pobieraniu opłat w oparciu o stawki godzinowe. Zmiana formy rozliczania na taką nie oznacza, że nasz klient nagle przeobraża się w studnię bez dna i możemy od niego pobierać pieniądze w nieskończoność. Budżet jest ograniczony, zawsze. Estymowanie, mierzenie i weryfikowanie pozwala na kontrolę aktualnego stanu budżetu oraz planowanie jego wykorzystnaia w przyszłości. Co można zrobić źle? Estymować i mierzyć, ale nie weryfikować. Jeżeli taki scenariusz połączymy z wytwarzaniem dużego systemu w modelu “wdróżmy wszystko naraz, a nie iteracyjnie” to kończymy bez budżetu, ale z systemem wytworzonym w 80%, który nie jest gotowy do wykorzystania przez klientów.</p> <h1 id="motywacja-zespołu">Motywacja zespołu</h1> <p>W poprzedniej części serii o estymacjach przytaczaliśmy następujące prawo:</p> <blockquote> <p>Praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie.</p> <p>– Prawo Parkinsona, Cyril Northcote Parkinson</p> </blockquote> <p>Brak definiowania deadlineów wpływa negatywnie na wydajność, kreatywność i poczucie odpowiedzialności zespołów. Wiąże się to między innymi z teorią mówiącą, że w ramach wspierania pracy zespołów samoorganizujących się powinniśmy umożliwić im samoorganizację, ale jednoczęśnie nadając pewne ograniczenia w obrębie których taki zespół samodzielnie powinien stworzyć rozwiązania. Jednym z takich ograniczeń jest właśnie termin - należy pamiętać, aby był wywarzony - motywujący i osiągalny - ponieważ może wpłynąć na zespół zarówno pozytywnie, jak i negatywnie.</p> <p>Szacowanie jest motywujące również przez publiczne (i grupowe) mówienie o tym. Stałe podawanie niepoprawnych estymacji pozbawione wyciągania wniosków na przyszłość jest pewną plamą na honorze, którą widzą koledzy i koleżanki z zespołu.</p> <h1 id="wysoka-niedokładność">Wysoka niedokładność</h1> <p>Nabywając każdą nową umiejętność na początku jesteśmy skazani na niepowodzenia. Estymowanie w początkowych fazach pracy z systemem którego nie znamy generuje stres wśród członków zepsołu i łatwo jest doprowadzić do sytuacji w której ludzie nie chcą kontynuować szacowania, ponieważ w pierwszych sprintach wiele estymacji jest przekroczonych. Rolą osób spokojniejszych (lub <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)#Scrum_master">Scrum Mastera</a>) jest wyjaśnienie po co to robimy i dlaczego warto, oraz doprowadzenie do sytuacji w której każdy członek zespołu rozumie powody stojące za estymowaniem, zamiast traktować spotkania groomingowe jako najbardziej stresujący moment tygodnia.</p> <h1 id="mowa-nienawiści">Mowa nienawiści</h1> <p>Podobnie jak w przypadku komunikacji przy code review, można stworzyć atmosferę w której przeglądanie kodu innych osób czy analizowanie estymacji i ich słuszności stanie się okazją do wyładowania emocjonalnego, i powiedzenia innym jacy są źli. Ponownie, rolą Scrum Mastera lub współpracującego ze sobą zespołu jest doprowadzenia do sytuacji w której nikt nie traktuje tego procesu jako potencjalnego powodu do zaczepki, a jako element wspierający w stawaniu się lepszą grupą zmierzającą w tym samym kierunku.</p> <h1 id="błędy-i-zmiany">Błędy i zmiany</h1> <p>Szacując objętność dowolnego zadania bardzo często skupiamy się na obsłudze <a href="https://en.wikipedia.org/wiki/Happy_path">szczęśliwej ścieżki</a> jego wykonania. Zapominamy o ewentualnych błędach, które może generować stworzone rozwiązanie oraz konieczności wdrożenia modyfikacji na które wpadamy podczas jego realizacji. W takich sytuacjach z pomoca przychodzi nam rozmowa z zespołem podczas <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)#Daily_scrum">daily</a>, wykorzystwanie funkcjonalności Remaining Estimate w systemach ticketowych, <a href="https://martinfowler.com/bliki/TestDrivenDevelopment.html">test driven development</a> oraz <a href="https://dannorth.net/introducing-bdd/">behaviour driven development</a>.</p> <p>Specjaliści najczęściej są optymistami. Warto zestawiać własne myślenie z głębokim drążeniem tematu w zakresie tego czego mogliśmy nie przemyśleć, co mogliśmy przeoczyć, co może pójść nie tak, czy da się to zrobić prościej.</p> <h1 id="samodzielne-estymacje">Samodzielne estymacje</h1> <p>Zupełnie jak w stadzie wilków - nikt nie jest Alfą i Omegą. Bardzo trudne jest osiągnięcie wysokiego prawdopodobieństwa szacunków w systemie złożonym, gdy wykonuje to jedna osoba. Taki element procesu można uznać za antywzorzec i należy omówić z zespołem jego modyfikację na korzyść estymacji grupowych i wspólnego analizowania problemu. Każdy z nas ma inne doświadczenie i każdy popełnił inne błędy w życiu. Dzięki temu nieocenione jest wykorzystywanie punktu widzenia innych osób mogących powiedzieć <em>“been there, done that… zróbmy to inaczej…“</em>. Życie przyzwyczaja nas do uczenia się na błędach własnych, a nie na błędach innych osób - nie jest to jednak najefektywniejsza ścieżka.</p> <h1 id="estymowanie-cudzej-pracy">Estymowanie cudzej pracy</h1> <p>To chyba najpopularniejszy antywzorzec z którym się spotykałem. Lider zespołu lub manager estymujący czas realizacji zadania bez udziału specjalistów, którzy będą dane zadanie realizować. Doprowadza to do stresowania zespołu, ale przede wszystkim do pozbawiania nas szansy na omówienie rozwiązywanego problemu w kilka osób. Gdy to tylko możliwe - estymujmy w grupach, koniecznie przy udziale tych osób, które będą brać udział w doprowadzaniu zadania do końca.</p> <h1 id="agresywny-klient">Agresywny klient</h1> <p>Współpracownicy oraz klienci są różni. Zdarzają się sytuacje w których rozmawiamy z osobami kontaktowymi po stronie klienta, które mogą być dość konkretne, ostre lub niemiłe. W takich sytuacjach osoby o słabszych charakterach mają tendencję do zaniżania swoich estymacji, celem uniknięcia kontaktu z nieprzychylną klienta. Problemy wychodzą później, gdy konieczne jest przedstawienie wyników swojej pracy. W takich momentach warto chronić osoby, które na trudną komunikację z klientem reagują wysokim stresem i warto umożliwić im skupienie się na samej efektywnej realizacji zadania.</p> <h1 id="zbyt-wczesne-szacowanie-i-brak-odpowiedniej-granulacji">Zbyt wczesne szacowanie i brak odpowiedniej granulacji</h1> <p>Warunkiem poprawnego okreslenia objętości zadania jest posiadanie wystarczającej ilości danych o nim. Estymując zadanie o olbrzymim zakresie, bez przeprowadzenia wstępnej analizy dość trudno jest precyzyjnie je oszacować. Warto zebrać podstawowe informacje, a przede wszystkim podzielić task na mniejsze, których szacowanie będzie zdecydowanie łatwiejsze.</p> <h1 id="podsumowanie">Podsumowanie</h1> <p>Każdy kij ma dwa końce. W przypadku estymacji zdecydowanie korzystniejszym z końców jest ten pozytywny, ale warto pamiętać również o negatywnych aspektach płynących z procesu estymowania i przygotować się na spotkanie z nimi, ponieważ z pewnością się pojawią.</p> <p>Powyższe przykłady stanowią jedynie niewielki wycinek problemów jakie mogą powstać podczas podejmowania wysiłku szacowania pracy. Należy jednak pamiętać, że najczęstszym rozwiązaniem jest - praca zespołowa.</p> <blockquote> <p>Talent wins games, but teamwork and intelligence win championships.</p> <p>– Michael Jordan</p> </blockquote> <hr /> <h4 id="źródła-i-pojęcia">Źródła i pojęcia</h4> <ul> <li>[1] <a href="https://en.wikipedia.org/wiki/Time_and_materials">Time & materials, Wikipedia</a></li> <li>[2] <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)#Scrum_master">Scrum Master, Wikipedia</a></li> <li>[3] <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)#Daily_scrum">Daily Scrum, Wikipedia</a></li> <li>[4] <a href="https://martinfowler.com/bliki/TestDrivenDevelopment.html">Test Driven Development, Martin Fowler</a></li> <li>[5] <a href="https://dannorth.net/introducing-bdd/">Behaviour Driven Development, Dan North</a></li> </ul> </article> <div class="divider"></div> <div class="page-navigation code"> <a class="home" href="https://rmakara.github.io//" title="Back to Home">Back to Home</a> <br/><br/> <a class="next" href="/Ksiazki-i-najlepszy-prezent-materialny-w-2017">Next article: Książki i najlepszy prezent materialny w 2017</a> </div> </div> <br/> <aside> <p class="goodbye"> This blog is no longer maintained <br/><br/> Subscribe to new articles at <a href="https://www.sorryengineering.com/">https://www.sorryengineering.com/</a> </p> </aside> <div class="footer"> <span class="block">© 2023 Rafal Makara</span> <span class="block"><small></> Powered by <a href="https://jekyllrb.com/">Jekyll</a> and <a href="https://github.com/heiswayi/the-plain">The Plain theme</a>.</small></span> </div> </body> <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-92815270-1', 'auto'); ga('send', 'pageview'); </script> </html>