Metodyka odchudzona Scrum

Autor: David Starr.David Starr jest głównym technologiem oprogramowania w Scrum.org, gdzie koncentruje się na doskonaleniu zawodu dewelopera oprogramowania.Założył również internetową społeczność techniczną ElegantCode.com.

Lipiec 2012 r.

Przejrzyj nieodłączne cechy metodyki odchudzonej używane w środowisku Scrum oraz różne sposoby, jak pomóc zespołom scrumowym poprawić swoją efektywność za pomocą odchudzonego myślenia.

Dotyczy

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

Bieżące dyskusje na temat zwinnego tworzenia oprogramowania obejmują niezmiennie Scrum, tworzenie odchudzone i Kanban — trzy narzędzia do planowania, monitorowania i wykonywania działań tworzenia oprogramowania.Narzędzia te często są ze sobą porównywane lub przeciwstawiane sobie przez niektórych praktykujących agile — niektórzy twierdzą, że Scrum i Odchudzone myślenie dobrze ze sobą współdziałają, podczas gdy inni patrzą na te narzędzia jako na dwa zasadniczo różne sposoby dostarczania oprogramowania.

Omówienie

Scrum jest bardzo popularna; 92% zespołów korzystających z metodyk zwinnych korzysta ze Scrum[1].Mając próbkę sukcesów, jakie zapewnia metodyka Scrum, wiele zespołów szuka możliwości zwiększenia dojrzałości swoich praktyk poza podstawowe środowisko Scrum.Ten artykuł opisuje rozszerzanie środowiska Scrum o techniki odchudzonego myślenia oraz Kanban, z myśleniem Kaizen oraz ciągłą poprawą.

Scrum

Struktura Scrum, wprowadzona w 1995 r. przez Kena Schwabera i Jeffa Sutherlanda, jest sposobem na współpracę zespołów, mającą na celu dostarczanie oprogramowania w sposób powtarzalny i przyrostowy.Zespoły Scrum organizują pracę w jednostki czasowe nazywane Sprintami, trwającymi miesiąc lub mniej, a każdy Sprint ma stworzyć kompletny i działający produkt.

Struktura Scrum jest łatwa do zrozumienia i stała się bardzo popularna wśród zespołów projektujących oprogramowanie i ich klientów.Scrum doradza, aby współzależne i samozarządzalne zespoły skupiały uwagę przez cały czas trwania Sprintu na dostarczeniu Przyrostu pracy oraz oprogramowania potencjalnie gotowego do wypuszczenia na rynek.

Scrum jest skodyfikowana w przewodniku Scrum, który dokumentuje role, artefakty i zdarzenia Scrum.Podręcznikiem Scrum zajmują się jego autorzy. Jest on dostępny online na stronie Scrum.org.

Metodyka odchudzona

Metodyka odchudzonego myślenia jest sposobem podejścia do optymalizacji systemu przez skoncentrowanie się na ograniczaniu strat i poprawie ogólnego przepływu wartości przez system.Metodyka odchudzona ma bogatą historię w produkcji i zyskała popularność w kręgach producentów oprogramowania w ostatnich latach.

Zastosowana do rozwoju oprogramowania metodyka odchudzonego myślenia jest uosabiana przez następujące siedem zasad opublikowanych po raz pierwszy w książce Lean Software Development: An Agile Toolkit[2].

1. Eliminowanie strat

2. Poprawa skuteczności nauki

3. Zdecyduj jak najpóźniej

4. Dostarczaj tak szybko, jak to możliwe

5. Wyposaż zespół w kompetencje

6. Wbuduj integralność

7. Zobacz całość

Zastosowanie tych zasad do prac mających dostarczyć produkt oprogramowania nie jest celem końcowym.Nie mówi się, że ktoś „działa w sposób odchudzony”, ale raczej stosuje zasady metodyki odchudzonej do sterowania podejmowaniem decyzji i wybierania technik, które poprawią ogólnie system.Na przykład praktyka TDD (tworzenia oprogramowania opartego na testowaniu) wbudowuje integralność w oprogramowanie przez sprawdzanie go w miejscu tworzenia, wspierając tym samym zasadę odchudzonego programowania przewidującą wbudowywanie integralności w trakcie procesu tworzenia.

Kanban

Jedna technika zakorzeniona w metodyce odchudzonego myślenia to Kanban[3], która korzysta z tej metodyki w metodzie formalnej, koncentrując się na zmniejszaniu ilości strat, dostawie w trybie just in time oraz unikaniu nadmiernego obciążenia przez pracowników.W przeciwieństwie do Scrum, Kanban nie jest metodą iteracyjną i przyrostową; zamiast na iteracji Kanban opiera się na pięciu głównych działaniach.

1. Wizualizacja przepływu pracy

2. Ograniczaj pracę w toku (PWT)

3. Zarządzaj przepływem

4. Uczyń zasady procesu jawnymi

5. Poprawa przez wspólne działanie

Różne zespoły używające metodyki Kanban często mają bardzo różne procesy.Metoda Kanban to po prostu zestaw technik zarządzania procesem i jego celowa optymalizacja.Metodyka Kanban jest łatwo stosowana do procesów już istniejących, w tym Scrum.

Scrum i Kaizen

Gdy przyrosty działającego oprogramowanie dostarczane są stale z każdego sprintu, zespoły scrumowe poszukują nowych sposobów poprawy efektywności działania.Sercem skutecznego Scrum jest Kaizen, czyli myślenie o ciągłych udoskonaleniach.Dobre zespoły scrumowe niemal z pewnością używają mnóstwa praktyk w swoim skupieniu się na metodyce Kaizen.Narzędzia i techniki, takie jak oszacowanie względne, programowanie z testowaniem na pierwszych etapach, automatyzacja kompilacji i programowanie w parach — wszystkie są dostępne w zespołach Scrum.

Nie tylko inne narzędzia, techniki i praktyki działają dobrze w uzupełnieniu metody Scrum, ale istnieje też model rozszerzania metody Scrum opisany i zarządzany w witrynie scrum.org.Ten model rozszerzenia do Scrum zachęca społeczność do włączenia się w dokumentowanie praktyk stanowiących uzupełnienie Scrum i poprawnie działających w ramach struktury.W czasie pisania tego dokumentu zostało zaproponowanych kilka rozszerzeń w szczególności stosujących praktyki odchudzonego programowania w metodyce Scrum.

