Agile, Scrum i Kanban: co do cholery naprawdę oznaczają te słowa?

Kiedy programista słyszy wiadomość o „nowym frameworku JavaScript” lub „nowym IDE”, nie musi zadawać więcej pytań, aby wyjaśnić, o co chodzi. Ale jeśli usłyszy o „nowej zwinnej strukturze”, prawdopodobnie przytakuje Homerowi-Simpsonowi, udając, że wie, o co chodzi, ale będzie miał jedno i tylko jedno pytanie: Co u licha robi „zwinne ramy” mieć na myśli?

W nowoczesnym środowisku programistycznym coraz częściej słyszymy słowa „agile”, „scrum” i „kanban” i często są one używane niewłaściwie. W tym artykule postaram się wyjaśnić i doprecyzować niektóre z tych terminów.

Zręczny

Jeśli chcesz być mądralą z tłumu, powinieneś używać słowa „agile” w co drugim zdaniu, gdy mówisz o procesie pracy. Ma dość szeroki zakres, nie zobowiązuje Cię do dużej wiedzy na temat, o którym mówisz, i jest naprawdę fajnym przymiotnikiem lub przysłówkiem: „zwinne myślenie”, „zwinne podejście”, „według zwinnych zasad”. Ale co tak naprawdę oznacza „agile”?

„Zwinny” odnosi się do „zwinnego tworzenia oprogramowania”, podejścia do programowania, które jest zgodne z zasadami zwinnymi. Ale czym u licha są „zasady Agile”? Przyjrzyj się Manifestowi Agile i 12 zasadom agile, które kładą podwaliny pod zwinny rozwój. Z Manifestu:

Zasady zwinne zachęcają do ciągłego dostarczania działającego oprogramowania, ścisłej komunikacji między zespołami i dużej zdolności adaptacji do zmieniających się potrzeb. Jeśli w swojej pracy kierujesz się tymi wartościami i zasadami, możesz powiedzieć, że pracujesz w zwinnym środowisku. Tak więc zwinne tworzenie oprogramowania nie jest metodologią, jest to po prostu zestaw różnych metodologii, ram i technik, które działają zgodnie z tymi samymi zasadami. Można powiedzieć, że „agile” to ramy myślenia i podejmowania decyzji.

Ale dlaczego tak ważne jest przestrzeganie tych zasad w naszej pracy?

Manifest i zasady są wynikiem poszukiwania najlepszych rozwiązań, które ewoluowały przez dziesięciolecia w odpowiedzi na wyzwania rozwoju oprogramowania. W latach 70., 80. i 90. różni programiści i zespoły na całym świecie eksperymentowały z metodami pracy i podejściami do rozwiązywania problemów, wymyślając różne frameworki i techniki (takie jak scrum i Extreme Programming), a nawet dochodząc do tego samego pomysły równolegle. W końcu, w lutym 2001, siedemnastu programistów zebrało się razem i znalazło wspólne mianowniki dla wszystkich tych różnorodnych pomysłów i doświadczeń. Tak powstał manifest.

Scrum

Jeśli mówisz o „zwinnych” metodach, nie wiedząc, co oznaczają, możesz się pomylić i powiedzieć rzeczy, które odkryją cię przed rozmówcą, który zna temat: „Scrum i inne zwinne metodyki”.

Scrum nie jest metodologią, chociaż wszyscy słyszeliśmy, że nazywa się to częściej niż liczba zabójstw w Game of Thrones . Scrum nie udzieli odpowiedzi na każde pytanie i nie zapewni precyzyjnej procedury reagowania na każdą sytuację, z którą się spotykasz. I prawdopodobnie w wyniku tej błędnej interpretacji większość implementacji scrum jest również błędna: Zespoły nie otrzymują wartości. Skutkuje to prawdopodobnie najgłupszym stwierdzeniem o scrumie: „Scrum nie działa”.

Czym jest scrum? Przewodnik po Scrumach definiuje scrum jako:

Jest to więc framework i jak każdy inny framework może być i regularnie jest używany w niewłaściwy sposób. Skuteczne korzystanie ze scrum wymaga nie tylko przyjęcia struktury określonej przez scrum, ale także głębokiego zrozumienia i uznania zasad Agile w całym zespole.

Scrum składa się z następujących ról: Product Owner, Scrum Master, Development Team.

Odbywają się również cztery ceremonie Scrum: Spotkanie Planowania, Codzienny Scrum, Przegląd Sprintu, Retrospektywa Sprintu

Oraz trzy artefakty: Backlog Produktu, Backlog Sprintu, Przyrost Produktu.

Projekty Scrum są zorganizowane w regularne ramy czasowe, które nazywamy sprintami. Zwykle trwają dwa tygodnie.

