Lean Software Development

Lean software development - Tłumaczone, jako "odchudzone" zarządzanie lub "odchudzone" tworzenie oprogramowania. Podstawową myślą podejścia jest eliminacja strat - rozumianych, jako elementy niedodające produktowi żadnej wartości. Celem takiego działania jest jak najszybsze dostarczenie klientowi gotowego produktu.

Odchudzone wytwarzanie oprogramowania jest adaptacją Systemu Produkcyjnego Toyoty dla środowiska informatycznego i opiera się na wartościach i zasadach adaptacyjnego zarządzania projektami. Za twórców określenia "Lean software development" uważa się Mary Poppendieck i Toma Poppendiecka, którzy w swojej książce "Lean Software Development: An Agile Toolkit" przedstawili m.in. 7 głównych zasad odchudzonego zarządzania i zestaw 22 technik wspierających podejście.

TL;DR

Lean software development to podejście oparte na eliminowaniu strat w tworzeniu oprogramowania. Opiera się na 7 zasadach, takich jak eliminacja strat, wzmaganie procesu uczenia, opóźnianie decyzji, dostarczanie szybkich rezultatów, upoważnienie zespołu, zapewnienie spójności i spójne spojrzenie na całość. Celem jest dostarczenie klientowi wartościowego produktu jak najszybciej.

Stała Ewolucja

Znany autor Antoine de Saint-Exupery, zauważył, że w doskonałości nie chodzi o to, czy nic nie zostało do dodania, ale czy nic nie zostało do wycięcia. To stara mądrość z rozwoju oprogramowania, gdzie większość funkcji w każdym produkcie nie stanowi wartości dodanej produktu, a raczej generuje jedynie niepotrzebne koszty oraz złożoności, a zatem stopniowo pogarsza się produkt. Złożoność pierwszej przeglądarki Netscape wzrosła tak szybko, że firma nie była sobie w stanie z nią poradzić, przez co straciła ogromny udział w rynku oraz przodowanie w technologii w ostatnich latach. Podobny los spotkał platformę telefonów Nokia, Symbian 60, która została porzucona z powodu coraz trudniejszego wprowadzania innowacji do zbyt złożonego systemu.

W różnych branżach, gdzie niezależnie czy jest to celem ogólnym, IT lub oprogramowanie wbudowane, zawiera od 30 do 50 procent funkcji niepotrzebnych, dodawanych kompleksowo. Popyt na oszczędności zmusił przemysł oprogramowania do spojrzenia na metody "lean" w celu zastosowania ich do produkcji oprogramowania. Chociaż niektórzy twierdzą, że zasady z innych dziedzin nie mogą być stosowane do kreatywnej oraz zorientowanej na projekt dyscypliny, jaką jest tworzenie oprogramowania. Wiele badań dowiodło, że prosta wiedza, którą wszyscy pozyskujemy dzięki wzmocnionym oraz zmotywowanym zespołom, umożliwia tworzenie produktów szybciej oraz o lepszej jakości jeśli strategia rynkowa jest rozumiana oraz umożliwia zarządzanie wymaganiami zmian. Branża oprogramowania jest teraz gotowa do przekształcenia się w rozwój ukierunkowany na klienta, który dąży do redukcji kosztów, zwiększenia wydajności oraz skuteczności przy równoczesnej eliminacji marnotrawstwa i dodawaniu wartości.

Z perspektywy oprogramowania, droga do odchudzenia rozpoczęła się od zwinnych metod w kodowaniu. Przez ostatnią dekadę, większość firm wprowadziła zwinny rozwój w celu poprawy wydajności i skuteczności. Chociaż to ogromnie pomogło z rozwojem iteracyjnym oraz ukierunkowanym na użytkownika, jego stopień zastosowania korporacyjnego pozostawał w miejscu. Zbyt często zwinne praktyki były ograniczone do zespołów lub projektów, koncentrując się za bardzo na krótko-terminowości, ograniczaniu ich do zespołów lub projektów, redukcji dokumentacji oraz niepotrzebnych funkcjach, co później odbijało się negatywnie na kosztach. Lean software development próbuje wypełnić tę lukę. Gdy Mary i Tom Poppendieck pisali swoją pierwszą książkę na temat lean software development ponad 10 lat temu, była ona ściśle połączona ze zwinnym tworzeniem oprogramowania. Ostatnio znacznie więcej różnorodności zostało wprowadzonych przez potrzeby użytkownika oraz analizę przepływu pracy do ogólnego pomiaru wydajności.

Zasady i Cele

Lean software development opiera się na 7 podstawowych zasadach. Są to wytyczne, które wspomagają wypracowanie praktyk pasujących do konkretnych środowisk programistycznych.

• Eliminacja Strat (ang. eliminate waste).

