adnotare
Cartea este un algoritm narat pentru desfășurarea procesului de dezvoltare de la idee la implementare folosind tehnici agile. Procesul este structurat în etape și la fiecare pas sunt indicate metodele pentru etapa de proces. Autorul subliniază că majoritatea metodelor nu sunt originale, fără a pretinde că sunt originale. Dar stilul bun de scriere și o oarecare integritate a procesului fac cartea foarte utilă.
O tehnică cheie de mapare a poveștii utilizatorului este structurarea ideilor și a performanțelor pe măsură ce utilizatorul trece prin proces.
În același timp, procesul poate fi descris în moduri diferite. Puteți construi pași pe măsură ce obțineți o valoare cheie sau puteți pur și simplu să vă imaginați ziua de lucru a utilizatorilor pe măsură ce trece prin utilizarea sistemului. Autorul se concentrează pe faptul că procesele trebuie să fie conturate, rostite sub forma unei povești de utilizator pe o hartă a proceselor, ceea ce ne-a dat numele user story map.
Cine are nevoie de ea
Pentru analiști IT și manageri de proiect. O lectura obligatorie. Ușor și plăcut de citit, cartea este de dimensiune medie.
Revizuirea
În forma sa cea mai simplă, așa funcționează.
Un vizitator vine la o cafenea, selectează feluri de mâncare, plasează o comandă, primește mâncare, mănâncă și plătește.
Putem scrie cerințe pentru ceea ce ne dorim de la sistem în fiecare etapă.
Sistemul ar trebui să arate o listă de feluri de mâncare, fiecare fel de mâncare are o compoziție, greutate și preț și să poată adăuga în coș. De ce avem încredere în aceste cerințe? Acest lucru nu este descris în descrierea „standard” a cerințelor și acest lucru creează riscuri.
Interpreții care nu înțeleg de ce este necesar acest lucru fac de obicei un lucru greșit. Interpreții care nu sunt implicați în procesul de creare a unei idei nu sunt implicați în rezultat. Agile spune, să ne concentrăm în primul rând nu pe sistem, ci pe oameni, pe consumatori, pe sarcinile și obiectivele lor.
Creăm personaje, le oferim detalii pentru empatie și începem să spunem povești din partea persoanei.
Angajatul biroului Zakhar a mers la prânz și vrea să ia o gustare rapidă. De ce are nevoie? Ideea este că probabil vrea un prânz de afaceri. O altă idee este că dorește ca sistemul să-și amintească preferințele, pentru că ține dietă. O altă idee. Vrea să i se aducă cafea imediat pentru că este obișnuit să bea cafea înainte de prânz.
Și există și o afacere (un caracter organizațional este un personaj care reprezintă interesele unei organizații). Companiile doresc să mărească cecul mediu, să mărească frecvența achizițiilor și să crească profiturile. Ideea este - să oferim feluri de mâncare neobișnuite din unele bucătării. O altă idee - să introducem micul dejun.
Ideile pot și trebuie să fie concretizate, transformate și prezentate sub forma unei povești de utilizator. În calitate de angajat al Centrului de Afaceri Zakhar, vreau ca sistemul să mă recunoască astfel încât să pot primi un meniu în funcție de preferințele mele. Ca ospatar vreau ca sistemul sa ma anunte cand sa ma apropii de masa pentru ca clientul sa fie multumit de serviciul rapid. Și așa mai departe.
Zeci de povești. Urmează prioritizarea și întârzierea? Jeff subliniază problemele care apar: blocarea în mici detalii și pierderea înțelegerii conceptuale, plus prioritizarea funcționalității creează o imagine zdrențuită din cauza inconsecvenței cu obiectivele.
Calea autorului: Nu acordăm prioritate funcționalității, ci rezultatului = ceea ce primește utilizatorul în final.
Un punct evident neevident: sesiunea de prioritizare nu este realizată de întreaga echipă, pentru că este ineficientă, ci de trei persoane. Primul este responsabil pentru afaceri, al doilea pentru experiența utilizatorului și al treilea pentru implementare.
Să selectăm minimul pentru rezolvarea unei probleme de utilizator (soluție minimă viabilă).
Detaliem ideile prioritare folosind poveștile utilizatorilor, schițele de design, constrângerile și regulile de afaceri pe harta user story, spunând și discutând cu echipa de ce au nevoie oamenii și părțile interesate la fiecare pas al procesului. Lăsăm ideile rămase neexaminate în stocul de oportunități.
Procesul este scris pe carduri de la stânga la dreapta, cu idei pe carduri sub pașii procesului. Este imperativ ca drumul prin întreaga poveste să fie discutat împreună cu membrii echipei pentru a asigura înțelegerea reciprocă.
Elaborarea în acest fel creează integritate în conformitate cu procesele.
Ideile primite trebuie testate. Un non-membru al echipei își îmbracă pălăria persoanei și trăiește ziua persoanei în capul lui, rezolvându-i problema. Este posibil ca el să nu vadă evoluțiile, creând din nou cărți, iar echipa să descopere alternative pentru ea însăși.
Apoi există detalii pentru evaluare. Trei oameni sunt suficienți pentru asta. Responsabil cu experiența utilizatorului, dezvoltator, tester cu o întrebare favorită: „Ce ar fi dacă...”.
În fiecare etapă, discuția urmează o hartă a procesului a istoricului utilizatorului, care permite păstrarea sarcinii utilizatorului în minte pentru a crea o înțelegere coerentă.
Este necesară documentarea în opinia autorului? Da, am nevoie. Dar ca note care vă permit să vă amintiți despre ce ați convenit. Implicarea unui străin din nou necesită discuții.
Autorul nu se adâncește în tema suficienței documentației, concentrându-se pe necesitatea discuției. (Da, este nevoie de documentație, indiferent cum o susțin oamenii care nu au o înțelegere profundă a agile). De asemenea, elaborarea doar unei părți a capabilităților poate duce la necesitatea unei reproiectări complete a întregului sistem. Autorul subliniază riscul elaborării excesive în cazul în care ideea este greșită.
Pentru a elimina riscurile, este necesar să primiți rapid feedback cu privire la produsul creat pentru a minimiza daunele generate de crearea produsului „greșit”. Am realizat o schiță a ideii - am validat-o cu utilizatorul, am schițat prototipuri de interfață - am validat-o cu utilizatorul etc. (Separat, există câteva informații despre cum să validați prototipurile de programe). Obiectivele creării de software, în special în stadiul inițial, sunt învățarea prin primirea de feedback rapid, în consecință, primul produs creat sunt schițele care sunt capabile să demonstreze sau să infirme o ipoteză; (Autoarea se bazează pe munca lui Eric Ries „Startup using Lean methodology”).
O hartă a poveștii ajută la îmbunătățirea comunicării atunci când implementarea este efectuată în mai multe echipe. Ce ar trebui să fie pe hartă? Ce ai nevoie pentru a menține conversația. Nu doar o poveste de utilizator (cine, ce, de ce), ci idei, fapte, schițe de interfață etc...
Împărțind cărțile de pe harta istorică în mai multe linii orizontale, puteți împărți lucrarea în versiuni - evidențiați minimul strict, stratul de funcționalitate crescândă și fundături.
Povestim pe harta procesului.
Un angajat a venit la prânz.
Ce vrea? Viteze de serviciu. Pentru ca prânzul lui îl așteaptă deja pe masă sau măcar pe o tavă. Hopa - un pas ratat: angajatul a vrut să mănânce. S-a autentificat și a selectat opțiunea de prânz de afaceri. A văzut conținutul de calorii și conținutul nutrițional pentru a-l ajuta să țină dietă și să nu se îngrașă. A văzut imagini cu felul de mâncare pentru a decide dacă va mânca sau nu în acel loc.
Apoi, va merge să ia prânzul și cina? Sau poate vor livra prânzul la biroul lui? Apoi, pasul procesului este alegerea unui loc unde să mănânci. Vrea să vadă când îi va fi livrat și cât va costa, astfel încât să poată alege unde să-și petreacă timpul și efortul - coborând sau mergând la muncă. Vrea să vadă cât de aglomerată este cafeneaua ca să nu se împodobească la cozi.
Apoi angajatul a venit la cafenea. Vrea să-și vadă tava ca să o ia și să meargă direct la cină. Cafeneaua vrea să accepte bani pentru a face bani din serviciu. Angajatul doreste sa piarda un minim de timp pe decontari cu cafeneaua, pentru a nu pierde timp pretios inutil. Cum să o facă? Plătiți în avans sau invers după service de la distanță. Sau plătiți pe loc folosind un chioșc. Care este cel mai important lucru la asta? Câți oameni sunt dispuși să plătească pentru prânz cu un card bancar? Câți oameni ar avea încredere în această cantină pentru a-și păstra numărul cardului pentru plăți repetate? Fără cercetare de teren nu este clar, este nevoie de testare.
La fiecare pas al procesului, trebuie să oferiți cumva funcționalitate pentru aceasta trebuie să luați o persoană ca bază și să alegeți ceea ce este mai important pentru el (aceași trei selectori). A urmat povestea până la capăt = a făcut o soluție viabilă.
Urmează detaliile. Clientul vrea să vadă cât de aglomerată este cafeneaua, pentru a nu se zgudui la cozi. Ce vrea mai exact?
Vezi prognoza câți oameni vor fi în 15 minute când va ajunge acolo
Vedeți timpul mediu de serviciu într-o cafenea și dinamica acesteia cu jumătate de oră înainte
Vedeți situația și dinamica ocupării mesei
Ce se întâmplă dacă sistemul de prognoză dă un rezultat neclar sau încetează să funcționeze?
Urmărește prin video cozile din cafenea, precum și ocuparea meselor. Hmm, de ce să nu faci asta mai întâi?!
Autorul subliniază un mic exercițiu de exersat: încearcă să-ți imaginezi ce faci dimineața după trezire. O carte = o acțiune. Măriți cardurile (în loc să măcinați cafeaua, beți o băutură revigorantă) pentru a elimina detaliile individuale, concentrându-vă nu pe metoda de implementare, ci pe obiectiv.
Pentru cine este această carte: analiști IT și manageri de proiect. O lectura obligatorie.
aplicaţii
Discuțiile și luarea deciziilor sunt eficiente în grupuri de 3 până la 5 persoane.
Scrieți pe prima carte ce trebuie dezvoltat, pe a doua - corectați ceea ce ați făcut în prima, pe a treia - corectați ceea ce s-a făcut în prima și a doua.
Pregătește povești ca prăjiturile - nu scriind o rețetă, ci afliind cui, pentru ce ocazie și pentru câți oameni este prăjitura. Dacă descompunem vânzările, atunci nu ar fi în producția de prăjituri, smântână etc., ci în producția de prăjituri mici gata preparate.
Dezvoltarea software este similară cu realizarea unui film, atunci când trebuie să dezvoltați și să lustruiți cu atenție scenariul, să organizați scena, actorii etc. înainte de a începe filmarea.
Întotdeauna va fi o lipsă de resurse.
20% din eforturi produc rezultate tangibile, 60% dau rezultate de neînțeles, 20% dintre eforturi sunt dăunătoare - de aceea este important să ne concentrăm pe învățare și să nu disperați în cazul unui rezultat negativ.
Comunicați direct cu utilizatorul, simțiți-vă în pielea lui. Concentrați-vă pe unele probleme.
Detalierea și dezvoltarea poveștii pentru evaluare este partea cea mai îngrozitoare a scrum-ului, faceți discuțiile în picioare în modul acvariu (3-4 persoane discută la consiliu, dacă cineva dorește să participe, înlocuiește pe cineva).
Sursa: www.habr.com