A mai bejegyzéshez a sorozatban feldolgozott cikk-ből ezt a mondatot (legalábbis egy részét) választottuk: “Product development and architecture aren't the programmer's job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level ‘user stories’.” - “A termékfejlesztés és az architektúra nem a fejlesztő feladata, hiszen az tovább tart két hétnél. Ehelyett a programozó atomi, feature-szintű ‘user story’-kon dolgozik”.

Először vizsgáljuk meg, mit jelent a termékfejlesztés kifejezés. (A komplex architektúráknak külön bejegyzést szentelünk majd.) A businessdictionary.com szerint a termékfejlesztés “termékek létrehozása új vagy különböző jellemzőkkel, amik új vagy további előnyöket biztosítanak a vevő számára. A termékfejlesztés állhat létező termék módosításából vagy bemutatásából, vagy egy teljesen új termék kialakításából ami újonnan definiált vevői szükségletet elégíg ki, vagy egy piaci rést tölt be”.

Mind ebben a definícióban, mind az agilis kiáltványban hiba, hogy nem tesz különbséget vevő és felhasználó között. Ez a kettő sokszor egybeesik, de nagyon sokszor nem: más veszi meg a terméket és más fogja használni. Ideális esetben mindig a felhasználó számára készülne a termék, de tudjuk, előfordul, hogy egy bizonyos funkcióra csak azért van szükség, hogy el lehessen adni a terméket; használni senki nem fogja. Ez nem tragédia, de érdemes tudatosítani, mit miért csinálunk és annak megfelelő energiát fektetni bele.

Az egyszerűség kedvéért engedjük most meg ezt a pongyolaságot, és vizsgáljuk így a termékfejlesztés kérdését. Ha elfogadjuk a fenti definíciót, akkor kijelenthetjük: soha nem volt még annyira a fejlesztő feladata a termékfejlesztés, mint most. Sőt, nem csak a fejlesztőé, a teljes fejlesztőcsapaté, amiben természetesen a tesztelők is helyet kapnak.

Valóban user story-kon dolgoznak a csapattagok, de mi az a user story? Egy kezdetben szándékosan alulspecifikált vevői igény megfogalmazási mód, mely segít minden résztvevőnek beleélnie magát a felhasználó szerepébe és kikényszeríti az igény közös megértése és a legjobb megoldás megtalálása érdekében az üzlet és fejlesztés közötti párbeszédet.

Az üzlet nem azt kommunikálja a fejlesztés számára, hogyan működjön a rendszer, hanem hogy mi az a probléma, amit a rendszerrel meg szeretnénk oldani.

A user story formátum másik nagy előnye, hogy vertikális feladatokat definiál: egy felhasználói igény kielégítéséhez a rendszer minden rétegében szükséges módosítások egy story részét képezik. Ellentétben a horizontális megközelítéssel, amikor egy feladat pl. új adatbázistáblát tervezni, sok esetben a valós felhasználói szükségletek, a táblában tárolandó adatok használati módjainak pontos ismerete nélkül.

A követelményeket tehát úgy daraboljuk és úgy fogalmazzuk meg, hogy a fejlesztőcsapat tagjai felhasználói szemmel tekinthessenek a rendszerre, és így gondolhassák végig a felmerült feladatot. Ha egy követelmény nem ad semmilyen értéket a felhasználónak, nem fogjuk tudni jól megfogalmazni user story-ként. Klasszikus példája ennek, amikor a story hazudik, egy fejlesztési ötletet “ráfogunk” a felhasználóra, pl.:

Én, mint az online hírportál olvasója
Szeretném, ha az oldal tele lenne mindenféle felugráló reklámokkal, amik miatt az engem érdeklő cikket alig bírom elolvasni
Azért, hogy a kiadónak legyen valami bevétele