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

42

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?

Peter Bridger
fuente
Respondiendo Matts último comentario, agregaría que el desarrollador principal debería ser el que tome las decisiones arquitectónicas clave que afectan a muchos componentes del sistema. También está en el que lleva esta responsabilidad y debería cambiar de opinión si las cosas van mal.
user2236631

Respuestas:

46

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.

Ryathal
fuente
¿Puede agregar alguna aclaración a lo que quiere decir con "entregar decisiones por edicto es una forma terrible de ejecutar cualquier equipo de desarrollo"? Estoy de acuerdo con el resto de tu publicación, pero solo estoy de acuerdo con la declaración mencionada de ciertas maneras, pero no de otras. Por ejemplo, ¿cómo se decidiría usar SOA en un nivel de base de datos? ¿No habría sido un edicto o alguien no tendría la última palabra? Pregunto porque soy un líder de equipo y me encontré con esta situación. Hice una llamada para no usar SOA en función de las necesidades comerciales. Simplemente no hay tiempo suficiente para permitir que todos los desarrolladores discutan / discutan cada punto.
Brian
@Brian tomar decisiones de arquitectura sería una historia en un sprint, probablemente una destinada a un miembro específico, pero por lo demás igual a cualquier otra historia. Debe ser sometido a una revisión por pares como cualquier otra historia. El argumento del tiempo es una mierda, si te perdiste X o decidiste probar Z para que todos los demás miembros del equipo no estén familiarizados contigo, como resultado, pasarás más tiempo desarrollando, incluso un día completo discutiendo sobre el diseño sería insignificante comparativamente . Una reunión / revisión simple para decir "Elegí A porque X, Y, Z". probablemente tomaría una hora y conseguiría que fuera un esfuerzo de colaboración.
Ryathal
30

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!

MetaFight
fuente
No estoy de acuerdo Con demasiada frecuencia he visto una decisión precipitada tomada por un desarrollador por su cuenta con malas consecuencias solo porque el líder no estaba allí y el desarrollador no estaba acostumbrado a tal situación. Pastoreando gatos, te digo.
andrew.fox
20

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.

Telastyn
fuente
1
Esto es especialmente importante en las reuniones que están "Timeboxed", lo que significa que la reunión, o discusión específica, no durará más de X minutos. Al final del tiempo, alguien toma la decisión y mantiene el proceso en movimiento. Este podría ser un desarrollador principal para la arquitectura del sistema y las discusiones relacionadas.
Chris
1
Así poner. Un desarrollador líder también debe estar orientado a mejorar la experiencia y la comprensión del equipo en el que se encuentra, con un plan a largo plazo que no sea solo ser un 'líder' sino un miembro de un equipo de pares.
David 'el jengibre calvo'
Lo que has descrito es un ScrumMaster.
DBedrenko
6

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.

BrandonV
fuente
6

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.

Calphool
fuente
+1 para "EL TRABAJO A MANO". Estoy de acuerdo en centrarme en la mejor solución para lo que tiene que ofrecer ahora. No se trata de a quién se le ocurre la idea.
Kwebble
Si todo lo que un líder de equipo desarrollado hace en un equipo SCRUM según usted es "producir un mejor software que las otras personas en el equipo", entonces todo lo que son es un desarrollador sin responsabilidades distintivas. ¿Es ese el punto sugerido por su respuesta? De lo contrario, esto realmente no responde a la pregunta de cómo un líder de desarrollo encaja en un equipo SCRUM.
DBedrenko
Si lo hace Son buenos ingenieros, por lo que tienen el rol de ingenieros (técnicamente, un "miembro del equipo"). ¿Qué más serían?
Calphool el
3

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.

Bob Tway
fuente
Esto es similar a mi experiencia, pero de hecho creo que hay más "insignias" y "sombreros" de los necesarios. Casi no hay diferencia entre cómo un buen desarrollador piensa sobre un diseño y lo que piensa un arquitecto sobre un diseño.
Calphool