Jak sprawnie zarządzać tworzeniem nowego oprogramowania lub produktów? Wybierz odpowiednie dla siebie zwinne, aktywne podejście umożliwiające szybką reakcję i zmianę kierunku rozwoju w dowolnym momencie trwania projektu. Poczuj jego przewagę nad tradycyjną metodologią, zakładającą przestrzeganie harmonogramu i z góry ustalonego zakresu prac oraz kosztów.
Poznaj Kanban i Scrum – dwa style zarządzania rozwojem oprogramowania i innymi projektami, które sprawdzają się w określonych środowiskach firm.
Scrum skupia się na dostarczaniu ciągle udoskonalanego produktu, Kanban – koncentruje się na wykonywaniu jednego konkretnego zadania w danym czasie, które ma znany cel, by utrzymywać równowagę pomiędzy ilością zadań, co przynosi wymierną wartość oraz zapewnia płynność pracy. Oba podejścia działają motywująco na członków zespołu i są ukierunkowane na poprawę efektywności oraz pozwalają na odkrycie wyzwań czy zależności na wczesnym etapie pracy.
Cele w Kanban i Scrum
Kanban – cele
- Dążenie do tego, żeby na raz wykonywać jedno konkretne zadanie, którego cel jest znany i przynosi wymierną wartość
- Identyfikacja oraz usuwanie blokerów i wąskich gardeł
- Szybka reakcja na zmiany w dowolnym momencie
- Lepszy wgląd w przepływ pracy
Scrum – cele
- Dostarczanie działających funkcjonalności w krótkich okresach
- Ciągłe rozwijanie i ulepszanie produktu
- Elastyczne reagowanie na zmiany w ramach danego cyklu
- Inspekcja i usprawnianie procesów
Co to jest Kanban?
Kanban (z japońskiego Kàn, „znak” i Bǎn, „tablica”), to zwinna metodyka pozwalająca zapanować nad chaosem i wyłowić to, co istotne. Kanban powstał już w latach pięćdziesiątych w japońskich fabrykach Toyoty, aby w wizualny sposób zarządzać przepływem procesu.
Managerowie zarządzający projektami i zespołami we współczesnych firmach tworzących oprogramowanie często stosują Kanban, ponieważ dzięki niemu już na pierwszy rzut oka mogą się zorientować, na jakim etapie znajduje się proces, jakie zadania są aktualnie wykonywane i gdzie potrzebne są modyfikacje, aby usprawnić rozwój oprogramowania. Ideą Kanban jest zapewnienie stabilnego przepływu działań w całym procesie i uniknięcie zawirowań.
Kolejność wykonywania zadań w Kanban
Zamiast rozpoczynać kolejne zadania i przeskakiwać między różnymi aktywnościami, zespół najpierw zamyka jedno zadanie, a następnie zaczyna pracę nad następnym, tak aby zminimalizować ilość zadań o statusie „w toku”.
Wizualizacja zadań w Kanban
Kanban wykorzystuje potencjał wizualizacji. Na tablicy Kanban można przedstawić wszystkie zadania ze statusami prac (zaplanowane, w toku, zrobione) oraz śledzić przepływ pracy. Zyskujemy też bieżący wgląd w zadania, nad którymi aktualnie pracują inni członkowie zespołu.
Tablica Kanban służy do zarządzania całością zleceń związanych z danym projektem, a nie dzielenia ich na partie. Dzięki temu zespół nie musi szacować czasu ich realizacji. Umożliwia natomiast podzielenie całości pracy na konkretne zadania, np. ostatnio dodanego zlecenia, z ustaleniem dla niego ograniczenia czasowego. W ten sposób można kontrolować obciążenie zespołu pracą w danym czasie i jej przepływ.
Kiedy wykorzystać Kanban?
Kanban sprawdza się w małych zespołach, które pracują nad projektami przebiegającymi dynamicznie i gdy zespół musi działać bardzo elastycznie. Przykładem może być tzw. Support team, który odpowiada na bieżące potrzeby swoich klientów. Jeżeli w projektach zdarzają się przestoje i spadki efektywności, tablice Kanbana pomogą namierzyć i usunąć blokery oraz usprawnić pracę, w co angażuje się cały zespół.
Stosuj Kanbana gdy:
- trudno wskazać konkretny produkt
- nie da się przewidzieć, ilu klientów i z jakimi zapytaniami się zwróci
- praca nie wymaga zespołu, który współdziała ze sobą, bo zadania można wykonywać indywidualnie pod okiem osoby dbającej o właściwy przepływ pracy
- każdy z członków zespołu jest świadomy zasad, reguł procesu i wytycznych tej metody
- zmiana może się zadziać w każdym momencie
Co to jest Scrum?
Scrum to uproszczone ramy postępowania, które pomagają zapanować nad złożonością procesów, jaka pojawia się przy rozwoju produktu. Scrum najlepiej sprawdza się pracy nad skomplikowanymi problemami, gdzie nie do końca da się przewidzieć zakres czynności i trudno zrobić plan realizacji na początku projektu. Dlatego Scrum zakłada ciągłą inspekcję i adaptację w krótkich przedziałach czasu.
Scrum opiera się na iteracji – powtarzalności sprintów (określonych przedziałów czasu) i wytwarzanym przez zespół przyroście (increment) – systematycznym rozbudowywaniu poprzednich efektów pracy oraz weryfikacji, czy wszystkie poprzednie przyrosty są do siebie dopasowane.
Zespół w Scrum
W Scrumie podstawową komórką jest mały zespół, w skład którego wchodzą product Owner, Scrum Master i deweloperzy. Zespół scrumowy nie dzieli się na podzespoły i nie obowiązuje w nim hierarchia – każdy z jego członków jest w takim samym stopniu odpowiedzialny za pracę całego zespołu. Deweloperzy to nie tylko programiści, ale również inni specjaliści, których obecność jest niezbędna do ukończenia zaplanowanej pracy, np. UX designer, analityk biznesowy, etc.
Doświadczenie podpowiada, że zespół scrumowy nie powinien przekraczać 10 osób – tylko wtedy osiągana jest najlepsza zwinność pracy, budowana lepsza komunikacja i synergia. Jeśli zespół jest liczniejszy, warto podzielić go na dwa mniejsze – z tym samym product Ownerem, backlogiem i celem produktu.
Zespoły scrumowe same decydują, kto, kiedy i jak będzie wykonywać określoną pracę i są odpowiedzialne za tworzony podczas każdego sprintu użyteczny increment (przyrost), którym najczęściej jest działający element aplikacji.
Deweloperzy
To osoby zobowiązane do wytworzenia każdego aspektu użytecznego incrementu podczas sprintu. Deweloperzy są odpowiedzialni między innymi za stworzenie backlogu sprintu, zapewnienie jakości zgodne z definition of ready, a także wzajemne wspieranie się, pomoc i egzekwowanie odpowiedzialności za pracę.
Product Owner
Jest odpowiedzialny za maksymalizację wartości produktu, nad jakim pracuje zespół scrumowy. Product Owner nie jest i nie może być przełożonym lub managerem zespołu. To członek zespołu scrumowego o równorzędnych prawach i obowiązkach. Monitoruje konkurencję, ustala priorytety, tworzy nowe elementy (zadania) backlogu, objaśnia je i precyzuje.
Scrum Master
Odpowiada za efektywność pracy zespołu scrumowego oraz za to, aby Scrum był stosowany zgodnie z zasadami.
Scrum Master wspiera zespół między innymi poprzez:
- Usuwanie blokerów i przeszkód napotykanych przez zespół.
- Upewnienie się, że spotkania scrumowe odbywają się, zespół zna ich cel.
- Pomaganie w przebiegu spotkań i facylitacji.
Scrum Master pomaga Product Ownerowi między innymi poprzez:
- Znajdowanie sposobów efektywnego zarządzania backlogiem.
- Zrozumienie i wprowadzenie empirycznego podejścia do pracy w środowisku zwinnym.
- Współpracę z interesariuszami, w sytuacji, gdy zachodzi taka potrzeba lub jest o to poproszony.
Wydarzenia w Scrumie
Scrum zawiera w sobie kilka określonych wydarzeń (spotkań) – sprint, planowanie sprintu, daily scrum, retrospektywa sprintu. Celem wydarzeń jest stworzenie przejrzystego środowiska pracy, możliwość inspekcji i wprowadzenia adaptacji.
Sprint (iteracja)
Każdy sprint można uznać za osobny projekt, na którego końcu przedstawia się wyniki prac, jakie udało się wykonać. Cykle, czyli sprinty są jak klocki Lego, gdzie każdy kolejny przyczynia się do osiągnięcia celu produktu, czyli np. zbudowania użytecznego elementu aplikacji internetowej.
Iteracje stosuje się po to, żeby pomyłki mało kosztowały. Nam ludziom wydaje się, że siebie rozumiemy, ale to nie jest zawsze prawda. Dlatego przynajmniej raz na iterację weryfikujemy z osobami spoza zespołu (użytkownikami, interesariuszami, itp.) kierunek rozwoju produktu. Celem tego spotkania (sprint review) nie jest wyłącznie pokazanie tego, co udało się zrobić, albo rozliczenie z dostarczonych funkcjonalności, ale zweryfikowane tego, czy produkt jest rozwijany w odpowiednim kierunku i dostosowanie planu na następne iteracje.
Sprint planning
Jest pierwszym spotkaniem sprintu, podczas którego cały zespół ustala i decyduje, co będzie do wykonania w nadchodzącym sprincie.
Daily scrum
Krótkie codzienne spotkanie dla deweloperów. W jego trakcie członkowie zespołu pokazują postępy w realizacji celu sprintu, a także tworzą plan na nadchodzący dzień pracy.
Sprint review
Spotkanie, na którym zespół scrumowy przedstawia interesariuszom efekty pracy wykonanej podczas ostatniego sprintu, a także omawia przyszłe zmiany.
Sprint retrospective
Ostatnie wydarzenie w sprincie, którego celem jest podniesienie jakości, efektywności i organizacja lepszej współpracy zespołu deweloperskiego podczas sprintu. Retrospektywa sprintu skupia się na procesach i interakcjach, na tym, jak przebiegały, na poprawie ich korelacji i funkcjonowania.
Definition of ready i definition of done
Podczas pracy w zwinnych frameworkach możemy się spotkać ze zwrotami „definition of ready” (definicja gotowości) i „definition of done” (definicja ukończenia). Są to bardzo pomocne elementy i dobre praktyki. Jasno określają (mierzą), czy jesteśmy gotowi na uwzględnienie zadania w backlogu sprintu oraz czy zadanie spełnia wszystkie ustalone i wymagane kryteria potrzebne do stwierdzenia, że dane zadanie jest ukończone.
Definiton of ready (przykłady):
- Zadanie jest właściwie opisane (posiada cel, zakres, kryteria ukończenia).
- Zadanie jest zrozumiałe dla wszystkich członków zespołu.
- Zadanie jest oszacowane i jest na tyle małe, że zespół jest w stanie ukończyć je w ramach jednej iteracji (np. dwutygodniowego sprintu).
- Zadanie nie ma otwartych i znanych zależności względem innych zadań.
Definition of done (przykłady):
- Kod został stworzony w oparciu o wytyczne technologiczne i wewnętrzne wytyczne projektu.
- Zostały stworzone testy jednostkowe, wyniki tych testów są pozytywne.
- Kod został sprawdzony przez inną osobę niż autor (code review).
- Kryteria akceptacji zostały spełnione.
- Funkcjonalność jest już przetestowana i wyniki testów są już udokumentowane.
- Nowo stworzona funkcjonalność nie zawiera otwartych błędów.
Backlog produktu
To zbiór wszystkich zadań, nad którymi zespół lub kilka zespołów pracuje równocześnie. Ma formę uporządkowanej według priorytetów listy, która określa, co należy wykonać, aby otrzymać produkt. Każde zadanie w backlogu spełnia określoną rolę i ma na celu realizację wymagań klienta (user story), zadania techniczne, defekty, etc.
Osobą odpowiedzialną za backlog produktu jest Product Owner – to właśnie on przekłada wymagania klienta na pojedyncze zadania i określa priorytety. Pozostałe osoby z zespołu również mają dostęp do backlogu produktu, mogą wspierać i również opracowywać zadania.
Kiedy wykorzystać Scrum?
Scrum sprawdza się w zespołach projektowych, które liczą nie więcej niż 10 osób i zajmują się wytwarzaniem produktu lub dostarczają usługi. Ponieważ scrum zakłada ciągłe udoskonalanie rozwijanego produktu, np. oprogramowania, ta metodyka działa najlepiej, gdy członkowie zespołu szukają sposobu na poprawę jakości dostarczanego rozwiązania, a specyfikacja jest znana i dostarczana przez biznes (Product Owner). Sprawdzi się również w zespołach, którym zależy na ciągłości komunikacji, co ułatwiają spotkania scrumowe.
Kanban a Scrum – porównanie
Projekty rozwijające oprogramowanie muszą przebiegać dynamicznie, a dzięki możliwościom, jakie dają frameworki Scrum i Kanban, zespół deweloperski może działać efektywniej.
Osiągaj więcej dołączając do #Edge1Team! Sprawdź nasze oferty pracy i aplikuj!
