Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Dodatkowe funkcje, takie jak papierkowa robota i funkcje, które nie są często używane przez klientów są marnotrawstwem. Przełączanie ludzi pomiędzy zadaniami jest marnotrawstwem. Oczekiwanie na inne działania, zespoły, procesy jest marnotrawstwem. Ponowne uczenie się wymagane do ukończenia pracy jest marnotrawstwem. Defekty i niższa jakość to marnotrawstwo. Koszty ogólne zarządzania, które nie przynoszą rzeczywistej wartości to marnotrawstwo.
Do identyfikacji marnotrawstwa wykorzystuje się technikę mapowania strumienia wartości. Drugim krokiem jest wskazanie źródeł marnotrawstwa i ich eliminacja. Usuwanie marnotrawstwa powinno odbywać się iteracyjnie, aż do likwidacji nawet pozornie niezbędnych procesów i procedur.
Wzmocnij naukęEdit
Rozwój oprogramowania to ciągły proces uczenia się oparty na iteracjach podczas pisania kodu. Projektowanie oprogramowania jest procesem rozwiązywania problemów, w którym uczestniczą programiści piszący kod i to, czego się nauczyli. Wartość oprogramowania jest mierzona w przydatności do użycia, a nie w zgodności z wymaganiami.
Zamiast dodawać więcej dokumentacji lub szczegółowego planowania, różne pomysły mogą być wypróbowane poprzez pisanie kodu i budowanie. Proces zbierania wymagań użytkownika może być uproszczony poprzez prezentowanie ekranów użytkownikom końcowym i uzyskiwanie ich opinii. Akumulacji defektów powinno się zapobiegać poprzez uruchamianie testów zaraz po napisaniu kodu.
Proces uczenia się jest przyspieszany poprzez stosowanie krótkich cykli iteracji – każdy z nich połączony z refaktoryzacją i testami integracyjnymi. Zwiększenie ilości informacji zwrotnych poprzez krótkie sesje z klientami pomaga w określeniu aktualnej fazy rozwoju i dostosowaniu wysiłków do przyszłych ulepszeń. Podczas tych krótkich sesji, zarówno przedstawiciele klienta, jak i zespół programistów dowiadują się więcej o problemie domeny i ustalają możliwe rozwiązania dla dalszego rozwoju. W ten sposób klienci lepiej rozumieją swoje potrzeby, bazując na dotychczasowych wynikach prac rozwojowych, a programiści uczą się, jak lepiej zaspokajać te potrzeby. Innym pomysłem w procesie komunikacji i uczenia się z klientem jest rozwój oparty na zestawach – koncentruje się on na przekazywaniu ograniczeń przyszłego rozwiązania, a nie możliwych rozwiązań, promując w ten sposób narodziny rozwiązania poprzez dialog z klientem.
Decyduj tak późno, jak to możliweEdit
Jako że rozwój oprogramowania jest zawsze związany z pewną niepewnością, lepsze wyniki powinno się osiągnąć przy podejściu opartym na zestawach lub opcjach, opóźniając decyzje tak bardzo, jak to możliwe, aż będzie można je podjąć w oparciu o fakty, a nie niepewne założenia i przewidywania. Im bardziej złożony jest system, tym większą zdolność do zmian należy w niego wbudować, umożliwiając w ten sposób opóźnienie ważnych i kluczowych zobowiązań. Podejście iteracyjne promuje tę zasadę – zdolność do adaptacji do zmian i korygowania błędów, które mogą być bardzo kosztowne, jeśli zostaną odkryte po wydaniu systemu.
Z rozwojem opartym na zestawach: Jeśli na przykład w samochodzie potrzebny jest nowy układ hamulcowy, trzy zespoły mogą zaprojektować rozwiązania tego samego problemu. Każdy zespół poznaje przestrzeń problemową i projektuje potencjalne rozwiązanie. Gdy rozwiązanie zostanie uznane za nieracjonalne, jest wycinane. Na koniec okresu, ocalałe projekty są porównywane i wybierany jest jeden, być może z pewnymi modyfikacjami opartymi na nauce od pozostałych – jest to świetny przykład odraczania zaangażowania do ostatniego możliwego momentu. Decyzje dotyczące oprogramowania również mogłyby skorzystać z tej praktyki, aby zminimalizować ryzyko związane z dużym projektem z góry. Dodatkowo, istniałoby wtedy wiele implementacji, które działają poprawnie, ale są różne (implementacyjnie, wewnętrznie). Te mogłyby być wykorzystane do wdrożenia systemów odpornych na błędy, które sprawdzają wszystkie wejścia i wyjścia pod kątem poprawności, w wielu implementacjach, jednocześnie.
Zwinne podejście do rozwoju oprogramowania może przesunąć budowanie opcji wcześniej dla klientów, opóźniając w ten sposób pewne kluczowe decyzje, dopóki klienci nie uświadomią sobie lepiej swoich potrzeb. Pozwala to również na późniejszą adaptację do zmian i zapobieganie kosztownym, wcześniejszym decyzjom związanym z technologią. Nie oznacza to, że nie należy zajmować się planowaniem – wręcz przeciwnie, działania związane z planowaniem powinny być skoncentrowane na różnych opcjach i dostosowaniu się do bieżącej sytuacji, a także na wyjaśnianiu niejasnych sytuacji poprzez ustalanie wzorców szybkiego działania. Ocenianie różnych opcji jest skuteczne, gdy tylko uświadamiamy sobie, że nie są one darmowe, ale zapewniają elastyczność potrzebną do późnego podejmowania decyzji.
Dostarczaj tak szybko, jak to możliweEdit
W dobie szybkiej ewolucji technologii, nie przetrwają najwięksi, ale najszybsi. Im szybciej produkt końcowy zostanie dostarczony bez większych wad, tym szybciej można otrzymać informację zwrotną i włączyć ją do następnej iteracji. Im krótsze iteracje, tym lepsza nauka i komunikacja w zespole. Dzięki szybkości, decyzje mogą być opóźnione. Szybkość zapewnia spełnienie aktualnych potrzeb klienta, a nie tego, czego wymagał wczoraj. Daje im to możliwość opóźnienia podjęcia decyzji o tym, czego naprawdę potrzebują, dopóki nie zdobędą lepszej wiedzy. Klienci cenią sobie szybkie dostarczenie produktu wysokiej jakości.
Ideologia produkcji just-in-time może być zastosowana do wytwarzania oprogramowania, uznając jego specyficzne wymagania i środowisko. Osiąga się to poprzez przedstawienie potrzebnego wyniku i pozwolenie zespołowi na zorganizowanie się i podzielenie zadań dla osiągnięcia potrzebnego wyniku dla konkretnej iteracji. Na początku, klient dostarcza potrzebnych danych. Może to być po prostu przedstawione w małych kartach lub historiach – programiści szacują czas potrzebny na realizację każdej z nich. W ten sposób organizacja pracy zmienia się w system samonapędzający się – każdego ranka, podczas spotkania stand-up, każdy członek zespołu przegląda, co zostało zrobione wczoraj, co jest do zrobienia dzisiaj i jutro, i pyta o wszelkie potrzebne dane wejściowe od kolegów lub klienta. Wymaga to przejrzystości procesu, co jest również korzystne dla komunikacji w zespole.
Mitem leżącym u podstaw tej zasady jest to, że pośpiech czyni marnotrawstwo. Jednak wdrożenie Lean wykazało, że dobrą praktyką jest szybkie dostarczanie produktów, aby móc je jak najwcześniej zobaczyć i przeanalizować.
Umocnij zespółEdit
W większości firm istnieje tradycyjne przekonanie dotyczące podejmowania decyzji w organizacji – menedżerowie mówią pracownikom, jak mają wykonywać swoją pracę. W technice work-out role się odwracają – menedżerowie uczą się, jak słuchać programistów, dzięki czemu mogą oni lepiej wyjaśnić, jakie działania można podjąć, a także przedstawić sugestie dotyczące usprawnień. Podejście lean jest zgodne z zasadą agile „buduj projekty wokół zmotywowanych jednostek i ufaj im, że wykonają zadanie”, zachęcając do postępu, wyłapując błędy i usuwając przeszkody, ale nie mikrozarządzając.
Kolejnym błędnym przekonaniem jest traktowanie ludzi jako zasobów. Ludzie mogą być zasobami z punktu widzenia arkusza danych statystycznych, ale w tworzeniu oprogramowania, jak i w każdej innej działalności organizacyjnej, ludzie potrzebują czegoś więcej niż tylko listy zadań i zapewnienia, że nie będą przeszkadzać w ich wykonywaniu. Ludzie potrzebują motywacji i wyższego celu do pracy – celu w ramach osiągalnej rzeczywistości, z zapewnieniem, że zespół może wybrać swoje własne zobowiązania. Programiści powinni mieć zapewniony dostęp do klienta, a lider zespołu powinien zapewnić wsparcie i pomoc w trudnych sytuacjach, a także zadbać o to, by sceptycyzm nie zniszczył ducha zespołu. Szanowanie ludzi i docenianie ich pracy jest jednym ze sposobów na wzmocnienie zespołu.
Buduj integralność wEdit
Klient musi mieć ogólne doświadczenie z systemem. Jest to tak zwana postrzegana integralność: jak jest on reklamowany, dostarczany, wdrażany, dostępny, jak intuicyjne jest jego użycie, jego cena i jak dobrze rozwiązuje problemy.
Integralność koncepcyjna oznacza, że poszczególne komponenty systemu dobrze współpracują jako całość z zachowaniem równowagi pomiędzy elastycznością, łatwością utrzymania, wydajnością i szybkością reakcji. Można to osiągnąć poprzez zrozumienie domeny problemu i rozwiązywanie go w tym samym czasie, a nie sekwencyjnie. Potrzebne informacje są otrzymywane w małych partiach – nie w jednym ogromnym kawałku – najlepiej poprzez komunikację twarzą w twarz, a nie jakąkolwiek dokumentację pisemną. Przepływ informacji powinien być stały w obu kierunkach – od klienta do deweloperów i z powrotem, co pozwala uniknąć dużej ilości stresujących informacji po długim rozwoju w izolacji.
Jedną ze zdrowych dróg w kierunku architektury integralnej jest refaktoryzacja. Im więcej funkcji jest dodawanych do oryginalnej bazy kodu, tym trudniej jest dodać kolejne ulepszenia. Refaktoryzacja polega na utrzymaniu prostoty, przejrzystości, minimalnej liczby funkcji w kodzie. Powtórzenia w kodzie są oznaką złego projektu kodu i powinny być unikane. Kompletnemu i zautomatyzowanemu procesowi budowania systemu powinien towarzyszyć kompletny i zautomatyzowany zestaw testów deweloperskich i klienckich, posiadających taką samą wersjonalność, synchronizację i semantykę jak aktualny stan systemu. Na koniec integralność powinna być zweryfikowana za pomocą dokładnych testów, co daje pewność, że System robi to, czego oczekuje klient. Testy automatyczne są również uważane za część procesu produkcyjnego, a zatem jeśli nie dodają wartości, powinny być uważane za odpady. Zautomatyzowane testy nie powinny być celem, ale raczej środkiem do celu, a konkretnie do redukcji defektów.
Optymalizacja całości
Nowoczesne systemy oprogramowania nie są po prostu sumą ich części, ale także produktem ich interakcji. Defekty w oprogramowaniu mają tendencję do kumulowania się podczas procesu rozwoju – poprzez dekompozycję dużych zadań na mniejsze oraz standaryzację różnych etapów rozwoju, przyczyny powstawania defektów powinny zostać znalezione i wyeliminowane. Im większy system, im więcej organizacji jest zaangażowanych w jego rozwój i im więcej części jest rozwijanych przez różne zespoły, tym większe znaczenie ma posiadanie dobrze zdefiniowanych relacji pomiędzy różnymi dostawcami, w celu wytworzenia systemu z płynnie współdziałającymi komponentami. Podczas dłuższego okresu rozwoju, silniejsza sieć podwykonawców jest o wiele bardziej korzystna niż krótkoterminowa optymalizacja zysków, która nie umożliwia relacji typu win-win.
Lean thinking musi być dobrze zrozumiany przez wszystkich członków projektu, zanim zostanie wdrożony w konkretnej, rzeczywistej sytuacji. „Think big, act small, fail fast; learn rapidly” – te slogany podsumowują znaczenie zrozumienia dziedziny i przydatności wdrożenia zasad lean w całym procesie wytwarzania oprogramowania. Tylko wtedy, gdy wszystkie zasady lean są wdrażane razem, w połączeniu z silnym „zdrowym rozsądkiem” w odniesieniu do środowiska pracy, istnieje podstawa sukcesu w rozwoju oprogramowania.