INVEST en User Stories y SMART Tasks

por leticia  23. febrero 2011

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/

Tags:

Gestión de Proyectos | Metodologías y Procesos

Testing con VSTS 2010 – Para ir calentando motores …

por Victor Passador  18. febrero 2011

Estamos preparando una serie de post dedicados a testing con VSTS 2010 en las diferentes variantes en que se presenta a lo largo del ciclo de vida de la aplicación, y para ir introduciendo el tema quisiera dejarles unos links para que tengan a mano.

Se trata del blog de Mathew Aniyan, PM de Microsoft. En su blog, Mathew ha estado publicando una serie de Tips relacionado a lo que se conoce como Coded UI Test (Pruebas programáticas de Interfaz de Usuario).

Al momento de publicar este post, llegó hasta el N° 8, posteado con fecha enero/2010. Esperamos que retome la iniciativa y siga publicando más trucos.

Pueden ver la serie de tips aquí.

Saludos !

Tags: , , ,

ALM | TFS | Visual Studio | Testing

ALM DAY 1 - Buenos Aires

por Alejandra Federico  11. febrero 2011

ALM Day 1 – Buenos Aires

 

El 2 de Marzo se realizará en el auditorio del MUG la primera jornada de ALM (Application Lifecycle Management), donde Vemn Sistemas participará como orador.

El evento es organizado por el MUG y Microsoft, donde el objetivo es exponer ante la comunidad técnica el uso de Team Foundation Server (TFS) 2010 como solución ALM para la integración de roles. Está dirigida a Analistas de negocios, Analistas Funcionales, Arquitectos, DBAs, Desarrolladores, Testers, etc.

 

Temario:

 

\      ¿Cómo cambiar la cultura de una organización? (Patricia Scalzone)           

\      Administración de Proyectos con TFS 2010 (Eric Delahaye)

\       Integración de proyectos de Base de Datos al desarrollo (Maximiliano Accotto)

\       Mejora de la calidad del software con manejo de versiones en TFS 2010 (Guadalupe Casuso – Juan Pablo Díaz)

\      QA & Testing (Victor Passador)

\      Administración de Requerimientos usando Sharepoint (Alan Sheinkman)

 

Es una jornada gratuita.

Más información e inscripción en MUG 

 

Tags:

ALM | Eventos | Gestión de Proyectos | Metodologías y Procesos | TFS

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML