Realizado y Undone

Por Ken Schwaber y David Starr, Scrum.org

Enero de 2012

La entrega de un incremento finalizado es crucial para realizar correctamente el desarrollo del Software Agile.Mediante el uso de ejemplos reales y teóricos, los autores muestran la diferencia entre la percepción de “finalizado” y la realidad de “finalizado”, y cómo esto afecta el éxito de un proyecto.Mediante estos ejemplos, los autores muestran las herramientas y las estrategias que pueden ayudar a los equipos a empezar con una definición de finalizado que tenga sentido para ellos, así como los métodos que les ayudan a comunicar dependencias, estado y el significado de “finalizado”.

Se aplica a

Administración del ciclo de vida de la aplicación; Team Foundation Server

En este artículo:

Introduction
Pérdida de transparencia en la compañía de Ana
- Lo que la gente pensaba que sucedía
- Lo que sucedió realmente
- La lección
Deuda técnica en Nanomedtronics AZ
- Lo que la gente pensaba que sucedía
- Lo que sucedió realmente
- La lección
La deuda técnica aumenta con varios equipos
El plan de la versión en A Datum Corporation
- Lo que la gente pensaba que sucedía
- Lo que sucedió realmente
- La lección
Técnicas a gran escala para finalizar tareas
- Scrum de los Scrums
- Integración continua
Conclusión

Scrum es un marco de trabajo ágil, incremental e iterativo.Los equipos lo utilizan para entregar rápidamente incrementos de “terminado,” o funcionalidad de software potencialmente utilizable, en cada iteración o sprint.

“Listo” es una palabra simple, pero interpretada erróneamente en muchas ocasiones.Para mí, significa terminado, finalizado y completo.Finalizado indica que no hay nada que quede por hacer.Una tarea realizada es sencilla definir; sin embargo, un incremento finalizado sigue siendo uno de los requisitos fundamentales y más escurridizos del Scrum y de la agilidad.

La agilidad requiere ofrecer incrementos listos para su uso de software que funcione en cada Sprint.Aun así, la mayoría de los equipos de Scrum y ágiles generan incrementos incompletos, parcialmente realizados.Cuando se pregunta a un equipo de Scrum por qué los requisitos del trabajo pendiente del producto no se completaron totalmente en un sprint, los miembros del equipo responden a menudo “no teníamos tiempo”.

Este documento se ocupa de los problemas relacionados con los incrementos finalizados mediante ejemplos de casos prácticos auténticos procedentes de los primeros días de Scrum.Los nombres y ubicaciones de los implicados se han cambiado pero estoy seguro de que las personas se reconocerán a sí mismas y a su trabajo duro.Todos los sprints de este caso son una iteración mensual, a menos que se indique lo contrario.

Pérdida de transparencia en la compañía de Ana

Ana necesitaba automatizar la recepción en el departamento de cambios en títulos de propiedad.La compañía para la que trabajaba construía y explotaba los gasoductos de casi toda Norteamérica.Su departamento procesó y abonó los derechos de autor a las personas que poseían la tierra y pasó por ella.La información sobre los títulos de propiedad que recibía el departamento de Ana estaba en forma de copias impresas o documentos de cambio de propiedad.El volumen llegaba a ser abrumador, por lo que Ana deseaba automatizar el proceso de lectura de datos y de pago de derechos.

El equipo de desarrollo propuso que compilásemos el sistema de derechos de autor para Ana mediante Scrum.Gracias a esto, tendría un programa de software para inspeccionar cada mes.Ella también tenía el derecho de cambiar de opinión cada mes sobre lo que haría nuestro equipo a continuación.

Al final de tercer Sprint, teníamos una fuente de alguna de las provincias funcionando e integrada con datos más antiguos.Lo demostramos mediante una sencilla solución SQL.Ana estaba muy contenta porque la mayoría del trabajo pendiente del producto del personal era de esta provincia.

Ella quería que enseñáramos SQL a su personal para que pudieran empezar inmediatamente a utilizar el software que el equipo de desarrollo había entregado.

