Ohjelmointi

Ketterien käyttäjäkertomusten kirjoittaminen: 7 ohjetta

Ketterät käyttäjätarinat ovat pohjimmiltaan lyhyitä, yksinkertaisia ​​työkaluja dokumentoimaan yksittäisen toiminnan tai aikomuksen, jonka kohteena oleva käyttäjä haluaa tavoitteen saavuttamiseksi. Yksinkertaisimmilla käyttäjäkertomuksilla on muoto ”As a käyttäjätyyppi tai rooli, Haluan toiminta tai aikomusjotta syy tai hyöty”, Joka vastaa vähintään kolmeen yksinkertaiseen kysymykseen siitä, kuka, mitä ja miksi tarina on myöhässä.

Kun joukkueet kehittyvät ja organisaatiot käyttävät ketterää useissa ryhmissä ja aloitteissa, ketterät käyttäjätarinat saavat usein paljon suuremman määritelmän ja rakenteen, jotta tahdosta ja taustalla olevista vaatimuksista saadaan yhteinen käsitys.

Ketterien käyttäjäkertomusten kirjoittamisen aloittaminen

On paljon resursseja, jotka auttavat uusien tuotteiden omistajia, yritysanalyytikkoja, scrum-mestareita ja teknisiä johtajia ymmärtämään käyttäjäkertomusten kirjoittamisen perusteet. Jotkut aloituspaikat sisältävät artikkeleita Atlassianista, FreeCodeCampista, ketterästä mallinnuksesta ja nämä 200 käyttäjätarinan esimerkkiä. Yksi täydellisemmistä kirjoituksista on Alexander Cowanin parhaassa ketterässä käyttäjäkertomuksessa. Tarinankirjoituksesta on kirjoja, mukaan lukien Käyttäjän tarinan kartoituskirjoittanut Jeff Paton ja Peter Economy ja Sovelletut käyttäjän tarinatkirjoittanut Mike Cohn. Voit myös käydä tarinankirjoituskursseja Udemylta, Learning Tree, VersionOne ja Lynda.

Yksi perusperiaate, jonka Bill Wake jakoi ensin, on sijoita hyviin tarinoihin. Sijoittaatarkoittaa "riippumatonta, neuvoteltavaa, arvokasta, arvioitavaa, pientä ja testattavaa", mikä muodostaa hyvän tarkistuslistan ketterille tarinankirjoittajille. "Ketterän johtajan opas käyttäjien tarinoiden kirjoittamiseen" on yksi artikkeli, joka selittää hakemuksen sijoittaaperiaatteita.

Perustiedot ovat suhteellisen helppoja, mutta kuulen ja todistan usein, että sidosryhmät, tuotteiden omistajat, kehittäjät ja testaajat katkeavat yhteyden vaatimusten laatuun vai onko tarina todella tehty. Vaaditulla yksityiskohdilla on joskus ristiriitaisia ​​näkökulmia, mihin ne sopivat teknisiin vaatimuksiin ja mitkä artefaktit tulisi luoda käyttäjien tarinoiden kanssa.

Nämä kysymykset mielessä tässä on seitsemän perusopetuksen ohjetta ketterien käyttäjäkertomusten kirjoittamiseen.

1. Kirjoita tarinoita yleisölle, joka käyttää niitä

