Abstract
D'Buch ass e narréierten Algorithmus fir den Entwécklungsprozess vun Iddi bis Implementatioun mat agile Techniken auszeféieren. De Prozess ass a Schrëtt ausgeluecht an op all Schrëtt sinn d'Methoden fir de Prozess Schrëtt uginn. Den Auteur weist drop hin, datt déi meescht Methoden net originell sinn, ouni ze behaapten, datt se originell sinn. Awer de gudde Schreifstil an eng gewëssen Integritéit vum Prozess maachen d'Buch ganz nëtzlech.
Eng Schlësseltechnik vun der User Story Mapping ass Iddien a Performancen ze strukturéieren wéi de Benotzer duerch de Prozess beweegt.
Zur selwechter Zäit kann de Prozess op verschidde Weeër beschriwwe ginn. Dir kënnt Schrëtt bauen wéi Dir e Schlësselwäert erreecht, oder Dir kënnt einfach den Aarbechtsdag vun de Benotzer huelen a virstellen wéi et duerch de System geet. Den Auteur konzentréiert sech op d'Tatsaach datt d'Prozesser musse skizzéiert ginn, geschwat a Form vun enger Benotzergeschicht op enger Prozesskaart, dat ass wat eis den Numm Benotzergeschichtkaart ginn huet.
Wien brauch et
Fir IT Analysten a Projektmanager. A muss liesen. Einfach an agreabel ze liesen, d'Buch ass mëttelgrouss.
Feedback
A senger einfachster Form ass dëst wéi et funktionnéiert.
E Besucher kënnt an e Café, wielt Platen, mécht eng Bestellung, kritt Iessen, ësst a bezuelt.
Mir kënnen Ufuerderunge schreiwen fir wat mir aus dem System an all Etapp wëllen.
De System soll eng Lëscht vu Platen weisen, all Plat huet eng Zesummesetzung, Gewiicht a Präis a kënnen an de Weenchen addéieren. Firwat si mir zouversiichtlech an dës Ufuerderungen? Dëst ass net an der "Standard" Beschreiwung vun Ufuerderunge beschriwwen an dëst schaaft Risiken.
Kënschtler, déi net verstinn firwat dat néideg ass, maachen normalerweis déi falsch Saach. Performeren, déi net am Prozess vun der Iddi schafen, sinn net am Resultat involvéiert. Agile seet, loosst eis haaptsächlech net op de System konzentréieren, mee op d'Leit, op Konsumenten, hir Aufgaben an Ziler.
Mir kreéieren Personas, ginn hinnen Detailer fir Empathie, a fänken un Geschichte vun der Säit vun der Persona ze erzielen.
Office Employé Zakhar goung Mëttegiessen a wëll e séiere Snack iessen. Wat brauch hien? D'Iddi ass datt hien wahrscheinlech e Business Mëttegiessen wëll. Eng aner Iddi ass datt hie wëll datt de System seng Virléiften erënnert, well hien op enger Diät ass. Eng aner Iddi. Hie wëll de Kaffi direkt bei him bruecht ginn, well hien ass gewinnt Kaffi virum Mëttegiessen ze drénken.
An et gëtt och e Geschäft (en organisatoresche Charakter ass e Charakter deen d'Interesse vun enger Organisatioun representéiert). D'Geschäfter wëllen den Duerchschnëttscheck erhéijen, d'Frequenz vun den Akeef erhéijen an de Gewënn erhéijen. D'Iddi ass - loosst eis ongewéinlech Platen vun enger Kichen ubidden. Eng aner Iddi - loosst eis Kaffi virstellen.
Iddie kënnen a sollen a Form vun enger Usergeschicht konkretiséiert, transforméiert a presentéiert ginn. Als Employé vum Zakhar Business Center wëll ech datt de System mech erkennt, fir datt ech e Menü op Basis vu menge Virléiften kréien. Als Kelner wëll ech datt de System mech matdeelt wann ech op den Dësch kommen, fir datt de Client mam schnelle Service zefridden ass. A sou weider.
Dosende vu Geschichten. Als nächst ass Prioritéit a Réckstand? De Jeff weist op d'Problemer déi entstinn: sech a klengen Detailer verstoppen a konzeptuellen Verständnis verléieren, plus Prioritéite vun der Funktionalitéit schaaft e ragged Bild wéinst Inkonsistenz mat Ziler.
De Wee vum Auteur: Mir prioritär net d'Funktionalitéit, mee d'Resultat = wat de Benotzer um Enn kritt.
En offensichtlechen net offensichtleche Punkt: d'Prioritéitssitzung gëtt net vun der ganzer Equipe duerchgefouert, well se net effikass ass, mä vun dräi Leit. Déi éischt ass verantwortlech fir d'Geschäft, déi zweet fir d'Benotzererfarung an déi drëtt fir d'Ëmsetzung.
Loosst eis de Minimum auswielen fir ee Benotzerproblem ze léisen (minimum viabel Léisung).
Mir detailléieren déi éischt Prioritéit Iddien mat Benotzergeschichten, Design Skizzen, Aschränkungen a Geschäftsregelen op der Benotzergeschichtkaart andeems mir mat der Equipe erzielen an diskutéieren wat d'Leit an d'Akteuren bei all Schrëtt vum Prozess brauchen. Mir loossen déi reschtlech Iddien net ënnersicht am Réckstand vun de Méiglechkeeten.
De Prozess ass op Kaarte vu lénks op riets geschriwwen, mat Iddien op Kaarten ënnert de Prozess Schrëtt. Et ass néideg datt de Wee duerch d'ganz Geschicht zesumme mat den Teammemberen diskutéiert gëtt fir géigesäitege Verständnis ze garantéieren.
Ausschaffung op dës Manéier schaaft Integritéit am Aklang mat Prozesser.
D'Iddien, déi kritt ginn, musse getest ginn. En Net-Team-Member huet der Persoun säin Hutt op a lieft den Dag vun der Persoun a sengem Kapp a léist säi Problem. Et ass méiglech datt hien d'Entwécklungen net gesäit, erstellt Kaarten erëm, an d'Team entdeckt Alternativen fir sech.
Da gëtt et Detailer fir Evaluatioun. Dräi Leit si genuch dofir. Verantwortlech fir Benotzererfarung, Entwéckler, Tester mat enger Liiblingsfro: "Wat wann ...".
Op all Etapp follegt d'Diskussioun eng Prozesskaart vun der Geschicht vum Benotzer, wat et erlaabt dem Benotzer seng Aufgab am Kapp ze halen fir e kohärent Verständnis ze kreéieren.
Ass Dokumentatioun néideg der Meenung vum Auteur? Jo, ech brauch et. Awer als Notizen déi Iech erlaben ze erënneren wat Dir ausgemaach hutt. En Auslänner matzemaachen erfuerdert erëm Diskussioun.
Den Auteur verdreift net an d'Thema vun der Genuch vun der Dokumentatioun, konzentréiert sech op d'Bedierfnes fir Diskussioun. (Jo, Dokumentatioun ass néideg, egal wéi Leit, déi net en déiwe Verständnis vun Agile hunn, et behaapten). Och d'Ausschaffe vun nëmmen en Deel vun de Fähigkeiten kann zu der Bedierfnes fir eng komplett Neiaarbecht vum ganze System féieren. Den Auteur weist op de Risiko vun exzessive Ausbau am Fall wou d'Iddi falsch ass.
Fir Risiken ze eliminéieren, ass et néideg séier Feedback iwwert d'Produkt ze kreéieren, fir de Schued vum "falsche" Produkt ze minimiséieren. Mir hunn eng Skizz vun der Iddi gemaach - et mam Benotzer validéiert, Interface Prototypen skizzéiert - et mam Benotzer validéiert, asw. (Separat gëtt et e bëssen Informatioun iwwer wéi ee Programmprototypen validéiert). D'Ziler fir Software ze kreéieren, besonnesch an der éischter Etapp, si léieren duerch séier Feedback ze kréien; deementspriechend ass dat éischt Produkt erstallt Skizzen déi fäeg sinn eng Hypothese ze beweisen oder ze widderhuelen. (Den Auteur hänkt op d'Aarbecht vum Eric Ries "Startup mat Lean Methodologie").
Eng Geschichtskaart hëlleft d'Kommunikatioun ze verbesseren wann d'Implementatioun iwwer verschidde Teams duerchgefouert gëtt. Wat soll op der Kaart sinn? Wat Dir braucht fir d'Gespréich weider ze halen. Net nëmmen eng Benotzergeschicht (wien, wat, firwat), mee Iddien, Fakten, Interface Skizzen, etc ...
Andeems Dir d'Kaarten op der Geschichtskaart an e puer horizontale Linnen opdeelt, kënnt Dir d'Aarbecht a Verëffentlechungen opdeelen - Highlight dee Minimum, eng Schicht vun der Erhéijung vun der Funktionalitéit a Béi.
Mir erzielen Geschichten op der Prozesskaart.
En Employé koum fir Mëttegiessen.
Wat wëll hien? Service Vitesse. Sou datt säi Mëttegiessen schonn um Dësch oder op d'mannst op engem Schacht op hien waart. Oops - e verpasste Schrëtt: den Employé wollt iessen. Hien huet sech ugemellt an huet d'Geschäftslunch Optioun gewielt. Hien huet de Kaloriegehalt an den Ernärungsgehalt gesinn fir him Diät ze hëllefen an net Gewiicht ze gewannen. Hien huet Biller vum Plat gesinn fir ze entscheeden ob hien op där Plaz iessen oder net.
Als nächst wäert hien Mëttegiessen an Owesiessen kréien? Oder vläicht gëtt de Mëttegiessen op säi Büro geliwwert? Dann ass de Schrëtt vum Prozess d'Auswiel vun enger Plaz fir ze iessen. Hie wëll kucken wéini et him geliwwert gëtt a wéi vill et wäert kaschten, sou datt hie ka wielen wou hien seng Zäit an Energie verbréngt - erof goen oder op d'Aarbecht goen. Hie wëll kucken, wéi beschäftegt de Café ass, fir net an de Schlaangen ze stoen.
Dunn ass den Employé an de Café komm. Hie wëll säi Schacht gesinn, fir datt hien et kann huelen an direkt zum Iessen goen. De Café wëll Sue akzeptéieren fir Suen op Service ze maachen. Den Employé wëll e Minimum vun Zäit op Siidlungen mam Café verléieren, fir net wäertvoll Zäit nëtzlos ze verschwenden. Wéi maachen et? Bezuelt am Viraus oder vice versa nom Service op afstand. Oder bezuelt op der Plaz mat engem Kiosk. Wat ass dat wichtegst iwwer dëst? Wéi vill Leit si bereet fir Mëttegiessen mat enger Bankkaart ze bezuelen? Wéi vill Leit géifen dës Kantine vertrauen fir hir Kaartnummer ze späicheren fir widderhuelend Bezuelungen? Ouni Feldfuerschung ass et onkloer, Tester sinn néideg.
Op all Schrëtt vum Prozess musst Dir iergendwéi Funktionalitéit ubidden, dofir musst Dir eng Persoun als Basis huelen a wielt wat him méi wichteg ass (déi selwecht dräi Selektoren). D'Geschicht bis zum Schluss gefollegt = eng viabel Léisung gemaach.
Als nächst kënnt d'Detailer. De Client wëll gesinn, wéi beschäftegt de Café ass, fir net an de Schlaangen ze stoen. Wat genee wëll hien?
Kuckt d'Prognose wéi vill Leit et a 15 Minutten wäerte sinn wann hien do kënnt
Kuckt déi duerchschnëttlech Servicezäit an engem Café a seng Dynamik eng hallef Stonn am Viraus
Gesinn d'Situatioun an Dësch Besetzung Dynamik
Wat wann de Prognosesystem en onkloer Resultat gëtt oder ophält ze schaffen?
Kuckt duerch Video d'Schlaangen am Café, wéi och d'Besetzung vun den Dëscher. Hmm, firwat net dat éischt maachen?!
Den Auteur weist op eng kleng Übung fir ze üben: probéiert Iech virzestellen, wat Dir moies nom Erwächen maacht. Eng Kaart = eng Aktioun. Vergréisseren d'Kaarte (amplaz Kaffi ze schleifen, drénken en erfrëschende Getränk) fir eenzel Detailer ze läschen, net op d'Method vun der Ëmsetzung ze fokusséieren, mee op d'Zil.
Fir wien ass dëst Buch: IT Analysten a Projektmanager. A muss liesen.
Apps
Diskussioun an Entscheedungsprozess sinn effektiv a Gruppen vun 3 bis 5 Leit.
Schreift op der éischter Kaart wat muss entwéckelt ginn, op der zweeter - korrekt wat Dir an der éischter gemaach hutt, op der drëtter - korrigéiert wat an der éischter an zweeter gemaach gouf.
Bereet Geschichten wéi Kuch vir - net andeems Dir e Rezept schreift, mee duerch erauszefannen wien, fir wéi eng Occasioun a wéivill Leit de Kuch ass. Wa mir de Verkaf ofbriechen, da wier et net an d'Produktioun vu Kuchen, Crème, asw., mee an d'Produktioun vu klenge fäerdege Kuchen.
Softwareentwécklung ass ähnlech wéi e Film ze maachen, wann Dir de Skript suergfälteg entwéckelen a poléieren musst, d'Szen organiséieren, Akteuren, asw., ier Dir ufänkt ze filmen.
Et wäert ëmmer e Mangel u Ressourcen sinn.
20% vun den Efforten produzéiere konkret Resultater, 60% ginn onverständlech Resultater, 20% vun Efforte si schiedlech - dofir ass et wichteg sech op d'Léieren ze konzentréieren an net ze verzweifelen am Fall vun engem negativen Resultat.
Kommunizéiere direkt mam Benotzer, fillt Iech a senge Schong. Konzentréieren op e puer Problemer.
Detailléieren an Entwécklung vun der Geschicht fir d'Evaluatioun ass dee schrecklechsten Deel vum Scrum, maacht d'Diskussiounen am Aquariummodus stand-up (3-4 Leit diskutéieren um Verwaltungsrot, wann een wëll matmaachen, ersetzt een).
Source: will.com