¿Qué quería decir con que deseaba utilizarlo?¡Seguramente, ella había confundido terminar con un Sprint con terminar con el software!

Se lo dijimos a Ana tan cuidadosamente como fue posible.Ella se puso lívida.“¿Qué quiere decir con que está listo?Vi el primer incremento, el segundo incremento y ahora quiero empezar a usarlo.Impleméntelo y enséñenos a usar SQL para que se podamos usarlo”.

Comenzamos a sentirnos incómodos.Le dijimos a Ana que sí, que estaba finalizado.Pero, no era ese tipo de tarea realizada.Se hizo para mostrárselo, pero hubo problemas que aún deben resolverse antes de que el software se pueda usar:

Algunos registros de entrada no se pudieron procesar.Necesitábamos una instalación para almacenarlos y administrarlos, en vez de tirarlos.
Varios de los campos de los registros de entrada parecían utilizarse para propósitos distintos de los documentados.¿Qué se debe hacer con ellos?
Los campos de la base de datos existente contenían punteros o información que parecían información de referencia.Esto estaba por toda la base de datos.
Cuando ejecutábamos fuentes entrantes y consultábamos la base de datos, el sistema se bloqueó varias veces.Parecía que los datos estaban dañados durante estos bloqueos.

Ana nos preguntó cuánto tiempo pasaría antes de que pudiéramos hacer que fuera su tipo de finalización, una finalización que se pudiera utilizar.Estimamos que eran necesarios otros dos sprint para poder utilizar los incrementos.Nos dijo que siguiéramos adelante y que lo tuviéramos listo para que lo utilizase su departamento.A continuación, me “pidió" que me reuniera con ella la mañana siguiente.

A la mañana siguiente Ana, su jefe y el director de desarrollo estaban allí.Se mostraron decepcionados por no encontrar la transparencia que yo había promocionado.Opinaban que yo debía haber tratado los problemas sin resolver de una manera diferente a simplemente registrarlos como errores.Estaban molestos porque el progreso que se reflejaba en los informes de evolución proporcionados a todo el mundo era incorrecto.

Después de la reunión, los pedidos en curso eran:

Investigue y corrija los cuatro errores.
Finalice e implemente los tres primeros incrementos de modo que el departamento de Ana pueda comenzar a usarlos.
Mejorar nuestras habilidades en ingeniería y automatización de pruebas de modo que nuestra definición de tarea realizada sea igual que la definición de Ana (uso inmediato por parte de la empresa).
Cambie la manera en que grabamos defectos de modo que el requisito no se considere finalizado a menos que se corrijan.

Nos dijeron que sería una buena oportunidad de aprendizaje, si todos aprendíamos nuestras lecciones.

Lo que la gente pensaba que sucedía

Cuando desarrollamos un plan de línea base para el sistema, representaba lo que Anna y las partes interesadas pensaban que sucedería.El equipo de desarrollo informó sobre el progreso y todo parecía indicar que la versión marchaba según lo previsto, y las personas creyeron el informe.

El equipo de desarrollo creía realmente que hacía lo correcto mostrando que el trabajo continuaba según lo indicado en el plan.

Lo que sucedió realmente

La velocidad es la medida y el registro histórico de la productividad por sprint de un equipo de desarrollo.La velocidad se mide en cada sprint y se utiliza para establecer patrones de productividad.

El equipo de desarrollo necesitaba una velocidad continua de 8 unidades completas de trabajo en cada Sprint para cumplir el plan.Cuando algo amenazaba reducir disminuir nuestra velocidad por debajo de 8, no terminábamos todo el trabajo en esos elementos.

Entregamos funcionalidad que funcionó bastante bien, pero que no estaba lo suficientemente completa para poderse utilizar o servir de base en el desarrollo.Nos propusimos mejorarlo posteriormente.Cuando volvimos para estimar el trabajo no realizado, esto agregó otras 14 unidades de trabajo.

