Összefoglaló
A könyv a fejlesztési folyamat algoritmusát meséli el az ötlettől a megvalósításig az agilis technikák alkalmazásával. A folyamatot lépésekre bontja, és minden lépésnél megjelöli a hozzá tartozó módszereket. A szerző hangsúlyozza, hogy a legtöbb módszer nem eredeti, nem is célja az eredetiség. De a jó stílus és a folyamat bizonyos egysége rendkívül hasznossá teszi a könyvet.
A felhasználói történetek térképének kulcsfontosságú technikája az ötletek strukturálása és a felhasználói folyamat során a célok meghatározása.
A folyamatot különböző módon lehet bemutatni. Létrehozhatjuk a lépéseket az alapvető érték elérése során, vagy egyszerűen bemutathatjuk a felhasználók munkanapját, ahogy a rendszert használják. A szerző hangsúlyozza, hogy a folyamatokat fel kell vázolni, és felhasználói történetként elmondani a folyamat térképén, ami a felhasználói történetek térképének nevét adja.
Kinek szükséges ez
IT-elemzőknek és projektvezetőknek. Kötelező olvasmány. Könnyen és kellemesen olvasható, a könyv közepes méretű.
Vélemény
A legegyszerűbb formájában, ahogyan ez működik.
A látogató elmegy a kávézóba, választ ételek közül, rendel, kap ételt, eszik, majd fizet.
Minden lépésnél lehetőség van igények leírására, hogy mit akarunk a rendszertől.
A rendszernek meg kell mutatnia az ételek listáját, minden ételhez tartozik összetevő, súly és ár, valamint lehetőséget kell biztosítania a kosárba helyezésre. Miért vagyunk biztosak ezekben az igényekben? A "szabványos" követelményleírásban ez nem szerepel, ami kockázatokat teremt.
A kivitelezők, akik nem értik, miért van erre szükség, általában nem azt teszik, amire szükség van. Azok a kivitelezők, akik nincsenek bevonva az ötlet létrehozási folyamatába, nincsenek bevonva az eredménybe sem. Az agilis azt mondja, hogy fókuszáljunk először nem a rendszerre, hanem az emberekre, a felhasználókra, az ő feladataikra és céljaikra.
Készítünk személyiségeket, empátia céljából részleteket adunk meg nekik, és a személyiségek oldaláról kezdünk történeteket vázolni.
A hivatalnok Zachar elment ebédelni, és gyorsan szeretne egy harapnivalót. Mire van szüksége? Az ötlet — talán üzleti ebédet szeretne. További ötlet, hogy szeretné, ha a rendszer emlékezne a preferenciáira, mert diétán van. Még egy ötlet. Szeretné, ha azonnal hoznának neki kávét, mert megszokta, hogy ebéd előtt kávét iszik.
Van egy másik üzlet (szervezeti karakter — egy karakter, aki egy bizonyos szervezeti érdekeit képviseli). Az üzlet szeretné növelni az átlagos vásárlási értéket, növelni a vásárlások gyakoriságát, növelni a profitot. Az ötlet – miért ne kínáljunk különleges ételeket egy adott konyhából? Egy másik ötlet – miért ne vezessük be a reggelit?
Az ötleteket konkrétizálni, átalakítani és user story formájában megfogalmazni szükséges és fontos. Mint a Zahari üzletközpont dolgozója, azt szeretném, ha a rendszer felismerne és az én preferenciáimnak megfelelő menüt küldene. Mint pincér, azt szeretném, ha a rendszer értesítene arról, mikor kell odamenni a asztalhoz, hogy az ügyfél elégedett legyen a gyors kiszolgálással. És így tovább.
Több tucat történet. Továbbá prioritás és backlog? Jeff rámutat a felmerülő problémákra: az apró részletekbe való belebonyolódás és a koncepcionális megértés elvesztése, plusz a funkciók priorizálása darabos képet eredményez a célok összehangolatlansága miatt.
A szerző útja: nem a funkciókat priorizáljuk, hanem az eredményt = azt, amit a felhasználó végül kap.
Nyilvánvaló, hogy a prioritási ülést nem az egész csapat, hanem három ember tartja, mivel ez nem hatékony. Az első a vállalatért felelős, a második a felhasználói élményért, a harmadik pedig a megvalósításért.
Határozzunk meg minimumot a felhasználó egy feladatának megoldásához (minimum életképes megoldás).
Részletezzük az első prioritás ötleteit user story, dizájn skiccek, korlátozások és üzleti szabályok segítségével a felhasználói történetek térképén, mesélve és megbeszélve a csapattal, hogy mit szeretnének a szereplők és az érdekeltek a folyamat minden lépésénél. A többi ötletet hagyjuk feldolgozatlanul, a lehetőségek backlogjában.
A folyamatot balról jobbra kell kártyák formájában rögzíteni, az ötletek pedig a folyamat lépései alatt lévő kártyákon. Fontos, hogy a csapat tagjaival együtt végig kell beszélni az egész történetet, hogy kölcsönös megértés alakuljon ki.
Ez a módszer a folyamatoknak való megfelelés összhangját teremti.
A megszerzett ötleteket ellenőrizni kell. Nem csapattag felölti a karakter sapkáját, és egy napot él át a karakter fejében, megoldva a feladatát. Lehetséges olyan eset, amikor nem látja az előkészületeket, újra kártyákat alkotva, míg a csapat alternatívákat fedez fel.
Ezután a részletezés a becsléshez történik. Ehhez elegendő három ember. A felhasználói élményért felelős, a fejlesztő és a tesztelő, akinek kedvenc kérdése: "Mi lenne, ha...".
Minden szakaszban a felhasználói történetek folyamatábráját vitatják, ami lehetővé teszi, hogy a felhasználói feladatot szem előtt tartva egységes megértést alakítsanak ki.
Szükséges a dokumentáció a szerző véleménye szerint? Igen, szükséges. De inkább jegyzetként, amelyek segítenek emlékezni arra, miről állapodtak meg. Az érintett személy bevonása ismételten megköveteli a diskurzust.
A szerző nem mélyed el a dokumentáció elegendőségének kérdésében, főként a megbeszélések szükségességére helyezi a hangsúlyt. (Igen, szükséges a dokumentáció, még ha az emberek, akik nem mélyen értik az agilis módszertant, ezt vitatják is). Emellett csak a lehetőségek egy részének kidolgozása a teljes rendszer újbóli áttervezésének szükségességéhez vezethet. A szerző rámutat a túlzott kidolgozottság kockázatára, ha a gondolat nem talál célt.
A kockázatok csökkentéséhez gyorsan kell visszajelzést kapni a létrehozott termékről a "nem megfelelő" termék létrehozásából fakadó károk minimalizálása érdekében. Készítettek egy ötletvázlatot - validálták a felhasználónál, egy interfész prototípusát - validálták a felhasználónál, stb. (Külön említi, hogyan lehet validálni a programok prototípusaikat). A szoftverfejlesztés céljai, különösen a kezdeti szakaszban - tanulás a gyors visszajelzés által, így az első létrehozott termék vázlatok, amelyek képesek bizonyítani vagy cáfolni a hipotézist. (A szerző Eric Ries "Lean Startup" című munkájára támaszkodik).
A történet térkép segít a kommunikációk kialakításában, ha a megvalósítás több csapat által történik. Mi legyen a térképen? Az, ami szükséges a beszélgetés fenntartásához. Nemcsak a felhasználói történetek (ki, mit, miért), hanem ötletek, tények, interfészvázlatok stb.
A történet térképen lévő kártyák vízszintes vonalakra osztásával a munkákat kiadásokká lehet sorolni - kiemelni a legminimálisabb, a funkcionalitás bővítési rétegét és a csomagolásokat.
A folyamat térképen a történeteket definiáljuk.
Az alkalmazott ebédre érkezett.
Mit akar? Szolgáltatási sebességet. Azt szeretné, hogy az ebéd már az asztalán vagy legalább egy tálcán várja. Hoppá — kihagyott lépés: az alkalmazott enni akar. Belépett a rendszerbe, és kiválasztotta a napi menüt. Látta az étel kalóriatartalmát és tápanyagtartalmát, hogy betartsa a diétáját és ne hízzon el. Megnézte az étel képeit, hogy eldönthesse, eszik-e ebben a helyen vagy sem.
Ezután elmegy lunchért és ebédelni? Vagy talán a lunch az irodájába érkezik? Akkor a folyamat lépése — az étkezés helyének kiválasztása. Látni akarja, mikor érkezik meg és mennyibe fog kerülni, hogy eldönthesse, hova pazarolja az idejét és energiáját — lemenni vagy dolgozni. Látni szeretné a kávézó forgalmát, hogy ne kelljen sorban állnia.
Ezután az alkalmazott megérkezett a kávézóba. Azt szeretné látni, hol van a tálcája, hogy el tudja venni és azonnal ebédelni indulhasson. A kávézó pénzt akar elfogadni, hogy nyereséget termeljen a szolgáltatásból. Az alkalmazott szeretne a lehető legkevesebb időt vesztegetni a pénztárral, hogy ne pazarolja az értékes idejét. Hogyan lehet ezt megoldani? Előre fizetni vagy éppen ellenkezőleg, a szolgáltatás után távolról. Vagy a kiskapunál fizetni. Mi a legfontosabb ebből? Hány ember hajlandó bankkártyával fizetni az ebédért? Hány ember bízna meg a kártyaszám tárolásában az ismételt kifizetésekhez ennél az étkezdénél? A terepi kutatás nélkül nem világos, szükség van tesztelésre.
A folyamat minden lépésénél valamilyen módon biztosítani kell a funkcionalitást, ehhez egy személyt kell alapul venni, és kiválasztani, mi fontosabb számára (az a három választható). Végigmentünk a történeten = életképes megoldást hoztunk létre.
Ezután következik a részletezés. Az ügyfél látni akarja a kávézó forgalmát, hogy ne kelljen sorban állnia. Mit akar pontosan?
Megnézni a előrejelzéseket arról, hány ember lesz 15 perc múlva, amikor odaér.
Megnézni a kávézó átlagos kiszolgálási idejét és annak dinamikáját fél órára előre.
Megnézni a helyzetet és a asztalok kihasználtságának dinamikáját.
Mi van, ha a prognosztikai rendszer érthetetlen eredményt ad, vagy leáll?
Nézni a kávézó sorait videón, valamint az asztalok kihasználtságát. Hmm, miért ne ezt csinálnánk először?!
A szerző egy kis gyakorlati feladatra utal: próbálj meg elképzelni, mit csinálsz reggel ébredés után. Egy kártya = egy tevékenység. Egyszerűsítsd a kártyákat (ahelyett, hogy kávét főznél — igyál egy frissítő italt), hogy elhagyd az egyedi részleteket, a megvalósítás módja helyett a célt helyezve fókuszba.
Kinek szól ez a könyv — IT-analitikusoknak és projektmenedzsereknek. Kötelező olvasmány.
Alkalmazások
A tárgyalások és a döntéshozatal hatékonyak 3-5 fős csoportokban.
Írd az első kártyára, hogy mit kell fejleszteni, a másodikra — javítani azt, amit az elsőn írtál, a harmadikra — javítani azt, ami az első és második kártyán van.
Készíts történeteket, mint a tortákat — anélkül, hogy az elkészítési receptet írnád fel, tudd meg, kinek, milyen alkalomra, hány embernek készül a sütemény. Ha a megvalósítást darabokra törjük, akkor ne a piskóta, krém stb. elkészítése mentén, hanem kis, készen kapható torták készítése alapján.
A szoftverfejlesztés hasonló egy film elkészítéséhez, amikor alaposan ki kell dolgozni és csiszolni a forgatókönyvet, megszervezni a színpadot, a színészeket és hasonlókat a forgatás megkezdése előtt.
Mindig lesznek erőforráshiányok.
A befektetett erőfeszítések 20%-a érezhető eredményt ad, 60% nem hoz egyértelmű eredményt, 20% pedig kárt okoz — ezért fontos, hogy a tanulásra összpontosítsunk, és ne csüggedjünk a negatív eredmények esetén.
Közvetlenül kommunikálj a felhasználókkal, próbáld meg átérezni a helyzetüket. Fókuszálj néhány problémára.
A történetek részletezése és kidolgozása a becsléshez — a scrum legunatkozóbb része, tegyétek az értekezleteket álló formába akvárium módban (a táblán 3-4 ember beszél, ha valaki részt szeretne venni, helyettesíti az egyiket).
Forrás: habr.com
