¿El proceso de Scrum priva a los miembros del equipo de sus respectivas habilidades?

Question

Mi organización ha estado experimentando con la introducción de métodos más "ágiles". Hemos estado probando el enfoque de Scrum por un tiempo breve, y la mayoría del equipo se ha adaptado, más o menos, a él. Me gusta como un todo, pero me preocupa un impacto potencialmente grave de la metodología: como los equipos se centran constantemente en las características y los elementos atrasados, y los evaluadores están más integrados con el proceso de desarrollo general, parece que los conjuntos de habilidades se están volviendo borrosa, y la gente siente menos respeto por sus habilidades individuales.

Algunos de nuestros desarrolladores son excelentes en tecnologías del lado del servidor y en la optimización del aprovisionamiento de datos pesados. Otros han invertido una gran cantidad de sus carreras aprendiendo tecnologías de GUI y han desarrollado una comprensión fundamental de los usuarios y la usabilidad en una aplicación. Ni el conjunto de habilidades es mejor que el otro, pero ciertamente son diferentes.

¿Es este un resultado inevitable del proceso de Scrum? Dado que todos los integrantes del equipo (según tengo entendido) contribuyen a satisfacer la siguiente función/requisito, elemento atrasado o objetivo de prueba, la filosofía subyacente parece ser "cualquiera puede hacerlo". Esto es, en mi experiencia, simplemente no es verdad. La mayoría de los ingenieros (desarrolladores, probadores, etc.) tienen un conjunto particular de habilidades que han perfeccionado a lo largo de los años, y la metodología de Scrum, en mi opinión, tiende a devaluar esas habilidades por las que antes se respetaban.

He aquí un ejemplo de aclaración:

Si un cambio repentino de la tecnología se produce en el aprovisionamiento de datos del lado del servidor, y cada elemento de la lista de tareas pendientes para el sprint se basa en este nuevo cambio, la interfaz gráfica de usuario los desarrolladores (que probablemente no tuvieron tiempo de acostumbrarse a la nueva tecnología) podrían no contribuir al sprint. Por lo menos, necesitarán invertir tiempo para aumentar su velocidad, y entonces su código será sospechoso debido a su falta de experiencia.

Entiendo la necesidad de un desarrollo rápido para desalentar los "silos de roles", pero esto no excluye una realidad fundamental: las personas desarrollan habilidades según la necesidad, sus intereses o sus experiencias. Las personas parecen estar menos motivadas cuando perciben que su posición es de "capacidad de conexión" (por ejemplo, podemos "conectar" a cualquiera para realizar esta tarea en particular). ¿Cómo se ocupa Scrum de esto? Si no es así, ¿alguien ha abordado esto al adoptar la metodología Scrum?

Answer 1

El objetivo de Scrum es que los desarrolladores se autoorganicen. Usamos el scrum donde estoy, y los trabajos se clasifican pasivamente según el enfoque de una persona. No lo hacemos a propósito con un cuadro y una lista, simplemente sucede. Todos sabemos quién es mejor en qué, o cuáles son sus enfoques principales/secundarios. Si la persona "principal" necesita ayuda, la ayuda a la persona/personas con un enfoque secundario. Obtenemos muchas tareas no necesariamente en línea con lo que sea que sea nuestro enfoque particular, pero siempre sabes a quién pedir ayuda en ese momento.

Para su ejemplo - No sé si usted dice que tiene 3 tipos de servidores y 5 chicos de interfaz gráfica de usuario, que esperarían hacer todo el trabajo en ese sprint (si el servidor chicos + algo de ayuda del otros no fueron suficientes). La forma en que se supone que el sprint debe funcionar es que a partir de una lista priorizada, los desarrolladores eligen lo que creen que pueden hacer en ese plazo de 30 días.Si eso significaba que los tipos de GUI necesitaban 2 días de capacitación en el lado del servidor para ayudar, eso es lo que significaría. A menos que haya cosas concurrentes también en la parte superior de la lista que podrían hacer en su lugar. Se supone que las tareas de sprint no deben ser dictadas por la administración como una fecha límite de pseudopausa.

Si tiene una cuenta de Safari, hay un interesante libro de casos de estudio por uno de los tipos que inventaron el scrum.

Answer 2

Suena como esto conduciría a desarrolladores más completos, y también permitiría que aquellos que son expertos en ciertas áreas continúen aportando su experiencia.

No he usado Scrum mucho (todavía), pero según su descripción, este tipo de equipos conducirían a un equipo/organización que también es más completo en su conjunto, y no debería ser ese el objetivo de cualquier equipo?

Answer 3

Si encuentra por alguna razón ('cambio repentino de tecnología' o no) que la cantidad de trabajo requerida para un sistema durante un esprint es mayor que la cantidad disponible, entonces hay un problema con su programación.

Una solución es que, como sugieres, tomas programadores de otras áreas y los arrojas a la mezcla. Lo bien que esto funciona depende de las habilidades de esa persona y cuán diferente es el dominio del problema, pero tratar a los programadores como unidades genéricas que se pueden cultivar según sea necesario generalmente no es una estrategia exitosa para desarrollar software.

Sin embargo, este sigue siendo un problema de programación.

Answer 4

No estoy seguro de por qué el conjunto de habilidades se borrará. Hay una gran cantidad de confusión en el mundo ágil. Scrum es un proceso de gestión de proyectos y no un proceso de desarrollo de software y no debe verse como uno. Los ingenieros tienen que seguir sus propias metodologías, como TDD o programación extrema para agregar su parte a ser ágil.

Nada desaparece en el scrum.