Zalety stosowania metodyki odchudzonego myślenia do metodyki Scrum są bezsprzeczne.Co nie dziwi, wielu praktyków metody Scrum uzyskało lepszą wydajność i jakość przez zastosowanie metodyki odchudzonego myślenia do swoich praktyk Scrum.

Oglądanie Scrum przez odchudzony obiektyw

Struktura Scrum składa się z następujących ról, artefaktów i zdarzeń.Jeśli nie znasz podstaw środowiska Scrum, przed kontynuowaniem przeczytaj przewodnik po metodyce Scrum.

Role	Artefakty	Zdarzenia
Właściciel produktu Mistrz Młyna (Scrum Master) Zespół programistyczny	Dziennik produktu Dziennik sprintu Przyrost	Sprint Planowanie sprintu Scrum dzienny Omówienie sprintu Retrospektywa sprintu

Przewodnik Scrum ustanawia zasady, na jakich te składniki współpracują ze sobą, ale myślenie zgodne z metodyką chudego zarządzania zapewnia ramy dalszej optymalizacji wzajemnego oddziaływania ról, artefaktów i zdarzeń Scrum.Zespoły Scrum wybierają podzbiór Dziennika produktu, aby dostarczyć efekt każdego Sprintu i skupić się na dostarczaniu Przyrostu z właściwą jakością i funkcjonalnością.Metodyka odchudzonego myślenia może pomóc w optymalizacji przepływu pracy w całym sprincie i ograniczyć straty w całym strumieniu wartości.

Metody Scrum i programowania odchudzonego dążą do utrzymania wysokiej jakości, co jest niezbędne do sukcesu ogółu wykonywanej pracy.Aby zobaczyć zasady metodyki Scrum i rozwój oprogramowania chudego w działaniu, wystarczy przeanalizować role, artefakty i zdarzenia metodyki Scrum przez obiektyw chudego myślenia.

Zdarzenia

Z wyjątkiem sprintu, który jest kontenerem dla wszystkich innych zdarzeń, zdarzenia Scrum są tak naprawdę spotkaniami.Metodyka odchudzonego myślenia ogólnie traktuje spotkania jako straty, a straty trzeba pilnie eliminować.

Może to prowadzić do stwierdzenia, że zdarzenia Scrum są niepotrzebne.Jednak każde zdarzenie w metodzie Scrum jest starannie zaprojektowane do usunięcia innych spotkań, które w przeciwnym razie występowałyby w spontaniczny (przerywający) sposób.Dobrze wykonane zdarzenia Scrum skutkują mniejszą liczbą spotkań i mniejszą ilością czasu traconego na reagowanie na nieplanowane przerwy.

Każde zdarzenie Scrum ma na celu sprawdzenie czegoś i dostosowanie czegoś.Inspekcja obsługuje zasady Lean dotyczące nauki i tworzenia integralności w procesie tworzenia.Adaptacja planu, wymogu lub innego artefaktu podczas zdarzenia Scrum jest zbieżna z zasadami odchudzonego projektowania przewidującymi odraczanie decyzji i patrzenie całościowe.W poniższej tabeli przedstawiono zdarzenia Scrum z tematami, które podczas każdego z nich są badane i dostosowywane.

Zdarzenie	Sprawdzone	Zaadaptowany
Porządkowanie zaległości	Dziennik produktu	Dziennik produktu
Planowanie sprintu	Dziennik produktu Poprzednie skoki	Cel sprintu Dziennik sprintu
Scrum dzienny	Dziennik sprintu Postęp w kierunku celu sprint.	Dziennik sprintu Plan dzienny
Omówienie sprintu	Najnowszy przyrost Najnowszy sprint Dziennik produktu	Dziennik produktu Inne długoterminowe plany
Retrospektywa sprintu	Najnowszy przyrost Najnowszy sprint Zespół Scrum Praktyki techniczne	Zachowania zespołów Scrum Praktyki techniczne Używane w Scrum praktyki zarządzania pracą

Artefakty

Artefakty Scrum powinny być tak proste, jak to tylko możliwe.Wymagania, plany, a nawet oprogramowanie dostarczone przez zespół Scrum są najcenniejsze, gdy zawierają tylko szczegóły potrzebne do wykonania zadania.

Dziennik produktu

W idealnym świecie nie byłoby trzeba utworzyć wymagań wykraczający poza zwykłą rozmowę między osobami.Idealnie jest, gdy osoba prosząca o oprogramowanie zostaje właściwie zrozumiana przez tych, którzy je tworzą. W takim przypadku nie są potrzebne żadne pośrednie doprecyzowania wymagań.Chociaż jest to możliwe w bardzo małych zespołach, gdzie istnieją bliskie relacje z klientami, po prostu nie występuje w większych.Tworzenie wymagań przed dostarczeniem funkcji jest niezbędne do planowania.Metodyka odchudzona widzi wymagania jako zapasy, typową stratę w metodyce odchudzonego myślenia, i tym samym coś, co należy minimalizować.

W metodyce Scrum wymaganiami zarządza się w zaległości produktu, której definicja przewiduje bardzo mało formy i struktury.Nie istnieje wymóg, aby szczegółowo i dokładnie wyrażać elementy zaległości produktów .

Chociaż obsługa zaległości produktu i wymagania są niezbędne do planowania pracy, idealnym sposobem użycia jest utworzenie i uściślenie elementów zaległości produktu tylko trochę wcześniej niż zespół programistyczny, który faktycznie nad nimi pracuje.Skuteczne zespoły scrumowe unikają tworzenia wymagań w zaległości produktu, który mogą nigdy nie być przetwarzane.

Dziennik sprintu

W idealnym świecie nie byłoby potrzebne planowanie.Zespół programistyczny może po prostu wciąż następne żądanie o funkcję z kolejki, ignorując kontekst i koszt wymogu.Chociaż ten prosty model przetwarzania pracy jest bardzo elastyczny, nie uwzględnia faktu, że rozwój oprogramowania jest z natury złożonym przedsięwzięciem.Rozwój produktu o znacznej złożoności czerpie korzyści z planu, nawet jeśli taki plan jest prosty i pozbawiony szczegółów.

Przewodnik Scrum definiuje zaległości Sprint jako podzbiór elementów zaległości produktu wybranych do sprintu i plan ich dostarczania.Zaległości sprintu pokazują spis (straty) przewidywanej dla Sprintu pracy, który jest poprawiany co najmniej raz dziennie.Dzienne doskonalenie sprawia, że plan nigdy nie stanowi obietnicą i umożliwia zespołowi odroczenie decyzji dotyczących wdrożenia do ostatniej odpowiedniej chwili.