Stratą lub marnotrawstwem jest wszystko, co w żaden sposób nie dodaje produktowi wartości rozumianej, jako wartość z punktu widzenia klienta (zob. Muda). W szczupłym myśleniu pojęcie straty jest niezwykle istotne. Jeśli program posiada niewymagane przez klienta funkcje, jest to strata. Stratą jest również przekazywanie pracy nad oprogramowaniem innemu zespołowi czy nadmierne testowanie. Poniżej przedstawiono czynniki generujące straty w przemyśle przełożone na straty w środowisku programistycznym.

Straty w przemyśle	Straty przy tworzeniu oprogramowania
Zapasy	Gotowe części kodu
Nadmierne przetwarzanie	Dodatkowe procesy
Nadprodukcja	Niepotrzebne funkcje
Transport	Zmienianie zadań
Oczekiwanie	Oczekiwanie
Zbędny ruch	Zbędny ruch
Błędy i wady jakościowe	Błędy i wady jakościowe

Idea eliminacji strat opiera się o zrozumienie potrzeb klienta i dostarczenie mu rozwiązania realizującego dokładnie te potrzeby, jak najszybciej. Każdy czynnik opóźniający pracę jest marnotrawstwem.

• Wzmaganie procesu uczenia (ang. amplify learning).

Rozwój i produkcja oprogramowania to proces wymagający ciągłego uczenia i dostosowywania do nowych wyzwań. Wspomaganie tych procesów znacznie poprawia wydajność pracy. Aby to osiągnąć można stosować krótkie cykle przyrostowe oprogramowania - w skład, których wchodzi integracja z dotychczasowym kodem i niezbędne testy, oraz konsultacje z klientem po każdym cyklu.

• Opóźnianie decyzji (ang. decide as late as possible)

Tworzenie oprogramowania zawsze związane jest z niepewnością i ryzykiem. Ich redukcji sprzyja podejmowanie decyzji oparte na faktach a nie spekulacjach, co w początkowych stadiach prac jest wręcz niemożliwe. Z tego powodu należy dążyć do podejmowania decyzji jak najpóźniej to możliwe posiadając już konkretne dane. Ważnym elementem realizowania tej zasady jest budowa systemu z myślą o jego otwartości na zmiany, w przeciwieństwie do dostarczania wielu niemodyfikowalnych części.

• Jak najszybsze rezultaty(ang. deliver as fast as posible).

Dostarczanie produktów jak najszybciej zapewnia, że klient otrzyma rozwiązanie którego potrzebuje, a nie którego potrzebował kiedyś. Idea opóźniania decyzji opiera się o podejmowanie szybkich decyzji bazując na dostępnej aktualnie wiedzy i wytwarzanie potrzebnej części oprogramowania. Bez szybkiego tempa dostarczania strategia traci na wartości. Pozwala ona również klientowi na bieżąco oceniać wdrożone funkcjonalności.

• Upoważniony zespół (ang. empower the team).

W związku z tym, że decyzje podejmowane są jak najpóźniej a wykonywanie poszczególnych elementów systemu następuje szybko, nie jest możliwe pełne kontrolowanie pracowników przez kierownictwo. Podejście "odchudzone" wspiera zasadę "znajdź dobrych ludzi i pozwól im pracować". Jej realizacja polega na przyznaniu odpowiednich uprawnień, codziennych spotkaniach, wyłapywaniu błędów oraz odstępstw od planu. Nie należy natomiast dążyć do kontrolowania każdej czynności pracownika.

• Zapewnienie spójności (ang. build integrity in).

Spójność rozumiana jest, jako zgodność oprogramowania z wymaganiami klienta oraz współdziałanie elementów systemu ze sobą. Ponadto program powinien zachowywać swoją użyteczność z biegiem czasu, a więc otwarty na modyfikacje.

• Spojrzenie całościowe (ang. see the whole)

Zasada ma na celu zwalczanie zjawiska suboptymalizacji. Rozbicie projektu na części i osobne mierzenie postępów każdego z nich może działać negatywnie na projekt. Nadmierne skupienie się na jednym elemencie powoduje jednocześnie zaniedbanie integralności systemu i przeszkadza w postrzeganiu go jako jednego produktu.

Lean Software Development — artykuły polecane

Metodyka Extreme Programming — Jidoka — Large-scale scrum — DevOps — Lean Enterprise — Inżynieria oprogramowania — Lean Six Sigma — Komputerowo zintegrowane wytwarzanie — Feature-Driven Development

Bibliografia

• Ebert C., Abrahamsson P., Oza N. (2012), Lean software Development, IEE Software
• Lisiecka K., Burka I. (2011), Koncepcja Lean Management i kierunki jej rozwoju, Problemy Jakości, nr 6
• Poppendieck M. (2003), Lean Development and the Predictability Paradox, Cutter Consortium
• Poppendieck M., Poppendieck T. (2003), Lean Software Development: An Agile Toolkit, Addison Wesley
• Svitis C. (2013), Lean Software Development, BA thesis, University of Gothenburg

Autor: Mariusz Szpyt, Szczepan Konik