User Stories: El proceso de las 3 C’s de Ron Jeffries

por Publicado el

Ron Jeffries en el libro Extreme Programing Installed describe el mejor proceso de trabajo de historias de usuario mediante 3 pasos (3 C’s) Card, Conversation, Confirmation. El propósito es compartir el conocimiento y llegar a un entendimiento compartido del problema y de la solución del mismo por parte de todos los involucrados en el proyecto. A continuación te lo explico.

Paso 1: Card. Escribe lo que te gustaría ver en el software.

Las tarjetas son la unidad básica de construcción en las historias de usuario. Al inicio del diseño de tu proyecto debes de escribir un montón de tarjetas indexadas que representen todas las actividades que tendrán los usuarios con tu sistema. Las tarjetas deben tener un sistema de índices que te sirva para referenciar la actividad general con los detalles que la componen, es imposible documentar toda la información necesaria en una pequeña etiqueta adherible. Las tarjetas van a mostrar la fotografía completa del trabajo que debe, puede, podría o debería hacerse. Cuando tengas todas las tarjetas posibles en una superficie como una mesa o un pizarrón, puedes organizarlas para crear estructuras de pensamiento que se adecuen a las necesidades del proyecto. Puedes organizar las tareas por valor, riesgo, falta de conocimiento o cualquier necesidad que tengas en la construcción del proyecto. Todas las actividades resultantes de este mapeo son el backlog.

Paso 2: Conversation: Junta a todos los involucrados y hablen acerca del software que se va a construir.

Las tarjetas de actividades y el backlog no son el fin del proyecto, son el medio que permite empezar la conversación acerca de que vas a construir. La conversación puede comenzar acerca de que estás pensando, las otras personas se van a formar una idea en su cabeza que puede coincidir o no con tu idea. Es difícil explicar tus ideas debido a que cada persona se puede formar una imagen distinta a partir de la misma información. Obvio, van a surgir diferencias de visión, puede que tu entendimiento del problema no sea adecuado, al comunicar tus ideas alguien te corrija y te clarifique tus pensamientos. Los demás harán preguntas acerca de tus ideas y tu harás lo mismo, el propósito de la conversación es construir conocimiento compartido. Si todos tenemos la misma visión del problema y de la solución, entonces podemos tomar decisiones eficientemente. No es un camino fácil el entendimiento compartido, pero es necesario para asegurar que estás aportando valor con lo que estás construyendo.

Tu meta no debe ser construir un requerimiento correctamente, tampoco debe ser expresar tus ideas, y solo tus ideas en un documento. La verdadera meta a la que debes de llegar es:

Debes de trabajar en conjunto con todos los involucrados para entender el problema que se resolverá con la construcción del software y después resolverlo de la mejor forma posible de acuerdo a las posibilidades de tu equipo.

Paso 3: Confirmation: Juntos todos los involucrados lleguen a un acuerdo de como el software va a ser hecho.

Discutir sobre lo que vas a construir con tu equipo está bien, pero eventualmente van a tener que construir algo, ¿verdad?. Cuando llegues a un consenso con tu equipo vas a tener que responder la siguiente pregunta:

Si todos estamos de acuerdo en construir esto, entonces. ¿Qué confirmará que esto está hecho?.

La definición de hecho es usualmente una lista corta de cosas a revisar, esta lista se conoce como criterio de aceptación o story tests.

Cuando llegue el momento de demostrar esto después. ¿Cómo lo haremos?

Responder esta pregunta puede evidenciar agujeros en tus criterios de aceptación. Dependiendo del desarrollo puede ser fácil o difícil de demostrar lo que construyes.

Registra los acuerdos y conclusiones del equipo.

No basta con solo llegar a un acuerdo entre todos, es necesario registrar las actividades, la documentación y los criterios de aceptación en un medio persistente. Puede ser un correo electrónico,  hojas de papel, dentro del tablero mismo. El objetivo es que todo el trabajo realizado en torno a tus historias de usuario no se pierda.

Bibliografía: User Story Mapping

Bibliografía: Extreme Programming Installed

 

Autor imagen: Lars Plougmann

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.