it-swarm-es.com

Mi jefe de proyecto no acepta el arrastre en Scrum, ¿es eso normal?

Soy un desarrollador que trabaja en una nueva aplicación móvil para Android e iOS con un gran componente de back-end. Hemos estado en tres sprints de este proyecto, y usamos Scrum con todas sus ceremonias (refinamiento , planificación, diarios, retrospectivas, etc.).

En dos de los sprints, el equipo tuvo que trabajar horas extras (no remuneradas) y fines de semana, porque la administración estaba muy alarmada de que no completáramos el compromiso del sprint a tiempo. Todos trabajaron duro, pero algunas dependencias externas y estimaciones optimistas nos hicieron luchar para lograr todas las historias de sprint.

En mi experiencia, tener un pequeño porcentaje de historias no completadas durante algunos sprints es algo normal, y pueden abordarse en la próxima. Pero nuestro gerente de proyecto dice que es nuestra culpa, ya que hicimos la estimación nosotros mismos, por lo que debemos completar todos los elementos en el sprint.

  1. ¿Es esta una variación aceptable/común de Scrum que no conozco?

  2. ¿Cómo sugieres que actúe sobre esto?

52
MrAn3

Algunas cosas me destacan.

La idea de que la gerencia tiene que el equipo se compromete con un conjunto de trabajos es inconsistente con las últimas versiones de la Guía Scrum. La palabra "compromiso" o "compromiso" solo se usa dos veces en la versión más reciente (noviembre de 2017) de la Guía de Scrum, una vez cuando se enumeran los valores de Scrum y otra vez para indicar que "las personas se comprometen personalmente a lograr los objetivos del Equipo Scrum". ".

La idea de los objetivos es importante para Scrum. No solo las organizaciones y los equipos tienen objetivos amplios, sino que en Scrum, cada Sprint tiene un Objetivo Sprint que se define en Sprint Planning como una colaboración entre el Propietario del producto y el Equipo de desarrollo. El objetivo de Sprint se cumple mediante la implementación de elementos del Backlog del producto, pero no es simplemente "terminar este trabajo" y, a menudo, no representa el Backlog completo de Sprint. Es decir, debe ser capaz de alcanzar el objetivo de Sprint sin completar todos los elementos de la Lista de pedidos de productos seleccionados para Sprint o cada elemento de la Lista de pedidos de Sprint. Mi opinión actual es que el trabajo necesario para lograr el Objetivo Sprint debería estar en algún lugar alrededor del 60-70% de la capacidad de su equipo, sin embargo, usted tiene en cuenta la capacidad. Sin embargo, las diferentes organizaciones serán diferentes, pero es probable que sea un buen punto de partida.

Trabajar horas extras y fines de semana también es una práctica de desarrollo de software anti-ágil. Uno de los principios subyacentes es que todas las partes interesadas de un esfuerzo pueden trabajar a un ritmo sostenible. Los días largos y los fines de semana, incluso si se pagaran, no son sostenibles para un equipo.

En este punto, hay algunos pasos siguientes. El Scrum Master del equipo debería educar a la gerencia sobre los valores y principios del desarrollo de software ágil y Scrum (como el "compromiso" y el "ritmo sostenible"). El equipo debe trabajar en su capacidad de pronosticar el trabajo y negociar el alcance con el Propietario del producto. El equipo también debe identificar y trabajar para resolver o prevenir los impedimentos que llevaron a esta situación (eliminar o reducir el impacto de las dependencias externas).

76
Thomas Owens

La situación que usted describe, donde la administración requiere que el equipo trabaje horas extras para completar todas las historias planificadas, es una de las razones por las cuales la literatura de Scrum ha dejado de usar el término "compromiso". Solo se puede dar un verdadero compromiso cuando se elimina toda la incertidumbre, incluida la incertidumbre sobre las dependencias de terceros, cuánto trabajo es cada elemento, cuánto tiempo estarán disponibles todos teniendo en cuenta la enfermedad, etc.

Una de las ideas básicas de Scrum es que el equipo trabaja a un ritmo sostenible, lo que esencialmente significa trabajar horas normales sin horas extras (remuneradas o no). Esto significa directamente que estás no experimentando una variación aceptable de Scrum.