Właściciel Produktu jest odpowiedzialny za kierowanie projektem. W miarę określania nowych zadań i funkcji właściciel procesu dodaje je do rejestru produktu. Sprint rozpoczyna się od spotkania planistycznego, podczas którego zespół programistów wybiera z backlogu zadania do pracy i planuje sposób ich realizacji. Potem następuje rozwój, podczas którego zespół programistów wykorzystuje backlog do śledzenia postępów i spotyka się na codziennym spotkaniu w celu zsynchronizowania działań i dostosowania planu, jeśli to konieczne. Rezultatem rozwoju powinien być przyrost produktu, coś, co można zastosować do produktu i natychmiast uwolnić. Pod koniec sprintu przyrost produktu jest prezentowany Właścicielowi Produktu podczas przeglądu sprintu, gdzie backlog produktu jest powiększany, jeśli potrzebne są dalsze zmiany. Następnie cały zespół uczestniczy w retrospekcji sprintu, podczas której rozmawia o procesie pracy io tym, jak można go ulepszyć.

Scrum jest łatwy do nauczenia i zrozumienia, ale trudno go zaadoptować. Istnieje wiele powodów, dla których ten framework może, ale nie musi, dobrze pasować do projektu. Często wymaga wielu zmian, nie tylko w codziennym rozwoju, ale także kulturowo. Scrum najlepiej sprawdza się przy tworzeniu produktów złożonych, trwałych długo i angażujących różnego rodzaju specjalistów.

Dlaczego scrum jest tak popularny i dlaczego ma przewagę nad tradycyjnym modelem wodospadu? Mówiąc najprościej, ponieważ zapewnia większą wartość produktowi i klientom. Dzięki „ciężkim” metodom, takim jak wodospad, obfitują opowieści grozy, w których nikt nie widzi nic z projektu przez miesiące. W przypadku Scrum nie jest to możliwe.

Scrum to wartość dostarczana użytkownikom końcowym. Jeśli naprawdę wykorzystujesz scrum, podczas każdego sprintu musisz dostarczać coś wartościowego. Wartość można zmierzyć, a zespół jest również zmuszony do sprawdzania przeszkód i dostosowywania się w celu zapewnienia większej wartości w następnej iteracji.

W większości przypadków tworzenia oprogramowania nie budujemy wieżowca; nie musimy przygotowywać całego planu przed rozpoczęciem i trzymać się go do końca. Tworzymy oprogramowanie i mamy możliwość dostosowania się do różnych sytuacji i zmiany wymagań produktu podczas rozwoju. Przez długi czas wielu programistów postrzegało to jako ósmy grzech śmiertelny, ale z perspektywy produktu jest to ogromna korzyść dla optymalizacji przewidywalności i kontrolowania ryzyka. Scrum jest rozwijany wokół tej umiejętności, a jego wdrożenie daje niezawodny i skuteczny sposób radzenia sobie z niezbędnymi zmianami.

Wiele technik jest używanych w połączeniu ze scrum: planowanie pokera, programowanie w parach, programowanie sterowane testami (TDD), programowanie sterowane zachowaniem (BDD) i inne. Nie są one tak naprawdę częścią scrum, ale raczej kompatybilnymi technikami. Jedną z metod często wymienianych w tym samym czasie co scrum jest kanban i istnieje wiele niejasności co do tego, co te dwie rzeczy oznaczają w odniesieniu do siebie.

Kanban

Kiedy mówisz o scrum i kanbanie, jednym z często zadawanych pytań z tłumu będzie: „Który jest lepszy, scrum czy kanban?” I nie będziesz wiedział, co odpowiedzieć, bo to jak porównywanie jabłek i pomarańczy albo pytanie: „Co jest lepsze, naleśniki czy piwo?” Oba są lepsze.

Kanban to prosta metoda, która ma na celu dostarczenie na czas, jednocześnie nie obciążając członków zespołu. Jest podobny do scrum, ponieważ celem jest dostarczenie maksymalnej wartości na końcu, ale jest znacznie bardziej elastyczny niż scrum.

Kanban nie został wymyślony przez społeczność programistów. W rzeczywistości ma swoje korzenie w procesach produkcyjnych w Toyocie i ma szerokie zastosowanie w innych sferach. Nie ma ścisłych procedur, których powinieneś przestrzegać, ani ścisłego sposobu, w jaki powinieneś wdrażać i używać kanban; jest to raczej zestaw zasad i praktyk, z których możesz wybierać, aby dopasować je do swoich potrzeb. Istnieje jednak najczęściej stosowana implementacja kanban w tworzeniu oprogramowania, która obejmuje użycie tablicy kanban składającej się z kolumn reprezentujących etapy pracy i zadania.

Kolumny przedstawiają stan zadania w procesie rozwoju. Najprostszy przykład składa się z trzech kolumn: „Do zrobienia”, „W toku” i „Gotowe”. Tak więc zadania są dodawane do „Do zrobienia”, przenoszone do „W toku”, gdy rozpoczyna się tworzenie, i uważane za „Gotowe”, gdy są przenoszone do ostatniej kolumny. Ale oczywiście może to być bardziej złożone:

