Eliminowanie „Waste"

Jedną z zasad Lean jest eliminowanie „Waste" (pol.: marnotrawstwo). Koncepcja ta została zapoczątkowana w późnych latach 40. XX wieku w branży wytwórczej przez Toyotę. W tamtych czasach produkcja pojazdów była bardzo kosztowna i firmy musiały pobierać od klientów bardzo wysokie ceny. Jedynym sposobem Toyoty na obniżenie cen samochodów było zmniejszenie kosztów produkcji.

Co oznacza „Waste" w Lean?

„Waste" czyli „marnotrawstwo" jest w zasadzie przeciwieństwem „Value" (wartości), tzn. zdolności dostarczanej klientowi, dzięki której uzyskuje on bezpośrednią lub pośrednią korzyść. Na przykład spotkanie zespołu bez konkretnego powodu jest czystą stratą czasu.

Oto siedem rodzajów marnotrawstwa zidentyfikowanych przez Shigeo Shingo w Systemie Produkcyjnym Toyoty (TPS):

1. Zapasy: niedokończona produkcja (WIP: work in progress)

2. Nadprodukcja: produkowanie więcej niż wymaga popyt

3. Przetwarzanie: dodatkowe etapy w procesie, które nie są potrzebne

4. Transport: przewożenie towarów z jednego miejsca do drugiego

5. Oczekiwanie: przerwy między poszczególnymi etapami przetwarzania

6. Ruch: zbędne ruchy w procesie

7. Błędy: wady produktów wpływające na ich właściwości i funkcje

Jakie są rodzaje marnotrawstwa w tworzeniu oprogramowania?

Na podstawie siedmiu rodzajów marnotrawstwa w przemyśle wytwórczym Mary i Tom Poppendiek zdefiniowali siedem rodzajów marnotrawstwa w tworzeniu oprogramowania:

1. Niedokończona praca: W każdym Sprincie członkowie zespołu są odpowiedzialni za określoną liczbę User Stories. Czasami jednak nie udaje im się ukończyć wszystkich Stories. Muszą wtedy ustalić, dlaczego nie byli w stanie tego zrobić, aby zmniejszyć ten rodzaj marnotrawstwa.

2. Dodatkowe funkcje: Na początku Product Owner stworzył wizję, a następnie Product Backlog z priorytetyzowanymi funkcjami, które tworzą wartość dla produktu. Zasada Pareto mówi jednak, że często nie jest konieczne rozwijanie wszystkich funkcji, ponieważ wiele z nich jest bezużytecznych.

3. Uczenie się: W każdym Sprincie gromadzi się coraz więcej wiedzy, którą można wykorzystać, aby nie wymyślać koła na nowo.

4. Przekazywanie: Tutaj praca jest przekazywana innej osobie, gdy pierwsza skończy. Jak temu zaradzić? Najlepiej wyeliminować zależności między User Stories (i funkcjami) lub przekazać wszystkie User Stories z zależnościami jednemu zespołowi, aby ograniczyć ryzyko.

5. Opóźnienia: To wszystko, co opóźnia dostarczenie lub rozpoczęcie działania zwiększającego wartość. Jak temu zapobiec? Należy wyeliminować wąskie gardła i przeprojektować wszelkie powolne procesy, aby je zsynchronizować.

6. Przełączanie zadań: Zdarza się to, gdy Product Owner zmienia priorytety i członkowie zespołu muszą przechodzić z jednej User Story na inną, nie mogąc jej wcześniej ukończyć. Głównym powodem jest często brak jasnej wizji produktu u Product Ownera lub pojawienie się nowego produktu konkurenta na rynku, do którego chce się jak najszybciej dostosować własny produkt.

7. Błędy: To jeden z największych problemów w tworzeniu oprogramowania. Po pewnym czasie nagromadza się ogromna góra długu technicznego, a od tego momentu trzeba inwestować dużo czasu i wysiłku, aby Sprint po Sprincie powoli go redukować.

Podsumowując, mogę powiedzieć, że choć wiele osób uważa, że Lean nie jest dobrym podejściem dla zespołu pracującego z Agile, to się mylą. W rzeczywistości każda firma powinna najpierw zastosować Lean, a następnie przejść do Agile!!!

Tekst pochodzi z bloga Maria Lucero i został przez nas przetłumaczony.

Product Backlog Refinement

=> Tak przebiega Backlog Refinement w zespołach Scrum.

Jak przebiega Sprint Review w zwinnych zespołach?

=> Dowiedz się tutaj, jak może wyglądać idealna Sprint Review.