https://www.storyboardthat.com/ro/articles/b/agil-user-povestiri

Definirea poveștilor utilizatorilor și dezvoltarea agilă

Utilizați scenarii pentru a explica procesele și interacțiunea cu clienții

Un principiu central al proceselor moderne de dezvoltare este dezvoltarea agilă . Această metodologie de dezvoltare subliniază utilizarea poveștilor de mici dimensiuni ale utilizatorilor pentru a defini ceea ce face un sistem din perspectiva utilizatorului, nu una tehnică. Unui utilizator îi pasă dacă un produs este rapid, ușor de utilizat și își rezolvă problema. Nu le pasă dacă urmează o arhitectură pe 3 niveluri, dacă are Mongo DB sau dacă folosește Rails sau Asp.net.

Povești de utilizatori:

  • Sunt ușor de înțeles și oricine poate participa
  • Lucrați iterativ; ele pot și trebuie schimbate sau modificate frecvent
  • Aliniați dezvoltatorii, utilizatorii și specialiștii în afaceri în jurul obiectivelor și așteptărilor comune
  • Sunt mult mai ușor de citit decât documentele de cerere de 400 de pagini

Storyboard That oferă o platformă ideală pentru a crea povești agile ale utilizatorilor și a declanșa conversații într-un format mult mai puțin impozabil decât un perete de text.


Epic

În contextul poveștilor utilizatorilor, o „epopee” este pur și simplu o poveste foarte largă care va fi împărțită mai târziu în multe povești specifice utilizatorilor. Începând cu o epopee aliniază toată lumea cu o singură viziune la nivel înalt. Povestea epică ancorează un proiect de sus în jos și, dacă nu are sens să construiești o epopee, munca de sprijin va fi, de asemenea, o risipă de efort.

Customer Care Generic Epic

Creați o Poveste de Utilizator Agilă*

În această poveste, este foarte clar care este viziunea pe termen lung și cum ar trebui să arate succesul. O poveste epică bună ar trebui să includă:


  • Setare sau context
  • Actori sau utilizatori
  • Teluri si obiective
  • Activități și evenimente

Definirea utilizatorilor

Mai ales atunci când proiectați software, este important să aveți o viziune bună despre cum vor fi utilizatorii. Nu fiecare utilizator se va potrivi cu această viziune cu precizie și pot exista mai multe categorii de utilizatori, dar aceste viziuni discrete necesită articulare. Gândindu-vă la utilizatori, mai întâi protejează împotriva ingineriei excesive și a excesului de complicații, împiedicând un nou produs să aibă ceva pentru toată lumea și să nu fie util nimănui.

Acme Corp. Users

Creați o Poveste de Utilizator Agilă*

Crearea unei povesti

Odată ce a fost stabilită o epopee și utilizatorii au fost definiți, se pot construi povești mai mici și mai specifice despre anumite experiențe ale utilizatorilor. Poveștile de mai jos descompun cele prezentate mai sus în două narațiuni: căutarea unei comenzi și reordonarea unui produs.

Aceste narațiuni nu conțin informații tehnice; utilizatorilor nu le pasă cum se obțin rezultatele, atâta timp cât îndeplinește sarcinile dorite. În mod similar, UX este descris generic, pentru a evita sufocarea inovației sau forțarea unei căi. În general, poveștile ar trebui să fie:

  • Mic - Sub 10 zile de muncă
  • Valoroase - Odată finalizate, acestea ar trebui să livreze ceva utilizabil
  • Estimabil - Capabil să creeze o estimare de parcare a cât de mult efort este implicat

Căutând o comandă

Acme Corp. - Looking up an Order

Creați o Poveste de Utilizator Agilă*

Efectuarea unei Reordonări

Acme Corp. Replacement Order

Creați o Poveste de Utilizator Agilă*

Conversație și planificare pentru testare

Aceste povești ar trebui să invite conversații și întrebări, cum ar fi:

  • Sunt acestea poveștile potrivite care se potrivesc cu epopeea noastră?
  • Ce alte povești ar trebui create?
  • Sunt aceste povești în concordanță cu ceea ce știm despre utilizatorii noștri?

Este perfect rezonabil să creezi multe povești; de fapt, ar trebui încurajat. Unele dintre aceste povești nu vor fi folosite niciodată, dar este important să vedem calea pe care au stabilit-o. Această colecție de povești va elimina cerințele suplimentare și va influența testarea.

Poveștile ar trebui să provoace și să informeze discuțiile despre modul în care software-ul va fi testat și ce reguli de afaceri trebuie definite în mod explicit. De exemplu:

  • Cât de rapid trebuie să fie o căutare?
  • Există o limită de timp pentru re-comenzi?
  • Ce ar trebui să facă sistemul dacă este a doua comandă? A cincea?
  • Ce teste și întrebări de urmărire ați avea?


Check out Storyboard That 's ilustrată Ghid pentru Dezvoltare Produs pe Client Journey Mapping!
*(Acest lucru va incepe un test gratuit de 2 saptamani - nu este nevoie de card de credit)
https://www.storyboardthat.com/ro/articles/b/agil-user-povestiri
© 2024 - Clever Prototypes, LLC - Toate drepturile rezervate.
StoryboardThat este o marcă comercială a Clever Prototypes , LLC și înregistrată la Oficiul de brevete și mărci comerciale din SUA