En esta serie de post (Tipologías de equipos software (I). El equipo “Control y Mando” y Tipologías de equipos software (II). El equipo cirujano) en la que estamos recorriendo, cronológicamente, las diferentes maneras de organizar un equipo software, ante de llegar al cuarto y último post de la serie, que tratará sobre el equipo ágil, como evolución del aprendizaje, de los errores y aciertos, de los equipos “Control y Mando” y “Cirujano”, casi como paso intermedio a este, vamos a analizar varios patrones y buenas prácticas sobre organización de equipos software.
Patrones….
Ya sabes, si pasas más o menos con frecuencia por este nuestro blog, que te habré comentado por aquí mi época leyendo todo lo que había sobre patrones en diseño software. Llevado a ello por el trabajo, y porque me dio por hacer la tesis doctoral sobre el tema.
Con el tiempo, el movimiento de los patrones, tan de moda años atrás, sin tener hoy el glamour de otras palabras más populares en el mundo del software patrio, no sólo se ha mantenido vivo, en silencio, sino que se ha ampliado a otras muchas áreas, como, por ejemplo, la agilidad.
Simplificadamente, citando la definición clásica, los patrones son buenas soluciones, extraídas de la experiencia, a problemas recurrentes en un contexto específico. Veamos algunos sobre equipos, en nuestro recorrido hacia el equipo ágil (próximo y último post de la serie)
Y si quieres profundizar en los siguientes, el libro a leer es Organizational Patterns of Agile Software Development.
Patrones organizativos: De 3 a 7 ayudantes máximo por rol
Una evolución, en la misma línea, de lo que decía el equipo cirujano, que hay que controlar el “desperdicio” (en terminología Lean) de los canales de comunicación. El equipo cirujano se centraba mucho en el cirujano, el programador jefe, y este patrón extiende la idea a todo el equipo.
Si ves un equipo como una red de comunicaciones entre miembros, intenta que la red no supere a 7 personas, por persona, con las que comunicarse
Patrones organizativos: El arquitecto también programa
Igualmente, como evolución a las ideas del el equipo cirujano, el arquitecto no es sólo alguien que toma decisiones de diseño en papel, es alguien que además está muy en contacto y metido en la implementación, lo cual ayuda a que tenga sensaciones reales de qué está pasando para tomar decisiones correctas.
Patrones organizativos: pon un “firewall” frente al equipo
Otra de esas ideas tomadas, y repetidas, en el mundo ágil, el efecto que tiene en la productividad la distracción y la interrupción (en su día le dedique un post Interrumpir a quien programa, o al que realiza cualquier actividad intelectual, hace que su productividad caiga (mas de lo que imaginas)
Por ello, este patrón habla de que debe haber un rol dedicado a evitar las interrupciones. Originariamente se le llamaba “manager”, hoy, en el mundo ágil, será responsabilidad en parte del Product Owner y en parte del Scrum Master.
Patrones organizativos: permite que clientes y desarrolladores se relacionen
La mayoría de las organizaciones son reacias al contacto directo entre desarrolladores y clientes, temiendo que los desarrolladores prometan entregar cosas fuera de contrato, irrealizables, etc.
Sin embargo, como conocer todos los requisitos y su detalle es casi imposible, los desarrolladores necesitan información de los clientes a lo largo del proyecto.
Muchas organizaciones utilizan comerciales parasolucionar este problema y evitar un contacto entre desarrollo y clientes. Pero estos no conocen la parte técnica, sólo hacen de filtro, introducen errores, etc.
Desarrolladores y arquitectos deben hablar libremente, y con frecuencia, con los clientes. Y para evitar el “descontrol” haz uso del patrón un “firewall” frente al equipo.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024