Plan zarządzania projektami, część 1: Kompleksowe porównanie Agile, Scrum, Kanban i Lean

Przegląd

W dzisiejszym tworzeniu oprogramowania stosuje się wiele metodologii. Być może słyszałeś modne hasła, takie jak Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming itp.

W tym artykule zdefiniuję te terminy, omówię, jak są ze sobą powiązane i czym się od siebie różnią. Wiele z wyżej wymienionych haseł opiera się na koncepcjach Lean Manufacturing, które pierwotnie opierały się na Toyota Manufacturing System (TPS), więc porozmawiamy o tym najpierw.

Metodyka Lean

Początki Lean i Lean Manufacturing

Termin „Lean” ma swoje korzenie w produkcji, gdzie został ukuty w celu opisania modelu produkcyjnego opartego na systemie produkcyjnym Toyoty (TPS) pierwotnie opracowanym przez Sakichi Toyodę, Kiichiro Toyodę i Taiichi Ohno, których inspiracją był Henry Ford. TPS koncentrował się na filozofii „całkowitej eliminacji wszelkich odpadów” i zrewolucjonizował produkcję w latach 50-tych i 70-tych. TPS stało się znane jako „Lean Manufacturing” w 1990 roku, kiedy opublikowano „Maszynę, która zmieniła świat”.

TPS zidentyfikował trzy główne rodzaje odpadów w Toyocie:

• Muda: tłumaczone jako „odpady”. W Toyocie zidentyfikowano siedem rodzajów mudy, a później dodano ósmy. To są:
  • Defekty: wysiłek związany ze znalezieniem i naprawą defektów
  • Nadprodukcja: produkcja wyprzedzająca popyt
  • Oczekiwanie: oczekiwanie na kolejny etap produkcji, przerwy itp.
  • Niewykorzystany talent: niewykorzystane możliwości, nieodpowiednie szkolenie itp.
  • Transport: ruchome części lub produkty, które nie są wymagane do przetwarzania
  • Zapasy: zapasy gotowe i produkcja w toku
  • Ruch: poruszanie się lub chodzenie więcej niż jest to potrzebne do przetwarzania

  • Nadmierne przetwarzanie: z powodu złego oprzyrządowania lub projektu produktu

• Muri: przetłumaczone jako „przeciążenie”. Muri zwykle wynika z mura, ale może wynikać z mudy. Muri objawia się awariami, nieobecnościami, problemami bezpieczeństwa itp.
• Mura: tłumaczone jako „nierówność”. Mura można znaleźć w wahaniach popytu klientów, czasach procesu na produkt lub zmienności czasów cyklu dla różnych operatorów. Kiedy mura nie jest zredukowana, zwiększa się prawdopodobieństwo wystąpienia muri, a zatem i mudy. Mura można zmniejszyć, tworząc otwartość w łańcuchu dostaw, zmieniając projekt produktu i tworząc standardową pracę dla wszystkich operatorów.

TPS pracował nad wyeliminowaniem marnotrawstwa, stosując te dwie podstawowe koncepcje:

• Jidoka: luźno tłumaczone jako „automatyzacja z ludzkim dotykiem” stanowi, że „Jakość musi być wbudowana w proces produkcyjny!” co oznacza, że ​​w przypadku wystąpienia problemu sprzęt natychmiast się zatrzymuje, uniemożliwiając produkcję wadliwych produktów.
• Just-in-Time: Robienie tylko „tego, co jest potrzebne, kiedy jest to potrzebne i w potrzebnej ilości”.

Wraz z ewolucją TPS te podstawowe filary i wartości opierały się na koncepcjach Jidoka i JIT i ugruntowały się:

• Ciągłe doskonalenie:
  • Wyzwanie: tworzenie długoterminowej wizji i stawianie czoła wyzwaniom z odwagą i kreatywnością w celu realizacji marzeń
  • Kaizen: ciągłe doskonalenie operacji biznesowych, zawsze dążenie do innowacji i ewolucji, eliminowanie jednej mudy na raz
  • Genchi Genbutsu: ćwiczenie genchi genbutsu, chodzenie do źródła, aby znaleźć fakty, aby podejmować właściwe decyzje, budować konsensus i osiągać cele w naszym najlepszym tempie
• Szacunek dla ludzi:
  • Szacunek: szanowanie innych i dokładanie wszelkich starań, aby się nawzajem zrozumieć, brać odpowiedzialność i starać się budować wzajemne zaufanie
  • Praca zespołowa: stymulowanie rozwoju osobistego i zawodowego, dzielenie się możliwościami rozwoju oraz maksymalizacja wyników indywidualnych i zespołowych
