¿Cómo podemos hacer que sea ágil para los desarrolladores a los que les gusta tener grandes porciones de manera personal e independiente de principio a fin?

Diré que hay muy pocas tiendas de software que son lo suficientemente afortunadas como para tener la rara distinción donde Agile realmente no tiene sentido como metodología. Si todo su equipo está formado por desarrolladores de software verdaderamente excepcionales con un profundo conocimiento de los aspectos del negocio y la longevidad con la empresa y entre sí, y si los requisitos de su negocio y los de sus clientes son siempre similares y rara vez están sujetos a cambios a mitad de camino. libérelo, entonces tiene la suerte de trabajar en un entorno tan raro en el que Agile probablemente pueda DESTACAR.

Está diseñado para ser el enfoque más efectivo en medio de requisitos comerciales caóticos y en constante cambio y las necesidades de los clientes, la evolución o el cambio de los recursos del proyecto y los plazos ajustados o cambiantes. Un entorno de este tipo supone cierto destino para el desarrollo típico en cascada, ya que es vulnerable a los cambios del equipo a mitad del proyecto, vulnerable a los requisitos cambiantes y extremadamente vulnerable a una fecha cambiante.

Lo siento por los valiosos miembros de tu equipo que ya no encuentran alegría en su trabajo. Muy bien pueden ser personas excepcionalmente talentosas que se absorben en su trabajo, pero al final, una serie de factores fuera de su mejor control aún pueden matar el proyecto. La mejor manera de enfocar el desarrollo de características es que pierdan la actitud y expresión individual y piensen en términos del enfoque de equipo.

Si encuentra que esto no funcionará para ellos, puede encontrar un uso especial para ellos. Si son excepcionalmente talentosos y experimentados, vea si estarían interesados en un papel de arquitectura, diseñando enfoques de alto nivel, experimentando con nuevas tecnologías y desarrollando las mejores prácticas. Haga que estas personas controlen y revisen la documentación de diseño.

Si esto no les conviene aún, entonces quizás haga que trabajen por separado en refactorizaciones técnicas extremadamente complejas en una rama separada, prototipos enormemente involucrados y pruebas de conceptos, u otro trabajo pionero que a veces se necesita hacer pero no encaja bien en el alcance de un solo proyecto o lanzamiento.

  

Simplemente no encuentran alegría en el trabajo como solían hacer.

Correcto.

Eso es un gran síntoma de que lo estás haciendo mal.

Agile no debería imponer un nuevo y mal orden a las personas.

Agile debería permitir que el equipo se autoorganice de una manera que lo haga más efectivo.

La autoorganización significa que la administración no impone reglas extrañas. No impone malos horarios y no impone una interacción innecesaria.

  

Algunos desarrolladores están motivados principalmente por la alegría de realizar un trabajo difícil, pensar en un diseño, analizar posibles problemas y luego resolver el problema pieza por pieza, con una interacción mínima con otros, durante un período prolongado de tiempo.

¿Por qué no pueden seguir haciendo esto?

¿Por qué cambiarlos?

Por favor lee el Manifiesto Agile unas cuantas veces.

El Manifiesto Agile dice

  

Personas e interacciones sobre procesos y herramientas

No dice que obligue a las personas a trabajar de una manera incómoda e improductiva.

Si está forzando a las personas a una "interacción" demasiado valiosa, entonces ha ido demasiado lejos.

  

Software de trabajo sobre documentación completa.

¿Están haciendo esto? Entonces déjalos en paz.

  

Colaboración del cliente sobre negociación de contrato.

¿Ya estás haciendo esto? Entonces no cambies.

  

Respondiendo al cambio siguiendo un plan.

¿Dónde estas personas ya pueden responder al cambio? Si es así, entonces ya eran ágiles. No necesitaban cambiar.

mi compañía intentó (y aún intento después de años de intentarlo) hacer la misma transición y hasta ahora personalmente, no he visto mucho éxito con ella. Durante esta transición, he leído mucho sobre desarrollo ágil y diferentes formas / aspectos / preocupaciones / técnicas y una cosa con la que estoy totalmente de acuerdo es que el desarrollo ágil puro es más adecuado cuando todo el equipo está formado por personas de alto nivel y alta calidad. (o al menos todas las personas del mismo nivel).