Ennen kuin kirjoitat tarinoita, muista, että tarinat on tarkoitettu lukemaan ja ymmärtämään kehitysprosessiin osallistuvilla ihmisillä, joilla on erilaiset tarpeet ja vastuut. Tarinankirjoittajien ja kirjoittajien tulisi pitää yleisö mielessä ja suunnitella tarinoita vastaamaan kollektiivisiin tarpeisiin:

  • Tuotteiden omistajat eivät välttämättä kirjoita tarinoita, varsinkin jos organisaatiosi delegoi tämän toiminnon yritysanalyytikoille tai jos tarinoiden kirjoittamiseen osallistuu useita ihmisiä. Tuotteiden omistajat haluavat varmistaa, että tarina ottaa käyttäjän tarpeet ja tarkoitukset täysin huomioon. Heidän tulisi lukea yksityiskohtaiset hyväksymiskriteerit, mutta he eivät välttämättä halua, että heillä on takana tekniset toteutustiedot. Tuotteiden omistajien tulisi myös ymmärtää, kuinka tarina kohdistetaan laajempaan kuvaan, joten heidän on kiinnitettävä aktiivista huomiota eeppien ja ominaisuuksien määrittelyyn ja tarinoiden määräämiseen heille.
  • Sidosryhmät eivät lue tarinan yksityiskohtia, mutta tutkivat eepoja ja lukevat tarinan yhteenvedon. Jos sinulla on monia sidosryhmiä, harkitse kuvailevan muodon käyttämistä yhteenvetoiksi ja siirrä "As a käyttäjätyyppi tai rooli”Kuvaus käyttäjän tarinan kuvauksen alkuun.
  • Tekniset johtajat ovat usein ensimmäinen henkilö tiimistä, joka tarkastelee tarinoita, ja he tutkivat vaatimuksia nähdäkseen, onko tarina liian suuri ja pitäisikö se jakaa useaan tarinaan, vai onko tarina tarjonnut etukäteen teknistä työtä parhaan selvittämiseksi ratkaisu.
  • Valtuutettu on vastuuhenkilö, joka tarkistaa yksityiskohdat ja raportoi edistymisestä päivittäisissä standup-kokouksissa. Valtuutettujen tulisi tarkistaa tarinoita riippuvuuksista, joista voi tulla estoja sprintin aikana.
  • Tiimin jäsenet tarkastelevat usein kaikkia tarinoita ymmärtääkseen niille osoitetut tarinat muiden sprintille osoitettujen tarinoiden yhteydessä.
  • Testaajat selvittävät, onko olemassa aukkoja tai riskejä, joita ei ole tunnistettu hyväksymiskriteereissä, ja miettivät sitten, miten ne voidaan parhaiten toteuttaa automaattisissa testauskehyksissä.
  • Ryhmän analyytikko, joka voi olla ohjelmapäällikkö tai projektinhallintatoimiston jäsen, haluaa tarinat täysin merkittyinä ja luokiteltuina, jotta merkitykselliset mittarit voidaan vetää myöhässä.

2. Aloita käyttäjän mielessä

Vaikka ketterät käyttäjätarinat saattavat vaatia monia yksityiskohtia, on erittäin tärkeää aloittaa käyttäjän mielessä. Tarinan pitäisi olla määrittelevä mitätoiminta tai aikomus, jonka käyttäjä haluaa suorittaa, ja miksitämä kohdistuu kokemukseen perustuvaan tarpeeseen, perusarvoon tai tavoitteeseen.

Monimutkaisemmissa sovelluksissa erilaisten käyttäjähenkilöiden määritteleminen, jotka kuvaavat eri käyttäjätyyppien tarpeita, arvoja ja käyttötapoja, on tärkeä ala ja voi parantaa tarinankirjoitusta. Roman Pichler ehdottaa "10 vinkkiä hyvien käyttäjäkertomusten kirjoittamiseen", että "persoonalliset tavoitteet auttavat sinua löytämään oikeat tarinat. Kysy itseltäsi, minkä toiminnallisuuden tuotteella tulisi olla henkilöiden tavoitteiden saavuttamiseksi. " Henkilöiden käyttäminen käyttäjien tavoitteiden vahvistamiseen antaa rikkaamman merkityksen miksitarina on tärkeä ja auttaa priorisoimaan myöhästymistä.

3. Vastaa miksi tarina on tärkeä

Käyttäjätarpeiden tai käyttäjän henkilökohtaisten tavoitteiden ymmärtäminen, dokumentointi ja keskustelu on vain yksi ulottuvuus miksituotteen omistaja priorisoi tarinoita. Tarinan tulisi myös tuottaa liiketoiminnallista arvoa, mikä on vaikea mitata, mutta saattaa olla kelvollinentarinan, ominaisuuden, eepoksen tai julkaisutasolla.

Vastaaminen miksivoi olla tärkeä kehittäjille, kun heillä on valtuudet ehdottaa erilaisia ​​toteutusvaihtoehtoja. Esimerkiksi ominaisuus, joka parantaa käyttäjien kirjautumiskokemusta, voi hyödyttää myös yritystä, jos uusi kokemus tuottaa myös parempia asiakastietoja. Kehittäjä voi pohtia tätä liiketoiminnan lisäarvoa ja optimoida tämän tavoitteen toteutuksen, vaikka tarinan hyväksymiskriteerit eivät olekaan tarkkoja tämän vaatimuksen suhteen.

4. Määritä hyväksymiskriteerit määrittelemättä ratkaisua

