Adaptacyjne tworzenie oprogramowania - praktyki

Praktyki Adaptive Software Development opierają się na wierze w ciągłą adaptację, z cyklem życia przystosowanym do akceptowania 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.
• Inżynieria współbieżna 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 Adaptive Software Development 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 Adaptive Software Development faza spekulacji obejmuje dwa działania -

• Initiation
• Planning

Spekulować 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ć podczas 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 wiecie, spekulowanie nie rezygnuje 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. Po podjęciu decyzji o liczbie iteracji i długości 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 wersje 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 przypisania funkcji jest to, że każda iteracja musi dostarczać klientowi widoczny zestaw cech o znacznej funkcjonalności.

Podczas przypisywania funkcji do iteracji -

• Zespół programistów powinien opracować 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ólnego 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, można przeprowadzać co tydzień lub na koniec 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 to zmienia naszą perspektywę, dokąd musimy iść?”