¿Qué es el MMM?
Primero quiero explicar el contexto de la Ley de Brook. ¿Cuál fue la suposición que lo hizo crearlo en 1975?
Un hombre-mes es una unidad de trabajo hipotética que representa el trabajo realizado por una persona en un mes; La ley de Brooks dice que es imposible medir el trabajo útil en meses-hombre.
fuente: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
En el pasado, los proyectos de programación complejos significarían grandes sistemas monolíticos. Y Brooks afirma que no se pueden dividir perfectamente en tareas discretas en las que se pueda trabajar sin comunicación entre los desarrolladores y sin establecer un conjunto de interrelaciones complejas entre las tareas y las personas que las realizan.
Esto es muy cierto en los monolitos de software altamente cohesivos. No importa cuánto se desacople, el gran monolito exige tiempo requerido para que los nuevos programadores aprendan sobre el monolito. Y mayor sobrecarga de comunicación que consumirá una cantidad cada vez mayor del tiempo disponible.
Pero, ¿realmente tiene que ser así? ¿Tenemos que escribir monolitos y mantener canales de comunicación n(n − 1) / 2donde nestá el número de desarrolladores?
Sabemos que hay compañías donde miles de desarrolladores están trabajando en grandes proyectos ... y funciona. Entonces debe haber algo que cambió desde 1975.
Posibilidad de mitigar el MMM
En 2015, PuppetLabs y IT Revolution publicaron los resultados del Informe de estado de DevOps de 2015 . En ese informe, se centraron en la distinción entre organizaciones de alto rendimiento y no de alto rendimiento.
Las organizaciones de alto rendimiento muestran algunas propiedades inesperadas. Por ejemplo, tienen el mejor rendimiento de fecha de vencimiento del proyecto en desarrollo. La mejor estabilidad operativa y confiabilidad en las operaciones. Además del mejor historial de seguridad y cumplimiento.
Una de las cosas sorprendentes destacadas en el informe es la métrica de implementaciones por día. Pero no solo las implementaciones por día, sino que también midieron la implementación / día / desarrollador y cuál es el efecto de agregar más desarrolladores en organizaciones de alto rendimiento frente a las de bajo rendimiento.
Este es el gráfico de ese informe:
Mientras que las organizaciones de bajo rendimiento se alinean con los supuestos del Mes del Hombre Mítico. Las organizaciones de alto rendimiento pueden escalar la cantidad de implementación / día / desarrollo linealmente con la cantidad de desarrolladores.
Una excelente presentación en DevOpsDays London 2016 por Gene Kim habla sobre estos hallazgos.
Cómo hacerlo
Primero, ¿cómo convertirse en una organización de alto rendimiento? Hay un par de libros que hablan sobre esto, no hay suficiente espacio en esta respuesta, así que solo los enlazaré.
Para las organizaciones de software y TI, uno de los factores críticos para convertirse en una organización de alto rendimiento es: centrarse en la calidad y la velocidad .
Por ejemplo, Ward Cunningham explica la Deuda técnica como todas las cosas que permitimos dejar sin reparar. Esto es aceptado por la gerencia porque siempre viene con la promesa de que se solucionará cuando haya tiempo.
Nunca hay tiempo suficiente, y la deuda técnica empeora cada vez más.
¿Cuáles son estas cosas que hacen crecer la deuda técnica?
- código heredado
- configuración manual de ambientes
- prueba manual
- implementaciones manuales
Código heredado Según lo definido en Trabajar eficazmente con código heredado por Michael Feathers es cualquier código que no tenga pruebas automatizadas.
En cualquier momento se utilizan atajos para llevar el código a producción; Las operaciones están cargadas con el mantenimiento de esta deuda para siempre. Entonces el proceso de despliegue se hace más y más largo.
Gene cuenta una historia en su presentación sobre una compañía que tiene implementaciones de seis semanas. Involucrando a decenas de miles de pasos tediosos extremadamente propensos a errores, atando a 400 personas, y lo harían cuatro veces al año.
Uno de los principios de DevOps es que la confiabilidad proviene de realizar implementaciones más pequeñas con mayor frecuencia.
Ejemplo
Estas dos presentaciones muestran todo lo que Amazon hizo para disminuir el tiempo que les lleva implementar el código en producción.
Según Gene, lo único que cambia con el tiempo en estas organizaciones de alto rendimiento es la cantidad de desarrolladores. Entonces, a partir del ejemplo de Amazon, se podría decir que en cuatro años aumentaron sus implementaciones diez veces simplemente agregando más personas.
Esto significa que bajo ciertas condiciones, con la arquitectura correcta, las prácticas técnicas correctas, las normas culturales correctas, la productividad del desarrollador puede escalar a medida que aumenta el número de desarrolladores. Y DevOps definitivamente está en el medio de todo esto.