User Stories
Una historia de usuario (User Story) describe funcionalidad valiosa para el usuario, equivale a un requerimiento funcional. Las historias de usuarios se redactan desde el punto de vista del usuario final, en un lenguaje simple, permiten que clientes y desarrolladores puedan acordar el trabajo conjunto a realizar de una manera efectiva.
¿Qué debe poseer una buena historia de usuario?
· Interacción con el cliente: Se deben obtener de las reuniones realizadas con el cliente.
· Definición: Las historias deben de ser claras, redactadas en un formato entendible por el usuario, para evitar confusiones. Debe capturar la esencia y no los detalles.
· Valoración: Deben de poder priorizarse por el usuario.
· Confirmación: Los clientes deben contribuir a validarlas, indicando de qué manera las probarían para aceptar el desarrollo realizado, mediante los tests de aceptación.
Sigla 'INVEST' Para las User Stories
I-Independent: Es deseable que las historias no se solapen conceptualmente, permitiendo que se puedan desarrollar independientemente una de otra.
N-Negotiable: No se considera a una historia de usuario como contrato, ya que la misma no es lo suficientemente detallada, no obstante su definición alcanzará para que pueda ser estimada y planificada. La comunicación con el cliente permitirá luego delimitar su alcance y obtener su detalle. Una historia de usuario puede cambiar a lo largo del proyecto de desarrollo, por lo que se negociará con el cliente hasta lograr la funcionalidad definitiva.
V-Valuable: La historia de usuario debe tener valor para el cliente. El equipo debe lograr que el cliente perciba el valor en los casos en que el mismo proviene de otros aspectos que no son apreciables “a simple vista” (por ejemplo aspectos técnicos específicos de arquitectura).
E-Estimable: Una buena historia puede ser estimada. No es necesario que sea de manera exacta, sino lo suficiente para que ayude al cliente a priorizar y planificar su implementación. La condición de estimable está relacionada con su condición de negociable, puesto que es difícil estimar historias que no se comprenden. Cuanto más grande se la historia o menos se entienda, más inexacta será su estimación. La experiencia del equipo influirá considerablemente en obtener mejores estimaciones conforme avance el proyecto.
S-Small: Una historia de usuario representa idealmente unos pocos días de desarrollo. Una historia grande deberá subdividirse en otras más pequeñas (Split). Frases como “me llevará más de un mes” deben alertar al equipo de que no se conoce cuál es el alcance de la historia o bien que no se entiende su total implicancia.
T-Testable: Toda historia de usuario (y requerimiento no funcional) debe de poder testearse. El hecho de contar con tests en forma temprana ayuda a los desarrolladores a verificar la exactitud del requerimiento y las necesidades reales. El mismo usuario colaborará con el equipo si sabe y comunica cómo probar la historia, evidenciando en caso contrario que la historia no está clara o que no refleja suficiente valor.
Tareas
Toda Historia de Usuario refleja lo que el cliente desea, pero no refleja lo que el equipo debe de considerar para su desarrollo. Al equipo le corresponde evaluar cada historia y descomponerla en tareas que desarrollo, y así asumir con confianza el compromiso de completarlas en la iteración acordada.
Sigla 'SMART' Para las tareas
S- Specific: Una tarea necesita ser específica de manera que cualquiera puede entender de qué se trata. Esto ayuda tanto a comprender la tarea como parte de un total.
M-Measurable: Que la tarea pueda medirse significa que se pueda marcar como “hecha”. El alcance de este término puede ser acordado dentro del equipo y con el cliente, aunque necesariamente implica cumplir que se haga lo que se propuso, con los test incluidos y el código refactorizado.
A-Achievable: Las tareas deben ser “logrables”, para lo cual todo miembro del equipo puede pedir ayuda cada vez que lo necesite para garantizar el cumplimiento.
R-Relevant: Cada tarea tiene sentido para el desarrollador, pero además es necesario poder explicar y justificar ante el cliente la misma cada vez que lo requiera.
T-Time boxed: Cada tarea debe tener una duración acotada (ideal un día…), no necesariamente formal pero que sí contribuya a anticipar la necesidad de ayuda cuando la tarea es más compleja que lo esperado.
Viviana Chelini y Leticia Medela
Fuente: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/