Limity WIP jako sposób na przywrócenie „przepływu” w przepływie pracy

W programowaniu Agile limity prac w toku (WIP) wyznaczają maksymalną liczbę prac, która może mieć równocześnie jednakowy status w przepływie pracy. Ograniczenie liczby prac w toku ułatwia identyfikację obszarów niskiej efektywności w przepływie pracy zespołu. Wąskie gardła w pipelinie dostarczania zespołu są wyraźnie widoczne, zanim sytuacja stanie się krytyczna.

Teraz myślisz sobie pewnie: „Mów dalej!” (a przynajmniej mam taką nadzieję).

Limity WIP zwiększają produktywność i pozwalają ograniczyć liczbę „prawie gotowych” prac poprzez wymuszenie na zespole skoncentrowania się na mniejszych zbiorach zadań. Na poziomie podstawowym limity WIP sprzyjają kulturze opartej na dążeniu do kończenia zadań. Co ważniejsze, limity WIP uwidaczniają blokery i wąskie gardła. Gdy pojawi się sygnał, że konkretna praca powoduje wąskie gardło, zespoły mogą razem pochylić się nad zgłoszeniami powodującymi blokady, aby je zrozumieć, wdrażać i rozwiązywać. Po usunięciu blokad przepływ pracy w zespole zostaje przywrócony. Pozwala to zagwarantować szybsze dostarczanie klientom przyrostów korzyści, dzięki czemu limity WIP stają się cennym narzędziem w procesie programowania Agile.

W trakcie prac programistycznych łatwo można ulec pokusie, aby pomyśleć: „zrobię sobie przerwę z tym zgłoszeniem i zacznę pracę nad innym”. Dwa otwarte zgłoszenia oznaczają przełączanie kontekstu między dwoma różnymi aspektami lub przesyłanie prac między członkami zespołu. Odpuszczenie jednego zgłoszenia na rzecz innego ma swoją cenę — zajmuje czas i obniża koncentrację. Niemal zawsze lepiej jest kontynuować pracę nad oryginalnym zgłoszeniem, niż rozpocząć nowe i go nie ukończyć. Innymi słowy, limity WIP zniechęcają nas do tamowania własnego przepływu.

Ponadto limity WIP wskazują również obszary chronicznej bezczynności lub przeciążenia pracą. Pomagają one zespołowi dostrzegać braki efektywności w całym procesie, a nie tylko w konkretnym zakresie prac, którym zespół się zajmuje.

Teraz, gdy zaintrygowały Cię już zalety tego rozwiązania, możemy przejść do konkretów.

Podczas wdrażania nowego przepływu pracy określ razem z zespołem limity WIP dla każdego statusu. My zalecamy ustalanie limitów WIP w oparciu o wyniki prowadzonej przez kilka sprintów obserwacji średniej liczby jednostek pracy na poszczególnych etapach. Poniżej znajduje się przykładowa tablica Agile z limitami WIP, z której korzysta typowy zespół programistyczny.

W powyższym przykładzie ustalono limit WIP dla etapu przeglądu kodu. Limit w kolumnie został przekroczony, zatem kolor tła zmienił się na czerwony.

Ponieważ po rozwiązaniu zgłoszenia wszystko jest już zrobione, w takiej sytuacji nie ma potrzeby stosowania limitu WIP. Na powyższej tablicy Kanban stan „Do zrobienia” oznacza, że historyjka została w pełni sprawdzona przez product ownera i zespół. Przystępując do realizacji jednostek pracy, zespół programistów przenosi pracę z kolumny „Do zrobienia” do kolumny „W toku”. Najlepszą praktyką jest zadbanie o to, aby status „Do zrobienia” miała taka liczba zadań, która pozwala w pełni wykorzystać potencjał wykonawczy każdego członka zespołu programistycznego. Dzięki utrzymywaniu optymalnej liczby historyjek o statusie „Do zrobienia”, product owner nie wybiega zbyt daleko w przyszłość, jeśli chodzi o precyzowanie szczegółów wymagań, a program lepiej reaguje na zmiany.

Kolumna „W toku” zawiera zadania, nad którymi aktywnie pracują programiści. Celem limitów WIP w tym przypadku jest zapewnienie, aby każdy miał co robić, ale nikt nie był obciążony wieloma zadaniami. Na powyższej tablicy limit prac w kolumnie „W toku” wynosi 4, a obecnie na tym etapie są 3 jednostki pracy. Jest to dla zespołu informacja, że dysponuje potencjałem wykonawczym do podjęcia się jeszcze jednego zadania. Dobrym rozwiązaniem stosowanym przez niektóre zespoły jest ustawienie limitu WIP na poziomie niższym niż liczba członków zespołu. Ma to na celu utrwalanie dobrych praktyk Agile. Jeśli programista kończy pracę nad jednostką, a zespół osiągnął już limit WIP, taka osoba wie, że nadszedł czas na uporanie się z kilkoma przeglądami kodu lub dołączenie do innego programisty i wspólną pracę razem z nim.