• Andon: wizualny wskaźnik stanu lub problemu
• Heijunka: oznacza wyrównanie lub wyrównanie produkcji
• Hansei: oznacza autorefleksję. Aby poprawić wydajność, pracownicy powinni kwestionować założenia stojące za obecnymi procesami, aby znaleźć lepsze.
• Kanban: szyld używany jako wizualne narzędzie do kontroli produkcji
• Poka-yoke: określane również jako zabezpieczenie przed błędami lub zabezpieczenie przed błędami
• System wciągania: materiał jest wciągany do stacji roboczej dokładnie tak, jak jest potrzebny
• Seiri: to zasada, która odzwierciedla marnotrawstwo. Seiri dyktuje, że to, co jest niepotrzebne, powinno zostać usunięte. Obejmuje to wszystkie oryginalne siedem odpadów TPS
• Standaryzacja: organizuje wszystkie zadania związane z ruchem człowieka i tworzy wydajną sekwencję produkcyjną bez mudy. Pomaga to prowadzić do jakości, stałego tempa i pozwala na ciągłe doskonalenie.

Poniższy diagram pokazuje, w jaki sposób podstawowe pojęcia i podstawowe wartości odnoszą się do siebie.

szczupłe zarządzanie

Toyota Product System i Lean Manufacturing ewoluowały z biegiem czasu i były stosowane w wielu obszarach, w tym w zarządzaniu.

Lean Management zastosowało podstawowe wartości ciągłego doskonalenia i szacunku dla ludzi i przekształciło je w zestaw pięciu nakazowych zasad Lean, które byłyby powtarzane wiele razy w celu ciągłego doskonalenia i eliminowania marnotrawstwa:

1. Zidentyfikuj wartość: Określ wartość z punktu widzenia klienta końcowego według rodziny produktów.
2. Mapuj strumień wartości: Zidentyfikuj wszystkie kroki w strumieniu wartości dla każdej rodziny produktów, eliminując w miarę możliwości te kroki, które nie tworzą wartości.
3. Tworzenie przepływu: Spraw, aby etapy tworzenia wartości odbywały się w ścisłej kolejności, tak aby produkt płynnie płynął w kierunku klienta.
4. Ustanowienie ściągania: w miarę wprowadzania przepływu pozwól klientom pobierać wartość z następnej czynności poprzedzającej.
5. Poszukuj perfekcji: Po określeniu wartości identyfikowane są strumienie wartości, zmarnowane kroki są usuwane, wprowadzane są przepływ i ciągnięcie, ponownie rozpocznij proces i kontynuuj go, aż zostanie osiągnięty stan doskonałości, w którym powstaje idealna wartość bez marnotrawstwa.

Te zasady i inne aspekty Lean Management zostały sformalizowane, kiedy firma Womack & Jones opublikowała „Lean Thinking” w 1996 roku.

Rozwój oprogramowania szczupłego

Od tego czasu Lean znalazł zastosowanie w zarządzaniu, tworzeniu oprogramowania i innych dziedzinach.

W latach 80. i 90. branża programistyczna zbliżała się do kryzysu, ponieważ projekty realizowane przy użyciu tradycyjnych metodologii kaskadowych trwały coraz dłużej. Często skutkowało to ogromnym opóźnieniem między zidentyfikowaniem potrzeby biznesowej a dostarczeniem rozwiązania programowego. Czasami opóźnienie to było mierzone w wielu latach, a nawet dziesięcioleciach w niektórych branżach o szczególnych wymaganiach, takich jak przemysł lotniczy.

W tych wieloletnich ramach czasowych zmieniły się wymagania, systemy, a nawet całe firmy. Często projekty były anulowane w połowie lub uzupełniały swój zakres tylko po to, by stwierdzić, że to, co dostarczyły, nie spełnia już potrzeb biznesowych określonych na początku projektu.

Metodologia Waterfall nagradzała interesariuszy za myślenie o wszystkim, ponieważ zostali zmuszeni do napisania umowy, mimo że prawdopodobnie nie byli pewni, czego potrzebują. Metodologia Waterfall wymuszała podejmowanie decyzji na etapie wymagań lub projektowania, a decyzje te bardzo trudno było zmienić bez zmiany umowy i zwiększenia kosztów projektu. Wysoki odsetek projektów oprogramowania nie powiódł się całkowicie lub został dostarczony z opóźnieniem i przekroczeniem budżetu lub nie dostarczył tego, co było potrzebne.

