¿Cuál es el papel del desarrollador principal en un equipo ágil?

En un equipo de desarrollo no ágil, un desarrollador líder generalmente :

• Establece el estándar (codificación y demás)
• Investiga nuevas tecnologías para el equipo.
• Establece la dirección técnica del equipo.
• Tiene la última palabra sobre asuntos
• Diseña la arquitectura de un sistema.

Sin embargo, un equipo ágil funciona de manera diferente:

• Un equipo ágil dependerá de un diseño emergente, en lugar de desde el principio
• Un equipo ágil diseña en conjunto, en lugar de que el diseño sea dictado por una sola persona.
• Un equipo ágil decide su propia dirección técnica, lo que es mejor para entregar un proyecto.

¿Dónde deja esto a un desarrollador líder en un equipo ágil? ¿Es posible tener un desarrollador líder en un equipo ágil? ¿Un equipo ágil exige diferentes responsabilidades de un líder?

Nada en ágil cambia cómo debería funcionar el desarrollador principal. Deben involucrar al resto del equipo con las decisiones de arquitectura del sistema y la dirección técnica, sin importar el modelo de desarrollo que se siga.

Repartir decisiones por edicto es una forma terrible de ejecutar cualquier equipo de desarrollo. Agile solo hace que la compra del resto del equipo sea un proceso más explícito, y un desarrollador líder debería haber estado haciendo eso de todos modos.

El hecho de que no haya un rol de desarrollador líder establecido en una metodología scrum no significa que las opiniones de los programadores más experimentados no sean las más respetadas. Agile no permite que todos se vuelvan locos por sí mismos y luego intenta mantener todo junto, todavía hay una visión y dirección unificadas que deben establecerse.

En un equipo ágil, todos deben dejar a un lado sus egos.

Si un miembro de un equipo ágil tiene más experiencia que los demás, lo más probable es que el miembro experimentado participe en la mayoría de las revisiones de código y las personas a menudo diferirán de la experiencia de esa persona al tomar decisiones del equipo.

Por lo tanto, un desarrollador "líder" continuará "liderando", pero como consecuencia natural de su experiencia y no como una función obligatoria de su título.

Eso es en un mundo ideal donde las personas pueden dejar de lado sus egos. ¡Buena suerte!

Además de la respuesta de Ryathal :

Usted habla sobre el diseño emergente y la dirección del equipo como si fluyeran del equipo al unísono y armonía perfectos. Grupos de personas, grupos de programadores especialmente tienen conflictos . Como líder del equipo, su trabajo en un equipo ágil es más un árbitro o catalizador que en cascada. Cuando el equipo tiene un conflicto sobre qué diseño usar, por ejemplo, se asegurará de que las personas tengan la misma opinión y se peguen por los méritos. Y terminas siendo el árbitro de la solución propuesta con la que irá el equipo cuando el camino no esté claro.

Esta es una de las responsabilidades más importantes del líder, pero se necesitan muchas otras cosas para hacer que un grupo de personas formen un equipo. Todavía necesita dar un ejemplo en lo que respecta a la buena codificación y, a menudo, aplicarlo (ya sea directamente o creando una cultura para hacerlo). Debe facilitar la comunicación entre todos los miembros de su equipo, porque una vez al día en standup no va a cortarlo.

La otra cosa importante que has pasado por alto son las reuniones. No es práctico llevar a todo el equipo a todas las reuniones donde el equipo necesita interactuar con gente de negocios, otros equipos técnicos, etc. Como líder del equipo, usted es el representante del equipo. Usted va a las reuniones para que puedan quedarse en sus escritorios y hacer las cosas. Eres el punto de contacto para que no sean interrumpidos por personas que se detienen directamente. Y trabajas para tomar información del mundo exterior (en qué están trabajando otros equipos, cómo se ven los equipos ágiles el próximo sprint, cuál es el estado de esa solicitud abierta, etc.), la reducen y se la comunican.

En resumen, usted es el lubricante para asegurarse de que puedan funcionar sin problemas.

Su descripción no ágil no invalida su descripción ágil.

Un equipo ágil dependerá de un diseño emergente, en lugar de desde el principio.

Nada acerca de su definición de desarrollador principal dice que el diseño se debe tener por adelantado. Puede establecer la dirección, y aún puede diseñar un diseño inicial. Ese diseño es definitivamente emergente.

Un equipo ágil diseña en conjunto, en lugar de que el diseño sea dictado por una sola persona.

