7 marnotrawstw w tworzeniu oprogramowania Lean i jak im zapobiegać

Myślenie oparte na szczupłych procesach stawia na pierwszym miejscu eliminowanie i ograniczanie kompilacji odpadów. Pomimo „szczupłego” podejścia przyjętego przez duże firmy, niektóre standardowe praktyki „odpadów” utrzymują się ze względu na ich „oczywisty charakter”. Natura głęboko zakorzeniona w ludzkich i organizacyjnych praktykach jest uparta, dopóki nie przyjmie się surowego podejścia.

Co to są odpady?

Wszystko, co wymaga zasobów/czasu lub wysiłku, ale nie daje odpowiednich wyników w zakresie wydajności lub ponoszenia przychodów, jest określane jako „odpady”.

Ostatecznie procedura „redukcji odpadów” jest zaprojektowana i prowadzona w celu zwiększenia produktywności zespołu i wyników.

Jednak teraz, gdy rozwój oprogramowania Lean jest prekursorem zwinności, możemy zastosować te siedem zasad redukcji odpadów w zakresie inżynierii i rozwoju oprogramowania, aby zapewnić efektywne produkty i usługi, obniżyć koszty i skrócić czas wprowadzania produktu na rynek.

1. Częściowo wykonana praca

Jeśli poprzednia praca nigdy nie zostanie wznowiona, wysiłek ten był marnotrawstwem.

Wszelkie prace do czasu ukończenia/zakończenia nie zwiększają propozycji wartości klienta; w ten sposób marnuje czas i wyzwania związane z utrzymaniem kodu, jeśli zostanie zawieszony.

Współczesnym przykładem jest sytuacja, gdy klient wymaga modyfikacji lub dodatkowych funkcji produktu. Firma jest zobowiązana do pilnego ich wykończenia; zespół programistów musi przerwać trwające prace i działać zgodnie z wymaganiami. Na tej samej stronie, jeśli poprzednia praca nigdy nie zostanie wznowiona, jest to strata wysiłku.

lub

Dokumentacja niekodowana: wymagania są szczegółowo opisane, ale nigdy nie zostały zaimplementowane.

Jak zmniejszyć to marnotrawstwo?

• Należy skupić się na „zakończeniu”, a nie tylko na „rozpoczęciu” projektu.
• Skróć czasy pracy w toku.
• Odciąć oczekiwanie na szczegółową specyfikację każdego wymagania, aż zespół będzie gotowy do wdrożenia wysiłków (wtedy nie będzie to przegrana sprawa).

2. Dodatkowe procesy

Każdy dodany proces lub nieprzeczytana dokumentacja, która nie przekazuje praktycznej wartości i niepotrzebnie wydłuża czas wprowadzenia produktu na rynek lub osiągnięcie, jest marnotrawstwem.

Jednak zasady biznesowe często nakazują takie dokumenty, z dużą ilością papierkowej roboty, ale nigdy ich nie przeczytano. Te wysiłki są ekstrawaganckie.

Typowe przykłady:

• Niepotrzebne uszczegółowienie dokumentacji.
• Dodatkowe zarządzanie lub planowanie bez realizacji.

Jak to zmniejszyć?

Organizacje mogą odróżnić, co jest straconą przyczyną/wysiłkiem, a tym, co wnosi wartość do tabeli, należy skupić się na generowaniu znaczących wyników i ukierunkowaniu wysiłków na wykonanie większej pracy „jakościowej” poprzez ograniczenie pracy „ilościowej”.

3. Dodatkowe funkcje

Każda funkcja lub funkcje o niskiej wartości, które są dodawane dla/przez klienta, ale nie są o to proszone/nie przyczyniają się do wzrostu przychodów, to strata wysiłku.

Firmy popełniają ten błąd programistyczny, gdy dodają funkcje, które nie będą zbytnio wykorzystywane lub ćwiczone; ta nowa funkcja rzeczywiście jest bezczynna i zwiększa złożoność aplikacji.