Ta ogólna frustracja doprowadziła do tego, że różni liderzy myśli próbowali ulepszyć Waterfall. Wczesne przykłady obejmują Rapid Application Development (RAD), który koncentrował się na zmniejszeniu ilości odpadów poprzez skrócenie wymagań i faz projektowania poprzez szybkie opracowanie prototypu i współpracę z biznesem w celu dalszego rozwijania wymagań. Nastąpił również ruch w kierunku rozwoju iteracyjnego, w którym ukończono mały projekt i dodano funkcje w ciągłych iteracjach. Chociaż te metodologie pomogły, nie rozwiązały podstawowych problemów związanych z Wodospadem.

W latach 90. i na początku XXI wieku kilku autorów opublikowało książki na temat zastosowania zasad Lean w tworzeniu oprogramowania. Dr Robert Charette opublikował „Lean Software Development” w 1993 roku oraz „12 zasad Lean Software Development” w 2003 roku.

Tom i Mary Poppendieck opublikowali „Lean Software Development: Agile Toolkit” w 2003 roku. Książka ta szczegółowo opisuje siedem zasad Lean Development, które bezpośrednio korelują z siedmioma formami marnotrawstwa w Lean Manufacturing. Podobieństwa i różnice między dwiema różnymi publikacjami Lean i Agile (omówione w następnej sekcji) zostały przedstawione na poniższym schemacie.

Różnice między Lean a Agile

Według dr Charette, jedną z głównych różnic między Lean a Agile jest to, że Agile jest oddolne, podczas gdy Lean jest odgórne.

Agile Framework

Początki Agile i Manifest Agile

Mniej więcej w tym samym czasie, gdy Charette i Poppendiecks opublikowali swoje książki, stworzono Agile Framework, aby pomóc rozwiązać te same problemy. W lutym 2001 roku grupa pionierów Agile spotkała się na niesławnym spotkaniu Snowbird w Snowbird w stanie Utah, aby spróbować znaleźć rozwiązanie.

Rezultatem był Manifest Agile, który określał zestaw wartości i zasad dla metodologii, która próbuje dostosowywać się do zmieniających się wymagań i potrzeb klientów, ograniczać marnotrawstwo i szybciej dostarczać korzyści przy użyciu stopniowego, iteracyjnego podejścia.

Manifest Agile brzmi następująco:

„Odkrywamy lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym. Dzięki tej pracy doceniliśmy:

• Osoby i interakcje nad procesami i narzędziami
• Działające oprogramowanie nad obszerną dokumentacją
• Współpraca z klientem przy negocjacjach umowy
• Reagowanie na zmianę na przestrzeganie planu

Oznacza to, że chociaż przedmioty po prawej stronie mają wartość, bardziej cenimy przedmioty po lewej stronie.

12 zasad manifestu Agile jest zgodnych z wartościami zawartymi w manifeście:

„Przestrzegamy tych zasad:

1. Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania.
2. Witamy zmieniające się wymagania, nawet na późnym etapie rozwoju. Procesy zwinne wykorzystują zmiany dla przewagi konkurencyjnej klienta.
3. Dostarczaj działające oprogramowanie często, od kilku tygodni do kilku miesięcy, preferując krótsze ramy czasowe.
4. Biznesmeni i programiści muszą współpracować codziennie przez cały czas trwania projektu.
5. Buduj projekty wokół zmotywowanych osób. Zapewnij im środowisko i wsparcie, których potrzebują, i ufaj, że wykonają swoją pracę.
6. Najbardziej wydajną i efektywną metodą przekazywania informacji zespołowi programistycznemu i wewnątrz niego jest rozmowa twarzą w twarz.
7. Działające oprogramowanie jest podstawową miarą postępu. Procesy zwinne promują zrównoważony rozwój.
8. Sponsorzy, programiści i użytkownicy powinni być w stanie utrzymać stałe tempo w nieskończoność.
9. Ciągła dbałość o doskonałość techniczną i dobry projekt zwiększa zwinność.
10. Prostota — sztuka maksymalizacji ilości niewykonanej pracy — jest niezbędna.
11. Najlepsze architektury, wymagania i projekty powstają dzięki samoorganizującym się zespołom.
12. W regularnych odstępach czasu zespół zastanawia się, jak stać się bardziej skutecznym, a następnie odpowiednio dostosowuje i dostosowuje swoje zachowanie”.

Powyższe wartości i zasady to zastosowania zasad Lean, takich jak Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka oraz ograniczanie marnotrawstwa.

Zasady Agile stosowane przy tworzeniu oprogramowania

