Kanban i praca nad produktem

Najczęściej, gdy rozmawiam z kimś o Kanbanie, słyszę, że to fajna metoda, ale sprawdza się tylko w zespołach operacyjnych, admińskich, tam gdzie jest dużo powtarzalnych zadań wykonywanych na czyjeś zlecenie. Rzadko kto myśli o Kanbanie w kategoriach metody pracy, która służy rozwojowi produktu, którą można stosować w zespole developerskim i dzięki której szybko dostarczymy wartość użytkownikowi. Pora zatem odczarować możliwości Kanbana.

Faktycznie początkowo Kanban był używany przez zespoły przede wszystkim z myślą o pozbyciu się nadwyżki zadań, o wprowadzeniu płynności do przepływu prac, czy o jak najszybszym wykonywaniu zleconych zadań. Jednak wraz z usprawnieniem pracy zespoły coraz częściej zadawały sobie pytanie, co powinniśmy robić w następnej kolejności, co może poczekać, jak długo, czy jest coś, czego może nie powinniśmy robić. I tutaj z odpowiedzią w 2010 przyszedł Patrick Steyaert formułując pojęcie Upstream Kanbanu. Ta część metody koncentruje się na procesach odkrywania produktu i na kliencie, mając za zadanie dostarczenia zespołowi wykonawczemu (“tradycyjny” Downstream Kanban) wystarczającej liczby gotowych do podjęcia w danym momencie zadań, tak by jednocześnie nie przeciążyć pracą osób, które są odpowiedzialne za generowanie opcji dla rozwoju produktu, niezależnie od tego, czy będzie to inny czy ten sam zespół. 

Reklama



Upstream Kanban składa się z trzech faz:

  • Capture – czyli czas, w którym zbieramy wszystkie możliwe opcje, idee i pomysły dla naszego produktu 
  • Synthesis – czyli moment, w którym dokonujemy pierwszego przeglądu naszego koszyka (albo Backlogu…) pomysłów w celu wyboru najwartościowszych
  • Analysis – czyli ostatni etap, gdy pośród niewielu, najbardziej wartościowych opcji dokonujemy priorytetyzacji w oparciu o wybrane kryteria

W zależności od rodzaju organizacji, produktu, klienta zespół może wypracować bardzo różne etapy pracy nad zadaniem, zanim będzie ono faktycznie gotowe do podjęcia. Możemy na początku skorzystać z Product Vision Board czy innych metod dotyczących konceptualizacji produktu (i w tym temacie polecam książkę Romana Pichlera zrecenzowaną przez Kubę oraz przykład użycia Story Mappingu opisany przez Dawida), potem zastosować adekwatne metody priorytetyzacji, a na końcu przejść do przygotowania zadania do realizacji. A tutaj już zespół zdecyduje, czy będzie potrzebna wstępna analiza lub opis warunków technicznych, czy konsultacja z wybranymi działami organizacji, czy zweryfikowanie opcji pod kątem prawnym, czy może nawet wykonanie makiety i przetestowanie jej z klientem. 

Słów jeszcze kilka o tym, co warto wziąć pod uwagę, żeby Upstream Kanban miał jak największe szanse powodzenia:

  • Oczywiście, dla przejrzystości prac korzystamy z pierwszej zasady Kanbanu, czyli wizualizacji. Każde zadanie, na każdym etapie powinno być widoczne i prawidłowo (czyli zgodnie z przyjętymi przez zespół zasadami) opisane, oznaczone, czy umieszczone. Na takiej wizualizacji możemy mieć zatem kolumny przeznaczone na analizę, konsultacje, makiety i inne potrzebne etapy prac, zanim zadanie zostanie przeniesione do kroku pt. Gotowe do realizacji czy W realizacji.
  • Co ważne natomiast z punktu widzenia płynności prac, tak jak Downstream Kanban posiada maksymalne limity WIP, żeby zespół nie popadł w multitasking i skupiał się na kończeniu zadań, tak Upstream Kanban nakłada na swój proces minimalne limity WIP, po to by zespół podejmujący zadania cały czas miał z czego czerpać i nie musiał czekać na przygotowanie następnej porcji pracy. 
  • A ponieważ w momencie podjęcia pracy w Downstream Kanbanie zaczyna nam liczyć się lead time i chcemy jak najszybciej dostarczyć gotowe rozwiązanie klientowi, musimy zapewnić sobie kompletność zadania przed rozpoczęciem prac. Do tego służy Definition of Ready, czyli lista warunków, dzięki której upewniamy się, że mamy wszystko, co jest potrzebne, żeby rozpocząć prace nad zadaniem. To mogą być kryteria akceptacji używane przez zespoły scrumowe, to mogą być zatwierdzone makiety, wersje językowe, uzgodniony kierunek w rozwiązaniu technicznym i co tylko jeszcze zespół potrzebuje, żeby w trakcie implementacji nie musieć na nikogo i na nic czekać. 

Dobrze zaimplementowany Upstream Kanban, niezależnie od tego, czy należy do tego samego zespołu, który zajmuje się dostarczeniem produktu, czy mieści się w zupełnie innym dziale, pomaga organizacji osiągnąć bardziej kompletny proces end to end. Ponieważ jednak niektórym z was proces oparty o dwie części Kanbanu może wyglądać na pierwszy rzut oka jak zakamuflowany Waterfall podkreślę na koniec, że Upstream i Downstream dzieją się w tym samym czasie, korzystają z częstej pętli informacji zwrotnej, a osoby zaangażowane po obydwu stronach dbają o częste i szybkie dostarczanie swojej części pracy. Nie ma zatem mowy o produkcji zadań w Upstreamie trwającej pół roku z kompletem wymagań – tu chodzi o to, żeby wybrane, najbardziej wartościowe zadania jak najszybciej dotarły do zespołu wytwórczego, który dzięki dobremu przygotowaniu tychże zadań w krótkim czasie dostarczy klientowi właściwe rozwiązania.

Jeśli pojęcie Upstream Kanbanu zaciekawiło was, możecie zgłębić samodzielnie temat pobierając darmowego e-booka ze stron Kanban University, w którym Patrick Steyaert opisuje szczegółowo, jak wprowadzał Upstream Kanbanu do zespołu. Miłej lektury!

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x