Źródło obrazu: pixabay.com

Dzisiejsze zespoły oprogramowania, przynajmniej w swoich procesach, są bardziej zwinne! Są skłonni myśleć poza ustawionymi parametrami, aby podążać za tym, co im odpowiada. Chętnie uczą się i przyjmują nowe techniki zarządzania projektami i procesów projektowych.

Metoda zarządzania projektami o nazwie Kanban od kilku lat robi obchody w branży oprogramowania i zyskała na wartości w ciągu ostatnich pięciu lat. Wraz z metodologią Agile przyjęcie metody Kanban dało firmom wiele do świętowania.

Ale jest też krytyka, że ​​Kanban jest niczym innym jak sławną listą rzeczy do zrobienia. O co w tym wszystkim chodzi? Dowiedzmy Się.

Co to jest Kanban?

Jeśli Twoja firma jest gotowa wyjść poza tradycyjne podejście do zarządzania projektami oprogramowania, dziś nie brakuje technik zarządzania projektami.

Po pierwsze, istnieje system Agile Project Management, który koncentruje się na nieliniowych, iteracyjnych metodach tworzenia oprogramowania. Zastosowanie metod Agile jest widoczne w Scrumie, który koncentruje się na bardziej elastycznym podejściu do zarządzania projektami.

Agile ma również linki do innych ram zarządzania projektami, takich jak Kanban i Extreme Programming. Spośród nich Kanban zyskał dużą popularność. W końcu kto nie chce, aby Japończycy ewoluowali?

Kanban to koncepcja, która ewoluowała w zakładzie produkcyjnym Toyota w celu osiągnięcia produkcji just-in-time (JIT), która obniża koszty i umożliwia mniejsze wykorzystanie zasobów. W swojej istocie kieruje się zasadą „ciągnięcia” pracy, co oznacza, że ​​zadania lub produkty muszą być „ciągnięte” według wymagań i popytu, a nie „wypychane” z góry na dół. Został opracowany w celu zapewnienia lepszego zaopatrzenia w części samochodowe w zakładach Toyoty, w zależności od zapotrzebowania. Oznaczało to, że wraz ze wzrostem popytu żądania będą wypełniane.

Koncepcja została zaadaptowana do branży oprogramowania z kilkoma zmianami przez Davida Andersona w jego książce Kanban z 2010 roku. Od tego czasu jest wykorzystywany do różnych projektów z dużym sukcesem. Może to być bardzo pomocne w złożonych projektach, które mogą cierpieć z powodu przeciążenia po jednej stronie cyklu rozwoju.

Zasadniczo system Kanban traktuje proces projektu oprogramowania jako potok. Powiedzmy, że proces oprogramowania ma trzy typy zadań: analiza, rozwój, testowanie i wreszcie wdrożenie. Powiedzmy, że jest dwadzieścia zadań do wykonania.

W przypadku tradycyjnego systemu zarządzania projektami, jeśli na przykład

  • W sumie jest 25 historii
  • Analitycy są w stanie poradzić sobie z pięcioma historiami tygodniowo
  • Deweloperzy mogą obsługiwać pięć historii tygodniowo
  • Testerzy są ograniczeni do trzech historii na tydzień

W tej sytuacji praca po prostu nakłada się na koniec testerów. Pod koniec pierwszego tygodnia sytuacja będzie wyglądać następująco:

  • Tylko trzy historie przeszły do ​​wdrożenia.
  • Deweloperzy i analitycy pracują nad trzema historiami, ponieważ testerzy nie są w stanie pobrać wyników twórców i przetestować tego samego.
  • Praca się gromadzi, pozostawiając programistów, analityków i kierownika projektu w naprawie.

Analitycy i programiści mogą teraz po prostu poruszać kciukami! Lub ich kierownik może zdać sobie sprawę, że są bezczynni i przenieść ich do innego projektu, w którym może wystąpić podobna sytuacja. Są więc dwa projekty, które utknęły w fazie testowania!

Problemy w takiej sytuacji nie są trudne do zauważenia. Jaki jest sens opracowania dziesięciu historii (lub fragmentów oprogramowania), gdy nie będą one wkrótce testowane?

Teraz przejdźmy do metody Kanban.

Metoda Kanban jest niezwykle prostą koncepcją. Wynika to z prostej logiki polegającej na użyciu „metody ściągania” w celu usunięcia wąskich gardeł w pierwszej kolejności i ograniczenia prac w toku (WIP) w celu uzyskania lepszych procesów roboczych.

W najprostszej formie Kanban, dosłownie, „wizualna tablica” pomaga „wyciągając” elementy z listy rzeczy do zrobienia, zamiast pracować z osiami czasu. Metoda Kanban pomaga zidentyfikować wąskie gardła, aby lepiej zarządzać przepływem procesu.

Podstawowa tablica Kanban ma listę zadań do wykonania, zadań w toku i zadań ukończonych.