Backlog → Definiowanie specyfikacji → Gotowe do rozwoju → Rozwój → Przegląd kodu → Testowanie → Wdrożone (→ Nikt tak naprawdę go nie używa → Całkowicie usunięty).

Każda kolumna może mieć podkolumny; na przykład „Rozwój” można podzielić na „Planowanie” i „Kodowanie”; „Testowanie” można podzielić na „testowanie jednostkowe” i „testowanie integracyjne” i tak dalej. W razie potrzeby kolumny mogą być dedykowane specjalistom. Zespół definiuje kolumny i etapy zgodnie ze swoimi potrzebami. Zgodnie z filozofią „pull”, zadania powinny wchodzić do obiegu tylko wtedy, gdy zapotrzebowanie na nie jest natychmiastowe.

Celem tej tablicy jest wizualizacja przepływu pracy , która jest pierwszą kluczową praktyką w kanbanie. W rzeczywistości kanban można w ogóle zrobić bez tablicy! Może to być prosta lista zadań w arkuszu Google z różnymi kolorami tła wskazującymi stan zadania lub może to być wykresy Gantta, diagramy, tabele… Może to być nawet zestaw wiader w Twoim biurze, gdzie każdy z nich reprezentuje stan zadania i gdzie piłki są używane jako zadania. Wystarczy zwizualizować przepływ pracy i zapewnić przejrzystość całego procesu.

Inną ważną zasadą jest zmniejszenie wielkości partii swoich wysiłków . W uproszczeniu oznacza to uniknięcie wielozadaniowości. Może to oznaczać zmniejszenie liczby zadań, nad którymi pracujesz w tym samym czasie. Jeśli masz trzech projektantów w zespole, zespół może ustawić maksymalną liczbę zadań w kolumnie „Projektowanie” na trzy.

Podobnie jak scrum, kanban również postrzega zespół jako najważniejszą postać w procesie. Ale nie sugeruje ról, tak jak robi to Scrum, i możesz zachować istniejące role, aby uniknąć wprowadzania zmian w istniejącym procesie. To samo oznacza ciągłe doskonalenie: Kanban ogólnie zachęca do ciągłego uczenia się i doskonalenia, ale nie określa konkretnego wydarzenia tylko dla tego procesu, tak jak Scrum Retrospective Sprint.

Którego powinienem użyć?

Scrum i kanban nie wykluczają się wzajemnie i nie są tak naprawdę porównywalne. W scrum są zdefiniowane role, podczas gdy kanban mówi: „Do diabła, zachowaj swoje obecne role i obowiązki”. Scrum zmusi Cię do zmiany sposobu pracy; kanban pozwala rozpocząć istniejący proces. W scrumie ramy wyznaczają jasny harmonogram wydarzeń; w kanbanie nie masz wydarzeń. Jednak mają wiele podobieństw: obaj są zorientowani na wartości, członkowie zespołu są szanowani jako „szefowie” systemu i zasadniczo mają tę samą misję: ciągłe eliminowanie marnotrawstwa i usuwanie przeszkód.

Ale pytanie: „Czego powinienem użyć w moim konkretnym projekcie i w moim konkretnym zespole?” ma o wiele więcej sensu. Kanban nie wymaga tak dużego procesu i zmian kulturowych, aw większości przypadków będzie łatwiejszy do przyjęcia niż scrum. Z drugiej strony Scrum oferuje znacznie więcej struktury do kierowania procesem, co może wyeliminować wiele kosztów ogólnych, o ile wszyscy są na tej samej stronie.

Ale piękno obu jest takie, że żaden z nich nie jest ścisłym zestawem zasad. Nic nie stoi na przeszkodzie, aby wybrać najlepsze dla siebie elementy scrum, takie jak codzienne spotkanie czy przegląd. I nie ma powodu, dla którego nie można włączyć tablicy kanban do scrum.

Scrum okazał się bardzo skutecznym frameworkiem, gdy cały zespół dobrze go rozumie. Jednak z mojego doświadczenia wynika, że ​​trudno mi pracować w scrum z niektórymi klientami. Procesów i zmian kulturowych wymaganych do prawidłowego wdrożenia scrum może być zbyt wiele (zwłaszcza w przypadku kogoś, kto uważa, że ​​tworzy nowe Google!). Z drugiej strony kanban jest bardziej elastyczny i nie zmusza ludzi do zmian. Niektórzy autorzy twierdzą również, że kanban jest dobrą drogą do zwinności i oferuje łatwiejszą implementację scrum. Inni twierdzą, że użycie scrum powinno prowadzić na końcu do kanbanu.

Prawda jest taka, że ​​każdy projekt jest inny i nie ma jednego uniwersalnego rozwiązania. Jako kierownik projektu to Ty decydujesz, co najlepiej sprawdza się w Twoim zespole.