Publicado en
Autor
El concepto de entrega continua está ganando tracción en las organizaciones; sin embargo, su adopción no es trivial. El cambio de entregas poco frecuentes a un flujo continuo puede intimidar a cualquiera. Adicionalmente, las organizaciones grandes y/o con varias décadas de operación típicamente tienen una gran variedad de herramientas independientes para soportar el desarrollo y gestión de software, que no se integran entre sí. Así que antes de comenzar un esfuerzo de adopción de entrega continua, bien vale la pena evaluar nuestro estatus actual.
En este artículo presento un modelo de evaluación de capacidad para entrega continua desarrollado por la empresa Electric Cloud y documentado a mayor detalle en su whitepaper “The Journey to Enterprise Continuous Delivery” [1]. El objetivo es que las organizaciones puedan evaluar sus capacidades actuales relacionadas con entrega continua y establecer un mapa de ruta para su adopción.
El modelo considera 3 dimensiones:
Tecnología
Personas
Procesos
En cada dimensión se identifican cinco niveles y para cada uno se indican rasgos comunes.
Aunque cada dimensión es independiente, las organizaciones típicamente maduran de forma concurrente a través de ellas. Es decir, difícilmente encontraremos una organización que mejore significativamente sus procesos sin mejorar en sus personas y tecnología.
Personas
Una organización requiere la cultura adecuada para soportar e incentivar la entrega continua. Desafortunadamente, demasiadas organizaciones perciben que el trabajo necesario para establecer la colaboración y comunicación necesaria es un obstáculo demasiado grande que bloquea la productividad. Es solo cuando estos equipos maduran que se dan cuenta de la importancia de su cooperación.
Nivel | Rasgos comunes | Resultados |
0 | Integrantes con personalidad de “divas”. No hay compromiso. | La creatividad es vista como la clave, así que hay resistencia a usar estándares o procedimientos. La calidad no es consistente. Se dan problemas en la integración ya que cada persona defiende su forma de hacer las cosas. |
1 | Las personas están aisladas; la comunicación se hace por correo electrónico y típicamente es reactiva; el liderazgo es “a la antigua” que se reúne 1 o 2 veces por semana para ver avance; los integrantes con menor experiencia no tienen mentoría. | La comunicación típicamente sólo se da de forma vertical (entre jefes y sus coordinados); hay poca colaboración y la retroalimentación entre pares no se recibe bien; se opera en modo reactivo. Las personas se dedican a solamente hacer lo que tiene asignado en el plan de trabajo y se alarman cuando este cambia. |
2 | Algo de colaboración entre equipos; los programadores se enfocan en construir componentes individuales que luego “pasan” a que otros revisen, liberen y mantengan; las iniciativas para de mentoreo se dan de forma silvestre. | Hay algo de colaboración pero no es muy efectiva; las personas están algo conscientes de las metas de negocio pero su enfoque está en proteger agendas individuales. |
3 | Amplia conciencia de las metas de negocio; hay interés en colaborar para conseguir las metas; se busca y aprecia la retroalimentación; se da algo de atención a la mentoría. | Alta adaptabilidad al cambio, las personas entienden los objetivos y respetan los planes pero entienden que los planes pueden cambiar; hay interés en la satisfacción del cliente, reflejada en jidoka (cualquiera puede detener la línea de producción) y kaizen (mejora continua). |
4 | La colaboración y cooperación son clave para cualquier actividad; hay amplio interés en la mentoría. | Los equipos son dirigidos por la mejora continua y continuamente se ajustan a las necesidades del negocio. |
Procesos
La entrega continua implica un flujo a través del cual todos los involucrados colaboran para entregar mayor valor al usuario de forma consistente. Esto implica una planeación y estilo de liderazgo distinto al tradicional, pero cualquier organización puede lograr establecerlo con la dedicación y compromiso requeridos.
Nivel | Rasgos comunes | Resultados |
0 | No hay planes ni procesos, solo procedimientos ad-hoc. | Construir software es considerado una actividad creativa, no de ingeniería; la mayoría del tiempo se dedica a generar y discutir formas de hacer las cosas. |
1 | Existen planes de proyecto pero faltan procesos bien definidos para gestionar peticiones (cambio, diseño, escalamiento); no hay pruebas continuas. | La falta de procedimientos para atender peticiones resulta en “bomberazos” frecuentes. Esto impacta incluso al código fuente, que está regado en distintas ramas y repositorios. |
2 | Hay procesos definidos (ej. Integración continua, pruebas, despliegue) pero la ejecución no es consistente o integrada de punta a punta; es común que se utilice Scrum. | Los procesos son vistos como engorrosos, así que las personas toman atajos. |
3 | Existen procesos bien definidos, integrados y automatizados; la última versión del código está en una sola rama del repositorio; es común que se utilice Kanban. | Dado que los procesos están cuidadosamente planeados e instrumentados, tienden a hacerse invisibles, permitiendo que las personas se enfoquen en sus responsabilidades principales. |
4 | Existen procesos de mejora continua para satisfacer requerimientos de negocio dinámicos apoyándose en herramientas de monitoreo del proceso. | Los procesos se mejoran de manera continua utilizando datos en tiempo real como parte de su ciclo de retroalimentación. |
Tecnología
Existen una gran oferta de herramientas para instrumentar la entrega continua. Sin embargo, siempre hay que tener en cuenta que las herramientas por sí solas no resuelven el problema. Conforme las organizaciones maduran en las otras 2 dimensiones, hacen que las herramientas se ajusten a sus necesidades, en lugar de estas ajustarse a las capacidades de las herramientas.
Nivel | Rasgos comunes | Resultados |
0 | Procedimientos manuales; herramientas open source básicas. | Fuera de algo de scripting básico, hay poca automatización. |
1 | Distintos equipos utilizan distintas herramientas para actividades específicas (ej. Integrar, probar) no integradas entre sí, típicamente administradas por personas distintas sin un proceso o entendimiento común. | Se depende de personas para integración manual; las personas se convierten en cuellos de botella; la salida de una persona del equipo tiene un gran impacto. |
2 | Se crea infraestructura común pero no se considera el proceso de punta a punta ni hay una buena integración. | Los mejores recursos técnicos dedican su valioso tiempo a construir y mantener herramientas en lugar de resolver problemas del producto o negocio. No hay estandarización a través de áreas o departamentos, así que transferir la propiedad de un producto digital a otra área/departamento es caótico. |
3 | Hay automatización a través de todo el ciclo de integración/prueba/despliegue; la configuración y aprovisionamiento de la infraestructura también está automatizada; se utiliza infraestructura centralizada y elástica disponible bajo esquema de autoservicio. | La tecnología se encarga de la orquestación; las herramientas están tan integradas que pasan desapercibidas; se genera ejecutables de manera rápida y confiable, cuando hay errores se reportan en tiempo real. |
4 | Por medio de dashboards cualquiera puede estar enterado del estatus en tiempo real; el negocio determina qué se libera y cuándo. | Cuando se necesitan ajustes, se puede modificar las herramientas y procesos en tiempo real con impacto mínimo a la operación. |
Adoptar una disciplina de entrega continua involucra tener la cultura, procesos y herramientas adecuadas. Espero que este sencillo modelo te ayude a determinar donde está tu organización.
Referencias
- Log in to post comments