Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta INVEST. Mostrar todas las entradas
Mostrando las entradas con la etiqueta INVEST. Mostrar todas las entradas

martes, abril 25, 2017

División de Características

Cómo dividir correctamente las Características de tu Próximo Incremento de Programa

Una de las actividades clave que ayudará a que tu programa SAFe® sea un éxito es la cuidadosa preparación de tus Características (Features) antes de tu siguiente planificación de Incremento de Programa (PI). Y una parte importante de esta preparación es dividir las Características específicas que sean demasiado grandes como para ser entregadas fácilmente dentro del Incremento de Programa.
En esta guía práctica descargable, la gente de Ivar Jacobson International comparte algunas de las experiencias de los autores, Ian Spence y Keith de Mendonca, en la división de Características. Y, en homenaje a Richard Lawrence y su popular póster de División de Historias, los autores también proporcionan también un póster complementario de División de Características para que la puedas utilizar en tu programa de SAFe. ¡Genial!
La guía también incluye algunos malos hábitos al dividir características, como dividir demasiado pronto, dividir por componentes de la solución u olvidar las pruebas.
Quise traducir esta guía y el póster porque los lineamientos expuestos allí aplican no solo a las Características a abordar en un PI de SAFe, sino que aplican en general a cualquier esfuerzo de desarrollo de producto donde haya historias grandes o épicas, esto es, todos.
La guía original en inglés la encuentran en www.ivarjacobson.com, más específicamente en: https://www.ivarjacobson.com/featureslice.
Para saber más de SAFe® pueden visitar el sitio oficial www.scaledagileframework.com
Y para ver un resumen muy bueno de los principales aspectos de este marco de trabajo para escalar, no puedo sino recomendarles estos dos artículos de mi gran amigo Johnny Ordoñez, quien tiene suma experiencia en el tema:
Inspirado por, y complementario a, “Cómo Dividir una Historia”, Richard Lawrence, www.agileforall.com. Traducción de Lucho Salazar, www.gazafatonarioit.com

Puedes descargar la guía haciendo clic aquí
Y el póster haciendo clic aquí
Déjame saber en el foro que piensan de la guía.

domingo, junio 26, 2016

¡El tamaño sí importa!


Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:


Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

Y este otro:

De historias de usuario, culturas y del arte de narrar historias


También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html