Lean software development
Lean software development – zastosowanie koncepcji lean management (szczupłego zarządzania) w produkcji oprogramowania.
Metoda została zaadaptowana 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 edytuj
Eliminacja strat (ang. Eliminate Waste) edytuj
Marnotrawstwo to wszystko, co nie dodaje wartości do produktu. To klient definiuje wartość.
Tworzenie jakości i spójności (ang. Build Quality In) edytuj
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, lecz 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) edytuj
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) edytuj
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) edytuj
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) edytuj
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) edytuj
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.