Búsqueda


29 de julio de 2016

La rana en la olla, agile y los equipos de operaciones

Cuando das clases de muchas temáticas diferentes pasa que durante un curso tu mente se enfoca en una materia concreta y al siguiente curso la materia cambia. Si en medio además te dedicas a hacer proyectos, notas cómo esas materias te influencian fuertemente en tu manera de enfocar o de abordar los problemas que se plantean en la ejecución.
Este último mes he tenido proyectos de agilidad, clases de lean y clases de ITIL® así que mi cabeza es un hervidero de ideas. Entre ellas, esta mañana apareció un flash: ¿que pasa con los atributos de garantía en un entorno ágil?
Hace unas semanas escuchaba a Alex Ballarin en una clase diciendo algo que me hizo sonreír: las historias de usuario pueden usarse también para expresar requerimientos no funcionales, por ejemplo algo así como "Como sistema quiero soportar 1000 usuarios concurrentes para que no se ralentice la cadena de valor"
Con la interpretación “tradicional" de ITIL® vemos el ciclo de vida del servicio como una gigantesca rueda waterfall que lleva un servicio completo desde la Estrategia hasta la Operación y luego lo hace evolucionar en forma de "servicio modificado” con la mejora continua del servicio. Con esta visión es fácil comprender la importancia que tiene en la etapa de diseño que utilicemos las famosas 4P para tener en cuenta los aspectos de garantía del servicio y que incorporemos los requerimientos de garantía en el diseño y posteriormente en la construcción, pruebas y despliegue.
La cosa es grande y viene de lejos, así que nos preparamos para acogerla en nuestro entorno de producción; para ello tendremos en cuenta a los equipos de operaciones o, para ser más itileramente formal, a las funciones de la etapa de Operación del Servicio y por ejemplo prepararemos las infraestructuras para dar soporte al volumen de usuarios que esperamos.
Cuando se avecina un cambio grande, es normal que se cree esa sensación de necesidad de preveer las consecuencias y por lo tanto que se piense en aspectos como la capacidad, la disponibilidad o la seguridad.
Pero… ¿y qué pasa en el momento en que cambiamos el modo de trabajo y pasamos a trabajar el modo “evolutivo” desde el minuto cero?
Peter Senge explica en su libro La Quinta Disciplina el concepto de adaptación a los cambios lentos y graduales y el peligro que conllevan si no estamos atentos y lo ilustra con una parábola que a mi personalmente me pone los pelos de punta por lo cruel de la idea: la parábola de la rana hervida. Muy cruel, pero explicita!
Si ponemos una rana en una olla de agua hirviente, inmediatamente intenta salir. Pero si ponemos la rana en agua a la temperatura ambiente, y no la asustamos, se queda tranquila. Cuando la temperatura se eleva de 21 a 26 grados centígrados, la rana no hace nada, e incluso parece pasarlo bien. A medida que la temperatura aumenta, la rana está cada vez más aturdida, y finalmente no está en condiciones de salir de la olla. Aunque nada se lo impide, la rana se queda allí y hierve. ¿Por qué? Porque su aparato interno para detectar amenazas a la supervivencia está preparado para cambios repentinos en el medio ambiente, no para cambios lentos y graduales.

De repente ocurre que en algún momento aparece esa necesidad de soportar 1000 usuarios concurrentes, la implementamos y luego se producen 200 modificaciones posteriores a las funcionalidades del servicio en forma de sendas historias de usuario que se implementan en sprints sucesivos…. y de repente esas pequeñas modificaciones que una a una eran poquita cosa hacen que nuestro sistema deje de soportar 1000 usuarios concurrentes.
Técnicamente esto no debería pasar, porque a cada modificación hacemos pruebas de regresión y pruebas de los requerimientos funcionales y nos aseguramos de que cada pequeño cambio no rompa nada, pero… por favor, que levante la mano el que esté dispuesto a asegurar que hace eso para todos sus servicios en la etapa de construccion.
Si salen más de 10, prometo borrar este post.
En resumen, que propongo que al menos para empezar, la historia de usuario se reescriba para contemplar este peligro y quede en algo asi como
Como sistema, quiero soportar 1000 usuarios concurrentes y seguir soportándolos despues de los próximos 10 sprints. Depués volvemos a hablar de demanda, capacidad y arquitectura.
A media que vayamos madurando y consigamos un flujo continuo con todos los requerimientos de información necesarios, una arquitectura flexible y escalable y un sistema de testing automatizado que nos garantice que cumplimos los requisitos no funcionales en modo regresión entonces podremos modificar la historia de usuario para reflejar el objetivo real:
Como sistema quiero soportar el numero de usuarios concurrentes que necesite el negocio en todo momento de modo flexible, elástico y con una estructura de costes asumible por la organización.
Pero eso requiere un nivel de madurez enorme en toda la organización: el negocio debe decir de forma continua (o casi) la demanda prevista, la capacidad debe poderse adaptar de forma instantánea, las arquitecturas deben poderse redimensionar al momento y todo esto con un esquema económico razonable… o podemos quitar al negocio de la ecuacion y montar un sistema flexible y automatizado que crezca o decrezca según la demanda real…
¿Ciencia Ficción?
¡Preguntale a Etsy o a Netflix!
PS:: Iba a ilustrar este post con alguna foto… lo primero que me vino a la cabeza fue esta preciosa ranita de San Antonio del blog Naturaleza Andaluza, pero finalmente me he negado…. no se ha dañado ninguna rana para escribir este post. Ojalá Peter Senge piense en otra parabola menos salvaje!

PS2: Pues resulta que este post inspiró a mi amigo Rui Soares, autor de ITIL Blues y creador de los personajes Mush & Room, quien me dibujó la  fantástica ilustración que acompaña  este artículo. GRACIAS!