Metodyki zarządzania projektem. Kanban w Jira.

W poniższym artykule omawiam różne metodyki zarządzania projektem ze szczególnym uwzględnieniem właściwej pracy z tablicami Kanban. Skupiam się na możliwościach wykorzystania Jira Software w procesie zarządzania projektem, wykorzystując do tego wirtualne tablice Kanban dostępne w Jira, a także na dobrych praktykach, które powinien wdrażać lider zespołu.

Każdy się orientuje, czym jest projekt. Według książkowej definicji to tymczasowe przedsięwzięcie, które ma na celu stworzenie unikalnej usługi lub produktu w określonym czasie. Projekt ma swój początek i powinien mieć też swój koniec, ale… z tym różnie bywa.  

Tak czy inaczej, powinien być zdefiniowany w czasie. Pamiętajmy, że każdy projekt trwa dokładnie tyle, ile na niego zaplanowaliśmy czasu, plus kilka tygodni więcej. To oczywiście żart, ale zawiera w sobie zawsze odrobinę rzeczywistości.

W związku z powyższym ludzkość szuka najlepszego podejścia do realizacji projektów w zamierzonym czasie i bez bałaganu. Dzięki rozwojowi technologii informatycznej możemy wykorzystać do tego oprogramowanie, które wspiera nas w realizacji naszych przedsięwzięć.  Metodyki zarządzania projektami są różne, tak jak różne są cele, które musimy realizować.

Z oczywistych względów nie będę się skupiał na wszystkich metodach, ale standardowo możemy przyjąć, że najpopularniejsze metodyki zarządzania projektami to Project Management Body of Knowledge (PMBoK), oparty na zbiorze dobrych praktyk związanych z realizacją projektów, PRINCE2, narzędzia związane z CCPM, czyli wyznaczanie ścieżek krytycznych dla projektu oraz metodyki zwinne (Agile w tym Kanban, Scrum)

Pierwszą przywołaną przeze mnie metodyką zarządzania projektem jest  Project Management Body of Knowledge, w skrócie PMBoK, który obecnie uważa się za globalny standard zarządzania projektami.

W myśl tej metodyki projekty dzielą się na etapy, a każdy etap składający się na projekt ma swoje wejście i wyjście. Produkty będące rezultatem na wyjściu jednego etapu projektu, stanowią elementy na wejściu etapu następnego. Poszczególne fazy i ich produkty tworzą cykl egzystencji projektu.

Jest to procesowe podejście do zarządzania projektem, charakterystyczne dla podejścia PMI. Większość modeli cyklu życia, zaprezentowanych w przewodniku PMI, to modele kaskadowe. PMBoK dostarcza wskazówek dotyczących tego, jak między innymi powinny wyglądać procesy definiowania i zatwierdzania nowych projektów w organizacji, ich sposobu realizacji, wykorzystanych środków oraz kolejności realizacji zadań.

Kolejną metodą prowadzenia projektów jest PRINCE2 – Projects In Controlled Environments. Metoda ta nie wyklucza wprawdzie praktych zalecanych PMBoK, ale niespecjalnie je uwzględnia. PRINCE2 cechuje się wysoką standaryzacją i powtarzalnością procesów w realizacji projektów, jest przejrzysta i uporządkowana.

PRINCE2 może być stosowane do wszelkich typów projektów i nie wnika bezpośrednio w charakter prac wykonywanych przez zespół projektowy. Ma jednak też swoje wady związane z dużą ilością tworzonej dokumentacji (z czasem dokumenty mogą stać się celem samym w sobie) czy ciągłymi spotkaniami zespołów, a przede wszystkim z kaskadowym charakterem, bez wsparcia metodyk zwinnych (czytaj więcej Podejście Agile w biznesie).

Celem tej metody jest zapewnienie zasobów na równym poziomie, aby realizacja mogła odbywać się na tym samym poziomie. Podstawą CCPM są relacje pomiędzy poszczególnymi zadaniami. Chodzi o to, że pewnych zadań nie można zacząć przed ukończeniem wcześniejszych newralgicznych dla nich etapów.

Najprościej mówiąc, trudno będzie dekarzowi położyć dachówkę na domu, który nie ma jeszcze więźby dachowej, albo ścian… Co oczywiście nie oznacza, że nie można już zająć się zamówieniem lub produkcją pokrycia dachowego (jeśli ktoś potrafi).

