HTML

Agilitás Blog - az agilitas.hu blogja

Agilis módszertani cikkek, újdonságok, vélemények, intejúk, szoftverek, eszközök és technikák - a gondolkodó, tapasztalt tanácsadók szemével.

Friss topikok

  • kulcsár bence: @Borbándy László: kezdem sejteni, van vagy 4 borbandy laszlo es vagy 6 kulcsar bence a facebookon.... (2013.03.11. 22:51) A UserStory feldarabolás 10 stratégiája
  • Janovszki Zsolt: időnként jó ezt újra meg újra végiggondolni, most pont egy prezentációhoz kellett, gondoltam gondo... (2013.03.04. 23:14) Agile Principles - magyarul
  • kulcsár bence: A cikk célja az volt, hogy a lehető legszélesebb áttekintését adja az agilis szerződéseknek. Jó öt... (2011.02.15. 11:08) Agilis szerződések
  • kulcsár bence: A kérdés jó. Először is tisztázni kell, hogy a csapat agilis csapat-e. A mi esetünkben igen, ami r... (2011.02.08. 23:26) Az önszervező csapat sikerfaktorai
  • Janovszki Zsolt: @sipos_zoli: ott a két pont. Kérlek járuljatok hozzá az átadás dokumentálásához, amire a mai napon... (2010.12.08. 13:01) Szerintem félreértelmezi

Linkblog

A UserStory feldarabolás 10 stratégiája

2011.05.10. 18:00  kulcsár bence

A UserStory egy lefejlesztendő rendszer-funkcionalitást, vagy felhasználói igényt jelent. A funkció meghatárazásakor a felhasználói szemléletű leírás (Szerepkör -> Cél) széleskörűen elterjedt az agilis projektekben. "Mint felhasználó, szeretnék egy vonatjegyet foglalni Párizsba"


A UserStory-k meghatározásakor gyakran használják a következő szabályokat:

3C
Card, Conversation, Confirmation


INVEST
Independent, Negotiable, Valuable, Estimable, Small enough, Testable


USERVOICE FORMAT
AS A <User Role>
I CAN <Goal>
SO THAT <Business Value>


Így a UserStory-k eredményorientáltak és felhasználócentrikusak.

Minden UserStory a csapat által kerül becslésre, valamint a ProductOwner által priorizálva, továbbá elég kicsinek kell lennie, hogy egy Sprint alatt szállítani lehessen (általában a legkisebb csapatok is minimum 3 UserStory-t szállítanak egy Sprint-ben). Ez szükségszerű ha vizsgálni szeretnénk az értékszállítás, a láthatóság, a rugalmasság, a visszajelzés  és a folyamatos javítás előnyeit.
Egy coach életében gyakran előfordul, hogy segítenie kell a ProductOwner-nek felosztani a UserStory-kat kisebb egységekre.
Itt olvasható 10 stratégia amely hatékonyan segít nagyon UserStory-k felosztásakor:

1. Egy folyamat lépései

A felhasználó egy jól definiált folyamat meghatározott lépéseit hajtja végre. A nagy UserStory ezen lépések - státuszok mentén van felosztva és lépésenként lefejlesztve. Minden lépésnek saját UserStory-ja lesz.

2. Forgatókönyv

Egy forgatókönyv mentén történik a feldarabolás. Az egyik UserStory lehet a sikeres bejárási út, a többi pedig az alternatív bejárások:
Ha x történik, akkor…
Ha .., akkor

3. Forgatókönyv szekvenciája

Sokkal precízebb, ha a UserStory-kat a forgatókönyv specifikus lépéseinek szekvenciája mellet osztjuk fel.

4. Műveletek

A UserStroy-k feldarabolásának egyik legkézenfekvőbb és leggyakoribb módja ha műveletek mentén osztják szét. A CRUD (Create, Retrieve, Update, Delete) funkcionális dekompozícionálás jó példa lehet. Természetesen ezekből csoportokat is lehet képezni (pl. két részre bontva) ha az megfelelőbb.

5. Az adatméret vagy adattípus

Szintén gyakori eset. A nagy UserStory a használt objektumok kezelése mentén lesz felbontva (pl. különböző account type, vagy language message)

6. Input, Output típus vagy Konfiguráció

Adat és adattípus variációk konfigurációk függvényében vagy akár UserInterface esetek konfigurációként értelmezve szintén segíthetnek nagyobb UserStory-k felosztásában.

7. Felhasználó típus vagy szerepkör

A UserStory felosztást a terméket használók személye vagy betöltött szerepköre mentén is elvégezhetjük. Ha a UserVoice formátumot használtuk a Story-k meghatározásánál akkor kézenfekvő és egyszerű lehet ez a fajta megközelítés. Másfelől segíthet a bonyolult UserStory-k vizualizálásában.

8. Ismeret szintje

A szétdarabolás elengedhetetlen feltétele a funkcionalitás mély ismerete. Szétbontható egy nagyobb UserStory jól ismert és ismeretlen részekre. A kevéssé ismert UserStoryk-ra értelemszerűen spike-okat lehet indítani, azaz olyan timebox-olt rövid iterációt, amelynek az outputja a vizsgált ismeretlen időbeli megbecslése.

9. Komplexitás szintje

Például egy UserStrory-t a legegyszerűbb legelemibb funkcióra bontjuk, a többi peddig ettől komplexebb vagy többrészlettel bíró darabba.

10. Minőségi szintek

Teljesítmény, biztonság, használhatóság ezek a nem funkcionális követelmények gyakran hangzanak el egy specifikus UserStory-val kapcsolatban. Ezek az elégedettség fokmérői de ugyanakkor segíthenek a UserStory felbontásban is (pl. 60 másodpercen belül jelenjen meg a képernyőn, kevesebb mint 30 másodpercen benül jelenjen meg a képrenyőn, valós időben jelenjen meg a képernyőn).
 

4 komment

A bejegyzés trackback címe:

http://agilitas.blog.hu/api/trackback/id/tr172893603

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

Borbándy László 2013.02.14. 09:36:22

Szia Bence,
Egy nagy projekten kezdünk a cégemmel dolgozni és szeretnénk kérni segítséget a scrum alkalmazásához. Ha érdekel FB-n írjál rám lsz.

kulcsár bence 2013.03.11. 10:51:06

@Borbándy László: Szia, kuldtem, semmi valasz. Megkaptad?

Borbándy László 2013.03.11. 22:03:08

Szia nem kaptam semmit. Probald ujra lsz

kulcsár bence 2013.03.11. 22:51:12

@Borbándy László: kezdem sejteni, van vagy 4 borbandy laszlo es vagy 6 kulcsar bence a facebookon. talan egyszerubb igy: bence.kulcsar@agilitas.hu