Proces tworzenia oprogramowania można traktować jako rurociąg z żądaniami funkcji wchodzącymi z jednej strony i lepszym oprogramowaniem wychodzącym z drugiej.

Wewnątrz rurociągu, istnieje pewien rodzaj procesu, który może wahać się od nieformalnego procesu ad hoc do bardzo formalnego etapowego procesu. W tym artykule, założymy prosty proces fazowy: (1) analiza wymogów, (2) opracowanie kodu i (3) testowanie jego pracy.

Efekt wąskich gardeł

Wąskie gardło w rurociągu ogranicza przepływ. Przepustowość całego rurociągu jest ograniczona do przepustowości wąskiego gardła.

Jako przykład wykorzystamy nasz rurociąg tworzenia: jeśli testerzy są w stanie przetestować 5 funkcji w tygodniu, podczas gdy programiści i analitycy są w stanie wyprodukować 10 funkcji w tygodniu, przepustowość całego rurociągu wyniesie tylko 5 funkcji w tygodniu, gdyż testerzy działają jako wąskie gardło.

Jeśli analitycy i programiści nie zdadzą sobie sprawy, że testerzy stanowią wąskie gardło, wtedy przed testerami piętrzyć się będą zaległości w pracy.

clip_image001

W wyniku tego, czas realizacji zwiększy się. Jak zapasy w magazynie, praca stojąca w rurociągu zamrozi inwestycję, stworzy dystans z rynkiem i z czasem spadnie na wartości.

Nieuchronnie ucierpi jakość. Aby być na bieżąco, testerzy zaczną iść na skróty. Wynikające błędy dopuszczone do produkcji spowodują problemy dla użytkowników i marnują przyszłą przepustowość rurociągu.

Z drugiej strony, jeśli wiedzielibyśmy gdzie znajduje się wąskie gardło, moglibyśmy ponownie ulokować środki w celu jego usunięcia. Na przykład, analitycy mogliby pomóc w testowaniu a programiści mogliby popracować nad automatyzacją testów.

Ale skąd mamy wiedzieć, gdzie znajduje się wąskie gardło w konkretnym procesie? I co się stanie, gdy się przemieści?

Kanban dynamicznie wykrywa wąskie gardła

Kanban jest nadzwyczaj prosty, ale jednocześnie bardzo potężny. W najprostszej formie, system Kanban składa się z dużej tablicy na ścianie z umieszczonymi na niej kartami i nalepkami w kolumnach z numerami na górze.

Ograniczenie pracy w toku ujawnia wąskie gardła, dzięki czemu można się nimi zająć.

Karty reprezentują elementy robocze przepływające przez proces rozwoju reprezentowane przez kolumny. Numery u góry każdej kolumny to limity dotyczące ilości kart dopuszczalnej w każdej kolumnie.

Limity stanowią istotną różnicę pomiędzy tablicą Kanban a innymi tablicami typu storyboard. Ograniczenie ilości prac w toku (WIP) na każdym etapie procesu zapobiega nadprodukcji oraz szybko wykrywa wąskie gardła, tak że można im zapobiec zanim wymkną się spod kontroli.

Opracowany przykład

Poniższa tablica ukazuje sytuację, gdzie deweloperzy i analitycy nie mogą wziąć więcej pracy do czasu zanim testerzy nie zwolnią otworu i nie wezmą się za nowy element roboczy. W tym momencie, deweloperzy i analitycy powinni szukać nowych sposobów pomocy testerom w ich pracy.

clip_image002

Zauważ, że podzieliliśmy niektóre kolumny na dwie części, aby wskazać elementy robocze w toku i te skończone i gotowe do przekazania do procesu następczego. Istnieje kilka różnych układów na tablicy. Jest to dość prosty sposób. Limity na górze podzielonych kolumn obejmują zarówno kolumny „doing” (w toku) jak i „done” (zakończone).

Po skończeniu testowania funkcji przez testerów, przesuwają kartę na wolne miejsce w kolumnie „Test” (Testy).

clip_image003

Teraz puste miejsce w kolumnie „Test” może zostać wypełnione jedną z kart w kolumnie produkcji „done” (zakończone). To zwalnia miejsce pod „Development” (Tworzenie) i następna karta może być przeciągnięta z kolumny „Analysis” (Analiza), itd.

clip_image004

Buforuj swoje wąskie gardła

W związku z tym, żewąskie gardło jest tak ważne, jedną z rzeczy jakie chcemy zrobić jest upewnienie się, że rzadko (najlepiej nigdy) nie będzie brakowało mu pracy. Możesz zastanawiać się w jaki sposób wąskie gardło może nie mieć pracy, podczas gdy, z definicji, jest zasilane przez szerszy rurociąg? Rzeczą wartą zapamiętania jest fakt, iż w naszym systemie Kanban celowo ograniczamy pracę w toku (WIP), a elementy robocze różnią się pod względem rozmiaru; a więc kilka przetwarzanych dużych elementów na wcześniejszym etapie procesu może tymczasowo zagłodzić wąskie gardło.

Rozwiązaniem tego problemu jest umieszczenie buforu przed wąskim gardłem, jak na wykresie poniżej. W tym przykładzie, wąskim gardłem jest zespół deweloperski, należy więc umieścić bezpośrednio przed nim bufor z limitem 3 elementów roboczych (numery u góry kolumn to limity).

clip_image005

Jak zwymiarować bufor?
Każdy dodatkowy element WIP niesie za sobą karę w postaci czasu realizacji, tak więc zacznij od małych ilości i reguluj je w górę i w dół empirycznie. Inną rzeczą godną rozważenia jest podzielenie większych elementów roboczych na mniejsze elementy, lub odwrotnie – łączenie kilku małych elementów, aby stworzyły większe elementy. Zmniejszenie różnorodności rozmiarów elementów roboczych umożliwi zmniejszenie rozmiaru buforu.

Ile buforów potrzebujemy?
Ściśle rzecz biorąc, w dowolnym momencie w czasie, w rurociągu może być tylko jedno wąskie gardło. Jednakże, w przypadku zmian – nie tylko w zakresie rozmiaru elementów roboczych, ale również w zakresie rodzaju prac i zaangażowanych osób – wąskie gardło może od czasu do czasu się przesuwać. Po jakimś czasie stosowania systemu Kanban, będziesz w stanie wyczuć gdzie najczęściej występują wąskie gardła. Ulokuj swoje bufory w odpowiedni sposób.

Powodzenia Uśmiech

Pisząc ten tekst inspirowałem się pisami na http://kanbanblog.com/. Z tej strony pochodzą też rysunki.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close