Jednak w zarządzaniu oprogramowaniem zadania mogą być nieco bardziej złożone. Większość projektów zwinnych ma podobną zarząd. Na planszy Kanban etapy wdrożenia są wyraźnie oznaczone, wraz z numerem dla każdej kolumny. Liczba ta reprezentuje maksymalną liczbę zadań lub historii, które dany krok może obsłużyć.

Nasz przykład na tablicy Kanban wyglądałby mniej więcej tak na początku drugiego tygodnia. Oznacza to, że programiści i analitycy nie będą pracować nad optymalną liczbą artykułów w tym tygodniu. Byłoby oczywiste, że praca jest gromadzona na końcu testera. Organizacje mogą zapewnić współpracę zespołów w celu przeprowadzenia testów. Ewentualnie mogą spojrzeć na inne modele przebiegu procesu, aby tak się nie stało.

Kiedy projekty są obsługiwane przez system Kanban, jest mniej miejsca na gromadzenie pracy. Historie są pobierane zgodnie z maksymalną dostępną przepustowością.

W typowej konfiguracji Kanban praca będzie podejmowana zgodnie z dostępną przepustowością, a zespoły będą ją przyciągać, tak aby zawsze miały maksymalną przepustowość. System pozwala również na szybkie śledzenie pilnych zadań, tak aby poruszały się po planszy przy minimalnym wysiłku.

Spójrz na tę tablicę Kanban.

Oczywiste jest, że wszystkie kroki działają z maksymalną wydajnością. Uwzględniono także zadanie znajdujące się w „Szybkiej ścieżce”.

Kanban w żadnym wypadku nie jest jedyną metodą zwiększania wydajności poprzez ograniczanie WIP. Istnieją inne systemy, które osiągają ten sam wynik - na przykład systemy CONWIP (Constant Works in Progress) i DBR (Lina-Bufor-Bufor-Bufor), które są przeznaczone głównie dla przemysłu wytwórczego.

Jednak Kanban to system, który najlepiej zmodyfikować, aby pasował do branży oprogramowania.

Czym Kanban różni się od metodologii zwinnych?

U podstaw Kanban leży metodologia wykorzystująca pewne elementy Agile Project Management. Wiele projektów w ramach Agile ma swoje korzenie w podejściach Lean. Różnica między metodologią Kanban a zwinnym zarządzaniem projektami nie jest tak czarno-biała, jak chcieliby nam wmówić zwolennicy obu metod. Mają więcej wspólnego niż różnice.

Ramy Agile nie są absolutne. Pytanie nie dotyczy tego, czy zespoły są zwinne, czy nie. Zespoły często mają zwinność w różnym stopniu. Jedną z metod zwiększania sprawności w procesie tworzenia oprogramowania jest użycie Kanban.

Istnieje kilka różnic między metodologiami Kanban i Agile. Niektóre funkcje programowania Kanban, które nieco różnią się od Agile, to:

  • Linie czasu nie są znaczącym czynnikiem . Jest to trudna koncepcja do obejścia, ponieważ wydaje się bardzo nieintuicyjna. „Jak pracujesz bez terminów?” Często pytają ludzie. Ale jeśli każdy członek zespołu jest zaangażowany z maksymalną wydajnością, czas przestaje być czynnikiem.
  • Historie (zadania) są większe niż w typowych systemach Agile. Zazwyczaj długość i złożoność historii jest dłuższa niż w przypadku typowego projektu Scrum. Ponieważ nie skupiamy się na szacowaniu czasu, ale po prostu na kontynuowaniu procesu, Kanban może sobie pozwolić na pracę nad większymi historiami.
  • Nie ma znaczących zmian w istniejących procesach. Zasady Kanbana dotyczące tworzenia oprogramowania, sformułowane przez jego założyciela, Davida Andersona, na jego blogu, obejmują następujące podstawowe zasady:
    • Zacznij od tego, co robisz teraz
    • Zgadzam się dążyć do stopniowych zmian ewolucyjnych
    • Przestrzegaj obecnego procesu, ról, obowiązków i tytułów
  • Każda historia mierzona jest w czasie cyklu . Projekt jest oceniany nie przez tradycyjne zwinne obliczanie prędkości (liczba kondygnacji ukończonych w danym czasie), ale przez czas cyklu. Oznacza to, że Kanban kładzie nacisk na czas potrzebny na wykonanie zadania. Na wielu tablicach Kanban często widnieje napis, który wspomina, ile dni zespół zajmuje ukończeniu historii. Oszacowanie wprowadza się do następnego cyklu.

Kanban: Zarząd, ale co jeszcze?

Kanban to tablica, która pokazuje nam, jak układane są historie - czy to nawet tak wielka sprawa, wielu pyta. W rzeczywistości odbywa się wiele dyskusji na temat tego, czym Kanban jest i co może zrobić.

