Scrum i Kanban: wyjaśnienie dwóch potężnych metodologii Agile

Więc masz zamiar zarządzać złożonym projektem? Do wykonania jest cała masa pracy, ale nie panikuj! Jako kierownik projektu będziesz odpowiedzialny za planowanie, monitorowanie, zarządzanie budżetem, wykonanie, weryfikację jakości i terminowe wydanie finalnego projektu. Na szczęście istnieje wiele metodologii zarządzania projektami, które mogą sprawić, że Twoja (i Twojemu zespołowi) praca będzie łatwiejsza i bardziej wydajna!

W tym artykule chciałbym skoncentrować się na dwóch najpopularniejszych metodologiach Agile – Scrum i Kanban – które szturmem podbiły świat tworzenia oprogramowania w ostatnich latach. W dzisiejszych czasach trudno znaleźć software house, który nie zaadoptuje tych dwóch frameworków do zarządzania projektami. O co w nich chodzi? Czytaj dalej i dowiedz się wszystkiego, co musisz wiedzieć o Scrumie i Kanbanie!

Czym dokładnie jest metodyka Agile w zarządzaniu projektami?

Dziś firmy nie pracują już nad pojedynczym projektem bez testowania go na wszystkich etapach procesu rozwoju. To się po prostu nie opłaca! Dlaczego nie?

Wyobraź sobie: cały Twój zespół pracuje przez kilka miesięcy, powiedzmy, nad tworzeniem aplikacji mobilnej, którą testujesz i oceniasz dopiero na samym końcu, gdy cała praca Twoich backendowych i frontendowych developerów, designerów i copywriterów jest już zakończona. Co jeśli tylko wtedy zdasz sobie sprawę, że Twój produkt nie odpowiada już na wymagania rynku i potrzeby użytkowników? Trzeba by wtedy wprowadzać kolejne iteracje całego projektu, co pochłania dużo czasu, pieniędzy i energii.

Metodologia Agile jest więc świetnym rozwiązaniem, które znacząco usprawnia przepływ pracy i łatwe wprowadzanie zmian na każdym etapie. Kluczową zasadą Agile jest rozbicie jednego „dużego” i złożonego projektu na kilka mniejszych elementów (lub funkcji) i publikowanie ich jeden po drugim. W tym przypadku zarówno rozwój, jak i testowanie to dwie równoległe czynności, co ułatwia ciągłą walidację projektu i wprowadzanie wszystkich niezbędnych ulepszeń.

Co ciekawe, o ile przez wiele lat Agile dominowało w firmach IT i tworzących oprogramowanie, to metodologia ta okazała się na tyle skuteczna, że ​​jest obecnie wykorzystywana w wielu innych dziedzinach, takich jak marketing, sprzedaż, HR czy operacje. Według raportu State of Agile przygotowanego przez Verison One, w 2020 roku 95% firm technologicznych i software house’ów ćwiczyło różne metody Agile.

Scrum framework: dlaczego jest taki niesamowity?

Wiele osób ma tendencję do mieszania dwóch pojęć, które choć wydają się być dość podobne, nie są równoznaczne – są to Agile i Scrum. W skrócie, Agile to termin zbiorczy, który wskazuje na wszystkie metody i podejścia określone w Manifeście Agile , podczas gdy Scrum jest w rzeczywistości jedną z tych metod. To takie proste!

Co to jest Scrum i kiedy można go stosować?

Scrum to framework do zarządzania projektami, stosowany głównie do budowania złożonych produktów, których proces rozwoju trwa co najmniej kilka miesięcy. Opiera się ona przede wszystkim na przejrzystości, bieżącej komunikacji pomiędzy wszystkimi członkami zespołu oraz zbiorowej odpowiedzialności. Taka strategia ułatwia dostarczenie ostatecznej wersji projektu, która odpowiada potrzebom grupy docelowej i odpowiada na bieżące potrzeby rynku.

Chociaż Scrum stał się wiodącym frameworkiem, szczególnie w ostatnich latach, w rzeczywistości nie jest to nic nowego. Wróćmy do 1986 roku, kiedy Harvard Business Review opublikował artykuł The New Product Development Game . Tam autorzy opisali podejście do zarządzania stosowane przez firmy takie jak Honda czy Canon, które doprowadziło do ich sukcesu. Następnie, w 1993 roku, te koncepcje zainspirowały Jeffa Sutherlanda i zespół Easel Corporation do ustanowienia procesu zespołowego zwanego Scrum.

