Académique Documents
Professionnel Documents
Culture Documents
Para qu sirven?
El objetivo de escribir user stories es determinar quin, qu ypara qu se utilizar cada funcionalidad.Son escuet
en su contenido porque dan la posibilidad de colaborar y construir iterativamenteentre los miembros del equipo, co
el cliente y usuarios nales, al recibir feedback.
Comparando con las metodologas tradicionales, en los casos de uso del Proceso Unicado, por ejemplo, hacamo
hincapi a las especicaciones del diseo de software para que pudieran codicarse como parte de una actividad d
sistema; en cambio a las historias de usuario las utilizamos para estimar y planicar, ocasin en la qu
aprovechamos para conversar en ms profundidad sobre sus particularidadesdentro del sistema, ytenemos desde
comienzo una pauta sobre cmo probarlas, con el criterio de aceptacin.
Por s solo el post it o tarjeta no tiene validez si no es corroborada y construida en cooperacin como equipo
Una user story sigue laforma:
http://agilecoaching.com.ar/comoescribirunahistoriadeusuarioen5pasos/ 1/6
30/12/2016 Cmoescribirunahistoriadeusuarioen5pasosAgileCoaching
Ejemplo de user story para crear un calendario de pago de expensas, en una aplicacin para la
administracinde edicios.
http://agilecoaching.com.ar/comoescribirunahistoriadeusuarioen5pasos/ 2/6
30/12/2016 Cmoescribirunahistoriadeusuarioen5pasosAgileCoaching
Es posible que descubramos que no todos los usuarios se sientan cmodos empleandoel software que originalmen
pensamos, yhaya que adaptarlo a sus gustos particulares. Con el feedback que recibimos puede que tengamos qu
cambiar algunas condiciones de entrada, luego de que los usuarios lo prueben.
La parte ms difcil de reunir los requerimientos no es el acto de anotar lo que el cliente quiere,
es la actividad exploratoria e incremental de ayudar a otros a darse cuenta de qu quieren.
Steve McConnell
3. Para qu
http://agilecoaching.com.ar/comoescribirunahistoriadeusuarioen5pasos/ 3/6
30/12/2016 Cmoescribirunahistoriadeusuarioen5pasosAgileCoaching
Es importante denir un contexto para que exista la historia que estamos creando, porque nos ayudar a entender
valor que estaremos aportando, su objetivo de construccin, y nos da la posibilidad de explorar otras alternativ
para llegar al mismo n.
Nuevamente, a diferencia de los casos de uso, en donde estaban completamente escritos los pasos a seguir pa
llegar al objetivo, aqu podemos adoptar diferentes caminos, porque a medida que progresamos se harn m
claros para el equipo los gustos y deseos del cliente.
4. Resultados esperados
El criterio de aceptacin nos dice exactamente qu salidas obtendremos cuando nalice el proceso de ejecucin d
la funcionalidad, y nos sirve para vericar que est terminada la funcionalidad (DOD). Esta condicin es
directamente relacionada con las pruebas que realizaremos para vericar que cumplimos con la expectativa d
diseo, usabilidad,rendimiento, y principalmente la satisfaccin de su necesidad.
Hay varias maneras de escribir el criterio de aceptacin: incluyendo puntos a vericar (como en el ejemplo
pequeospasos para llegar a estos resultados, descripcin breve del proceso, bosquejo sencillo, o laforma (til pa
la automatizacin de pruebas):
Dado que <condicin> Cuando <causa> Entonces <efecto>.
En los resultados esperados podemos tener mock-ups, wireframes o prototipos, dibujos a mano alzada ydiagram
de las interfaces que esperamos construir. No es necesario que sea algo complejo, con que pueda entenderse y
partir de all construir la solucin es suciente (en caso de no requerirse documentacin especca por parte d
cliente).
5. Comentarios
Como dijimos, las user stories facilitan laconversacin permanente con el cliente para vericar que lo que estamo
construyendo est de acuerdo a sus expectativas en cuando a funcionamiento del sistema. Esta discusin
negociacin se va registrando segn se necesite como comentarios, notas adicionalesa tener en cuenta a la hora d
llevarlo a cdigo/diseo/pruebas. Esta forma de trabajo nos ayuda a colaborar y mantener una comunciacin uid
con los miembros del equipo, ya que la historia va cambiando durante la marcha de la iteracin y progresivamente
va elaborando en conjunto.
About LatestPosts
Carolina Gorosito
Agile Coach, trainer & consultant at Agile Coaching
1 Ms
Me gusta:
Megusta
Selprimeroendecirquetegusta.
Relacionado
Cmo priorizar las actividades de Tengo las habilidades para ser un Cmo priorizar las actividades de
un proyecto - Parte 1 tester gil? un proyecto - Parte 3
8 abril, 2015 3 julio, 2015 24 abril, 2015
En "Blog" En "Blog" En "Blog"
This entry was posted in Blog and tagged gil, criterio de aceptacin, historia de usuario, requerimiento, requisito
story. Bookmark the permalink.
Addacomment...
FacebookCommentsPlugin
Translate
ENLACES TILES CREATIVE COMMONS SUSCRBETE A MI
LICENSE BOLETN
Guas de Scrum en varios idiomas
Correo Electrnico *
Presentaciones en Slideshare
http://agilecoaching.com.ar/comoescribirunahistoriadeusuarioen5pasos/ 5/6
30/12/2016 Cmoescribirunahistoriadeusuarioen5pasosAgileCoaching
Tecnoday_
SocialMediaIconsPoweredbyAcuraxWebsiteDesigningCompany
Translate
http://agilecoaching.com.ar/comoescribirunahistoriadeusuarioen5pasos/ 6/6