Czym jest SPIKE? Wyjaśnienie dla Project Managera

Wina analityków

W firmach często pracujemy w systemie projektowym. W związku z tym zdarza się nam realizować spore analizy upfront. Jest to jak najbardziej ok i zwiększa naszą wiedzę w sposób pozwalający na wycenę projektu oraz późniejszą jego realizację. Często jednak programiści narzekają, że “analiza była słaba”. Nie jest to oczywiście wina analityków. Jest to kwestia tego, że zawsze narzeka się na osoby “przed nami” w nieperfekcyjnym procesie w którym brakuje poprawnych przepływów feedbacku, więc… być może to wina programistów, że nie rozmawiają z analitykami? Who knows. :) A być może późniejsza analiza to coś normalnego?

Co na to Pan(i) Agile?

W podejściu zwinnym, effort “uczenia się” lub effort analityczny jest częścią Sprintu. Oznacza to, że każdy członek Development Teamu 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ę.

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, ani nawet podjęcie decyzji czy jego implementacja powinna się w ogóle odbyć? Innymi słowy, nie mamy wiedzy, aby rozpocząć realizację zadania. PM pyta “ile godzin?”, a odpowiedzi nie da się udzielić.

Na pomoc przychodzi typ zadania znany w środowisku programowania ekstremalnego jako - SPIKE.

Czym jest spike?

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 […].

Ich wynikiem jest zwiększenie wiedzy o danym problemie co pozwolą na podjęcie lepszej decyzji.

Przykład

Mamy user story: “Jako Content Manager chcę w Prismicu zbudować stronę statyczną z odnośnikami do polecanych artykułów, aby następnie została ona wyświetlona na stronie statycznej w naszym storefroncie”.

Załóżmy, że nasz zespół nigdy nie integrował się z Prismiciem i trochę 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):

Przykłady spike’ów z innej beczki

Dobre praktyki spajkowania

Jak Ci to pomoże jako PMowi?