Ley de Brooks: Agregar mano de obra a un proyecto de software tardío lo hace más tarde.
En su libro No Silver Bullet - Esencia y accidentes de ingeniería de software, Frederick Brooks define el concepto del Mes del Hombre Mítico :
La suposición de Brooks es que los proyectos de programación complejos no se pueden dividir perfectamente en tareas discretas en las que se pueda trabajar sin comunicación entre los trabajadores y sin establecer un conjunto de interrelaciones complejas entre las tareas y los trabajadores que las realizan .
Desde 1982 ciertamente hemos avanzado y acumulado más experiencia en la mitigación de este problema. ¿Cuáles son algunas de las soluciones que ha aplicado con éxito en su trabajo para agregar recursos a un proyecto sin crear más problemas?
fuente
Respuestas:
¿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?
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) / 2dondenestá 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 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.
fuente
Lo que he hecho (y esto es solo subjetivo) es el siguiente:
Cuando un gerente que está pensando en una fecha de vencimiento desea agregar personas a mi equipo para reducir el tiempo necesario y parece estar bajo MMM, primero discuto con él o ella sobre por qué esto podría ser malo. Mi analogía favorita para esto es recordarles que si una mujer puede tener un bebé en nueve meses, nueve mujeres no tendrán un bebé en un mes, pero tendrán nueve bebés en nueve meses. El tiempo no se corta, solo el procesamiento paralelo es mejor.
Cuando la decisión se impone a nuestro equipo, generalmente tratamos de dividir aún más algunas tareas, y cuando esto no es posible, usualmente confiamos en la programación de pares , donde un programador es responsable de escribir, y el otro dicta el código (y cambia periódicamente) )
La escritura del código en sí es más lenta, pero hay menos errores tipográficos / linting y errores al probar debido a la inevitable revisión que se realiza al escribir. Siento que la calidad general del código también es un poco mejor, pero no tengo métricas para respaldar esa afirmación.
fuente
Hablando exclusivamente desde una perspectiva de CI, aumentar el número de desarrolladores que trabajan en un proyecto generalmente se traduce en más personas que trabajan en la misma rama.
Los sistemas de CI tradicionales tienen un problema de escalabilidad a este respecto: la probabilidad de roturas / regresiones / bloqueos aumenta la desaceleración de la velocidad de integración e invita a los equipos más pequeños a interrumpir y pasar a las ramas secundarias (es decir, más ralentizaciones). Vea ¿Cómo puede la integración continua escalar para proyectos / equipos muy grandes? . Esto juega a lo largo del concepto del Mes Mítico del Hombre.
La solución que sugiero en mi respuesta a esa pregunta, un sistema de CI altamente escalable permitiría la migración hacia un verdadero CI: integración basada en una sola rama / troncal para equipos enteros más grandes (incluso con grandes tamaños).
Con todos en la misma página, utilizando las mismas herramientas / procesos automatizados y la gran mayoría de las verificaciones de control de calidad automatizadas dentro del propio sistema de CI, es mucho más fácil cambiar los roles y centrarse entre los miembros del equipo. Todo el proceso de desarrollo se vuelve más suave, más predecible, más relajado.
Traer nuevas personas a bordo en un entorno así, hacerlos productivos simplemente descargando las tareas menos difíciles de los miembros del equipo más experimentados que luego pueden asumir las más difíciles es, por lo tanto, más fácil.
Todo esto puede verse, creo, como relajante de los efectos conceptuales del Mes Mítico del Hombre.
fuente
Having them all communicate via a single integration branch is an anti-pattern- ¿por qué? Si están desacoplados en el sentido de que ya no necesitarán integrar su trabajo, entonces tocarán la rama de una manera no superpuesta / no conflictiva. Si su trabajo aún necesita ser integrado, entonces continuar con sucursales adicionales solo retrasará y complicará la integración al desviarse de la metodología de CI y perder todas sus ventajas.mainrama o 10 repositorios uno al lado del otro (¿módulos git?) Cada uno con unamainrama debería ser más o menos equivalente de la perspectiva de CI.