Az epikák halottak. Itt kell tennünk helyette.

Mit nem nyilvánítottak már halottnak? A tesztvezérelt fejlesztést évekkel ezelőtt temették el. Ennek ellenére tovább terjed. Természetesen Agile is meghalt. De még a hagyományos vállalatok is kapcsolatba lépnek a Scrummal. A halottak továbbra is élnek, de valami halottnak nyilvánítása mindig jó a frappáns címsor számára. Ebben az értelemben tanúja lehet, hogy agilis gyakorlatként hogyan pusztítom el az eposzokat.

Mik az eposzok?

A kifejezés homályos. Ennek előnyei vannak. Az eposzok inkább kommunikációra szolgálnak, mint specifikációra. A homályosság sokoldalúvá teszi őket. De fennáll a félreértések veszélye. Ragaszkodom Mike Cohn definíciójához:

A Scrum eposz nagy felhasználói történet. (Forrás)

A kifejezést így használom: Az eposz olyan történet, amely túl nagy ahhoz, hogy egy Scrum sprintben megvalósítható legyen. A Product Backlog tetején található elemek tehát nem eposzok, hanem kis történetek. A lemaradásban általában epikákat talál. Idővel az eposzokat olyan sztorikra "szeletelik", amelyek sprintbe vonhatók.

Ezt tanítottam évek óta a tanfolyamaimon. Úgy tűnik, hogy ez az általános konszenzus. Első pillantásra intuitív. Azért vagyok itt, hogy elmagyarázzam, miért nem praktikus.

3 epaktikus módszer az eposzok kezelésére

Eddig háromféleképpen találkoztam a vállalatokkal az eposzokkal. Egyik sem praktikus. Hívjuk őket:

Pusztulás

Linkek

Fák

1. Oldódás

A feloszlás elve egyszerű. Az eposz teljesen összetevőire, az egyes kis történetekre tagolódik.

Például egy online repülési portál epikus „Book flight” -ját az egyes folyamatlépésekre lehet bontani. Tehát „Bejelentkezés”, „Repülés keresése” stb. Minden folyamatlépés történetté válik. A csapat becsüli a történetet. Amíg túl nagy, a csapat tovább szeleteli. Miután az összes történet elég kicsi ahhoz, hogy beférjen a sprintekbe, a csapat törli az eposzt, és megkezdi a történetek fejlesztését.

A teljesség alapgondolata zavar. A feloldás azt sugallja, hogy egy téma előre meghatározott hatókörrel kiegészíthető.

De ha a fejlesztések során lehetségesek a történetek módosítása, akkor nem határozhatja meg minden történetet előre.

A Scrum Guide szerint:

A termékállomány soha nem teljes. […] A követelmények soha nem változnak.

Ha fix hatókört kell átadnia, hagyja abba a színlelést. Felejtsd el az eposzokat, és kezdetben írd le a részletes követelményeket. Csak akkor ne állítsd, hogy agilis vagy.

2. Linkek

Ha nem oldod fel teljesen az eposzaidat, célszerű hivatkozásokat használni. Az eposzok maradnak, a lemaradásban. Új kis történeteket kapcsol össze az eposzokkal, amelyekből származnak.

A kockázat az, hogy az idő múlásával az eposzok száma növekszik. A lemaradás felpuffad. Olyan epikákat tartalmaz, amelyekre már nincs szükséged. Az érdekelt fél már nincs a társaságban. Vagy a téma már nem releváns.

Természetesen időnként megtisztíthatja lemaradását. Ezt nem hozzáadott értékű munkának tekintem. És elkerülheti, ahogy később leírom.

3. Fák

Egy másik módszer az eposzok és történetek faként való ábrázolása:

Eposz szerint csoportosítja a kis történeteket. Nem rossz ötlet. De amit elveszít, az a lemaradás rendezett listája. Hogyan határozza meg akkor a megvalósítási sorrendet?

Természetesen használhat egy digitális eszközt, amely mindkét nézetet támogatja. A kockázat: túl sok időt és erőfeszítést fordít az eszközökre. Mi a vélemény? Melyek az attribútumok? Mi az alapul szolgáló adatmodell? Érdekes kérdések. De agilis megközelítésben nem szabad kiemelt fontosságúnak lenniük.

Összefoglalva, a csoportosítás ötlete jó. De ez időigényes.

