21. dic., 2017

Los obstáculos para adoptar DEVOPS


El concepto de DEVOPS cumplió en este año 9 años en el mercado. Sin embargo, tenemos que no todas las organizaciones han adoptado dicha práctica de TI que combina el desarrollo de software con las operaciones y el personal de testing en equipos interfuncionales destinados a mejorar la agilidad en la entrega de servicios de TI.

De acuerdo con afirmaciones de la compañía Forrester en sus investigaciones solo un 13% de las organizaciones ha implementado DEVOPS. De estas un 50% lo han hecho bajo el esquema de pruebas piloto o pruebas de concepto. Otro 27% de éstas planean implementar DevOps dentro del año próximo y un 9% de ellas está interesado en hacerlo en algún momento, pero no tiene planes de adoptar DEVOPS dentro de los próximos 12 meses.

Si quisieramos indagar las razones de la adopción lenta de esta práctica se tienen varias, por un lado el estado actual no lo ha incentivado, la propiedad del desarrollo de las aplicaciones se encuentra dispersa en numerosas agencias y hay barreras para los procesos de automatización y para que los procesos continuos funcionen en toda la empresa. Se dice que en Europa solo un 17% aproximadamente de la información se maneja en las organizaciones de forma digital y con procesos de automatización. Si ha eso vamos en latinoamérica este porcentaje no llega al 10%. Dado que esos 2 conceptos son la base Devops (automaticación y procesos continuos) pues obviamente se considera como una barrera de entrada en su adopción. Por otro lado, su estado aún no tiene las habilidades adecuadas para brindar soporte a DevOps completamente.

Los obstáculos para adoptar y expandir DEVOPS en los departamentos de TI de las empresas, como las soluciones en sí, afectan a las personas, los procesos y la tecnología- lo que tiene implícito un cambio cultural- que en países como Colombia no son tan fáciles de llevar a cabo aunque se hable de la gestión del cambio de forma natural y como si fuera algo sencillo de adoptar y llevar a la realidad.

Entonces si queremos mencionar cuales son los obstáculos específicos que enfrenta un CIO en esta área cuando desea implementar DEVOPS tenemos lo siguiente:

1. "El dolor del cambio de Cultura"

Que un equipo utilice los principios de DEVOPS - como ciclos de retroalimentación más cortos, sprints más cortos y pruebas de usabilidad - requiere un cambio en la forma en que las personas piensan y operan. Es decir, un cambio cultural, algo que no se puede forzar de la noche a la mañana.

Se puede decir que "adoptar DEVOPS" el día de mañana es el Big Bang de TI y simplemente puede no funcionar. Uno introduce demasiado, de manera demasiado rápida. "Y si está tratando de usar DevOps para todo, hará que las personas se revelen". Es el enfoque correcto para muchas cosas, pero no para todo y esto a veces se desconoce por parte de los líderes y por parte de la organización y por ello se sufre luego las consecuencias y se presenta la implementación de estas prácticas como un fracaso y una pérdida de dinero.

En una encuesta realizada en el otoño del 2017, realizada por la empresa de software Pensa, se identificaron problemas relacionados con las personas como una de las principales barreras para la adopción de DEVOPS. Pensa encuestó a más de 200 responsables de la toma de decisiones de TI en el mes de Septiembre, preguntando sobre los mayores desafíos que enfrentan al adoptar las prácticas de DEVOPS. Aproximadamente, el 19,7% expresó que tener presupuestos limitados como una barrera muy importante, el 9.4% mencionó la cultura de la compañía, el 7.9% afirmó que lo eran las habilidades limitadas de TI y el 7.4% mencionó la falta de aceptación por parte de los ejecutivos.