Último lanzamiento Estaba en un equipo "ágil" que tenía a IMHO demasiados desarrolladores con niveles de habilidad en todo el lugar e intentamos que todos participaran en el mismo proyecto. Fue un desastre. Hicimos más conversaciones / discusiones que en el trabajo, y al final lo que el equipo produjo fue un trabajo promedio (lea Peopleware o Mythical Man Month sobre cómo tomar el promedio). Olvídese de los patrones de diseño, olvídese de un bajo acoplamiento o división del código en clases y métodos pequeños. Olvídese de intentar hacer algo interesante porque a) eso no pudo ser explicado ni comprendido por todos los miembros del equipo (al menos no de manera oportuna) yb) ya que éramos ágiles, sea como sea que comencé esta iteración, alguien más sin ningún entendimiento. Continuaría en la siguiente iteración. Personalmente, simplemente me di por vencido y simplemente esperé a Scrum oa quien me asignara tareas, las hice, fui a casa y codifiqué mis propios proyectos personales.

Odiaba absolutamente el hecho de que no podía hacer nada con las plantillas de C ++, o escribir algunas bibliotecas de marcos de bajo nivel geniales (pero algo complejas) que hubieran hecho nuestras vidas mucho más fáciles. ¿Cómo se puede hacer algo así cuando nadie más en el equipo es capaz de leer los archivos de encabezado de STL, pero se supone que todos estamos trabajando en una cosa a la vez? Todo el proyecto terminó siendo una característica forzada de brutalidad, porque eso es lo que Agile parece enfatizar.

Al mismo tiempo, hay pocas (muy pocas) personas en mi empresa con las que me encantaría trabajar de lado a lado y compartir todo mi código.

Pero ahora te enfrentas a una elección. A) Tome a todos sus buenos desarrolladores senior que producen códigos de alta calidad, póngalos en su propio equipo y ponga el resto en un equipo separado. O B) tratar de equilibrar los equipos y poner los buenos con los no tan buenos. En (A) el problema es que uno de sus equipos tendrá un rendimiento inferior y no adquirirá buenas habilidades / hábitos de los buenos. En (B) sus buenos (en un ambiente ágil y puro) se sentirán frustrados y comenzarán a trabajar en sus currículos. El mío está actualizado.

Entonces, ¿qué vas a hacer?

No sé si esta es la solución correcta. Pregúntame de nuevo dentro de aproximadamente un año. Pero, ¿qué pasa si en lugar de "ágil puro" formó un equipo, pero identificó claramente qué persona (s) tiene más influencia (diseño, revisiones de código ...) y asegúrese de que esa persona entienda eso y sea recompensada por una responsabilidad adicional? A medida que los miembros del equipo comiencen a trabajar juntos, identifique a aquellos que están adquiriendo buenos hábitos / prácticas y elevarlos al mismo nivel que sus buenas personas. Es de esperar que a medida que las personas pasan un lanzamiento o dos trabajando juntos, aprenderán lo que piensa la otra persona y cómo funcionan, por lo que serán más compatibles para trabajar en el mismo código al mismo tiempo. Pero hasta que eso suceda, si solo arrojas a la gente a un proyecto, no será más que frustración (nuevamente, solo mi opinión). De esta manera, si los hombres mayores tienen que trabajar con los menos experimentados, al menos tienen más peso (no dictadura, solo más peso) en la toma de decisiones.

Algunos de mis pensamientos se basan en cómo empecé profesionalmente en software. Cuando era una cooperativa trabajaba con un chico que era mi mentor. Me enseñó todo, desde la codificación de la ética hasta el buen diseño, a leer miles y miles de líneas de código que no escribiste. Al principio no estábamos en el mismo nivel y sería ridículo si nos ubicaran en un equipo ágil y nos dijeran que podemos trabajar en el código de cada uno. Pero con el tiempo (pocos años), comenzamos a pensar de forma muy parecida. Pude entender su código con una simple mirada y me dijo varias veces que no tenía absolutamente ningún problema (y eso me sorprendió) al navegar por mi código que nunca antes había visto. Esto llevó años, no algo que sucedió durante la noche. Después de experimentar un desastre tras otro en un entorno ágil en los últimos años, me gustaría saltar al corazón ante la posibilidad de trabajar junto con ese tipo en un equipo ágil