Lo que puede hacer al respecto depende de su función.

Si eres desarrollador, entonces lo mejor que puedes hacer es

  • (colectivamente como equipo de desarrollo) se niegan a "comprometerse" con más trabajo del que está absolutamente seguro de que puede entregar en un sprint. Esto probablemente será mucho menos de lo que la gerencia quiere que haga.
  • concéntrese en terminar el trabajo, en lugar de comenzar en nuevas tareas. Si ve que parte del trabajo no se puede completar, indíquelo lo antes posible para que los planes se puedan ajustar.

Si eres un maestro de Scrum, entonces realmente puedes demostrar tu valía educando a la gerencia sobre Scrum. Algunos puntos que me destacan:

  • Como se indicó en el primer párrafo, el equipo no se compromete durante la planificación del sprint, pero dan un pronóstico del trabajo que esperan haber terminado.
  • Aunque el equipo debe evitar tener un trabajo inacabado al final de un sprint, esta situación es casi inevitable al comienzo de un proyecto (o después de un cambio en la composición del equipo). La cantidad de trabajo que el equipo puede realizar de manera realista en un sprint solo puede determinarse en función de las cifras históricas de los últimos sprints del equipo en esta composición. Al principio del proyecto, tales figuras históricas simplemente no existen, por lo que un equipo que logre en los primeros 3 sprints exactamente lo planeado para cada sprint es más un accidente que una buena planificación. Después de aproximadamente 5 sprints a un ritmo sostenible, hay suficientes datos para tener una idea razonable de cuánto trabajo puede terminar el equipo de manera realista dentro de un sprint.
33

Su PM no tiene nada que ver con su scrum.

Su PM no tiene por qué pedirle horas extra sin pagar.

Lo obvio es hacer una estimación de todas las tareas de tal manera que pueda garantizar que se completarán a tiempo. Entonces deberías poder ir al pub de la segunda manera, ya que claramente si subestimar una tarea significa que la terminas gratis, entonces sobreestimar significa que tienes tiempo sin trabajo.

21
gnasher729

Hay varios aspectos de esto, pero a un nivel alto, sí, el PM absolutamente querrá entender claramente por qué el trabajo planificado no se ha completado. Sin embargo, esto debería plantearse (y resuelto) en la retrospectiva. Desde el lado del desarrollador, hay muchos factores que pueden contribuir a las fallas de sprint.

Algunas cosas que puede considerar:

Demasiado en el sprint

Si regularmente te comprometes a demasiado trabajo, los sprints fallarán. La velocidad del sprint debe rastrearse con el tiempo para averiguar cuál es el número óptimo de puntos (o días).

Asignación de recursos

Asegúrese de que la planificación del sprint tenga en cuenta adecuadamente las actividades que no son de desarrollo, como las ceremonias, los días festivos, la capacitación, la administración, el apoyo y otros proyectos, etc. ponerte en el pie trasero desde el principio.

variación estimada

Estás haciendo un refinamiento, pero ¿hay ciertos tipos de tareas que siempre se desbordan? Por lo general, estos se deben a requisitos vagos o faltantes. Si los requisitos son imprecisos, la historia ni siquiera debería llegar al sprint a menos que se haya refinado adecuadamente o se haya planeado un pico.

Velocidad

Si la velocidad se rastrea adecuadamente, la verdadera cantidad de historias debe quedar clara. Eso no quiere decir que siempre se harán a tiempo, pero debería facilitar las cosas.

Buena voluntad

En cualquier proyecto, la buena voluntad es limitada. Si constantemente trabaja sin horas para entregar, la moral se verá afectada y los desarrolladores se agotarán - esta es una falla de gestión del proyecto =. Como ya he descrito, asegúrese de que la planificación de sprints solo programe un número realista de historias usando velocidad y picos para ayudarlo en el camino.

Picos