Zespoły Scrum tworzą wymagania i plany, które są ledwie wystarczające, w celu minimalizowania kosztów.Podejście odchudzone do minimalizowania zapasów pozwala na odraczanie podejmowania decyzji i umożliwia zespołowi samoorganizację w ramach Sprintu.Zamiast skupić się na wymaganiach lub planie, zespoły Scrum skupiają się na wartości dostarczanej w każdym przedziale przyrostu.

Przyrost

Każdy sprint obejmuje dostawę co najmniej jednego przyrostu działającego oprogramowania.Przyrost produktu to jedyny artefakt Scrum, który według metodologii Lean nie jest uważany za odpad.Mimo tego przyrost produktu może mieć w sobie straty.Odpady mogą występować w formie nieużywanych funkcji, wad, niekompletnej funkcjonalności, trudnego w obsłudze kodu lub słabo uwarunkowanych projektów.

Wysokowydajne zespoły scrumowe bezlitośnie eliminują straty w samym produkcie.Często jest to robione przez kontrolę przyrostów często przez cały sprint i utrzymanie wysokiej jakości przez cały czas.Realizuje to prawdziwą istotę zasady metodyki odchudzonej przewidującą wbudowywanie integralności.

Zespoły Scrum odnoszą również korzyści, pamiętając o zasadach odchudzonych podczas dostarczania Przyrostu.Struktura Scrum gwarantuje, że przyrost jest otwarty na kontrole w ramach przeglądu Sprint.Odbieranie opinii na temat przyrostu w przeglądzie Sprint jest bardzo istotne w procesie nauki.

Role

Role opisane przez Scrum są starannie zrównoważone w celu umocowania zespołu Scrum i zmniejszenia występujących w nim napięć.Scrum Masters, zespoły deweloperów i właściciele produktu działają wspólnie, aby odnieść sukces, który wymaga, aby wszyscy pracownicy widzieli perspektywy pozostałych.Współpraca taka sprawia, że członkowie zespołu Scrum widzą cały system Scrum. Widoczne stają się wszelkie decyzje, które częściowo zoptymalizowałyby zespół Scrum, poprzez wyróżnianie tylko jednej roli.

Współtwórca Scrum, Jeff Sutherland, uważa, iż podstawą pomyślnego wykonania implementacji odchudzonej jest systemowy wywiad i pracownicy z uprawnieniami menedżerów ułatwiającymi pracę.Samozarządzalne Zespoły programistyczne Scrum obejmują uprawnionych pracowników od metodyki odchudzonego myślenia, zdolnych do motywowania do uczenia się w organizacji, zamiast narzucania konieczności uczenia się.

Unikatowa dla metodyki Scrum jest rola Scrum Master, którą przewodnik Scrum opisuje następująco:

Mistrz Scrum jest odpowiedzialny za to, aby Scrum był zrozumiany i wdrożony. Scrum Masters robią to poprzez zapewnienie zespołu Scrum zgodnego z teorią, praktykami i zasadami Scrum. Mistrz Scrum jest liderem pracującym na rzecz zespołu Scrum.Przewodnik Scrum — październik 2011 r.

Jedną z głównych umiejętności i działań dobrego Scrum Mastera jest umożliwianie.W większości przypadków Scrum Master organizuje zdarzenia Scrum.Scrum Masters są menedżerami, aczkolwiek zarządzają przyjęciem i zgodnością Scrum, a nie osobami.

W kierunku Skromniejszy Scrum

Używanie metodyki odchudzonego myślenia przy rozważaniu problemów ujawnionych przez Scrum często daje wysokie zyski i jest doskonałym sposobem utrzymywania kultury Kaizen.Zespoły Scrum nadal uczą się, jak stowować odchudzone strategie w Scrum, ale wiele praktyk zyskuje na popularności, ponieważ przyczyniają się one do zwiększenia skuteczności zespołów Scrum.

Istnieje wiele wspólnych praktyk i technik używanych w pracy opartej na wiedzy, które bezpośrednio obsługują zasady metodyki Lean.Kilka z tych technik jest opinanych poniżej ze zwróceniem uwagi na to, jak mogą być realizowane w zespole Scrum.

Z pewnością nie jest to wyczerpujący wykaz technik, ale są to po prostu przykłady, jak niektóre zespoły Scrum mogą poprawić używanie wspólnych technik odchudzania, przeznaczone dla praktyków.Ponadto każdą technikę można zastosować na wiele sposobów.Poniżej przedstawiono tylko kilka technik metodyki odchudzonego myślenia.Zespoły Scrum mogą stosować inne niż opisane w tym dokumencie podejścia do następujących scenariuszy.

Eliminowanie strat

Prawdopodobnie najbardziej podstawową praktyką metodyki odchudzonej jest eliminacja strat.W metodyce odchudzonej za starty uznaje się wszystko, co nie jest jednoznacznie niezbędne do wytworzenia pożądanego rezultatu.Typowe straty podczas tworzenia oprogramowania obejmują:

1. Nieużywany kod lub funkcje

2. Wady, które prowadzą do przeróbek

3. Opóźnienia lub czas poświęcony na oczekiwanie na coś

4. Warunki przekazywania od jednej osoby, zespołu lub procesu biznesowego do innego

5. Bardzo szczegółowe wymagania

6. Niewystarczające wymagania

7. Wolna lub słaba komunikacja

Niektórych strat po prostu nie można uniknąć, a nawet są konieczne.W definicji najsurowszej na przykład dokumenty wymagań są stratami.Karta indeksu reprezentująca wymóg nie jest mimo wszystko dostarczana do klienta.Z tego powodu karta indeksu jest stratą.Sama karta wymagań nie jest funkcją produktu; reprezentuje ona pracę, którą należy wykonać, aby utworzyć funkcję.Karta wymóg istnieje, aby ułatwić deweloperom opracowywanie koncepcji i śledzenie pracy.Chociaż większość zespołów uważa to za niezbędną praktykę, łatwo to zidentyfikować jako stratę.

Chociaż niektóre straty są konieczne, często można zmniejszyć ich liczbę, zoptymalizować lub nawet je usunąć.Niektóre straty w strumieniu wartości tworzenia oprogramowania takie jak zbyt długie oczekiwanie na ewidencjonowanie kodu są łatwo rozpoznawane i eliminowane.Inne straty odkryte w zespołach pracujących nad rozwojem oprogramowania takie jak tworzenie dużych dokumentów dotyczących wymogów, zanim rozpocznie się proces rozwoju są częścią kultury i wymagają znacznego wysiłku i czasu, aby dokonać podstawowych zmian.