Agile jest ramą parasolową, która ma zastosowanie do każdego procesu, który stosuje zestaw wartości i zasad Agile.

Oto kilka przykładów:

• Ekstremalne programowanie
• Scrum
• Kanban

Scrum

Krótka historia szumowin

Scrum to framework, który stosuje zasady Agile, które zostały wymyślone oddzielnie przez wiele osób, z których kilka podpisało Manifest Agile:

• Hirotaka Takeuchi i Ikujiro Nonaka początkowo wprowadzili termin „scrum” w kontekście produkcyjnym w swojej białej księdze „The New Product Development Game”. opublikowany w 1986 roku w Harvard Business Review.
• Jeff Sutherland, John Scumniotales i Jeff McKenna wdrożyli Scrum w Easel Corporation w 1993 roku.
• Ken Schwaber wykorzystał to, co w latach 90. stało się Scrumem w jego firmie, Zaawansowane Metody Rozwoju.

Schwaber i Sutherland współpracowali przez całe lata 90., aby opracować i udoskonalić ramy w kontekście tworzenia oprogramowania, przemawiając na różnych konferencjach. Schwaber współpracował z Mikiem Beedle, aby opisać metodę w książce „Zwinne tworzenie oprogramowania za pomocą Scrum” w 2001 roku.

Następnie Schwaber stworzył oba główne urzędy certyfikacji Scrum:

• Scrum Alliance: utworzony w 2001 roku. Stworzył serię akredytacji Certified Scrum .
• Scrum.org: utworzony w 2009 roku po tym, jak Schwaber opuścił Sojusz Scrum. Skonfiguruj równoległą serię akredytacji Professional Scrum .

Z biegiem czasu stworzono kilka frameworków/jednostek certyfikujących w celu skalowania struktury Scrum do większych zespołów i projektów, ponieważ Scrum został pierwotnie zaprojektowany dla małych zespołów (7 plus lub minus 2 członków):

• SAFe: Scaled Agile Framework
• LeSS: Scrum na dużą skalę
• Scrum@scale: Scrum at Scale stworzony przez Jeffa Sutherlanda

Wartości Scrum

Według Scrum Alliance:

Scrum to prosty, ale niezwykle potężny zestaw zasad i praktyk, które pomagają zespołom dostarczać produkty w krótkich cyklach, umożliwiając szybką informację zwrotną, ciągłe doskonalenie i szybką adaptację do zmian.

Scrum to nakazowe, przyrostowe i iteracyjne ramy do tworzenia oprogramowania, które stosuje zasady Agile. Wartości i zasady Scrum są przedstawione na poniższych wykresach i są w znacznym stopniu zgodne z wartościami i zasadami Lean i Agile.

Przegląd Scrum

Praca jest podzielona na krótkie, ograniczone czasowo iteracje zwane sprintami, które zwykle trwają 1-3 tygodnie. Stanowi to wyraźny kontrast z dogłębnym planowaniem Wodospadu. Praca zaplanowana na bieżący sprint jest wybierana z góry priorytetowego rejestru elementów pracy zwanego Backlogiem Produktu (Pull System, Heijunka) i jest naprawiana po rozpoczęciu sprintu. Celem jest posiadanie działającego oprogramowania na końcu każdego sprintu, umożliwiającego szybką informację zwrotną.

Pod koniec sprintu zespół spotyka się, aby przejrzeć wykonaną pracę, przebieg sprintu i zaplanować kolejny sprint. Długość sprintu, a także rytuały sprintu i kadencja są ustalone dla każdego sprintu.

Sprinty realizowane są przez wielofunkcyjne zespoły zawierające wszystkie umiejętności potrzebne do wykonania pracy w sprincie. Codzienne planowanie i śledzenie postępów odbywa się za pomocą artefaktów wizualnych, takich jak tablica scrum i wykresy wypalania sprintu.

Praca w sprincie jest wyciągana z zaległości o określonym priorytecie. Postępowanie zgodnie z tymi metodami pozwala na zmianę wymagań w czasie i zachęca do ciągłej informacji zwrotnej od użytkowników końcowych.

Poniższy diagram mapy myśli przedstawia niektóre z głównych koncepcji Szumowiny, które zostaną omówione w kolejnych sekcjach.

Role Scrum

Scrum ma trzy role:

