Lean Software Development

Lean Software Development
Metodyka
Inżynieria oprogramowania
TwórcyMary Poppendieck
Tom Poppendieck
Powstanie2003
okładka podręcznika
Oficjalna strona internetowa


Lean Software Development - przeniesienie praktyk i metod Lean Management oraz różnorodnych zasad IT na grunt inżynierii oprogramowania, w efekcie czego powstała metodyka programowania należąca do grupy metodyk zwinnych.

Spis treści

Rozwój standardu

Odchudzone czy inaczej wyszczuplone zarządzanie (ang. lean management) nosi nazwę amerykańską, jednak rodowód jego jest w całości japoński. Lean Management 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 i znana jest obecnie pod nazwą Lean Software Development. Została ona zaadoptowana przez Mary Poppendieck i Toma Poppendiecka i opisana w książce, której tytuł stał się nazwą metody. W szczupłym wytwarzaniu oprogramowania wyróżnia się 7 zasad wspomaganych przez 22 narzędzia, charakterystyczne dla Lean manufacturing i dostosowane do praktyk Agile.

Zastosowanie

Metodyki zwinne ze względu na swą różnorodność są nieporównywalne. Metodyka Scrum przykładowo dotyczy strony zarządzania projektem, pozostawiając inżynierskie sprawy – projektowanie, kodowanie, zarządzanie konfiguracją, testowanie itd. samoorganizującemu się zespołowi, a tymczasem XP dotyczy spraw inżynierskich i nie dostarcza żadnych specyficznych narzędzi do Zarządzanie projektami|zarządzania projektem. Lean Software Development dotyczy z kolei zarządzania projektami, ale w znacznie szerszym ujęciu niż metodyka SCRUM, bowiem z punktu widzenia organizacji całego przedsiębiorstwa.

Opis

Lean software development może być podsumowane za pomocą siedmiu zasad:
  • Eliminacja marnotrawstwa (ang. Eliminate Waste) - marnotrawstwem jest wszystko, co nie dodaje wartości do produktu. Wartością jest to, co klient uzna za wartościowe. Aby być w stanie wyeliminować straty, należy umieć je rozpoznać. Jeżeli niektóre działania mogą być pominięte lub wynik można osiągnąć bez owych działań, to są to straty. Częściowo wykonane kodowanie, ostatecznie przerwane w trakcie rozwoju procesu także jest stratą. Dodatkowe procesy i funkcje, które nie są często używane przez klientów stają się stratami. Awarie oraz spadki jakości są stratami. Podsumowując, wśród strat wymienić można m.in.:
    • zbędne kodowanie oraz funkcjonalność
    • opóźnienia w procesie programowanie zwinnego
    • brak konkretnych wymagań
    • biurokracja
    • słaba i wolna komunikacja wewnętrzna
  • 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

Bibliografia

ostatnia modyfikacja 20 sierpnia 2016 r.