viernes, 12 de agosto de 2011

Relación entre la frecuencia de entrega y los procesos

Recientemente vi un video de Kent Beck, Software G Forces: The Effects of Acceleration, comentado por Mary Poppendieck en How Cadence Predicts Process.

Kent analiza como cambian los procesos y buenas prácticas según aumenta la frecuencia de entregas (Anual, Trimestral, Mensual, Semanal, Diaria, Horas). Comenta como algunas prácticas son buenas con cierta frecuencia de entrega y son malas en otras.
Plantea la relevancia de este análisis debido a que, según su percepción, la frecuencia de entrega de los equipos de software tiene a acelerarse.

Mi intensión es hacer un resumen, pero recomiendo ver el video que, aunque dura 90 min, es mucho más rico que este post.

Entregas anuales → trimestrales

Prácticas que se agregan: Test de aceptación automatizados, refactoring, Integración continua
Justificación: No se puede solo reducir los tiempos, hay que cambiar los procesos. No puedo tener un mes de integración y corrección de bug, con una o dos semanas de pruebas manuales para hacer regresiones. Entonces aparece Integración continua, y Pruebas de Aceptación Automatizada. No puedo tener uno o dos meses de diseño, aparece la necesidad de avanzar aún sin tener todo el diseño hecho o cerrado. Estoy seguro que tendré que cambiar el diseño, por lo tanto, tengo la necesidad de refactoring.

Cambios en el negocio: Suscripción.
Justificación: No se pueden vender 4 versiones por año. Necesito bajar el costo de transacción (tanto para la empresa como para los clientes).

Entregas trimestrales → mensuales

Prácticas que se agregan: prueba por parte de los desarrolladores, reuniones diarias, tarjetas en las paredes.
Prácticas que se quitan: Departamente de QA, soporte a múltiples versiones, Documento de diseño, Control de cabios, equipo de análisis, equipo de build.
Justificación: no hay tiempo para el ida y vuelta con un grupo separado de QA. La mayoría del testing y la reducción del defectos deben ser hechos por el mismo grupo, y probablemente por la misma personas (testers en el equipo y pruebas por los programadores), en el plazo de horas, no de días. La comunicación debe ser mucho más rápida, no podemos sincronizarnos y detectar problemas una vez por semana o mensualmente. Tenemos que estar al tanto cada día, solo tenemos 20 días para entregar (reuniones diarias), tenemos que planificar y re-planificar en forma barata y rápida (tarjetas en las paredes, dejar de usar control de cambios formales). No podemos dedicar mucho tiempo para escribir las decisiones detalladas de diseño antes de usarlas (Documentos de diseño).
Al aumenta la cantidad de entregas, el costo de soporte de muchas versiones se vuelve prohibitivo, y debemos mantener una o pocas versiones del producto (soporte de múltiples versiones). Necesitamos iniciar el diseño y el desarrollo, no podemos esperar una fase de análisis o el ida y vuelta en paralelo con un grupo de análisis (mismo problema que con QA).

Cambios en el negocio: Pagar por el uso.
Justificación: la suscripción no nos da suficiente feedback. Con pagar por el uso, sabemos realmente que funcionalidad que estamos desarrollando les interesa a los clientes.

Entregas mensual → semanales

Prácticas que se agregan: migración de datos en vivo, cero defecto, ramas temporarias, dovela clave (keystoning), kanban.
Prácticas que se quitan: equipos de test, migración en un sólo sentido, ramas de release, parches, diseño de usabilidad al inicio, venture capitals
Justificación: para poder cambiar las estructuras de datos en sitios con grandes volúmenes de datos y cantidad de usuarios, se debe hacer procesos de migración en dos o tres fases, de manera de cambiar la estructura sin nunca dejar de dar el servicio (migración de datos en vivo).
Como los tiempos son cortos, algunas funcionalidades se comienzan a agregar sin hacerlas visibles. Solo cuando está todo dispobible, se agrega la última parte (como la dovela clave de un arco de medio punto), y queda dispobible para los usuarios. Siendo que las entregas son tan rápidas, cualquier cambio, por más urgente que sea, puede incluirse en la próxima entrega. Se elimina la necesidad de procesos de emergencia (parches).

Cambios en el negocio: Bootstrap financing.
Justificación: La financiación de Venture Capitals necesita mayor predecibilidad en los planes, e impone restricciones a desarrollo de productos (a esta velocidad).

Entregas semanal → diarias

Prácticas que se agregan: inmunización, A/B testing
Prácticas que se quitan: staging, equipo de operaciones, reuniones diarias.
Justificación: algunos de los releases van a ser malos. Tenemos que tener formas muy sencillas de volver atrás o formas muy rápidas de corregir y continuar. No hay mucho tiempo para discusciones sobre diseño de interfase, se pude simplemente dar las alternativas y ver como lo usan los usuarios (A/B testing). Para hacer entregas rápidas, no podemos pasar por tantos pasos (ambientes) intermedios. Simplemente no hay tiempo para usarlos (staging), lo que se puede hacer es hacer instalaciones en distintos servidores de producción, que se va midiendo y obteniendo feedback. Todo esto lleva a que la operación debe ser parte de la responsabilidad del equipo (equipo de operaciones). La comunicación en el grupo tiene que ser tan continua y rápida, que no tiene mucho sentido para las reuniones diarias.

Mis conclusiones

Esta visión me hizo repensar mis ideas sobre La mejor manera de probar, reinterpretando parte de mis observaciones desde esta nueva perspectiva. La corelación entre ambas visiones es muy fuerte, pero no completa. Es interesante que la visión de Kent está muy asociada a situaciones en las que el software es el componente principal de los productos.
Publicar un comentario