• Scrum Master : Scrum Master jest sługą liderem zespołu Scrum. Jest trenerem zespołu, który ułatwia współpracę, usuwa utrudnienia, wymusza i zabezpiecza proces Scrum oraz chroni zespół. Oznacza to zazwyczaj, że organizują i ułatwiają rytuały sprintu, zapewniają, że właściciel produktu ma odpowiednio uporządkowane i uporządkowane zaległości, upewnia się, że zespół nie jest zmuszany do nadmiernego angażowania się w sprint, zapewnia, że ​​zakres nie jest dodawany do sprintu, zapewnia przestrzeganie Definicji Ukończenia. Nie przydzielają zadań członkom zespołu (Genchi Genbutsu) i nie odpowiadają za dostarczenie projektu
• Właściciel produktu : właściciel produktu to „pojedyncza szyjka, którą można ukręcić”, odpowiada za dostarczenie produktu. Właściciel produktu określa wizję tego, co chce zbudować i przekazuje tę wizję zespołowi i organizacji. Właściciel produktu jest właścicielem wymagań biznesowych i rynkowych oraz nadaje priorytet całej pracy, którą należy wykonać podczas tworzenia i zarządzania rejestrem produktu. To oni decydują, które funkcje i kiedy wysłać. Współpracują z zespołem i innymi interesariuszami, aby upewnić się, że wszyscy rozumieją elementy w rejestrze produktu. Akceptują lub odrzucają pracę wykonaną w sprincie na sprint demo.
• Członek zespołu : Zespół Scrum to samoorganizujący się, wielofunkcyjny zespół składający się zazwyczaj z pięciu do siedmiu członków. Wszyscy w projekcie pracują razem i pomagają sobie nawzajem, niekoniecznie przywiązani do odrębnych ról, takich jak architekt, programista, projektant czy tester. Wszyscy razem dopełniają zestawu pracy. Zespół Scrumowy planuje, ile pracy może wykonać każdy sprint i jest właścicielem planu (Genchi Genbutsu).

Scrum Flow, działania i ceremonie

Jak omówiono powyżej, Scrum ma określony przepływ oraz zestaw rytuałów i czynności. Przebieg sprintu jest następujący.

Planowanie sprintu:

Przed rozpoczęciem sprintu Scrum Master ułatwia spotkanie z zespołem scrumowym i właścicielem produktu, zwane spotkaniem planowania sprintu, gdzie właściciel produktu identyfikuje cele nadchodzącego sprintu, a następnie zespół planuje swoją pracę zgodnie z celami.

Odbywa się to zwykle za pomocą następujących czynności:

• Pojemność sprintu: zespół określa pojemność sprintu, biorąc pod uwagę liczbę dni, liczbę członków zespołu, urlopy itp.
• Cele sprintu: właściciel produktu określa, jakie są cele sprintu. Niezwykle ważne jest, aby zaległości produktowe były traktowane priorytetowo zgodnie z celami (tj. odpowiednie historie były na górze) i przygotowywane.
• Wybór pracy: historie lub zadania są wciągane ze szczytu zaległości do sprintu, aż do osiągnięcia szacowanej wydajności. Gdy historie są wciągane, właściciel produktu wyjaśnia historię i odpowiada na pytania zespołu, aktualizując historię zgodnie z potrzebami, aż właściciel produktu i zespół Scrumowy będą mieli dobre, wspólne zrozumienie historii. Po zakończeniu tego działania zespół ma proponowany początkowy zakres sprintu.
• Podział zadań: zespół Scrum szczegółowo omawia każdą historię, kładąc nacisk na zaplanowanie, w jaki sposób ukończy historię i zajmie się wszystkimi kryteriami akceptacji oraz DoD. Stworzą listę podzadań potrzebnych do ukończenia historii. Gdy lista podzadań jest kompletna, oszacowanie historii jest przeglądane i aktualizowane w razie potrzeby.
• Zaangażowanie w sprint: po rozbiciu wszystkich historii i zaktualizowaniu szacunków następuje przegląd proponowanego początkowego zakresu sprintu. Historie mogą zostać usunięte ze sprintu i umieszczone z powrotem w backlogu i/lub mogą zostać dodane dodatkowe historie. Po wykonaniu tej czynności TYLKO zespół Scrumowy (a nie Scrum Master czy właściciel produktu) zobowiązuje się do zakończenia pracy w sprincie i sprint się rozpoczyna.

Całkowita ilość pracy lub zakresu przydzielonego do sprintu jest mierzona w punktach fabularnych.

Wykonanie sprintu

Podczas sprintu członkowie zespołu wyciągają elementy pracy (historie użytkowników, zadania itp.) z góry listy zadań do wykonania, aby nad nimi pracować. Różni członkowie zespołu będą pracować nad różnymi elementami pracy lub ich podzadaniami. W razie potrzeby zaktualizują status elementu, przenosząc go z jednej kolumny do następnej (zazwyczaj Do zrobienia > W toku > Testowanie > Zrobione lub jakaś ich odmiana) na tablicy Scrum, dopóki nie zostanie ukończone.

