¿Cómo detener / evitar el paso del tiempo en un equipo Scrum?

14

En realidad, estoy ayudando a una pequeña tienda de software en su Implementación Scrum. Recientemente, Scrum Master me informó que tiene un problema porque el Equipo está trabajando A lo largo del tiempo para lograr el Ámbito (acumulación comprometida). Así que tienen un Unreal Velocity .

Mi (s) pregunta (s) formal (es) son:

  1. Además de hablar sobre la reunión retrospectiva; ¿Crees que es una buena idea implementar algunos bloques duros para evitar el exceso de tiempo?
  2. Si es así, ¿qué técnicas / herramientas sugieres?

    • Sistema de control de revisión (SVN, GIT, HG, etc.), bloques por horas (8 a 5)
    • ¿Bloques de estaciones de trabajo por horas (8 a 5) u horas acumuladas (hasta 8 horas por día)?
    • Otro (s) ...
  3. O, tal vez, no bloquee este tipo de cosas; pero implementa un poco de "Sistema de penalización" para Horas extra no justificadas ?

Primero: Tks todos por sus respuestas rápidas.

@Baqueta (y otros con preguntas similares): No, no se les pagó por Horas Extra. Mi primer consejo para ellos fue que revisaran sus estimaciones porque quizás estaban subestimando. Este fue mi consejo favorito:

  

Si tienen interés en trabajar horas extras, elimínelo. El desarrollo no es algo que pueda hacer durante 60 horas a la semana y mantenerse productivo, y hay numerosos estudios que lo demuestran. Si el problema es el pago por tiempo extra, deshágase de él y mejore su salario base para que obtengan lo que valen.

Además, creo que el problema raíz (para este equipo) es una combinación de lo siguiente:

  
  1. Se les dice a los desarrolladores lo que deben lograr en un sprint / no se les consulta sobre lo que se puede lograr / se ignoran cuando dicen que hay demasiado trabajo.
  2.   
  3. Los desarrolladores subestiman constantemente el tiempo que llevarán las tareas / cuántas unidades de trabajo están involucradas en cada tarea.
  4.   

Resumen: hablaré con el equipo para revisar sus estimaciones y con el P.O. porque siento que no están siendo consultados sobre el alcance, como usted mencionó.

    
pregunta Lorenzo Solano 01.08.2012 - 05:30
fuente

8 respuestas

26

Francamente, esos "bloques duros" que mencionas en el # 2 son la peor idea que he escuchado en mucho tiempo. ¿Qué sucede si se encuentra un error de máxima prioridad a las 4.45 pm y la persona que tiene la capacidad de anular sus bloqueos está enferma? En cuanto al # 3, estás sugiriendo que castigue a las personas por hacer su trabajo .

Si el equipo está trabajando horas extras constantemente para completar los sprints, entonces ellos tienen interés en trabajar horas extras, por ejemplo. las horas extras pagan o las vuelven a tener en cuenta como días festivos, o se comprometen a hacer demasiado trabajo en los sprints.

Si tienen interés en trabajar horas extras, eliminarlo . El desarrollo no es algo que pueda hacer durante 60 horas a la semana y mantenerse productivo, y hay numerosos estudios que lo demuestran. Si el problema es el pago por tiempo extra, deshágase de él y mejore su salario base para que obtengan lo que valen.

Si hay demasiado trabajo en los sprints, esto suele ser por una de tres razones:

  1. Se les dice a los desarrolladores lo que deben lograr en un sprint / no se les consulta sobre lo que se puede lograr / se ignoran cuando dicen que hay demasiado trabajo.
  2. Los desarrolladores subestiman constantemente el tiempo que llevarán las tareas / cuántas unidades de trabajo están involucradas en cada tarea.
  3. Los desarrolladores siguen siendo arrastrados a tareas que no forman parte del scrum.

Si es el número 1, lo estás haciendo mal . No hay dos maneras de hacerlo!