Scenariusz

Scrum działa już sześć miesięcy.Zespoły projektowe tworzą działające kompilacje przyrostowe oprogramowania z każdego dwutygodniowego sprintu i wszystkie mierzone wskaźniki jakości wykazują trend rosnący.

Podejście odchudzone

Mistrzowie Scrum spotykają się, aby dyskutować na temat szkolenia swoich zespołów z zakresu osiągania wyższej wydajności i jakości.Scrum Master sugeruje eliminowania strat w sposób opisany w metodyce odchudzonego myślenia.Zgadzając się na wypróbowanie pomysłu, Scrum Masterzy szukają przykładów strat i dzielą je między dwie listy — tych, które mogą zostać natychmiast wyeliminowane, i tych wymagających bardziej czasochłonnego zarządzania.

Pierwsza lista zawiera niepotrzebne elementy do wyeliminowania przez samych Scrum Masterów lub przez zespoły projektowe, i nie wymaga uprawnień ani oczekiwania.Drugi ma etykietę "Odpady z dziennika zaległości" i identyfikuje odpady, które wszyscy uznali za istniejące, ale ich zmiana wymaga znacznej ilości czasu lub nakładu pracy.Poniżej przedstawiono przykłady obu list:

Do zajęcia się natychmiast

Zaległości odpadów

Niektóre kompilacje są wykonywanie ręcznie na maszynie kompilacyjnej, która musi być wykorzystana tylko do tego celu. Pakowanie witryny sieci Web jest procesem ręcznym.Zautomatyzuj to. Wszyscy deweloperzy używają udostępnionej bazy danych i zmiany danych często przerywają płynność prac.Przenieś do modelu, gdzie każdy deweloper ma dedykowaną projektową bazę danych. Testy nie są zapisywane, dopóki istnieje funkcja.Zachęcaj i ucz praktyk testowania na pierwszych etapach dla specjalistów ds. testów.

Modele UML utworzone wcześniej do kodowania wszystkich funkcji. Komunikacja utrudniana przez układ biura, która wymaga od członków tego samego zespołu programistycznego chodzenia między pomieszczeniami biurowymi na drobne, spontaniczne dyskusje. Wprowadzaj instalatory w przypadku, gdy jest to możliwe, dzięki czemu operacja wdrażania nie będzie ręczna. Wiele pól w systemie raportowania ze śledzenia błędów jest wymaganych i rzadko używanych.Czas zużyty na tworzenie danych dla tych pól można oszczędzić, czyniąc je opcjonalne.

Uzbrojony w te listy, Scrum Masterzy przychodzą do swoich odpowiednich zespołów scrumowych z praktycznymi sugestiami umożliwiającymi natychmiastową poprawę.Chociaż Scrum Masterzy prowadzą zespoły do wyższych poziomów jakości, samoorganizacyjny charakter zespołów Scrum wymaga, aby same zespoły ustalały wartość zmian i tworzyły plany ich wprowadzenia.

Retrospektywa sprintu jest wyspecjalizowanym forum dzielenia się pomysłami na poprawę i uzyskiwania pomocy, aby wcielić je w życie.Skuteczne retrospektywy sprintu często skutkują planami wprowadzenia ulepszeń, wspierając kulturę Kaizen.Wyeliminowanie lub ograniczenie strat śledzonych w zaległości może wymagać pracy poza zespołem scrumowym.Jest to odpowiedzialność Mistrza Scrum, którego obowiązki obejmują doskonalenie wykorzystywania Scrum i zachęcanie pracowników organizacji do wykazywania się sprawnością.

Ograniczanie pracy w toku

Scenariusz

Zespół programistyczny mający pięciu członków używa metody Scrum od 12 tygodni, wykonując trzy czterotygodniowe sprinty z mieszanymi wynikami.Chociaż jakość produkowanych przyrostów jest wyższa niż wcześniej utworzonego oprogramowania do implementowania Scrum, wydaje się, że wykonano mniej pracy, a członkowie zespołu programistycznego nadal nie działają wspólnie.Scrum dzienny zawiera dzienne przypomnienie, że każda osoba w zespole pracuje nad własnymi zadaniami w izolacji, aż do momentu, gdy sytuacja nie będzie ulegać poprawie.

Podczas planowania sprintu zespół programistyczny tworzy listę „Do wykonania” dla prac wymaganych w celu dostarczenia każdego elementu zaległości produktu wybranego dla sprintu.Ta technika tworzy zaległość sprintu podczas planowania sprintu oraz mechanizm śledzenia postępu prac zespołu programistycznego przez cały sprint.

Zespół projektowy korzysta z graficznej tablicy zadań na ścianie swojego miejsca pracy, aby śledzić postęp całego sprintu.Podczas ostatniego sprintu Scrum Master robił zdjęcia tablicy każdego dnia przed scrumem dziennym.Poniżej przedstawiono kilka zdjęć.

Dzień 1	Dzień 4
Dzień 9	Dzień 14
Dzień 17	Dzień 20

Mistrz Scrum udostępnił zespołowi te zdjęcia.Niektóre rzeczy były łatwo zauważalne, takie jak:

• Więcej zadań jest regularnie w toku niż członków w zespole programistycznym.

• W dniu drugim deweloper przeciągnął wszystkie zadania dla funkcji C do stanu „W toku” i pozostawił je tam na czas trwania sprintu.

• Nad funkcją B nie pracowano aż do końca sprintu i nie została ona ukończona.

• Nad funkcją C pracowano przez cały sprint, ale nie została ukończona.Deweloper pracujący nad funkcją C był sfrustrowany brakiem pomocy w przypadku występienia nieznanych problemów.Pomimo subtelnych podpowiedzi w dziennych scrumach, że chętnie skorzysta z pewnej pomocy, nigdy jej nie otrzymała, ponieważ pozostali członkowie zespołu koncentrowali się na własnej pracy i nie czuli odpowiedzialni za funkcję C.

• Funkcje zostały umieszczone w zaległości sprintu w kolejności priorytetów podczas planowania sprintu i właściciel produktu był bardzo rozczarowany, że funkcja B nie została ukończona w sprincie, ponieważ była w hierarchii wyżej niż inne funkcje, które zostały dostarczone.

• Kilka funkcji było jednocześnie w toku, powodując wystąpienie zmian w bardzo różnych częściach kodu jednocześnie.Podczas sprintu doprowadziło to do kilku błędów kompilacji i przeróbek, ponieważ deweloperzy nieświadomie wpłynęli wzajemnie na swój kod.