Role i obowiązki w zespole Scrumowym

W zespole Scrumowym wszystkie role są jasno określone od samego początku i zazwyczaj nie zmieniają się w trakcie całego projektu. Z reguły ten framework ma 3 podstawowe role: Product Owner, Scrum Master i Development Team.

Mistrz Scrum

Scrum Master to rodzaj (ale nie do końca) team leadera, który dba o to, aby wszystko odbywało się we właściwy sposób, a proces tworzenia przebiegał sprawnie. Główne obowiązki Scrum Mastera to:

• coaching członków zespołu, aby wszyscy pracowali wydajniej, aby dostarczać nowe funkcje produktu cyfrowego
• planowanie wszystkich zadań na kolejne sprinty (poniżej opowiem więcej o sprintach w Scrumie) oraz prowadzenie backlogu produktu
• edukowanie interesariuszy i wszystkich członków zespołu o znaczeniu zasad Scrum w zarządzaniu projektami,
• ocena, czy wszystkie zadania są realizowane zgodnie z planem
• próba wyeliminowania wszelkich przeszkód, które utrudniają realizację zadań w danym sprincie.

Niezwykle ważne jest, aby Scrum Master zawsze ściśle współpracował z Właścicielem Produktu . Wspólnie planują kolejne sprinty, oceniają jakość wykonanych zadań, wyznaczają kierunek dla zespołu i ustalają, czy projekt wymaga wprowadzenia zmian. Mówiąc najprościej, Scrum Master dokłada wszelkich starań, aby pomóc zespołowi programistycznemu odnieść sukces i dostarczyć wszystkie funkcje na czas.

Właściciel Produktu

Właściciel produktu jest odpowiedzialny za dostarczenie ostatecznej wersji produktu, która może generować rzeczywiste zyski biznesowe. Dlatego w całym zespole Scrumowym to Product Owner wyznacza priorytety i odgrywa najbardziej decydującą rolę . Co ważne, backlogiem produktu zarządza Product Owner, który określa, które cechy produktu powinny być rozwijane w pierwszej kolejności, ponieważ mają one największą wartość biznesową.

Oto główne obowiązki Właściciela Produktu:

• zarządzanie backlogiem produktu
• kontaktowanie się z interesariuszami
• określenie głównego celu każdego sprintu
• planowanie wydania nowych funkcji
• ocena pracy Zespołu Deweloperskiego i odwoływanie sprintu w razie potrzeby

Zespół programistów

Bez Zespołu Deweloperskiego Scrum nie byłby możliwy, ponieważ to oni wykonują rzeczywistą pracę i wykonują wszystkie zadania zaplanowane na poszczególne sprinty.

Zazwyczaj Zespół Deweloperski składa się z osób posiadających wiedzę w określonej dziedzinie , takiej jak iOS, uczenie maszynowe, backend czy frontend development. Wszyscy łączą siły, aby zapewnić wysokiej jakości funkcje produktu cyfrowego. Należy jednak pamiętać, że chociaż termin „zespół deweloperski” zwykle odnosi się do inżynierów, nie zawsze jest to trafne. Marketerzy, projektanci, analitycy, testerzy, copywriterzy czy specjaliści ds. sprzedaży również mogą wnieść pewną wartość i być częścią zespołu Scrum.

Jedną z rzeczy do rozważenia przy budowaniu zespołu deweloperskiego jest liczba jego członków. Nawet tutaj Scrum określa kilka podstawowych zasad! Mówi się, że taki zespół musi składać się z 3 do 9 osób i powinien posiadać umiejętności wymagane do dostarczenia wszystkich funkcji. Oczywiście wszystko zależy od złożoności projektu i potrzeb klienta; czasami 4 lub 5 programistów wystarcza w zupełności do zbudowania produktu cyfrowego.

Ale jaka dokładnie jest rola Zespołu Deweloperskiego w Scrumie? Zasadniczo powinien:

• zbuduj wszystkie cechy produktu zgodnie z instrukcjami Właściciela Produktu
• określić ile przedmiotów zbudować w danym sprincie
• sprawnie zarządzaj nakładem pracy, aby wszystkie zadania zostały ukończone do końca sprintu
• podejmować wszystkie istotne decyzje wspólnie
• mieć postawę „my” – zespół podejmuje wszystkie decyzje, wspólnie rozwiązuje problemy, a każda osoba czuje się odpowiedzialna za innych współpracowników