Esto no es realmente una respuesta, pero resume mi experiencia / observaciones. Quiero ver lo que otros dirían sobre esto.

¿Qué es Agile?

Es:

• ¿Un conjunto de reglas que debe seguir para lograr lo que pretenden los que establecen las reglas?

• ¿el mejor enfoque para hacer las cosas dentro de sus fortalezas, requisitos y limitaciones particulares?

Si crees que Agile es el primero, y siempre sigues todas y cada una de las reglas de Scrum y te preocupas constantemente si lo estás haciendo bien o no, tal vez este enlace te iluminará un poco.

Si piensas que es más sobre el segundo, entonces felicitaciones - obtienes Agile. Cualquier metodología ágil solo puede ser una sugerencia de cómo hacer las cosas. Si algún aspecto del método ágil elegido no le parece correcto, entonces tiene el deber de dejar de usarlo, cambiarlo o, de lo contrario, ser ágil al respecto. Lo importante es que logre algo, que no se vea limitado por limitaciones artificiales, no solo por las que todos conocemos y amamos en nuestros viejos días en la cascada, donde el primer ministro lo molestaría por diagramas completos y documentados que nadie más lo haría. lea solo porque "eso es lo que el proceso dice que se debe hacer", pero también por las restricciones de lo que está usando. Si un scrum diario se siente como si fuera una restricción, ¡entonces no lo tengas! Tenerlos a ciegas porque las reglas así lo dicen no es más ágil que las formas antiguas.

Ahora, si tienes algunos tipos que se encargan de hacer las cosas encerrados en una habitación con solo un galón de cola y una compuerta para pizza, utiliza ese hecho. Ofrézcales una parte del sistema que sea mayoritariamente autónomo y guárdelos. Cuando hayan terminado, debe hacer que integren ese trabajo (o que otra persona lo haga si lo prefieren) con el resto del sistema.

Alistair Cockburn describió esto en sus métodos. Si tiene "practicantes de nivel 3", un método ágil perfectamente válido es el siguiente:

  

“Poner 4-6 personas en una habitación con   estaciones de trabajo y pizarras y   Acceso a los usuarios. Haz que entreguen   Ejecutando, software probado para los usuarios.   cada uno o dos meses, y de otra manera   déjalos en paz ”.

Como tiene una mezcla de personas, necesita encontrar una manera de hacer que trabajen de manera constructiva, y eso significa que un enfoque de talla única probablemente no será muy eficiente. Por lo tanto, debe dividir las tareas y, al mismo tiempo, asegurarse de enfatizar el objetivo común. Está bien enviar a esos muchachos al código, pero deben ser conscientes de cómo sus cosas serán una parte integral del resto del trabajo del equipo y no lograrlo es un fracaso de lo que sea que estén produciendo. . Una vez que entienden eso (es decir, no pueden simplemente hacer lo que se les ocurra y entregar algo inutilizable), entonces su trabajo habrá terminado.

Digamos que agile no es para todos y agile no es para todos los proyectos. Al mismo tiempo, ágil es un término muy amplio y Scrum es solo una implementación de un proceso ágil: de alguna manera puedo decir que la implementación es probablemente la que tiene más restricciones y que trata de configurar un proceso estandarizado con pasos bien conocidos.

Otra área a considerar es ¿cuál es el propósito de ágil? ¿Es ágil la forma en que trabajan los desarrolladores? Quizás - algunas metodologías van en esa dirección. Pero Ágil en sí cubre áreas fuera del desarrollo. Agile es más sobre la conducción de todo el proceso, la forma en que funciona una interacción, la forma en que entrega el producto de trabajo con las funciones más importantes a tiempo y la forma en que controla los recursos, cómo ve en qué parte del proyecto está actualmente. etc.

Existen metodologías que no intentan cambiar nada de su proceso de desarrollo: Scrum no es la única. Todas las metodologías ágiles enfatizan la mejora continua. Detectarás algún paso ineficiente en tu proceso e intentarás mejorarlo / cambiarlo, esa es la forma ágil. Compruebe otra popular metodología ágil - Kanban.