Wszystkie te spostrzeżenia ponownie wskazują na skłonność zespołu programistycznego do pracy nad wieloma rzeczami naraz.Dzielenie uwagi pomiędzy kilka zadań i próba skupienia się na wielu elementach jednocześnie powoduje, że członkowie zespołu programistycznego czują się przeciążeni i przytłoczeni pracą w Zaległości sprintu.W związku z tym każdy członek zespołu koncentrował się na własnej pracy i działał jako osoba, a nie jako członek zespołu.

Podejście odchudzone

Podczas retrospektywy sprintu Scrum Master wyjaśnił pomysł ograniczenia PWT do zespołu programistycznego, który zdecydował się wypróbować tę technikę.Zespół zdecydował się na wprwadzanie trzech nowych reguł w celu zmniejszenia PWT w następnym sprincie:

1. Funkcje w zaległości sprintu są implementowane w kolejności od góry do dołu.

2. Nie więcej niż 3 elementy mogą być jednocześnie w toku.Jeśli czwarty element jest umieszczany w toku, zespół zatrzyma się w celu ustalenia, dlaczego występuje wąskie gardło w systemie.

Mistrz Scrum robił zdjęcia ponownie w trakcie następnego Sprintu.Kilka zdjęć jest przedstawionych poniżej.

Dzień 2	Dzień 8
Dzień 12	Dzień 20

Podczas retrospektywy sprintu zdjęcia zostały ponownie udostępnione zespołowi programistycznemu, który dokonał następujących spostrzeżeń dotyczących sposobu zmiany rzeczy dla nich w tym najnowszym sprincie:

1. Członkowie zespołu programistycznego pracowali razem nad bardziej złożonymi elementami.Chociaż opinie różniły się czasem na temat sposobu wykonania pracy, różnice zostały rozwiązane i zespół notował szybsze ogólne postępy.

2. Członkowie zespołu programistycznego zaczęli dowiadywać się o funkcjach produktu, na których wcześniej się nie skupiali.Wszyscy informowali o poczuciu zbiorowej odpowiedzialności za produkt jako całość.Była to ogromna ulga w porównaniu z poprzednimi praktykami członków zespołu skupiających się tylko na funkcjach, które rozumieli.

3. Złożoność koordynacji zmian w wielu różnych obszarach kodu naraz została znacznie obniżona.Do tego stopnia, że wydajność pracy zespołu programistycznego znacznie wzrosła.

4. Mimo że funkcja E nie została ukończona w ramach sprintu, wszystkie funkcje, które zostały dostarczone, miały wyższy priorytet niż funkcja E.Właściciel produktu był zachwycony i postanowił wysłać przyrost do klienta, nawet bez tej funkcji z niskim priorytetem.

Chociaż tworzenie zaległości sprintu podczas planowania sprintu ogranicza rozmiar partii pracy wybranej dla sprintu, dalsze ograniczanie PWT w ramach sprintu może prowadzić do większego przerobu i wyższej wydajności.Ograniczenie PWT podczas sprintu również zwiększa współpracę i zmniejsza ryzyko angażowania technicznych specjalistów, których praca nie jest zrozumiana przez innych użytkowników.

Zmniejszenie czasu oczekiwania

Mnóstwo czasu pochłania oczekiwanie na różne wydarzenia w procesie tworzenia oprogramowania.Ten rodzaj strat często można spotkać w większości zespołów programistycznych.Nowe zespoły scrumowe często czekają na wiele rzeczy podczas sprintu, włączając:

• Uprawnienie do czegoś

• Długi proces do wykonania

• Materiał przekazany przez inny zespól lub osobę

• Testy, które mają zostać uruchomione lub walidacja, która ma zostać ukończona

• Dostęp do potrzebnego zasobu

• Współpraca osób spoza zespołu

Gorsze niż nieefektywność oczekiwania zespołów Scrum jest oczekiwanie przez klientów i firmy na zintegrowanie, zapakowanie i dostarczenie oprogramowania.Ten problem zwiększa się wraz z rozwojem organizacji.Jak więcej deweloperów lub zespołów jest dodawanych do projektu, zwiększa się koszt integrowania ich pracy w jeden produkt.

Najdłuższy czas oczekiwania na kompilację w Scrum to sprint.To kontener dla wszystkich zdarzeń Scrum. Jedynym wymaganiem dla czasu trwania sprintu jest to, aby trwał on jeden miesiąc lub mniej.Skraca to do miesiąca czas oczekiwania na działający przyrost oprogramowania.Większość zespołów scrumowych dostarcza działające przyrosty nawet częściej.

Scenariusz

Firma ma sześć zespołów scrumowych pracujących nad dużymi i skomplikowanymi programami.Każdy zespół scrumowy koncentruje się na określonym obszarze funkcji i praca jest koordynowana poprzez główną zaległość produktu.Sprinty zazwyczaj trwają trzy tygodnie i dotyczą integracji pracy zespołów programistycznych.

Wcześniej sprinty trwały dwa tygodnie, ale wraz z rozwojem produktu wzrosła złożoność jego tworzenia.Dodano nowe zespoły scrumowe, które potrzebowały więcej czasu na zintegrowanie ich pracy, w związku z czym długość sprintów została zwiększona w celu uwzględnienia działań integracyjnych.

Trzeci tydzień teraz jest potocznie znany jako tydzień integracji.Integracja nowych funkcji do wiersza głównego kodu jest podstawowym działaniem w tym czasie.Ustanawia się zespół integracyjny w każdym tygodniu integracji z przedstawicielami każdego zespołu programistycznego.Kierują pracą działań integracyjnych.

Zespół integracji nie akceptuje nowych funkcji podczas tygodnia integracji, oprócz żądania niewielkich zmian w celu rozwiązania problemów z integracją.Powoduje to gwałtowny wzrost natychmiastowych zmian w kodzie podczas Tygodnia integracji, zgodnie z potrzebami zespołu integracyjnego.

Na poniższym rysunku przedstawiono zarządzanie typową konfiguracją podczas sprintu.Zespoły programistyczne tworzą własne wersje rozwojowe na początku każdego sprintu.Na koniec tygodnia 2 scalają swój kod.W tygodniu 3 zespoły programistyczne obsługują w razie potrzeby żądania zespołu integracyjnego.

