absztrakt
A könyv egy elbeszélt algoritmus, amely agilis technikák segítségével a fejlesztési folyamatot az ötlettől a megvalósításig hajtja végre. A folyamat lépésekben van lefektetve, és minden lépésnél fel van tüntetve az eljárási lépés módszerei. A szerző rámutat arra, hogy a módszerek többsége nem eredeti, anélkül, hogy azt állítaná, hogy eredeti. De a jó írásstílus és a folyamat némi integritása nagyon hasznossá teszi a könyvet.
A felhasználói történetek feltérképezésének egyik kulcstechnikája az ötletek és teljesítmények strukturálása, miközben a felhasználó halad a folyamaton.
Ugyanakkor a folyamat többféleképpen is leírható. Lépéseket építhet, amikor elér egy kulcsértéket, vagy egyszerűen elképzelheti a felhasználók munkanapját a rendszer használatával. A szerző arra helyezi a hangsúlyt, hogy a folyamatokat fel kell vázolni, felhasználói történet formájában meg kell beszélni egy folyamattérképen, ez adta a felhasználói történettérkép elnevezést.
Kinek szüksége van rá?
Informatikai elemzőknek és projektmenedzsereknek. Kötelező olvasmány. Könnyen és élvezetesen olvasható, a könyv közepes méretű.
Áttekintése
A legegyszerűbb formájában ez így működik.
A látogató bejön egy kávézóba, kiválasztja az ételeket, megrendeli, ételt kap, eszik és fizet.
Minden szakaszban írhatunk követelményeket arra vonatkozóan, hogy mit akarunk a rendszertől.
A rendszernek meg kell mutatnia az ételek listáját, minden ételnek megvan az összetétele, súlya és ára, és a kosárba kell tenni. Miért bízunk ezekben a követelményekben? Ezt a követelmények „standard” leírása nem írja le, és ez kockázatokat jelent.
Azok az előadók, akik nem értik, miért van erre szükség, általában rosszul cselekszenek. Azok az előadók, akik nem vesznek részt az ötletalkotás folyamatában, nem vesznek részt az eredményben. Az Agilis azt mondja, elsősorban ne a rendszerre koncentráljunk, hanem az emberekre, a fogyasztókra, azok feladataira, céljaira.
Személyeket hozunk létre, részleteket adunk nekik az empátia érdekében, és a személyiség oldaláról kezdünk el mesélni.
Zakhar irodai alkalmazott ebédelni ment, és szeretne egy gyors uzsonnát. Mi kell neki? Az ötlet az, hogy valószínűleg üzleti ebédre vágyik. Egy másik elképzelés az, hogy azt akarja, hogy a rendszer emlékezzen a preferenciáira, mert diétázik. Egy másik ötlet. Azt akarja, hogy azonnal hozzanak neki kávét, mert hozzászokott, hogy ebéd előtt kávét iszik.
És van üzlet is (a szervezeti karakter egy szervezet érdekeit képviselő karakter). A vállalkozások növelni szeretnék az átlagos csekket, növelni szeretnék a vásárlások gyakoriságát és növelni a profitot. Az ötlet az, hogy néhány konyha szokatlan ételeit kínáljuk. Egy másik ötlet - mutassuk be a reggelit.
Az ötleteket lehet és kell konkretizálni, átalakítani és felhasználói történet formájában bemutatni. A Zakhar Business Center alkalmazottjaként szeretném, ha a rendszer felismerne, hogy a preferenciáimnak megfelelő menüt kaphassak. Pincérként szeretném, ha a rendszer értesítene, mikor kell megközelíteni az asztalt, hogy az ügyfél elégedett legyen a gyors kiszolgálással. Stb.
Több tucat történet. Következő a rangsorolás és a lemaradás? Jeff rámutat a felmerülő problémákra: az apró részletekbe való belemerülés és a fogalmi megértés elvesztése, valamint a funkcionalitás prioritása rongyos képet hoz létre a célokkal való összeegyeztethetetlenség miatt.
A szerző útja: Nem a funkcionalitást helyezzük előtérbe, hanem az eredményt = amit a felhasználó a végén kap.
Egy nyilvánvaló, nem nyilvánvaló szempont: a rangsorolást nem az egész csapat végzi, mert az eredménytelen, hanem három ember. Az első az üzletért, a második a felhasználói élményért, a harmadik pedig a megvalósításért felelős.
Válasszuk ki a minimumot egy felhasználói probléma megoldásához (minimális életképes megoldás).
Részletezzük az elsőbbséget élvező ötleteket felhasználói történetek, tervezési vázlatok, megszorítások és üzleti szabályok segítségével a felhasználói történettérképen úgy, hogy elmondjuk és megbeszéljük a csapattal, mire van szükségük az embereknek és az érdekelt feleknek a folyamat egyes lépéseiben. A fennmaradó ötleteket megvizsgálatlanul hagyjuk a lehetőségek hátralékában.
A folyamat balról jobbra haladva van felírva a kártyákra, az ötletek pedig a folyamat lépései alatt találhatók. A kölcsönös megértés biztosítása érdekében elengedhetetlen, hogy az egész történeten keresztül vezető utat a csapattagokkal együtt megbeszéljék.
Az ilyen jellegű kidolgozás a folyamatoknak megfelelő integritást teremt.
A kapott ötleteket tesztelni kell. A nem csapattag felveszi az illető kalapját, és fejében éli meg az illető napját, megoldva a problémáját. Lehetséges, hogy nem látja a fejleményeket, újra kártyákat készít, és a csapat alternatívákat fedez fel magának.
Ezután következik a részletezés az értékeléshez. Három ember elég ehhez. Felelős a felhasználói élményért, fejlesztő, tesztelő egy kedvenc kérdéssel: „Mi lenne, ha...”.
A megbeszélés minden szakaszában a felhasználó történetének folyamattérképét követi, amely lehetővé teszi a felhasználó feladatának szem előtt tartását a koherens megértés érdekében.
A szerző véleménye szerint szükséges-e a dokumentáció? Igen, szükségem van rá. De mint jegyzetek, amelyek lehetővé teszik, hogy emlékezzen arra, hogy miben állapodott meg. Egy kívülálló bevonása ismét megbeszélést igényel.
A szerző nem mélyed el a dokumentáció elegendőségének témájában, a vita szükségességére helyezi a hangsúlyt. (Igen, szükség van a dokumentációra, akárhogyan is állítják az agilishoz mélyen nem értő emberek). Ezenkívül a képességek egy részének kidolgozása a teljes rendszer teljes átdolgozásának szükségességéhez vezethet. A szerző felhívja a figyelmet a túlzott kidolgozottság veszélyére abban az esetben, ha az ötlet hibás.
A kockázatok kiküszöbölése érdekében gyorsan visszajelzést kell kapni a készülő termékről, hogy minimalizáljuk a „rossz” termék létrehozásából adódó károkat. Készítettünk egy vázlatot az ötletről - validáltuk a felhasználóval, felvázoltuk az interfész prototípusait - validáltuk a felhasználóval stb. (Külön is van egy kis információ a programprototípusok érvényesítéséről). A szoftverkészítés célja – különösen a kezdeti szakaszban – a tanulás a gyors visszacsatoláson keresztül, ennek megfelelően az első termék olyan vázlat, amely egy hipotézist igazolni vagy cáfolni képes. (A szerző Eric Ries „Startup using Lean methodology” című munkájára támaszkodik).
A történettérkép segít a kommunikáció javításában, ha a megvalósítást több csapaton keresztül hajtják végre. Mi legyen a térképen? Amire szüksége van a beszélgetés folytatásához. Nem csak egy felhasználói sztori (ki, mit, miért), hanem ötletek, tények, felületvázlatok stb...
Ha az előzménytérképen lévő kártyákat több vízszintes vonalra osztja, feloszthatja a munkát kiadásokra - emelje ki a minimumot, a növekvő funkcionalitás rétegét és a meghajlásokat.
A folyamattérképen történeteket mesélünk el.
Egy alkalmazott jött ebédelni.
Mit akar? Szolgáltatási sebességek. Úgy, hogy az ebédje már az asztalon vagy legalább egy tálcán várja. Hoppá – kihagyott lépés: az alkalmazott enni akart. Bejelentkezett, és az üzleti ebéd lehetőséget választotta. Látta a kalóriatartalmat és a tápanyagtartalmat, hogy segítsen neki diétázni és nem hízni. Képeket látott az ételről, hogy eldöntse, eszik-e azon a helyen vagy sem.
Ezután megy ebédelni és vacsorázni? Vagy talán az ebédet az irodájába szállítják? Ezután a folyamat lépése az étkezési hely kiválasztása. Azt akarja látni, hogy mikor szállítják ki neki, és mennyibe kerül, így választhat, hogy hol töltse idejét és energiáját - lemenni vagy dolgozni. Meg akarja nézni, milyen zsúfolt a kávézó, hogy ne lökdösödjön a sorban állás.
Aztán az alkalmazott bejött a kávézóba. Látni akarja a tálcáját, hogy el tudja venni, és egyenesen vacsorázni tudjon. A kávézó pénzt akar elfogadni, hogy pénzt keressen a szolgáltatásból. Az alkalmazott minimális időt szeretne veszíteni a kávézóval való elszámolásokon, hogy ne veszítse el a drága időt haszontalanul. Hogyan kell csinálni? Fizessen előre, vagy fordítva a szolgáltatás után távolról. Vagy fizessen a helyszínen egy kioszk segítségével. Mi ebben a legfontosabb? Hányan hajlandóak bankkártyával fizetni az ebédért? Hány ember bízna meg ebben az étkezdében, hogy eltárolja a kártyaszámát ismételt fizetéshez? Területi kutatás nélkül nem egyértelmű, tesztelésre van szükség.
A folyamat minden lépésében valamilyen módon funkcionalitást kell biztosítani, ehhez egy személyt kell alapul venni, és ki kell választani, hogy mi a fontosabb számára (ugyanaz a három választó). Követte a történetet a végéig = életképes megoldást hozott.
Ezután jön a részletezés. Az ügyfél látni akarja, hogy a kávézó mennyire elfoglalt, hogy ne lökdösödjön a sorban állás. Mit akar pontosan?
Nézze meg az előrejelzést, hogy hány ember lesz 15 percen belül, amikor odaér
Tekintse meg egy kávézó átlagos kiszolgálási idejét és annak dinamikáját fél órával korábban
Tekintse meg a helyzetet és az asztalok foglaltsági dinamikáját
Mi van akkor, ha az előrejelző rendszer nem egyértelmű eredményt ad, vagy leáll?
Tekintse meg videón keresztül a kávézóban a sorokat, valamint az asztalok foglaltságát. Hmm, miért ne tenné meg előbb?!
A szerző rámutat egy kis gyakorlatra: próbáld meg elképzelni, mit csinálsz reggel ébredés után. Egy kártya = egy akció. Nagyítsa ki a kártyákat (kávédarálás helyett igyon egy élénkítő italt), hogy eltávolítsa az egyes részleteket, ne a megvalósítás módjára, hanem a célra összpontosítva.
Kiknek szól ez a könyv: informatikai elemzőknek és projektmenedzsereknek. Kötelező olvasmány.
Apps
A vita és a döntéshozatal 3-5 fős csoportokban hatékony.
Írja fel az első kártyára, hogy mit kell fejleszteni, a másodikra - javítsa ki, amit az elsőnél, a harmadikra - javítsa ki az első és a második.
Készítsen történeteket, mint a süteményeket – ne úgy, hogy kiír egy receptet, hanem úgy, hogy megtudja, kinek, milyen alkalomra és hány embernek szól a torta. Ha lebontjuk az eladásokat, akkor az nem sütemények, krémek stb., hanem kis kész sütemények gyártására irányulna.
A szoftverfejlesztés hasonló a filmkészítéshez, amikor a forgatás megkezdése előtt gondosan ki kell fejleszteni és csiszolni a forgatókönyvet, meg kell szervezni a jelenetet, a színészeket stb.
Mindig lesz forráshiány.
Az erőfeszítések 20%-a kézzelfogható, 60%-a érthetetlen, 20%-a káros – ezért fontos a tanulásra koncentrálni, és negatív eredmény esetén ne essen kétségbe.
Közvetlenül kommunikáljon a felhasználóval, érezze magát a helyében. Koncentrálj néhány problémára.
A sztori részletezése, értékelésre való kidolgozása a scrum legrosszabb része, a megbeszéléseket akvárium módban tegyük stand-upba (3-4 ember megbeszéli a táblánál, ha valaki részt akar venni, lecserél valakit).
Forrás: will.com