DevOps: Desarrollando soporte para el equipo

por Diego Fontdevila

Mientras escribía ayer las instrucciones de aprovisionamiento para los servidores de nuestro proyecto actual, me puse a pensar en mi rol en equipos ágiles en los últimos dos años, y descubrí sin mucha sorpresa algo que puede ser interesante y quisiera compartir.

En la mayoría de esos proyectos no estuve escribiendo funcionalidades para usuarios finales si no funcionalidades para usuarios internos, equipo de desarrollo de producto y los responsables de infraestructura de tecnología y operaciones. Tal vez resulte sorprendente pero creo que esto ha ocurrido por varias razones:

• Tiendo a tener dedicación parcial en los proyectos de desarrollo, y por lo tanto me es más fácil no tomar requerimientos del cliente que tienden a ser prioritarios.
• Tengo bastante experiencia en desarrollo, con lo cual tiendo a percibir las necesidades y varias alternativas de solución. El patrón Genérico vs. Específico describe este esquema, desarrolladores más experimentados para desarrollar componentes genéricos y los desarrolladores menos experimentados para desarrollar componentes más específicos.
• Me gusta aprender nuevas tecnologías y resolver problemas técnicos más allá del código de la aplicación.

En general, los equipos de desarrollo estamos acostumbrados a vivir por el adagio de “En casa del herrero, cuchillo de palo”, enfocados en generar producto inmediato para el cliente o el usuario final sin mejorar nuestras propias herramientas y contexto de trabajo. Esto tiende a resultar en equipos que no pueden sostener su ritmo de desarrollo, acumulando problemas e ineficiencias que los demoran cada vez más. Por suerte, la comunidad está avanzando hacia prácticas de ingeniería cada vez más avanzadas y constantes. Una marca clara de esta tendencia en la publicación del libro Continuous Delivery de Jez Humble en 2010, y la popularidad del movimiento DevOps.

Algunas de las prácticas básicas DevOps en las que me encuentro enfocado son las siguientes:

* Gestión de configuración (código, configuración, ambientes, etc.)
* Build automatizado
* Integración Continua
* Despliegue automatizado
* Pruebas automatizadas (unitarias, integración, aceptación)
* Desarrollo guiado por pruebas de aceptación (ATDD)
* Infraestructura como código
* Entrega Continua

Esta lista no es más que una referencia de las prácticas de ingeniería que estamos usando y que nos sirven para mejorar el flujo de proceso y la generación de valor. Varias de ellas están directamente relacionadas con la interacción con el negocio aunque sean prácticas técnicas, en particular el despliegue automatizado, las pruebas de aceptación automatizadas y la entrega continua. Durante estos últimos años estas prácticas nos han resultado habilitantes en la relación con otros interesados, incluyendo al negocio y áreas de tecnología, en lugar de resultar bloqueantes o conflictivas. Por ejemplo, antes de implementar infraestructura como código tendíamos a considerar que les resultarían conflictivas a las áreas de tecnología en organizaciones cliente, sin embargo ha resultado todo lo contrario, un mecanismo para iniciar conversaciones y crear acuerdos tempranos, y lograr implementaciones rápidas y con menos errores. De la misma manera, para el negocio mismo, incluyendo a los niveles directivos de grandes organizaciones, ha resultado muy efectivo describir las mejoras en los tiempos y en esfuerzos invertidos productos de las mejoras aplicadas, especialmente en términos de automatización y especificación ejecutables de requerimientos.

Como reflexión final, considero central balancear las necesidades del equipo y del negocio en términos de soporte del proceso de desarrollo, negociando colectivamente la generación de funcionalidad con la generación software para procesos de soporte. Esta dedicación del equipo debe ser transparentada hacia los clientes e involucrados, además de presentarse en la perspectiva de cada interesado por el valor que les genera.