Merkittävin kurinalaisuus, johon tarinankirjoituksessa on keskityttävä, on hyväksymiskriteerien laatiminen. Nämä ovat usein luettelomerkittyjä luetteloita lyhyistä läpäisy- tai epäonnistumislausekkeista, jotka dokumentoivat vaatimukset, rajoitukset, mittarit ja odotukset. Näitä hyväksymiskriteerejä käytetään usein useilla tavoilla:

  • Tekniset johtajat ja ryhmät käyttävät niitä arvioidakseen tarinapisteitä monimutkaisuuden ja vaivojen perusteella.
  • Kehittäjät kaventavat toteutusvaihtoehdot sellaisiin, jotka täyttävät hyväksymiskriteerit.
  • Tuotteiden omistajat voivat vähentää hyväksymiskriteerien soveltamisalaa tai monimutkaisuutta saadakseen aikaan toteutuksia pienemmillä arvioilla.
  • Valtuutettu kommunikoi vaikeiden kriteerien täyttävien lohkojen tai asioiden kanssa standupsissa.
  • Laadunvarmistusinsinöörit käyttävät hyväksymiskriteerejä automatisoitujen testien kehittämiseen.
  • Tuotteen omistaja tarkistaa tärkeimmät kriteerit ketterän esittelyn aikana varmistaakseen, että tarina on tehty.

Hyväksymiskriteerien kirjoittaminen ei ole triviaalia. Hyväksymiskriteerien hyväksymiskriteerit korostavat joitain asioita, kuten liian monien kriteerien tarjoaminen, liian epämääräisten kriteerien määrittäminen tai monimutkaisten kriteerien dokumentoiminen, joita ei voida helposti vahvistaa. Jotkut kirjoittajat käyttävät hyväksymiskriteerimalleja, jotka määrittelevät rakenteen lyhyille, atomi- ja testattaville kriteereille.

5. Käytä tarinoita määritelläksesi mitä ja miksi; määritellä tehtävät miten toteuttaa

Yksi kriittisistä virheistä, joiden näen joukkueiden tekevän tarinan kirjoittamisen ympärillä, on olla täsmällinen ja täsmällinen toteutuksen suhteen. Nämä huonosti kirjoitetut tarinat käyttävät paljon vaivaa kuvaamiseen Mitentoteuttaa usein kuvaamisen kustannuksella mitäkäyttäjän tarpeet, miksisiinä käsitellään heidän tavoitteitaan ja missäse lisää liiketoiminnan arvoa.

Tähän voi olla muutama syy.

Kokemattomat tuotteen omistajat voivat käyttää tarinoita maalaamaan toteutusvisionsa. Toisin sanoen he saattavat täsmentää liikaa käyttäjän suunnittelua ja toiminnallisia toteutuksia sen sijaan, että jakavat kohdekäyttökokemuksen ja edut. Jotkut tuotteiden omistajat sekoittavat käsitteensä siitä, miten jokin voityön (prosessi, jolla he ymmärtävät vaatimukset) ja miten se toimii pitäisityötä, muuttamalla sisäisen toteutusesimerkin vahingossa ulkoiseksi toteutusmäärittelyksi.

Muut tuotteiden omistajat saattavat ylittää rajansa pyytämällä tiimiä "rakentamaan minulle tämä". Se on yksi 20 huonosta käyttäytymisestäni tuotteen omistajien kanssa, ja minulla on suosituksia tuotteiden omistajille yhteistyöstä ratkaisutiimin kanssa.

Toinen syy siihen, että tarinat voivat olla täynnä toteutuksen yksityiskohtia, on se, että jotkut tiimit ja tekniset johtajat haluavat tämän tason yksityiskohtia. Äskettäin perustetut tekniset ryhmät, jotka työskentelevät nykyisten sovellusten parantamiseksi, saattavat haluta tämän tason yksityiskohtia, kunnes he ymmärtävät paremmin sovelluksen toiminnan ja ymmärtävät täysin käyttäjien tarpeet. Jotkut hajautetut ryhmät, jotka työskentelevät offshore-kehittäjien tai freelancereiden kanssa, saattavat myös haluta dokumentoida toteutuksen yksityiskohdat varmistaakseen, että nämä jäsenet ymmärtävät vastuunsa.

Tällaisten ryhmien kannalta parasta on linkittää toteutuskaavioihin ja dokumentoida, kuka tekee mitä ja miten tarinaan liittyvinä tehtävinä. Useimmat ketterät hallintatyökalut sallivat tehtävien tai alatehtävien, ja tämä yksityiskohtaisuus erotetaan yleensä tarinan rungosta. Tämän viestin kaavio tekee hyvää työtä havainnollistaen tätä tärkeää periaatetta käyttää ketteriä tarinoita käyttökokemusten ja liiketoimintaprosessien hajottamiseksi ja lisätä tehtäviin määrittelemään toteutus yksittäisiin töihin.

