Feature-driven development

Feature-driven development (FDD) – metodyka programowania należąca do grupy metodyk zwinnych inżynierii oprogramowania (z których najbardziej znaną jest programowanie ekstremalne). Jej głównymi celami jest umożliwienie wytwarzania użytecznego oprogramowania w powtarzalny i efektywny sposób, zapewniając wiarygodne informacje o stanie projektu informatycznego do wszystkich jego uczestników, z minimalnym narzutem na pracę programistyczną.

Historia

Metodyka FDD została opracowana przez Jeffa De Lucę(inne języki) w roku 1997, na potrzeby projektu realizowanego w dużym, singapurskim banku^[1]. Rezultatem był zestaw pięciu procesów, pokrywających ogólny model, wyliczenie, planowanie, modelowanie oraz tworzenie funkcji systemu. Od czasu pierwszego udanego wykorzystania, pojawiło się kilka implementacji FDD.

Pierwszy opis FDD pojawił się w szóstym rozdziale książki Java modeling in color with UML^[2] autorstwa Petera Coada(inne języki), Erica Lefebvre i Jeffa De Luci, wydanej w roku 1999. Kolejny, bardziej ogólny opis tej metodyki, został opublikowany w książce A practical guide to feature-driven development^[1] autorstwa Stephena Palmera i Maca Flesinga.

Założenia

• FDD jest zwinną metodyką oprogramowania
• Zapewnia dostateczną strukturę dla prac większych zespołów
• Kładzie nacisk na jakość wytwarzanego oprogramowania
• Kolejne wersje oprogramowania powstają często i zawierają nowe użyteczne funkcje
• Zapewnia mechanizmy do wiarygodnego śledzenia postępu prac
• W FDD są używane testy jednostkowe
• FDD zakłada przypisanie kodu (klas) do właścicieli (programistów)
• Podczas implementacji wykonywane są inspekcje kodu

Role osób w projekcie

FDD definiuje sześć ról kluczowych oraz szereg ról wspierających i dodatkowych^[1].

Role kluczowe

• Project manager (kierownik projektu). Główny zarządca projektu, którego zadaniem jest kreowanie i zarządzanie środowiskiem w taki sposób, aby system działał jak najlepiej, a zespół mógł być produktywny i wydajny.
• Chief architect (główny architekt). Jest odpowiedzialny za całościowy projekt systemu. Podejmuje ostateczne decyzje w przypadku wszystkich problemów związanych z architekturą systemu i jest odpowiedzialny za przeprowadzenie zespołu przez wszelkie trudności techniczne.
• Development manager (kierownik rozwoju). Odpowiedzialny za nadzorowanie codziennych czynności związanych z rozwojem systemu. Rozwiązuje problemy związane z zasobami. Czasami rola ta łączona jest z rolą kierownika projektu lub głównego architekta.
• Chief programmers (główni programiści). Doświadczeni programiści, którzy przynajmniej kilka razy przeszli przez cały cykl rozwoju oprogramowania. Biorą udział w analizie wymagań oraz projektowaniu architektury oraz są odpowiedzialni za zarządzanie małymi zespołami, składającymi się z od trzech do sześciu programistów.
• Class owners (właściciele klas). Programiści, którzy pracują w zespołach zarządzanych przez głównych programistów. Ich rola polega na projektowaniu, programowaniu, tworzeniu testów oraz pisaniu dokumentacji do tworzonych funkcji.
• Domain experts (eksperci dziedzinowi) – Użytkownicy, klienci, sponsorzy i analitycy biznesowi. Ich zadanie polega na wykorzystaniu dogłębnej znajomości biznesu w celu wytłumaczenia programistom, jakie funkcje są wymagane od tworzonego systemu. Ich wsparcie pozwala upewnić się, że tworzony jest właściwy system.

Role wspierające

• Release Manager (manager wdrożeń). Pilnuje, by główni programiści raportowali postępy zgodnie z założeniami FDD, a założone terminy były dotrzymywane. Odpowiada bezpośrednio przed kierownikiem projektu.
• Language guru (guru języka). Osoba, która posiada dogłębną znajomość wykorzystywanego języka programowania lub technologii. Jest szczególnie istotna, kiedy język programowania lub technologia jest wykorzystywana przez zespół po raz pierwszy.
• Build engineer. Odpowiedzialny za proces budowania projektu. Zarządza systemem kontroli wersji, publikuje raporty i dokumentację oraz tworzy skrypty związane z wdrożeniami.
• Toolsmith (twórca programów narzędziowych). Tworzy małe narzędzia dla deweloperów, testerów i zespołu odpowiedzialnego za zarządzanie danymi. Tworzone narzędzia są dedykowane dla konkretnego projektu.
• System Administrator (administrator systemu). Konfiguruje, zarządza i rozwiązuje problemy związane z zasobami (siecią, serwerami, stacjami roboczymi) wykorzystywanymi w projekcie.

Role dodatkowe

• Testers (testerzy). Niezależni od programistów testerzy oprogramowania. Zespół testowy może stanowić część zespołu projektowego lub zostać oddelegowany z działu kontroli jakości niezwiązanego z konkretnym projektem.
• Deployers. Zajmują się konwersją istniejących danych do nowych formatów, wymaganych przez tworzony system, oraz kwestiami związanymi z wdrażaniem nowych wersji oprogramowania.
• Technical Writers (twórcy dokumentacji technicznej). Odpowiedzialni za pisanie i redagowanie dokumentacji użytkownika.

Fazy projektu

W FDD wyróżniono pięć faz projektu, z których dwie ostatnie są powtarzane wielokrotnie podczas projektu.

Budowa ogólnego modelu

Na początku projektu zespół projektowy opracowuje model systemu, zapewniający wspólne rozumienie jego architektury i stanowiący przewodnik do jego budowy podczas następnych faz.

Budowa listy cech

Wymagania użytkowe do systemu są gromadzone w postaci listy cech. Cechy są funkcjami systemu, które:

• są niewielkie,
• pełnią użyteczną funkcję,
• dają się zdefiniować przy pomocy pojedynczego zdania (np. w systemie dla hotelu może to być Rezerwacja pokoju dla klienta)

Cechy są grupowane w grupy i obszary funkcjonalne.

Planowanie według cech

W uzgodnieniu z klientem układany jest plan tworzenia oprogramowania według udokumentowanych cech. Cechom przypisywany jest priorytet, określana jest ich pracochłonność i związane z nimi ryzyko, a następnie cechy są układane w kolejności, w jakiej będą implementowane.

Projekt według cech i Implementacja według cech

Dwie ostatnie fazy powtarzają się iteracyjnie do końca projektu. Na czas każdej iteracji tworzony jest zespół składający się z właścicieli klas zmienianych w ramach implementacji danej grupy cech. Zespół wykonuje szczegółowy projekt (być może modyfikując główny projekt stworzony w pierwszej fazie), a następnie implementuje zaplanowane cechy. Po każdej iteracji klientowi dostarczana jest kolejna wersja oprogramowania.

Śledzenie postępu projektu

Śledzenie postępu projektu w FDD dotyczy dwóch ostatnich faz (Projektowania i implementacji według cech). Procent wykonania projektu wynika z liczby zrealizowanych cech w stosunku do ogólnej ich liczby. FDD dostarcza wzorce schematów pozwalających graficznie przedstawiać postęp prac dla różnych uczestników projektu.