Odpowiedzi:
Nie, nie ma formuły. Nie ma jednego
Wiele zależy od sposobu pracy zespołu, praktyk, których używasz itp. Jeśli sparujesz program, będziesz mieć niższe limity w kolumnie programowania niż wielu programistów.
Jeśli wprowadzisz Kanban do istniejącego zespołu, możesz spróbować zmapować całą trwającą obecnie pracę do MMF, a następnie zobaczyć, ile funkcji masz w różnych kolumnach. Dałoby to wgląd w to, jakie ograniczenia naprawdę masz w tej chwili i jest to dobry punkt wyjścia do ustalenia limitów Kanban.
Kolejna rada, którą dostajesz, to iść z przeczuciem swojego / twojego zespołu. Rób to, co uważasz za słuszne. Następnie sprawdź, czy twoje limity nie są zbyt napięte czy zbyt luźne i dostosuj. Niektórzy mówią, że „tablica ci powie” i to w zasadzie prawda. Jeśli trafisz na wąskie gardło co tydzień, prawdopodobnie masz ustawione zbyt niskie limity. Jeśli jeden lub dwa programy blokujące nie stanowią problemu, limity problemów są zbyt wysokie.
Napisałem post, w którym ustaliliśmy nasze limity podczas tworzenia naszej tablicy Kanban: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html
Próbowałem dwóch skrajności, obie sugerowane przez różnych ludzi. Jednym z nich jest stosowanie wysokich limitów i modyfikowanie ich, aż boli, a drugie jest odwrotnie, zaczynając od n-1, gdzie n jest liczbą osób, które mogłyby przyciągnąć zadanie do tej kolumny. To ostatnie jest bardziej bolesne dla zespołów, które dopiero zaczynają korzystać z Kanban, ale pomogło nam dojść do punktu maksymalizacji przepływu szybciej niż pierwsza opcja, ponieważ kiedy poczuliśmy ból (wąskie gardła), naszym pierwszym instynktem było zbadanie problemu z podniesieniem limitu PWT jako w ostateczności, w wyniku czego odkryliśmy i rozwiązaliśmy kilka problemów procesowych, które w innym przypadku mogłyby być niewidoczne.
Chociaż zgadzam się, że nie ma formuły jako takiej - jednocześnie istnieje prawdziwa możliwość modelowania procesu Kanban. Pomoże to w symulacji prawdopodobnych wyników takich rzeczy jak czas cyklu, czas oczekiwania, wydajność itp.
Wdrożyłem taki symulator, który modeluje nasz proces Kanban. Symuluje przepływ historii na całym świecie pod naszymi ograniczeniami Kanban wokół limitów PWT i zasobów zespołu. Mamy stan wymagający zewnętrznego przeglądu klienta. Wszyscy podejrzewaliśmy, że ten etap zabija nasz czas cyklu, tworząc kopię zapasową naszych historii.
Odczucie było wyczekiwane na tym etapie, ale nie wiedzieliśmy, czy po prostu rozwiąże to problem gdzie indziej. Nie wiedzieliśmy też, jak daleko posunąć się w boksie czasowym, ani jak bardzo by to poprawiło.
To bardzo dobrze, mówiąc, po prostu poprawianie, ale może być bardzo destrukcyjne. Ludzie przyzwyczają się do procesu i sfrustrują kogoś, kto nieustannie próbuje ulepszyć przeczucie. Dlatego często musisz wprowadzić bardzo dobry przypadek przed wprowadzeniem zmiany.
Podczas modelowania możesz modyfikować bez zakłóceń i mieć znacznie większą pewność, że Twoje poprawki zapewnią oczekiwany rezultat. Plus, to w jakiś sposób przyczyni się do uzyskania magicznej formuły.
Zacznę od liczby „miejsc” w każdej kolumnie, która jest równa liczbie osób, które podejmą pracę w powiązanej kolumnie. To ujawni wąskie gardła lub punkty bólu. Zajmij się punktem bólu, aż zniknie.
Z biegiem czasu eksperymentuj ze zmniejszaniem liczby miejsc w każdej kolumnie.
Używam dwóch technik określania limitu PWT, kiedy rozpoczynamy nowy projekt lub zespół.
W przypadku projektu rozwojowego: pracujemy w parach (robimy XP), co oznacza, że dwóch członków może pracować nad jednym elementem na raz. Gdyby zespół składał się z 6 osób, PWT wynosiłby 3, zgodnie z poprzednim zdaniem. Jednak programowanie parami jest męczącym zajęciem, a czasami koledzy chcieliby pracować trochę samotnie, daję plus jeden, więc limit WIP dla 6 członków wynosiłby 4.
Kiedy mówimy o projekcie konserwacji, testu weryfikacyjnego lub wsparcia, sprawdzam, ile pracy równoległej mogą wykonywać różni koledzy, sumuję ten numer i odejmuję go jednym. Na przykład każdy z wcześniej wspomnianego zespołu może zająć się 2 równoległymi sprawami, to sprawiłoby, że limit WIP wynosi 12, ale przy -1 -1 wynosi 11. -1 zapewnia mi, że zespół pozostaje skupiony i współpracuje. Gdyby w tym przypadku limit PWT wynosił 12, wszyscy pracowaliby na jego / jej maksymalnie dwóch kartach i współpraca nie byłaby możliwa.
Chcę zrozumieć, że używam tych technik dopiero na początku, kiedy rozpoczyna się projekt / zespół. Następnie dostosowanie limitu PWT jest obowiązkiem zespołu na podstawie jego uczuć, obciążenia, celu itp.