Usted / su empresa ha decidido usar Scrum y puede llevar a que a algunas personas no les guste y se vayan. Debes tratar con cada uno de tus desarrolladores por separado. Debe hablar sobre eso con cada uno y debe tratar de encontrar algunos intereses que les permitan disfrutar del trabajo nuevamente.

Pueden tener el rol de mentores, pueden enseñar a otros, mostrarles cómo refactorizar el código para mejorar la arquitectura cuando se trabaja de manera iterativa. Pueden formar juntos algún tipo de uso de la arquitectura global en todos los proyectos. También pueden trabajar en la prueba de conceptos, participar en RFI (solicitud de información) cuando los clientes hacen preguntas para pensar en la viabilidad de los requisitos. Pueden trabajar en parejas con desarrolladores menos capacitados y realizar juntos la tarea compleja, etc. Su principal valor debe ser el uso de sus habilidades y permitir que otros aprendan de ellos.

Scrum y ágil en todo el mundo, de hecho, de alguna manera mantienen a los individuos y priorizan a los equipos: los equipos entregan aplicaciones, no individuos. Esta idea se basa en el hecho de que nunca tendrás un equipo donde todos tengan las mismas habilidades y experiencia.

Si su transición a Scrum será exitosa, deberían ver que el proceso general ha mejorado, los tiempos de entrega se redujeron, la calidad ha mejorado y los clientes están más satisfechos. Todavía pueden creer que las aplicaciones desarrolladas en sí mismas son mucho peores de lo que podrían ser, pero ese es el punto: el cliente no quiere que se escriba el mejor código. Los clientes desean el código de trabajo mínimo / más barato / más rápido desarrollado que satisfaga sus requisitos. Si la fuerza bruta es suficiente para eso, entonces sé. Esto es algo que puede causar problemas a los desarrolladores altamente calificados, pero no es una falla ágil, es el lugar donde las demandas comerciales y el perfeccionismo van uno contra el otro.

Beneficiará a todo el equipo si toma algunos de los principales problemas y se los entrega a un gran desarrollador. Todos pueden ponerse al día y aprender algo en el proceso. Simplemente no compile una aplicación completa de esta manera.

No diluyes el código al mínimo común denominador. Haces que los inexpertos se pongan al día con los mejores desarrolladores.

Ha habido mucha discusión sobre lo que es o no es "ágil" y muchos sentimientos, experiencias y dudas personales sobre el proceso ágil compartido aquí, pero realmente no he visto una respuesta real a la pregunta. La pregunta original era cómo mantener a tus mejores desarrolladores motivados cuando ven su código que han escrito a nivel de arte puro e invirtieron su sudor y sangre, pirateados por otra persona y "corrompidos". Tenga en cuenta que, ágil o no, esto va a suceder en algún momento, ahora es más visible porque todavía están trabajando en el código al mismo tiempo que en otros, en lugar de tener el traspaso típico que se debe apoyar. En ese momento, simplemente no verían que se hacían esos cambios.

Lo que vería como la clave aquí es expandir la responsabilidad de estos desarrolladores y ayudarlos a cambiar su enfoque al panorama general. Tal vez eso signifique un nuevo título, como Arquitecto de software, Líder de equipo o Ingeniero de software sénior. Luego muéstreles que esta es una oportunidad para tener un mayor impacto, no solo en un solo proyecto a la vez, sino en múltiples proyectos. El sentido de propiedad aún puede estar allí, pero su enfoque ya no debería estar en la entrega de un gran proyecto único, sino en ayudar a establecer el estándar para proyectos ALL . Ayúdelos a buscar su fuerte deseo de construir algo grande, pero cambie el enfoque para desarrollar las prácticas de ingeniería de software de su empresa y los otros desarrolladores. En lugar de encogerse ante la idea de que sus compañeros de trabajo rompan su código en pedazos, esta puede ser una oportunidad para que puedan pasar al siguiente nivel y mentorear a sus compañeros de equipo y llevarlos a su nivel.

Intentaré ilustrar algunos aspectos que no se han abordado en otras respuestas y que, en mi opinión, son importantes.

  

