Feature-Driven Development

Feature-Driven Development (FDD) - jest jedną z metodyk adaptacyjnego zarządzania projektami. Stawia na szybkie dostarczanie klientowi widocznych rezultatów pracy oraz dokładnych informacji o aktualnym stanie projektu, przy minimalnym zaangażowaniu programistów. FDD łączy w sobie najlepsze praktyki zarządzania projektami informatycznymi w spójną całość. Zawarte w metodyce zalecenia charakteryzują się skupianiem uwagi na cenione przez klienta funkcjonalności aplikacji. Metodyka FDD opisuje również poszczególnych uczestników projektu, ich role, kolejne procesy wytwarzania oprogramowania oraz sposoby mierzenia rezultatów. Twórcami podejścia są Jeff De Luca i Peter Coad, którzy wspólnie pracując nad dużym przedsięwzięciem programistycznym w Singapurze zmuszeni byli opracować efektywniejszy od tradycyjnych sposób zarządzania projektem. Pojęcie "Feature-Driven Development" po raz pierwszy pojawiło się w książce "Java Modeling in Color with UML" autorstwa Petera Coada w 1999 roku (S. Goyal 2007).

TL;DR

Feature-Driven Development (FDD) to metodyka zarządzania projektami informatycznymi, która skupia się na szybkim dostarczaniu klientowi widocznych rezultatów pracy. FDD polega na opracowaniu ogólnego modelu, tworzeniu listy funkcji, planowaniu, projektowaniu i budowaniu według funkcji. Metodyka ta zawiera szereg dobrych praktyk, takich jak modelowanie obiektowe systemu, tworzenie listy wymaganych funkcji, odpowiedzialność za kod, dynamiczne zespoły programistów, inspekcje, przyrostowa budowa produktu, zarządzanie konfiguracją i raportowanie postępów. FDD różni się od innych metodyk zwinnych, takich jak Extreme Programming czy Scrum, pod względem projektowania systemu, podejścia do programowania i testowania. FDD kładzie duży nacisk na modelowanie i odpowiedzialność za kod, podczas gdy inne metodyki skupiają się na testowaniu i komunikacji w projekcie.

5 procesów Feature-Driven Development

• Proces pierwszy - opracowywanie ogólnego modelu: Model FDD zakłada, aby zespoły dołożyły wystarczającej ilości wysiłku na początku projektu, żeby zbudować model obiektu podkreślający problem domeny. Modelowanie FDD jest ograniczone czasowo i w dużej mierze oparte na współpracy. Modele domenowe powinny być tworzone przez małe grupy, a następnie prezentowane do oceny. Należy zakładać, że zaproponowany model lub kombinacja modeli zostanie wykorzystana dla każdego obszaru domeny. Następnie zostaną one scalone w celu stworzenia ogólnego modelu.
• Proces drugi - tworzenie listy funkcji. Z wiedzy uzyskanej podczas procesu modelowania ustalana jest lista funkcji poprzez podział domen na obszary tematyczne, które zawierają informacje o działaniach biznesowych. Kroki, które są używane dla każdej czynności biznesowej stanowią skategoryzowaną listę funkcji. Funkcje wyrażone są na przykład jako: wynik, akcja, obiekt. Wymaga się, aby ukończenie funkcji nie trwało dłużej niż dwa tygodnie. Jeżeli jest to niemożliwe to należy wtedy podzielić te funkcje na mniejsze sekcje,
• Proces trzeci - plan według funkcji. Po tym jak listy funkcji zostaną utworzone, następujący proces obejmuje przydzielanie różnych zestawów funkcji programistom.
• Proces czwarty - projektowanie według funkcji. Programiści razem z głównym programistą tworzą pakiet projektowy dla każdej funkcji poprzez wybór grupy funkcji, która powinna zostać stworzona w ciągu dwóch tygodni. Główny programista zajmuje się również tworzeniem szczegółowych diagramów dla każdej z funkcji, jednocześnie poprawiając model. Po tym etapie tworzone są prologi oraz przeprowadzana jest kontrola projektu.
• Proces piąty - buduj według funkcji. Po tym jak inspekcja projektu zostanie zakończona, projektanci planują działanie dla każdej funkcji i opracują kod dla odpowiednich klas. Następnym etapem po zakończeniu kontroli i wykonaniu testu jednostkowego jest dodanie funkcji do głównej wersji (Feature Driven... 2015).

Dobre praktyki FDD

Feature-Driven Development zawiera w sobie szereg dobrych praktyk wspierających zarządzanie projektem informatycznym. Najważniejsze z nich to:

• Model obiektowy systemu

W podejściu FDD bardzo ważne jest ustalenie ogólnego modelu obiektowego projektowanego systemu. Na jego podstawie podejmowane są wszelkie późniejsze decyzje dotyczące produktu. Istotny jest również sposób prezentowania opracowanego modelu. Do tego celu zalecane jest wykorzystanie modelowania UML w kolorze, jako że podejście FDD było tworzone w oparciu o tą technologię.

• Tworzenie w oparciu o wymagania

