¿No estaría bueno si, una vez que termináramos una historia, nunca tuviéramos que volver a agarrarla? Esta es la idea detrás del "terminado terminado". Una historia no es un desparramo de código sin integrar, sin probar. La historia debe estar lista para ser desplegada.
Las historias parcialmente terminadas generan costos ocultos al proyecto. Cuando llega el momento de entregar, debemos completar una cantidad indeterminada de trabajo. Esto desestabiliza los esfuerzos de planificación de las entregas, y nos impide cumplir nuestros compromisos.
[inset side="right" title="Terminado Terminado"]Debemos poder desplegar el software en producción al final de cada iteración.[/inset]
Para evitar este problema, debemos asegurarnos que todas nuestras historias planificadas estén "terminadas terminadas" al final de cada iteración. Debemos ser capaces de desplegar el software al final de cualquier iteración, aunque normalmente se espere a juntar un grupo de características.
¿Qué se necesita para que el software esté "terminado terminado"? Esto depende de la organización. En general una historia sólo está completa cuando el cliente puede usarla como esperaba. Pueden crear una lista de muestre el criterio de completitud de una historia (conocido como Definición de Terminado en Scrum). Por ejemplo:
- Probada (están terminadas todas las pruebas unitarias, de integración y de aceptación del cliente)
- Codificada (todo el código está escrito)
- Diseñada (el código tiene los refactors necesarios para la satisfacción del equipo)
- Integrada (la historia funciona de punta a punta - usualmente, desde el UI hasta la base de datos - y funciona con el resto del software)
- Construcción (los scripts de construcción incluyen cualquier módulo nuevo)
- Instalable (los scripts de construcción incluye a la historia en el instalador automatizado)
- Migración (los scripts de construcción actualizan la base de datos si es necesario; el instalador migra los datos cuando sea apropiado)
- Revisada (los clientes revisaron la historia y confirmaron que cumple sus expectativas)
- Corregida (se arreglaron todos los bugs conocidos, o se planificaron como historias propias)
- Aceptada (el cliente confirma que la historia está finalizada)
Algunos equipos agregan "Documentada" a la lista, queriendo decir que la historia cuenta con la documentación y textos de ayuda.
Otros equipos incluyen "Rendimiento" y "Escalabilidad" en su lista de "terminado terminado", pero esto podría ocasionar optimizaciones prematuras. Prefiero planificar el rendimiento, la escalabilidad y temas similares como historias propias.
Cómo llegar al "terminado terminado"
Extreme Programming funciona mejor cuando hacemos pequeños avances en cada aspecto del software todos los días, en vez de reservar los últimos días de la iteración para que las historias estén "terminadas terminadas". Una vez que te acostumbrás resulta ser la forma más fácil de trabajar, y disminuye el riesgo de encontrarnos con trabajo sin terminar al final de la iteración.
[inset side="right" title="Pasos pequeños"]Avanza un poquito en todos los aspectos, todos los días.[/inset]
Utilizá el Desarrollo Guiado por Pruebas (TDD) para combinar el testing, la codificación y el diseño. Cuando trabajes en una tarea técnica, asegurate que se integre con el código existente. Utilizá la integración continua y mantené al proyecto integrado cada 10 minutos. Creá una tarea técnica para actualizar el instalador y hacé que una pareja esté trabajando en paralelo junto a las otras tareas de la historia.
Igual de importante es incluir al cliente en tu trabajo. Mientras estás trabajando en tareas de interfaz gráfica, mostrale al cliente cómo se ve la pantalla, aunque todavía no funcione. Los clientes suelen querer hacer arreglos y modificaciones a la interfaz cuando la ven por primera vez. Esto puede llevar muchísimo tiempo si demoramos las demos para la última iteración.
De manera similar, a medida que integramos varias piezas, debemos ejecutar el software para que funcione todo junto. Aunque esto no debería reemplazar al testing, es una buena comprobación que ayuda a que nos olvidemos de algo. Pidamos la ayuda a los testers para que nos enseñen distintas técnicas exploratorias para las pruebas (nuevamente, esta revisión no reemplaza al testing exploratorio real).
A lo largo de todo el proceso podemos encontrar errores, equivocaciones y bugs. Cuando los encontremos, debemos arreglarnos inmediatamente - y luego mejorar nuestra forma de trabajo para prevenir que este tipo de error vuelva a ocurrir.
Cuando creemos que una historia está "terminada terminada", enseñémosla a los clientes para su aceptación final. Como estuvimos revisando el progreso junto al cliente durante toda la iteración, esto debería tomar unos pocos minutos.
Hacer tiempo
Todo esto podría parecer una imposible cantidad de trabajo para hacer en una semana. Es más fácil de hacer si lo vamos trabajando durante toda la iteración, en vez de dejarlo para los últimos dos días. Sin embargo, el secreto real es hacer que las historias sean lo suficientemente pequeñas como para poder terminarlas en una semana.
Muchos equipos nuevos de XP crean historias demasiado grandes como para poder "terminar terminar". Terminan toda la codificación, pero no les queda tiempo para completar la historia - quizás la interfaz no esté muy prolija, o aparezca algún bug raro.
Recordá, vos controlás la planificación. Vos decidís cuántas historias comprometer, y qué tan grande son. Dividí una historia grande en muchas pequeñas, y trabajá en una sola pieza por iteración.
Es un error común crear historias grandes, pero algunos equipos empeoran el problema pensando "bueno, en realidad terminamos la historia, excepto por ese pequeño bug". Se dan a si mismos crédito por la historia, lo cual aumenta su velocidad y perpetúa el problema.
[inset side="derecha" title="velocidad"]Si una historia no está "terminada terminada", entonces no cuenta para la velocidad.[/inset]
Si tenés problemas en que tus historias estén "terminadas terminadas", no las cuentes para tu velocidad. Incluso aunque tu historia tenga sólo un bug menor, la tenés que contar como "cero" al calcular la velocidad. Esto va a disminuir la velocidad, lo cual te ayudará a elegir una cantidad de trabajo más manejable para la próxima iteración.
Quizás te ocurra que hacer esto disminuya tu velocidad tanto que sólo puedas planificar una o dos historias para la iteración. Esto significa que las historias son muy grandes. Dividí estas historias, y trabajá para que las historias futuras sean más pequeñas.
Preguntas
¿Cómo encaja el rol del tester con "terminado terminado"?
Además de ayudar a los clientes y a los programadores, los testers son responsables por las pruebas no funcionales y el testing exploratorio. Usualmente hacen esto después de que las historias están "terminadas terminadas". Sin embargo, pueden realizar algunas pruebas no funcionales, en el contexto de una historia de rendimiento específica.
Más allá de esto, los testers son parte del equipo, y todos en el equipo son responsables en ayudar a que el equipo cumpla su compromiso de entregar historias "terminadas terminadas" al final de la iteración. En la práctica, esto suele significar que los testers ayudan al cliente con las pruebas del cliente, y pueden ayudar a los programadores y al cliente a revisar el trabajo en progreso.
¿Qué pasa si entregamos una historia que pensamos está "terminada terminada", pero encontramos un bug, o los usuarios nos dice que quieren cambios?
Este tipo de feedback es normal, debemos esperarlo. El gerente del producto debe decidir si los cambios son apropiados, y si lo son, debe modificarse el plan de entregas. Si constantemente nos sorprenden los cambios de los usuarios, habría que analizar si el cliente que los representa realmente refleja la comunidad de usuarios.
Resultados
Cuando las historias están "terminadas terminadas" evitamos apuros inesperados de trabajo, y distribuimos las tares para pulir las historias a lo largo de toda la iteración. Los clientes y los testers tienen una carga constante de trabajo durante la iteración. La aceptación final del cliente sólo dura unos minutos. Al final de cada iteración, el software está listo para demostrarlo a los usuarios, con las historias planificadas funcionando correctamente.
Contraindicaciones
Aunque esta práctica puede parecer muy avanzada, no lo es. Lo que si necesita es mucha auto-disciplina. Para poder estar "terminado terminado" cada semana, también debemos trabajar en interaciones y usar historias pequeñas centradas en el cliente.
Además, necesitamos un equipo completo - un equipo que incluye al cliente y a los testers, además de los programadores. El equipo completo se sienta junto. Si no están juntos, los programadores no podrán obtener el feedback que necesitan para terminar las historias a tiempo.
Por último, se necesita hacer un diseño y arquitectura incremental, y usar desarrollo guiado por pruebas, para poder probar, codificar, y diseñar cada historia dentro de un marco de tiempo tan pequeño.
Alternativas
La práctica de "terminado terminado" es fundamental en la planificación de Extreme Programming. Si no estamos "terminados terminados" al final de cada iteración, nuestra velocidad no va a ser confiable. No vamos a poder entregar en cualquier momento. Esto va a alterar la planificación y nos impedirá cumplir el compromiso, que a su vez dañará nuestra confianza con el cliente. Además es probable que genere más estrés y presión al equipo, dañe la moral, y dañe la capacidad del equipo de trabajar con entusiasmo.
La alternativa al "terminado terminado" es llenar el final de la planificación con trabajo inventado. Vamos a terminar con una cantidad incierta de trabajo para arreglar bugs, pulir la interfaz, crear un instalador, y así. Aunque muchos equipos operan de esta manera, va a dañar nuestra credibilidad para realizar entregas. No lo recomiendo.