El problema básico es este: algunos desarrolladores están motivados principalmente por la alegría de tomar un trabajo difícil, pensar en un diseño, pensar en problemas potenciales y luego resolver el problema pieza por pieza, con una interacción mínima con los demás. durante un período prolongado de tiempo. Generalmente, completan el trabajo con un alto nivel de calidad y de manera oportuna; su trabajo es mantenible y se ajusta a la arquitectura en general.

A este tipo de desarrolladores les puede resultar difícil adaptarse a un entorno ágil y su actitud a menudo se descarta como "falta de voluntad para cambiar", posiblemente relacionada con el ego o con ser anticuada.

Lo que a menudo se ignora es que para resolver problemas complejos se necesita manejar mucha información, y que esto puede requerir mucho análisis, pensar, intentar, dibujar una solución, desecharla e intentar otra. Un problema tan complejo puede requerir desde unas pocas horas hasta unas pocas semanas de trabajo enfocado hasta que tenga una solución completa.

Un enfoque es que un desarrollador toma la especificación del problema, va a su habitación y regresa dos / tres semanas después con una solución. En cualquier momento (cuando sea necesario), el desarrollador puede iniciar alguna interacción con otros miembros del equipo o con las partes interesadas (haciendo preguntas sobre problemas específicos) pero la mayoría El desarrollador al que se le asigna la tarea realiza el trabajo.

¿Qué sucede en un escenario ágil? El equipo divide el problema en partes pequeñas (historias de usuario) después de un análisis rápido (preparación). La esperanza es que las historias de los usuarios sean independientes entre sí, pero a menudo este no es el caso: para dividir un problema complejo en partes realmente independientes, necesitará un conocimiento que normalmente obtiene después de trabajar en él durante varios días. En otras palabras, si puede dividir un problema complejo en partes pequeñas e independientes, significa que básicamente ya lo resolvió y que solo le queda trabajo de diligencia. Para un problema que requiere, digamos, tres semanas de trabajo, este será probablemente el caso durante la segunda semana, no después de un par de horas de preparación al comienzo del sprint.

Entonces, una vez que se ha planeado un sprint, el equipo trabaja en diferentes partes de un problema que probablemente tienen dependencias entre sí. Esto genera una gran cantidad de sobrecarga de comunicación al tratar de integrar diferentes soluciones que pueden ser igualmente buenas, pero son diferentes entre sí. Básicamente, el trabajo de prueba y error se distribuye entre todos los miembros del equipo involucrados, con una sobrecarga de comunicación adicional (que aumenta de forma cuadrática). Creo que algunos de estos problemas se ilustran muy bien en este artículo de Paul Graham, en particular el punto 7.

Por supuesto, compartir el trabajo entre los miembros del equipo reduce el riesgo relacionado con que un miembro del equipo abandone el proyecto. Por otro lado, el conocimiento sobre el código se puede comunicar de otras maneras, por ejemplo, utilizando revisiones de código o dando presentaciones técnicas a los colegas. En este sentido, no creo que haya una bala de plata válida para todas las situaciones: la propiedad del código compartido y la programación de pares no son la única opción.

Además, la "entrega de la funcionalidad de trabajo en intervalos más cortos" da como resultado una interrupción del flujo de trabajo. Esto puede estar bien si la parte de la funcionalidad es "agregar un botón de cancelación en la página de inicio de sesión" que se puede completar al final de un sprint, pero cuando está trabajando en una tarea compleja, no desea tales interrupciones: es como Intente conducir un automóvil 100 km lo más rápido que pueda y pare cada 5 minutos para comprobar qué tan lejos ha llegado. Esto solo va a frenarte.

Por supuesto, tener puntos de control frecuentes tiene la intención de hacer que un proyecto sea más predecible, pero en algunos casos la interrupción puede ser muy frustrante: uno apenas puede ganar velocidad y ya es hora de detenerse y presentar algo.

Entonces, no creo que la actitud descrita en la pregunta esté relacionada solo con el ego o la resistencia al cambio. También puede ser que algunos desarrolladores consideren que el enfoque de resolución de problemas descrito anteriormente es más efectivo porque les permite comprender mejor los problemas que están resolviendo y el código que están escribiendo. Forzar a estos desarrolladores a trabajar de una manera diferente puede resultar en reducir su productividad.

