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

Nada en Agile cambia la forma en que debería funcionar el desarrollador principal. Deben involucrar al resto del equipo en las decisiones de arquitectura del sistema y dirección técnica, independientemente del modelo de desarrollo que se esté siguiendo.

La distribución de decisiones por edicto es una manera terrible de ejecutar cualquier equipo de desarrollo. Agile simplemente hace que la compra por parte 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 intenten mantenerlo todo junto, todavía hay una visión y dirección unificadas que deben establecerse.

En un equipo ágil, se supone que todos deben dejar de lado sus egos.

Si un miembro de un equipo ágil tiene más experiencia que los otros, lo que probablemente sucederá es que el miembro experimentado participará en la mayoría de las revisiones de código y las personas a menudo se someterán a la experiencia de esa persona al tomar decisiones en 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 respuesta de Ryathal :

Hablas sobre el diseño emergente y la dirección del equipo como si fluyeran del equipo en perfecta armonía y armonía. Grupos de personas, grupos de programadores especialmente tienen conflicto . Como líder del equipo, su trabajo en un equipo ágil es más un árbitro o un catalizador que en una cascada. Cuando el equipo tiene conflictos sobre qué diseño usar, por ejemplo, se asegurará de que las personas tengan la misma opinión y se apegue a discutir sobre los méritos. Y terminas siendo el árbitro para 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 formar un grupo de personas. Aún debe establecer un ejemplo en lo que respecta a la buena codificación y, a menudo, imponerlo (ya sea directamente o creando una cultura para hacerlo). Necesitas facilitar la comunicación entre todos los miembros de tu equipo, porque una vez al día en el standup no se va a cortar.

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 personas 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. Usted es el punto de contacto para que no sean interrumpidos por personas que se detienen directamente. Y trabajas para obtener información del mundo exterior (en qué otros equipos están trabajando, cómo se ven los equipos ágiles en el próximo sprint, cuál es el estado de ese requerimiento abierto, etc.), hazlo para ellos y comunícalo.

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 se basará en el diseño emergente, en lugar de en el frente.

Nada acerca de su definición de desarrollador líder dice que el diseño debe tenerse por adelantado. Puede establecer la dirección, y aún puede presentar 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 líder dice que él dicta el diseño. A pesar de que puede tener la última palabra, solo un líder pobre ignorará por completo los pensamientos de sus compañeros de equipo mayoritarios. Por otro lado, solo un equipo pobre ignoraría completamente 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 conductor no establezca esta dirección inicialmente. El liderato es parte de este equipo ágil. Incluso en un entorno no ágil, solo un líder deficiente continuaría dirigiendo a un equipo en dicha dirección cuando se ha vuelto impracticable a sabiendas, o cuando se ha 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 colegas ingenieros de software qué hacer? ¿Es tu experiencia? ¿Es el pequeño título divertido que tu jefe te entregó? ¿Es tu ego? ¿Tu permanencia en la empresa? ¿Es tu "panache"? ¿Tu estilo?" Tus "habilidades de liderazgo?"

Los equipos ágiles no se entregan insignias ni sombreros entre ellos que dicen "Felicidades, eres nuestro súper genio, eres el único autorizado para hacer el trabajo súper secreto del doble genio". Más bien, el enfoque es EL TRABAJO A MANO. Si realmente tiene más experiencia, entonces esa experiencia debería MOSTRAR en qué tan bien sus diseños impulsan el trabajo hacia su finalización. Sus asignaciones (tarjetas) autoelegidas deben reflejar las áreas en las que es más experto. Por otro lado, si algún niño recién salido de la universidad tiene una mejor idea y se ajusta al contexto mejor que algo que surja un veterano de 40 años con, ¿por qué demonios iríamos con el diseño más pobre? Nuestros lugares de trabajo no son oficinas de terapia, son el lugar donde construimos grandes cosas.

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

Entonces, ¿qué pasa con el "líder del equipo de desarrollo?" en agile? Nada, es mejor que estén a la altura de ese nombre, es mejor que realmente puedan producir mejor software que las demás personas del equipo. De lo contrario, no hay razón para llamarlos "líderes", es solo una pequeña insignia o un sombrero divertido, y no tiene sentido. Mucha gente encuentra esto amenazante. Sienten que han estado "trabajando para" una insignia o un sombrero divertido. Los buenos desarrolladores no funcionan para sombreros divertidos. Trabajan para crear un gran software y planean hacerlo hasta que crezcan: su objetivo es mejorar en la construcción de software, todos los días. Si ese no es usted, tal vez quiera examinar la gestión de proyectos. Probablemente seas más feliz.

En mi experiencia con Agile, el equipo de desarrollo en su conjunto tiene menos responsabilidad de lo que sus ejemplos implican, dejando que el desarrollador y arquitecto principal coordine las opciones de diseño de nivel superior, pero entregue el diseño de nivel inferior al equipo ágil como un todo.

Por lo tanto, el desarrollador líder sigue siendo responsable de la arquitectura del sistema y las opciones tecnológicas. Esto es muy importante: aunque ágil fomenta el diseño emergente y la refactorización, esto debería suceder a nivel de objetos de código. El sistema en su conjunto debe 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 ágil 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 al alcance de las reuniones de planificación por lo demás aburridas.

También funcionó como el punto de ú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.