Praktyka stosowania Cumulative Flow w kontekście Scrum i SAFe
W tym artykule planuję opowiedzieć, jak w naszej praktyce stosujemy Cumulative Flow Chart w Scrum w procesie pracy według frameworka SAFeBlog osobisty.
Nie udało się wczytać tego obrazu.W tym artykule planuję opowiedzieć, jak w naszej praktyce stosujemy Cumulative Flow Chart w Scrum w procesie pracy według frameworka SAFe
Zacznę chyba od linku do takiego artykułu - tutaj, moim zdaniem, dobrze opisano jego przeznaczenie w standardowej postaci, polecam zapoznać się przed przeczytaniem mojego artykułu. Poniżej opiszę, jak go zaadaptowaliśmy do procesu Scrum (pierwotnie jest używany w Kanban) i jakie problemy pomaga nam rozwiązywać podczas pracy w sprintach.
Wcześniej, w artykule o Burn Down Charts mówiłem już, że widzimy tam pojawianie się nowej pracy i wypalanie starej. Problem Burn Down Chart polega na tym, że w przeciwieństwie do Cumulative Flow Chart nie widzimy na niej ruchu Historyjek Użytkownika po statusach. Kiedy natomiast zaczynamy obserwować ruchy po statusach w Cumulative Flow Chart, zaczynamy widzieć codzienne zmiany (Burn Down Chart może się nie zmieniać przez kilka dni i w niektórych kontekstach może to być całkiem normalne) i możemy zauważyć subtelniejsze problemy.
Oto jak to może wyglądać w dynamice (na obrazku diagram zbudowany na rzeczywistych danych).
W tym przykładzie widzimy następujące rzeczy
- Przez pierwsze 7 dni sprintu w testowaniu znajduje się bardzo mały wolumen pracy i nie zmienia się
- Z DOR (tutaj to szkic) do pracy Historyjki Użytkownika przechodzą dość równomiernie - to dobrze.
- Podobnie jak na Burn Down, widzimy, że zgodnie z tendencją Historyjki Użytkownika nie zostaną ukończone do końca sprintu
Te 3 obserwacje razem prowadzą do następującego wniosku. Tutaj wyraźnie już na wczesnych etapach (gdzieś w drugim-trzecim dniu sprintu) Scrum Master powinien był zwrócić uwagę na warstwę "Testowanie", która jest zbyt mała i nie zmienia się wystarczająco długo (ustalić, jaka jest przyczyna). Można przypuszczać, że wolumenu pracy gotowej do testowania nie da się przetestować z jakichś powodów, ale wtedy oznacza to, że testerzy stoją bezczynnie, a więc przynajmniej warto uważniej ich wysłuchać na najbliższym standupie.
Jeśli mówić o praktyce stosowania, to ja na przykład codziennie publikuję w czacie zespołu wszystkie metryki przed standupem, z oznaczeniem całego zespołu.
Ogólnie nie należy zapominać, że metryki trzeba jednak właściwie interpretować. Umieć dostrzegać rzeczywiście problemy systemowe, jeśli takie są, i nie uznawać za problemy tego, co w waszym kontekście może być nawet pozytywnym sygnałem