Si un artículo está mal refinado o es simplemente lanoso, no tengas miedo de poner un pico para proporcionar una mejor estimación de los sprints posteriores. Sí, algunas personas son malas en la estimación, pero la mayoría de las veces, los hechos completos simplemente no se conocen en ese momento. Idealmente, esto debería haber sido cubierto en el refinamiento o recogido temprano por el PO, pero a veces pueden deslizarse en un sprint. Los desarrolladores deberían estar presionando estos duros ya que pueden torpedear fácilmente un sprint que de otra manera iría bien.

12
Robbie Dee

No, esta no es una forma reconocida de Agile, por una razón muy importante: si se compromete a entregar todo , no estás haciendo Agile, estás haciendo Waterfall, y si crees que estás haciendo Agile en su lugar, probablemente estés haciendo Waterfall mal , a eso. Estoy seguro de que has escuchado la vieja sierra "buena, rápida, barata, elige dos", ¿verdad? Con el desarrollo de software, es más como "todas las funciones entregadas, a tiempo, dentro del presupuesto, elija la primera o las otras dos". Waterfall elige el primero, y Agile elige los segundos dos.

Si va a ser ágil, necesita la flexibilidad para eliminar historias del Sprint que no puede completar a tiempo. Una forma posible de hacer esto es pedirle al propietario del producto que evalúe las historias utilizando la priorización de MoSCoW. Esto implicaría seleccionar no más del 60% de las historias (por el total de puntos de la historia) como Debe tener que se completará, 20% como debería tener que debe completar al concluir el proyecto y se lanza el Producto mínimo viable, 20% como Podría Haves que podría completarse si tiene el tiempo, y cualquier cosa fuera del alcance de la versión actual como Won't Haves. También es importante tener en cuenta que, cuando se combinan, los Must Haves deben tener suficiente carne en sus huesos para crear el Producto mínimo viable sin necesidad de incluir ningún elemento de las otras categorías.

Determinar si se deben dejar caer o no los artículos de la reserva de Sprint es responsabilidad del propietario del producto, después de que el equipo lo haya solicitado, y cualquier artículo que se haya caído de la reserva de Sprint sea evaluado por el propietario del producto, y luego eliminado del proyecto por completo, o colocado en el Backlog del proyecto en una posición debidamente clasificada.

En este caso, supongo que el propietario de su producto es su gerente de proyecto, ¿verdad? Sería su trabajo determinar qué tareas abandonar, por lo que ciertamente no debería culparlo por comprometerse demasiado, ya que sería su trabajo abandonar las tareas para compensar eso, y parece que no lo está haciendo.

10
nick012000

Él tiene razón, que no debería haber ningún traspaso entre sprints. Los equipos Scrum que tienen una transferencia entre sprints es un antipatrón y no es algo que Scrum canónico acepte como resultado válido.

Pero, su enfoque no es bueno.

Durante un sprint, el equipo debe monitorear constantemente el trabajo que se realiza y si pueden mantener su compromiso de planificación de sprint para terminar las historias seleccionadas. Si el equipo identifica que no puede terminar todas las historias, debe reunirse con PO y seleccionar una historia para eliminar del sprint. Al hacerlo, todos DEJAN DE TRABAJAR EN LA HISTORIA y se concentran en completar las historias restantes. Recuerde: siempre es mejor terminar una historia por completo que tener dos historias a medio terminar.

Los problemas de las dependencias externas y la estimación imprecisa es exactamente por qué existen las retrospectivas. Durante Retro, el equipo debe reflexionar e identificar estos problemas. Y el equipo debe encontrar e implementar soluciones a esos problemas. Las estimaciones pueden hacerse más precisas al conocer mejor el sistema y la experiencia simple. Las dependencias externas son más difíciles, pero no imposibles de solucionar.

Scrum Master no debe permitir que tu PM ( ¿qué está haciendo incluso PM en un equipo Scrum ?? )) te obligue para terminar todas las historias. En cambio, si tiene quejas, debería guardarlas para Retrospectiva. Y aún mejor, debería ser parte de la solución de los problemas que impidieron que las historias se terminaran a tiempo.

6
Euphoric

¿Es esta una variación aceptable/común de Scrum que no conozco?