Chociaż integracja podczas sprintu jest niezbędna, jedna trzecia wydajności sześciu zespołów Scrum jest aktualnie wykorzystywana do wykonywania integracji.W tym czasie duża część możliwości zespołów jest poświęcana na działania poza sprintem.Należy zauważyć, że w przykładzie powyżej zespół 5 nie miał żadnej pracy w tygodniu integracji.

Zwiększenie kosztów tygodnia integracji jest zakłóceniem przepływu w zespołach scrumowych, który często muszą zmieniać kontekst.Niektóre zespóły rozgałęziają i rozwidlają wiersze kodów w ukryciu, aby utrzymać produktywność w ciągu tygodnia, co powoduje komplikacje i przeciwdziała przezroczystości niezbędnej do podejmowania odpowiednich decyzji.

Podejście odchudzone

Mistrzowie Scrum określonych zespołów spotykają cię w celu omówienia opcji.Scrum Master twierdzi, że jej zespołowi udało się ograniczyć PWT podczas pierwszych dwóch tygodni każdego sprintu.Mistrzowie Scrum widzą, że jeśli każdy zespół ograniczy PWT do jednej funkcji w danym momencie, może to potencjalnie integrować pracę zespołu po zakończeniu każdej funkcji.

Jeśli ta praktyka byłaby wykorzystana przez wszystkie zespoły programistyczne, żaden zespół nie musiałby czekać do końca drugiego tygodnia na zintegrowanie swojej pracy.Zamiast czekać na zintegrowanie nowych funkcji, każdy zespół może teraz rozważyć integrację z częścią wiersza głównego kodu definicji ProduktGotowy1 dla każdej funkcji, na której pracuje.

Definicja produktu gotowego to koncepcja w Scrum, w którym zespoły projektowe uzgadniają warunki, które muszą być spełnione dla każdego elementu listy zaległości produktu wybranych dla sprintu, aby można było uznać element zaległości produktu za „gotowy”.Więcej informacji na temat definicji produktu gotowego — zobacz artykuł w witrynie MSDN Gotowe i cofnięte.

Podczas następnych retrospektyw sprintu zespoły programistyczne postanawiają spróbować integrować swoje prace wraz z kończeniem każdej funkcji.Ustanawiają i zatwierdzają następujące nowe zasady:

1. Każdy zespół programistyczny ogranicza PWT do jednej funkcji naraz.

2. Funkcja nie jest ukończona, dopóki nie zostanie umieszczona w wierszu głównego kodu.

3. Przed rozpoczęciem pracy nad nową funkcją zespół programistyczny zaktualizuje wiersze kodu o świeżą kopię głównego wiersza.

Działanie wynikowe jest przedstawione na poniższym rysunku:

Nowe reguły spowodowały, że zespoły płynniej dostarczają nowe funkcje.Zespoły programistyczne nie muszą już siedzieć bezczynnie i nie doznają zakłócania pracy w trzecim tygodniu sprintu, ponieważ nie ma tygodnia integracji.

Czas na zintegrowanie zmian podczas sprintu jest na początku dłuższy, ale wraz z zapoznawaniem się z modelem ciągłej integracji, zwiększa wydajność każdego zespołu projektowego.Z czasem funkcje dodane do każdego sprintu będą się zwiększać.

Ponieważ gotowość funkcji teraz oznacza, że funkcja jest zintegrowana z wierszem głównego kodu, nie ma już żadnych pytań, czy funkcja jest naprawdę gotowa.Definicja produktu gotowego uwzględnia obecnie integrację głównego kodu wszystkich poszczególnych funkcji.Znacznie zmniejszyło się ryzyko niepowodzenia integracji.

Wreszcie decyzja o skróceniu czasu, przez jaki zespół programistyczny musi czekać na zintegrowanie kodu, zwiększyła ogólną wydajność pracy zespołów programistycznych i usunęła potrzebę tygodnia integracji.Zespoły scrumowe mogą wrócić do krótszych sprintów, umożliwiając właścicielowi produktu nawet częstszą dostawę (stosownie do sytuacji).

Odraczanie przyjęcia zobowiązania

Odroczenie przyjęcia zobowiązania jest jedną z oryginalnych zasad metodyki odchudzonej wyrażonej jako wartość w metodyce odchudzonego tworzenia oprogramowania.Zasada ta jest często nazywana „czekaniem do ostatniej rozsądnej chwili” z podjęciem decyzji.

Nie wartości lub jest ona mała w podejmowaniu decyzji, która przedwcześnie wymusza plan działania — tak głosi zasada.Dlaczego nie zaczekać, aż decyzja będzie musiała być podjęta i będą znane najbardziej możliwe informacje o problemie?Ogranicza to ryzyko podejmowania niewłaściwych decyzji i daje czas na jeszcze większą ilość opcji lub ścieżek działania do powierzchni.

Scenariusz

Podczas planowania sprintu zespół programistyczny tworzy szczegółowe plany wdrożenia elementów zaległości produktu wybranych dla sprintu.Często plan zmienia się podczas sprintu wraz z pozyskiwaniem kolejnych informacji.Zauważyły, że jeśli praca jest mniej oczywista, plan zmienia się jeszcze bardziej.Wiedząc, że niewykorzystane wymagania są stratami, zespół chce uniknąć tych przeróbek planu.

Zobowiązanie się do jednego kierunku działania wymaga odrzucenia innych opcji.Często powoduje to, że osoby świadome zobowiązań odrzucają pomysły.Może być kilka sposobów implementowania danej funkcji, ale gdy określony plan działania został już podjęty, programiści mogą przestać brać pod uwagę inne sposoby rozwiązania problemu, gdyż powoduje to spadek potencjału innowacyjnego.

Podejście odchudzone

Zespół projektowy postanawia zezwolić większe i mniej określone elementy w dzienniku sprintu.W rzeczywistości decydują, że element zaległości produktu może zostać zaakceptowany do sprintu w ogóle bez szczegółowego planu.

Zespół projektowy czeka teraz na więcej szczegółów, aby można było później utworzyć szczegółowy plan.Dla nich oznacza to dzielenie dużego elementu zaległości sprintu na mniejsze kawałki, gdy pracę faktycznie się rozpoczyna lub jest w toku.Powoduje to odroczenie szczegółowego planowania do czasu, kiedy jest faktycznie potrzebne i pozwala zespołowi na zmianę zdania co do wdrożenia bliżej punktu pracy.Zapewnia również używanie najlepszego możliwego planu zamiast wykonywania planu, który może nie być już prawidłowy.

Efektem jest lepsze zrozumienie opcji implementacji, gdy nadejdzie czas zaimplementowania funkcji.Zespół projektowy dowiedział się więcej na temat produktu w czasie wdrażana poprzednich funkcji w sprincie i w razie potrzeby był czas na analizę.