Teniendo en cuenta lo complicadas que eran las fuentes iniciales de títulos, tuvimos que revisar la totalidad del plan para reflejar una programación de probablemente veinte meses.El departamento de Ana envía incrementos cada dos meses aproximadamente, habilitando fuentes nuevas.Las nuevas fuentes automatizadas redujeron el trabajo manual total de tal manera que fue decepcionante cuando el sistema se activó veintidós meses después de su inicio.

La lección

La transparencia real requiere que todas las personas que vean el incremento deben ver y entender lo mismo.La inspección transparente del incremento debería haber permitido que Ana administrase el riesgo y consiguiese previsibilidad.Sin embargo, dado que el incremento no es transparente, no lo podía planear eficazmente.

Al principio del proyecto, Ana estableció un objetivo para el lanzamiento.Después del Sprint 1, evaluó el progreso respecto al objetivo inspeccionando lo que pensaba que era un incremento utilizable.Tomó una decisión sobre lo que hacer en el Sprint 2 basándose en el progreso incremental hacia el objetivo.Si había pensado que nuestro progreso era inadecuado, podría haber cancelado el proyecto.

Al final del Sprint 3, Ana creyó que se completaron 3/10 del total, que es claramente incorrecto.

Desgraciadamente, apenas habíamos hecho lo justo de cada incremento para mostrarlo.El trabajo sin hacer hizo inutilizables y opacos a la inspección los incrementos en el departamento de Ana.

La opacidad al inspeccionar un incremento es como cubrir un termostato con un toallita frío y húmeda.El termostato no comprende correctamente la temperatura real de la habitación, y pondría incorrectamente la calefacción cuando en realidad debería poner el aire acondicionado.

Sin incrementos transparentes, las partes interesadas no tienen una comprensión correcta de lo que está ocurriendo realmente, y pueden que tomen incorrectamente medidas que no tienen sentido.

En resumen, sin transparencia completa, se pierde la capacidad de los equipos de inspeccionar y de adaptar eficazmente.

Deuda técnica en Nanomedtronics AZ

La deuda técnica es el trabajo diferido que debe completarse antes de que el software se considere terminado.La deuda técnica adopta varias formas, como diseño deficiente, duplicación del código y características no comprobadas.El ejemplo siguiente muestra la causa y el impacto de la deuda técnica como trabajo sin hacer a lo largo de un proyecto.

Nanomedtronics AZ era una pequeña empresa de software que acababa de empezar.Tenían un equipo Scrum que trabajaba en una nueva versión de su producto de importancia crítica: un software utilizado por nanorrobots para limpiar las arterias obstruidas de los pacientes con tensión sanguínea alta.

Lo que la gente pensaba que sucedía

Cuando el equipo se puso en marcha, le encargaron la selección de elementos de trabajo pendiente del producto para convertirlos en algo finalizado (sin restos de trabajo, utilizable y que se pueda entregar) en un sprint de un mes.El equipo de desarrollo tenía todos los conocimientos para desarrollar totalmente los requisitos en un incremento finalizado.

Cuando el equipo de Scrum inició el primer Sprint, vieron que había 80 unidades de trabajo que debían completarse en 10 meses.En consecuencia, el equipo de desarrollo diligentemente seleccionó 8 unidades de trabajo en cada Sprint.Argumentaron que solo con hacer 8 unidades por sprint, habrían terminado en los 10 meses exigidos por la compañía.

El equipo de desarrollo mostró un incremento operativo al final de cada sprint.Lo que se percibía desde fuera era que Scrum estaba trabajando y Nanomedtronics AZ estaba en proceso de entregar el producto según lo previsto.

Lo que sucedió realmente

Lo que no estaba claro más allá del equipo de desarrollo era que cada incremento entregado incluía realmente ciertas implementaciones deficientes, errores no críticos, lógica repetida y código generalmente sin optimizar.Además, los incrementos no se probaron totalmente porque el equipo de desarrollo detuvo las pruebas cuando se le presionó con los plazos en un Sprint.El equipo de desarrollo se comprometió a cumplir la programación, y reducir la calidad era a menudo la manera de hacerlo.

