Chude rozwoju oprogramowania

Autor: Davida J.Anderson.David J.Anderson jest autorem książek, w trzech lekcji w zarządzaniu Agile: na droga do Kanban, który został opublikowany w 2012 r., Kanban: pomyślnej zmianie ewolucyjny dla Twojej firmy technologii, [1] wydanym w 2010 r. i, Agile zarządzanie dla inżynierii oprogramowania: zastosowania teorii ograniczeń dla wyników biznesowych, [2] wydanym w 2003 roku.Był członkiem zespołu, który opracował metodę zwinnego tworzenia oprogramowania — Feature-Driven Development (tworzenie oprogramowania oparte na funkcjach) — w Singapurze, w latach 1997-99.Stworzył MSF na rzecz poprawy procesu CMMI i współautorem Uwaga techniczna z Software Engineering Institute, "Agile i CMMI: Dlaczego nie objąć zarówno!" Był jednym społeczeństwa systemów chudego (http://www.leansystemssociety.org).Jest Dyrektor Generalny Kanban chudego University Inc., akredytowanych szkolenia i jakości organizacji normalizacyjnej szkoleniowe Kanban poprzez sieć partnerami na całym świecie i prowadzi kształcenie w zakresie zarządzania międzynarodowych i firmie konsultingowej, David J.Anderson & Associates, Inc.(http://www.agilemanagement.net), które pomaga firmom technologicznym zwiększyć ich wydajność poprzez lepsze zasady zarządzania i podejmowania decyzji.

Listopad 2011 zaktualizowane listopada 2012.

Anderson opisuje metodykę odchudzonego tworzenia oprogramowania.

Dotyczy

Metodyka odchudzona, tworzenie oprogramowania, zarządzanie projektami, Team Foundation Server

• Introduction

• Metodyka odchudzona i zwinne programowanie

• Metodyka odchudzona poza metodykę zwinną

• Definiowanie zasad odchudzonego tworzenia oprogramowania

• Wartości

• Zasady

• Praktyki

Określenie Lean Software Development zostało zaprezentowane po raz pierwszy jako tytuł konferencji zorganizowanej przez inicjatywę ESPRIT Unii Europejskiej w Stuttgarcie, w Niemczech, w październiku 1992 r.Niezależnie w następnym roku Robert „Bob” Charette w 1993 r. zasugerował koncepcję „odchudzonego tworzenia oprogramowania” jako część jego prac dotyczących szukania lepszych sposobów zarządzania ryzykiem w projektach tworzenia oprogramowania.Termin „Chudy” datuje się na rok 1991. Został zaproponowany przez Jamesa Womacka, Daniela Jonesa i Daniela Roosa w książce The Machine That Changed the World: The Story of Lean Production[3], jako termin języka angielskiego, używany do określania podejścia do zarządzania w firmie Toyota.Pomysł zastosowania metodologii Lean w rozwoju oprogramowania powstał bardzo wcześnie, bo już po 1 lub 2 latach od pierwszego zastosowania jej w odniesieniu do procesów produkcji i inżynierii przemysłowej.

W swojej drugiej książce, opublikowanej w 1995 r., Womack i Jones[4] zdefiniowali pięciu filarów metodyki odchudzonego myślenia.Były to:

• Wartość

• Strumień wartości

• Przepływ

• Ciągnij

• Doskonałość

Stało się to domyślną definicją roboczą odchudzonego myślenia na większą częśc następnej dekady.Dążenie do doskonałości, jak to zasugerowano, zostało osiągnięte poprzez wyeliminowanie odpadów.Wśród 5 filarów tylko ten piąty, polegający na dążeniu do doskonałości poprzez identyfikację systemową działań nieekonomicznych i ich eliminacji, naprawdę zyskał na popularności wśród szerokiego grona odbiorców.Metodyka odchudzona stała się prawie wyłącznie kojarzona z praktyką eliminacji strat pod koniec lat 90 i na początku 21 wieku.

Definicja Womack i Jones dla metodyki Lean nie jest powszechnie udostępniana.Zasady zarządzania w firmie Toyota są znacznie bardziej subtelne.Pojedynczy wyraz „odpady” jest opisany bardziej szczegółowo trzema japońskich określeniami:

• Muda — oznacza dosłownie „odpady”, ale sugeruje działania niedające wartości dodanej

• Mura — oznacza „nierównomierność” i jest interpretowane jako „zmienność przepływu”

• Muri — oznacza „nadmierne obciążenie” lub „nieracjonalność”

Doskonałość jest osiągana poprzez ograniczenie działalności bez wartości dodanej, lecz również poprzez wygładzanie przepływu i wyeliminowanie nadmiernego obciążenia.Ponadto podejście Toyoty bazowało na fundamentalnym szacunku dla ludzi i było pod ogromnym wpływem XX-wiecznych teorii specjalistów od zapewniania jakości oraz statystycznej kontroli procesów, takich jak W.Edwards Deming.

Niestety istnieje prawie tyle definicji chudego, ilu jest autorów.

Metodyka odchudzona i zwinne programowanie

Robert Charette był zaproszony, ale nie mógł uczestniczyć w spotkaniu w 2001 r. w Snowbird w Utah, gdzie został utworzony manifest zwinnego tworzenia oprogramowania[5].Pomimo braku na tym spotkaniu historycznym odchudzone tworzenie oprogramowania zostało uznane za jedno z kilku zwinnych podejść do tworzenia oprogramowania.Jim Highsmith dedykował rozdział swojej książki z 2002 r.[6] rozmowie z Bobem na ten temat.Później Mary i Tom Poppendieck napisali serię 3[7,8,9] książek.Podczas pierwszych kilku lat XXI wieku zasady metodyki odchudzonej zostały wykorzystane do wyjaśnienia, dlaczego metody zwinne były lepsze.Według metodyki odchudzonej metody zwinne zawierały mało „strat” i stąd generowały lepsze wyniki ekonomiczne.Zasady metodyki odchudzonej były używane jako „czynnik zezwalający” na przyjęcie metod zwinnych.

Metodyka odchudzona poza metodykę zwinną

W ostatnich latach odchudzone tworzenie oprogramowania rzeczywiście zyskało status odrębnej dyscypliny, która jest związana z metodyką zwinną, ale niekoniecznie stanowi jej podzbiór.Ewolucja rozpoczęła się wraz z syntezą idei metodyki Lean Product Development i pracy Donalda G.Reinertsen[10,11] i pomysły ze spoza środowiska Agile, ze świata inżynierii systemowej na dużą skalę i zapisy Jamesa Suttona i Petera Middletona[12].Również syntetyzowałem prace Eli'ego Goldratta i W.Edwards Deming rozwinął skupienie uwagi na przepływie, a nie zmniejszeniu strat[13].Na p. Reinertsena około 2005 r. wprowadziłem systemy kanban, które ograniczają pracę w toku i „wciągają” nową pracę tylko wtedy, gdy system jest gotowy do przetwarzania jej.Alan Shalloway dodał swoje przemyślenia na temat odchudzonego tworzenia oprogramowania w swojej książce z 2009 r. na ten temat[14].Od 2007 pojawienie się metodyki Lean jako nowego sposobu wprowadzania zmian w profesji rozwoju oprogramowania skupia się na usprawnieniu przepływu, zarządzaniu ryzykiem oraz poprawą procesu decyzyjnego (w zarządzaniu).Metodyka Kanban stała się głównym wehikułem stosowania metodyki odchudzonej w projektach informatycznych.Wydaje się, że nacisk na przepływ, a nie na eliminację strat, jest lepszym katalizatorem ciągłej poprawy w ramach działań w pracy opartej na wiedzy, takich jak tworzenie oprogramowania.

Definiowanie zasad odchudzonego tworzenia oprogramowania

Definiowanie zasad odchudzonego tworzenia oprogramowania jest trudne, ponieważ nie istnieje konkretna metoda ani proces odchudzonego tworzenia oprogramowania.Metodyka odchudzona nie jest tożsama z osobistym procesem tworzenia oprogramowania (Personal Software Process), modelem V, modelem spiralnym, EVO, tworzeniem oprogramowania opartym na funkcjach (Feature-Driven Development), programowaniem ekstremalnym, metodą Scrum ani tworzeniem oprogramowania opartym na testowaniu (Test-Driven Development).Proces tworzenia oprogramowania lub zarządzania projektem można określić jako „odchudzony”, jeśli dopilnowano, aby był dostosowane do wartości cyklu odchudzonego tworzenia oprogramowania i zasad odchudzonego tworzenia oprogramowania.Dlatego też osoby oczekujące prostego rozwiązania do szybkiego wdrożenia, które występuje jako rozwój oprogramowania typu Lean, będą rozczarowane.Należy dostosowywać własny proces rozwoju oprogramowania poprzez zrozumienie zasad szczupłego zarządzania i przyjęcie wartości podstawowych szczupłego zarządzania.

Istnieje kilka sposobów myślenia w ramach programowania oprogramowania typu Lean.Szkoła największych i prawdopodobnie wiodącym jest społeczeństwa systemów chudego, które obejmuje Donald Reinertsen, Jim Sutton, Alan Shalloway, Bob Charette, Mary Poppendeick i David J.Anderson.Maria oraz Tom Poppendieck pracy rozwiniętych przed przystąpieniem do tworzenia społeczeństwa i jego credo oznacza oddzielnie, jak działa Craig Larman, Bas Vodde[15,16]i ostatnio, Jim Coplien[17].Ten artykuł ma być szeroko reprezentatywne z punktu widzenia społeczeństwa systemów chudego wyrażone w jego credo i zapewnienie syntezy i krótki opis ich pomysłów.

Wartości

Towarzystwo systemów chudego opublikowało jego credo[18] na oprogramowanie chudego 2012 & Konferencja systemy[19].Było to oparte na zestawie wartości wydanej rok wcześniej.Te wartości:

• Zaakceptuj specyfikę człowieka

• Zaakceptuj, że złożoność i niepewność są naturalne w pracy opartej na wiedzy

• Należy działać na rzecz lepszego wyniku gospodarczego

• W przypadku włączenia lepszych wyników socjologicznych

• Wyszukuj, przyjmuj i kwestionuj pomysły z szerokiego zakresu dyscyplin

• Społeczność oparta na wartościach zwiększa szybkość i głębokość pozytywnych zmian.

Zaakceptuj specyfikę człowieka

Praca oparta na wiedzy, taka jak tworzenie oprogramowania, jest podejmowana przez ludzi.Jako ludzie jesteśmy z założenia skomplikowani i chociaż myślimy logicznie, kierują nami również emocje i niektóre nieodłączne cechy zwierzęce, które nie dają się w racjonalny sposób przezwyciężyć.Nasi psycholodzy oraz neuropsycholodzy muszą być brani pod uwagę podczas projektowania systemów i procesów, w ramach których pracujemy.Nasze zachowanie społeczne również musi zostać dostosowane.Ludzie są z natury emocjonalne, społeczni i stadni, a nasze zachowanie zmienia się wskutek zmęczenia i stresu.Pomyślne procesy to te, które uzględniają specyfikę człowieka w odróżnieniu od tych, które jej zaprzeczają i zakładają logiczne, zautomatyzowane zachowanie.

Zaakceptuj, że złożoność i niepewność są naturalne w pracy opartej na wiedzy

Zachowanie klientów i rynków jest nieprzewidywalne.Przepływ pracy w procesie i kolekcji pracowników jest nieprzewidywalny.Wady i konieczne przeróbki są nieprzewidywalne.Istnieje nieodłączne ryzyko lub pozornie przypadkowe zachowanie na wielu poziomach w ramach programowania oprogramowania.Cel, cele i zakres projektów są zwykle zmienne podczas dostarczania.Pomimo początkowej niewiedzy niepewność i zmienność stają się znajome w takim sensie, że mogą zostać przestudiowane i policzone, a ich ryzykiem można zarządzać, ale pewna zmienność nie jest znana z wyprzedzeniem ani nie można jej odpowiednio przewidzieć.W efekcie systemy odchudzonego tworzenia oprogramowania muszą być w stanie reagować na bieżące zdarzenia, a system musi mieć możliwość adaptacji do zmieniających się okoliczności.Dlatego każdy proces odchudzonego tworzenia oprogramowania musi istnieć w granicach środowiska pozwalającego na dostosowanie (procesu) do pojawiających się zdarzeń.

Należy działać na rzecz lepszego wyniku gospodarczego

Działania człowieka, takie jak odchudzone tworzenie oprogramowania, powinny koncentrować się na uzyskaniu lepszych wyników ekonomicznych.Kapitalizm jest dopuszczalny, gdy przyczynia się zarówno do wzrostu wartości dla firmy, jak i korzyści dla klienta.Inwestorzy i właściciele przedsiębiorstw zasługują na zwrot z inwestycji.Pracownicy zasługują na godziwą stawkę płacy za godziwy wysiłek przy wykonywaniu pracy.Klienci zasługują na dobry produkt lub usługę, która zapewnia przyrzeczone korzyści, w zamian za godziwą ceną płaconą.Lepsze wyniki ekonomiczne obejmą dostarczanie większej wartości do klienta po niższych kosztach przy zarządzaniu kapitałem zaangażowanym przez inwestorów lub właścicieli w sposób najbardziej efektywny.

Umożliw lepsze wyniki socjologiczne

Lepsze wyniki ekonomiczne nie powinny być dostarczane kosztem osób wykonujących pracę.Niezbędne jest utworzenie miejsca pracy, w którym szanuje się specyfikę człowieka i tworzy systemy pracy respektujące psychologiczną i socjologiczną naturę człowieka.Utworzenie znakomitego miejsca do znakomitej pracy jest kluczową wartością wspólnoty osób zajmujących się odchudzonym tworzeniem oprogramowania.

Zasady

Społeczność Lean Software & Systems wydaje się zgadzać na kilka zasad, które stanowią podstawę procesów rozwoju oprogramowania Lean.

• Postępuj zgodnie z metodyką systemowego myślenia i projektowania

• Na wyniki koncepcyjne może mieć wpływ architektura kontekstu złożonego systemu adaptacyjnego

• Szacunek względem ludzi (jako część systemu)

• Użyj metody naukowej (do ulepszenia dysku)

• Zachęcaj do objęcia przywództwa

• Generuj widoczność (pracy, przepływu pracy i działania systemu)

• Zmniejsz czas przepływu

• Zmniejsz odpady w celu poprawy efektywności

Postępuj zgodnie z metodyką systemowego myślenia i projektowania

Ta często jest określone w literaturze chudego zarządzania jako „Optymalizacja całości”, co oznacza, że są to dane wyjściowe całego systemu (lub procesu), który chcemy poddać optymalizacji i nie powinniśmy omyłkowo optymalizować części w nadziei, że w magiczny sposób zostanie wtedy zoptymalizowana całość.Większość praktyków uważa to następstwo za pewnik, że optymalizacja części (optymalizacja lokalna) doprowadzi do nieadekwatnego wyniku.

Strategia myślenia i projektowania przy użyciu systemów odchudzonych wymaga, abyśmy brali pod uwagę oczekiwania wobec systemu ze strony zewnętrznych zainteresowanych stron, na przykład klientów, oraz wymagane przez nie rezultaty.Musimy zbadać rodzaj popytu i porównać go z możliwościami naszego systemu w zakresie dostarczania.Żądanie będzie zawierać tak zwane „żądanie wartości”, za które klienci są skłonni zapłacić, „żądanie awarii”, które jest zwykle żądaniem przeróbki lub żądaniem dodatkowym spowodowanym przez usterkę w dostarczaniu żądania wartości.Żądanie pousterkowe często ma dwie formy: przeróbki poprzednio zrealizowanego żądania wartości i dodatkowych usług lub wsparcia z powodu niezrealizowania żądania wartości.W tworzeniu oprogramowania awarii żądania pousterkowe są zazwyczaj składane dla poprawek błędów oraz żądań do działów obsługi klienta lub pomocy technicznej.

Podejście do projektowania systemów wymaga również stosowania podejścia Zaplanuj-Wykonaj-Sprawdź-Popraw (PDSA) przy projektowaniu i poprawianiu procesu.W.Edwards Deming używał wyrazów „badanie” i „możliwości”, aby wskazać, że możemy badać naturalną filozofię zachowań naszego systemu.System ten składa się z naszego procesu tworzenia oprogramowania i wszystkich osób, które go używają.Będzie miał dostrzegalne zachowanie w kategoriach czasu realizacji, jakości, liczby funkcji lub dostarczonych funkcji i (zwanych w literaturze zwinnego programowania „prędkością”) i itd.Wskaźniki te będą wykazywać zmienność i, badając średnią i rozprzestrzenianie się zmienności, możemy wypracować zrozumienie naszych możliwości.Jeśli to jest niezgodne z żądaniem i oczekiwaniami klienta, system należy przeprojektować, aby zamknąć tę lukę.

Deming uczył także, że na możliwości w 95% wpływa projekt systemu, a tylko 5% jest wniesione przez działania osób.Innymi słowy szanujemy ludzi przez nieobwinianie ich o lukę między możliwościami a żądaniami oraz przez przeprojektowanie systemu tak, aby umożliwić im skuteczną pracę.

Aby zrozumieć projektowanie systemu, potrzebna jest teoretyczna znajomość dynamiki możliwości systemu i czynników, które mają na nią wpływ.Modele są opracowane do przewidzenia dynamiki systemu.Chociaż istnieje wiele możliwych modeli, kilka popularnych znajduje się w powszechnym użyciu. Należą do nich: opis kosztów ekonomicznych, tak zwanych kosztów transakcji i koordynacji, które odnoszą się do produkcji wycenionej przez nabywcę produktów lub usług, teoria ograniczenia, czyli zrozumienie wąskich gardeł i teoria dogłębnej wiedzy, czyli badania i uznawanie zmienności jako wspólnej cechy projektowania systemu lub specjalnej oraz zewnętrznej wobec projektowania systemu.

Na wyniki koncepcyjne może mieć wpływ architektura kontekstu złożonego systemu adaptacyjnego

Złożone systemy mają warunki początkowe i proste reguły, które podczas wykonywania iteracyjnego generują wynik koncepcyjny.Wyniki koncepcyjne są trudne lub niemożliwe do przewidzenia, biorąc pod uwagę warunki początkowe.Eksperyment naukowy na komputerze „Gra życia” to przykład złożonego systemu.Złożony system adaptacyjny ma w sobie pewną samoświadomość i wewnętrzną metodę refleksji, która umożliwia mu rozważanie, jak dobrze jego bieżący zestaw reguł pozwala mu osiągnąć pożądany wynik.Następnie złożony system adaptacyjny może dostosować się sam — zmienić swoje proste reguły – zlikwidować rozbieżność między przychodem bieżącym i żądanym.Gra Game of Life dostosowana, tak aby reguły można było przepisać podczas gry, może być złożonym systemem adaptacyjnym.

W procesach tworzenia oprogramowania „proste reguły” złożonych systemów adaptacyjnych są zasadami, które tworzą definicję procesu.Podstawowe założenie opiera się na przekonaniu, że rozwój produktów oprogramowania i usług nie jest działaniem deterministycznym i dlatego zdefiniowany proces, który nie może się sam dostosować, nie będzie odpowiedni do nieprzewidywalnych zdarzeń.Stąd proces zaprojektowanych jako część naszego myślenia systemowego i podejścia projektowego musi być adaptacyjny.Dostosowuje się poprzez zmianę zasad, z których się składa.

Podejście Kanban do rozwoju oprogramowania Lean wykorzystuje tę koncepcję, traktując zasady systemu ściągania kanban jako "proste reguły". Warunki początkowe to przedstawienie graficzne pracy i jej przepływu, który jest zarządzany za pomocą systemu dynamicznego, a organizacja stosuje naukowe podejście do opisywania, proponowania i implementowania udoskonaleń procesu.

Szacunek względem ludzi

Społeczność Lean przyjmuje definicję Petera Drucker'a dotycząca pracy z wiedzą, która mówi, że pracujący z wiedzą to pracownicy, którzy mają większe pojęcie na temat wykonywanej pracy od swoich przełożonych.Powstaje domniemanie, że pracownicy są najwłaściwszą grupą mogącą podejmować decyzje dotyczące sposobów wykonywania pracy i modyfikowania procesów, aby poprawić jakość pracy.Uwagi pracownika powinny być brane pod uwagę.Pracownicy powinni być uprawnieni do samodzielnego organizowania się w celu zakończenia pracy i osiągnięcia pożądanych rezultatów.Powinny być również upoważnione do sugerowania i wdrażania możliwości poprawy procesu lub "zdarzeń kaizen", jak są określane w literaturze dotyczącej odchudzonego myślenia.Czynienie zasad procesu jawnymi, tak aby pracownicy byli świadomi reguł, które ich ograniczają, jest kolejnym sposobem okazywana im szacunku.Jasno określone reguły wspierają samoorganizację, usuwając strach i potrzebę odwagi.Poszanowanie osób, poprzez nadanie im uprawnień i udostępnienie jasnych zasad, jest zgodne z podstawową wartością poszanowania ludzi.

Użyj metody naukowej

Poszukuj sposobów na korzystanie z modelów, aby zrozumieć dynamikę sposobu pracy i sposobu działania systemu odchudzonego rozwoju oprogramowania.Obserwuj i analizuj system i jego możliwości, a następnie opracowuj i stosuj modele do przewidywania jego zachowania.Zbieraj dane ilościowe w swoich ankietach i używaj tych danych, aby zrozumieć, jak system działa, i przewidywać, jak może się zmienić po zmianie procesu.

Społeczność Lean Software & System używa metod statystycznych, takich jak statystyczne wykresy kontroli procesów i histogramy analizy widmowej danych surowych dotyczących czasu realizacji i prędkości, aby poznać możliwości systemu.Używają także modeli takich jak: Teoria ograniczenia, aby zrozumieć wąskie gardła; System dogłębnej wiedzy, aby zrozumieć wewnętrzną odmianę projektu systemu w kontekście tej, na która wpływ wywierany jest z zewnątrz; a analizę ekonomicznych kosztów w formie zadań wykonywanych jedynie w celu koordynowania, konfiguracji, dostarczania lub oczyszczania po utworzeniu produktu lub usługi ocenionej przez klienta.Wdrażane są niektóre inne modele, takie jak Teoria opcji rzeczywistych, która pozwala na zastosowanie teorii opcji finansowych z zarządzania ryzykiem finansowym w procesie decyzyjnym w rzeczywistości.

Metoda naukowa sugeruje: robimy badania; żądamy wyniku na podstawie modelu; zaburzamy system oparty na tym przewidywaniu; i obserwujemy ponownie, aby przekonać się, czy zaburzenie wywołało wynik, jaki przewidziany został przez model.Jeśli nie, sprawdzamy nasze dane i ponownie rozważamy, czy nasz model jest dokładny.Używanie modeli do poprawiania procesów to metoda naukowa i odejście od irracjonalnego działania opartego na intuicji.

Zachęcaj do objęcia przywództwa

Przywództwo i zarządzanie to nie to samo.Zarządzanie jest działaniem projektowania procesów, tworzenia, modyfikowania i usuwania zasad, podejmowania decyzji strategicznych i operacyjnych, gromadzenia zasobów, zapewnienia finansowania i infrastruktury oraz przekazywania informacji o kontekście takich jak strategia, cele i pożądane rezultaty.Przywództwo dotyczy wizji, strategii, taktyki, odwagi, innowacji, osąd, orędownictwa i wielu więcej atrybutów.Przywództwo może i powinno pochodzić od różnych osób w organizacji.Niewielkie działanie kierownicze pracowników spowodują kaskadę usprawnień, która zapewni zmiany niezbędne w procesie rozwoju oprogramowania typu Lean.

Generuj widoczność

Praca oparta na wiedzy jest niewidoczna.Jeśli nie widzisz czegoś, jest niemożliwe (prawie) tym zarządzać.Jest konieczne generowanie wglądu w podejmowane prace i przepływu tych prac przez sieć osób, umiejętności i działów, aż do ukończenia.Jest konieczne utworzenie wglądu w proces projektowania przez znalezienie sposobów wizualizacji przepływu procesu i pokazanie zasad procesu wyraźnie wszystkim, aby mogli się z nimi zapoznać i uwzględnić.Gdy widoczne są wszystkie te rzeczy, następnie możliwe jest wykorzystanie metody naukowej i rozmowy o potencjalnych ulepszeniach mogą być obiektywne i służyć współpracy.Poprawa procesu współpracy jest praktycznie niemożliwa, jeśli praca i przepływ pracy są niewidoczne, a zasady procesu nie są jawne.

Zmniejsz czas przepływu

Zawodowcy, zajmujący się tworzeniem oprogramowania i naukowcy, którzy badają inżynierię oprogramowania, tradycyjnie koncentrują się na pomiarze czasu spędzonego na pracy nad daną czynnością.Społeczność rozwoju oprogramowania Lean odkryła, że być może bardziej użyteczny jest pomiar rzeczywistego czasu kalendarza, który zajęło przetworzenie czegoś.Zwykle jest to określone jako czas cyklu i jest zazwyczaj kwalifikowane przez granice wykonywanych czynności.Na przykład czas cyklu od analizy do gotowości do wdrożenia mierzyłby całkowity czas trwania elementu pracy, takiego jak historyjka użytkownika, obejmującego analizę, zaprojektowane, wytworzenie, testowanie na kilka sposobów i oczekiwanie w kolejce gotowych do wdrożenia w środowisku produkcyjnym.

Skoncentrowanie się na czasie, jaki pochłaniają prace na kolejnych etapach procesu, jest ważne na kilka sposobów.Wykazano, że dłuższe czasy cyklu są skorelowane z nieliniowym wzrostem liczby błędów.Stąd krótsze czas cyklu prowadzą do wyższej jakości.Jest to niezrozumiałe, ponieważ wydaje się absurdalne, że w kodzie mogą znaleźć się wady, skoro żaden człowiek nie miał do niego dostępu.Tradycyjnie, profesjonalna inżynieria oprogramowania i pracownicy naukowi zajmujący się tą dziedziną ignorowali ten czas bezczynności.Jednakże dowody empiryczne sugerują, że czas cyklu jest ważny dla początkowej jakości.

Alan Shalloway również mówił o koncepcji „pracy wywoływanej”. Jego obserwacja jest taka, że opóźnienie w wykonywaniu zadania może prowadzić do poświęcenia na nie znacznie większego wysiłku, niż trzeba.Na przykład błąd znaleziony szybko i naprawiany od razu może zostać usunięty tylko w 20 minut, ale jeśli taki błąd zostanie sklasyfikowany, umieszczony w kolejce i następnie czeka kilka dni lub tygodni na interwencję, jego naprawa może obejmować kilka lub wiele godzin.Stąd opóźnienie czasu cyklu „wywołało” dodatkową pracę.Ponieważ pracy tej można uniknąć, w kategoriach metodyki odchudzonej musi być postrzegana jako „strata”.

Trzeci powód koncentrowania się na czasie jest związany z branżą.Każda funkcja lub historyjka użytkownika ma wartość.Wartość ta może być niepewna, ale jednak istnieje.Wartość może ulec zmianie z upływem czasu.Pojęcie wartości różnej w czasie można ekonomicznie wyrazić jako funkcję opłacalności rynku.Gdy funkcja opłacalności rynku dla elementu pracy jest zrozumiała, nawet jeśli funkcja pokazuje rozkład wartości do niepewności modelu, istnieje możliwość oszacowania „kosztu opóźnienia”. Koszt opóźnienia pozwala umieścić wartość skrócenia czasu cyklu.

W przypadku niektórych elementów pracy funkcja opłacalności rynku nie jest uruchamiana do znanej daty w przyszłości.Na przykład funkcja zaprojektowana do użytku podczas święta 4 lipca w Stanach Zjednoczonych nie ma wartości przed tą datą.Skrócenie czasu cyklu i zdolność przewidywania czasu cyklu z pewną dokładnością jest nadal przydatna w takim przypadku.W warunkach idealnych chcemy rozpoczęcia prac tak, aby funkcja została dostarczona „dokładnie na czas”, kiedy jest potrzebna, nie znacznie przed żądaną datą, ani za późno, ponieważ opóźnienie dostawy powoduje koszty.Dostarczenie just-in-time gwarantuje, że optymalnie wykorzystano dostępne zasoby.Wczesna dostawa oznacza, że mogliśmy pracować nad czymś innym i co za tym idzie, poniesliśmy dla szansy koszt polegający na opóźnieniu.

W wyniku tych trzech powodów metodyka odchudzonego tworzenia oprogramowania stara się zminimalizować czas przepływu i rejestrować dane, które umożliwią prognozowanie czasu przepływu.Celem jest minimalizacja zapotrzebowania na reakcję na awarię z powodu usterek, niepotrzebnych działań wynikających z nadmiernego obciążenia w celu opóźnienie poprawek usterek, oraz maksymalizacji dostarczonej wartości, dzięki uniknięciu kosztów zwłoki i kosztu opóźnienia.

Zmniejsz odpady w celu poprawy efektywności

Dla każdego działania generującego wartość dodaną istnieją działania instalacji, oczyszczania i dostarczenia, które są niezbędne, ale same nie dodają wartości.Na przykład iteracja projektu, która tworzy przyrost w postaci działającego oprogramowania, wymaga planowania (działanie instalacji), środowiska i prawdopodobnie gałęzi kodu w kontroli wersji (nazywanych zbiorczo zarządzaniem konfiguracją, a także działaniem instalacji), planu wydania i wykonaniem rzeczywistego wydania (działanie dostawy), pokazania klientowi (działanie dostawy) i prawdopodobnie demontażu lub ponownej konfiguracji środowiska (działanie czyszczenia). W kategoriach ekonomicznych działania instalacji, oczyszczania i dostarczania są kosztami transakcji przy wykonywaniu pracy generującej wartość dodaną.Te koszty (zwane też kosztami ogólnymi) są uważane za straty w metodyce odchudzonego myślenia.

Każdą formę nakładów na komunikację można uznać za straty.Spotkania w celu ustalania stanu projektu i utworzenia harmonogramu lub przypisania pracy członkom zespołu będą uważane za koszt koordynacji w języku ekonomii.Wszystkie koszty koordynacji są stratami w metodyce odchudzonego myślenia.Metody odchudzonego tworzenia oprogramowania starają się wyeliminować lub zmniejszyć koszty koordynacji przez użycie kolokacji członków zespołu, krótkich spotkań twarzą w twarz takich jak codzienne spotkania, oraz kontrolę wizualną, takich jak ściany z karteczkami.

Trzecią popularną formą odpadów w Lean Software Development jest żądanie awarii.Żądanie pousterkowe jest obciążeniem dla systemu tworzenia oprogramowania.Żądanie pousterkowe dotyczy zazwyczaj przeróbki lub innej formy pracy generowanej jako efekt uboczny niskiej jakości.Najbardziej typowe formularze zgłaszania awarii w rozwoju oprogramowania to usterki, wady produkcji i działania obsługi klienta wypływające z braku możliwości korzystania z oprogramowania zgodnie z jego przeznaczeniem.Procent pracy w toku, podczas której często występuje awaria, to obciążenie z awarią.Procent pracy przynoszącej wartość dodaną w stosunku do występowania awarii to miernik skuteczności systemu.

Procent wartości dodanej działań w porównaniu do całkowitej pracy, w tym wszystkie koszty transakcji i koordynacji niedające wartości dodanej, określający poziom skuteczności.System bez kosztów transakcji i koordynacji oraz bez obciążenia awariami byłby uważany za 100-procentowo skuteczny.

Tradycyjnie zachodnia nauka zarządzania naucza, że można poprawić wydajność przez zwiększenie rozmiaru partii pracy.Zazwyczaj koszty transakcji i koordynacji są ustalone lub nieznacznie rosną wraz ze wzrostem rozmiaru partii.W rezultacie duże partie pracy są bardziej efektywne.Pojęcie to jest znane jako „ekonomia skali”. Jednak w problemach w pracy opartej na wiedzy koszty koordynacji zwykle wzrastają nieliniowo ze wzrostem partii, podczas gdy koszty transakcji często wykazują wzrost liniowy.W rezultacie tradycyjne XX-wieczne podejście do efektywności nie jest właściwe dla problemów w pracy opartej na wiedzy, takiej jak tworzenie oprogramowania.

Lepiej jest skupić się na zmniejszeniu obciążeń przy zachowaniu małych wielkości partii w celu poprawy efektywności.Dlatego efektywność w metodyce odchudzonej polega na zmniejszeniu strat.Metody odchudzonego tworzenia oprogramowania skupiają się na szybkich, tanich i sprawnych metodach planowania; niskim obciążeniu komunikacją; oraz skutecznych i nieobciążających mechanizmach koordynacji, takich jak kontrole wizualne w systemach kanban.Zachęcają one również do automatycznego testowania i zautomatyzowanego wdrażania, aby obniżyć koszty transakcji dostawy.Nowoczesne narzędzia służące zminimalizowaniu kosztów instalacji i usuwania środowiska, takie jak nowoczesne systemy kontroli wersji, oraz stosowanie wirtualizacji również pomagają poprawić wydajność małych partii tworzenia oprogramowania.

Praktyki

Metodyka odchudzonego tworzenia oprogramowania nie przepisuje żadnych praktyk.Ważniejsze jest wykazanie, że rzeczywiste definicje procesów są dopasowane do zasad i wartości.Jednakże pewna liczba praktyk jest powszechnie przyjmowana.Ta sekcja zawiera krótkie omówienie niektórych z nich.

Zbiorcze diagramy przepływu

Zbiorcze diagramy przepływu są standardową częścią raportowania w programie Team Foundation Server od wersji 2005.Zbiorcze diagramy przepływu to wykresy powierzchniowe łącznie wszystkich elementów pracy na każdym etapie przepływu pracy.Są bogate w informacje i mogą być użyte do uzyskania średniego czasu cyklu między krokami w procesie, jak również prędkości przepływności (zwanej "prędkością").Różne procesy tworzenia oprogramowania generują różne wizualne podpisy na zbiorczych diagramach przepływu.Praktykujący mają szansę nauczyć się rozpoznawać wzorce dysfunkcji w procesie przedstawionym na wykresie obszaru.W prawdziwie odchudzonym procesie będzie widać równomiernie rozłożone obszary koloru, o płynnie rosnącym nasyceniu w stałym tempie.Obraz będzie wyświetlany bez postrzępionych linii i widocznych bloków koloru.

W najprostszej postaci zbiorcze diagramy przepływu są używane do wizualizacji ilość pracy w toku na każdy etap w cyklu życia elementu pracy.Można tego używać do wykrywania wąskich gardeł i obserwowania skutków "mura" (zmienności przepływu).

Formanty wizualne

Oprócz stosowania zbiorczych diagramów przepływu zespoły korzystające ze zwinnego tworzenia oprogramowania używają fizycznych tablic lub projekcji z elektronicznych systemów wizualizacji do wizualizacji pracy i obserwowania jej przepływu.Takie wizualizacje pomagają członkom zespołu obserwować prowadzone prace i umożliwiają im skupienie się na wąskim gardle oraz efektach „mura”. Formanty wizuane pozwalają również członkom zespołu na organizację pracy i współpracę bez planowania, określonych wskazówek kierowniczych ani interwencji.Te formanty wizualne są często określane jako "ściany z karteczkami" lub czasem (niepoprawnie) jako "płyty kanban".

Wirtualne systemy Kanban

System kanban to praktyka przyjęta z metodyki produkcji odchudzonej.Używa systemu fizycznych kart do ograniczenia ilości pracy w toku na każdym etapie przepływu pracy.Takie systemy ograniczonego nakładu pracy w toku tworzą „wciąganie”, dzięki któremu zaczyna się nowe zadanie, gdy istnieją wolne kanban wskazujące, że nowe zadanie może zostać „wciągnięte” do określonego stanu, a praca zostanie wykonana w większym stopniu zaawansowania.

W odchudzonym wytwarzaniu oprogramowania obiekty kanban są wirtualne i często śledzone przez ustawienie maksymalnej liczby dla danego etapu w przepływie pracy dla typu elementu pracy.W niektórych implementacjach elektroniczne systemy śledzą wirtualne obiekty kanban i wysyłają sygnał, gdy można rozpocząć nową pracę.Sygnał może być wizualny lub w formie alertu, takiego jak wiadomość e-mail.

Wirtualne systemy Kanban często są łączone z formantami wizualnymi, tworząc wizualny wirtualny system Kanban reprezentujący jeden lub kilka typów elementów pracy.Takie systemy są często określane jako „karty kanban” lub „elektroniczne systemy kanban”. Wizualny system witualny kanban jest udostępniany jako wtyczka dla Team Foundation Server o nazwie PWT Visual[20].Ten projekt został opracowany jako open source przez Hakana Forssa w Szwecji.

Małe rozmiary partii/mały przepływ pojedynczego elementu

Metodyka odchudzonego tworzenia oprogramowania wymaga, aby praca była podejmowana w małych porcjach, często określanych jako „iteracje” lub „przyrostach”, lub aby elementy pracy przepływały niezależnie, co jest określane jako „przepływ jednoelementowy”. Przepływ jednoelementowy wymaga zaawansowanej strategii zarządzania konfiguracją, aby umożliwić wykonanej dostarczanie wykonanej pracy oraz zapobiec przypadkowemu zwalnianiu niekompletnej pracy.Zazwyczaj jest to osiągane przy użyciu strategii rozgałęzienia w systemie kontroli wersji.Za małą partię pracy zazwyczaj uważana się partię, którą może wykonać niewielki zespół maksymalnie 8 osób w terminie poniżej 2 tygodni.

Małe partie oraz przepływ pojedynczego elementu wymagają interakcji z właścicielami działalności biznesowej, aby zniwelować zaległości, kolejkę lub wykonać pracę.Wymagają one także możliwości częstych wydań.Aby włączyć częste interakcje z ludźmi biznesu i częste dostawy, należy zmniejszyć koszty transakcji i koordynacji obu działań.Powszechny sposób osiągnięcia tego to wykorzystanie automatyzacji.

Automatyzacja

Metodyka odchudzonego tworzenia oprogramowania oczekuje wysokiego poziomu automatyzacji, aby ekonomicznie uzasadnić przepływ jednoelementowy i wspierać wysoką jakość oraz zmniejszenie i zmniejszenia żądań pousterkowych.Użycie automatycznego testowania zautomatyzowanego wdrażania i fabryk oprogramowania do zautomatyzowania wdrażania wzorców projektowania oraz tworzenie powtarzalnych sekcji kodu źródłowego o niskiej zmienności będzie powszechne w procesach programowania oprogramowania typu Lean.

Zdarzenia kaizen

W literaturze poświęconej metodyce odchudzonej termin kaizen oznacza „ciągłą poprawę”, a zdarzenie kaizen to czynność wprowadzania zmiany w procesie lub narzędziu, która, mamy nadzieję, przyniesie poprawę.

Procesy odchudzonego tworzenia oprogramowania używają kilku różnych działań do generowania zdarzeń kaizen.Są one wymienione poniżej.Każde z tych działań jest przeznaczone do stymulowania konwersacji o problemach, które szkodliwie wpływają na możliwości i w konsekwencji na zdolność realizacji żądań.Istota kaizen w pracy wymagającej wiedzy polega na tym, że należy prowokować rozmowy na temat problemów w grupie osób z różnych zespołów i o różnych umiejętnościach.

Codzienne spotkanie

Zespoły programistów, często składające się z maksymalnie 50 osób, zazwyczaj spotykają się przy wizualnym systemie kontroli, takim jak biała tablica wyświetlająca wizualizację ich aktualnej pracy.Omawiają dynamikę przepływu oraz czynniki wpływające na przepływ pracy.Szczególna uwaga jest poświęcona pracy blokowanej zewnętrznie i pracy opóźnianej przez usterki.Problemy z procesu często stają się oczywiste po serii spotkań wprowadzających.Wynik oznacza, że mniejsza grupa może pozostać po spotkaniu w celu omówienia problemu i zaproponowania rozwiązania lub zmiany procesu.Nastąpi zdarzenie kaizen.Te spontaniczne posiedzenia są nazywane często spontanicznymi kręgami jakości w starszych pozycjach literatury fachowej.Takie spontaniczne spotkania są podstawą kultury kaizen.Menedżerowie będą zachęcać do powstania zdarzeń kaizen po codziennych spotkaniach w celu promowania metodyki odchudzonej w swojej organizacji.

Kolekcje

Zespoły pracujące nad projektem mogą planować regularne spotkania, aby dyskutować o postępach.Są one często wykonywane po ukończeniu produktów cząstkowych projektu lub po przyrostach programistycznych w wyznaczonym czasie, znanych jako iteracje lub sprinty w programowaniu oprogramowania Agile.

Kolekcje zazwyczaj używają podejścia anegdotycznego do odczuć, zadając pytania typu: „co poszło dobrze?”, „co mogliśmy zrobić inaczej?” czy „co powinniśmy przestać robić?"

Kolekcje tworzą zazwyczaj dzienniki z sugestiami dotyczącymi zdarzeń kaizen.Zespół może następnie priorytetyzować niektóre z nich w celu implementacji.

Przeglądy operacji

Przegląd operacji jest zazwyczaj większy niż retrospektywa i obejmuje przedstawicieli z całego strumienia wartości.Jest typowe, że nawet 12 działów prezentuje obiektywne, ilościowe dane pokazujące zgłoszony popyt i odzwierciedlające możliwość jego zaspokojenia.Przeglądy operacji są zazwyczaj przechowywane co miesiąc.Główne różnice między przeglądem działań i retrospektywą polegają na tym, że przeglądy działań dotyczą szerszego zestawu funkcji, zwykle obejmują portfolio projektów i innych działań, a ponadto korzystają z obiektywnych danych ilościowych.Kolekcje, dla porównania, zwykle obejmują zakresem pojedynczy projekt; obejmują kilka zespołów, jak zespół analizy, rozwoju czy badań; i mają ogólnie anegdotyczny charakter.

Przegląd operacji będzie powodować dyskusje na temat wzajemnej dynamiki wpływającej na funkcjonowanie zespołów.Prawdopodobnie jeden zespół generuje żądanie pousterkowe, które jest przetwarzane przez inny zespół.Może to żądanie pousterkowe jest szkodliwe i powoduje, że drugi zespół nie wywiązuje się z zobowiązań oraz nie spełnia oczekiwań?Przegląd operacji dostarcza możliwości omówienia takich problemów i zaproponowania zmian.Przeglądy operacji zazwyczaj tworzą małe zaległości zdarzeń kaizen, które mogą być ustalone jako priorytet i zaplanowane do przyszłej implementacji.

Nie istnieje nic takiego jak pojedynczy proces programowania oprogramowania Lean.Proces można uznać za odchudzony, jeżeli jest wyraźnie dopasowany do wartości i zasad metodyki odchudzonego tworzenia oprogramowania.Metodyka odchudzonego tworzenia oprogramowania nie przepisuje żadnych praktyk, ale niektóre działania stały się popularne.Organizacje stosujące metodykę odchudzoną zachęcają do stosowania metodyki kaizen przez wizualizację przepływu pracy i pracy w toku oraz zrozumienie dynamiki przepływu i czynników wpływające na niego (np wąskie gardła, brak natychmiastowej dostępności, zmienność, straty).Udoskonalenia procesu są sugerowane i uzasadnione jako sposoby zmniejszenia źródeł zmienności, wyeliminowania odpadów, poprawy przepływu lub zwiększenia wartości dostawy lub zarządzania ryzykiem.W związku z tym procesu odchudzonego tworzenia oprogramowania zawsze będą ewoluowały i specyficznie dostosowywały się do organizacji, w której ewoluują.Nie będzie naturalne po prostu skopiować definicję procesu z jednej organizacji do innej i spodziewać się, że będzie działała w innym kontekście.Jest również mało prawdopodobne, aby po powrocie do organizacji po kilka tygodniach lub miesiącach okazało się, że używany proces jest taki sam, jak zaobserwowano wcześniej.Zawsze będzie on ewoluował.

Można powiedzieć, że organizacja korzystająca z procesu rozwoju oprogramowania Lean jest Lean, jeśli wynikiem jej działania jest tylko niewielka ilość odpadów we wszystkich trzech formularzach ("mura", "muri" i "muda") i może wykazać się optymalizacją dostarczania wartości poprzez skuteczne zarządzanie ryzykiem.Dążenie do doskonałości w Lean to zawsze wyzwanie.Brak obiektu docelowego.Prawdziwie chude organizacje zawsze szukają możliwości dalszej poprawy.

Odchudzone tworzenie oprogramowania to wciąż nowa dziedzina i spodziewamy się jej ewoluowania w ciągu następnej dekady.

1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

2. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

3. Womack, James P., Daniel T.Jones i Daniel Roos, The Machine That Changed the World: The Story of Lean Production, wydanie zaktualizowane z 2007 r., Free Press, 2007

4. Womack, James P. i Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, wydanie drugie, Free Press, 2003

5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Poppendieck, Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Poppendieck, Mary and Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James i Peter Middleton, Lean Software Strategies : Proven Techniques for Managers and Developers, Productivity Press, 2005

13. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

14. Alan Shalloway, Guy Beaver oraz James R.Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

15. Larman, Craig i Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.i Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/