Wizualizacja przepływu pracy

Pierwszy krok w metodzie Kanban wymaga wizualizacji przepływu pracy rzeczywistej używanej przez zespół.To realizuje zasadę „widzenia całości” metodyki odchudzonej i wymaga, aby był wyświetlany rzeczywisty przepływ pracy, a nie wyidealizowana wersja przypisana przez dokument procesu biznesowego lub inny istniejący model.Przydatna wizualizacja reprezentuje to, co faktycznie się dzieje.

Gdy istnieje wizualizacja pracy, można za jej pomocą śledzić pracę.Przykładowy model typowego procesu tworzenia etapowego (kaskadowego) przedstawiono poniżej, z kilkoma funkcjami w toku.

Zespoły Scrum korzystają z wizualizacji przepływu pracy dla lat, aby poznać działanie Sprintu.Najczęstszą formą wizualizacji przepływu pracy w zespołach projektowych Scrum to „tablica zadań” lub po prostu „tablica Scrum”.Ta wizualizacja jest zwykle prostsza niż model przedstawiony powyżej i może wyglądać podobnie do następującego modelu.

Ta typowa forma wizualizacji przepływu pracy jest silnie zależna od stosowania metody Scrum przez interdyscyplinarne zespoły programistyczne.Skupienie się na interdyscyplinarnych zespołach programistycznych jest cechą definiującą środowiska Scrum.Interdyscyplinarny zespół ma wszystkie kompetencje potrzebne do dostarczania wszystkich przyrostów działającego oprogramowania w każdym sprincie.Członkowie zespołu wykonują jednocześnie wiele działań związanych z projektowaniem oprogramowania.

Zespoły interdyscyplinarne mogą zrobić nieco wszystkiego naraz, gdy wdrażają razem jedną z funkcji.Różni się to w znacznym stopniu od modelu opierającego się głownie na planie, w którym to specjaliści skupiają się na wykonywaniu tylko jednej czynności w danym czasie.Ponadto członkowie zespołów interdyscyplinarnych mogą mieć specjalizacje, ale wszyscy członkowie zespołu regularnie pracują nad wszystkimi działaniami niezbędnymi do dostarczania oprogramowania, niezależnie od tego, czy działania te są w obszarze ich specjalizacji.Interdyscyplinarne zespoły deweloperów oprogramowania zwykle działają lepiej niż zespoły specjalistów dedykowanych.

Scenariusz

Zespół programistyczny dostarcza przyrosty działającego oprogramowania, ale członkowie zespołu nie współpracują dobrze.Programiści pracują na problemami w izolacji, zanim przekażą kod testerom, którzy muszą szybko dokonać walidacji pod koniec sprintu.

Pozostawia to niewiele czasu na końcu Sprintu na przeprowadzenie testów, zatem zespół czasami pomija ten krok i dostarcza przyrostu, w którym testowanie regresywne nie zostało ukończone.Stwierdza się wady w produkcji, które byłyby stwierdzone wcześniej, gdyby pozwolono na dokończenie testów regresji funkcjonalnej.

Podejście odchudzone

Mistrz Scrum współpracuje z zespołem, aby stworzyć model rzeczywistego przepływu pracy, występującego w ramach każdego sprintu.Mimo że zespół korzysta z typowej tablicy scrumowej podczas scrumu dziennego, szybko staje się jasne, że rzeczywisty przepływ pracy jest procesem etapowym.Zespół tworzy następujące model, aby odzwierciedlał rzeczywisty przepływ pracy:

Mistrz Scrum pomaga zespołowi zrozumieć możliwości wzrostu produktywności, zdobyte przez pracę w sposób oparty na współzależności funkcjonalnej.Chociaż mają wątpliwości, członkowie zespołu postanawiają spróbować poprawić ich przepływ pracy, tak aby był bardziej interdyscyplinarny.

Zespół projektowy pozostawia wizualicację nienaruszoną i używa jej do monitorowania pracy w sprincie, ale szuka każdej możliwej okazji do zwinięcia etapów.Oznacza to, że zespół szuka możliwości połączenia dwóch etapów w jeden, a więc zastąpienia przekazywania współpracą.Robią to w określonym stopniu w danym momencie, wprowadzając zamierzone zmiany w procesie współpracy osób w ramach zespołu projektowego.W każdej retrospektywie sprintu poprawiają oni model w celu odzwierciedlenia ulepszeń dokonanych przez zespół.

Po pierwsze Arnie i Kyle zgadzają się współpracować nad scalaniem faz projektowania i tworzenia kodu.Próbują różnych technik w celu poprawy współpracy i szybko dowiadują się, że ich przepływ pracy zmienił następujące elementy:

Zespół ten szybko dowiaduje się o tworzeniu testów regresji funkcjonalnej przed wprowadzeniem w życie kodu, co powoduje następujące zmiany:

Przez kilka następnych miesięcy zespół programistyczny będzie szukał możliwości zmniejszenia liczby etapów planowanej dostawy.Kultura zespołu faktycznie zmienia się, gdy specjaliści dzielą się swoją wiedzą, a wszystkim zależy na uzyskaniu płynniejszej pracy w zespole.Członkowie zespołu, w miarę rozwijania współpracy, zaczynają uważać się za „specjalistów znających się na wszystkim”.

Wzrost współpracy w zespole powoduje wzrost zbiorowej wiedzy na temat tworzonego oprogramowania i rozeznania członków zespołu co do obowiązków współpracowników.Ta współpraca naturalnie powoduje załamanie się etapów pracy podczas Sprintu i znajduje odzwierciedlenie w prostszej wizualizacji przepływu pracy, który występuje w ramach Sprintu.Zespół projektowy jest obecnie uniwersalny i postrzega rzeczywisty przepływ pracy, tak jak to pokazano poniżej.

Powtarzające się analizowanie przez zespół etapów procesu eliminacji ostatecznie doprowadziło do przepływu pracy, który Scrum zaleca w pierwszej kolejności, pojedynczej fazy opracowywania w toku.Pokazuje to, jak w pełni zoptymalizowana tablica metody Kanban ostatecznie okazuje się być tradycyjną tablicą metody Scrum.

Wbudowywanie integralności

