Cuando mi gerente le dijo al equipo que " ahora las historias de usuarios exitosas serán consideradas para evaluación ".
Nos sentamos allí por un momento en estado de shock y ese fue uno de los muchos momentos asombrosos que nos dio :-)
Sentimos que era una idea estúpida, ya que esto arruinaría todo concepto y objetivo de la metodología de desarrollo ágil.
Déjame saber lo que piensan ustedes? ¿Y cómo podemos convencerlo?
Respuestas:
Sandy, desafortunadamente, la declaración de su gerente es un malentendido clásico de scrum en particular y ágil en general.
El enfoque propuesto mata la colaboración y contrarresta el principio de propiedad del código colectivo . Las historias de usuarios en ágil (si es realmente ágil) rara vez se completan antes de ser tocadas por varias personas. Además, tendrá historias de usuarios de vez en cuando que necesitan enjambre para poder terminar dentro de la iteración. ¿Cómo van a obtener eso cuando los incentivos individuales estén alineados 180 grados en la dirección opuesta?
Los instintos de tu equipo son correctos. ¿Qué fuentes le sugeriría a corto plazo para que lea mientras hace una lluvia de ideas sobre la respuesta a su gerente? Mire los blogs de renombrados expertos ágiles como Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby y varios otros y busque artículos sobre la organización de equipos ágiles.
Mi principal objeción a este método de evaluación es que puede ser un obstáculo para la cooperación entre desarrolladores. Creo que una parte importante de la productividad de un equipo de desarrollo es la disposición de los miembros del equipo a ayudarse mutuamente. Según entiendo el esquema sugerido, podría llevar a los desarrolladores a cumplir con sus propias tareas asignadas e ignorar a otros miembros del equipo que están atrapados y podrían ser fácilmente despegados con un poco de ayuda.
Siempre estamos buscando la contribución que el programador está haciendo al equipo y al negocio.
Esto está a la par de medir líneas de código o número de errores, pero un poco más sofisticado.
A primera vista, la medición no tiene nada de malo, pero cuando lo piensa, comienza a plantear objeciones:
es el más obvio que me viene a la mente: estoy seguro de que hay otros.
Obviamente, su gerente cree que esta es una buena idea, por lo que debe tener cuidado de que cuando presente objeciones también pueda presentar soluciones. Esta solución podría tener que ser una modificación de su esquema en lugar de un nuevo esquema.
Entonces, por ejemplo, es posible que desee señalar que alguien que solo trabaja en historias "fáciles" completará más que alguien que trabaja en historias más "difíciles" y esto podría conducir a una concentración en los aspectos menos importantes del desarrollo. Entonces, una solución podría ser considerar el número de puntos de la historia en lugar de solo el número de historias.
Estoy de acuerdo con ChrisF en que esto se remonta al mismo problema con cualquier medición. Lo que elogias es lo que obtienes. Siempre habrá personas que jueguen con el sistema, sea lo que sea ese sistema.
El único método efectivo real que he encontrado para recompensar a los programadores viene con tres pasos.
La clave completa es que los programadores no son engranajes en una máquina que se pueden "ajustar" mirando las estadísticas. Las personas reales deben ser examinadas y mejoradas en su conjunto y el equipo debe poder confiar unas en otras de manera cooperativa y no competitiva.
Los trabajadores de bajo rendimiento del equipo tienen todas las oportunidades de mejora y enriquecimiento antes de que se les considere despedidos. En última instancia, los buenos programadores prosperarán en este entorno y los programadores pobres, que se niegan a mejorar, serán despedidos.
La mayoría de las veces, las historias de usuario se completan en un esfuerzo colectivo. Esto hace que sea prácticamente imposible basar la evaluación individual en esta métrica.
La métrica en sí misma puede manipularse fácilmente ya que el proceso de planificación también es un esfuerzo de equipo e incluso más temprano que tarde, todo el sistema se arregla. Eso es definitivamente lo que no quieres en un proceso centrado en las personas.
Creo que el buen rendimiento debe ser reconocido por algún tipo de sistema de bonificación basado en el éxito del equipo, pero las Historias de usuarios no son un buen indicador del éxito.