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/

Flexibilidad como opuesto a rigidez, agilidad como enemigo de proceso, gestión adaptativa versus gestión predictiva, cumplir el plan o responder al cambio. Estas opciones evolucionan como búsqueda de mejora a resultados poco satisfactorios (ya lo estudia estadísticamente Standish Group desde hace años) para los proyectos de desarrollo de software.

Entre aferrarnos totalmente a lo establecido o innovar sin más, vale no perder de vista la ser realistas y considerar:

· Que la relación de procesos-tecnología-personas es la clave del éxito para obtener ventajas competitivas, aunque la proporción depende del tipo de producción y características de cada empresa, su cultura, misión y el tipo de proyectos que desarrolla.

· Que un cliente puede preferir ceñirse al triángulo “producto-fecha-costo planificados”, y no se encuentre preparado para adoptar una visión que proponga que “no existe el producto terminado, sino que el producto está en constante evolución”.

· Que el proyecto aplique sin problemas para la ejecución de un plan controlado. Puede no necesitar disponer de un producto en lo inmediato, contar con requisitos claros, detallados e inamovibles, por lo que no exista un escenario de incertidumbre. Que la innovación no sea el factor determinante para el proyecto.

· Que en cada situación se evaluará la relación costo /beneficio en función de los riesgos.

Y mientras tanto seguir discutiendo las siguientes premisas:

· Que a más documentos menos contacto con el producto real.

· Que a más adherencia a procesos menos lugar a creatividad e innovación.

· Que no siempre se verifica que “la forma más eficiente de desarrollar un trabajo es hacerlo bien a la primera”.

· Que productividad y calidad no se dan necesariamente de manera homogénea.

· Que pueden convivir en un mismo equipo personas del negocio con las de desarrollo y hacer de la comunicación directa una fortaleza.

· Que los procesos y la tecnología son dueños de los conocimientos explícitos pero que la innovación siempre estará en las personas.

Ser flexibles es poder ir incorporando cambios para mejorar, si adherimos a que “El cuestionamiento de lo conocido es el motor de la evolución del conocimiento”.

El documento http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf , es una interesante guía para la transición.