El equipo trabajó duro y creó el producto durante los 10 meses.El cliente estaba encantado y preparado para implementar y utilizar el software.Sin embargo, el equipo de desarrollo había acumulado 48 unidades de trabajo sin realizar, que se muestran en la ilustración siguiente como una nueva deuda técnica.

Trabajo completado y sin completar

El equipo de Nanomedtronics AZ no tomó en consideración todas las actividades y el trabajo que realmente sería necesario realizar.A continuación se incluyen cosas que el equipo no tuvo en cuenta, y no pretende ser ni mucho menos exhaustivo.Hay muchas más cosas que se podrían incluir.

Análisis
Diseño
Análisis de dependencia
Pruebas de rendimiento
Pruebas de estabilidad
Refactorización
Pruebas de la respuesta inmunológica
Integración con el trabajo de cualesquiera otros equipos que estén trabajando en un producto
Las pruebas de integración con el trabajo de cualquier otro equipo para que el incremento sea la totalidad de las contribuciones de todo el equipo
Notas de la versión
La internacionalización para las seis referencias culturales donde se vendió el producto
Prueba de aceptación del usuario
Pruebas de regresión
Revisiones de código

El trabajo anterior se debe completar para crear un incremento completo e integrado al final del sprint.Sin embargo, la mayoría de los equipos de desarrollo no completaron todo el trabajo anterior.Dejan algo “sin hacer” en cada sprint.Esto crea incrementos con diseño deficiente, código duplicado, lógica excesivamente compleja, funcionalidad o capacidades no comprobadas u otras formas de estado incompleto.Así es cómo los equipos crean la deuda técnica en el software.

Nanomedtronics AZ supo que el producto incluía todas las características necesarias para entregarlo a los clientes, pero también que incluía muchos defectos y que le faltaba el empaquetado y acabado necesarios para comercializar el producto.El equipo de desarrollo había creado accidentalmente un trabajo pendiente de trabajo adicional que llevaría otro 6 meses, suponiendo una velocidad ya incorrecta de 8 unidades por sprint.

Una espera de 6 meses para enviar el producto no era aceptable para los directivos de la compañía, y el producto se envió con trabajo sin hacer después de solo 3 meses.El potencial perdido no era simplemente el retraso de 3 meses en el envío del producto, sino la lenta capacidad de agregar nuevas características, ya que el equipo de desarrollo ahora tenía que pelearse con la deuda técnica en sprints futuros.

La lección

La deuda técnica oculta el verdadero progreso y empaña la transparencia necesaria para la toma de decisiones empírica del propietario del producto y las partes interesadas.La deuda técnica se pagará, bien en tiempo gastado deliberadamente en corregir problemas técnicos, o en pérdidas debido a envíos retrasados o con mala calidad.

En la mayoría de los casos, al menos el 50 % de trabajo deshecho permanece en los productos cuando se lanzan.En consecuencia, el trabajo no realizado se institucionaliza como deuda en curso.La deuda técnica provoca rápidamente la fragilidad del producto y puede forzar en última instancia la toma de decisiones comerciales negativas, como la reescritura del software o el abandono de un producto.

La deuda técnica aumenta con varios equipos

Un equipo de desarrollo debe elegir meticulosamente solamente el trabajo que pueda realizar en un Sprint.El equipo de desarrollo aprende el trabajo que cuesta a través de la experiencia.No obstante, un equipo tiene que emplear procedimientos de ingeniería modernos como la compilación automatizada y las pruebas de regresión para lograr sus objetivos.Si estos no se emplean, el trabajo manual suele sobrecargar un equipo hacia el cuarto o el quinto Sprint.

Piense en un equipo de desarrollo de tres programadores y dos especialistas de QA.Cada día los programadores introducen código en el sistema de código fuente.Se está probando y se están detectando errores y se ha entregado al programador correcto.Transcurre cierto tiempo desde que se protege el código hasta que se detectan y se notifican los defectos.Durante ese tiempo, los otros programadores podrían haber protegido el código antes que el código defectuoso.El esfuerzo necesario para corregir el problema inicial es mayor ahora.Si el equipo de desarrollo tuviera una capacidad continuada de compilación y de pruebas, el error se habría detectado inmediatamente.Las personas pudieron investigarlo, lo corrigieron y, después, continuaron.Se podía haber evitado el trabajo adicional y los desechos.

