-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathCzym-jest-spike-wyjasnienie-dla-project-managera.html
1 lines (1 loc) · 9.93 KB
/
Czym-jest-spike-wyjasnienie-dla-project-managera.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>Czym jest SPIKE? Wyjaśnienie dla Project Managera · Rafal Makara</title> <meta property="og:title" content=" Czym jest SPIKE? Wyjaśnienie dla Project Managera "> <meta property="twitter:title" content=" Czym jest SPIKE? Wyjaśnienie dla Project Managera "> <meta property="og:description" content=" Jakie benefity może osiągnąć zespół developerski oraz project manager przez korzystanie ze spajków? "> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@rafalmakara" /> <meta property="og:image" content="https://rmakara.github.io/assets/20200116_header.jpg" /> <meta name="twitter:image" content="https://rmakara.github.io/assets/20200116_header.jpg" /> <meta name="description" content="Wina analitykówW firmach usługowych zdarza nam się pracować w systemie projektowym. W związku z tym czasami wykonujemy spory etap analizy jeszcze przed rozpo..."> <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//Czym-jest-spike-wyjasnienie-dla-project-managera"> <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="/is-your-feedback-meeting-about-money-wyniki-ankiety-czesc-I">Previous article - Is your feedback meeting about money? Wyniki ankiety, część I</a> </div> <div class="divider"></div> <h1 class="title">Czym jest SPIKE? Wyjaśnienie dla Project Managera</h1> <div class="center"> <time class="code">2020-01-16</time> </div> <div class="divider"></div> <h2 id="wina-analityków">Wina analityków</h2> <p>W firmach usługowych zdarza nam się pracować w systemie projektowym. W związku z tym czasami wykonujemy spory etap analizy jeszcze przed rozpoczęciem prac programistycznych. Jest to jak najbardziej ok i zwiększa naszą wiedzę w sposób pozwalający na wycenę projektu oraz późniejszą jego realizację.</p> <p>Często jednak zespoły programistyczne narzekają, że <em>“analiza była słaba”</em>. Nie jest to oczywiście wina analityków. Jest to kwestia tego, że zazwyczaj narzeka się na osoby “przed nami” w nieperfekcyjnym procesie w którym brakuje poprawnych mechanizmów współpracy między rolami, więc… być może jest to wina programistów, że nie rozmawiają z analitykami? A być może późniejsza analiza to coś normalnego?</p> <h2 id="co-na-to-agile-i-extreme-programming">Co na to Agile i Extreme Programming?</h2> <p>W podejściu zwinnym, effort “uczenia się” lub effort analityczny jest częścią Sprintu. Oznacza to, że każdy członek Development Teamu moe za taką analizę odpowiada. Jeżeli braki w wiedzy do zrealizowania danej historyjki są dość małe to można taką analizę wykonać w obrębie tego samego issue co samą implementację.</p> <p>Co jednak, gdy mamy duże braki w wiedzy i nie pozwalają nam one na oszacowanie czasu potrzebnego do realizacji zadania, rozpisanie sub-tasków lub na podjęcie decyzji czy jego implementacja powinna się w ogóle odbyć? Innymi słowy, nie mamy wiedzy, aby rozpocząć realizację zadania. PM pyta <em>“ile godzin?”</em>, a odpowiedzi nie da się udzielić.</p> <p>Na pomoc przychodzi znany w środowisku programowania ekstremalnego - SPIKE.</p> <h2 id="czym-jest-spike">Czym jest Spike?</h2> <p>W świecie Agile, Spike to wysiłek / effort, który może być wydzielony z historyjek implementacji konkretnych funkcjonalności na rzecz zdobycia wiedzy, która pozwoli nam rozpocząć faktyczną pracę nad zadaniem (lub podjąć decyzję o jego odrzuceniu). Spajki mogą być funkcjonalne, techniczne, architektoniczne […].</p> <p>W świecie Extreme Programming, jest to najmniejszy mozliwy eksperyment pozwalajcy na rozeznanie sie w potencjalnych rozwiazaniach przed zdecydowaniem sie na pelna implementacje. Celem jest obnizanie ryzyka wynikajacego z konkretnej niepewnosci w zakresie technicznym.</p> <h2 id="przykład">Przykład</h2> <p>Mamy user story: <em>“Jako Content Manager chcę przy uzyciu Prismica zbudować stronę statyczną z odnośnikami do polecanych artykułów, aby następnie została ona wyświetlona na stronie statycznej w naszym storefroncie”</em>.</p> <p>Załóżmy, że nasz zespół nigdy nie integrował się z <a href="https://prismic.io/">Prismiciem</a> i nie wie od czego zacząć. Oszacowanie punktowe / czasowe realizacji tej historyjki będzie strzałem bazującym na domysłach. Nie są znane też ryzyka, które mogą zaistnieć podczas implementacji. No i teraz możemy wydzielić przykładowe spike. Opiszmy je w formie storiesów (kilka różnych wersji):</p> <ul> <li>[SPIKE] Jako Dev Team chcemy zdobyć wiedzę o tym jak pobierać dane z Prismica oraz w jakiej formie przekazywane są strony z Prismica na storefront, aby precyzyjnie zdefiniować zadania z zakresu integracji z Prismic i je wyestymować</li> <li>[SPIKE] Jako Dev Team chcemy zweryfikować czy pokazywanie linków na stronach statycznych z Prismica niesie za sobą jakieś potencjalne problemy, aby precyzyjnie podczas refinementu uwzględnić ryzyka do przemyślenia podczas implementacji historyjki</li> <li>[SPIKE] Jako Dev Team chcemy zebrać wnioski z integracji z systemami CMS w innych naszych projektach, aby przyjąć jak najlepszą koncepcję architektoniczną dla integracji z Prismiciem</li> </ul> <h2 id="przykłady-spikeów-z-innej-beczki">Przykłady spike’ów z innej beczki</h2> <ul> <li>[SPIKE] Chcemy wykonać analizę SWOT, aby ustalić czy powinniśmy zaimplementować system rekomendacji produktowych w naszym eCommerce wykorzystując PHP, Pythona, czy może powinniśmy kupić gotowe rozwiązanie?</li> <li><a href="https://github.com/DivanteLtd/shopware-pwa/issues/98">https://github.com/DivanteLtd/shopware-pwa/issues/98</a></li> <li><a href="https://github.com/DivanteLtd/shopware-pwa/issues/100">https://github.com/DivanteLtd/shopware-pwa/issues/100</a></li> <li><a href="https://github.com/SAP/cloud-commerce-spartacus-storefront/issues/1218">https://github.com/SAP/cloud-commerce-spartacus-storefront/issues/1218</a></li> </ul> <h2 id="dobre-praktyki-spajkowania">Dobre praktyki spajkowania</h2> <ul> <li>Dla każdego spike warto ustalić <strong>konkretny timebox</strong>. Np. na realizację naszego spike o Prismicu chcemy poświęcić <strong>maksymalnie 3 godziny</strong>. W tym czasie zdobywamy jak najwięcej wiedzy + spisujemy wnioski. To musi nam wystarczyć do podjęcia kolejnych decyzji.</li> <li>Warto zaznaczyć w kryteriach akceptacyjnych danego spike co powinno być wynikiem jego realizacji. Analiza SWOT, rekomendacja, lista ryzyk, lista sub-tasków, pseudo-kod?</li> </ul> <h2 id="jak-ci-to-pomoże-jako-pmowi">Jak Ci to pomoże jako PMowi?</h2> <ul> <li>Dyskusja o sensowności realizacji historyjek będzie bardziej rzeczowa.</li> <li>Ludzie mają tendencję do implementacji pierwszego rozwiązania jakie wpadnie im do głowy. Spajkowanie pomaga na weryfikację czy pierwszy pomysł na pewno jest najlepszy.</li> <li>Spajki skrócą czas implementacji oraz późniejszego ping-pongu na etapie testowania.</li> <li>Rozwiązania techniczne prawdopodobnie będą lepsze i czas potrzebny na późniejszy refactoring będzie mniejszy.</li> <li>Zwiększenie wiedzy pozwoli na stworzenie sub-tasków, które uczynią proces implementacji bardziej transparentnym. Unikniemy sytuacji <em>“koduję, będzie gotowe jak skończę”</em>.</li> <li>Odseparowanie “uczenia się” od implementacji zwiększy transparentność tego co aktualnie się dzieje z danym zadaniem. Unikniemy tego, że przez 2 tygodnie będziemy czekać na realizację czegoś, co w praktyce nawet się nie zaczęło, bo ktoś samodzielnie wchodzi w bardzo głębokie rozkminy na poziomie <em>“czy można płakać pod wodą?”</em>.</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="/przez-brak-continuous-deployment-tracisz-do-20-budzetu">Next article: Przez brak continuous deployment tracisz do 20% budżetu. Wyjaśnienie dla Project Managera</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>