Az eposzok alternatívája

Régóta létezik alternatíva. Még ugyanabban a blogbejegyzésben is megemlíti Mike Cohn, amelyet fentebb linkeltem.

Beszélek témákat .

Egy téma felfogható a történetek további attribútumaként. Normális esetben több történet ugyanazt a témát osztja meg. A „Keresési járat” történet témája lehet „Könyvrepülés”. A lemaradás egy kivonata így nézhet ki:

A témákat nem kezeljük különálló elmaradt elemként. Ez kiküszöböli a Linkek fejezetben tárgyalt takarítási munkát. Az jó.

De amit elveszít, az a fokozatos finomítás folyamata a nagy eposzoktól a sprintben megvalósítható történetekig. Ez rossz.

Szerencsére vannak olyan gyakorlatok, amelyek lehetővé teszik ezt a finomítást a lemaradáson kívül. A témák azonosításának egyik módja a használati eset diagramja:

Az a szép az ilyen diagramokban, hogy a nagy absztrakció és a grafikus ábrázolás miatt a „Nagy képet” mutatják. Erre a lemaradás alkalmatlan.

A felhasználási esetek neve később az elmaradt témákká válik. De hogyan juthat el a használati esettől a történetekig? Ehhez Jeff Patton Story Mapping alkalmas:

A példa térkép felső két sora a „Book flight” és a „Profil kezelése” felhasználási eseteket és azok alapvető folyamatát mutatja. Az egyes lépések alatt a csapat felakasztja az alternatívákat: egyéb folyamatokat, hibákat és így tovább. Ezeket a sárga jegyzeteket felhasználói feladatoknak nevezzük.

A Backlog Refinement-ben a csapat a felhasználói feladatokból származtatja a történeteket. Egy feladat szolgálhat a történet címeként. A csapat részleteket, például elfogadási kritériumokat ad hozzá a történetekhez.

A következmények

Ennek az alternatív megközelítésnek a következményei vannak. Például a Product Backlog csak a következő 1-2 sprint történetét tartalmazza. Tehát talán 10–20 történet.

Minden tevékenység, például további prioritások meghatározása, becslése és az elfogadási kritériumok kidolgozása, csak ezeknél a történeteknél zajlik. Ahogy a 10. agilis elv mondja:

Az egyszerűség - az el nem végzett munka mennyiségének maximalizálásának művészete - elengedhetetlen.

Ha a menedzsment betekintést szeretne kapni a fejlesztés előrehaladásába, ez három szinten lehetséges:

  • A kezelési esetek diagramjai vagy témái hosszú távú perspektívát nyújtanak. 1 évig, vagy akár tovább is. De: nem alkalmasak a részletek megadására.
  • A történeti térképek képezik az alapot a kiadás tervezéséhez. A kiadvány iránt érdeklődő érdekelt felek elkészítik a történet térképét a csapattagokkal. (Az új eredmények miatt a hatókör változhat a fejlesztés során.)
  • Azok, akik mély betekintést akarnak kapni és befolyásolni a részleteket a fejlesztés során, részt vesznek a Sprint Review és a Backlog Refinement programokban .

Csak kis magasságban látjuk a részleteket. A termékhátralék pedig alapvetően olyan, mint egy bevásárló lista. Írnád, mit szeretnél vásárolni egy év múlva?

Végül, de nem utolsósorban az eposzok halála a fogyasztóság elhalását hirdeti. Ha szeretne valamit, akkor meg kell állapodnia a csapattal és szorosan együtt kell működnie.

Halott

A kollégákkal folytatott megbeszélés során rámutattak, hogy egy eposz feloszlatása után is hozzáadhatók kis történetek. Így van, és számomra ez elfogadható megoldás. Ami azonban ebben az esetben elveszett, az a „Nagy kép”, amelyet a használati eset diagramján bemutattam.

Végül a termék alkalmassága a felhasználók számára meghatározza annak sikerét. Nem hogy készült. Ez minden fejlesztési gyakorlatra vonatkozik, beleértve az eposzokat is.

Talán kitalált egy értelmes módszert az eposzok kezelésére?

Megtanulhatja, hogyan kezelheti hatékonyan a termékhátralékát az online tanfolyamom felkeresésével. Ez a cikk először a HOOD Blogon jelent meg német nyelven.