×
×

Agilidad, DevOps y atributos de calidad en ITIL

Quería tomar el testigo del artículo de Antonio Valle “La rana en la olla, Agile y los Equipos de Operación”, ha dado en el clavo de una idea que he comentado en varias clases y clientes. Me gusta colaborar con Antonio porque aprendo desde sus enfoques y me estimula a pensar en cosas nuevas.

En primer lugar quería comentar los posibles planteamientos iniciales de los atributos de calidad del sistema, caracterizados habitualmente por elementos como la arquitectura y el diseño, los requisitos no funcionales y las pruebas técnicas. En agilidad no se prohíbe preocuparse de estos atributos técnicos antes de comenzar la construcción. El Manifiesto Ágil habla explícitamente de:

  • Software funcionando sobre documentación extensiva
  • Respuesta ante el cambio sobre seguir un plan

Y por otro lado podemos ver ciclos de vida como el que propone Disciplined Agile Delivery, donde empleamos el tiempo mínimo necesario en la fase de Inception para consensuar suficientemente los atributos de calidad y las medidas que tomaremos para satisfacerlos. Aquí nos preocuparíamos de identificar esa historia de “quiero soportar 1000 usuarios” (otro tema es la idea errónea que las historias de usuario sólo se pueden escribir con el formato Como… quiero… para…).

P11_DAD_Lifecycle.JPG

 

En segundo lugar, en una organización que hace DevOps, el desarrollo está integrado con las actividades de gestión de operaciones como la monitorización. Los profesionales que definen las historias, las desarrollas y miden su rendimiento no están en equipos, edificios o empresas diferentes: están colaborando desde ese minuto 1 y las herramientas ayudan a establecer la trazabilidad entre los objetivos de calidad en las historias de usuario técnicas y sus resultados. Tres ejemplos de medidas que permitirían salvar a la rana de Peter Senge son:

  • Los desarrolladores y los administradores de sistemas colaboran antes, durante y después del desarrollo, incluyendo en el dimensionamiento y diseño de los sistemas, así como en el análisis del rendimiento de producción.
  • Se hacen reuniones periódicas del equipo integrado de “construcción y operación” del producto. En éstas se pueden tomar decisiones “preventivas” o “correctivas” si el rendimiento o la carga de usuarios no son los esperados.
  • Se automatizan los procesos de pruebas, tanto funcionales como de rendimiento, y de despliegue. Esto permite responder con rapidez a las necesidades de cambio.

Esta es una de las transparencias a la que más cariño tengo de mis cursos de agilidad. Está inspirada en el libro User Story Mapping de Jeff Patton. Extiende el concepto tradicional de “Card, Conversation and Confirmation” de Ron Jeffries, uno de los popes de Extreme Programming. En esta transparencia se ve como todo en la agilidad corresponde a un flujo de historias de usuario (o flujo de valor en Lean), incluyendo definir historias técnicas o atributos de éxito en las historias funcionales.

P11_UserStories_5C.JPG

 

Creo que Antonio no tendrá que borrar su artículo, no muchos podrán levantar su mano con ejemplos de DevOps desarrollados y funcionando. ¡Menos mal, después del esfuerzo de escribirlo!

Este artículo y mucho más lo podrás encontrar en www.itnove.com.

Español