Blog de Marcial.Atiénzar

  ¿Qué busco transmitir? En muchas lecturas encuentras todo tipo de información sobre la definición de Historias de Usuario: Las 3 C's: Card, Conversation y Confirmation Definición de READY Modelo INVEST para ayudar a la descomposición en historias más pequeñas Definición de DONE (DoD) Specification by example ... En este post, lo que busco no es centrarnos en la definición de DONE, sino en qué opciones tenemos para comprobar que realmente una Historia de Usuario la podemos marcar como DONE. Algunas referencias antes de meternos en materia Algunas referencias, independientemente del orden de importancia o que aporten más o menos, serían estas: En scrum.org encontramos este artículo: https://www.scrum.org/resources/blog/definicion-de-terminado-done En proyectosagiles.org encontramos este artículo: https://proyectosagiles.org/definicion-de-hecho-definition-of-done/ . En él se profundiza mucho más y te da una visión más clara. Jerónimo Palacios nos hace también

Estimación de historias Actualmente existen varias tendencias a la hora de estimar historias, entre ellas la de no estimar o la de estimar en tiempo o en complejidad, como Javier Garzás nos muestra en varios de sus posts: https://www.javiergarzas.com/2019/07/agilidad-viejuna.html https://www.javiergarzas.com/2019/04/no-estimar-noestimates-en-el-mundo-real.html https://www.javiergarzas.com/2018/03/puntos-historia-horas-o-complejidad.html En mi caso os voy a contar mi experiencia, empezando con un equipo acostumbrado a un modelo waterfall o a un modelo basado en ejecución de tareas simple. Paso 1. Introducir al equipo en metodologías ágiles Es muy imporante que el equipo antes de empezar en este mundo sepa de qué estamos hablando, entienda la filosofía detrás de los principios y valores que hay detrás de Agile. Luego con el tiempo, irá definiendo sus propios valores y principios, pero sin dejar a un lado los ya adquiridos como base de Agile. Se trata de una paso important