W łańcuchach krytycznych tworzymy sieć powiązań między newralgicznymi etapami. W projektach wyznaczamy kilka ścieżek równoległych wobec siebie, którym nadajemy odpowiednie wartości czasowe (czas realizacji). Najdłuższa ścieżka tworzy jednocześnie łańcuch krytyczny, do którego powinniśmy dostosować poszczególne etapy. Pozostałe ścieżki będą miały „zapas czasu”.

Wyznaczenie ścieżki krytycznej pokazuje nam, na których etapach musimy się skupić, szczególnie gdy chcemy przyspieszyć projekt. Więcej informacji na temat projektów sieciowych można znaleźć w internecie, do czego zachęcam.

Metodyki zwinne (Agile) są niezwykle mocno rozpowszechnione w branży IT, ale mogą wspierać projekty z każdej dziedziny. Zwinne podejście pojawiło się w związku z tym, że ogólnie ujmując, branża IT często dostarcza produkty niematerialne, jakimi są aplikacje mobilne czy oprogramowanie desktopowe.

Ryzyko realizacji takich projektów metodami waterfall (kaskadowe) jest duże. Jak to się kończy widać szczególnie w zamówieniach publicznych związanych z projektami IT. Niestety specyfika zamówień publicznych wymusza hierarchiczne planowanie projektów.

Finał takiej realizacji projektów często nie zadowala żadnej ze stron. Najprościej rzecz ujmując, aby temu zapobiec, poszczególne elementy projektu oddaje się przez przez cały okres trwania projektu, iteracyjnie je doprecyzowując, a sam projekt nie ma ściśle określonych zadań.

Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu i stąd potrzebna ciągłej modyfikacji. Oczywiście wiąże się to z tym, że trudniej zapanować nad wymaganiami klienta, a co za tym idzie obciążeniem zespołów projektowych. Dlatego powołuje się szereg działań, które mają uporządkować pracę, jak choćby funkcja Scrum Masterów w całym procesie iteracji.

Metodyki zwinne dużą wagę przywiązują do bezpośredniej komunikacji między członkami zespołu, minimalizując potrzebę tworzenia dokumentacji, co jest przeciwieństwem opisywanej przeze mnie metodyki PRINCE2. Całość procesu realizacji projektów w zwinnym podejściu przedstawia się symbolem lemniskaty (symbol nieskończoności). Jeśli interesuje cię więcej informacji na temat zarządzania projektami związanymi z tworzeniem oprogramowania i wykorzystania metodyki zwinnej DevOps odsyłam do moich dwóch artykułów: DevOps z Atlassian – efektywne wsparcie procesu tworzenia oprogramowania.

Lemniskata przedstawiająca zwinne podejście w realizacji projektów informatycznych. Źródło: Atlassian.

Praca metodyką Scrum sprowadza się do spiralnej sekwencji działań, które zamykają się w iteracjach zwanych sprintami, które zazwyczaj nie przekraczają jednego miesiąca i zawsze powinny trwać tyle samo. W branży IT Scrum to podstawowa metoda pracy.

W tej metodyce nie przypisuje się odgórnie zadań konkretnym członkom zespołu. Każdy wybiera zadania do realizacji według własnych umiejętności. Realizację działań w sprincie wspierają codzienne spotkania, tzw. Codzienny Scrum (ang. Daily Scrum), na których omawia się zadania, problemy wynikające z ich realizacji oraz bieżące zadania.

Sprinty kończą się Przeglądem Sprintu (ang. Sprint Review), na którym prezentowany jest produkt wykonany podczas przebiegu.

W skład zespołu Scrumowego wchodzą: Właściciel Produktu (ang. Product Owner), Zespół Deweloperski (ang. Development Team) oraz Scrum Master. Zespoły Scrumowe samodzielnie decydują o tym, w jaki sposób wykonują zadania i nie są w żaden sposób kierowane przez kogokolwiek z zewnątrz.

Sprint

W Scrumie Backlog Produktu (ang. Product Backlog) gromadzi listę wymagań użytkownika (klienta), które przeważnie zbierane są w postaci historyjek (ang. User Stories). Każda historyjka opisuje jedną cechę systemu.

Właściciel Produktu przedstawia priorytet tych wymagań oraz główny cel pierwszego sprintu, bo jest jedyną osobą odpowiedzialną za zarządzanie backlogiem produktu (nie musi jednak każdego aspektu zarządzania Backlogiem Produktu wykonywać samodzielnie, może delegować, ponosząc pełną odpowiedzialność).

W czasie Planowania Sprintu szacuje się czas realizacji, pracochłonność, złożoność i ryzyko każdego zadania. Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę Sprint Backlog.

Backlog. Grafika Atlassian. 

Kanban to opracowana w Japonii metoda sterowania produkcją. Metoda ta została zaadaptowana do inżynierii tworzenia oprogramowania ze względu na podobieństwo między procesem produkcji i wytwarzania oprogramowania. Kanban umożliwia sprawowanie pełnej kontroli nad procesem tworzenia oprogramowania i pozwala na wyeliminowanie przyczyn nieefektywności i zwiększenie produktywności.

W przeszłości tablice Kanban miały postać fizycznej planszy z notatkami Post-it lub kart reprezentujących elementy pracy. Możesz jednak skorzystać z wirtualnych tablic Kanban, które znacznie ułatwiają pracę.

Jira Software zawiera kilka gotowych narzędzi, które pomagają uruchomić Kanban w zespole. Korzystając z Jira Software, możemy ustawić tablicę Kanban przy użyciu jednego z domyślnych workflow i natychmiast rozpocząć dodawanie zgłoszeń.

Gdy twój zespół zapozna się z planszą, możesz rozpocząć dostosowywanie projektu, przepływu pracy i typów zagadnień, aby dopasować je do swoich potrzeb.

Kierownicy projektów korzystających z kanbana śledzą pracę na tablicach wyświetlających statusy zadań w kolumnach i torach.

Scrum to metoda, która pomaga właścicielom produktu organizować pracę zespołu, dzieląc ich projekt na zadania, które mają być zakończone w sprincie. Kierownicy projektów mogą z łatwością śledzić postępy i planować każdego dnia w krótkim spotkaniu Daily.

Korzystając z tablic Kanban, można kontrolować ilość nowych zadań i ograniczyć prace w toku, żeby zapewnić lepszy przepływ pracy i szybszą realizację zadań.

Tablica Kanban w Jira Software. W czerwonej ramce system zakreślił nam obszar, w którym zbyt wiele zadań ma ten sam status (WIP limit).

Tablica Kanban wizualizuje, na jakim etapie (tzn. w jakim statusie) są zadania, które wpłynęły do naszego zespołu. Każdy może w dowolnym momencie zobaczyć, gdzie konkretne zadanie znajduje się na tablicy zespołu i jaki ma status.

Zarządzanie przy pomocy tablicy Kanban to po prostu proces zarządzania tym przepływem. Proces ten, aby był wiarygodny, musi zawierać 100% wszystkich zadań zespołu.

Zacznijmy od ewidencji zadań, w której świetnie pomoże nam Jira. W tym celu powinniśmy przenieść do Jira wszystkie zebrane zagadnienia, nad którymi pracuje zespół.

Można tego dokonać w ramach wewnętrznych warsztatów, posługując się fizycznymi planszami jak w przykładzie poniżej:

Następnie całość danych, jaka pojawiła nam się na fizycznych planszach przenosimy do Jira. W tym celu tworzymy w Jira Epic – czyli zbiór zadań, które musimy wykonać w obrębie konkretnego zagadnienia:

Pojedyncze zadanie, które zawiera nasz Epic, na przykład BAU-162, będzie wyglądało tak:

Mając komplet danych o zadaniach i ich przypisaniu do poszczególnych członków zespołu, można będzie następnie przejść do ich wizualizacji na tablicy Kanban. Tablica Kanban zbudowana jest z kolumn, które odpowiadają etapom procesu przepływu zadań. Ten proces pokazuje jakie przystanki mija zadanie w drodze do celu.

Tablica kanban wizualizuje bardzo różne procesy, czasem bardzo złożone i wieloetapowe. Producent oprogramowania Jira proponuje jednak wizualizację maksymalnie 7 kolumn na jednej tablicy.

Dlatego ważne jest, aby szczególnie na początku nie tworzyć własnej wizji procesów, tylko odzwierciedlić w uproszczeniu, jak faktycznie wygląda obecnie przepływ pracy w naszym zespole.

W Jira możesz skonfigurować różne przepływy pracy (ang. workflows) dla różnych typów zgłoszeń lub połączyć wszystkie typy zgłoszeń z ujednoliconym przepływem pracy.

Po zaprojektowaniu poszczególnych statusów nasz zespół powinien mieć świadomość jak ważna jest aktualizacja danych o pracy. Powinniśmy zachęcać nasz zespół, aby regularnie aktualizował statusy zadań w systemie, żeby odpowiadały temu, na jakim etapie znajdują się poszczególne zadania.

