keresési feltétel:

Mi a Feature Driven Development és hogyan használjuk?


A Feature Driven Development (FDD) egy modell vezérelt rövid iterációjú agilis keretrendszer. Hogyan használható a feature-k megírására?

A Feature Driven Development (FDD) egy modell vezérelt rövid iterációjú agilis keretrendszer, amelynek a fő fókusza az ügyfélközpontúság, illetve az igényeknek elegettevő funkciók / feature-k időben és megfelelő minőségben történő szállítása. Használata kifejezetten nagyméretű szervezetekben és komplex projekteken elterjedt.

Az FDD felépítése

Az FDD öt fő részből áll.

Feature Driven Development öt része

  • Develop overall model

Ez a szint egy magas-szintű megközelítésű elemzés után történik, ami alapján a csapatok kellően részletezett, úgynevezett „domain modelleket” egyesítenek egy rendszerszintű vázlattá. Ezt követően finomítják a teljes modellt.

  • Build feature list

Itt történik az ügyfél által értékelt feature lista felvétele. Itt már különösen fontos, hogy egy feature beleférjen 2 hétbe, amennyiben nem, akkor kisebb részekre bontják [cselekmény] + [eredmény] + [célobjektum] megközelítésben. Itt inkább kisebb célokban kell gondolkodni a megírás során, nem feladatokban.

  • Plan by feature

Itt történik a feladatok felosztása, a komplexitás megvizsgálása, a fejlesztési terv meghatározása, a fejlesztési szerepek kijelölése, a csapatok és a fejlesztők dedikálása a feature-kre, osztályokra.

  • Design by feature

A sprintbe betervezett a feature-k esetében, ha szükséges akkor finomítják a célmodellt és a fejlesztési tervet, majd megtörténik a design vizsgálat is.

  • Build by feature

A sikeres design vizsgálatot és tervezést követően a fejlesztők megkezdik a kódolást a csapatukban. A fejlesztést követően történik a tesztelés, a kód vizsgálata és a kész feature-k élesítése.

A Feature Driven Development használata

A FDD megközelítés sokkal egyszerűbb, amikor egy API (alkalmazásprogramozási felület) vagy Backend feature-t szeretnénk megírni, ahol nincs user, így mesterkélt lehet az Én, mint (user szerep) azt szeretném, hogy (cselekmény) azért, (üzleti érték) megközelítés.

Ezáltal a Product Backlog-ban sokkal könnyebben áttekinthető feature-k jelennek meg és a Product Owner sem tölti idejét azzal, hogy szólítson meg megszemélyesítve egy API-t, így idejét akár a Backlog item-ek jobb kidolgozására fordíthatja.

 

A feature formája a FDD rendszer szerint a Product Backlog-ban:

[cselekmény] + [eredmény] + [célobjektum]

Példa:

Becsülj egy záróárat a részvényekre;

Generálj egy egyedi azonosítót a tranzakciókra;

Változtasd meg a szöveget a kijelzőn.

 

Cikkünknek nem volt célja a részleteit bemutatni a Feature Driven Development igen strukturált és összetett modellének, csak egy egyszerű leírást adni, ami az általános megértést segíti. Bemutatva azt, hogy a Product Backlog-ban user story-k, technikai feladatok, bug-ok, task-ok, feature-k jelennek meg és nem kell feltétlenül követni a user story formakövetelményeit.

Szerző: Bazsi


Megosztás


Tetszett? Akkor ezeket is nézd meg!


Konfliktusmegoldás háromszögek segítségével
A cikkben a konfliktusmegoldás két innovatív eszközét mutatjuk be: a dráma-, és a felhatalmazás háromszögét.

A kultúraváltás elfogadása és ösztönzése
Kultúraváltás sikeres vezetése: hogyan hajtsd végre és teremtsd meg az elfogadást és az összhangot? A helyes vezetői lépések megismerése.

A tönkrement kultúra ellenszere
Cikkünk mélyrehatóan feltárja a kultúra váltás rejtelmeit és bemutatunk egy elengedhetetlen lépést, amely segít a változásban.


Kapcsolat


Következő lépések
Írj egy üzenetet nekünk
Mi felvesszük veled a kapcsolatot 48 órán belül