Adaptive S / W Development - Quick Guide
Co to jest Agile?
W sensie literackim słowo „zwinny” oznacza kogoś, kto potrafi szybko i łatwo działać lub kogoś, kto potrafi myśleć i działać szybko i jasno. W biznesie termin „zwinny” jest używany do opisywania sposobów planowania i wykonywania pracy, przy czym rozumie się, że wprowadzanie zmian w razie potrzeby jest ważną częścią pracy. „Zwinność” biznesowa oznacza, że firma jest zawsze w stanie uwzględnić zmiany rynkowe.
W tworzeniu oprogramowania termin „zwinny” jest dostosowany do określenia „zdolności reagowania na zmiany - zmiany wynikające z wymagań, technologii i ludzi”.
Manifest Agile
Manifest Agile został opublikowany przez zespół programistów w 2001 roku, podkreślając znaczenie zespołu programistów, dostosowując się do zmieniających się wymagań i zaangażowania klientów.
Manifest Agile to -
Odkrywamy lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym. Dzięki tej pracy doszliśmy do wartości -
- Osoby i interakcje nad procesami i narzędziami.
- Działające oprogramowanie ponad obszerną dokumentację.
- Współpraca z klientem zamiast negocjacji umowy.
- Reagowanie na zmianę zgodnie z planem.
Oznacza to, że podczas gdy elementy po prawej stronie mają wartość, bardziej cenimy elementy po lewej stronie.
Charakterystyka zwinności
Oto cechy Agility -
Agility in Agile Software Development koncentruje się na kulturze całego zespołu z wielodyscyplinarnymi, wielofunkcyjnymi zespołami, które są uprawnione i samoorganizujące się.
Sprzyja wspólnej odpowiedzialności i rozliczalności.
Ułatwia skuteczną komunikację i ciągłą współpracę.
Podejście obejmujące cały zespół pozwala uniknąć opóźnień i czasów oczekiwania.
Częste i ciągłe dostawy zapewniają szybką informację zwrotną, która z kolei umożliwia zespołowi dostosowanie się do wymagań.
Współpraca ułatwia łączenie różnych perspektyw w odpowiednim czasie we wdrażaniu, naprawianie defektów i dostosowywanie zmian.
Postęp jest stały, trwały i przewidywalny, z naciskiem na przejrzystość.
Zwinne metodologie
Wczesne wdrożenia metod Agile obejmują Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development oraz Dynamic Systems Development Method (DSDM). Są one obecnie zbiorczo określane jako metodologie Agile, po opublikowaniu manifestu Agile w 2001 roku.
W tym samouczku nauczymy się metodologii Agile - Adaptive Software Development.
Co to jest adaptacyjne tworzenie oprogramowania?
Adaptacyjne tworzenie oprogramowania jest krokiem w kierunku praktyk adaptacyjnych, pozostawiając praktyki deterministyczne w kontekście złożonych systemów i złożonych środowisk. Adaptive Software Development koncentruje się na współpracy i uczeniu się jako technice tworzenia złożonych systemów. Wywodzi się z najlepszych praktyk Rapid Application Development (RAD) i Evolutionary Life Cycles. Adaptacyjne tworzenie oprogramowania zostało następnie rozszerzone o adaptacyjne podejście do zarządzania, przy czym planowanie zastąpiło spekulacje.
Jim Highsmith opublikował książkę na temat adaptacyjnego tworzenia oprogramowania w 2000 roku. Według słów Highsmitha -
„Adaptacyjne tworzenie oprogramowania przebiega cyklicznie, podobnie jak model ewolucyjny, z nazwami faz Spekuluj, współpracuj, ucz się, odzwierciedlając nieprzewidywalną sferę coraz bardziej złożonych systemów. Rozwój adaptacyjny idzie dalej niż jego dziedzictwo ewolucyjne na dwa kluczowe sposoby. Po pierwsze, wyraźnie zastępuje determinizm pojawieniem się. Po drugie, wykracza poza zmianę cyklu życia i prowadzi do głębszej zmiany stylu zarządzania ”.
Model cyklu życia oprogramowania (SDLC) to struktura opisująca czynności wykonywane na każdym etapie projektu tworzenia oprogramowania.
W cyklu życia oprogramowania działania są wykonywane w pięciu fazach -
Requirements Gathering- Zbierane są wymagania dotyczące oprogramowania, które ma zostać opracowane. Wymagania te będą w języku zrozumiałym dla klienta / użytkownika. Zalecana jest terminologia specyficzna dla domeny.
Analysis - Zebrane wymagania są analizowane z punktu widzenia implementacji, a specyfikacje oprogramowania są pisane w celu uwzględnienia zarówno wymagań funkcjonalnych, jak i wymagań niefunkcjonalnych.
Design - Ta faza obejmuje ustalenie architektury oprogramowania i specyfiki implementacji w oparciu o technologię wybraną do rozwoju.
Construction - Na tym etapie kod jest opracowywany, testowany jednostkowo, integrowany, testowany pod kątem integracji i tworzona jest kompilacja.
Testing- Na tym etapie wykonywane są testy funkcjonalne zbudowanego oprogramowania. Obejmuje to również testowanie wymagań niefunkcjonalnych.
Istnieją dwa podejścia do wykonywania tych czynności -
Prescriptive - Modele SDLC, które zapewnią Ci sposoby wykonywania czynności w określony sposób, zgodnie z definicją ramową.
Adaptive- Modele SDLC, które zapewnią elastyczność w wykonywaniu czynności, z pewnymi zasadami, których należy przestrzegać. Metody zwinne przeważnie są zgodne z tym podejściem, a każda z nich ma swoje zasady. Jednak stosowanie podejścia adaptacyjnego lub zwinnego nie oznacza, że oprogramowanie jest tworzone bez przestrzegania jakiejkolwiek dyscypliny. Doprowadziłoby to do chaosu.
Musisz zrozumieć, że nie możemy powiedzieć, że określony model SDLC jest dobry lub zły. Każdy z nich ma swoje mocne i słabe strony, a zatem nadaje się do określonych kontekstów.
Wybierając model SDLC do swojego projektu, musisz zrozumieć -
- Kontekst Twojej organizacji
- Twój kontekst technologiczny
- Twój skład zespołu
- Twój kontekst klienta
Na przykład, jeśli rozwój oprogramowania jest przewidywalny, możesz zastosować podejście nakazowe. Z drugiej strony, jeśli rozwój oprogramowania jest nieprzewidywalny, tj. Wymagania nie są całkowicie znane lub zespół programistów nie ma wcześniejszego kontaktu z aktualną domeną lub technologią itp., Wówczas najlepszym wyborem jest podejście adaptacyjne.
W kolejnych sekcjach poznasz najbardziej rozpowszechnione modele SDLC, które powstały podczas realizacji projektów tworzenia oprogramowania w całej branży. Dowiesz się również o mocnych i słabych stronach każdego z nich oraz w jakim kontekście się nadaje.
Model Waterfall to klasyczny model SDLC, który jest szeroko znany, rozumiany i powszechnie stosowany. Został wprowadzony przez Royce'a w 1970 roku i nadal jest stosowany jako powszechne podejście do tworzenia oprogramowania w różnych organizacjach w branży.
W modelu wodospadu każda faza cyklu życia może rozpocząć się dopiero po zakończeniu wcześniejszej fazy cyklu życia. Jest to zatem model liniowy bez pętli sprzężenia zwrotnego.
Model wodospadu - mocne strony
Mocne strony modelu Waterfall to -
- Łatwy do zrozumienia, łatwy w użyciu.
- Zapewnia strukturę niedoświadczonemu zespołowi programistów.
- Kamienie milowe są dobrze rozumiane.
- Ustala stabilność wymagań.
- Idealny do kontroli zarządczej (planowanie, monitorowanie, raportowanie).
- Działa dobrze, gdy jakość jest ważniejsza niż koszt lub harmonogram.
Model wodospadu - słabości
Słabości lub wady modelu Waterfall to -
Wyidealizowany - nie pasuje do rzeczywistości.
Nierealistyczne - nie można oczekiwać dokładnych wymagań na wczesnym etapie projektu.
Nie odzwierciedla iteracyjnego charakteru rozwoju eksploracyjnego, który jest bardziej powszechny.
Trudne i drogie zmiany.
Oprogramowanie jest dostarczane dopiero po zakończeniu projektu. Z tego powodu -
Opóźnia wykrycie poważnych usterek.
Możliwość dostarczenia przestarzałych wymagań.
Znaczne koszty zarządzania, które mogą być kosztowne dla małych zespołów i projektów.
Wymaga doświadczonych zasobów na każdym etapie - analityków, projektantów, programistów, testerów.
Testowanie rozpoczyna się dopiero po zakończeniu programowania, a testerzy nie biorą udziału w żadnej z wcześniejszych faz.
Ekspertyza zespołów wielofunkcyjnych nie jest dzielona, ponieważ każda faza jest wykonywana w silosach.
Kiedy używać modelu wodospadu?
Możesz użyć modelu Waterfall, jeśli -
Wymagania są bardzo dobrze znane.
Definicja produktu jest stabilna.
Technologia jest dobrze rozumiana.
Nowa wersja istniejącego produktu.
Przeniesienie istniejącego produktu na nową platformę.
Duża organizacja ze zorganizowanymi zespołami wielofunkcyjnymi.
Kanały komunikacji są dobrze ugruntowane w organizacji, a także z klientem.
Ewolucyjny model prototypowania
Podczas tworzenia oprogramowania przy użyciu modelu Evolutionary Prototyping programiści budują prototyp w fazie wymagań. Następnie użytkownicy końcowi oceniają prototyp i przekazują informacje zwrotne. Informacje zwrotne mogą być poprawkami do prototypu lub dodatkową funkcjonalnością. Na podstawie opinii programiści dopracowują prototyp.
W ten sposób produkt ewoluuje poprzez Prototyp → Opinie → Udoskonalone cykle prototypowe i stąd nazwa Evolutionary Prototyping. Gdy użytkownik jest zadowolony z funkcjonalności i działania produktu, prototypowy kod jest dostosowywany do wymaganych standardów w celu dostarczenia produktu końcowego.
Ewolucyjny model prototypowania - mocne strony
Mocne strony lub zalety ewolucyjnego modelu prototypowania to:
Klienci / użytkownicy końcowi mogą wizualizować wymagania systemowe w miarę gromadzenia się, patrząc na prototyp.
Programiści uczą się od klientów, dzięki czemu nie ma żadnych niejasności dotyczących domeny lub środowiska produkcyjnego.
Umożliwia elastyczne projektowanie i rozwój.
Interakcja z prototypem stymuluje świadomość dodatkowo potrzebnej funkcjonalności.
Niespodziewane wymagania i zmiany wymagań można łatwo dostosować.
Powstają stałe i widoczne oznaki postępu.
Dostawa dokładnego i łatwego do konserwacji produktu końcowego.
Ewolucyjny model prototypowania - słabości
Wady lub wady modelu ewolucyjnego prototypowania są następujące:
Tendencja do porzucania ustrukturyzowanego programowania w tworzeniu kodu i poprawiania, chociaż nie jest to zalecane przez model.
Model ten zyskał złą opinię za metody szybkie i brudne.
Można przeoczyć ogólną łatwość konserwacji.
Klient może ewentualnie poprosić o dostarczenie prototypu jako finalnego, nie dając deweloperom możliwości wykonania ostatniego kroku, czyli standaryzacji produktu końcowego.
Projekt może trwać wiecznie (z ciągłym rozszerzaniem się zakresu) i kierownictwo może tego nie doceniać.
Kiedy używać ewolucyjnego modelu prototypowania?
Możesz użyć modelu Evolutionary Prototyping -
- Gdy wymagania są niestabilne lub wymagają wyjaśnienia
- Jako etap wyjaśnienia wymagań modelu kaskadowego
- Opracowywanie interfejsów użytkownika
- Do krótkotrwałych demonstracji
- Do nowego lub oryginalnego rozwoju
- Za wdrożenie nowej technologii
W modelu iteracyjnym przyrostowym początkowo konstruowana jest częściowa implementacja całego systemu, tak aby był on w stanie dostarczalnym. Dodano zwiększoną funkcjonalność. Ewentualne wady z wcześniejszej dostawy są usuwane i dostarczany jest sprawny produkt. Proces jest powtarzany aż do zakończenia całego rozwoju produktu. Powtórzenia tych procesów nazywane są iteracjami. Pod koniec każdej iteracji dostarczany jest przyrost produktu.
Iteracyjny model przyrostowy - mocne strony
Zalety lub mocne strony iteracyjnego modelu przyrostowego to -
Najpierw możesz opracować wymagania z priorytetami.
Początkowa dostawa produktu jest szybsza.
Klienci wcześnie otrzymują ważne funkcje.
Obniża początkowy koszt dostawy.
Każde wydanie jest przyrostem produktu, dzięki czemu klient przez cały czas będzie miał pod ręką działający produkt.
Klient może przekazać informację zwrotną na temat każdego przyrostu produktu, unikając w ten sposób niespodzianek pod koniec rozwoju.
Zmiany wymagań można łatwo dostosować.
Iteracyjny model przyrostowy - słabości
Wady modelu iteracyjnego przyrostowego to -
Wymaga efektywnego planowania iteracji.
Wymaga wydajnego projektu, aby zapewnić włączenie wymaganej funkcjonalności i możliwość późniejszych zmian.
Wymaga wczesnego zdefiniowania kompletnego iw pełni funkcjonalnego systemu, aby umożliwić zdefiniowanie przyrostów.
Wymagane są dobrze zdefiniowane interfejsy modułów, ponieważ niektóre są opracowywane na długo przed opracowaniem innych.
Całkowity koszt całego systemu nie jest niższy.
Kiedy używać iteracyjnego modelu przyrostowego?
Iteracyjny model przyrostowy może być używany, gdy -
Większość wymagań jest znana z góry, ale oczekuje się, że z czasem będą one ewoluować.
Wymagania mają priorytet.
Istnieje potrzeba szybkiego dostarczenia podstawowych funkcji.
Projekt ma długie harmonogramy rozwoju.
Projekt ma nową technologię.
Domena jest nowa w zespole.
Model Rapid Application Development (RAD) ma następujące fazy -
Requirements Planning phase - Na etapie planowania wymagań należy przeprowadzić warsztaty w celu omówienia problemów biznesowych w uporządkowany sposób.
User Description phase - Na etapie opisu użytkownika zautomatyzowane narzędzia są używane do przechwytywania informacji od użytkowników.
Construction phase - Na etapie konstrukcji narzędzia zwiększające produktywność, takie jak generatory kodu, generatory ekranów itp., Są używane w ramach ram czasowych z podejściem „Wykonuj aż do zakończenia”.
Cut Over phase - W fazie cut over przeprowadza się instalację systemu, testy akceptacyjne użytkowników i szkolenie użytkowników.
Model szybkiego tworzenia aplikacji - mocne strony
Zalety lub mocne strony modelu szybkiego tworzenia aplikacji są następujące:
Skrócony czas cyklu i lepsza produktywność przy mniejszej liczbie członków zespołu oznaczałyby niższe koszty.
Zaangażowanie klienta w całym cyklu minimalizuje ryzyko nieosiągnięcia satysfakcji klienta i wartości biznesowej.
Fokus przechodzi do kodu w trybie „co-widzisz-jest-co-otrzymujesz” (WYSIWYG). Daje to jasność co do tego, co jest budowane, jest właściwą rzeczą.
Wykorzystuje koncepcje modelowania do przechwytywania informacji o biznesie, danych i procesach.
Model szybkiego tworzenia aplikacji - słabości
Wady lub zalety modelu szybkiego tworzenia aplikacji są następujące:
Przyspieszony proces rozwoju musi dawać użytkownikowi szybką odpowiedź.
Ryzyko nieosiągnięcia zamknięcia.
Trudne w użyciu ze starszymi systemami.
Deweloperzy i klienci muszą być zaangażowani w szybkie działania w skróconych ramach czasowych.
Kiedy stosować model szybkiego tworzenia aplikacji?
Model szybkiego tworzenia aplikacji może być używany, gdy -
- Użytkownik może uczestniczyć w całym cyklu życia.
- Projekt może być ograniczony czasowo.
- Funkcjonalność może być dostarczana przyrostowo.
Choć doceniane są mocne strony modelu Rapid Application Development, jest on rzadko używany w przemyśle.
Model spiralny dodaje analizę ryzyka i prototypowanie RAD do modelu wodospadu. Każdy cykl obejmuje tę samą sekwencję kroków, co model wodospadu.
Model spiralny ma cztery ćwiartki. Omówmy je szczegółowo.
Kwadrant 1 - Określ cele, alternatywy i ograniczenia
Objectives - Funkcjonalność, wydajność, interfejs sprzętowy / programowy, krytyczne czynniki sukcesu itp.
Alternatives - Buduj, wykorzystuj ponownie, kupuj, podzlecaj itp.
Constraints - Koszt, harmonogram, interfejs itp.
Kwadrant 2 - Oceń alternatywy, zidentyfikuj i rozwiązuj ryzyko
Zbadaj alternatywy w odniesieniu do wyznaczonych celów i ograniczeń.
Zidentyfikuj ryzyka, takie jak brak doświadczenia, nowa technologia, napięte harmonogramy itp.
Rozwiąż zidentyfikowane ryzyka, oceniając ich wpływ na projekt, określając potrzebne plany łagodzące i awaryjne oraz wdrażając je. Ryzyka zawsze muszą być monitorowane.
Kwadrant 3 - Opracuj produkt wyższego poziomu
Typowe działania obejmują -
- Stwórz projekt
- Przejrzyj projekt
- Opracuj kod
- Sprawdź kod
- Produkt testowy
Kwadrant 4 - Zaplanuj następną fazę
Typowe działania obejmują -
- Opracuj plan projektu
- Opracuj plan zarządzania konfiguracją
- Opracuj plan testów
- Opracuj plan instalacji
Model spiralny - mocne strony
Zalety lub mocne strony metody Spiral to -
- Zapewnia wczesne wskazanie zagrożeń bez ponoszenia dużych kosztów.
- Użytkownicy mogą wcześnie przeglądać system dzięki narzędziom do szybkiego prototypowania.
- Krytyczne funkcje wysokiego ryzyka są opracowywane w pierwszej kolejności.
- Projekt nie musi być doskonały.
- Użytkownicy mogą być ściśle zaangażowani we wszystkie etapy cyklu życia.
- Wczesne i częste informacje zwrotne od użytkowników.
- Skumulowane koszty często oceniane.
Model spiralny - słabości
Wady lub słabości metody Spiral to -
Może być trudno zdefiniować cele, weryfikowalne kamienie milowe, które wskazują na gotowość do przejścia przez następną iterację.
Czas spędzony na planowaniu, resetowaniu celów, przeprowadzaniu analizy ryzyka i tworzeniu prototypów może być narzutem.
Czas poświęcony na ocenę ryzyka może być zbyt długi w przypadku projektów małych lub o niskim ryzyku.
Model spiralny jest trudny do zrozumienia dla nowych członków zespołu.
Wymagana jest specjalistyczna ocena ryzyka.
Spirala może trwać w nieskończoność.
Deweloperzy muszą zostać ponownie przydzieleni podczas czynności w fazie rozwoju.
Kiedy używać modelu spiralnego?
Model spiralny może być używany, gdy -
- Stworzenie prototypu jest właściwe.
- Ocena ryzyka jest ważna.
- Projekt charakteryzuje się średnim lub wysokim ryzykiem.
- Użytkownicy nie są pewni swoich potrzeb.
- Wymagania są złożone.
- Linia produktów jest nowa.
- Podczas poszukiwań spodziewane są znaczące zmiany.
- Długoterminowe zaangażowanie w projekt jest nierozsądne z powodu potencjalnych zmian biznesowych.
Metody Agile są oparte na manifeście Agile i mają charakter adaptacyjny. Zwinne metody zapewniają -
- Praca drużynowa.
- Współpraca z klientami.
- Stała i ciągła komunikacja.
- Odpowiedź na zmiany.
- Gotowość działającego produktu.
Powstało kilka metod Agile, promujących iteracyjny i przyrostowy rozwój z iteracjami ograniczonymi czasowo. Chociaż metody Agile są adaptacyjne, nie można ich ominąć, a zatem wymagają zdyscyplinowanej implementacji.
Metody zwinne - mocne strony
Zalety lub mocne strony metody Agile to -
- Wczesne i częste wydania.
- Dostosowanie do zmieniających się wymagań.
- Codzienna komunikacja między klientem a programistami.
- Projekty zbudowane wokół zmotywowanych osób.
- Zespoły samoorganizujące się.
- Prostota, skupienie się na tym, co jest natychmiast potrzebne.
- Żadnego budowania na przyszłość ani przeciążania kodu.
- Regularne refleksje w celu dostosowania zachowania w celu poprawy skuteczności.
Metody zwinne - słabości
Wady lub wady metody Spiral to -
Dostępność klienta może nie być możliwa.
Zespoły powinny mieć doświadczenie w przestrzeganiu zasad metody.
Aby szybko zdecydować o funkcjonalności, która ma zostać dostarczona w iteracji, wymagane jest odpowiednie planowanie.
Od zespołu oczekuje się umiejętności szacowania i negocjacji.
Zespół powinien mieć skuteczne umiejętności komunikacyjne.
Nowe zespoły mogą nie być w stanie się zorganizować.
Wymaga dyscypliny, aby rozwijać i dostarczać w iteracjach ograniczonych czasowo.
Projekt musi być prosty i łatwy w utrzymaniu, co wymaga efektywnych umiejętności projektowych.
Kiedy stosować metody Agile?
Metody Agile mogą być używane, gdy -
Aplikacja jest krytyczna czasowo.
Zakres jest ograniczony i mniej formalny (trwa skalowanie metod zwinnych do większych projektów, z pewnymi rozszerzeniami niektórych metod zwinnych).
Organizacja stosuje zdyscyplinowane metody.
Wcześniejsze modele SDLC są bardziej zorientowane na praktyki stabilności, przewidywalności i malejących zwrotów. Branża, taka jak platformy internetowe, zmierza w kierunku zwiększenia liczby zwrotów, nieprzewidywalnych, nieliniowych i szybkich podejść.
Adaptive Software Development (ASD) ewoluowało, aby rozwiązać te problemy. Koncentruje się na pojawianiu się jako najważniejszym z punktu widzenia kierownictwa czynniku zwiększającym zdolność do zarządzania rozwojem produktu.
Według Jima Highsmitha „Platforma Adaptive Software Development opiera się na wieloletnim doświadczeniu z tradycyjnymi metodologiami rozwoju oprogramowania, konsultowaniu, ćwiczeniu i pisaniu na temat technik szybkiego tworzenia aplikacji (RAD) oraz współpracy z firmami oferującymi zaawansowane technologicznie oprogramowanie w zakresie zarządzania rozwojem ich produktów praktyki ”.
Stwierdzono, że model wodospadu charakteryzuje się liniowością i przewidywalnością, przy niewielkim sprzężeniu zwrotnym. Można go postrzegać jako sekwencjęPlan → Build → Implement.
Modele ewolucyjnego cyklu życia, takie jak model spiralny, przeniosły podejście deterministyczne do podejścia adaptacyjnego, z Plan → Build → Revise Cycles.
Jednak nastawienie praktyków pozostawało deterministyczne, a przewidywalność długoterminowa zmieniła się w przewidywalność krótkoterminową. Stwierdzono, że praktyki ewolucyjnych modeli cyklu życia, takie jak RAD, są mniej deterministyczne.
Adaptacyjny cykl życia
Model adaptacyjny jest zbudowany z innego punktu widzenia. Nazwy faz, choć cykliczne, jak model ewolucyjny, odzwierciedlają nieprzewidywalną naturę coraz bardziej złożonych systemów.
Rozwój adaptacyjny idzie dalej niż jego dziedzictwo ewolucyjne na dwa kluczowe sposoby -
Wyraźnie zastępuje determinizm przejawem Pojawienia się.
Wykracza poza zmianę cyklu życia i prowadzi do głębszej zmiany stylu zarządzania.
Trzy fazy cyklu życia adaptacyjnego tworzenia oprogramowania to -
Speculate - Spekuluj zastępuje deterministyczne planowanie słów, planowanie specyfikacji produktów lub planowanie zadań związanych z zarządzaniem projektami.
Collaborate - Współpraca reprezentuje zachowanie równowagi między
Zarządzanie w tradycyjnym sensie zarządzania projektami oraz
Tworzenie i utrzymywanie środowiska współpracy potrzebnego do powstania.
Learn - Celem uczenia się, zarówno dla programistów, jak i klientów, jest wykorzystanie wyników każdego cyklu rozwoju do poznania kierunku następnego.
Działania oparte na współpracy tworzą produkty, nadążając za zmianami zachodzącymi w środowisku.
W tym rozdziale zrozumiemy różne koncepcje adaptacyjnego tworzenia oprogramowania.
Teoria Złożonych Systemów Adaptacyjnych (CAS)
Brian Arthur i jego koledzy z instytutu Santa Fe wykorzystali teorię Złożonych Systemów Adaptacyjnych (CAS), aby zrewolucjonizować rozumienie fizyki, biologii, ewolucji i ekonomii.
Brian Arthur zakończył ponad dwie dekady prób przekonania ekonomistów głównego nurtu, że ich pogląd, zdominowany przez fundamentalne założenia dotyczące malejących zwrotów, równowagi i deterministycznej dynamiki, nie wystarcza już do zrozumienia rzeczywistości. Nowy świat to coraz większe zwroty, niestabilność i niezdolność do określenia przyczyny i skutku.
Te dwa światy różnią się zachowaniem, stylem i kulturą. Wzywają -
- Różne techniki zarządzania
- Różne strategie
- Różne rozumienie
Złożone tworzenie oprogramowania
Wraz z eksplozją zakresu aplikacji, nawet organizacje zajmujące się tworzeniem oprogramowania mają podobne sprzeczności, jak wspomniano powyżej.
Jeden świat jest reprezentowany przez rozwój deterministyczny, wywodzący się z praktyk zarządzania, które są zakorzenione w podstawach stabilności i przewidywalności (co w kategoriach Arthura oznacza malejące zyski)
Drugi świat jest reprezentowany przez branże przechodzące od środowisk malejących do rosnących zwrotów, które są nieprzewidywalne, nieliniowe i szybkie.
Aby rozwiązać problemy tego drugiego świata, Jig Highsmith zaoferował strukturę, adaptacyjne tworzenie oprogramowania, która różni się od deterministycznego rozwoju oprogramowania.
Adaptive Software Development koncentruje się na rozwiązywaniu złożonych systemów -
Adaptacyjne tworzenie oprogramowania na potrzeby cyklu rozwojowego.
Adaptacyjne techniki zarządzania wymagające innego sposobu myślenia niż tradycyjne praktyki zarządzania projektami.
W tym samouczku możesz zrozumieć obie te implementacje.
Adaptacyjne tworzenie oprogramowania (ASD) opiera się na dwóch perspektywach -
Perspektywa pojęciowa oparta na teorii Złożonych Systemów Adaptacyjnych (CAS), jak podano w pierwszej części tego rozdziału.
Praktyczna perspektywa oparta na
Lata doświadczenia z deterministycznymi metodologiami tworzenia oprogramowania.
Doradztwo, ćwiczenia i pisanie na temat technik szybkiego tworzenia aplikacji (RAD); oraz współpracę z firmami oferującymi zaawansowane technologie przy zarządzaniu rozwojem ich produktów.
W tym rozdziale poznasz koncepcyjną perspektywę adaptacyjnego tworzenia oprogramowania.
Koncepcje złożonych systemów adaptacyjnych (CAS)
Teoria Złożonych Systemów Adaptacyjnych (CAS) ma wiele koncepcji. Adaptacyjne tworzenie oprogramowania opiera się na dwóch z tych koncepcji -
- Emergence
- Complexity
Powstanie
W złożonych projektach rozwoju oprogramowania wyniki są z natury nieprzewidywalne. Jednak udane produkty cały czas wyłaniają się z takich środowisk.
Może się to zdarzyć przez Pojawienie się, jak ilustruje teoria Złożonych Systemów Adaptacyjnych (CAS). Można to zrozumieć na prostym przykładzie zachowania ptaków w stadach.
Kiedy obserwujesz stado ptaków, zauważasz, że -
Każdy ptak próbuje
Zachowaj minimalną odległość od innych obiektów w środowisku, w tym innych ptaków.
Dopasuj prędkości do ptaków w sąsiedztwie.
Skieruj się w stronę dostrzeganego środka masy ptaków w jej sąsiedztwie.
Nie ma żadnych reguł zachowania dla grupy. Jedyne zasady dotyczą zachowania poszczególnych ptaków.
Jednak pojawia się pojawiające się zachowanie, stada ptaków. Kiedy zbłąkane ptaki pędzą, aby dogonić, stado rozdziela się wokół przeszkód i reformuje się po drugiej stronie.
Pokazuje to wymóg najtrudniejszych zmian modelu mentalnego w rozwoju adaptacyjnym - od sposobów zarządzania i organizowania tej indywidualnej wolności po pogląd, że nowy, twórczy porządek wyłania się w nieprzewidywalny sposób ze spontanicznej samoorganizacji.
Poza rozwojem najważniejszą koncepcją z punktu widzenia zarządzania jest pojawienie się.
Złożoność
W kontekście rozwoju oprogramowania złożoność oznacza -
Osoby zespołu, takie jak programiści, klienci, dostawcy, konkurenci i akcjonariusze, ich liczba i szybkość.
Rozmiar i złożoność technologiczna.
Adaptacyjne praktyki tworzenia oprogramowania
Adaptive Software Development oferuje inne spojrzenie na praktyki zarządzania oprogramowaniem. W poniższych sekcjach możesz zrozumieć dwie ważne praktyki - Jakość i RAD, które mają konsekwencje dla zbierania wymagań.
Szczegóły wszystkich praktyk można znaleźć w rozdziale Praktyki adaptacyjnego tworzenia oprogramowania w tym samouczku.
Jakość
W złożonym środowisku odwieczna praktyka „Zrób to dobrze za pierwszym razem” nie działa, ponieważ nie możesz przewidzieć, co jest właściwe na początku. Musisz mieć cel, aby wytworzyć odpowiednią wartość. Jednak w złożonym środowisku kombinacje i permutacje składników wartości, takich jak zakres (cechy, wydajność, poziomy defektów), harmonogram i zasoby, są tak ogromne, że nigdy nie można uzyskać optymalnej wartości. W związku z tym nacisk kładziony jest na zmianę, aby zapewnić najlepszą wartość na konkurencyjnym rynku.
Praktyki RAD
Praktyki RAD generalnie obejmują kombinację następujących -
- Ewolucyjny cykl życia
- Grupy fokusowe dla klientów, sesje JAD, przeglądy techniczne
- Zarządzanie projektami ograniczone czasowo
- Ciągła inżynieria oprogramowania
- Dedykowane drużyny z pokojami wojennymi
Projekty RAD mają nieodłączny adaptacyjny, wyłaniający się smak. Wiele organizacji IT jest przeciwko RAD. Jednak Microsoft i inni stworzyli niewiarygodnie duże i złożone oprogramowanie przy użyciu technik porównywalnych z RAD, ponieważ rodzi to pytania o ich podstawowy pogląd na świat.
Praktyki RAD i proces Microsoft są przykładami Adaptive Development w akcji. Nadanie im etykiety (tj. Rozwój adaptacyjny) i uświadomienie sobie, że istnieje rosnąca wiedza naukowa (np. Teoria CAS) wyjaśnia, dlaczego działają. Powinno to stanowić podstawę do szerszego stosowania tych praktyk.
Adaptacyjne tworzenie oprogramowania wyewoluowało z praktyk RAD. Do tych praktyk dodano również aspekty zespołowe. Firmy od Nowej Zelandii po Kanadę, dla szerokiej gamy typów projektów i produktów, korzystały z adaptacyjnego tworzenia oprogramowania.
Jim Highsmith opublikował Adaptive Software Development w 2000 roku.
Praktyki adaptacyjnego tworzenia oprogramowania zapewniają zdolność dostosowywania się do zmian i można je dostosować w niespokojnych środowiskach, w których produkty ewoluują przy niewielkim planowaniu i nauce.
Fazy cyklu życia ASD
Adaptacyjne tworzenie oprogramowania przebiega cyklicznie, podobnie jak w modelu ewolucyjnym, a nazwy faz odzwierciedlają nieprzewidywalność w złożonych systemach. Fazy w cyklu życia adaptacyjnego rozwoju to:
- Speculate
- Collaborate
- Learn
Te trzy fazy odzwierciedlają dynamiczny charakter adaptacyjnego tworzenia oprogramowania. Rozwój adaptacyjny wyraźnie zastępuje determinizm przejawem pojawienia się. Wykracza poza zwykłą zmianę cyklu życia i prowadzi do głębszej zmiany stylu zarządzania. Adaptive Software Development ma dynamiczny cykl życia spekuluj-współpracuj-ucz się.
Cykl życia adaptacyjnego tworzenia oprogramowania koncentruje się na wynikach, a nie zadaniach, a wyniki są określane jako funkcje aplikacji.
Spekulować
Termin plan jest zbyt deterministyczny i wskazuje na dość wysoki stopień pewności co do pożądanego rezultatu. Ukryty i jawny cel zgodności z planem ogranicza zdolność menedżera do kierowania projektem w innowacyjnych kierunkach.
W Adaptive Software Development termin plan jest zastępowany terminem spekulować. Spekulując, zespół nie rezygnuje z planowania, ale uznaje rzeczywistość niepewności w złożonych problemach. Spekulowanie zachęca do eksploracji i eksperymentowania. Zalecane są iteracje z krótkimi cyklami.
Współpracować
Złożone aplikacje nie są budowane, one ewoluują. Złożone aplikacje wymagają zebrania, przeanalizowania i zastosowania dużej ilości informacji do problemu. Turbulentne środowiska charakteryzują się wysokim współczynnikiem przepływu informacji. Dlatego złożone aplikacje wymagają gromadzenia, analizowania i stosowania dużej ilości informacji. Skutkuje to różnorodnymi wymaganiami dotyczącymi wiedzy, które można obsłużyć tylko dzięki współpracy zespołowej.
Współpraca wymagałaby zdolności do wspólnej pracy w celu uzyskania wyników, dzielenia się wiedzą lub podejmowania decyzji.
W kontekście zarządzania projektami, Collaboration przedstawia równowagę między zarządzaniem tradycyjnymi technikami zarządzania a tworzeniem i utrzymywaniem środowiska współpracy potrzebnego do powstania.
Uczyć się
Część „Nauka” cyklu życia jest niezbędna dla powodzenia projektu. Zespół musi stale poszerzać swoją wiedzę, stosując praktyki takie jak:
- Recenzje techniczne
- Retrospektywy projektu
- Grupy fokusowe dla klientów
Recenzje należy wykonywać po każdej iteracji. Zarówno programiści, jak i klienci analizują swoje założenia i wykorzystują wyniki każdego cyklu rozwojowego, aby poznać kierunek następnego. Zespół uczy się -
O zmianach w produktach
Bardziej fundamentalne zmiany w podstawowych założeniach dotyczących sposobu opracowywania produktów
Iteracje muszą być krótkie, aby zespół mógł uczyć się na małych, a nie dużych błędach.
Spekuluj - współpracuj - ucz się cyklu jako całości
Jak widać z cyklu Spekuluj-Współpracuj-Ucz się, podanego powyżej, jest oczywiste, że te trzy fazy są nieliniowe i nakładają się.
Obserwujemy następujące z Adaptive Framework.
Trudno jest współpracować bez nauki lub uczyć się bez współpracy.
Trudno jest spekulować bez uczenia się lub uczyć się bez spekulacji.
Trudno jest spekulować bez współpracy lub współpracować bez spekulacji.
Cykl życia adaptacyjnego tworzenia oprogramowania ma sześć podstawowych cech -
- Skoncentrowany na misji
- Oparte na funkcjach
- Iterative
- Time-boxed
- Kierowany ryzykiem
- Zmień tolerancyjny
W tym rozdziale zrozumiesz sześć cech adaptacyjnego tworzenia oprogramowania.
Zorientowany na misję
W przypadku wielu projektów ogólna misja, którą kieruje zespół, jest dobrze określona, chociaż wymagania mogą być niepewne na początku projektu. Deklaracje misji pełnią rolę przewodników, które zachęcają do eksploracji na początku, ale skupiają się tylko na przebiegu projektu. Misja zapewnia granice, a nie stałe miejsce docelowe. Deklaracje misji i dyskusje, które prowadzą do tych stwierdzeń, dostarczają wskazówek i kryteriów podejmowania krytycznych decyzji dotyczących projektów.
Bez jasnej misji i ciągłej praktyki udoskonalania misji, iteracyjne cykle życia stają się oscylującymi cyklami życia, kołyszącymi się w tę i z powrotem bez postępu w rozwoju.
Oparte na funkcjach
Cykl życia adaptacyjnego tworzenia oprogramowania opiera się na funkcjach aplikacji, a nie na zadaniach. Funkcje to funkcje, które są opracowywane podczas iteracji w oparciu o priorytety klienta.
Funkcje mogą ewoluować w kilku iteracjach, gdy klienci przekazują opinie.
Funkcje aplikacji, które zapewniają bezpośrednie rezultaty dla klienta po wdrożeniu, są podstawowe. Dokument zorientowany na klienta, taki jak podręcznik użytkownika, jest również uznawany za funkcję. Inne dokumenty, takie jak model danych, nawet jeśli są zdefiniowane jako produkty dostarczane, są zawsze drugorzędne.
Wielokrotny
Cykl życia adaptacyjnego tworzenia oprogramowania jest iteracyjny i koncentruje się na częstych wydaniach w celu uzyskania informacji zwrotnej, przyswojenia wynikającej z tego wiedzy i wyznaczenia właściwego kierunku dalszego rozwoju.
Ograniczony czas
W cyklu życia adaptacyjnego tworzenia oprogramowania iteracje są ograniczone czasowo. Należy jednak pamiętać, że ograniczenia czasowe w Adaptive Software Development nie dotyczą terminów. Nie powinien być używany do zmuszania zespołu do pracy przez długie godziny, co stanowi wyzwanie dla środowiska współpracy lub w celu obniżenia jakości wyników.
W adaptacyjnym opracowywaniu oprogramowania ograniczenie czasowe jest uważane za kierunek skupiania się i wymuszania trudnych decyzji kompromisowych w razie potrzeby. W niepewnym środowisku, w którym stopy zmian są wysokie, potrzebna jest okresowa funkcja wymuszająca, taka jak przedział czasowy, aby zakończyć pracę.
Zorientowany na ryzyko
W Adaptive Software Development iteracje są sterowane przez identyfikację i ocenę krytycznych zagrożeń.
Tolerancja na zmiany
Adaptacyjne tworzenie oprogramowania jest odporne na zmiany, traktując zmiany jako zdolność do uzyskania przewagi konkurencyjnej, ale nie jako problem dla rozwoju.
Praktyki Adaptive Software Development opierają się na wierze w ciągłą adaptację, z cyklem życia przystosowanym do akceptacji ciągłych zmian jako normy.
Cykl życia adaptacyjnego tworzenia oprogramowania jest przeznaczony dla:
- Kontynuacja nauczania
- Zmień orientację
- Re-evaluation
- Zaglądanie w niepewną przyszłość
- Intensywna współpraca między programistami, zarządem i klientami
Adaptacyjne SDLC
Adaptive Software Development łączy RAD z najlepszymi praktykami inżynierii oprogramowania, takimi jak -
- Rozpoczęcie projektu.
- Adaptacyjne planowanie cyklu.
- Współbieżna inżynieria komponentów.
- Przegląd jakości.
- Ostateczna kontrola jakości i wydanie.
Praktyki adaptacyjnego tworzenia oprogramowania można zilustrować następująco:
Jak pokazano powyżej, praktyki adaptacyjnego tworzenia oprogramowania są podzielone na trzy fazy w następujący sposób -
Spekuluj - inicjacja i planowanie
Rozpoczęcie projektu
Ustalenie ram czasowych dla całego projektu
Zdecyduj o liczbie iteracji i przypisz każdemu przedział czasu
Opracuj temat lub cel dla każdej z iteracji
Przypisz funkcje do każdej iteracji
Collaborate - Równoczesny rozwój funkcji
Współpraca dla rozproszonych zespołów
Współpraca przy mniejszych projektach
Współpraca przy większych projektach
Learn - Przegląd jakości
Jakość wyniku z perspektywy klienta
Jakość wyniku z technicznego punktu widzenia
Funkcjonowanie zespołu dostawczego i członków zespołu praktyk jest wykorzystywane
Status projektu
Spekulować - inicjacja i planowanie
W adaptacyjnym rozwoju oprogramowania faza spekulacji obejmuje dwa działania -
- Initiation
- Planning
Spekuluj ma pięć praktyk, które można powtarzać na etapie inicjacji i planowania. Oni są -
- Rozpoczęcie projektu
- Ustalenie ram czasowych dla całego projektu
- Zdecyduj o liczbie iteracji i przypisz każdemu przedział czasu
- Opracuj temat lub cel dla każdej z iteracji
- Przypisz funkcje do każdej iteracji
Rozpoczęcie projektu
Rozpoczęcie projektu obejmuje -
- Wyznaczenie misji i celów projektu
- Zrozumienie ograniczeń
- Utworzenie organizacji projektowej
- Identyfikowanie i określanie wymagań
- Dokonywanie wstępnych szacunków wielkości i zakresu
- Identyfikacja kluczowych ryzyk projektowych
Dane dotyczące rozpoczęcia projektu należy zebrać we wstępnej sesji JAD, biorąc pod uwagę szybkość jako główny aspekt. Inicjację można przeprowadzić w ciągu dwóch do pięciu dni w przypadku małych i średnich projektów lub w ciągu dwóch do trzech tygodni w przypadku większych projektów.
Podczas sesji JAD wymagania są gromadzone na tyle szczegółowo, aby zidentyfikować cechy i ustanowić przegląd obiektu, danych lub innego modelu architektonicznego.
Ustalenie ram czasowych dla całego projektu
Należy określić ramy czasowe dla całego projektu w oparciu o zakres, wymagania dotyczące zestawu funkcji, szacunki i dostępność zasobów, które wynikają z prac związanych z rozpoczęciem projektu.
Jak wiesz, spekulowanie nie oznacza rezygnacji z szacowania, ale oznacza po prostu zaakceptowanie, że szacunki mogą się nie udać.
Iteracje i ramka czasowa
Podejmij decyzję o liczbie iteracji i długości poszczególnych iteracji w oparciu o ogólny zakres projektu i stopień niepewności.
Do małych i średnich aplikacji -
- Iteracje zwykle trwają od czterech do ośmiu tygodni.
- Niektóre projekty działają najlepiej z dwutygodniowymi iteracjami.
- Niektóre projekty mogą wymagać więcej niż ośmiu tygodni.
Wybierz czas w oparciu o to, co Ci odpowiada. Gdy zdecydujesz się na liczbę iteracji i długość każdej z iteracji, przypisz harmonogram do każdej z iteracji.
Opracuj motyw lub cel
Członkowie zespołu powinni opracować temat lub cel dla każdej iteracji. Jest to coś podobnego do celu sprintu w Scrumie. Każda iteracja powinna zawierać zestaw funkcji, które mogą zademonstrować funkcjonalność produktu, dzięki czemu produkt będzie widoczny dla klienta, aby umożliwić przegląd i opinie.
W ramach iteracji kompilacje powinny dostarczać działające funkcje, najlepiej codziennie, umożliwiając proces integracji i uwidaczniając produkt dla zespołu programistów. Testowanie powinno być ciągłą, integralną częścią rozwoju funkcji. Nie należy go odkładać do końca projektu.
Przypisz funkcje
Programiści i klienci powinni wspólnie przypisywać funkcje do każdej iteracji. Najważniejszym kryterium tego przypisania funkcji jest to, że każda iteracja musi dostarczać klientowi widoczny zestaw funkcji o znacznej funkcjonalności.
Podczas przypisywania funkcji do iteracji -
Zespół programistów powinien wymyślić oszacowania funkcji, ryzyka i zależności i przekazać je klientowi.
Klienci powinni zdecydować o priorytetyzacji funkcji, korzystając z informacji dostarczonych przez zespół programistów.
Dlatego planowanie iteracji jest oparte na funkcjach i wykonywane jako zespół z programistami i klientami. Doświadczenie pokazuje, że ten rodzaj planowania zapewnia lepsze zrozumienie projektu niż planowanie zadaniowe przez kierownika projektu. Ponadto planowanie oparte na funkcjach odzwierciedla wyjątkowość każdego projektu.
Współpraca ─ współbieżne opracowywanie funkcji
W fazie współpracy nacisk kładziony jest na rozwój. Faza współpracy obejmuje dwa działania -
Zespół programistów współpracuje i dostarcza działające oprogramowanie.
Kierownicy projektów ułatwiają współpracę i równoległe działania rozwojowe.
Współpraca to akt współtworzenia, który obejmuje zespół programistów, klientów i menedżerów. Wspólnemu tworzeniu sprzyja zaufanie i szacunek.
Zespoły powinny współpracować nad -
- Problemy techniczne
- Wymagania biznesowe
- Szybkie podejmowanie decyzji
Poniżej przedstawiono praktyki dotyczące fazy współpracy w adaptacyjnym tworzeniu oprogramowania -
- Współpraca dla rozproszonych zespołów
- Współpraca przy mniejszych projektach
- Współpraca przy większych projektach
Współpraca dla rozproszonych zespołów
W projektach z zespołami rozproszonymi należy wziąć pod uwagę:
- Różni partnerzy sojuszu
- Szeroka wiedza
- Sposób interakcji ludzi
- Sposób, w jaki zarządzają współzależnościami
Współpraca przy mniejszych projektach
W mniejszych projektach, gdy członkowie zespołu pracują blisko siebie, należy zachęcać do współpracy przy nieformalnych rozmowach na korytarzu i pisaniu na tablicy, ponieważ okazuje się to skuteczne.
Współpraca przy większych projektach
Większe projekty wymagają dodatkowych praktyk, narzędzi współpracy i interakcji z kierownikiem projektu i powinny być organizowane na podstawie kontekstu.
Dowiedz się - przegląd jakości
Adaptive Software Development promuje koncepcję „Eksperymentuj i ucz się”.
Uczenie się na błędach i eksperymentowanie wymaga, aby członkowie zespołu wcześnie udostępnili częściowo ukończony kod i artefakty, aby -
- Znajdź błędy
- Ucz się od nich
- Zmniejsz liczbę poprawek, znajdując małe problemy, zanim staną się dużymi
Pod koniec każdej iteracji programistycznej istnieją cztery ogólne kategorie rzeczy, których należy się nauczyć -
- Jakość wyniku z perspektywy klienta
- Jakość wyniku z technicznego punktu widzenia
- Funkcjonowanie zespołu dostawczego i zespołu praktyk
- Status projektu
Jakość wynikowa z perspektywy klienta
W projektach Adaptive Software Development uzyskanie informacji zwrotnych od klientów jest priorytetem. Zalecaną praktyką jest skupienie się na kliencie. Sesje te mają na celu zbadanie modelu roboczego aplikacji i rejestrowanie żądań zmian klientów.
Sesje grup fokusowych klientów są sesjami ułatwionymi, podobnymi do sesji jad, ale zamiast generować wymagania lub definiować plany projektu, służą do przeglądu samej aplikacji. Klienci przekazują informacje zwrotne na temat działającego oprogramowania wynikające z iteracji.
Jakość wynikowa z perspektywy technicznej
W projektach Adaptive Software Development należy przywiązywać wagę do okresowego przeglądu artefaktów technicznych. Przeglądy kodu należy przeprowadzać w sposób ciągły. Przeglądy innych artefaktów technicznych, takich jak architektura techniczna, mogą być przeprowadzane co tydzień lub na końcu iteracji.
W projektach Adaptive Software Development zespół powinien okresowo monitorować własną wydajność. Retrospektywy zachęcają zespoły do wspólnego poznawania siebie i swojej pracy.
Retrospektywy na końcu iteracji ułatwiają okresową samoocenę wyników zespołu, takich jak:
- Określ, co nie działa.
- Co zespół musi zrobić więcej.
- Co zespół musi robić mniej.
Status projektu
Przegląd statusu projektu pomaga w planowaniu dalszej pracy. W projektach adaptacyjnego tworzenia oprogramowania określanie statusu projektu jest podejściem opartym na funkcjach, przy czym koniec każdej iteracji jest oznaczony zakończonymi funkcjami skutkującymi działającym oprogramowaniem.
Przegląd stanu projektu powinien obejmować -
- Gdzie jest projekt?
- Gdzie jest projekt a plany?
- Gdzie powinien być projekt?
Ponieważ plany w projektach Adaptive Software Development są spekulatywne, ważniejsze niż pytanie 2 powyżej jest pytanie 3. Oznacza to, że zespół projektowy i klienci muszą nieustannie zadawać sobie pytanie: „Czego nauczyliśmy się do tej pory i czy zmienia to nasze spojrzenie na to, dokąd musimy iść?”
Schemat blokowy tradycyjnego zarządzania oprogramowaniem przedstawiono poniżej.
Tradycyjne zarządzanie oprogramowaniem zostało scharakteryzowane pod pojęciem dowodzenia i kontroli.
Wiele organizacji jest przesiąkniętych tradycją optymalizacji, wydajności, przewidywalności, kontroli, dyscypliny i doskonalenia procesów. Jednak wschodząca gospodarka wieku informacji wymaga zdolności adaptacyjnych, szybkości, współpracy, improwizacji, elastyczności, innowacyjności i giętkości.
Harvard Business Review and Management Books zawiera terminy takie jak upodmiotowienie, zarządzanie partycypacyjne, organizacja ucząca się, zarządzanie zorientowane na człowieka itp., Ale żaden z nich nie jest stosowany w zarządzaniu nowoczesnymi organizacjami.
W kontekście Adaptive Software Development luka wygląda na znacznie szerszą i istnieje potrzeba rozważenia technik zarządzania adaptacyjnego, które sprawdziły się w innych dziedzinach.
Zarządzanie adaptacyjne
Zarządzanie adaptacyjne okazało się skuteczne w środowiskach, w których menedżerowie zasobów pracowali razem z interesariuszami i naukowcami jako zespół, mając następujące cele:
Aby dowiedzieć się, jak systemy zarządzane reagują na interwencje człowieka.
Aby w przyszłości ulepszyć zasady i praktyki dotyczące zasobów.
Zasada zarządzania adaptacyjnego polega na tym, że wiele działań związanych z zarządzaniem zasobami to eksperymenty, ponieważ ich wyników nie można z góry wiarygodnie przewidzieć. Te eksperymenty są następnie wykorzystywane jako możliwości uczenia się do ulepszeń w przyszłości.
Zarządzanie adaptacyjne ma na celu zwiększenie zdolności szybkiego reagowania w obliczu nowych informacji oraz przy ustalaniu różnych celów i preferencji interesariuszy. Zachęca zainteresowane strony do wiązania sporów i omawiania ich w uporządkowany sposób, podczas gdy niepewności środowiskowe są badane i lepiej rozumiane.
Zarządzanie adaptacyjne pomaga interesariuszom, menedżerom i innym decydentom dostrzec granice wiedzy i potrzebę działania w oparciu o niedoskonałe informacje.
Zarządzanie adaptacyjne pomaga zmienić podjęte decyzje, wyjaśniając, że -
- Decyzje mają charakter tymczasowy.
- Decyzja kierownictwa nie zawsze musi być słuszna.
- Oczekiwane są modyfikacje.
Istnieją dwa rodzaje podejść do zarządzania adaptacyjnego -
- Zarządzanie pasywne adaptacyjne.
- Aktywne zarządzanie adaptacyjne.
Zarządzanie pasywne adaptacyjne
Zarządzanie adaptacyjne ma na celu poszerzenie wiedzy naukowej, a tym samym zmniejszenie niepewności.
W ramach zarządzania pasywnego adaptacyjnego wybiera się jeden preferowany sposób działania, oparty na istniejących informacjach i zrozumieniu. Wyniki działań zarządczych są monitorowane, a kolejne decyzje są korygowane na podstawie wyników.
Takie podejście przyczynia się do uczenia się i skutecznego zarządzania. Jednak jego zdolność do zwiększania możliwości naukowych i zarządzania w warunkach wykraczających poza wybrany kierunek działania jest ograniczona.
Aktywne zarządzanie adaptacyjne
Podejście do zarządzania Active Adaptive sprawdza informacje przed podjęciem działań zarządczych.
Następnie opracowywany jest szereg konkurencyjnych, alternatywnych modeli systemowych ekosystemów i związanych z nimi reakcji (np. Zmiany demograficzne; zastosowania rekreacyjne) zamiast jednego modelu. Opcje zarządzania są wybierane na podstawie ocen tych alternatywnych modeli.
Zarządzanie przywództwem i współpracą
Zarządzanie adaptacyjne najlepiej nadaje się do adaptacyjnego tworzenia oprogramowania. Podejście to wymaga menedżerów zasobów, tj. Menedżerów, którzy potrafią pracować z ludźmi, pozwalać na interwencje ludzi i tworzyć przyjazne środowisko.
W rozwoju oprogramowania liderzy często podejmują te obowiązki. Bardziej potrzebujemy przywódców niż dowódców. Liderzy są współpracownikami i współpracują z zespołem. Przywództwo oparte na współpracy jest najbardziej poszukiwaną praktyką w rozwoju adaptacyjnym.
Liderzy mają następujące cechy -
Chwyć i ustaw kierunek.
Wpływaj na zaangażowanych ludzi i udzielaj wskazówek.
Współpracuj, ułatwiaj i zarządzaj zespołem w skali makro.
Zapewnij kierunek.
Twórz środowiska, w których utalentowani ludzie mogą być innowacyjni, kreatywni i podejmować skuteczne decyzje.
Zrozum, że czasami muszą dowodzić, ale to nie jest ich dominujący styl.