En la compañía Forrester sus expertos afirman que los CIO deben abordar la cultura desde el comienzo de sus iniciativas de DEVOPS. Deben lograr que otros ejecutivos comprendan y respalden la estrategia de "vender la idea" de DEVOPS no como un conjunto de principios, sino como una herramienta fundamental para la transformación digital. Y deben hacer que los empleados trabajen colaborativamente en una organización más horizontal, donde haya más flexibilidad para que cada trabajador individual resuelva problemas. Esto a simple vista suena sencilo pero en entornos como el latinoamericano no lo es tanto.

DEVOPS requiere en realidad un replanteamiento fundamental, lo normal es que la gente se siente cómoda con la forma en que han estado trabajando durante años y no todos son agentes de cambio. Por lo tanto, es un desafío hacer entender las bondades de DEVOPS y cual es el beneficio para su día a día. Esto obviamente se lográ no solo con decirlo, implica que en realidad se capacite a los equipos para que puedan implementar las herramientas y principios que DEVOPS contiene, una vez la gente se sienta implicada en realidad se logrará el cambio cultural y organizativo necesario. Se aconseja que los departamentos de TI se centren en formar equipos de DEVOPS fuertes, contratando o capacitando en las habilidades correctas, e identificando a los líderes orientados al negocio y no a los tecnócratas, porque los líderes "están impulsando la agenda para entregar las funciones y características con el fin de hacer su negocio más eficiente y competitivo”.

2. De cara al proceso lo recomendable es que se comience en pequeño o fracasará

Además de la cultura, el proceso es otra clave para el éxito de DEVOPS. Con DEVOPS la automatización se emplea para desarrollar una integración continua y una plataforma de producción continua que puede evaluarse y supervisarse automáticamente. La complejidad de dicho sistema deja a muchos CIO luchando por decidir dónde comenzar.

Sin embargo, queda claro de acuerdo con experiencias de expertos en el tema y casos de éxito de empresas que ya están subidas en este barco que los beneficios son notorios. Tener implementado DEVOPS significa que un desarrollador cuente con el ambiente de desarrollo y pueda escribir, probar y desplegar código en producción de una manera automatizada, rápida y no exenta de riesgos - aunque en este punto puede decirse que los riesgos son menores que si no se tuviera automatización.

Estos casos exitosos han logrado por ejemplo gracias a su travesía de DEVOPS que puedan pasar código en desarrollo y producción de manera muy ágil. Se habla de que se requiere de horas para hacer lo que antes solía tomar semanas o incluso hasta un mes. Sin embargo, mantener a todos sincronizados es un verdadero desafío. En este aspecto puede decirse que los equipos trabajan en proyectos tratando de avanzar lo más rápido que puedan y cada equipo está muy preocupado con sus fechas límite. Esto hace que a veces el ritmo de la comunicación no sea el más eficiente posible.

Entonces lo que se recomienda para la sincronización es que se comience con pequeños proyectos para desarrollar los procesos que producirían los primeros éxitos de DEVOPS. Estos proporcionaran la base de los procesos, principios y prácticas que podrían utilizarse en proyectos más grandes y extensos en toda la organización. En algunas organizaciones se toma la decisión de tomar una muestra de proyectos en lo posible con categorizaciones diferentes o características diferentes para tratar de contemplar ejemplos del portafolio de la organización. De esta manera se adquieren lecciones aprendidas y experiencia que se pueden implementar dentro del proceso de desarrollo y despliegue de software. El hacerlo en forma de BigBang tiene un riesgo y es que al no ver resultados inmediatos la compañía se aburra o la gente que trabaja en la implementación pierda el entusiasmo. Lo que dicen los expertos de DEVOPS a nivel mundial es lo siguiente : "Es bueno comenzar con un proyecto pequeño y donde sabes que puedes tener éxito”. Desde nuestro punto de vista en PMPMedellin nos parece razonable y hasta cierto punto inteligente dado que de esta manera la alta gerencia ve ROI desde un principio y se puede programar de mejor manera la escalabilidad de DEVOPS en la organización.

3. Una cuestión de autoridad y estabilidad