Wiele technik tworzenia oprogramowania skupia się na wbudowaniu integralności w proces tworzenia.Wzorce projektowe oprogramowania, techniki programowania z testowaniem na pierwszych etapach, refaktoryzacja oraz programowanie w parach służą podnoszeniu jakości oprogramowania w chwili jego tworzenia.Używanie technik, które zwiększają jakość na wczesnym etapie procesu tworzenia gwarantuje, że zespoły nie muszą polegać na kontroli jakości po fakcie zgodnie z zasadą „jakość sprawdzimy później”.

Scenariusz

Zespół programistyczny eksperymentował z technikami programowania przewidującymi testowanie już na pierwszych etapach. Pomyślnie używa wyrażenia kryteriów akceptacji Zakładając/Jeśli/To w testach jednostkowych przygotowywanych przez deweloperów podczas tworzenia aplikacji.

Format kryteriów akceptacji Zakładając/Jeśli/To
Zakładając <pewien kontekst początkowy> Gdy <występują pewne akcje> W takim przypadku < to jest wynikiem >

Zespół ma dobre, czytelne pakiety testów jednostkowych. Deweloperzy liczą, że pakiety te zostaną wykorzystane do poprowadzenia ich projektu i częstego testowania kodu przy zautomatyzowanym wykorzystaniu testów.

Chociaż ta metoda działa na poziomie testów jednostkowych, specjaliści ds. testowania w zespole programistycznym nadal używają dokumentów programu Microsoft Word do tworzenia kryteriów akceptacji dla testów funkcjonalnych.Zostały one zweryfikowane ręcznie po zakodowaniu i skończeniu funkcji.Ponieważ testy te nie są uruchomiane, aż programistom wydaje się, że funkcja jest zakończona, ci specjaliści ds. testowania znajdują znaczną liczbę usterek.Powoduje to przeróbki w ramach Sprintu, a czasami prowadzi do sytuacji, w których funkcje nie są ukończone przed przeglądem Sprintu.

Podejście odchudzone

Dyskutując przepływ pracy kryteriów akceptacji w retrospektywie sprintu, zespół programistyczny postanawia wykonać następujące czynności:

1. Specjaliści zajmujący się testami utworzą kryteria akceptacji nie jako dokumenty Microsoft Word, ale jako zautomatyzowane testy wad, które nie mają wewnętrznej implementacji.

2. Nowe testy automatyczne będą uruchamiane codziennie o 5:00 i 15:00, tworząc raport z wynikami prawidłowymi i nieprawidłowymi.Nowo utworzone testy zawsze kończą się niepowodzeniem.

3. Po wybraniu nowej funkcji do opracowania programiści zaczynają od zaimplementowania funkcji przyjęcia zastępczej klasy testowej.

4. Test może być udoskonalany przez koder, ale we współpracy ze specjalistą, który stworzył test, aby zachować pierwotne przeznaczenie testu.

5. Funkcja nie zostanie wykonana, dopóki test nie zakończy się pomyślnie.

6. Wszystkie testy muszą być zaliczone do końca sprintu.

Po kilku sprintach z użyciem tej technik spadła liczba wad i przeróbek.Zespół projektowy monitoruje raport, który jest aktualizowany dwa razy dziennie w wyniku uruchomienia testów automatycznych, oraz sprawdza, czy prawidłowe i nieprawidłowe wyniki testów tworzą trend.Zespół tworzy raport, który jest aktualizowany wraz z każdym automatycznym uruchomieniem testowym.Raport przedstawia prawidłowe i nieprawidłowe wyniki testu akceptacyjnego w trakcie dwutygodniowego sprintu.Wykres przedstawiony jest poniżej.

Zespół ustalił, że podczas dziennego scrumu większą wartość dla niego stanowi przeglądanie tego raportu niż typowego wykresu spalania (burndown).Mistrz Scrum potwierdza, że ten nowy wykres może służyć jako kluczowa część zaległości sprintu.

Przewodnik Scrum określa, że zaległości Sprint są podzbiorem elementów zaległości produktu wybranych do sprintu wraz z planem ich dostarczania.Dla tego zespołu programistycznego plan jest teraz budowany na podstawie nieudanych testów akceptacyjnych, i postęp w kierunku zakończenia jest śledzony przez ustalenie trendu liczby testów udanych i nieudanych.Tak jak z używaniem zadań w zaległości sprintu, testy mogą być dodawane, usuwane lub modyfikowane przez cały sprint.Utworzenie danego testu często prowadzi do implementacji odpowiedniej funkcji przez kilka dni.

Używanie teraz rzeczywistych zautomatyzowanych testów jako wymogów i mechanizmu regresji funkcjonalnej oznacza, że testy są wymaganiami.Umożliwia to również postrzeganie pracy w Sprintach jako postęp automatycznego zatwierdzania testów.Ta technika programowania z testowaniem na pierwszych etapach ma ponownie zdefiniować sposób myślenia zespołu o użyciu metody Scrum i powoduje, że wymóg walidacji wymagań jest uwzględniony w samym procesie tworzenia, w ten sposób wbudowując integralność w produkt.

Wiele aspektów ogromnie popularnej środowiska Scrum wspiera zasady metodyki odchudzonej.Gdy zespoły scrumowe dojrzewają i się poprawiają, często stwierdzają, że metoda odchudzonego myślenia jest skutecznym narzędziem do znajdowania większej wartości w tworzeniu iteracyjnym i przyrostowym.

Chociaż określone techniki przychodzą i odchodzą, ciągłe zwracanie uwagi na ulepszanie ma istotne znaczenie dla utrzymania w dobrej kondycji zespołów projektujących oprogramowanie.Struktura Scrum jest wystarczająco elastyczna, aby pomieścić metody poprawy oparte na metodyce szczupłego zarządzania, podobnie jak w Kanban.Wyświetlanie Scrum przez obiektyw metodyki odchudzonego myślenia często prowadzi do lepszej jakości, większej produktywności i zmniejszenia odpadów.

Celowa optymalizacja wdrożenia metodyki Scrum w zespole może być kłopotliwa.Podczas poszukiwania sposobów poprawy nie pozwól, aby doskonałe było wrogiem wystarczająco dobrego.Doskonałość Scrum jest znacznie mniej istotna niż dostarczanie działającego oprogramowania wysokiej jakości cenionego przez klientów, więc należy skupiać się najpierw na rzeczach, które rzeczywiście usprawniają produkt.

Odniesienia

1. West, D.(2011).XXXXX.Forrester Research

2. Poppendieck M.P.(2003).Lean Software Development: An Agile Toolkit.Addison-Wesley Professional.

3. Anderson, D.(2010).Kanban — Successful Evolutionary Change for your Technology Business.Blue Hole Press.