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 Luca w roku 1997, na potrzeby projektu realizowanego w dużym, singapurskim banku. 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 autorstwa Petera Coada, Erica Lefebvre i Jeffa De Luca, wydanej w roku 1999. Kolejny, bardziej ogólny opis tej metodyki, został opublikowany w książce A practical guide to feature-driven development 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.

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.

Linki zewnętrzne

• http://www.featuredrivendevelopment.com/ (ang.)