Muchas organizaciones usan más de un equipo de Scrum para compilar software.Cuando esto sucede, el problema de deuda técnica descrito en la sección anterior aumenta considerablemente.Las oportunidades para proteger el código situado encima del código defectuoso son significativamente mayores.El costo de remediar la creciente fragilidad del software aumenta exponencialmente a medida que progresa el trabajo.

El plan de la versión en A Datum Corporation

Trabajé recientemente con otra compañía que llamo Datum Corporation, una empresa de software de infraestructuras.La línea de productos principal emplea a más de 800 desarrolladores, incluyendo 250 programadores.La infraestructura de desarrollo se automatizó parcialmente.Las pruebas a menudo retrasaron en varios días la codificación.El tiempo que transcurría desde que un programador protegía un código defectuoso hasta que se detectaba y notificaba a menudo era de diez días o más.

Para minimizar la complejidad de tener tantos programadores, cada equipo de desarrollo trabajaba en su propia bifurcación de código.Los administradores de desarrollo ayudaron a organizar los requisitos del trabajo pendiente del producto para minimizar las dependencias.Si cada equipo de desarrollo combinara el código en la línea de código principal cada día, la cantidad de trabajo de revisión potencial se reducirá al mínimo.

Sin embargo, la administración creía que tardaría demasiado tiempo.La administración decidió combinar todas las bifurcaciones codificadas en la raíz cada tercer Sprint.Las pruebas de integración encontrarían cualquier defecto, que a continuación se corregirían.Un candidato de versión comercial estaría al final de cada trimestre.

Lo que la gente pensaba que sucedía

La ilustración siguiente muestra la programación y el ciclo de versiones planeados.

Programación y ciclo de versiones planeados

El plan original asumido:

9 Sprints
3 candidatos de versión comercial y, después una versión completa
Organización de desarrollo de 800 personas

Lo que sucedió realmente

Cuando esta organización llegó a la fecha de lanzamiento después de nueve sprints mensuales, el producto no estaba preparado para su lanzamiento.El sexto candidato de versión comercial tenía más de 5.000 defectos y más de 2.000 elementos de trabajo pendiente del producto sin completar.Nos preguntábamos cómo era posible.Habíamos visto un candidato a versión final cada tres meses.Cuando investigamos, descubrimos que la demostración había sido desde la bifurcación del código de cada equipo de desarrollo.No se produjo ninguna integración.No se produjo ninguna prueba de integración.

Para mantener la velocidad necesaria para la fecha de lanzamiento, los equipos de desarrollo habían aplazado cualquier trabajo de integración, con lo que estaban creando una gran cantidad de deuda técnica.El resultado fue un retraso de ocho meses desde la fecha de lanzamiento programada.Las palabras “candidato de versión comercial” no tenían ningún significado.

La ilustración siguiente muestra el proyecto real más el tiempo necesario para la estabilización.

Proyecto real más tiempo necesario para la estabilización

Los candidatos de versión tenían funcionalidad parcialmente operativa de la bifurcación de código para cada equipo.Son necesarios cinco meses de “estabilización” antes del lanzamiento.Algo particularmente molesto que retrasó la entrega más que otras fue “un rendimiento insuficiente”. Este problema se registró en el primer Sprint.

La lección

Equipos diferentes que trabajan en mismo software combinan eventualmente su trabajo.El software de integración para asegurarse de que funciona reduce el riesgo de las integraciones y debe producirse con frecuencia.

Esperar a combinar el trabajo de varios equipos es tentador, ya que permite retrasar el costo de la combinación.Sin embargo, este último costo del retraso está en relación con el número de equipos participantes y el número de bifurcaciones que deben integrarse.