PM aún documento a medida que avanzan Los arquitectos aún diseñan sus componentes. Lo único es que solo retrasan algunas decisiones importantes a un punto más responsable en el tiempo. Los desarrolladores deben seguir las mejores prácticas, como SOLID principles, para permitir la refactorización de manera coherente a medida que cambian las características.

Answer 5

Manejar cambios repentinos es parte de Agile y esto puede significar que algunas personas tienen que irse y aprender nuevas habilidades. Por supuesto, esto está más dentro de la filosofía Agile general que cualquier cosa específica de Scrum. Puede haber algunos casos extremos en los que el cliente o la empresa decida cambiar el mundo aportando algo nuevo y, por lo tanto, deba lidiar con el dolor posterior de esas personas que aumentan de tamaño, pero si esto es lo que quieren y los desarrolladores quedan anulados, entonces hay solo un par de opciones: (tome sus bultos e intente manejar los cambios principales) o (salga y salga de allí).

Si bien puede haber algunos casos en que alguien que se haya especializado en algo pueda hacer las cosas más rápido, esto no significa necesariamente mucho si es solo una persona del equipo que es un experto y hay suficiente trabajo en esa área para 10 personas para todo el sprint. ¿Los que no son expertos simplemente no deben hacer ese trabajo y dejar que esa persona intente superar todo lo que él o ella pueda? No lo creo, pero debería haber algo que decir para aquellos que no son los mejores en algo que aún intentan hacer lo que pueden hacer.

Answer 6

Lo mejor de Scrum es exactamente el hecho de que las habilidades se vuelven un poco borrosas. El objetivo es evitar los silos a toda costa al difundir el conocimiento especializado en todo el equipo y dejar que la gente trabaje un poco fuera de su zona de confort.

Obviamente esto no es para todos. Algunos desarrolladores están contentos en su propio campo de especialización y esas personas son más un obstáculo en un proceso de Scrum que una ventaja, mientras que las personas bien integradas y con muchos talentos que están decididas a hacer el trabajo, por lo general se adaptan muy bien a y son mucho más productivos.

Uno de los beneficios clave de Scrum es conseguir que todo el equipo se involucre e invierta en el proyecto en lugar de abordar sus propias tareas especiales y luego salir a la luz. Yo diría que para la mayoría de las personas, esta es una forma de trabajo mucho más gratificante que la cinta transportadora: el enfoque de los procesos en cascada.

Así que aconsejo adoptar con valentía la combinación de habilidades y hacer que la gente se reúna para resolver problemas desagradables en lugar de depender de silos especializados. El resultado de equipos compuestos por personas motivadas puede ser sorprendente.

Answer 7

Creo Scott Ambler aborda esta cuestión en profundidad en http://www.agilemodeling.com/essays/generalizingSpecialists.htm ...

Su concepto de un especialista Generalizar es exactamente lo que la propiedad colectiva/Equipo Scrum requiere, y tiene todo el sentido para mí.

Es difícil de lograr en la vida real, aunque ;-)

Answer 8

He estado trabajando como un ScrumMaster durante unos 18 meses y he trabajado con dos equipos diferentes. Inicialmente esperaba experimentar los posibles problemas que plantea, pero este no ha sido el caso. Lo que generalmente observo es que el equipo evoluciona en una mezcla de especialistas y generalistas a medida que las personas encuentran el papel apropiado para ellos mismos, uno que pueden disfrutar y tener éxito. Esto es autoorganización en el trabajo. Nunca tuve un caso donde nuestros especialistas estaban sentados inactivos.

Si esto ocurriera, esperaría que fuera planteado como un problema en Sprint Retrospective y el equipo discutiría cómo mejorar la situación. La conclusión más obvia (y brutal) sería cambiar la composición del equipo.

Answer 9

La respuesta corta es un enfático NO! Scrum does not desenfocar o depreciar las habilidades requeridas para la especialización. Scrum no promueve la generalización.

La respuesta larga es que en Scrum, lo más importante es conseguir el trabajo "Hecho". El equipo, como equipo (a diferencia de una colección de "estrellas" individuales) colabora, según sea necesario, para realizar el trabajo. Lo que sea necesario, como quieran (Scrum se trata de equipos de autogestión, auto motivación, ¿no?).

Lo que esto significa es que un equipo de scrum puede estar compuesto por varios especialistas, que principalmente hacen en lo que se especializan (DBA, diseño gráfico, incluso escritores técnicos). El equipo, como un todo, debe tener todas las habilidades requeridas para cumplir con los requisitos. Esto no es lo mismo que decir que cada miembro del equipo tiene que tener todas las habilidades antes mencionadas.

Dicho esto, a menudo se desea, a menudo por los mismos miembros, que los miembros que no sean los especialistas sean al menos adecuados en habilidades diferentes de su especialidad. Otro cartel ya mencionó al "Especialista General" de Scott Ambler. Esto ayuda al equipo cuando hay demasiado trabajo de un tipo, cuando el especialista está ausente, y ayuda al miembro cuando realmente desea obtener experiencia fuera de su especialidad.

Dado que el equipo se organiza a sí mismo, si por algún motivo un especialista se encuentra en medio del sprint, sin ningún trabajo que hacer en su especialidad, la mejor manera de enfrentarlo es simplemente preguntarle al especialista lo que quiere hacer Deja que el equipo decida.El especialista puede decidir ayudar en sus otras áreas de adecuación, hacer un POC para el próximo sprint, "apuntalar" las defensas mediante la reparación de una deuda técnica olvidada hace tiempo, o hacer brillar los zapatos de los miembros que están trabajando .

Sí. No sé si esto es la respuesta larga. Pero definitivamente fue una respuesta larga. :-)