Se trata de un cambio cultural que enfatiza el papel de las personas y la forma en que colaboran – especialmente entre departamentos-, que utiliza metodologías ágiles y que aprovecha un conjunto de tecnologías tales como herramientas de automatización, cloud, microservicios… y lo hace con una perspectiva que abarca el ciclo de vida del software; es decir, desde su creación hasta su uso.
Lo primero que uno debe saber sobre Devops es que requiere un cambio cultural que fomenta la colaboración y se centra en las personas. Así que obviando la parte de orquestación de tecnología, personas y procesos en la que se centran los modelos de madurez existentes en el mercado, primero va ha necesitar un impulso desde arriba para definir una misión y fomentar la colaboración entre equipos multidisciplinares dentro de una nueva estructura organizativa.
Algunos aspectos a considerar serán:
Misión: Debe existir una definición clara de cuál es la misión. Ésta debe ser lo suficientemente amplia para dar cabida a diferentes perfiles y, por otro, establecer un propósito de negocio para poder sortear problemas ocasionales que permitan mantener un flujo continuo de inversión.
Comunicación: Para que la colaboración sea buena se debe establecer una comunicación efectiva entre equipos multidisciplinares a través de un vocabulario compartido.
Multidisciplinario: Los componentes del equipo deben adquirir un conocimiento de otras áreas más allá del propio ámbito de especialización ( desarrollo de habilidades T Shaped).
Innovación: La innovación que empuja el área de desarrollo debe ser compatible con la búsqueda de estabilidad de operaciones, para ello será necesario trascender la mentalidad confinada a cada área y adquirir otra centrada en la resolución de problemas.
Empatia: fomentar un entorno y unas reglas informales que desarrollen la empatía.
Seguimiento: Tendrá que medirse el impacto generado en términos de negocio para entender cuáles
son los progresos y servir de acicate para una mejora continua.
El desarrollo de software, debe pasar por un flujo continuo de interacciones en un bucle de retroalimentación constante. Por ejemplo, el auto no es la suma de sus partes, es el producto de la interacción de las mismas. Pues bien, del mismo modo el software no es la suma de desarrollo, despliegue, operaciones… sino la suma de la interacción de todas ellas.
No siempre un mayor número de interacciones se traducirá en una pérdida de agilidad, si se incorpora una mayor automatización y se establece un marco de colaboración efectiva que “rompa” unos silos organizativos pensados para un desarrollo secuencial, en cascada.
La estructura de costes ha cambiado, porque cuanto más tarde se detecten los fallos en el software, mayores serán los costes derivados. Frente a estos costes deben contraponerse los de evitar
que se produzcan fallos y corregirlos llegado el caso. Al final, los costes totales tienen forma de “V” (los costes de “evitar” e “incurrir” se mueven en sentido opuesto en el tiempo). Sin embargo, ahora el punto donde se minimizan ha cambiado: las correcciones ya no tienen que esperar a ser acumuladas aprovechando nuevas versiones y actualizaciones. Además, existe la posibilidad de descomponer
el software en fragmentos más pequeños y volver a recomponerlo con facilidad o aprovechar las
ventajas que otorga el modelo cloud.
Implantar Devops será complejo y llevará tiempo, porque va a necesitar el uso de nuevas herramientas, cambiar comportamientos, adquirir nuevas habilidades, modificar workflows... y, envolviéndolo todo, será necesario un cambio cultural.
QUE NO ES DEVOPS
1. DevOps no es un puesto de trabajo. dijo el consultor de Agile, Scott Ambler. DevOps no debe ser un rol laboral, dijo. "DevOps se trata de que los desarrolladores entiendan la realidad de las operaciones y de que el equipo de operaciones comprenda lo que involucra el desarrollo.". "Pero el puesto de DevOps es un síntoma de que las organizaciones que contratan [gerentes de DevOps] no entienden lo que DevOps es realmente. Ellos no lo entienden todavía."
2. DevOps no es una categoría de herramienta de software. DevOps no se trata de herramientas, sino de cultura, dijo Patrick Debois en una presentación titulada “DevOps: tonterías, herramientas y otras cosas inteligentes”, durante la Conferencia GOTO. Debois, quien acuñó el término "DevOps" y fundó una conferencia conocida como DevOpsDays, dijo que las herramientas juegan un papel importante en el apoyo al enfoque de DevOps para la entrega y la gestión de software, pero DevOps no se trata de las herramientas en sí.
3. DevOps no se trata de resolver un problema de TI. DevOps es ampliamente entendido como una forma de resolver un problema de TI: permite que desarrollo y operaciones colaboren en la entrega de software. Pero ese no es su objetivo final, dijo Damon Edwards, socio gerente de consultoría de TI, Soluciones DTO. "El punto de DevOps es permitirle a su empresa reaccionar ante las fuerzas del mercado lo más rápido, eficiente y confiable como sea posible. Sin el negocio, no hay otra razón para que estemos hablando de problemas DevOps, mucho menos pasar tiempo resolviéndolos", escribió Edwards escribió en su blog.
4. DevOps no es sinónimo de integración continua. DevOps se originó en Agile como una forma de apoyar la práctica ágil de liberaciones de código más frecuentes. Pero DevOps es más que eso, dijo Ambler. "El hecho de que se practique la integración continua no significa que se está haciendo DevOps." Él ve a los gerentes de operaciones como los principales interesados que los equipos ágiles necesitan trabajar para liberar software.
No hay comentarios:
Publicar un comentario