sesiones - ¿El proceso Scrum, en última instancia, separa a los miembros del equipo de sus respectivas habilidades?
reuniones que se realizan en scrum (9)
Mi organización ha estado experimentando con la introducción de más métodos "ágiles". Hemos estado probando el enfoque Scrum por un corto tiempo, y la mayoría del equipo se ha adaptado, más o menos, al mismo. Me gusta en general, pero me preocupa un impacto potencialmente grave de la metodología: dado que los equipos se centran constantemente en las características y los elementos de la reserva, y los evaluadores están más integrados con el proceso de desarrollo general, parece que los conjuntos de habilidades se están convirtiendo 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 en el aprendizaje de tecnologías GUI y han desarrollado una comprensión fundamental de los usuarios y la facilidad de uso en una aplicación. Ninguna de las dos habilidades es mejor que la otra, pero ciertamente son diferentes.
¿Es este un resultado inevitable del proceso Scrum? Como todos los miembros del equipo (como lo entiendo) contribuyen a satisfacer la siguiente característica / requisito, el elemento del trabajo pendiente o el objetivo de prueba actual, la filosofía subyacente parece ser "cualquiera puede hacerlo". Esto es, en mi experiencia, simplemente no es cierto. La mayoría de los ingenieros (desarrolladores, evaluadores, etc.) tienen un conjunto de habilidades particular que han perfeccionado a lo largo de los años, y la metodología Scrum, en mi opinión, tiende a devaluar esas habilidades por las que antes eran respetados.
Aquí hay un ejemplo de aclaración:
Si se produce un cambio repentino de tecnología en el aprovisionamiento de datos del lado del servidor, y cada elemento de la lista de tareas para el sprint se basa en este nuevo cambio, los desarrolladores de GUI (quienes probablemente no han tenido tiempo de aclimatarse con el nueva tecnología) podría no ser capaz de contribuir al sprint. Como mínimo, tendrán que invertir tiempo para aumentar su capacidad, y luego su código será sospechoso debido a su falta de experiencia.
Entiendo la necesidad de un desarrollo rápido para desalentar a los "silos de roles", pero esto no descarta una realidad fundamental: las personas desarrollan habilidades de acuerdo con la necesidad, sus intereses o sus experiencias. Las personas parecen estar menos motivadas cuando perciben que su posición es una de "capacidad de conexión" (por ejemplo, podemos "conectar" a cualquier persona para realizar esta tarea en particular). ¿Cómo aborda esto Scrum? Si no es así, ¿alguien se ha ocupado de esto al adoptar la metodología Scrum?
¡Lo mejor de Scrum es 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 las personas trabajen un poco fuera de su zona de confort.
Obviamente esto no es para todos. Algunos desarrolladores están contentos en su propio campo especializado y estrecho, y esas personas son más un obstáculo en un proceso Scrum que un activo, mientras que las personas bien dotadas y con múltiples talentos que están decididas a hacer el trabajo, generalmente se adaptan muy bien a Es y son mucho más productivos.
Uno de los beneficios clave de Scrum es lograr que todo el equipo participe e invierta en el proyecto en lugar de abordar sus propias tareas especiales y luego dirigirse hacia el horizonte. 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.
Por lo tanto, le aconsejo que adopte audazmente la combinación de habilidades y que las personas se unan para resolver problemas desagradables en lugar de confiar en silos especializados. El resultado de equipos formados por personas motivadas puede ser sorprendente.
Creo que Scott Ambler aborda este problema muy a fondo en http://www.agilemodeling.com/essays/generalizingSpecialists.htm ...
Su concepto de un Especialista en Generalización es exactamente lo que exige el Grupo de Propiedad Colectiva / Scrum, y tiene mucho sentido para mí.
Aunque es difícil de lograr en la vida real ;-)
El manejo de cambios repentinos es parte de Agile y esto puede significar que algunas personas tienen que irse y aprender nuevas habilidades. Por supuesto, esto es más dentro de la filosofía ágil general que cualquier cosa específica de Scrum. Puede haber algunos casos extremos en los que el cliente o la empresa decidan cambiar el mundo incorporando algo nuevo y, por lo tanto, deben manejar el dolor subsiguiente de las personas que se están preparando, pero si esto es lo que quieren y los desarrolladores son rechazados, entonces hay solo un par de opciones: (Tome sus bultos y trate de manejar los cambios más importantes) o (salga y salga de allí).
Si bien puede haber algunos casos en los que alguien que se haya especializado en algo pueda hacer las cosas más rápido, esto no necesariamente significa mucho si esa 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 hacen ese trabajo y dejan que esa persona intente superar todo lo que pueda? No lo creo, pero debería haber algo que decir para aquellos que no son los mejores en algo que todavía está tratando de hacer lo que se puede hacer.
He estado trabajando como ScrumMaster durante aproximadamente 18 meses y he trabajado con dos equipos diferentes. Inicialmente esperaba experimentar los problemas potenciales 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 adecuado para ellos mismos, uno en el que puedan disfrutar y tener éxito. Esta es la autoorganización en el trabajo. Nunca he tenido un caso donde nuestros especialistas estaban sentados sin hacer nada.
Si esto ocurriera, esperaría que se tratara como un problema en Sprint Retrospective y el equipo discutiera cómo mejorar la situación. La conclusión más obvia (y brutal) sería cambiar la composición del equipo.
La respuesta corta es un enfático NO ! Scrum no desenfoca ni deprecia las habilidades necesarias para la especialización. Scrum no promueve la generalización.
La respuesta larga es que en Scrum, lo más importante es hacer 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 ellos 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 lo que se especializan (DBA, diseño gráfico, incluso escritores técnicos). El equipo, en su totalidad, debe tener todas las habilidades necesarias para cumplir con los requisitos. Esto no es lo mismo que decir que cada miembro del equipo debe tener todas las habilidades mencionadas anteriormente.
Dicho esto, a menudo es deseable, a menudo por los propios miembros, que los miembros distintos de 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 le gustaría adquirir experiencia fuera de su especialidad.
Dado que el equipo se auto organiza, si por alguna razón un especialista se encuentra en medio del sprint, sin ningún trabajo que hacer en su especialidad, la mejor manera de lidiar con él es simplemente preguntarle al especialista qué quiere hacer. hacer. Deja que el equipo decida. El especialista puede decidir ayudarlo en sus otras áreas de adecuación , hacer un POC para el próximo sprint, "apuntalar" las defensas al arreglar alguna deuda técnica olvidada por largo tiempo, o sacar a relucir los zapatos de los miembros que están trabajando.
Sip. No sé si esta es la respuesta larga. Pero definitivamente fue una respuesta larga. :-)
No estoy seguro de por qué las habilidades se difuminarán. Hay una buena 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 considerarse como uno solo. Los ingenieros tienen que seguir sus propias metodologías como TDD o programación extrema para agregar su propia parte a ser ágiles.
Nada se va en el scrum.
Los PM siguen documentando sobre la marcha. 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 aún deben seguir las mejores prácticas, como los principios de SOLID, para permitir la refactorización de manera consistente a medida que cambian las características.
Parece que esto llevaría a desarrolladores más completos y también permitiría que aquellos que son expertos en ciertas áreas continúen contribuyendo con su experiencia.
No he usado mucho Scrum (todavía), pero según su descripción, este tipo de equipos llevaría a un equipo / organización que también está más completo en su conjunto, y no debería ser el objetivo de ningún equipo. ?
Si, por alguna razón (''cambio repentino de tecnología'' o no), descubre que la cantidad de trabajo requerido para un sistema durante un sprint es mayor que la cantidad disponible, entonces hay un problema con su programación.
Una solución es que, como usted sugiere, toma programadores de otras áreas y los lanza a la mezcla. La forma en que funciona esto depende de las habilidades de esa persona y de lo diferente que sea el dominio del problema, pero tratar a los programadores como unidades genéricas que se pueden desarrollar según sea necesario generalmente no es una estrategia exitosa para desarrollar software.
Esto sigue siendo un problema de programación sin embargo.
El objetivo de Scrum es que los desarrolladores se autoorganicen. Usamos el scrum donde estoy, y los trabajos se clasifican de forma pasiva según el enfoque de una persona. No lo hacemos a propósito con un gráfico 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, puede ayudar a la persona / personas con un enfoque secundario en ella. Conseguimos muchas tareas que no están necesariamente en línea con lo 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 tenía 3 tipos de servidores y 5 tipos de interfaz gráfica de usuario, que esperaría realizar todo el trabajo en ese sprint (si los tipos de servidores + alguna ayuda de los demás no era suficiente). La forma en que se supone que debe funcionar el sprint es que de una lista de prioridades, los desarrolladores eligen lo que creen que pueden hacer en ese plazo de 30 días. Si eso significara que los muchachos de la GUI necesitaban 2 días de capacitación del lado del servidor para ayudar, eso es lo que significaría. A menos que haya cosas concurrentes también en la lista que podrían hacer en su lugar. Las tareas de sprint no deben ser dictadas por la administración como una fecha límite de psuedo.
Si tienes una cuenta de Safari, hay un interesante libro de estudio de casos realizado por uno de los tipos que inventó el scrum.