No. Está completamente mal. Podría ¡tal vez simpatizar con pagado horas extras, si la OP cometió el error de entregar las estimaciones como hechos antes del final del sprint, pero sin pagar = las horas extra son completamente ridículas y me harían buscar otro trabajo lo antes posible.

¿Cómo sugieres que actúe al respecto?

En mi experiencia, las personas que son tan ferroviarias no escucharán argumentos lógicos. La única forma de que vean qué tan roto está es mostrar, no decirlo. Entonces, la próxima vez que haga una estimación y se comprometa, comprométase a ¡la cantidad más pequeña posible. Comprométete a terminar un pequeño boleto al final del sprint. Uno que podrías hacer en un día. Vea cómo reacciona su PM. Luego comience una discusión a partir de ahí sobre para qué se utiliza el sistema y para qué se utiliza el sistema debería.

5
nvoigt

Generalmente, al comienzo del proyecto, cuando decidimos la velocidad del equipo, buscamos un número conservador (más bajo de lo habitual) considerando el hecho de que es un equipo nuevo, tomaría un poco de tiempo para que el equipo se calme , nos entendemos, entendemos los requisitos funcionales y NFR, etc. Básicamente, después de los primeros sprints optimizamos la velocidad del equipo y obviamente la velocidad solo mejorará a partir de ese punto.

No tiene sentido cometer una velocidad más alta al principio y estirar al equipo para lograrlo.

Una cosa más es que, en un escenario único, donde hay un compromiso de entrega que no se puede perder, los gerentes de proyecto pueden presionar al equipo para que se estire, trabaje hasta tarde y trabaje los fines de semana. Pero eso debe considerarse como una excepción y no la norma de trabajo. Trabajar así podría aumentar la velocidad a corto plazo, pero a largo plazo sería contraproducente, ya que podría generar problemas de calidad del código, problemas de agotamiento del equipo, equipo descontento con poca motivación, etc.

4
Rajesh Nair

Compromiso FAQ

¿Es normal este comportamiento?

No estoy seguro.

¿Es sorprendente?

No. Algunas personas siempre entenderán que "compromiso" significa que todo en el compromiso debe debe completarse.

¿Es una buena idea?

No. El desarrollo ágil tiene sostenibilidad como tema central: trabaje solo tanto/largo/duro como pueda hacer indefinidamente. Esa es una idea sensata en la mayoría de los casos. (Si su gerencia no acepta esto, no deberían llamar a su organización ágil).

¿Qué debemos hacer?

  • Explique que el contenido del sprint se basa en un estimado. "Estimación" significa que solo algunas veces será correcto, y generalmente estará equivocado. Cuando está mal, a veces es demasiado bajo y a veces demasiado alto.
  • Explique que es mucho más fácil cambiar el comportamiento de estimación que la velocidad de trabajo.
  • Explique que cuando el equipo es castigado por estimar demasiado alto, solo estimará más bajo y la gerencia perderá mucho más progreso de esa manera que al pasar ocasionalmente parte del contenido de un sprint al siguiente.

Lo bueno es que su gerente de proyecto ya sabrá todas estas cosas y las reconocerá como correctas. Es solo que a corto plazo uno puede preferir ignorarlos.

2
Lutz Prechelt

No estoy de acuerdo con su equipo de gestión. No deberían haberte hecho trabajar horas extras para terminar el sprint.

Sin embargo, la idea de que los compromisos no son posibles proviene de un malentendido del desarrollo de software. He visto a muchos equipos tratar de predecir las historias que pueden completar en un sprint por la cantidad de puntos de historia que han completado en sprints anteriores. Si eso fuera posible, diría que el desarrollo de software es lineal, es decir, si trabajo dos horas, hago el doble que en una hora.

El desarrollo de software es creativo y, por lo tanto, no lineal. Es una mejor práctica para el equipo contarle a la gerencia lo que pueden hacer en un sprint y luego entregar esas historias. Si constantemente pierde sus compromisos, no tenía idea del alcance de la historia para empezar o el propietario de su producto lo está presionando para asumir más.

En el primer caso, debe asegurarse de comprender el alcance de la historia antes de aceptar seguirla. Si es lo último, tiene un problema cultural y hay poco que se pueda hacer.

2
John Douma