RI Consulting
keresési feltétel:

A viselkedésvezérelt fejlesztés szerepe a user story-kban


A viselkedésvezérelt fejlesztés arra ösztönzi a csapatokat, hogy konkrét példákkal hivatalossá tegyék az alkalmazás működésének megértését.

A viselkedésvezérelt fejlesztés (Behavior Driven Development, BDD) egy agilis szoftverfejlesztési folyamat, amely ösztönzi az együttműködést a fejlesztők, a QA és a nem műszaki vagy üzleti résztvevők között egy szoftverkészítő folyamatban.

Miben segít a viselkedésvezérelt fejlesztés?

A BDD ösztönzi a csapatokat, hogy beszélgetéssel és konkrét példákkal hivatalossá tegyék az alkalmazás működésének közös megértését. A tesztvezérelt fejlesztésből (TDD) alakult ki. A viselkedésvezérelt fejlesztés ötvözi a TDD általános technikáit és elveit a tartományvezérelt tervezés és objektumorientált elemzés és tervezés ötleteivel, hogy a szoftverfejlesztő és -kezelő csapatok számára megosztott eszközöket és közös folyamatot biztosítson a szoftverfejlesztésben való együttműködéshez.

Hogyan kapcsolódik a BDD a user story-hoz?

Rövid bevezető rész a már ismert szerkezettel: "Én, mint(user szerep) azt szeretném, hogy (cselekmény) azért, mert (üzleti érték).".

 „Én, mint egy autó tulajdonos, azt szeretném, hogy az autó magától meghatározza a sebességhatárt és álljon be erre, azért, mert így nem kell figyelnem a sebességre és nem lesz gyorshajtásom.”

BDD Elfogadási kritériumok a story-hoz (Acceptance criteria)

Minden user storynak valamilyen módon a következő struktúrát kell követnie:

  • Cím
  • Narratíva

A narratíva minden egyes forgatókönyvének leírása a következő szerkezettel:

Given - Adott: a forgatókönyv elején, egy vagy több záradékban szereplő kezdeti környezet;

When - Mikor: a forgatókönyvet kiváltó esemény;

Then - Ezután: a várt eredmény, egy vagy több záradékban.

A viselkedésvezérelt elfogadási kritérium példák

Elfogadási kritériumok a példánkhoz, amiben láthatjuk, hogy a BDD narratíva mennyivel rugalmasabb, könnyebben érthető és pontosabb megközelítést adhat:

"Adott egy sebességhatár, mikor az autó sebessége eléri, azután álljon be közel a határhoz, de ne lépje át".

És

"Adott, amikor az autó halad az úton, mikor a sebességhatár változik, ezután, a sebesség változzon, de ne váltson ki hirtelen erőhatást"

Az agilis fejlesztések során a Product Owner, a fejlesztők és a tesztelők közös megértéssel csökkentik a rework típusú veszteségek kockázatát és közösen határozzák meg az elfogadási teszteket, amiket rögzítenek a story-kban, úgy, hogy minden résztvevő hozzá tudja tenni a saját területének követelményeit (üzlet, technológia, tesztelés, fejlesztés). És mivel közösen határozzák meg, így az információáramlás nem sérül.

Elfogadási tesztek

Az elfogadási tesztek az alábbiak lehetnek:

"Adott, a sebességhatár, ami 50 km/h, mikor az autó halad az úton, ezután a sebesség essen 49-50 km/h óra közé."

És

"Adott, a sebességhatár, ami 50 km/h, mikor a sebességhatár változik 30 km/h-ra, ezután a fékezési sebesség legyen 5 méter/másodperc."

A user story-knak több formája is van, egy későbbi cikkünkben majd azzal foglalkozunk, hogy az FDD rendszerben hogyan néz ki.

Szerző: Bazsi


Megosztás


Tetszett? Akkor ezeket is nézd meg!


Az évtizedekre szóló büdzsé tervezés a múlt az IKEA-nál
A hagyományos büdzsé tervezés helyett az IKEA szcenáriókat, forgatókönyveket tervez, ami növeli a szervezet rugalmasságát.

Az Agilis Coaching Növekedési Kerék
Az Agilis Coaching Növekedési Kerék, egy eszköz, amivel segíteni és fejleszteni lehet a csapatokat az agilis gyakorlatok alkalmazásával.

A Shu-Ha-Ri alkalmazása az agilis folyamatokban
“Mi mester képzünk, nem örökös tanítvány!” - szól a RI egyik legfontosabb mottója. És, hogy miből is ered ez a mondat? A Shu-Ha-Ri egy japán harcművészeti fogalom, amelyet a mesterré válás folyamatának az egyes szakaszaira használnak.


Kapcsolat


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