The Agile Micro-management

STOP

Uzi Mamani (@uzigula) Aspirante a Software Craftsmanship

Lead Developer en Belatrix Software

Aspirante a Sherpa en Leansight.

Por qué este título?

Todo empieza bonito, cuando llegas a un equipo y te dicen vamos hacerlo ágilmente

Pero después del primer sprint o incluso antes!!!

Necesito saber que están haciendo, debemos tener un trackeo de todas las actividades, esto es super importante para las métricas del proyecto…

Pues bien, que como lo hacemos?

Necesito saber cuanto tiempo le dedican a cada Historia de usuario y tarea, así podremos saber en el futuro cuando terminaremos y/o cuantas historias de usuario podemos hacer en cada sprint…

Ok…

Dividamos las Historias por Capas (front-end, Backend, Repositorio/Base De datos)

Esta bueno pero necesitamos ver avance en el burndown chart ¿Pueden hacer mas granulares las tareas?

Por la naturaleza de la tarea Desarrollo, Test, Análisis, Diseño, etc…

Umh… Por directiva, Control, Vista, Procedimiento, Clase, Componente, ….

Ahora si podemos ver como avanzamos día a día XD

Consecuencias

Terminamos con Historias incompletas

http://img0.gtsstatic.com/wallpapers/ecfeb91e3493be5d8cba5beb12799373_large.jpeg

No fomenta la auto-organización

No Autonomía, No Maestría, No Propósito

Nos llevan a medir las cosas incorrectas

Al final ….

http://wp.patheos.com.s3.amazonaws.com/blogs/nakedpastor/files/2011/07/micro-manager.jpg

¿Cómo podemos mejorar esto?

Customers don't measure you on how hard you tried. They measure you on what you deliver.

Empieza a medir valor

Impact Mapping Gojko Adzic

Empieza a medir valor

User Story Mapping Jeff Patton

Olvídate de las Tareas

Olvidarme de las Tareas

Si, olvídate de ellas

Huuhhh??

Apóyate y Adopta BDD

BDD no es testing, es descubrimiento de valor

BDD In Action John Fergusson

BDD usa conversaciones alrededor de los ejemplos, en un formato que reduce la pérdida de información y malos entendidos

Proyectos exitosos deben construir las características correctas, correctamente.

BDD In Action John Fergusson

Specification by Example Gojko Adzic

Ósea que….

Historia de Usuario 1

Criterio de Aceptación 1

Criterio de Aceptación 2

Criterio de Aceptación 3

Ejemplo(1,1)

Ejemplo(1,2)

Ejemplo(1,3)

Ejemplo(2,1)

Ejemplo(2,2)

Ejemplo(3,1)

Ejemplo(3,2)

Estructura de una Historia de Usuario

Podemos utilizar los criterios de Aceptación como unidad para dividir

las Historias de Usuario

Puedes poner cuantos criterios de aceptación tengan tus Historias de

usuario, en tu tablero de tareas o en la herramienta que uses.

La Unidad de progreso será ahora “criterio de aceptación aceptado”

Ummh

@Uzi Mamani Fernández

Historia de Usuario 1

Criterio de Aceptación 1

Criterio de Aceptación 2

Criterio de Aceptación 3

Historias Pendiente En construcción Terminado

Historia de Usuario 2

Criterio de Aceptación 1

Criterio de Aceptación 2

Criterio de Aceptación 3

#%*+?

Si PO o el Management necesitan un nivel mas de detalle, podrías poner los ejemplos

Beneficios

Obtener funcionalidad completa al final de la Iteración

Al tener los escenarios y ejemplos puedes aprender cuales son los que realmente son importantes de implementar y cuales podrías dejar, sin perder la funcionalidad esperada.

Tener tus Historias de Usuario Validadas / Verificadas desde el principio

Facilitará la adopción tácticas y técnicas de XP

Integración y Entrega Continua

Y Claro si aún necesitas métricas Obtendrás reportes de avance reales

Dificultades

Convencer al Management, cambiar el chip

Example Mapping

Domain Drive Design

No existen balas de Plata

@Uzi Mamani Fernández

The Agile Micro-management

STOP