Przejdź do zawartości

Lean software development

Z Wikipedii, wolnej encyklopedii
To jest stara wersja tej strony, edytowana przez ZéroBot (dyskusja | edycje) o 09:21, 19 kwi 2012. Może się ona znacząco różnić od aktualnej wersji.
Następująca wersja przejrzana tej strony, którą oznaczono 19 kwi 2012, była oparta na tej wersji.

Lean (Lean Software Development) – "Odchudzone" czy inaczej "wyszczuplone" zarządzanie (ang. lean management) nosi nazwę amerykańską, jednak rodowód jest w całości japoński. Odchudzone zarządzanie ma swe źródło w koncepcji odchudzonej produkcji (ang. Lean production), która została wymyślona i po raz pierwszy zastosowana w japońskim koncernie samochodowym Toyota, przez szefa produkcji tego koncernu Taiichi Ohno. Ta bardzo popularna koncepcja znalazła swoje zastosowanie także przy produkcji oprogramowania, znana jest pod nazwą Lean Software Development, a została zaadoptowana przez Mary Poppendieck i Toma Poppendiecka. W szczupłym wytwarzaniu oprogramowania wyróżnia się 7 zasad wspomaganych przez 22 narzędzia.

Siedem zasad Lean Software Development

Lean development może być podsumowane za pomocą siedmiu zasad, które są bardzo zbliżone do zasad Lean manufacturing.

Eliminacja strat (ang. Eliminate Waste)

Marnotrawstwem jest wszystko, co nie dodaje wartości do produktu. Wartością jest to, co klient uzna za wartościowe.

Tworzenie jakości i spójności (ang. Build Quality In)

Jakość i spójność produktu finalnego polega na uzyskaniu równowagi pomiędzy funkcjami aplikacji, jej niezawodnością i wartością ekonomiczną wytworzoną dla klienta firmy. Spójność jest tutaj rozumiana jako połączenie elementów jak jakość architektury (czy jest łatwa do pielęgnacji, łatwa do rozbudowywania, itp.), zadowolenia klienta z produktu zarówno w momencie dostarczenia produktu, jak i potem przez długi czas oraz używalności aplikacji. Firmy informatyczne tworzą często aplikacje które im samym się bardzo podobają i z których są dumne, niestety inne spojrzenie ma na to klient, który oczekiwał nie do końca tego, co zostało wdrożone.

Wzmocnienie pozyskiwania wiedzy (ang. Create Knowledge)

Tworzenie oprogramowania jest jednocześnie procesem uczenia się, poznajemy nową organizację, nowe zasady rządzące danym biznesem dla którego tworzymy aplikację. Dlatego też bardzo istotnym jest uzyskanie jak najlepszego sprzężenia zwrotnego. Można to uzyskać poprzez stosowanie częstych i krótkich iteracji, każdej zakończonej wdrożeniem nowo powstałego produktu. Jeśli nowa funkcjonalność powstała w n-tej iteracji zostanie wdrożona, natychmiast dostaniemy informacje zwrotną od klienta, dzięki czemu będziemy mogli zweryfikować czy wiedza jaką pozyskaliśmy jest właściwa, a także czy oczekiwania naszego klienta zostały zaspokojone.

Podejmowanie decyzji najpóźniej, jak to możliwe (ang. Defer Commitment)

Podczas tworzenia oprogramowania zespół musi podjąć szereg decyzji, choćby takich jaką technologię zastosować, z którą bazą danych związać produkt, o jakie architektury i szkielety (ang. framework) oprzeć produkt finalny. Bardzo często nie mamy na danym etapie realizacji projektu dość wiedzy, aby zdecydowanie podjąć decyzje i pójść wybraną drogą. Dlatego też zgodnie z zasadami szczupłego programowania, decyzje należy odwlekać tak długo jak się da, jednocześnie utrzymując tworzone oprogramowanie w takim stanie, że łatwo będzie je przystosować do zmian jakie wynikną w związku z ostatecznym podjęciem decyzji.

Wdrażanie najwcześniej, jak to możliwe (ang. Deliver Fast)

Zalecane jest dostarczenie produktu szybko i w małych porcjach, implementując je w poszczególnych iteracjach. Dzięki temu unikniemy bolesnych zmian wymagań klienta, ponieważ po szybkim wdrożeniu klient od razu będzie wiedział, czy zaimplementowana część produktu jest tym o czym myślał, czy też może wymagania klienta nie zostały właściwie odczytane. Miarą dojrzałości firmy informatycznej jest szybkość odpowiedzi na potrzeby klienta.

Respektowanie zespołu (ang. Respect People)

Idealnym zespołem jest zespół samoorganizujący się, dlatego należy zespołowi przekazać uprawnienia do decydowania, kto zajmuje się czym i za co jest odpowiedzialny. Zaangażowani członkowie zespołu stanowią o jego największej wartości. Osoby które dostarczają wartość dodaną, powinny mieć możliwość pełnego wykorzystania swojego potencjału, należy wspierać je, jak tylko się da.

Spojrzenie na całość (ang. Optimize the Whole)

Należy widzieć produkt jako całość, dotyczy to w miarę możliwości wszystkich członków zespołu go tworzącego. Rozwiązania technologiczne i szanse powinny być dobrze wyważone. Bezwzględnie należy ustrzec się przed optymalizacją pewnej części funkcjonalności systemu kosztem jej całości.

Zobacz też

Linki zewnętrzne

Źródło: „https://pl.wikipedia.org/w/index.php?title=Lean_software_development&oldid=30721325”