Ważną rolę odgrywa zasada Software 80/20 – 80% użytkowników korzysta tylko z 20% jej funkcji. Dlatego należy skupić się na tym, aby te 20% funkcji było najwyższej klasy, aby zachować obecnych użytkowników.

Dodatkowe kody mają swoje wady:

• Zwiększa złożoność aplikacji.
• Może spowodować potencjalny punkt awarii aplikacji.
• Wymaga zbędnych działań następczych w zakresie śledzenia i konserwacji przez cały cykl życia produktu.

Jak zmniejszyć to marnotrawstwo?
Skoncentruj się na rozwoju iteracyjnym — co oznacza, że ​​podczas początkowego wydania produktu zbuduj solidne podstawowe funkcje, które definiują USP Twojej aplikacji.

Skoncentruj się na jego funkcjonalności i potwierdź uczenie się ciągłego rozwoju produktu. Ponadto buduj odpowiednie funkcje w oparciu o analizę rynku, zachowania konsumentów i informacje zwrotne.

4. Przełączanie zadań

Przypisywanie ludzi do wielu zadań, gdy nie czują się z tym komfortowo i utrudnia ich istniejący proces, może zająć ogromną ilość ich dni. Najskuteczniejszym sposobem zakończenia konkretnego zadania lub dwóch jest kończenie jednego na raz.

Podczas przełączania się między zadaniami wiąże się z niewielkim kosztem zamknięcie istniejącego i nadanie rozpędu drugiemu, nazywa się to przełączaniem kontekstu. „wynik” lub „czas dostawy”.

Jak to zmniejszyć?

Proste — jedna rzecz na raz.

• Ogranicz przełączanie treści.
• Zminimalizuj przerwy lub czynniki rozpraszające.
• Odłóż te nieważne.
• Alokuj zasoby jako jeden projekt na raz.

5. Oczekiwanie/opóźnienia

Zależności dotyczące zatwierdzania powinny być ustalane w czasie przede wszystkim podczas planowania produktu; jeśli nie przydzielono określonego przedziału czasowego, przygotuj się na opóźnione odpowiedzi i informacje zwrotne. Opóźnienia również uniemożliwiają konsumentowi uświadomienie sobie rzeczywistej wartości produktu. Ale jako programiści lub projektanci musisz poczekać na zatwierdzenie wykonanej pracy; w ten sposób nie można całkowicie uniknąć upływu czasu.

Co możesz zrobić, aby to zmniejszyć?

• Wybierz/przypisz coś, czekając na istniejącą opinię.
• Przydziel czas na wprowadzanie i przeglądanie.
• Rozważ szybkie rozmowy telefoniczne, rozmowy twarzą w twarz zamiast wysyłania zmian e-mailem.
• Regularna informacja zwrotna.

6. Ruch

Jeśli zespoły programistyczne lub badawcze zostały rozproszone po zdobytych informacjach i nie oznaczyły ich/oznaczyły odpowiednio, może minąć wieczność, aby zamglić zamieszanie i wpaść. Jeśli informacje są niewłaściwie umieszczone za każdym razem, gdy dostarczany jest element dostawy; to drastycznie utrudni wyniki.

Jak to zmniejszyć?

• Przypisania etykiet lub pozyskane zasoby.
• Skróć czas przesyłania informacji zwrotnych.
• Współpraca twarzą w twarz.

7. Wada

Ilość odpadów spowodowana defektem = (Wpływ defektu) x (Czas, w którym pozostaje niewykryty)

Ze względu na swoją złożoność, tworzenie oprogramowania powoduje nieuniknione defekty, ale problem pojawia się, gdy ich wykonanie i naprawa się przedłuża lub koszty poniesione w związku z naprawą lub przeróbką. Ponadto poważne błędy i błędy kodu mogą potencjalnie wpływać na cały cykl życia produktu i utrudniać go, a także narażać go na zagrożenia bezpieczeństwa, powodując utratę milionów przychodów.

Co możesz zrobić, aby to zmniejszyć?

• Natychmiastowe testowanie.
• Stała integracja.
• Testowanie produktu i wydanie JAK NAJSZYBCIEJ.