Además, no creo que tener algunos miembros del equipo trabajando de manera aislada en problemas específicos y difíciles esté en contra de los valores ágiles. Después de todo, los equipos deben organizarse por sí mismos y utilizar el proceso que hayan encontrado más efectivo a lo largo de los años.

Sólo mis 2 centavos.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Parece que son "Lone Rangers". En el Scrum canónico, estas personas no pueden encajar en el Equipo (pierden el bit de "interacción").

Si no son "Rangers Solitarios", entonces hay esperanza. Si estás haciendo Scrum correctamente, deben ser parte del diseño de la función en la que estarán trabajando (durante la Planificación del Sprint). Esta es la única vez que necesitan interactuar con otros. Incluso puedes "asignar" todas las historias relacionadas con esa característica para ellos.

Durante el Sprint, solo serán "molestados" por el Scrum diario ... hasta que pueda demostrarles (con acciones, no con palabras) que solo serán 15 minutos de su tiempo, y solo para garantizar que todo está funcionando sin problemas Manténgase cerca de las tres preguntas y la mayoría de las personas dejarán de cumplir.

En nuestro equipo, tenemos un grupo especial solo para mejoras de rendimiento. No los vemos mucho, solo al inicio del sprint para hablar sobre los cambios que se harán, y al final en la retrospectiva. Ellos tienen su propio "líder scrum" que informa al equipo de Scrum of Scrum. Les puedo decir que se están divirtiendo.

Si Joe (tu desarrollador de Hero) es un poco flexible, entonces no veo un problema:

Como se dijo anteriormente, deje que el equipo se autoorganice: si algunos problemas se resuelven mejor dejando que Joe lo mastique solo, entonces usted esperaría que un equipo autoorganizado de mente abierta llegue a esa conclusión por su cuenta.

Los únicos desafíos que permanecen dentro de las pocas restricciones que Scrum impone:

1. Entregando funcionalidad a intervalos regulares: si le permite a Joe masticar un problema durante meses, sin mostrar nada hasta el final, entonces Joe no es ágil: está tomando como rehén al propietario del producto y no le está permitiendo una oportunidad para volver a especificar esa parte del producto. Con esta práctica también existe el riesgo de que llegue tarde y nadie lo note. (Pero según su descripción eso no es tan probable). Remedio: ¿Sería mucho pedirle a Joe, sentarse junto con el PO, dividir la historia del usuario y acordar entregas intermedias, de preferencia (pero no necesariamente) con el valor del usuario?

2. Respetar las prioridades establecidas por el propietario del producto: si los códigos son propiedad de expertos, entonces se arriesga a una situación en la que la evolución del producto está determinada por la disponibilidad de cada experto, en lugar de las prioridades comerciales: El resto del equipo podría estar trabajando en características menos importantes, mientras que las 3 características principales se estancaron porque "solo Joe puede hacerlo". Eso es malo. En ese momento, el equipo debe (temporalmente) cambiar su hábito y dividir el trabajo de Joe sobre más miembros del equipo.

En resumen: Si Joe, el desarrollador de héroes, está de acuerdo con el PO sobre cómo mostrará el progreso de cada carrera, entonces el equipo puede asignarle ciertas historias y dejarlo solo. Pero si el PO tiene demasiado trabajo para Joe, y no lo suficiente para el equipo (o viceversa), entonces Joe y el equipo tienen que adaptarse, no el PO.

Las reglas para un equipo ágil deben personalizarse para que se ajusten al equipo; esto puede ser una personalización realmente personal; Por ejemplo, trabajé en un equipo donde la regla era:

  

Todo el Código debe estar escrito por un par, excepto que David puede escribir solo el código.

David era un desarrollador / arquitecto senior, que trabajó principalmente en herramientas que otros usarían en su propio código. Él era el dueño del código que escribió. Fue mantenible y probado, y todos en el equipo sabían que él era probablemente el mejor programador allí, y que el equipo recibiría el mejor servicio al permitirle construir ciertas piezas de marco y presentarlas como completas al equipo.

No tengo una respuesta para los introvertidos de variedades de jardín, pero para los introvertidos excepcionales, el equipo tomará alegremente diferentes reglas para obtener el beneficio.