Postęp jest śledzony za pomocą wykresu spalania, który pokazuje ilość wykonanej pracy i pozostałej pracy mierzonej w punktach fabularnych. Pozostałe punkty kondygnacji są pokazane na osi Y, a pozostały czas na osi X. Wykres spalania jest aktualizowany po zakończeniu historii.

Na co dzień Scrum Master skupia się na:

• Ułatwia codzienne spotkanie standup w celu zaplanowania dnia i przeglądu postępów (patrz poniżej)
• Zapewnia, że ​​zespół ma plan na cały dzień
• Usuwa blokady drogowe
• Chroni zakres sprintu i zespół przed zakłóceniami
• Pomaga zespołowi utrzymać wykres wypalania i inne statystyki Scrum

Codzienny Standup

Na początku każdego dnia sprintu Scrum Master ułatwia krótkie, 15-minutowe spotkanie z zespołem scrumowym i właścicielem produktu, aby zaplanować dzień i dokonać przeglądu postępów sprintu. Jest to krótkie spotkanie, na którym wszyscy stoją przed tablicą Scrum i każda osoba na spotkaniu odpowiada na następujące pytania w ciągu 2 minut lub mniej, odnosząc się do konkretnych pozycji na tablicy sprintu:

• Co robiłeś wczoraj?
• Co planujesz dzisiaj zrobić?
• Czy są jakieś przeszkody uniemożliwiające Ci ukończenie pracy?

Dzięki temu każdy może zobaczyć, nad czym wszyscy pracują, zobaczyć, jakie postępy są czynione, a także identyfikować przeszkody i/lub potrzebną pomoc.

Ukończenie sprintu

Scrum Master ułatwia dwie ceremonie zamknięcia sprintu przed zaplanowaniem kolejnego sprintu.

Demo sprintu

Pod koniec sprintu Scrum Master ułatwia spotkanie demonstracyjne, podczas którego każda ukończona historia jest prezentowana właścicielowi produktu i reszcie zespołu w działającym oprogramowaniu. Właściciel produktu albo zaakceptuje historię, jeśli wszystkie kryteria akceptacji zostaną spełnione, albo odrzuci historię. Jeśli historia zostanie odrzucona, braki są identyfikowane, a historia jest umieszczana z powrotem w zaległości produktu w kolejności priorytetowej do ukończenia w późniejszym czasie lub wcale. Często części historii, których właściciel produktu nie akceptuje, są rozdzielane na osobne historie, a oryginalna historia jest zamykana.

Całkowita liczba ukończonych punktów fabularnych na sprint (Velocity) jest obliczana i sprint jest zamykany. Prędkość służy do śledzenia poziomu wyjściowego zespołu i służy do oszacowania, kiedy funkcje lub wydania zostaną ukończone.

Retrospektywa Sprintu

Po demonstracji sprintu, ale przed kolejnym spotkaniem planującym sprint, Scrum Master przeprowadza retrospektywę sprintu, podczas której zespół zastanawia się nad sprintem, który właśnie się zakończył i omawia, co poszło dobrze, a co nie poszło dobrze, aby móc stale i stopniowo ulepszać proces i jakość w czasie (Kaizen, Hansei). Istnieje mnóstwo retrospektywnych formatów lub ćwiczeń, które można wykorzystać, aby pomóc zespołowi wywołać dyskusję.

Tworzona jest lista elementów działań usprawniających, które czasami skutkują dodaniem elementów do rejestru produktu, zmian w DoD lub statucie zespołu itp.

Zarządzanie Backlogiem Produktu

Tworzenie Backlogu Produktu

Zanim sprint będzie mógł zostać zaplanowany lub wykonany, właściciel produktu musi stworzyć rejestr prac produktowych. Zaległości zwykle zaczynają się od elementów rozwoju funkcji, zwanych historiami, napisanych przez właściciela produktu, a z czasem są również wypełniane zadaniami programistycznymi lub QA, skokami, defektami itp. potencjalnie stworzonymi przez dowolnego członka zespołu. Wszystkie pozycje w rejestrze są uporządkowane według priorytetu.

Pielęgnacja zaległości