6. Lisää tarinoihisi analytiikkaa ja parannuksia

Kun tarinat on kirjoitettu, työskennelty ja valmistunut, monet tiimit haluavat kerätä mittareita ja tehdä analyyseja, jotka voivat edistää prosessin parantamista tai joita käytetään liiketoimintatapausten tekemiseen lisäsijoitusta varten.

Tässä on joitain esimerkkejä:

  • Merkitse tarinat tekniseksi velaksi, jotta voit mitata velan koon, prosenttiosuuden joukkueen nopeudesta, jota sillä on käytetty, ja kokonaisvelka, joka on suoritettu jokaisen julkaisun yhteydessä.
  • Määritä toiminnalliset ja tekniset huipputarinat kokeilun ja innovaatioiden edistämiseksi ja raportoi sitten, missä sillä on liiketoiminnallisia vaikutuksia.
  • Jos tiimisi arvioi ketteriä käyttäjäkertomuksia, pyydä tiimiä merkitsemään tarinoita sprintin lopussa ilmoittamaan, yliarvioivatko ne vai aliarvioivatko arvioiden tarkkuuden parantamiseksi.
  • Käytä tarroja, komponentteja ja mukautettuja kenttiä auttaaksesi hakemaan vanhentuneita tietoja tai mittareita. Esimerkiksi tieto siitä, mitkä tarinat vaikuttivat sovellusliittymiin tai mitkä vaatimukset johtivat viimeisiin toiminnallisiin parannuksiin sovelluksen tietylle alueelle, voidaan tehdä, kun tarinat on merkitty toiminnallisiin ja teknisiin komponentteihin.
  • Merkitse tunnisteita, jotka keräävät tai käsittelevät arkaluonteisia tietoja, kuten henkilökohtaisia ​​tunnistetietoja (PII), sähköisen kaupankäynnin tapahtumia tai alan säänneltyjä tietoja, kuten HIPAA-tietoja, turvallisuuden ja vaatimustenmukaisuuden tarkastusten mahdollistamiseksi.
  • Anna palautetta tuotteen omistajalle ja tiimille. Tarinan merkitsemisen lisäksi tehty, tuotteen omistaja voisi myös antaa palautetta tiimille, kuten tunnustaa a hyvää työtä. Vastaavasti tiimi voi antaa palautetta tuotteen omistajalle käyttäjän tarinan yleisestä laadusta ja tulkittavuudesta.

7. Määritä ketterät tarinamallit ja tyylioppaat

Suuremmat organisaatiot, jotka työskentelevät useiden ketterien ryhmien ja tuotteiden omistajien kanssa, saattavat haluta laatia standardeja ja tyylioppaita tarinan kirjoittamiseen. Johdonmukaisuus auttaa uusien tuotteiden omistajia oppimaan kirjoitustaidot nopeammin ja parantaa myös tiimin jäsenten tehokkuutta tiedon kulutuksessa.

Toinen syy tarinamallien suunnitteluun on, että erityyppiset tuotteet ja sovellukset soveltuvat erilaisiin käyttäjäkertomusten ilmaisuihin ja artefakteihin. Joitain esimerkkejä:

  • Liiketoimintaprosessitarinat saattavat edellyttää linkkejä työnkulun kaavioihin ja myös määrittää roolit ja käyttöoikeudet.
  • Asiakkaan suuntaisissa sovellustarinoissa tulisi olla linkit lankakehyksiin ja niiden tulisi sisältää suorituskykykriteerit.
  • API-tarinoiden tulisi dokumentoida odotetut käyttötavat ja mittarit.
  • Liiketoimintatiedon ja tietojen visualisointitarinoiden tulisi antaa ohjeet siitä, mitä kenttiä ja tietoja tarvitaan pyydettyyn analyysiin.

Mallit auttavat yhdistämään tiimien ja tuotteiden omistajien välisen viestinnän siihen, mihin on keskityttävä kirjoitettaessa ketteriä tarinoita.

Eikö se ole ketterien tarinoiden kohta? Ketterät tarinankirjoittamiskäytännöt, ohjeet ja periaatteet auttavat tiimejä tietämään, mikä on tärkeää käyttäjille ja yritykselle, ennen kuin harkitsevat toteutusta.

$config[zx-auto] not found$config[zx-overlay] not found