Yksi suurimmista haasteista ohjelmistojen kehitys on lähes mahdoton tehtävä kerätä selkeät vaatimukset, ja sitten saada ne vaatimukset pysyvät ennallaan aikana koodi kehitystä. Vesiputous lähestymistapa ohjelmistojen kehittäminen—huolimatta pyrkimyksiä määritellä, dokumentoida ja hyväksyä kaikki mahdollinen valmiussuunnitelma, ennen kuin kehitys alkaa—toimitettu tuote on harvoin, mitä asiakas haluaa.
ketterä vaihtoehto? Käyttäjän tarinan luominen.,
Yksi suurimmista eduista käyttäen ketterä lähestymistapa ohjelmistokehitykseen on, että vaatimukset eivät ole kiveen hakattuja, mutta sen sijaan odotetaan, muutos, jatkuva palaute sidosryhmiltä ja liiketoimintaa. Ketterät menetelmät, kuten Scrum ja extreme programming (XP) korvata perinteisiä, pitkiä vaatimukset asiakirjoja, joissa on priorisoitu tuotteen kehitysjono koostuu tiivis käyttäjän tarinoita, yksityiskohtia joista syntyy lähempänä kun tarina on valmis toteutetaan.,
Vaikka käyttäjä tarinan luominen on enemmän taidetta kuin tiedettä, tämä opas antaa sinulle tietoa, esimerkkejä, ja vaiheet sinun täytyy luoda laadukkaita käyttäjä tarinoita.
historia käyttäjän tarinoita
XP ensimmäisenä käyttöön käsitteen käyttäjän tarinoita vuonna 1998, vertaamalla niitä käyttää tapauksissa. Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson käyttöön käyttötapauksia kuin tapa dokumentoida vaatimusten määrittelemällä vuorovaikutusta rooli (henkilö käyttää järjestelmää) ja itse järjestelmä saavuttaa tavoite käyttämällä Unified Modeling Language (UML).,
Tämä lähestymistapa oli suosittu olio-kehitys-ja käytetään edelleen keskeisenä prosessin software development frameworks, kuten Unified Process (UP), IBM: n Rational Unified Process (RUP), ja Oracle Unified Method (OUM). Käyttötapausten käyttö käyttäjien tarinoiden sijaan mahdollistaa iteratiivisen ja inkrementaalisen kehityksen, ja sitä pidetään ketteränä lähestymistapana vaatimusten määrittelyyn.,
ottamalla käyttöön paljon lyhyempi käyttäjän tarinoita ja suosio XP ja Scrum, tuotteen kehitysjono koostuu käyttäjän tarinoita tuli yleisesti tunnettu lähestymistapa ketterä vaatimusten määrittely. Monet harjoittajat edelleen sitä mieltä, että käyttäjätarinat ovat ainoa hyväksyttävä ketterä lähestymistapa. Ketterän manifestin allekirjoittajiin kuuluva Alistair Cockburn kuitenkin käyttää tapauksia mieluummin käyttäjien tarinoihin.
vaikka ”ketterän” merkityksestä on paljon vahvoja mielipiteitä, sekä käyttötapaukset että käyttäjätarinat ovat yhteensopivia kyseisen lähestymistavan kanssa., Jotkut sanovat käyttäjätarinoiden muuttuvan lopulta käyttötapausten kaltaisiksi, kun tiimi on sopinut toteutuksen yksityiskohdista. Alkuvaiheessa, käyttäjä tarina on yksinkertaisesti lyhyt lause, mutta se ei ole täydellinen, ennen kuin tiedot ja hyväksymiskriteerit on määritelty.
käyttäjäkertomusten luominen
käyttäjäkertomuksen määrittelystä ja siitä, miten sellaisen luominen parhaiten onnistuu., Joitakin suuntaviivoja hyvä käyttäjätarina ovat seuraavat:
- Sen olisi kirjoittanut joku, joka edustaa liiketoiminta-käyttäjät (yleensä tuotteen omistaja)
- Se olisi aluksi sisältää lyhyet kuvaukset ”kuka, mitä, miksi,”mutta ei ”miten”
- Sen pitäisi tuottaa pystysuora siivu toimiva koodi
- Sen pitäisi olla tarpeeksi pieni, että se voi olla koodattu ja testattu yhden iteraation (yleensä one-to-neljän viikon jakson)
Eri malleja, tekniikoita, ja lyhenteitä käytetään auttaa tuotteen omistajat käyttäjä kirjoittaa tarinoita., Kolme yleisimpiä tekniikoita ovat rooli-ominaisuus-syy, malli, Kolmen C: n (card, conversation, confirmation), ja SIJOITTAA (riippumaton, neuvoteltavissa, arvokas, hyvä, pieni, testattavissa).
Esimerkkejä
Sano, että olet kehittää sovelluksen, jonka avulla kouluttajat voivat ladata kurssimateriaalia ja houkutella opiskelijoita, jotka ovat kiinnostuneita kurssilla. Näin voit soveltaa käyttäjän tarina tekniikoita.,
Rooli-Ominaisuus-Syy
Kuten Mike Cohn Mountain Goat Software kertoo, rooli-ominaisuus-syy mallin, tai RGB (rooli, tavoite, hyötyä), näyttää tältä:
”Koska minä haluan niin .”
vaikka variaatioita on, tämä lyhyt lauserakenne pitää huomion who: ssa, mitä ja miksi. Tämä estää tuotteen omistajaa antamasta kehitystiimille liikaa tietoa siitä, miten ratkaisu pitäisi toteuttaa. Keskittymällä kuka, mitä, miksi, kehitystiimi on valta löytää paras tekninen ratkaisu.,
Esimerkki 1: anna valmentaja, jolla on kyky lisätä tietenkin
kouluttajana, haluaisin pystyä lisätä uuden kurssin, niin että minulla on potentiaalia houkutella uusia opiskelijoita.
Esimerkki 2: Tarjota opiskelijalle kyky etsiä kurssin
opiskelija, haluaisin pystyä etsiä kurssitarjonta, niin että voin löytää joka tarjoaa että useimmat kiinnostaa minua.
rooli (who)
rooli kuvaa, jotka hyötyvät tämän toiminnon. Huomaa, että rooli ei ole vain ”käyttäjä.,”On olemassa erilaisia käyttäjiä, ja niin haluamme rooli olla tarkempi kuin ”käyttäjä”, mutta kuvaavat käyttäjätyyppiä, jotka hyötyvät tarina. Tuotteiden omistajien tehtävänä on usein saada käyttäjiensä mieleen, jotta he ymmärtäisivät, mikä olisi heille kaikkein arvokkainta.
Esimerkki 1 Rooli = kouluttaja
Esimerkki 2 Rooli = opiskelija
ominaisuus (mitä)
Tämä vaihe hyvin lyhyesti kuvataan, mitä käyttäjä haluaa. Tämä edustaa parhaiten vaatimusta, jonka kuvailet perinteisessä ohjelmistokehityksessä., Kuitenkin, haluat olla varovainen olla liian tarkka tai kuvata, miten kirjoittaa koodin. Se selviää lopulta, mutta ei silloin, kun luot käyttäjätarinan. Käyttäjän tarina tulisi kirjoittaa toiminnosta hyötyvän käyttäjän näkökulmasta, ei sitä koodaavan kehittäjän näkökulmasta.
Esimerkki 1 Ominaisuus = lisää uusi kurssi
Esimerkki 2 Toiminto = etsiä kurssitarjonta
syy (miksi)
Lopuksi, haluamme valtion, miksi käyttäjä haluaa tätä ominaisuutta. Mitä arvoa käyttäjä saa siitä?, Tämä auttaa tuotteen omistajaa arvioimaan, miten käyttäjän tarina priorisoidaan ruuhkassa. Jos arvoa tai hyötyä ei voi ilmaista, se voi olla jotain, mikä ei ole tarpeen. Arvon ymmärtäminen auttaa usein kehitystiimiä löytämään innovatiivisia tapoja koodin toteuttamiseksi tavoitteen ratkaisemiseksi-tapoja, jotka voivat olla erilaisia kuin mitä tuotteen omistajalla on mielessä.,
Esimerkki 1 Syy = houkutella uusia opiskelijoita
Esimerkki 2 Syy = etsi erinomainen tarjoaa että useimmat kiinnostaa minua,
Kolmen C: n: Card, Conversation, Confirmation
Kolmen C: n kaava kehittämä Ron Jeffries, auttaa saavuttamaan välinen sopimus liiketoiminnan ja teknisen tiimin merkitys käyttäjän tarina. The Three c ’ s ohjaa heitä läpi Progressiivinen laatiminen tarina, lyhyt lausunto täysin kehittynyt käyttäjän tarina.,
Kortti
käyttäjän tarina alkaa tarkoituksella lyhyt, yksinkertainen toteamus, joka voisi sovi 3×5-indeksi kortin, tyypillisesti seuraavat rooli-ominaisuus-hyöty-muodossa, että en vain kuulu. Esimerkiksi:
valmentajana haluaisin uuden kurssin, jotta minulla olisi potentiaalia houkutella uusia opiskelijoita.
Conversation
vaikka käyttäjätarina alkaa yksinkertaisena lausuntona, pitää yksityiskohtien syntyä ennen kuin tiimi alkaa työstää tarinaa., Sen sijaan kuvailla, mitä on tarvittavat asiakirjat, joukkue tulee sisältää 1) edustus liiketoiminnan (yleensä tuotteen omistaja), ja 2) kehitystiimi itse, mukaan lukien kehittäjät, testaajat, liike analyytikot, tai joku muu joukkue.
Tämän keskustelun avulla kehitystiimi esittää kysymyksiä, jotta heillä on selkeä käsitys siitä, mitä kysytään, ja arvo on säädetty. Esimerkiksi:
Kehittäjä: pitääkö kouluttajan ladata courseware verkkosivulle?,
Tuotteen omistaja: Ei, kouluttaja vain lisäämällä tietoa kurssi, joka tarjotaan, ja ominaisuus olisi sisällyttää tapa opiskelijalle saada kiinnostusta luetteloon. Tämä tarina antaa kouluttajalle mahdollisuuden mainostaa kurssia.
Developer: What fields should be included?
tuotteen omistaja: kurssin nimi, Abstrakti, päivämäärät ja ajat, sijainti.
Kehittäjä: tuleeko tämä vain mainostamaan kasvokkain-luokkia?
tuotteen omistaja: Kyllä., Voimme lisätä virtuaalinen luokka vaihtoehto myöhemmin, mutta tämä tarina kattaa vain lisäämällä kurssin tiedot face-to-face-luokan tarjoukset.
Kehittäjä: mitä tietoja kannattaa kerätä, kun mahdollinen opiskelija pyytää päästä korkolistalle?
Tuotteen omistaja: Nimi, puhelinnumero, ja sähköpostiosoite.
joukkue on päivittää käyttäjän tarina tiedot heillä kokoontuivat alkaen keskustelun, ja he keskustelevat täytäntöönpano—tai ”miten”—joka usein luo erityisiä tehtäviä, jotka on tehtävä, jotta täydellinen tarina., Vaikka käyttäjätarina on kirjoitettu käyttäjän näkökulmasta, kehitystiimi kirjoittaa tehtävät kehittäjille ja sisältää tekniset toteutustiedot.
Vahvistusta
kehitystiimi on oltava selkeä käsitys siitä, miten ominaisuus toimii eri tilanteissa, mukaan lukien virhe ehtoja. Niiden on saatava tuotteen omistajalta vahvistus hyväksymiskriteereistä. Näiden kriteerien on täytyttävä, jotta tarina katsotaan tehdyksi ja hyväksytyksi., Tässä on esimerkki hyväksymiskriteerit:
- kouluttaja voi lisätä uusi kurssi kirjoittamalla kurssin nimi, abstrakti, päivämäärät ja ajat, ja paikka lomake ja paina ”lisää kurssi” – painiketta.
- Jos jokin kenttä puuttuu tai päivämäärät tai ajat ovat virheellisiä, tulee virheilmoituksia.
- Kun kurssi on lisätty oikein, se näytetään julkisesti kurssin verkkosivuilla ja siellä on painike, josta opiskelija ilmaista kiinnostusta.,
- korko-painikkeen avulla käyttäjä voi syöttää nimi, sähköpostiosoite, ja puhelinnumero, ja tämä tieto tallennetaan ja liitetään uuden kurssin.
INVEST: ominaisuudet vankka käyttäjän tarina
INVEST on lyhenne, joka auttaa arvioida, onko sinulla on korkea-laatu käyttäjän tarina. Näin lyhenteen attribuutit pätevät tarinaan, jota olemme työstäneet.
I = Independent—saako tämän tarinan valmiiksi joukkue? Haluamme, että tiimi pystyy täydentämään koko tarinan sen sijaan, että olisi riippuvainen eri tiimistä esimerkiksi GUI: n tekemiseen.,
N = Neuvoteltavissa—tarina ei ole niin yksityiskohtainen kuin kuvata tarkasti, miten pitkä kentät pitäisi olla tai antaa yksityiskohtia siitä, päivämäärämuotoja ja vastaavat. Todennäköisesti tulee yhteisiä rutiineja tai kirjastoja, joiden avulla kehitystiimi voi toteuttaa niitä mielekkäimmin.
V = Arvokas—tuotteen omistaja kuvailee, että arvo haetaan on kyky kouluttaja voi mainostaa tulevia luokkia. Tämä käy ilmi alkuperäisen lausunnon ”miksi” – kohdasta ja korostuu keskustelussa uudelleen.,
e = Estimable—tiimi esittää tarpeeksi kysymyksiä ja kerää yksityiskohdat luottaakseen kykyyn arvioida tarinaa.
s = Small—joukkueen on voitava luottaa siihen, että he saavat tarinan valmiiksi sprintissä. Jos he eivät tee niin, he saattavat jakaa tarinan. Esimerkiksi, meidän näyte tarina, he voivat päättää kyky kerätä opiskelijan tiedot olla eri juttu ja yksinkertaisesti näyttää tietoja luokan tämän tarinan.
t = testattava—selkeillä hyväksymiskriteereillä voidaan testata sekä onnellista polkua että virheolosuhteita.,
Kohdistamalla visio
olen perusasiat luoda käyttäjän tarina, mutta silti täytyy ymmärtää iso kuva ennen kuin luot oman käyttäjän tarinoita. On paljon työtä sinun täytyy tehdä etukäteen, korkeammalla tasolla, määrittää, mitä korkeimman arvon ominaisuuksia on, että pitäisi toimittaa asiakkaille. Ne hajoavat lopulta käyttäjien tarinoiksi.
on tärkeää, että joukkue ensin ymmärtää korkean tason visio ja varmista, että ominaisuudet, ja viime kädessä käyttäjän tarinoita, tasaa, että korkean tason visio.,
tyypillisesti tuote hajotetaan ryhmiksi, jotka menevät nimillä, kuten ”teemoilla” tai ”ominaisuuksilla.”Vaikka merkintöjä näiden kehitysjonon kohdat voi vaihdella riippuen ketterä menetelmä ja työkalut, joilla voit käyttää kuvaamaan niitä, idea on varmistaa, että he kohdista niin, että työ voidaan jäljittää jopa visio, joka varmistaa, että sinulla ovat kokouksen tavoitteet ja arvot tuotteen visio.
taas, älä aloita projektia luomalla käyttäjätarinoita, vaan aloita luomalla visio., Esimerkissämme näytän yksinkertaisesti näyteilmoituksen, joka johtaa joihinkin näytteen ominaisuuksiin, jotka voidaan edelleen hajottaa käyttäjän tarinoiksi.
Vision
tarjoaa korkealaatuisen verkkosivuston, jonka avulla kouluttajat voivat mainostaa kursseja ja antaa opiskelijoille mahdollisuuden osallistua niihin.
Ominaisuudet
- Tarjota kurssitarjonta-sivu, jonka avulla opiskelijat voivat ilmoittautua kursseille.
- tarjoaa kotisivun, joka kertoo käyttäjille, mistä sivustossamme on kyse.
- tarjoaa rekisteröintiprosessin, jonka avulla käyttäjät voivat kirjautua sisään, luoda profiilin ja seurata luokkiaan.,
- antaa blogin, joka auttaa mainostaa tarjontaamme ja saada julkisuutta sivustollemme.
Käyttäjätarinat
- tarjoavat trainerille mahdollisuuden lisätä kurssi kurssitarjontasivulle.
- antaa opiskelijoille mahdollisuuden hakea kurssia.
yllä olevassa esimerkissä näet, miten käyttäjien tarinat saivat alkunsa. Käyttäjätarinat olivat osa ominaisuutta ”tarjota kurssitarjontasivu”, joka vastaa korkean tason visiota.,
Vaikutus kartoitus
Vaikka kohdistamalla vision auttaa sinua täyttää teidän ensimmäinen ruuhkaa, se ei ole ainoa tapa tehdä niin. On olemassa monia työkaluja ja tekniikoita, jotka tuotepäälliköt voivat käyttää luoda tarinoita, jotka menevät uuteen ruuhkaa ja että kohdista visio.
Yksi strateginen suunnittelu tekniikka, jota käytetään auttamaan ymmärtämään iso kuva, vaikutusten kartoitus, oli suosituksi Gojko Adzic, kirjoittaja Viisikymmentä Nopea Ideoita Parantaa Käyttäjän Tarinoita ja Vaikutusten Kartoitus: Tehdä suuri vaikutus ohjelmistoja, tuotteita ja hankkeita., Impact mapping on tavoitteesta alkava mielikartta, jonka pitäisi käsitellä arvokysymystä ja sitä, miksi tuotetta rakennetaan.
seuraava taso listaa ”näyttelijät” eli ihmiset, jotka auttavat tavoitteen saavuttamisessa. Seuraavaksi kartta listaa käyttäytymismallit eli” vaikutukset”, joita toimijat tekevät auttaakseen tämän tavoitteen saavuttamisessa. Kartan lopullinen taso esittelee” tuloksia”, joita tiimi voi toteuttaa. Ne mahdollistavat ja tukevat toimijoita luomaan toivottuja vaikutuksia. Se on näistä toimituksista, että saat ohjelmiston ominaisuuksia ja tarinoita.,
- Tavoite: Tehdä laajalti saatavilla kursseja, että opiskelijat haluavat ottaa
- Toimijat: Kouluttajat, opiskelijat
- Vaikutukset: Kouluttajat tarjoavat laadukkaita luokat, jotka kiinnostavat opiskelijoita, opiskelijoita, antaa lähetteet ja suositukset
- Tuotokset: Korkea-laatu-luokat, jotka ovat saatavilla opiskelijoille
- Mahdollisia tarinoita:
- ”Kuten valmentaja, haluan mainostaa luokat, niin että voin saada opiskelijat.
- ”kouluttajana haluan saada palautetta opiskelijoilta, jotta voin jatkuvasti parantaa.,”
- ” kouluttajana haluan selvittää, mitä opiskelijat haluavat, jotta voin lisätä opetussuunnitelmaani.”
- ” opiskelijana haluan löytää luokat, jotka kiinnostavat minua eniten.”
- ” opiskelijana haluan löytää kursseja, joita voin käydä netissä, jottei tarvitsisi matkustaa.”
- ” opiskelijana haluan lukea toisten arvosteluja, jotta voin päättää, mitkä tunnit sopivat minulle parhaiten.”
kartoittaa käyttäjän tarinoita tällä tavalla mahdollistaa jäljitettävyyden osaksi ajattelua siitä, miten tarinat lopulta luoda arvoa ja miten käyttää niitä saavuttaa päämäärä., Ideana ei ole toteuttaa kaikkea, vaan löytää lyhin polku kartan läpi tavoitteen saavuttamiseksi.
Jakaminen stories
Yksi yleisimmistä ongelmista ketterä joukkueet törmätä on, kun tarinat ovat liian suuria, ja voi olla suoritettu iteraatio. Kun joukkue luo tehtäviä, jotka liittyvät tarina, he ymmärtävät, että on olemassa liian monia tuntemattomia, tai että tehtävät vievät enemmän aikaa kuin joukkue on saatavilla yhden iteraation. Joukkueet käsittelevät tätä joskus jakamalla isomman tarinan pienempiin tarinoihin.,
muista kuitenkin, että haluat käyttäjätarinan toimittavan käyttöohjelmistoja, jotka tuovat lisäarvoa käyttäjälle. Sen sijaan, että luodaan käyttäjä tarina, joka vain osittain suorittaa toiminnon, jakaa tarinoita ”pystysuoria viipaleita”, jotka tarjoavat end-to-end toimintoja.
Kääntyä yhteisön syvempää oppimista
Yksityiskohtaisia ratkaisuja siihen, miten ratkaista kovimmat ongelmat liittyvät vaatimukset ja käyttäjätarinat ovat ainutlaatuisia kussakin tilanteessa. Yksi menestyvien ketterien harjoittajien yhteinen piirre on kuitenkin se, että he ovat innokkaita auttamaan muita ja jakamaan tietämäänsä.,
Cohnin userStories sivusto mahdollistaa niille, jotka työskentelevät tuotteen viivästyksiä ja käyttäjän tarinoita jakaa tuotteita, resursseja ja tietoa. Tuotteet-sivu sisältää vaikuttava lista työkaluja, monet saatavilla ilmaiseksi, mahdollisuuksia käyttäjän arvostelua ja input. Cohn toteaa sivustolla toivovansa sivuston laajentamista, jotta tuotteen taustajoukot voidaan jakaa.
ei tule koskaan olemaan yksikokoista vastausta siihen, miten täydellisiä käyttäjätarinoita kirjoitetaan., Kuitenkin, ajan, terve sekoitus kokemusta, neuvoja asiantuntijoilta, ja kokeilun ehdotti, työkaluja ja tekniikoita, voit jatkuvasti parantaa.