Po utworzeniu i ustaleniu priorytetów początkowego rejestru produktów, nadrzędny staje się trwający proces opracowywania rejestru. Celem jest, aby zawsze mieć przynajmniej wystarczającą liczbę najważniejszych pozycji w backlogu, przygotowanych i oszacowanych, aby były gotowe do wciągnięcia do sprintu podczas spotkania dotyczącego planowania sprintu. Odbywa się to zazwyczaj poprzez regularne spotkania z menedżerem produktu i zespołem wspieranym przez Scrum Mastera w celu omówienia zaległości.

Przed spotkaniem do zespołu wysyłana jest lista historii, aby mogli przejrzeć i przygotować się do spotkania groomingowego. Na spotkaniu groomingowym każdy element jest omawiany pod kątem kryteriów akceptacji, złożoności, ryzyka, rozmiaru, strategii wdrożenia itp. Kryteria akceptacji i inne szczegóły historii są przeglądane i korygowane do czasu, gdy zespół, właściciel produktu i Scrum Master mieć wspólne zrozumienie historii. W tym momencie historia jest szacowana w punktach fabularnych przy użyciu techniki zwanej planowaniem pokera.

Szacowanie punktów historii

Punkty historii to jednostka wysiłku, która wykorzystuje względne rozmiary, w której historie są porównywane z wcześniejszymi, znanymi, dobrze zrozumianymi fragmentami pracy. Zawsze zadajesz sobie pytanie „czy ta historia jest większa, mniejsza lub mniej więcej tego samego rozmiaru” co inne dzieło.

Skala Fibonacciego (1, 2, 3, 5, 8, 13, 21…) jest najczęściej używaną skalą, w której każdy przyrost jest w przybliżeniu dwa razy większy niż poprzedni (tj. pięciopunktowa historia jest mniej więcej dwa razy większa jak trzypunktowa historia). Czasami używane są inne skale, takie jak rozmiary T-shirtów (XS, S, M, L, XL), a nawet ryby (strzebla, złota rybka, pstrąg, tuńczyk, wieloryb itp.). Dowolna skala, która pozwala porównać rozmiar czegoś w stosunku do innego, będzie działać.

Punkty historii reprezentują cały wysiłek zespołu, aby wdrożyć historię, w tym rozwój, testowanie, projektowanie i inne różne zadania potrzebne do zdefiniowania ukończenia. Szacunek uwzględnia ilość pracy, złożoność i ryzyko. Po określeniu względnego rozmiaru historii, jako oszacowanie przypisywany jest rozmiar na skali.

Zespoły przygotowują się do procesu szacowania story pointów, najpierw ustalając punkt odniesienia dla szacowania, wybierając „najśredniej” historię, którą cały zespół rozumie jako historyjkę referencyjną. Wybrano również kilka dodatkowych historii referencyjnych, które są większe i mniejsze.

Szacowanie Story Point odbywa się podczas spotkań groomingowych, a czasem podczas planowania sprintu za pomocą Planning Pokera:

1. Każdy członek zespołu/estymator ma zestaw kart.
2. Pozycje zaległości są omawiane pojedynczo, jak opisano powyżej.
3. Gdy przedmiot zostanie w pełni omówiony, każdy estymator prywatnie wybiera kartę, która reprezentuje swoje oszacowanie.
4. Kiedy wszyscy estymatorzy dokonają szacunków, jednocześnie ujawniają swoje karty.
   • Jeśli wszystkie szacunki są zgodne, estymatorzy wybierają inny element zaległości i powtarzają ten sam proces.
   • Gdy szacunki się różnią, estymatorzy omawiają tę kwestię, aby dojść do konsensusu.

Zalety szacowania story pointów to:

• Szybko: szacunki odnoszą się do już zakończonych pozycji rejestru produktów.
• Wystarczająco dokładny: wystarczająco dokładny, aby dać przegląd zakresu, zaplanować przyszłą pracę, ustalić priorytety i zarządzać oczekiwaniami.
• Obejmuje niepewność: Punkty fabularne określają nieznany zakres czasowy. Wybór z określonej sekwencji punktów historii, podobnej do Fibonacciego, pozwala uchwycić niepewność.
• Sport zespołowy: angażuje wszystkich (programistów, projektantów, QA, menedżerów produktu). Wykorzystuje wiele perspektyw do określenia rozmiaru pracy, ale tylko członkowie zespołu wykonujący pracę mogą ją oszacować
• Mierzy prędkość zespołu: mierzy, ile pracy zespół wykonuje w sprincie w porównaniu z ilością czasu spędzonego na pracy. Wraz z rozwojem zespołu szybciej ukończą historie o tym samym rozmiarze, co z czasem zwiększy prędkość zdobywania punktów fabularnych.

Szacowanie i śledzenie wersji

Szacowanie punktów historii jest również używane w kontekście planowania wydania przy użyciu następującej techniki:

1. Wymień wszystkie historie do ustalenia
2. Ułóż je w kolejności od najmniejszego do największego
   • Weź pierwszą i drugą historię użytkownika.
   • Zdecyduj, który jest większy i umieść większy poniżej
   • Następnie weź następny i zdecyduj, gdzie pasuje do pozostałych dwóch
   • Powtarzaj proces, aż wszystkie historie znajdą się teraz na liście (w kolejności od najmniejszej do największej)
3. Rozmiar opowieści

Oszacowania historii dla wszystkich historii w wydaniu w połączeniu z szybkością działania zespołu pozwolą ci oszacować, kiedy wydanie zostanie ukończone i śledzić jego postępy. Jest to często pokazane na wykresie wypalania wersji.

Artefakty i warunki Scrum

• Rejestr produktu: lista zaległości wszystkich elementów pracy dla danego produktu, która może zawierać funkcje (historie), zadania techniczne, skoki i defekty
• Wypalanie wydania: Graficzny wykres używany do pokazania postępu na poziomie wydania i przewidywania, kiedy wydanie zostanie ukończone przy użyciu prędkości Sprint. Ukończone punkty historii są wyświetlane na osi Y, a sprinty są wyświetlane na osi X.
• Sprint Backlog: Lista zaległości wszystkich elementów pracy do wykonania w danym sprincie. Treść backlogu sprintu jest uzgadniana podczas spotkania planującego sprint.
• Tablica Scrum: Tablica w stylu stołu, która śledzi postęp prac poświęconych sprintowi. Statusy są wyświetlane u góry w pionowych kolumnach, a elementy pracy są przesuwane po każdym statusie, dopóki nie zostaną zakończone. Tablica Scrum jest wypełniana podczas spotkania planowania sprintu i jest resetowana na koniec sprintu.
• Sprint Burndown: Graficzny wykres, który pokazuje ilość wykonanej pracy i pozostałej pracy mierzonej w punktach fabularnych przez cały czas trwania sprintu. Pozostałe punkty kondygnacji są pokazane na osi Y, a pozostały czas na osi X.
• Prędkość sprintu: Liczba punktów fabularnych, które zespół Scrumowy zdobywa w sprincie.
• Backlog Utrudnień: Lista utrudnień, którymi Scrum Master musi się zająć, aby zespół mógł kontynuować pracę. Gdy członek zespołu zostanie zablokowany, doda element do rejestru utrudnień, aby zapewnić widoczność zespołowi i Scrum Masterowi.
• Epic: Epopeja to obszerna praca składająca się z wielu powiązanych historii użytkowników.
• User Story: User Story to opis funkcji oprogramowania z perspektywy użytkownika końcowego. Historyjka użytkownika opisuje typ użytkownika, czego chce i dlaczego. Historyjka użytkownika pomaga stworzyć uproszczony opis wymagania i zawiera kryteria akceptacji. Historyjki użytkownika są tworzone i obsługiwane przez właściciela produktu.
• Zadanie: Zadanie to praca, którą wprowadza Scrum Master lub członek zespołu, która może być bezpośrednio lub pośrednio związana z historyjkami użytkownika. Mają one zwykle charakter techniczny i zawierają kryteria akceptacji.
• Spike: Spike to specjalny rodzaj zadania, który jest używany, gdy trzeba najpierw przeprowadzić badania, prototypy i/lub architekturę, zanim zdecydujesz, jak wdrożyć lub oszacować historyjkę użytkownika.
• Podzadanie: podzadanie to zadanie, które jest wprowadzane jako etap implementacji w celu ukończenia historyjki użytkownika lub zadania. Zazwyczaj są one wprowadzane przez zespół podczas spotkania planowania sprintu.
• Szacunki Story Point: Skala szacowania względnego rozmiaru oparta na skali Fibonacciego (1, 2, 3, 5, 8, 13, 21…)
• Kryteria akceptacji: Lista specyficznych dla historii, testowalnych elementów zawartych w każdej historii, które muszą zostać ukończone, zanim właściciel produktu zaakceptuje historię jako ukończoną.
• Definicja ukończenia (DoD): Lista typowych kroków lub kryteriów, które muszą zostać spełnione, aby jakakolwiek historia mogła zostać uznana za ukończoną. Zespół zgadza się z tym i dokumentuje to, aby nie musiało być wymienione w każdej historii.

Zalety i wady Scrum

Główną zaletą Scrum jest zastosowanie wartości i zasad Agile oraz koncepcji Lean, takich jak Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System i Iterations. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.