Czy Kanban jest tylko metodą zarządzania przepływem pracy? Czy jest to coś, co można zastosować wraz z metodologiami Agile w celu uzyskania maksymalnej wydajności? Czy może to być zupełnie nowy sposób zarządzania przepływem pracy?

Każda drużyna korzysta z Kanbanu według własnego uznania, w zależności od konkretnej sytuacji. Niezależnie od tego, Kanban może pracować jako sposób na życie przy tworzeniu oprogramowania, o ile zostanie wykorzystany na optymalnym poziomie.

Niezależnie od tego, czy jest on używany do zarządzania przepływem pracy, czy jako nowy paradygmat w rozwoju oprogramowania, nie można zaprzeczyć, że pomaga on zarządzać PWT.

Aby Kanban działał najlepiej, ważne jest, aby myśleć o nim nie tylko jako o zarządzaniu PWT, ale o strukturze zarządzania projektami. Pewne podstawowe wytyczne pomogą w tym procesie.

  1. Zoptymalizuj zespoły, aby żaden zespół nie zaczął czegoś, czego nie może zakończyć. Pomaga to cały proces.
  2. Nie opieraj się zmianom oryginalnego systemu Kanban. Jeśli twój projekt dobrze sobie radzi z terminami i harmonogramami, włącz to samo, co ty. To zapewnia zdrowsze i bardziej niezawodne środowisko programistyczne.
  3. Nie unikaj pracy zespołowej. Kanban może wydawać się, ale nie jest, modelem opartym na osobach pracujących w izolacji. Praca zespołowa musi być integralną częścią rozwoju oprogramowania Kanban.
  4. Myśl nieszablonowo. Pomyśl o zmianach w przepływie pracy. Wiele zespołów decyduje się teraz na rozwój oparty na testach, w tym rozwój oparty na testach akceptacyjnych, w którym testy akceptacyjne przeprowadzane są najpierw w przypadkach użycia, które następnie określają wymagane funkcje i charakter rozwoju.

Hybrydy

Ponieważ coraz więcej firm korzysta z narzędzi zarządzania projektami najlepiej dostosowanych do ich konkretnej sytuacji, nic dziwnego, że dwie z najlepszych metodologii zarządzania projektami: Scrum i Kanban zostały zintegrowane z dużym sukcesem.

Hybryda, zwana Scrumban, wkracza do wielu projektów.

Jeśli organizacja już korzysta ze Scruma, ale trudno jest utrzymać projekt razem, albo ze sprintami nie działa dobrze, a testowaniem nie jest szczelne, być może czas rozważyć Scrumbana.

Aby to wyjaśnić po prostu, Scrumban polegał na zabraniu szkła powiększającego do sprintu. Nie chodzi tylko o sprinty w ramach projektu, ale o to, co dzieje się w sprintach. Scrumban pomaga spojrzeć, jak historia jest przetwarzana podczas sprintu, i to może mieć znaczenie.

Scrumban lub którykolwiek z jego wariantów jest minimalną zmianą w stosunku do istniejących praktyk. Piękno korzystania z Kanban polega na tym, że można go używać z praktycznie każdym rodzajem modelu zarządzania projektami: wodospadem, zwinnością lub czymkolwiek innym.

Rozpoczęcie pracy z Kanban

Rozpoczęcie pracy z systemem Kanban jest łatwe. Możliwe jest również wdrożenie Kanban w minimalnym stopniu jako próba dla określonej części projektu.

  1. Zaplanuj proces tworzenia oprogramowania. Zrób jasną mapę całego procesu. Jak działa projekt - od wstępnego projektu, przez programowanie, testowanie, zmiany funkcji, w rzeczywistości?
  2. Wymień kroki, w których będzie używany Kanban. Wykonaj kroki, które są całkowicie pod twoją kontrolą. Zazwyczaj obejmuje to fazę analizy, rozwoju, przeglądu i testowania.
  3. Pracuj nad ważnymi punktami, takimi jak:
    1. Ograniczenia prac w toku dla każdego kroku.
    2. Procesy przyspieszonej / zablokowanej pracy
    3. Szacunkowe dane koperty w odniesieniu do czasu cyklu
    4. Częstotliwość przeglądu tablicy / procesu / oceny Kanban
  4. Kup tablicę i stos karteczek samoprzylepnych.
  5. Zaczynaj
  6. Przejrzyj zgodnie z wymaganiami.
  7. Powtarzać

Więc śmiało i zacznij korzystać z Kanban!

Nie bój się, jeśli nie okaże się to tak, jak początkowo zamierzałeś. Cała idea metodologii Agile polega na uwzględnianiu zmian w ludziach i procesach! Poinformuj nas o swoich doświadczeniach z metodą Kanban.

Polecane artykuły

  1. 6 Najlepiej pomocny Office Management Project (PMO)
  2. 8 Przydatnych kroków do stworzenia wyrafinowanych map fabularnych dla twojego projektu
  3. 5 ważnych wartości ekstremalnego programowania (potężne)

Kategoria:

Rozwój przedsiębiorczości