Lean Software Development: Różnice pomiędzy wersjami
m (Dodanie TL;DR) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 14 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''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 [[adaptacyjne zarządzanie projektami|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. | |||
Odchudzone wytwarzanie oprogramowania jest adaptacją Systemu Produkcyjnego Toyoty dla środowiska informatycznego i opiera się na wartościach i zasadach [[adaptacyjne zarządzanie projektami|adaptacyjnego zarządzania projektami]]. Za twórców określenia "Lean software | |||
==TL;DR== | ==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. | 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 == | ==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. | 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 " | 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. | 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 == | <google>n</google> | ||
==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. | 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''). | * '''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. | '''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. | ||
<center><table border="1"> | <center><table border="1"> | ||
<tr> | <tr> | ||
| Linia 70: | Linia 54: | ||
</table></center> | </table></center> | ||
Idea '''eliminacji strat''' opiera się o zrozumienie [[potrzeba|potrzeb]] klienta i dostarczenie mu rozwiązania realizującego dokładnie te [[potrzeby]], jak najszybciej. Każdy czynnik opóźniający pracę jest marnotrawstwem. | Idea '''eliminacji strat''' opiera się o zrozumienie [[potrzeba|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''). | * '''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 | 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'') | * '''Opóźnianie decyzji''' (ang. ''decide as late as possible'') | ||
Tworzenie oprogramowania zawsze związane jest z [[niepewność|niepewnością]] i [[ryzyko|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. | Tworzenie oprogramowania zawsze związane jest z [[niepewność|niepewnością]] i [[ryzyko|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''). | * '''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. | 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''). | * '''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 " | 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 [[Zadanie, uprawnienie, odpowiedzialność|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''). | * '''Zapewnienie spójności''' (ang. ''build integrity in''). | ||
Spójność rozumiana jest, jako zgodność oprogramowania z [[Wymaganie, potrzeba, oczekiwanie|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. | Spójność rozumiana jest, jako zgodność oprogramowania z [[Wymaganie, potrzeba, oczekiwanie|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'') | * '''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. | [[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. | ||
== | {{infobox5|list1={{i5link|a=[[Metodyka Extreme Programming]]}} — {{i5link|a=[[Jidoka]]}} — {{i5link|a=[[Large-scale scrum]]}} — {{i5link|a=[[DevOps]]}} — {{i5link|a=[[Lean Enterprise]]}} — {{i5link|a=[[Inżynieria oprogramowania]]}} — {{i5link|a=[[Lean Six Sigma]]}} — {{i5link|a=[[Komputerowo zintegrowane wytwarzanie]]}} — {{i5link|a=[[Feature-Driven Development]]}} }} | ||
==Bibliografia== | |||
* Ebert C. Abrahamsson P. Oza N., Lean software Development, IEE | <noautolinks> | ||
* Lisiecka K., Burka I., Koncepcja | * Ebert C., Abrahamsson P., Oza N. (2012), ''Lean software Development'', IEE Software | ||
* Poppendieck M., Lean Development and the Predictability Paradox, Cutter Consortium | * Lisiecka K., Burka I. (2011), ''Koncepcja Lean Management i kierunki jej rozwoju'', Problemy Jakości, nr 6 | ||
* Poppendieck M., Poppendieck T. Lean Software Development: An Agile Toolkit, Addison Wesley | * Poppendieck M. (2003), ''Lean Development and the Predictability Paradox'', Cutter Consortium | ||
* Svitis C.(2013), [https://gupea.ub.gu.se/handle/2077/38521 Lean Software Development], University of Gothenburg | * Poppendieck M., Poppendieck T. (2003), ''Lean Software Development: An Agile Toolkit'', Addison Wesley | ||
* Svitis C. (2013), ''[https://gupea.ub.gu.se/handle/2077/38521 Lean Software Development]'', BA thesis, University of Gothenburg | |||
</noautolinks> | |||
[[Kategoria:Metodyki zarządzania projektami]] | [[Kategoria:Metodyki zarządzania projektami]] | ||
{{a|Mariusz Szpyt, Szczepan Konik}} | {{a|Mariusz Szpyt, Szczepan Konik}} | ||
{{#metamaster:description|Lean software development - eliminacja strat i dostarczanie klientowi gotowego produktu. Adaptacja Systemu Produkcyjnego Toyoty dla IT.}} | |||
Aktualna wersja na dzień 22:25, 14 sty 2024
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