Dla klienta istotne są konkretne funkcjonalności dostarczone w określonym czasie. Z tego względu należy zadbać o stworzenie dokładnej listy wymaganych funkcji. Wszystkie z nich, które są niemożliwe do implementacji w okresie dwóch tygodni, rozbijane są na inne, mniejsze.

• Odpowiedzialność za kod

Realizowana jest poprzez przypisanie każdej klasy wynikającej z projektu aplikacji konkretnemu programiście, który od danego momentu jest za nią w pełni odpowiedzialny.

• Dynamiczne zespoły programistów

Jeśli dana funkcjonalność wymaga większej ilości klas składany jest zespół odpowiedzialny za cały element. W skład zespołu wchodzą programiści, z których każdy opracowuje daną klasę. Jeden z nich jest programistą głównym, którego zadaniem jest również koordynowanie działań całego zespołu. W podejściu FDD często występuje sytuacja, w której jeden programista należy do wielu zespołów.

• Inspekcje

Aby zapewnić kontrolę jakości i integralność kodu prowadzone są regularne inspekcje. Z uwagi na to, że każdy programista należy do wielu zespołów inspekcja nie ocenia pracowników, lecz całe funkcjonalności i sposób ich wykonania.

• Przyrostowa budowa produktu

W regularnych odstępach czasowych cały kod realizujący określone funkcje jest pobierany i wykonywane są wszystkie prace niezbędne do jego uruchomienia. Zapewnia to możliwość prowadzenia testów oraz prezentowania klientowi kolejnych wersji systemu.

• Zarządzanie konfiguracją

Oprócz przechowywania jedynie kodu źródłowego projektu zalecane jest również zwracanie uwagi na wszystkie zdarzenia mające wpływ na jego ostateczną postać. Takimi wartymi zanotowania zdarzeniami są np. zmiany wymagań, wyniki analiz, wykryte błędy.

• Raportowanie postępów

Na wszystkich poziomach tworzenia produktu zbierane są dane o jego aktualnym stanie i zmianach. Informacje te służą potem do tworzenia raportów zbiorczych, wspierając menadżerów projektu.

Feature-Driven Development a inne metodyki zwinne

Wszystkie metodyki adaptacyjne posiadają pewne obszary, w których są do siebie bardzo podobne. Najbardziej znane z nich, jak Extreme Programming czy Scrum tak jak i Feature-Driven Development opierają się o przyrostowe podejście do produkcji oprogramowania. Metodyki te skupiają się na jak najszybszym dostarczeniu działających wersji programu klientowi i komunikacji między osobami biorącymi udział w projekcie. Sposób osiągania tych celów jest jednak odmienny dla każdej metodyki.

Różnice zaczynają się już na etapie projektowania systemu. Extreme Programming zaleca tworzenie oprogramowania tylko na podstawie analizy wymagań funkcjonalnych, wdrażając po kolei każdy zbiór funkcji. Feature-Driven Development doradza natomiast stworzenie ogólnego modelu obiektowego tworzonego produktu. Takie podejście powoduje wydłużenie czasu fazy przygotowawczej, ale posiada swoje zalety. Stworzenie ogólnego modelu przed przystąpieniem do pracy pozwala na redukcję późniejszych zmian w kodzie oraz na łatwiejsze zarządzanie projektem. Kolejnym wyróżnikiem FDD na tle innych metodyk jest podejście do programowania i odpowiedzialności za kod. W FDD konkretni programiści odpowiedzialni są za przypisane im klasy, a jakość kodu utrzymywana jest za pomocą cyklicznych inspekcji. W metodyce programowania ekstremalnego zalecane jest natomiast programowanie w parach, jako metoda inspekcji kodu. FDD w odróżnieniu od innych metodyk adaptacyjnych nie kładzie jednak dużego nacisku na testy. Sposób i dokładność ich wykonania zależy od głównego programisty. Inne metodyki zwinne podchodzą do tego problemu znacznie dokładniej nakazując pisanie testów dla danej funkcjonalności przed stworzeniem jej samej, co zapewnia wysoki stopień niezawodności kodu (S. Palmer, J. Felsing 2002).

Feature-Driven Development — artykuły polecane

Inżynieria oprogramowania — Testowanie w projekcie — Metodyka MSF — Ogólna charakterystyka metodyki Prince 2 — Backlog produktu — Scrum of scrums — Kanban (agile) — Metodyka Extreme Programming — DMAIC

Bibliografia

• Goyal S. (2007), Agile Techniques for Project Management and Software Engineering, Technical University Munich
• Goyal S. (2007), Feature Driven Development: Agile Techniques for Project Management and Software Engineering, Major Seminar On Feature Driven Development
• Palmer S., Felsing J. (2002), A Practical Guide to Feature-Driven Development, Prentice Hall
• Strona internetowa: FDD. Its processes & comparison to other Agile methodologies
• Strona internetowa: Feature Driven Development: A Guide, ARRK
• Strona internetowa: Feature Driven Development - lekka metodyka tworzenia oprogramowania

Autor: Mariusz Szpyt, Piotr Wyżga