Nada acerca de su definición de desarrollador principal dice que dicta el diseño. Aunque puede tener la última palabra, solo un pobre líder ignoraría por completo los pensamientos de sus compañeros de equipo mayoritarios. Por otro lado, solo un equipo pobre ignoraría por completo los pensamientos del desarrollador principal.

Un equipo ágil decide su propia dirección técnica, lo que es mejor para entregar un proyecto.

Nuevamente, esto no significa que el líder no establezca inicialmente esta dirección. El líder es parte de este equipo ágil. Incluso en un entorno no ágil, solo un líder pobre continuaría haciendo avanzar a un equipo en dicha dirección cuando se haya vuelto inviable a sabiendas o cuando se haya presentado nueva información para invalidar esta dirección.

La pregunta plantea algunas otras preguntas. ¿Qué crees que te califica para decirle a un equipo de ingenieros de software compañeros qué hacer? ¿Es tu experiencia? ¿Es el pequeño título divertido que te dio tu jefe? ¿Es tu ego? ¿Tu mandato en la empresa? ¿Es tu "garbo"? ¿Tu estilo?" ¿Tus "habilidades de liderazgo"?

Los equipos ágiles no se entregan insignias o sombreros entre ellos que dicen "Felicitaciones, eres nuestro super genio, eres el único al que se le permite hacer un trabajo super secreto de doble genio". Más bien, el enfoque es EL TRABAJO A MANO. Si realmente tiene más experiencia, entonces esa experiencia debería MOSTRAR cuán bien sus diseños impulsan el trabajo hacia la finalización. Tus tareas (tarjetas) elegidas por ti mismo deben reflejar las áreas en las que eres más experto. Por otro lado, si algún niño que acaba de salir de la universidad tiene una mejor idea y se ajusta mejor al contexto que algo que surja un veterano de 40 años con, ¿por qué demonios iríamos con un diseño más pobre? Nuestros lugares de trabajo no son oficinas de terapia, son donde venimos para construir grandes cosas.

Eso plantea otra pregunta: ¿quién decide qué significa "mejor"? La respuesta: el equipo de partes interesadas. Eso significa que los desarrolladores, personas de requisitos, evaluadores, empresarios, etc., que son los constructores y usuarios de la cosa en cuestión. Si tienes una gran idea, será mejor que puedas demostrar por qué es mejor. Si no puede hacer eso, entonces no hay razón para que el equipo crea que su idea es mejor. Ágil fomenta la meritocracia.

Entonces, ¿qué pasa con el "líder del equipo de desarrollo"? en ágil? Nada, es mejor que estén a la altura de ese nombre, que REALMENTE puedan producir mejor software que las otras personas del equipo. De lo contrario, no hay razón para llamarlos "protagonistas": es solo una pequeña placa o un sombrero divertido, y no tiene sentido. Mucha gente encuentra esto amenazador. Sienten que han estado "trabajando para" una insignia o un sombrero gracioso. Los buenos desarrolladores no trabajan para sombreros divertidos. Trabajan para construir un excelente software, y planean hacerlo hasta que croan: su objetivo es mejorar en la creación de software, todos los días. Si ese no es usted, tal vez desee examinar la gestión de proyectos. Probablemente serás más feliz.

En mi experiencia con Agile, el equipo de desarrollo en su conjunto tiene menos responsabilidad de lo que implican sus ejemplos, dejando que el desarrollador y el arquitecto líder coordinen las opciones de diseño de nivel superior, pero transmitiendo el diseño de nivel inferior al equipo ágil en general.

Por lo tanto, el desarrollador principal sigue siendo responsable de la arquitectura del sistema y las opciones de tecnología. Esto es muy importante: aunque ágil fomenta el diseño emergente y la refactorización, esto debería estar sucediendo a nivel de los objetos de código. El sistema en su conjunto necesita tener un mayor nivel de diseño previo y rigidez, de lo contrario, el proyecto corre el riesgo de convertirse en un desastre descoordinado.

En nuestro proyecto, el desarrollador principal ordenó las opciones de tecnología y diseñó cómo los componentes del sistema interactuarían entre sí. Las reuniones de planificación ágiles se centraron en cómo diseñar esos componentes dentro de sus mandatos de nivel superior. Como un lado agradable, esto mantiene un límite de alcance en reuniones de planificación que de otro modo serían aburridas.

También funcionó como el último recurso. Cuando los programadores individuales se encontraban con problemas que no podían solucionar, iban a la cabeza y la responsabilidad final de arreglar las cosas era suya.