Jira Software, który ma bardzo rozbudowane możliwości tworzenia tablic Kanban. Co istotne, w przypadku zespołów rozproszonych i osób pracujących z domu itp. „karteczki” z zadaniami można przesuwać między kolumnami niezależnie od swojej lokalizacji. A to tylko jedna z co najmniej kilkudziesięciu zalet pracy w tym systemie.

Ewidencja zadań w Jira

Zadania przypisywane poszczególnym członkom zespołu powinny być dostarczane przez nas w takiej postaci, aby mogli oni podjąć się dalszej pracy nad zagadnieniem. Nie chodzi o to, aby jak najszybciej przerzucać zadanie na inne pole.

Zarządzanie przy pomocy tablicy Kanban może pomóc w identyfikacji i poradzeniu sobie ze zjawiskiem przerzucania odpowiedzialności, gdy dana osoba w zespole multidyscyplinarnym nie dba o to, czy etap pracy przez nią przygotowany jest zrozumiały lub rzeczywiście ukończony.

W celu uniknięcia problemów związanych z „przerzucaniem zadań przez płot” zorganizuj warsztat kontraktowania pracy. Podczas tego warsztatu osoby z twojego zespołu, które przekazują sobie wyniki swojej pracy np. analitycy do programistów, albo programiści do testerów, powinni ustalić kryteria jakościowe gotowości zadań, które sobie przekazują.

Takie kryteria powinni ustalić sami zainteresowani, a lider niech pełni rolę moderatora dyskusji i wpisuje te ustalenia w standard pracy zespołu.

Te ustalenia wraz z wcześniej ustalonym procesem realizacji zadań stanowią komplet informacji potrzebnych do uruchomienia tablicy Kanban.

Poniżej przykład takich kryteriów w standardowym procesie na podstawie artykułu naszego kolegi Bogdana Górki Fast-Moving Projects #5 – How to deal with the most serious cross-team collaboration challenge

Status = Kryterium przejścia do następnego statusu:

Ostatecznie każdy z członków zespołu wykonujący swoje zadania będzie odpowiedzialnie zmieniać swój status tylko wtedy, gdy będzie w pełni przekonany o spełnieniu kryteriów przekazania wyników swojej pracy następnej osobie.

Jeśli powiążemy zadania z dokumentacją w Confluence (tzn. ze spisaną wiedzą i ustaleniami), takie przekazanie odbędzie się bez konieczności e-maila, spotkania lub telefonu.

Praca zespołu to bieg sztafety, która przekazuje sobie zadania. Jeśli ktoś nie może dostarczyć swojego zadania, nie jest to indywidualną sprawą danej osoby tylko problemem całego zespołu.

Zablokowane zadania można oznaczyć w Kanban. Dotyczy to sytuacji, gdy ktoś nie może zrealizować swojego zadania, ponieważ to, czego potrzebuje do realizacji, nie jest dostępne.

Dzięki wizualizacji na tablicy Kanban członkowie zespołu interesują się całością zadań w toku i przyczynami opóźnień ich realizacji lub blokad. Zwiększa to zaangażowanie zespołu oraz integrację. Wspólnie pracujemy na to, aby dostarczać naszym klientom zamówione produkty lub usługi.

W zespole zarządzanym przez Kanban, najczęściej nie jest konieczne, aby odprawy zespołu były organizowane codziennie, tak jak ma to miejsce w zespole Scrum (tzw. Daily). Warto jednak, żeby odbywały się regularnie zgodnie z intensywnością pracy i potrzebami komunikacyjnymi zespołu np. raz w tygodniu.

Dzięki dostępowi do wspólnej platformy Jira możemy razem dokonać przeglądu tablic Kanbanowych i analizy, jakie zadania są wstrzymane, które są planowane oraz ile zadań skumulowanych jest w poszczególnych statusach.

Metodyk zarządzania projektami jest wiele. Wkrótce (05.12.2018) odbędzie się planowany przez nas webinar na temat zarządzania projektami. Zachęcamy, aby się na niego zapisać.

Podczas tego webinaru poznasz 10 sprawdzonych funkcjonalności na zarządzanie zwykłymi projektami w typowej firmie, niezależnie od branży. Wszelkie informacje na temat webinaru dotyczącego zarządzania projektami znajdziesz na stronie poświęconej temu wydarzeniu: Jira nie tylko dla programistów.

Jeśli już teraz interesują cię dodatkowe informacje dotyczące tego, jak wykorzystać możliwości oprogramowania Atlassian – Jira Software i Confluence w zarządzaniu projektem w oparciu o tablice Kanban zachęcam do bezpośredniego kontaktu ze mną lub poprzez formularz kontaktowy na naszej stronie internetowej.