Znasz Scrum, prawda? Sądzę, że tak, biorąc pod uwagę, że Scrum Alliance ma ponad 400 000 członków, a większość z nich z powodzeniem wykorzystuje je w swoich organizacjach.
Ale to nie jedyny sposób na tworzenie oprogramowania w zwinny sposób - poważnie! Czy słyszałeś o Kanbanie?
W celu uzyskania niewielkiej ilości informacji podstawowych, pierwotnie zastosowano ją do produkcji odchudzonej jako sposób na wizualizację nakładów i wyników pracy przepływającej przez fabrykę. Ta wizualizacja została zaprezentowana na tablicy zwanej „poczekaj na nią” Kanban. Niedawno i bardziej dotyczy Ciebie, została przyjęta jako metoda zarządzania tworzeniem oprogramowania.
Po raz pierwszy nakreślony przez neurologa Davida J. Andersona, jest to sposób organizowania rozwoju oprogramowania i planowania, który pozwala odkryć problemy z procesem i konsekwentnie dostarczać cennych ulepszeń w twoim produkcie - co wiem, brzmi idealnie. Mówiąc najprościej, w dowolnym momencie możesz zobaczyć, gdzie praca (reprezentowana przez karty) jest w trakcie opracowywania.
Jak to działa
Podstawowa tablica Kanban wykorzystuje sześć kolumn, które pokazują, gdzie każda część pracy znajduje się w cyklu rozwoju produktu. Poniżej znajduje się przybliżona próbka tego, jak to wygląda.
Zobacz przykład tablicy Kanban na Trello.
Kolumna 1: Zaległości
Kolumna Backlog powinna zawierać priorytetową listę pomysłów, błędów lub potrzeb biznesowych. Karta nie musi jeszcze zawierać wielu szczegółów, ale powinna zawierać wystarczającą ilość informacji, aby członkowie zespołu zrozumieli, dlaczego jest ważna.
Kolumna 2: Planowanie
W tej kolumnie menedżer produktu wypełni specyfikację funkcji, spotykając się z interesariuszami biznesowymi, inżynierami i projektantami. Gdy będzie gotowy, przeniesie go do kolumny „Gotowy do inżynierii”.
Kolumna 3: Gotowy do inżynierii
Na tym etapie wszystkie karty powinny mieć szczegółową specyfikację. Chociaż możesz nadal mieć pytania dotyczące szczegółów technicznych, wymagania biznesowe powinny być jasne.
Kolumna 4: W toku
W dowolnym momencie możesz przenieść kartę do „W toku”. Ten samobieżny system „pull” buduje kulturę osobistej odpowiedzialności i ciekawości.
Kolumna 5: Testowanie
Po zakończeniu pracy nad kartą przenieś ją do „Testowania”, gdzie odbierze ją inny inżynier (lub ktoś z zespołu kontroli jakości).
Kolumna 6: Wdrożone
Kolejną cechą charakterystyczną jest to, że praca powinna być stale dostarczana do środowiska testowego lub produkcyjnego. Ta kolumna pozwala każdemu zespołowi zobaczyć, jakie prace zostały ostatnio wydane.
Zalety i kompromisy
Kiedy decydujesz się na Kanban i bardziej popularną metodologię, taką jak Scrum lub Waterfall, pamiętaj o tych korzyściach i wyzwaniach:
Korzyści: poprawia współpracę
W niektórych zespołach programistycznych, z którymi współpracowałem, inżynierami byli specjaliści. Każda drużyna miałaby kilku inżynierów i inżynierów. Oznaczało to, że praca była często blokowana, ponieważ inżynier był zajęty czymś innym.
Z drugiej strony Kanban ogranicza trwającą pracę i zniechęca do blokowania. Każdy członek zespołu może pracować tylko nad jednym przedmiotem na raz, a każdy, kto nie jest zajęty, może wyciągnąć pracę z góry kolumny „Gotowy do inżynierii”. Zachęca to inżynierów ogólnych i współpracę między członkami zespołu.
Zwiększ korzyści: nie pozwól, aby rzeczy minęły, zanim będą gotowe
Kanban działa tylko wtedy, gdy czekasz na przeniesienie kart do następnej kolumny, dopóki nie zostaną całkowicie ukończone. (Bonus: To znacznie minimalizuje wady.)
Wyzwanie: zniechęca do refleksji
Domyślnie nie ma sprinterów w określonych przedziałach czasowych z jasnymi celami, datami i cyklami wypuszczania. Zamiast tego pomyśl o każdej karcie jako niezależnym dziele, które można wykonać i wydać w dowolnym momencie.
Przy ciągłym strumieniu pracy nie ma opcji „czekaj do następnego sprintu”. Musisz ciągle sprawdzać planszę, ciągnąć następny przedmiot i przenosić ukończone przedmioty w dół. Jeśli nie zdążysz przygotować się na retrospekcję i starcia, członkom zespołu może być trudno nadążyć za ich postępem.
Porusz się: pożycz, co działa od Scruma
Korzystałem z codziennych standupów i retrospekcji w Kanban i odkryłem, że dodają one wartości. Jeśli istnieją regularne spotkania lub wzorce, które działają dla Twojego zespołu, nie zmieniaj ich, aby dogmatycznie stosowały się do Kanbana. Budżetuj czas na rozmowy o priorytetach i ich zmianie, aby wszyscy wiedzieli, co dzieje się w cyklu rozwoju produktu.
Korzyści: Zwiększa przejrzystość
Każdy programista musi podjąć inicjatywę, aby przenieść kartę do kolumny „W toku”. Oznacza to, że w dowolnym momencie kierownik zespołu może sprawdzić, kto jest zajęty, a kto nie, i jak długo trwa praca.
Gdy produkcja zwalnia lub zatrzymuje się, Kanban pozwala dokładnie zobaczyć, dlaczego. Niezależnie od tego, czy jest to spowodowane tym, że zespół biznesowy nie nadał priorytetu elementom zaległości, zespół ds. Produktu nie ukończył specyfikacji, zespół programistów porusza się wolniej niż oczekiwano, czy zespół ds. Kontroli jakości nie był w stanie czegoś przetestować; wąskie gardła są oczywiste.
Zwiększ korzyści: pozwól, aby postęp był publiczny
Jedną z zalet jest to, że Kanban jest bardzo wizualny. Nawet nietechniczni członkowie zespołu mogą spojrzeć na tablicę Kanban i powiedzieć, gdzie trwają prace. Wykorzystaj to na swoją korzyść i pozwól lśnić osiągnięciom zespołu, umieszczając tablicę w miejscu publicznym.
Wyzwanie: nie pozwala na planowanie długoterminowe
Martwienie się o terminy i szacunki nie jest najbardziej produktywnym wykorzystaniem twojego czasu, więc możesz docenić, że Kanban bardziej skupia się na codziennej produkcji. To powiedziawszy, samo nie zapewnia systemu do budowania długoterminowego planu. Może to powodować sporadyczną pracę nad projektami zamiast koncentrowania się na jednej rzeczy przez długi czas. Trudno jest spędzić dzień na Projekcie A, a następnie na Projekcie B, a następnie wrócić do Projektu A.
Porusz się: używaj go, gdy Twoje priorytety prawdopodobnie się zmienią
Każda kolumna na planszy jest niezależna od innych, więc członkowie zespołu mogą przenosić rzeczy w dowolnym momencie. Może to denerwować programistów w ustawieniach Scrum (gdzie szacunki dla sprintu są dokonywane z góry), ale Kanban rozwija się w tego rodzaju szybko zmieniającym się środowisku.
Każdy chce być bardziej produktywny, ale może być trudno wypróbować coś nowego, jeśli nie jesteś nawet pewien, od czego zacząć. Uważam, że Kanban jest pomocny i mam nadzieję, że okaże się również przydatny w twoim osobistym przepływie pracy (a nawet dla całego zespołu!).
Tweetnij, jeśli zdecydujesz się spróbować!
