Patton Jeff. Gebruikersverhalen. De kunst van agile softwareontwikkeling.

Samenvatting

Het boek is een uiteenzetting van het algoritme voor het ontwikkelingsproces van idee tot implementatie met behulp van agile technieken. Het proces wordt stap voor stap uiteengezet en voor elke stap worden de methoden aangegeven die bij die stap horen. De auteur legt uit dat de meeste methoden niet origineel zijn en niet pretenderen origineel te zijn. Maar de goede schrijfstijl en de enige samenhang in het proces maken het boek zeer nuttig.

De sleuteltechniek van de gebruikersverhalenkaart is het structureren van ideeën en taken gedurende de loop van het proces vanuit het perspectief van de gebruiker.

Het doorlopen van het proces kan op verschillende manieren worden gepresenteerd. Je kunt de stappen rangschikken op basis van het bereiken van de belangrijkste waarde, of je kunt eenvoudig de werkdag van gebruikers presenteren, zoals deze verloopt met behulp van het systeem. De auteur richt zich op het feit dat processen gepresenteerd en verteld moeten worden in de vorm van een gebruikersverhaal op de proceskaart, wat het de naam gebruikersverhalenkaart heeft gegeven.

Voor wie is dit nuttig

Voor IT-analisten en projectmanagers. Absoluut, een aanrader. Het leest gemakkelijk en prettig, het boek is gemiddeld van formaat.

Review

In de eenvoudigste vorm, hoe dit werkt.

Een bezoeker komt in een café, kiest gerechten, plaatst een bestelling, ontvangt eten, eet en betaalt.

Je kunt eisen opschrijven over wat we van het systeem willen in elke fase.

Het systeem moet een lijst van gerechten tonen, met ingrediënten, gewicht en prijs en de mogelijkheid bieden om iets aan de winkelwagentje toe te voegen. Waarom zijn we zeker van deze eisen? In de 'standaard' beschrijving van eisen wordt dit niet beschreven en dat genereert risico's.

Uitvoerders die niet begrijpen waarom dit nodig is, doen meestal niet wat nodig is. Uitvoerders die niet betrokken zijn bij het proces van ideecreatie, zijn ook niet betrokken bij het resultaat. Agile zegt, laten we ons vooral niet op het systeem concentreren, maar op de mensen, de consumenten, hun taken en doelen.

We creëren persona's, geven ze details voor empathie en beginnen vanuit de persona's verhalen te vertellen.

Kantoormedewerker Zachar ging lunchen en wil snel een hapje eten. Wat heeft hij nodig? Het idee is dat hij waarschijnlijk een zakelijke lunch wil. Een ander idee is dat hij wil dat het systeem zijn voorkeuren herinnert, omdat hij op dieet is. Nog een idee: hij wil dat hij meteen koffie krijgt, omdat hij gewend is koffie te drinken voor de lunch.

Er is ook een bedrijf (organisatiepersoon — een personage dat de belangen van een organisatie vertegenwoordigt). Het bedrijf wil de gemiddelde besteding verhogen, de aankoopfrequentie vergroten en de winst verhogen. Het idee is — laten we ongebruikelijke gerechten uit een bepaalde keuken aanbieden. Een ander idee — laten we ontbijt introduceren.

Ideeën kunnen en moeten ge concretiseerd, omgevormd en gepresenteerd worden in de vorm van user stories. Als medewerker van een businesscentrum wil ik dat het systeem mij herkent, zodat ik het menu krijg dat rekening houdt met mijn voorkeuren. Als ober wil ik dat het systeem me waarschuwt wanneer ik naar de tafel moet gaan, zodat de klant tevreden is met de snelle service. Enzovoorts.

Tientallen verhalen. En wat nu met prioritering en backlog? Jeff wijst op de opkomende problemen: vastlopen in detail en het verlies van conceptueel begrip, plus de prioritering van functionaliteit creëert een onsamenhangend beeld vanwege inconsistentie met de doelen.

De weg van de auteur: We prioriteren niet de functionaliteit, maar het resultaat = wat de gebruiker uiteindelijk ontvangt.