Do kolumny „Przegląd kodu” trafiają historyjki, które zostały w całości napisane, jednak przed scaleniem z bazą kodu wymagają sprawdzenia. Najlepszą praktyką jest terminowe recenzowanie kodu, które ułatwia zapewnienie wysokiej jakości, przyspiesza wprowadzanie nowych, innowacyjnych rozwiązań na rynek, ułatwia scalanie poprzez ograniczenie liczby otwartych gałęzi i sprzyja dzieleniu się wiedzą wśród członków zespołu inżynierskiego. Jednostkami pracy na tym etapie należy zajmować się w trybie pilnym z kilku powodów:

• Jakość kodu nie ulega pogorszeniu, ponieważ członkowie zespołu sprawdzają nowy kod.
• Programista nie traci kontekstu poznanego podczas tworzenia pierwotnego kodu.
• Funkcję można sprawnie scalić z gałęzią główną w celu wydania.

Limity WIP pozwalają wyeliminować gromadzenie się niesprawdzonego kodu.

Zauważ, że na powyższej tablicy zespół ma zbyt wiele pozycji w kolumnie przeglądu kodu, dlatego została ona podświetlona na czerwono, sygnalizując ten problem.

Podobnie jak w przypadku każdej nowej aktywności, na początku limity WIP mogą wydawać się nieco dziwne. Ich celem jest jednak optymalizacja pracy zespołu w perspektywie średnioterminowej, a nieporadność, jaka pojawia się na krótką metę, jest w istocie pozytywnym zjawiskiem. Sprawia, że zespół dostrzega pewne bolączki w swoim procesie. Po kilku tygodniach stosowania przez zespół limitów WIP warto wprowadzić odpowiednie korekty. Nie ulegaj pokusie zwiększania limitu WIP tylko dlatego, że zespół ustawicznie go przekracza. Wykorzystaj to jako okazję do zwiększenia potencjału wykonawczego, najlepiej poprzez edukację członków zespołu i zdobycie przez każdego z nich nowych umiejętności, bądź usprawnienie niektórych aspektów procesu programistycznego.

Cel 1: Ujednolicenie wielkości poszczególnych zadań. Dokonując podziału wymagań i historyjek użytkowników, należy pamiętać, aby poszczególne zadania trwały nie dłużej niż 16 roboczogodzin. To pozwala zwiększyć zdolność zespołu do trafnego szacowania i ułatwia zapobieganiu powstawania wąskich gardeł. Nic nie spowalnia zespołu i nie zaburza limitów WIP tak bardzo, jak ogromna jednostka pracy, która utknie w pipelinie.

Cel 2: Odwzorowanie limitów WIP w kompetencjach zespołu. Powyższy przykład zakłada, że członkowie zespołu dysponują podobnymi zestawami umiejętności. Jeśli w Twoim zespole pracują specjaliści, limity prac w toku mogą ulegać zmianie w sytuacjach, gdy korzysta się z ich usług. Utwórz wówczas specjalny status dla pracy specjalisty. Jeśli w obrębie tego statusu będą występowały wąskie gardła, wykorzystaj to jako szansę do dokształcenia innych członków zespołu w celu zaspokojenia dodatkowego zapotrzebowania na kompetencje specjalisty, a tym samym zwiększenia przepływu na poziomie całego zespołu.

Cel 3: Ograniczenie bezczynności. Gdy u jakiegoś członka zespołu występuje przestój, zachęć taką osobę do udzielenia wsparcia innemu członkowi zespołu na wcześniejszym lub późniejszym etapie. Pozwoli to nie tylko poprawić ogólną produktywność zespołu, ale także zdobyć jego członkom nowe umiejętności!

Cel 4: Ochrona zrównoważonej kultury inżynierskiej. Limity prac w toku nie oznaczają, że programiści muszą się spieszyć, aby uniknąć przeładowania konkretnego statusu zbyt dużą liczbą jednostek pracy. Ich celem jest wspieranie dobrze ugruntowanych praktyk inżynierskich Agile, które zapewniają wysoką jakość produktu i właściwą kondycję bazy kodu.

Jeśli Twój zespół jest gotowy do wdrożenia limitów WIP, użyj naszego szablonu tablicy Kanban, aby zacząć bez ponoszenia kosztów.