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

Limity prac w toku nie ograniczają postępów. W istocie jest wręcz przeciwnie.

Dan Radigan Dan Radigan
Przeglądaj tematy

Czym są limity WIP?

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.

Dlaczego limity WIP są istotne?

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.

Wskazówka eksperta:

W przypadku zespołów, które dopiero zaczynają korzystać z limitów WIP, mogą one wydawać się kłopotliwe. W trakcie kilku pierwszych iteracji znajdź czas na omówienie tej kwestii. Dowiedz się, kiedy i dlaczego zespół przekracza limity WIP. Nie ulegaj początkowej pokusie zwiększenia tych limitów. Jeśli limity będą stale przekraczane, to znak, że przewidziany limit jest zbyt rygorystyczny lub proces zespołu jest mało efektywny.

Korzystanie z limitów WIP w zespołach Agile

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.

Limity WIP | Atlassian Agile Coach

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.

Since there's nothing left to do once an issue reaches done, there is no need for a WIP limit there. In the board above, "To do" signifies that the story has been fully vetted by the product owner and team. The development team pulls work from "To do" into "in progress" as they start on work items. As a best practice, it's important to keep enough work in the "To do" status so that each member of the development team remains fully utilized. By keeping only just enough stories in the "To do" state, the product owner doesn't get too far ahead of the game when it comes to fleshing out requirements, and the program becomes more responsive to change.

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 Agile zespół ma zbyt wiele pozycji w kolumnie przeglądu kodu, dlatego została ona podświetlona na czerwono, sygnalizując ten problem.

Błędy, których nie należy powielać:
  • Podnoszenie limitów WIP w razie potrzeby, aby zespół ich nie przekroczył. („Limit zadłużenia” — brzmi znajomo?).
  • Realizowanie przez każdego członka zespołu obszernego „zadania w tle”, maskującego momenty, które w innym przypadku zostałyby uznane za okres bezczynności.
  • Bezczynne oczekiwanie członków zespołu na nadejście kolejnych prac, zamiast wspólnego zajęcia się wąskimi gardłami.
  • Eliminowanie wąskich gardeł poprzez przydzielanie większej liczby roboczogodzin zamiast wprowadzania poprawek w praktykach inżynierskich lub procesach zespołowych.

4 cele zespołów Agile korzystających z limitów WIP

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.

Wskazówka eksperta:

Gdy limity prac w toku zaczną działać na korzyść zespołu, skróceniu ulegnie czas cyklu zgłoszenia. Czas cyklu to ilość czasu, który zajmuje ukończenie zgłoszenia. Więcej informacji na ten temat zawiera nasza strona dotycząca wskaźników Agile.

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.