Een voor de hand liggend maar niet voor de hand liggend punt: de prioriteringssessie wordt niet door het hele team gedaan, want dat is niet effectief, maar door drie mensen. De eerste is verantwoordelijk voor het bedrijfsleven, de tweede voor de gebruikerservaring en de derde voor de implementatie.

Laten we het minimum definiëren voor het oplossen van één gebruikerstaak (minimaal levensvatbare oplossing).

We detailleren ideeën van de eerste prioriteit met behulp van user stories, schetsen van ontwerpen, beperkingen en bedrijfsregels op de kaart met gebruikersverhalen door samen met het team te vertellen en te bespreken wat nodig is voor de personages en stakeholders in elke stap van het proces. De overige ideeën laten we onverklaard in de backlog met mogelijkheden.

Het proces wordt geschreven in de vorm van kaarten van links naar rechts, en ideeën op de kaarten onder de stappen van het proces. Het is essentieel dat de hele geschiedenis samen met de teamleden wordt besproken om wederzijds begrip te creëren.

Deze manier van werken creëert samenhang tussen processen.

De gegenereerde ideeën moeten getest worden. Een teamlid draagt de hoed van de persoon en leeft een dag in het hoofd van de persoon, terwijl hij zijn taak oplost. Het is mogelijk dat hij de voorbereidende werkzaamheden niet ziet, waardoor hij kaarten opnieuw aanmaakt, terwijl het team alternatieven ontdekt.

Vervolgens vindt er een detaillering plaats voor de beoordeling. Hiervoor zijn drie personen voldoende. Verantwoordelijk voor de gebruikerservaring, ontwikkelaar, tester met de favoriete vraag: “En wat als…”.

In elke fase gaat de discussie over de proceskaart van de gebruikersgeschiedenis, wat helpt om de gebruikersbehoefte in gedachten te houden en een samenhangend begrip te creëren.

Is documentatie nodig volgens de auteur? Ja, dat is het. Maar als aantekeningen die helpen herinneren waarover is afgesproken. De betrokkenheid van iemand van buitenaf vereist opnieuw discussie.

De auteur gaat niet diep in op de voldoende documentatie, maar legt de nadruk op de noodzaak van discussies. (Ja, documentatie is nodig, hoezeer mensen die niet diep in agile zijn ook beweren). Ook kan het uitwerken van slechts een deel van de mogelijkheden leiden tot de noodzaak om het hele systeem opnieuw te ontwerpen. De auteur wijst op het risico van overmatige uitwerking als de ideeën niet kloppen.

Om risico's te verminderen, is het nodig om snel feedback te krijgen over het product dat wordt ontwikkeld om de schade van het creëren van een “onjuist” product te minimaliseren. We hebben een schets van een idee gemaakt — gevalideerd bij de gebruiker, schetsen van interfaceprototypes — gevalideerd bij de gebruiker, enzovoorts. (Er wordt apart vermeld hoe prototypes van programma’s te valideren). De doelen van softwareontwikkeling, vooral in de beginfase — leren door snelle feedback te krijgen; de eerste geproduceerde producten zijn schetsen die in staat zijn om een hypothese te bewijzen of te weerleggen. (De auteur baseert zich op het werk van Eric Ries “The Lean Startup”).

De kaart van verhalen helpt de communicatie te verbeteren als de uitvoering door verschillende teams wordt verzorgd. Wat moet er op de kaart staan? Wat nodig is om het gesprek te ondersteunen. Niet alleen user stories (wie, wat, waarom), maar ook ideeën, feiten, schetsen van interfaces, enzovoorts…

Door de kaarten op de verhalenkaart in meerdere horizontale lijnen te splitsen, kunnen de werkzaamheden in releases worden verdeeld — het minimum выделen, een laag voor extra functionaliteit en strikken.

We bespreken de verhalen op de proceskaart.

De medewerker is aangekomen voor de lunch.

Wat wil hij? Snelheid van service. Hij wil dat zijn lunch al op tafel of tenminste op een dienblad wacht. Oeps — gemiste stap: de medewerker wilde iets eten. Hij logde in het systeem en koos een optie voor de zakelijke lunch. Hij zag de caloriewaarde en de bijbehorende voedingswaarde om aan zijn dieet te voldoen en niet aan te komen. Hij zag foto's van de gerechten om te beslissen of hij op deze plaats wilde eten of niet.