Si es el número 2, la causa habitual es la inexperiencia, ya sea haciendo estimaciones de tiempo o con el sistema que se está desarrollando. Una buena forma de evitar esto es dejar de hacer estimaciones de tiempo y comenzar a estimar 'unidades de trabajo'. Use alguna unidad abstracta, solo asegúrese de que no sean horas en tiempo real (en última instancia, todavía está representando un intervalo de tiempo, ¡pero la abstracción es importante!). Luego, puede comenzar a calcular cuántas unidades de trabajo en realidad se realizan en una semana y luego configurar los sprints con esos datos.

Si es el número 3, debes comenzar a tener en cuenta esas otras tareas de alguna manera. Si es coherente, debería ser fácil de explicar (vea el # 2 arriba). Si es frecuente pero impredecible, es mucho más complicado lidiar con él. Querrá echar un vistazo a por qué está sucediendo (por ejemplo, errores graves en el código 'en vivo' = > ¿es su prueba lo suficientemente exhaustiva?) Pero si eso no puede solucionarse, a la larga el scrum podría no ser el enfoque adecuado para usted . Mi equipo recientemente cambió a Kanban por esta misma razón ...

Editar: Aclaré mi crítica de las ideas presentadas en la pregunta.

    
respondido por el vaughandroid 01.08.2012 - 10:21
fuente
12

En primer lugar, parece que tuvieron mucho trabajo en un sprint si tienen que trabajar horas extra para hacerlo. ¿Se registran todas las horas? Si es así, puedes contar cuánto trabajo real es un punto de historia y usar ese número para calcular el trabajo para el próximo sprint.

También es importante asegurarse de que el equipo entienda que solo se están haciendo daño al tomar demasiado trabajo. Incluso el manifiesto ágil habla de ritmo sostenible: "Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, los desarrolladores y los usuarios deben poder mantener un ritmo constante por tiempo indefinido". Trabajar horas extras todo el tiempo no es sostenible.

En general, sugeriría comunicación en lugar de fuerza y sanciones. Me imagino que eso solo llevaría a la desmoralización del equipo.

    
respondido por el simoraman 01.08.2012 - 06:29
fuente
4

Los desarrolladores que trabajan horas extras probablemente respondan a algún incentivo, ya sea real o percibido. El objetivo es eliminar el incentivo si es real o comunicar que un incentivo percibido no es operativo.

Cada límite duro sugerido tiene algunas soluciones u otros problemas. Los bloques de control de origen solo llevarían a los desarrolladores a mantener sus compromisos hasta que la ventana se abra de nuevo. Los bloques de estaciones de trabajo tendrían que desaparecer tan pronto como surgiera algún problema de soporte o uno de los desarrolladores necesitara cambiar sus horas por alguna razón. Los sistemas de penalización solo llevarán a esconder o enterrar horas extras.

Creo que el problema es más fundamental: el equipo tiene algún incentivo (o cree que tiene un incentivo) para trabajar horas extra.

Esto es lo que necesita ser abordado. ¿Están sus evaluaciones de desempeño ligadas a sus números de velocidad? ¿La gerencia trabaja horas extras? ¿Se otorgan promociones y premios a quienes trabajan largas horas? ¿Son contratistas a quienes se les paga por horas extras?

    
respondido por el JohnMcG 01.08.2012 - 17:05
fuente
3

Simplemente diga al equipo que no trabaje horas extras. Período.

Esto puede hacer que no puedan terminar algún trabajo. Eso no es un problema, eso es un punto de datos. Luego pueden usar ese punto de datos en la planificación del próximo sprint. Nuevamente, no los dejes trabajar horas extras. Ya sea que terminen o no, tienen otro punto de datos. Hacer espuma, enjuagar, repetir.

No hay cantidad de trucos o límites necesarios. Simplemente no trabajes horas extras. Aprenda cuánto trabajo puede realizar y ajuste su planificación de sprint en consecuencia.

    
respondido por el Bryan Oakley 01.08.2012 - 13:08
fuente
0

Tal vez haya un problema de no "cuánto" están trabajando, sino cuándo. Esto puede ser un problema cuando hay un día laboral programado, pero gran parte de las horas normales se componen de reuniones y otras distracciones sociales y personales. ¿Trabajan durante períodos de tiempo extra porque se sienten más productivos?

Reduzca la cantidad de trabajo en el sprint y comience a trabajar en el tiempo de flexión. Permítales que entren más tarde. La persona a cargo solo necesita decirle a la gente que se vaya a casa; todo está bien. Hay algunas culturas corporativas que crean un entorno en el que salir temprano puede provocar algunas críticas.

    
respondido por el JeffO 01.08.2012 - 17:10
fuente
0

Aconsejo fuertemente contra "bloques duros". Dichos controles podrían percibirse como una microgestión y pueden no abordar el problema subyacente.

Le sugiero que descubra por qué los programadores trabajan horas extras. La respuesta puede sorprenderte. Parece que eres un "forastero" (no un empleado de la compañía), y los programadores pueden estar dispuestos a ser sinceros contigo si te reúnes con ellos de forma privada (uno a uno).

¿La razón para trabajar horas extras realmente es la carga de trabajo, o es la razón más relacionada con la cultura o las expectativas?

Las razones de la carga de trabajo podrían ser

  • El retraso comprometido es demasiado grande
  • Ya sea programadores o el producto el propietario es "chapado en oro" (lo que hace que las funciones sean más complejas de lo necesario)

Las expectativas podrían ser

  • Algún tipo de recompensa financiera o de reconocimiento por trabajar horas extras
  • Miedo al fracaso. Los programadores temen que se vean mal o sean castigados si no cumplen con la fecha límite
  • Los programadores están subestimando los efectos dañinos a largo plazo de trabajar horas extras.
respondido por el Aaron Kurtzhals 01.08.2012 - 17:11
fuente
0

Luché con esto cuando primero cambié a scrum. Es natural querer hacer un esfuerzo adicional cerca de una fecha límite, pero el scrum tiene fechas límite cada dos semanas, así que es un ajuste. Además de la sugerencia que otros han hecho para reducir los puntos de historia comprometidos en cada iteración, también sugeriría que las historias se desglosen lo suficiente, para que cada desarrollador pueda terminar al menos dos o tres en una iteración.

Eso no solo garantiza que cada desarrollador sienta que ha logrado algo en cada iteración, sino que también le proporciona cierta flexibilidad en su alcance. Cuando su quema muestra que no podrá terminar una historia, puede sacarla y reasignar a las personas a las historias que se pueden terminar. Cuando las personas vean que se puede ajustar el alcance, será menos probable que se preocupen por los plazos poco realistas. Si comienza una iteración con cada historia en progreso, no tiene espacio para ajustes.

Un diagrama de flujo acumulativo ideal debería tener este aspecto si todos están terminando dos historias por iteración:

Nunca se ve así porque en realidad es muy difícil cronometrar todas las historias para terminar el último día mientras se mantiene a todos ocupados, pero es una buena regla general. Si está comprometido en exceso, el área roja será más grande y podrá eliminar historias. Si no estás comprometido, el área azul será más grande y podrás agregar historias. Si tus historias son demasiado grandes, el área verde será más grande y deberías dividirlas.

    
respondido por el Karl Bielefeldt 01.08.2012 - 19:30
fuente
0

Para evitar horas extras, debe reducir el alcance del proyecto.

El siguiente cuadro muestra dónde se encuentra la incertidumbre en un proyecto:

Siobserva,enlasfasesdedefiniciónyrequisitosdelproducto,tieneunagranvariaciónenlaestimacióndelesfuerzo.Nopuedeestarsegurodesitomaráunmesoundíaimplementarlafunción.

Estoyapostandoaqueningunadelastareasestá terminada porque simplemente están demasiado grandes y no especificados y hay demasiados de ellos.

Si su equipo puede manejar 10 boletos en 5 días, y se les asignan 20 boletos, reduzca ese número, páselo al propietario del producto / gerente de proyecto / gerente / cliente y dígales que prioricen.

En este punto, esa es la única forma de salvar al equipo de las horas extra. No puedes entregar todo, pero lo que hagas será menos probable que tenga errores.

También recomendaría buscar un nuevo trabajo y ayudar a los compañeros de equipo a hacer lo mismo y arreglar sus currículos y portafolios profesionales. Una empresa que espera horas extras es una para la que nadie debería trabajar, y el software producido tendrá muchos errores.

    
respondido por el Rudolf Olah 07.03.2015 - 17:58
fuente

Lea otras preguntas en las etiquetas