“If a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming” — Brooks
Fue un tal Mills quien le dio el nombre, pero fue Brooks, en su ya tan famoso y tan mencionado libro The Mythical Man Month, quien lo popularizó: el equipo tipo cirujano.
La idea es organizar grandes proyectos de desarrollo de software en varios «equipos q
uirúrgicos». Cada equipo está dirigido por un jefe de programación, que vendría a ser el cirujano, que hace el trabajo delicado. Y que cuenta con un equipo de especialistas de apoyo.
Esta tipología, que aparece en los 70, contempla varias características que hoy consideramos necesarias en un equipo de desarrollo “moderno”, llámalo ágil: el equipo es pequeño (menos de 10 personas) y multifuncional (por ejemplo, el tester es un perfil dentro del equipo, de apoyo al “cirujano jefe”, y no un departamento aparte).
Brooks justifica el uso de esta tipología en dos conceptos típicos a la hora de hablar de equipos software:
El tamaño en número de personas. Si lees con frecuenta los post de este blog, sabrás que siempre que sale algo de quipos sale el tema del número de personas ideal, tema obligado a tratar (recuerda lo de por qué los equipos con mucha gente (más de 7) son menos productivos. O por qué tener equipos pequeños es una buena práctica (ágil, además). Como bien decía Brooks, el principal problema de los grandes proyectos de desarrollo de software es la comunicación, más desarrolladores en el proyecto más problemas de comunicación. Por ello el equipo quirúrgico es pequeño.
Las variaciones de productividad entre programadores buenos y malos. Que Brooks argumenta citando varios estudios, que vienen a concluir en que hay una enorme brecha de productividad entre desarrolladores software. Los buenos desarrolladores son muy, muy buenos y los malos son muy, muy malos. Por ello el equipo quirúrgico se basa en tener un “cirujano”, un programador jefe, como le llama Brooks, muy muy bueno.
Es decir, sintetizando, reducir al mínimo el número de gente que toca el código y que sólo toquen los mejores, dándoles los apoyos que necesitan.
Pero, claro, nada tiene solo cosas positivas en este mundo. Y la principal crítica que ha tenido el equipo “quirúrgico” viene de la dependencia que tiene el equipo, hasta la organización, del “cirujano jefe”. Algo que los equipos ágiles, que se basan mucho en las ideas expuestas por Brooks, intentan mermar con, como te contaba en ¿Es posible evitar que solo unas pocas personas tengan el 100% del conocimiento de un proyecto?, numerosas prácticas como aquellas del “Shared understanding”: Coding standard (buenas prácticas de programación), Collective code ownership (que todo el código sea de todo el mundo), Simple design (mantenlo simple) y System metaphor (que se pueda explicar con facilidad).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024