También existen otros obstáculos -orientados al proceso- para la práctica exitosa de DevOps. Por ejemplo, DEVOPS puede permitir comportamientos deshonestos o atajos, a medida que la autoridad y la autonomía pasan de los ejecutivos y gerentes hacia los equipos DEVOPS. Esto es con la autoridad viene la capacidad de hacer cosas que no se deberían hacer. Los trabajadores pueden por ejemplo, reparar fallas inmediatas, pero ignorar los problemas subyacentes que esto contiene. De esta manera se adquieren una posición que no es segura o es más arriesgada y que que no es sostenible en el tiempo. Sobretodo en algunos sectores como el de seguros o el financiero este tipo de prácticas no estarían bien vistas y pueden acarrear multas o pérdidas económicas en el caso de un fallo. Los controles tienen sentido y es mejor hacer la revisión de los mismos de cara a no ocasionar demoras en los ciclos de DEVOPS.

4. La evaluación de los datos

Cuando se está provisionando código a producción de manera automática, las pruebas deben ser confiables y completas. En este punto se tiene que para muchas organizaciones los datos pueden ser un problema porque no se tienen la cantidad o calidad adecuadas o porque los ambientes de prueba no son lo suficientemente similares al productivo. Muchas organizaciones se han enfrentado a esta situación y se tiene que la falta de datos para usar en las pruebas de código puede demorar drásticamente el trabajo. Esto de cara a un ambiente de trabajo ágil representa un inconveniente. De cara al Testing Agile se tiene que no contar con los datos correctos en un período inferior a la duración de un Sprint pues obviamente es un obstáculo grave. Ahora bien existen opciones para mejorar la situación y se requiere de recursos y personas que trabajen en pro de resolver esta situación. Por otro lado se habla de la metodología Dataops como una opción para este problema, su resultado es una mayor velocidad, pruebas más fuertes y más creatividad. Los desarrolladores ahora saben que pueden acceder rápidamente a los datos necesarios para las pruebas y no sentirán que han perdido demasiado tiempo si la innovación no ocurre.

5. Apostar por las herramientas correctas

Existen sin duda alguna otros obstáculos en torno a la tecnología necesaria para tener éxito con DevOps. El desafío es integrar código, encontrar las fallas rápidamente y enlazar DevOps con las tecnologías previas. Para ello se ha encontrado en la integración continua, producción continua y en el trabajar en un entorno cada vez más automatizado la opción para salir avante frente a este reto.

Las herramientas son una barrera potencial. Los líderes de TI deben asegurarse de que sus equipos estén cómodos con las herramientas de DEVOPS como las herramientas de administración de la configuración, las plataformas de producción continua y las pruebas automatizadas. También deben saber cómo la organización decidirá qué herramientas usar, cómo serán administradas y si necesitan limitar cuántas herramientas diferentes se deben usar dentro de la organización. Además, los líderes de TI deberían estar atentos a qué herramientas tienen sentido para el futuro, y cuáles no, para no quedar rezagados prontamente o hacer una alta inversión y tener que desecharla rápido. Como resumen puede decirse que es un desafío encontrar las herramientas adecuadas y la industria está cambiando muy rápido.

En este punto también sucede otra cosa y es que los ejecutivos de las organizaciones no siempre dan a los equipos la capacidad y el tiempo de jugar de manera efectiva y experimentar con herramientas o productos. Esto obviamente puede hacer que se incurran en costos innecesarios dado se puede invertir en una herramienta que luego se reemplaza por otra freeware u opensource.

En PMPMedellin concluimos en este artículo que DEVOPS tiene múltiples beneficios pero lo más importante es resolver los obstáculos que mencionamos con las sugerencias que se plantean en el mismo. Esperamos que haya sido de su agrado y que sea compartido con sus conocidos y amigos.

Autor: Ing.Javier León Reyes
Twitter e Instagram: @PMPMedellin