Proces tworzenia Scrum w pigułce

Wiesz już, czym jest Scrum i kto tworzy zespół Scrumowy, więc teraz nadszedł czas, aby zrozumieć, jak wygląda proces rozwoju w tej metodologii i jak zrobić to dobrze.

W procesie Scrum każdy krok się liczy i przynosi realną wartość Twojemu zespołowi. Oto główne etapy, których nie należy pomijać:

1. Backlog produktu : lista wszystkich elementów, które należy zbudować w kolejnych sprintach. Jest zarządzany przez Product Ownera wraz ze Scrum Masterem, który dokładnie wie, kiedy każda funkcja lub element powinien zostać wydany.
2. Spotkanie planowania sprintu : Głównym celem tego spotkania jest określenie, co każdy członek Zespołu Deweloperskiego zrobi w następnym sprincie. Jest zawsze organizowany przed rozpoczęciem sprintu, aby każdy mógł ocenić, czy jest w stanie wykonać wszystkie zadania przed terminem. Upewnij się, że każdy członek zespołu w pełni rozumie główny cel sprintu.
3. Backlog Sprintu : Są to wybrane zadania zaczerpnięte z Backlogu Produktu, które zespół wybrał do wykonania w danym Sprincie.
4. Sprint : Tutaj dzieje się cała magia. Sprint to krótki okres, który zwykle trwa 1-4 tygodnie, kiedy Zespół Deweloperski pracuje nad wykonaniem wszystkich zadań przydzielonych podczas Wiosennego Spotkania Planującego.
5. Codzienny Scrum (zwany też Standupem ): Extra krótkie spotkania odbywające się codziennie o tej samej porze, podczas których każdy w 1-2 zdaniach raportuje swoje postępy w pracy: rozmawiają o tym, co zostało zakończone, a co jeszcze do zrobienia.
6. Przegląd sprintu: po zakończeniu sprintu każdy ma szansę zaprezentować swoje osiągnięcia innym członkom zespołu, a nawet interesariuszom, którzy dość często uczestniczą w przeglądach sprintów.
7. Retrospektywa Sprintu : Teraz nadszedł czas na ostatnie spotkanie, które kończy cały cykl Sprintu. Jeśli któryś z członków zespołu ma jakieś sugestie lub pomysły dotyczące tego, co można poprawić w kolejnym sprintu, może to zrobić podczas spotkania Retrospektywy Sprintu.

W przypadku procesu Scrum konieczne jest upewnienie się, że każdy cykl Scrum ma taką samą strukturę : zaczyna się od Spotkania Planującego Sprint, następnie wszyscy przystępują do pracy i wykonują zadania wyznaczone dla sprintu, a na samym końcu każdy członek zespołu pokazuje co osiągnęli.

Jest jeszcze jedna rzecz, o której chcę, żebyś pamiętał: Scrum ma bardzo ścisłą filozofię zmiany. Co to oznacza w praktyce? Członkowie zespołu Scrum nie powinni zmieniać zadań ani głównych celów podczas sprintu. Jeśli nie uda im się osiągnąć zaplanowanych wyników, powinno to być lekcją na przyszłość, aby lepiej oszacować czas potrzebny na ukończenie elementów.

Kilka słów o Kanbanie

Teraz, gdy nauczyłeś się, czym jest Scrum i jak zbudować z nim produkt cyfrowy, nadszedł czas, aby skupić się nieco bardziej na drugiej metodologii Agile. Jestem pewien, że już to znasz – nawet jeśli jeszcze nie zdajesz sobie z tego sprawy!

Co to jest Kanban i kiedy można go zastosować?

Termin Kanban pochodzi z języka japońskiego i można go po prostu przetłumaczyć jako „sygnał wizualny”. O to w zasadzie chodzi w tej metodologii. W Kanbanie każdy element ma swoją wizualną reprezentację – kartę, którą członkowie zespołu umieszczają na tablicach i zmieniają jej status (np. „do zrobienia”, „robi” lub „zrobione”).

Takie podejście może być z łatwością zastosowane w każdej branży, ale najczęściej wybierane jest przez zespoły programistyczne zaangażowane w złożone i czasochłonne projekty. I nie bez powodu – Kanban ułatwia komunikację w czasie rzeczywistym i sprawia, że ​​praca wszystkich członków zespołu jest w pełni przejrzysta.

