Feature-driven development

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.

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.