abstract
Het boek is een verteld algoritme voor het uitvoeren van het ontwikkelingsproces van idee tot implementatie met behulp van agile technieken. Het proces is in stappen uiteengezet en bij elke stap worden de werkwijzen voor de processtap aangegeven. De auteur wijst erop dat de meeste methoden niet origineel zijn, zonder te beweren origineel te zijn. Maar de goede schrijfstijl en enige integriteit van het proces maken het boek erg nuttig.
Een belangrijke techniek bij het in kaart brengen van gebruikersverhalen is het structureren van ideeën en uitvoeringen terwijl de gebruiker door het proces beweegt.
Tegelijkertijd kan het proces op verschillende manieren worden beschreven. U kunt stappen bouwen om een belangrijke waarde te bereiken, of u kunt eenvoudigweg de werkdag van de gebruiker in beeld nemen terwijl deze doorgaat met het gebruik van het systeem. De auteur concentreert zich op het feit dat processen moeten worden geschetst, gesproken in de vorm van een gebruikersverhaal op een proceskaart, wat ons de naam user story map heeft opgeleverd.
Wie heeft het nodig
Voor IT-analisten en projectmanagers. Een aanrader. Makkelijk en plezierig om te lezen, het boek is middelgroot.
terugroepen
In de eenvoudigste vorm werkt het zo.
Een bezoeker komt naar een café, selecteert gerechten, plaatst een bestelling, ontvangt eten, eet en betaalt.
We kunnen in elke fase vereisten schrijven voor wat we van het systeem willen.
Het systeem moet een lijst met gerechten tonen, elk gerecht heeft een samenstelling, gewicht en prijs en kan aan de winkelwagen worden toegevoegd. Waarom hebben wij vertrouwen in deze eisen? Dit staat niet beschreven in de “standaard” omschrijving van eisen en brengt risico’s met zich mee.
Artiesten die niet begrijpen waarom dit nodig is, doen meestal het verkeerde. Performers die niet betrokken zijn bij het proces van het creëren van een idee, zijn niet betrokken bij het resultaat. Agile zegt: laten we ons vooral niet richten op het systeem, maar op mensen, op consumenten, hun taken en doelen.
We creëren persona’s, geven ze details voor empathie en beginnen verhalen te vertellen van de kant van de persona.
Kantoormedewerker Zakhar ging lunchen en wil snel iets eten. Wat heeft hij nodig? Het idee is dat hij waarschijnlijk een zakenlunch wil. Een ander idee is dat hij wil dat het systeem zijn voorkeuren onthoudt, omdat hij op dieet is. Een ander idee. Hij wil dat er meteen koffie wordt gebracht, omdat hij gewend is koffie te drinken voor de lunch.
En er is ook een bedrijf (een organisatiekarakter is een karakter dat de belangen van een organisatie vertegenwoordigt). Bedrijven willen de gemiddelde cheque verhogen, de frequentie van aankopen verhogen en de winst vergroten. Het idee is: laten we ongebruikelijke gerechten uit een bepaalde keuken aanbieden. Nog een idee: laten we het ontbijt introduceren.
Ideeën kunnen en moeten worden geconcretiseerd, getransformeerd en gepresenteerd in de vorm van een gebruikersverhaal. Als medewerker van het Zakhar Business Center wil ik dat het systeem mij herkent, zodat ik een menu kan ontvangen op basis van mijn voorkeuren. Als ober wil ik dat het systeem mij laat weten wanneer ik aan tafel moet komen, zodat de klant tevreden is met een snelle service. Enzovoort.
Tientallen verhalen. Het volgende is prioritering en achterstand? Jeff wijst op de problemen die zich voordoen: verzanden in kleine details en het verliezen van conceptueel begrip, plus het stellen van prioriteit aan functionaliteit zorgt voor een rommelig beeld als gevolg van inconsistentie met de doelstellingen.
Het pad van de auteur: We geven geen prioriteit aan de functionaliteit, maar aan het resultaat = wat de gebruiker uiteindelijk krijgt.
Een voor de hand liggend, niet voor de hand liggend punt: de prioriteringssessie wordt niet door het hele team uitgevoerd, omdat deze niet effectief is, maar door drie personen. De eerste is verantwoordelijk voor de bedrijfsvoering, de tweede voor de gebruikerservaring en de derde voor de implementatie.
Laten we het minimum selecteren voor het oplossen van één gebruikersprobleem (minimaal haalbare oplossing).
We detailleren de eerste prioriteitsideeën met behulp van gebruikersverhalen, ontwerpschetsen, beperkingen en bedrijfsregels op de gebruikersverhaalkaart door met het team te vertellen en te bespreken wat mensen en belanghebbenden nodig hebben bij elke stap van het proces. De overige ideeën laten we ononderzocht in de backlog van kansen.
Het proces staat van links naar rechts op kaartjes geschreven, met ideeën op kaartjes onder de processtappen. Het is absoluut noodzakelijk dat het traject door het hele verhaal samen met de teamleden wordt besproken om wederzijds begrip te garanderen.
Door op deze manier uit te werken ontstaat integriteit in de naleving van processen.
De ontvangen ideeën moeten worden getest. Een niet-teamlid zet de hoed van de persoon op en leeft de dag van de persoon in zijn hoofd, terwijl hij zijn probleem oplost. Het kan zijn dat hij de ontwikkelingen niet ziet, opnieuw kaarten maakt en het team zelf alternatieven ontdekt.
Dan is er detaillering voor evaluatie. Hiervoor zijn drie personen voldoende. Verantwoordelijk voor gebruikerservaring, ontwikkelaar, tester met een favoriete vraag: “Wat als...”.
In elke fase volgt de discussie een proceskaart van de geschiedenis van de gebruiker, waardoor de taak van de gebruiker in gedachten kan worden gehouden om een samenhangend begrip te creëren.
Is documentatie noodzakelijk naar de mening van de auteur? Ja ik heb het nodig. Maar als aantekeningen waarmee je kunt onthouden wat je hebt afgesproken. Opnieuw een buitenstaander erbij betrekken vergt discussie.
De auteur verdiept zich niet in het onderwerp van de toereikendheid van de documentatie, maar concentreert zich op de noodzaak van discussie. (Ja, documentatie is nodig, ongeacht hoe mensen die geen diep begrip van agile hebben dit beweren). Ook kan het uitwerken van slechts een deel van de mogelijkheden leiden tot de noodzaak van een volledige herwerking van het gehele systeem. De auteur wijst op het risico van overmatige uitwerking in het geval dat het idee verkeerd is.
Om risico's te elimineren, is het noodzakelijk om snel feedback te krijgen over het product dat wordt gemaakt om de schade als gevolg van het maken van het "verkeerde" product te minimaliseren. We maakten een schets van een idee - valideerden het met de gebruiker, schetsten interface-prototypes - valideerden het met de gebruiker, enz. (Afzonderlijk is er wat informatie over het valideren van programmaprototypes). Het doel van het maken van software, vooral in de beginfase, is leren door het ontvangen van snelle feedback; dienovereenkomstig bestaat het eerste product uit schetsen die een hypothese kunnen bewijzen of weerleggen. (De auteur baseert zich op het werk van Eric Ries “Startup met behulp van de Lean-methodologie”).
Een storymap helpt de communicatie te verbeteren wanneer de implementatie door meerdere teams wordt uitgevoerd. Wat moet er op de kaart staan? Wat je nodig hebt om het gesprek gaande te houden. Niet alleen een gebruikersverhaal (wie, wat, waarom), maar ideeën, feiten, interfaceschetsen, enz...
Door de kaarten op de geschiedeniskaart in verschillende horizontale lijnen te verdelen, kun je het werk in releases verdelen - markeer het absolute minimum, een laag met toenemende functionaliteit en strikken.
Wij vertellen verhalen op de proceskaart.
Er kwam een medewerker lunchen.
Wat wilt hij? Servicesnelheden. Zodat zijn lunch al op tafel of in ieder geval op een dienblad op hem wacht. Oeps - een gemiste stap: de medewerker wilde eten. Hij logde in en selecteerde de optie zakenlunch. Hij zag het caloriegehalte en de voedingswaarde om hem te helpen een dieet te volgen en niet aan te komen. Hij zag foto's van het gerecht om te beslissen of hij op die plek zou eten of niet.
Zal hij vervolgens lunch en diner gaan halen? Of wordt de lunch misschien op zijn kantoor bezorgd? Vervolgens is de stap van het proces het kiezen van een plek om te eten. Hij wil zien wanneer het bij hem wordt afgeleverd en hoeveel het gaat kosten, zodat hij kan kiezen waar hij zijn tijd en energie aan wil besteden: naar beneden gaan of naar zijn werk gaan. Hij wil zien hoe druk het café is, zodat er geen wachtrijen ontstaan.
Vervolgens kwam de medewerker naar het café. Hij wil zijn dienblad zien, zodat hij het kan pakken en meteen kan gaan eten. Het café wil geld accepteren om geld te verdienen aan de bediening. De werknemer wil zo min mogelijk tijd verliezen aan schikkingen met het café, om geen kostbare tijd nutteloos te verspillen. Hoe je dat doet? Betaal vooraf of andersom na service op afstand. Of betaal ter plaatse via een kiosk. Wat is het belangrijkste hieraan? Hoeveel mensen zijn bereid om met een bankkaart voor de lunch te betalen? Hoeveel mensen zouden deze kantine vertrouwen om hun kaartnummer op te slaan voor herhaalde betalingen? Zonder veldonderzoek is het onduidelijk, testen is nodig.
Bij elke stap van het proces moet je op de een of andere manier functionaliteit bieden, hiervoor moet je iemand als basis nemen en kiezen wat voor hem belangrijker is (dezelfde drie selectors). Het verhaal tot het einde gevolgd = een haalbare oplossing gemaakt.
Vervolgens komt de detaillering. De klant wil zien hoe druk het café is, om niet in de rij te staan. Wat wil hij precies?
Bekijk de voorspelling van hoeveel mensen er over 15 minuten zullen zijn als hij daar aankomt
Bekijk een half uur van tevoren de gemiddelde bedieningstijd in een café en de dynamiek ervan
Bekijk de situatie en de dynamiek van de tafelbezetting
Wat als het voorspellingssysteem een onduidelijk resultaat geeft of niet meer werkt?
Bekijk via video de wachtrijen in het café, evenals de bezetting van tafels. Hmm, waarom doe je dat niet eerst?!
De auteur wijst op een kleine oefening om te oefenen: probeer je voor te stellen wat je 's ochtends doet nadat je wakker bent geworden. Eén kaart = één actie. Vergroot de kaarten (in plaats van koffie te malen, drink een verkwikkend drankje) om individuele details te verwijderen, waarbij de nadruk niet ligt op de wijze van implementatie, maar op het doel.
Voor wie is dit boek bedoeld: IT-analisten en projectmanagers. Een aanrader.
Apps
Discussie en besluitvorming zijn effectief in groepen van 3 tot 5 personen.
Schrijf op de eerste kaart wat er moet worden ontwikkeld, op de tweede - corrigeer wat je in de eerste hebt gedaan, op de derde - corrigeer wat er in de eerste en tweede is gedaan.
Bereid verhalen voor zoals taarten. Niet door een recept uit te schrijven, maar door uit te zoeken voor wie, voor welke gelegenheid en voor hoeveel personen de taart is. Als we de omzet uitsplitsen, zou het niet gaan om de productie van taarten, room, enz., maar om de productie van kleine, kant-en-klare taarten.
Softwareontwikkeling is vergelijkbaar met het maken van een film, waarbij je het script zorgvuldig moet ontwikkelen en bijschaven, de scène, acteurs, enz. moet organiseren voordat het filmen begint.
Er zal altijd een tekort aan grondstoffen zijn.
20% van de inspanningen levert tastbare resultaten op, 60% levert onbegrijpelijke resultaten op, 20% van de inspanningen is schadelijk - daarom is het belangrijk om je te concentreren op het leren en niet te wanhopen in geval van een negatief resultaat.
Communiceer rechtstreeks met de gebruiker, voel jezelf in zijn schoenen. Concentreer u op enkele problemen.
Het detailleren en ontwikkelen van het verhaal voor evaluatie is het meest saaie onderdeel van scrum, zorg ervoor dat de discussies stand-up zijn in de aquariummodus (3-4 mensen discussiëren op het bord, als iemand wil meedoen, vervangt hij iemand).
Bron: www.habr.com