abstrakti
Kirja on kerrottu algoritmi kehitysprosessin toteuttamiseksi ideasta toteutukseen ketterillä tekniikoilla. Prosessi on laadittu vaiheittain ja jokaisessa vaiheessa on osoitettu prosessivaiheen menetelmät. Kirjoittaja huomauttaa, että useimmat menetelmät eivät ole alkuperäisiä väittämättä olevansa alkuperäisiä. Mutta hyvä kirjoitustyyli ja prosessin rehellisyys tekevät kirjasta erittäin hyödyllisen.
Keskeinen tekniikka käyttäjien tarinakartoinnissa on ideoiden ja esityksiä jäsentää, kun käyttäjä liikkuu prosessin läpi.
Samalla prosessia voidaan kuvata eri tavoin. Voit rakentaa askeleita, kun saavutat avainarvon, tai voit yksinkertaisesti ottaa ja kuvitella käyttäjien työpäivän järjestelmän käytössä. Kirjoittaja keskittyy siihen, että prosesseja pitää hahmotella, puhua käyttäjätarinana prosessikartalla, josta saimme nimen user story map.
Kuka sitä tarvitsee
IT-analyytikoille ja projektipäälliköille. Pakollinen luettava. Helppo ja miellyttävä lukea, kirja on keskikokoinen.
Arvostelu
Yksinkertaisimmassa muodossaan se toimii näin.
Vierailija tulee kahvilaan, valitsee ruokia, tekee tilauksen, vastaanottaa ruokaa, syö ja maksaa.
Voimme kirjoittaa vaatimuksia sille, mitä haluamme järjestelmältä kussakin vaiheessa.
Järjestelmän tulee näyttää ruokalista, jokaisella ruoalla on koostumus, paino ja hinta, ja ne on voitava lisätä ostoskoriin. Miksi luotamme näihin vaatimuksiin? Tätä ei ole kuvattu "standardi" vaatimusten kuvauksessa ja tämä aiheuttaa riskejä.
Esiintyjät, jotka eivät ymmärrä, miksi tämä on tarpeellista, tekevät yleensä väärin. Esiintyjät, jotka eivät ole mukana idean luomisprosessissa, eivät ole mukana tuloksessa. Ketterä sanoo, ei keskitytään ensisijaisesti järjestelmään, vaan ihmisiin, kuluttajiin, heidän tehtäviinsä ja tavoitteisiinsa.
Luomme persoonaa, annamme heille yksityiskohtia empatiaa varten ja alamme kertoa tarinoita persoonan puolelta.
Toimistotyöntekijä Zakhar meni lounaalle ja haluaa pikaisen välipalan. Mitä hän tarvitsee? Ajatuksena on, että hän todennäköisesti haluaa liikelounaan. Toinen ajatus on, että hän haluaa järjestelmän muistavan hänen mieltymyksensä, koska hän on dieetillä. Toinen idea. Hän haluaa heti kahvia, koska on tottunut juomaan kahvia ennen lounasta.
Ja on myös liiketoimintaa (organisaation luonne on hahmo, joka edustaa organisaation etuja). Yritykset haluavat lisätä keskimääräistä sekkiä, lisätä ostotiheyttä ja kasvattaa voittoja. Ideana on - tarjotaan joidenkin keittiöiden epätavallisia ruokia. Toinen idea - esitellään aamiainen.
Ideoita voidaan ja pitää konkretisoida, muunnella ja esittää käyttäjätarinana. Zakhar Business Centerin työntekijänä haluan järjestelmän tunnistavan minut, jotta voin vastaanottaa mieltymykseni mukaisen valikon. Tarjoilijana haluan järjestelmän ilmoittavan minulle milloin tulee lähestyä pöytää, jotta asiakas on tyytyväinen nopeaan palveluun. Ja niin edelleen.
Kymmeniä tarinoita. Seuraavaksi priorisointi ja ruuhka? Jeff huomauttaa esiin nousevista ongelmista: takertuminen pieniin yksityiskohtiin ja käsitteellisen ymmärryksen menettäminen sekä toiminnallisuuden priorisointi luo hajanaisen kuvan, koska se on ristiriidassa tavoitteiden kanssa.
Tekijän polku: Emme aseta etusijalle toiminnallisuutta, vaan tulosta = mitä käyttäjä lopulta saa.
Ilmeinen ei-ilmeinen seikka: priorisointiistuntoa ei tee koko tiimi, koska se on tehoton, vaan kolme henkilöä. Ensimmäinen vastaa liiketoiminnasta, toinen käyttäjäkokemuksesta ja kolmas toteutuksesta.
Valitaan minimi yhden käyttäjäongelman ratkaisemiseksi (vähintään toimiva ratkaisu).
Esittelemme tärkeimmät ideat käyttämällä käyttäjätarinoita, suunnitteluluonnoksia, rajoituksia ja liiketoimintasääntöjä käyttäjätarinakartalla kertomalla ja keskustelemalla tiimin kanssa, mitä ihmiset ja sidosryhmät tarvitsevat prosessin jokaisessa vaiheessa. Jätämme jäljellä olevat ideat tutkimatta mahdollisuuksien ruuhkassa.
Prosessi on kirjoitettu korteille vasemmalta oikealle, ideat korteissa prosessin vaiheiden alla. On välttämätöntä, että koko tarinan läpi kulkeva polku keskustellaan yhdessä tiimin jäsenten kanssa molemminpuolisen ymmärryksen varmistamiseksi.
Tällä tavalla työstämällä syntyy prosessien mukaista eheyttä.
Saadut ideat on testattava. Ei-tiimin jäsen laittaa henkilön hatun päähänsä ja elää hänen päivän päässään, ratkaiseen hänen ongelmansa. On mahdollista, että hän ei näe kehitystä, luo kortteja uudelleen, ja tiimi löytää itselleen vaihtoehtoja.
Sitten on yksityiskohdat arviointia varten. Kolme ihmistä riittää tähän. Vastaa käyttökokemuksesta, kehittäjä, testaaja suosikkikysymyksellä: "Mitä jos...".
Keskustelussa seurataan kussakin vaiheessa käyttäjän historian prosessikarttaa, joka mahdollistaa käyttäjän tehtävän pitämisen mielessä johdonmukaisen ymmärryksen luomiseksi.
Onko dokumentaatio tekijän mielestä tarpeellista? Kyllä, tarvitsen sitä. Mutta muistiinpanoina, joiden avulla voit muistaa, mistä sovit. Ulkopuolisen mukaan ottaminen vaatii taas keskustelua.
Kirjoittaja ei syvenny dokumentaation riittävyyden aiheeseen, vaan keskittyy keskustelun tarpeeseen. (Kyllä, dokumentaatiota tarvitaan, vaikka ihmiset, joilla ei ole syvällistä ymmärrystä ketterästä, väittävät sitä). Myös vain osan ominaisuuksista kehittäminen voi johtaa siihen, että koko järjestelmä on uusittava kokonaan. Kirjoittaja korostaa liiallisen tarkentamisen riskiä siinä tapauksessa, että idea on väärä.
Riskien eliminoimiseksi on välttämätöntä saada nopeasti palautetta luotavasta tuotteesta, jotta "väärän" tuotteen luomisesta aiheutuvat vahingot voidaan minimoida. Teimme ideasta luonnoksen - validoimme sen käyttäjän kanssa, luonnostelimme käyttöliittymäprototyyppejä - validoimme sen käyttäjän kanssa jne. (Erikseen on vähän tietoa ohjelman prototyyppien validoinnista). Ohjelmiston luomisen tavoitteet varsinkin alkuvaiheessa ovat nopean palautteen kautta oppiminen, joten ensimmäinen tuote on luonnos, joka pystyy todistamaan tai kumoamaan hypoteesin. (Kirjoittaja luottaa Eric Riesin työhön "Startup using Lean methodology").
Tarinakartta auttaa parantamaan viestintää, kun toteutus toteutetaan useiden tiimien kesken. Mitä kartalla pitäisi olla? Mitä tarvitset keskustelun jatkamiseksi. Ei vain käyttäjätarina (kuka, mitä, miksi), vaan ideoita, faktoja, käyttöliittymäluonnoksia jne...
Jakamalla historiakartan kortit useisiin vaakasuoraan riviin, voit jakaa työn julkaisuihin - korosta vähimmäistasoa, lisää toimivuutta ja kumarteet.
Kerromme tarinoita prosessikartalla.
Työntekijä tuli lounaalle.
Mitä hän haluaa? Palvelun nopeudet. Joten hänen lounas odottaa häntä jo pöydällä tai ainakin tarjottimella. Hups - väliin jäänyt askel: työntekijä halusi syödä. Hän kirjautui sisään ja valitsi liikelounasvaihtoehdon. Hän näki kaloripitoisuuden ja ravintosisällön auttamaan häntä laihduttamaan ja laihduttamatta. Hän näki ruokalajista kuvia päättääkseen, syökö hän siinä paikassa vai ei.
Meneekö hän seuraavaksi lounaalle ja päivälliselle? Tai ehkä lounas toimitetaan hänen toimistoonsa? Sitten prosessin vaihe on ruokapaikan valinta. Hän haluaa nähdä, milloin se toimitetaan hänelle ja kuinka paljon se maksaa, jotta hän voi valita, mihin aikaansa ja vaivaansa käyttää - alakertaan vai töihin. Hän haluaa nähdä, kuinka kiireinen kahvila on, jotta se ei joutuisi jonoihin.
Sitten työntekijä tuli kahvilaan. Hän haluaa nähdä tarjottimensa, jotta hän voi ottaa sen ja mennä suoraan päivälliselle. Kahvila haluaa vastaanottaa rahaa ansaitakseen rahaa palvelusta. Työntekijä haluaa menettää mahdollisimman vähän aikaa kahvilan maksuihin, jotta hän ei tuhlaa arvokasta aikaa turhaan. Kuinka tehdä se? Maksa etukäteen tai päinvastoin etäpalvelun jälkeen. Tai maksa paikan päällä kioskilla. Mikä tässä on tärkeintä? Kuinka moni on valmis maksamaan lounaasta pankkikortilla? Kuinka moni luottaisi tähän ruokalaan tallentamaan korttinumeronsa toistuvia maksuja varten? Ilman kenttätutkimusta on epäselvää, testausta tarvitaan.
Prosessin jokaisessa vaiheessa sinun on tarjottava jotenkin toimintoja; tätä varten sinun on otettava joku henkilö perustaksi ja valittava, mikä on hänelle tärkeämpää (samat kolme valitsinta). Seurasi tarinaa loppuun asti = teki toteuttamiskelpoisen ratkaisun.
Seuraavaksi tulee yksityiskohdat. Asiakas haluaa nähdä kuinka kiireinen kahvila on, jottei joutuisi jonoihin. Mitä hän oikein haluaa?
Katso ennuste siitä, kuinka monta ihmistä siellä on 15 minuutin kuluttua, kun hän saapuu paikalle
Katso kahvilan keskimääräinen palveluaika ja sen dynamiikka puoli tuntia etukäteen
Katso tilanne ja pöytien käyttödynamiikka
Entä jos ennustejärjestelmä antaa epäselvän tuloksen tai lakkaa toimimasta?
Katso videon kautta kahvilan jonot sekä pöytien täyttöaste. Hmm, mikset tekisi sitä ensin?!
Kirjoittaja esittää pienen harjoituksen harjoittettavaksi: yritä kuvitella, mitä teet aamulla heräämisen jälkeen. Yksi kortti = yksi toiminta. Suurenna kortteja (kahvin jauhamisen sijaan juo virkistävää juomaa) yksittäisten yksityiskohtien poistamiseksi keskittyen toteutustapaan, vaan tavoitteeseen.
Kenelle tämä kirja on tarkoitettu: IT-analyytikoille ja projektipäälliköille. Pakollinen luettava.
Sovellukset
Keskustelu ja päätöksenteko on tehokasta 3-5 hengen ryhmissä.
Kirjoita ensimmäiselle kortille, mitä on kehitettävä, toiselle - korjaa mitä teit ensimmäisessä, kolmannelle - korjaa mitä tehtiin ensimmäisessä ja toisessa.
Valmista tarinoita kuten kakkuja - älä kirjoittamalla reseptiä, vaan selvittämällä kenelle, mihin tilaisuuteen ja kuinka monelle henkilölle kakku on tarkoitettu. Jos myynti jakautuisi, se ei koske kakkujen, kerman jne. tuotantoa, vaan pienten valmiiden kakkujen tuotantoa.
Ohjelmistokehitys on samanlaista kuin elokuvan tekeminen, kun täytyy kehittää ja hioa käsikirjoitus huolellisesti, organisoida kohtaus, näyttelijät jne. ennen kuvaamisen alkamista.
Resursseista tulee aina olemaan pulaa.
20% ponnisteluista tuottaa konkreettisia tuloksia, 60% antaa käsittämättömiä tuloksia, 20% ponnisteluista on haitallisia - siksi on tärkeää keskittyä oppimiseen eikä epätoivoon, jos tulos on negatiivinen.
Kommunikoi suoraan käyttäjän kanssa, tunne itsesi hänen kengissään. Keskity joihinkin ongelmiin.
Tarinan tarkentaminen ja kehittäminen arviointia varten on rumin ankein osa, tee keskustelut stand-up akvaariotilassa (3-4 henkilöä keskustelee laudalla, jos joku haluaa osallistua, hän korvaa jonkun).
Lähde: will.com