Técnicas a gran escala para finalizar tareas

Llegar a un estado “Listo” en varios equipos es difícil.Las complejidades implicadas son numerosas.Las dependencias entre los equipos y entre las bifurcaciones de código existen.Aunque esta complejidad de escala tenga un costo, es factible y proporciona un valor enorme cuando los equipos sincronizados se coordinan en su trabajo.

Hay varias técnicas que considero que resultan de utilidad cuando varios equipos trabajan juntos.

Scrum de los Scrums

Cuando muchos equipos de Scrum trabajan en el mismo proyecto, necesitan una técnica para coordinar su trabajo.He recomendado un “Scrum de Scrums". Este es un evento cotidiano, que tiene lugar inmediatamente después de cada Daily Scrum del equipo.Asistirán a él personal técnico de cada equipo.Cada representante de equipo describe lo que funcionó en su equipo.Describe posteriormente en lo que piensa trabajar durante el día siguiente.Según esta información, los representantes intentan identificar cualquier trabajo necesario, las dependencias siguientes y cualquier trabajo que se deba volver a programar.

El Scrum de Scrums ha sido útil a muchas organizaciones.Sin embargo, no es adecuado.Las dependencias y el trabajo de revisión pueden o no detectarse correctamente, porque los problemas se anticipan en lugar de conocerse.Las dependencias imprevistas fueron la causa de modificaciones y pruebas erróneas.Algunos equipos pasan más del 50% de cada Sprint trabajando en las dependencias.

Integración continua

Extreme Programming (XP) requiere la integración y pruebas de integración continuadas del trabajo de un equipo.¿Por qué no extender esto a todos los equipos?Tanto si hay dos equipos como si hay cincuenta, los equipos están obligados a producir un incremento integrado con integración comprobada al final de cada sprint.Para ello, los equipos tienen que integrar su trabajo con frecuencia.Puesto que cualquier trabajo no integrado pueden contener dependencias no resueltas, la integración continua es la mejor solución.

La integración continua de todo el trabajo es similar a las técnicas Lean de producción.En líneas de producción Lean, se usan muchas técnicas para evaluar la calidad de un producto en el proceso de producción.Cuando se producen desviaciones o problemas de calidad, se detiene la cadena de producción.La integración y pruebas de integración continuadas proporcionan las mismas técnicas para el desarrollo del producto de software.

Duro como es, recomiendo que cada equipo y miembro del equipo deje de codificar si se produce un error en una compilación o prueba continuadas.Cualquier trabajo subsiguiente se creará potencialmente sobre errores, produciendo un efecto de propagación de errores.Si se usa la integración continua, los equipos trabajan en estrecha colaboración evitar los errores de integración.Mejoran sus hábitos de trabajo, se reducen los residuos, y mejora la calidad.

La mayoría de las organizaciones que adoptan Scrum no comienzan con todos los conocimientos y herramientas de ingeniería a compilar un incremento finalizado.Un programa riguroso para lograr incrementos listos deba iniciarse y llevar un seguimiento del mismo.Los grupos de menos de cincuenta personas pueden obtener acceso rápidamente a un estado donde se completa un incremento finalizado dentro del Sprint.Las organizaciones de más de quinientos desarrolladores suelen requerir varios años para llegar a ese punto.

Los incrementos sin hacer crean residuos e impiden que los equipos alcancen una verdadera agilidad.El costo real del trabajo sin hacer es mucho mayor que la falta de una característica o función en el incremento.El costo incluye los residuos de la replaneación y de las modificaciones necesarias cuando un incremento no está realmente terminado, así como los costos de una menor previsibilidad y un riesgo más alto.

Muchas organizaciones desean las ventajas de la agilidad y emplean Scrum para obtenerlas.La entrega de un incremento finalizado es crucial para realizar correctamente el desarrollo del Software Agile.Los equipos deben comenzar con una definición de terminado que tenga sentido para ellos y, a continuación, expandir deliberadamente la definición con el tiempo.Solo entonces, adquirirán agilidad verdadera.