Gaat hij daarna de lunch halen en lunchen? Of misschien wordt de lunch naar zijn kantoor bezorgd? Dan is de volgende stap in het proces de keuze van de eetlocatie. Hij wil weten wanneer het wordt bezorgd en hoeveel het gaat kosten, zodat hij kan kiezen waar hij zijn tijd en energie aan wil besteden — naar beneden gaan of werken. Hij wil de drukte van het café zien, zodat hij niet in de rij hoeft te staan.

Vervolgens kwam de medewerker in het café. Hij wil zijn dienblad zien, zodat hij het kan pakken en meteen kan gaan lunchen. Het café wil geld verdienen door service te bieden. De medewerker wil zo min mogelijk tijd verspillen aan betalingen bij het café, zodat hij zijn waardevolle tijd niet nutteloos verliest. Hoe doe je dat? Van tevoren betalen of juist na de service op afstand? Of betaling op het moment zelf via een kiosk. Wat is hierin het belangrijkste? Hoeveel mensen zijn bereid om hun lunch met een bankkaart te betalen? Hoeveel mensen vertrouwen het bewaren van hun kaartnummer voor herhaalde betalingen aan deze cafetaria toe? Zonder veldonderzoek is het onduidelijk, testen is nodig.

Bij elke stap van het proces moet je op de een of andere manier de functionaliteit waarborgen, hiervoor moet je een bepaald persona als basis nemen en kiezen wat voor hem het belangrijkste is (diezelfde selectie van drie). De geschiedenis tot het einde doorlopen = een levensvatbare oplossing gemaakt.

Daarna komt de detaillering. De klant wil de drukte van het café zien, zodat hij niet in de rij hoeft te staan. Wat wil hij precies?

Kijk naar de voorspelling van hoeveel mensen er over 15 minuten zullen zijn als hij daar aankomt.

Bekijk de gemiddelde wachttijd in het café en de dynamiek daarvan voor een half uur vooruit.

Bekijk de situatie en de dynamiek van de bezetting van de tafels.

En wat als het voorspellingssysteem een onduidelijk resultaat geeft of stopt met werken?

Kijk via video naar de rijen in het café en de bezetting van de tafels. Hmm, waarom zou je dit niet als eerste doen?!

De auteur wijst op een kleine oefening om de praktijk te oefenen: probeer je voor te stellen wat je 's ochtends doet na het wakker worden. Eén kaart = één actie. Vergrijp de kaarten (in plaats van koffie malen — drink een verkwikkende drank) om individuele details te verwijderen, en richt je op het doel in plaats van de uitvoeringsmethode.

Voor wie is dit boek — voor IT-analisten en projectmanagers. Een aanrader om te lezen.

Applicaties

Discussie en besluitvorming zijn efficiënt in groepen van 3 tot 5 personen.

Schrijf op de eerste kaart wat ontwikkeld moet worden, op de tweede — wat gecorrigeerd moet worden van de eerste, op de derde — wat gecorrigeerd moet worden van de eerste en tweede.

Bereid verhalen voor als taarten — schrijf het recept niet uit, maar ontdek voor wie, bij welke gelegenheid en voor hoeveel personen de taart is. Als je de uitvoering opsplitst, doe dat dan niet in het maken van lagen, room, enz., maar in het maken van kleine kant-en-klare taarten.

Softwareontwikkeling lijkt op het maken van een film, waarbij je het script zorgvuldig moet ontwikkelen en verfijnen, de scène, acteurs en zo verder moet organiseren voordat de opnames beginnen.

Er zullen altijd niet genoeg middelen zijn.

20% van de inspanningen levert een merkbaar resultaat, 60% levert onduidelijke uitkomsten op, 20% van de inspanningen zijn schadelijk — daarom is het belangrijk om te focussen op leren en niet wanhopig te worden bij negatieve resultaten.

Communiceer direct met de gebruiker, voel je in zijn positie. Focust je op bepaalde problemen.

Detailering en uitwerking van een verhaal voor evaluatie is het meest tijdrovende deel van scrum, maak de discussies staand en in aquariummodus (bij het bord discussiëren 3-4 mensen, als iemand wil deelnemen, vervangt hij iemand).

Bron: habr.com