Co ciekawe, Kanban jest w rzeczywistości znacznie starszą metodologią niż Scrum. Jej początki sięgają lat 40. XX wieku, kiedy Toyota wprowadziła w swoich fabrykach system oddzielnych kartek umieszczanych na białych tablicach, które pracownicy mogli w każdej chwili zmienić. W rezultacie ta strategia znacznie usprawniła ich pracę i przyspieszyła komunikację między zespołami.

Kto jest kim w zespole Kanban?

Omawiając Scrum dokładnie opisałem role, obowiązki i kompetencje każdego członka zespołu (Scrum Master, Product Owner i developerzy). Tutaj sprawy mają się zupełnie inaczej. Kanban nie definiuje, kto ma większą władzę lub obowiązki, ponieważ praktycznie wszyscy członkowie zespołu są równi i wspólnie łączą siły i umiejętności.

Co więcej, Kanban nie określa, ile osób może pracować razem nad projektem, więc dowolna struktura zespołu jest akceptowalna. Jeśli jednak chcesz poprawić przepływ pracy, możesz rozważyć zbudowanie zespołu między programami. Dzięki temu rozwiązaniu członkowie zespołu z różnych obszarów wiedzy mogą dzielić się swoją wiedzą i udzielać informacji zwrotnej na każdym etapie rozwoju produktu. W ten sposób w ogóle nie będzie potrzeby konsultowania się z innymi zespołami!

Czym jest tablica Kanban i jak ją stworzyć?

Tablica Kanban jest sercem i duszą tej metodologii. To narzędzie do zarządzania projektami stworzone w celu wizualizacji postępu każdego zadania w czasie rzeczywistym. Jeśli zastanawiasz się, czy twoi koledzy z drużyny rozpoczęli już pracę nad ważną funkcją, a może już ją skończyli, po prostu sprawdź tablicę i już wiesz!

Ten przykład pokazuje dokładnie, czym jest Kanban i jak działa wizualizacja:

Ogólna koncepcja tablic Kanban jest więc dość prosta: masz kilka oznaczonych kolumn i na każdej z nich umieszczasz karty wizualne. Mogą to być lepki lub bilety. Na każdej z tych kart zapisujesz nazwę projektu, w który jesteś obecnie zaangażowany, lub konkretny przedmiot pracy, który budujesz. Następnie wystarczy przydzielić konkretną kartę do określonej kolumny, aby reszta zespołu była zaktualizowana i dokładnie wiedziała, nad czym teraz pracujesz.

Powyższy przykład pokazuje typowe kategorie kolumn, którymi są:

• 'do zrobienia'
• 'w trakcie'
• „testowanie”
• 'Gotowe'

Pamiętaj jednak, że możesz szerzej opisać swój przepływ pracy i dodać dodatkowe kolumny – ich wybór będzie zależał od projektu, którym zarządzasz.

Jeśli chcesz, aby Twój zespół odniósł sukces, jest jeszcze jedna rzecz, o której musisz wiedzieć – powinieneś zdefiniować limity dla elementów, nad którymi Twój zespół może pracować w tym samym czasie. Dlatego Kanban dodatkowo zaleca ustawienie limitów pracy w toku (WIT) . Jak to zastosować w praktyce? Musisz określić, ile kart może jednocześnie znajdować się w kolumnie (np. „W toku”). Jeśli twoja drużyna osiągnie ten limit, po prostu nie może dodać więcej kart. Wyznaczenie tych granic jest zawsze świetnym rozwiązaniem na przeciążenie pracą.

Scrum vs. Kanban: który framework wygrywa tę bitwę?

Cóż, odpowiedź na to pytanie nie jest wcale taka prosta. Te dwie strategie Agile mają podobne zasady, ale stosowane przez nie praktyki to dwie zupełnie różne rzeczy. Podczas gdy Kanban jest bardziej płynny i sprzyja ciągłym zmianom i regularnym informacjom zwrotnym, Scrum jest znacznie bardziej rygorystyczny i zorganizowany.

Gotowy na następny projekt oprogramowania?

Popracujmy razem

Oto główne różnice między tymi dwoma strukturami zarządzania projektami:

Który z tych frameworków Agile wybierzesz do zarządzania swoimi projektami? A może chciałbyś, aby zrobili to za Ciebie eksperci? Zapraszamy do kontaktu – wprowadzając różne metodyki Agile, dostarczyliśmy ponad 150 gotowych do użycia, udanych produktów!