¿Scrum sprints significa trabajar al ritmo más rápido posible?

21

Recientemente entrevisté a algunas compañías que hacen Agile, Scrum para ser más precisos y hay algunas cosas que no me parecen ágiles. Tomaré un caso que me interesa particularmente ahora, el de Scrum sprints.

Un gerente de proyecto en particular con el que hablé (sí, dije gerente de proyecto) dijo con orgullo que las personas de su equipo entienden ("me dijeron" es lo que aprendí del contexto) que no te vas a casa cuando terminan las horas de trabajo , te vas a casa cuando el trabajo está hecho, no importa cuánto te lleve. Lo que he leído entre líneas es que agrupamos tantas funciones como sea posible en un sprint y trabajamos horas extras para que esto suceda.

Ahora, no he hecho Agile por ahora (trabajé con instituciones financieras y gubernamentales que la mayoría todavía prefieren cascada) pero entiendo que:

sprint en Scrum es el nombre de la iteración genérica en Agile;
el equipo debe trabajar a un ritmo sostenible y tratar de evitar las horas extra a largo plazo, ya que eso tiene efectos solo en el corto tiempo y los efectos se ven reducidos por los problemas en los que incurren a largo plazo.

¿Son correctas mis declaraciones? Y, ¿debo tomar la presentación del gerente como una bandera roja?

agile scrum development-methodologies

— JohnDoDo
fuente

Tampoco hay experiencia real con Agile, pero por lo que he entendido, su carga de trabajo de sprint debe equilibrarse con la duración de su sprint, por lo que los desarrolladores están subestimando su carga de trabajo o el gerente solo les está dando trabajo sin pedirles su opinión sobre la carga de trabajo. . En este caso, probablemente el último. - Corrígeme si me equivoco, sin embargo

— Andreas

44

@gnat Creo que las preguntas son muy diferentes

— Andreas

27

"... no te vas a casa cuando terminan las horas de trabajo, te vas a casa cuando el trabajo está hecho, no importa cuánto te lleve ...". Corre como el viento. Ella es una idiota

— JᴀʏMᴇᴇ

He votado para reabrir esta pregunta. La cuestión del duplicado propuesto es "ágil-la-nueva-microgestión" tiene en común con esta pregunta, que el gerente llama a algo "scrum" y el autor de la pregunta quiere saber si esto es realmente scrum. Esta pregunta es sobre "horas extras", la propuesta sobre "no está permitido hablar con otros desarrolladores".

— k3b

"... que no te vas a casa cuando terminan las horas de trabajo, te vas a casa cuando el trabajo está terminado, no importa cuánto se necesite" parece un conflicto directo con el concepto clave de ritmo sostenible: trabajar allí si tuviera que poner comida en la mesa. HST, si esto ocurre de vez en cuando, no tengo ningún problema. A veces, a pesar de todos los esfuerzos, hay una crisis y el cliente es lo primero. Pero ella lo hace sonar como si fuera algo habitual, y que sea admirable. Lo que significa es que no están haciendo la causa raíz para entender por qué está ocurriendo y solucionar el problema subyacente.

— Don Branson

27

No tiene que buscar mucho para ver que estas prácticas son contrarias a los principios detrás de Agile. Uno de los principios detrás del Manifiesto Ágil establece:

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.

Hace unos años, Scrum hizo un cambio sutil pero importante . En lugar de que los equipos se comprometan con el trabajo que se puede lograr, pronostican lo que creen que pueden hacer.

El cambio se produce debido al abuso, que se parece mucho a la actitud de "no ir a casa hasta que se hace" que usted describe. En el desarrollo, hay muchos factores fuera del control de los equipos con los que no pueden comprometerse: para usar la analogía del clima, no se puede "comprometer" que lloverá mañana.

Para responder directamente a sus preguntas:

sí, Sprint es el nombre de una iteración en Scrum, vea esta respuesta para ver la diferencia
Sí, los equipos deberían trabajar a un ritmo sostenible. La única certeza de las horas extraordinarias es que va a reducir la productividad de los equipos a largo plazo.
sí, es una bandera roja!

— Dave Hillier
fuente

23

Sí, tienes razón, y si me dijeran lo que te dijeron, huiría de allí lo más rápido posible. Solo están usando ágil como excusa. Suena como la clásica marcha de la muerte.

— Miki Watts
fuente

3

¿No terminaría una marcha de la muerte? Ese proyecto suena como un infierno eterno si así es como funcionan sprint tras sprint.

— DXM

55

No, en una marcha de la muerte siempre hay "solo tenemos que pasar a la próxima versión, ¡luego podemos refactorizar y corregir errores! ¡Vaya! Le prometimos al cliente la próxima próxima versión en dos meses, solo tenemos que pasar a la próxima. ¡versión!" y así sucesivamente, te haces una idea.

— Miki Watts

2

@DXM tiene un final cuando todos renuncian o son despedidos. Los proyectos de la Marcha de la Muerte pueden durar años.

— Dogweather

3

Las marchas de la muerte de @DXM terminan cuando mueres.

— Dave Hillier

hmm, supongo que estaba proyectando mi propia experiencia allí. De alguna manera, en mi opinión, los proyectos mal administrados son una combinación de marcha de la muerte seguida de meses de indecisión sobre a dónde ir después. El tiempo más largo que nuestro equipo se sentó sobre sus pulgares con una cartera de pedidos vacía fue de casi 8 meses. Luego, tendríamos entre 4 y 6 meses para un lanzamiento con la declaración "estamos en un ciclo de lanzamiento anual"

— DXM

11

Hay una cosa clave que puede hacer que esto sea aceptable: el equipo acepta el alcance del sprint.

En Scrum, los equipos no solo reciben trabajo asignado. El propietario del producto negocia con el equipo para priorizar el trabajo del producto y el trabajo técnico (deudas). El gerente del proyecto, el propietario del producto y el equipo luego negocian qué se lleva a un sprint y cuál es el alcance de ese trabajo.

En este mundo, el equipo esencialmente dice "podemos hacer que X trabaje, pruebe y envíe esta iteración". Por lo tanto, esperaría que un equipo ocasionalmente trabaje horas extras para cumplir con estos compromisos.

Dicho esto, muchos lugares bastardan ágilmente y tan pocos líderes de equipo pueden negociar efectivamente con personas que generalmente son sus jefes ... Tomaría esto como una gran bandera roja.

— Telastyn
fuente

8

"ocasionalmente trabaja horas extras para cumplir con estos compromisos ( erróneamente estimados )" => hacer estimaciones incorrectas en un hábito

— mosquito

1

@gnat - pssh. Las estimaciones son a veces altas. Las estimaciones son a veces bajas. Si la subestimación se convierte en una tendencia, ciertamente es un problema. Pero eso es en gran parte por qué existen iteraciones: para ayudar a refinar la estimación.

— Telastyn

8

Los talleres de programación generalmente no aceptan negociaciones de los trabajadores.

— maple_shaft

1

@gnat: Si encuentra, como equipo, que habitualmente está subestimando el trabajo, debe comprometerse a menos trabajo en el próximo sprint.

— Bart van Ingen Schenau

Cuando los objetivos de gestión son realizar la mayor cantidad de trabajo posible, independientemente de los límites en las horas de trabajo (y la experiencia indica que esto es cierto en la gran mayoría de los casos), y los objetivos de los empleados son realizar la mayor parte del trabajo sin exceder el trabajo remunerado horas (admito que algunos gerentes pueden argumentar que esto es optimista), entonces, independientemente del error inherente en la estimación, la programación siempre tenderá a> = horas de trabajo. La extensión lógica es que los objetivos de los empleados deben pasar a subestimarse. @BartvanIngenSchenau así es como se desarrolla naturalmente ese hábito.

— Steven Evers

1

Scrum se divide en sprints donde calculas un conjunto de tareas que se completarán en la duración de ese sprint (generalmente 2 semanas, pero he visto entre 1 día y 4 semanas). Creo que esto crea un incentivo para desestimar las tareas. Las OP (propietario del producto) querrán estimaciones bajas para obtener un gran compromiso por sprint. El equipo hará grandes estimaciones para generar buenos gráficos de consumo para que los PM lo vean. Estos son, por supuesto, indicativos de una mala organización. Realmente desea obtener estimaciones precisas y no tener miedo de quedarse corto y llevar las historias al próximo sprint o terminar temprano y sacar tareas adicionales del trabajo atrasado. Creo que el término "sprint" crea esta imagen de personas que trabajan más rápido.

— jiggy
fuente

1

excepto que PO no debería tener parte en el proceso de estimación. Si fueran ágiles, los equipos serían los únicos responsables de elaborar estimaciones y, basándose en lo que el equipo estima, PO solo puede cambiar las prioridades de la cartera de pedidos.

— DXM

2

"El equipo hará grandes estimaciones para generar buenos gráficos de consumo para que los PM lo vean": esta es una de las razones por las que creo que todo este mecanismo es defectuoso. Creo que un gerente puede obtener un rendimiento mucho mejor de un equipo en el que confían que obligar a un equipo a proporcionar estimaciones para alimentar los gráficos.

— Giorgio

El equipo debería, pero como dije, tienen un incentivo para rellenar las estimaciones. Si la OP es la que paga, pueden aplicar presión para estimar de manera más agresiva. Para los antecedentes, trabajo en consultoría, por lo que el equipo scrum son mis compañeros de trabajo, mientras que el PO generalmente es externo y paga nuestra tasa de facturación inflada :)

— jiggy

@Giorgio, un equipo no confiable siempre puede aumentar las estimaciones y empeorar las cosas. Pero un equipo confiable, incluso de expertos, puede aprender a estimar mejor. Es por eso que se hacen las estimaciones, y luego se comparan con el trabajo real, para tratar de mejorar su capacidad de estimar. El mecanismo no tiene fallas, tener un equipo que se está aprovechando de un sistema es el problema, y será el problema independientemente del sistema de gestión.

— Chris

1

No: los sprints de scrum son un timebox, nada más y nada menos. Al comienzo del sprint / iteración, el equipo da una estimación de la cantidad de puntos de historia que creen que pueden lograr, basándose en cosas como el rendimiento anterior, la disponibilidad, los próximos eventos, los impedimentos abiertos, etc. Luego negocian con el propietario del producto. sobre qué historias de usuarios se ponen en el sprint. Ese es (o fue? Ver otra respuesta) el compromiso que el equipo le da al propietario del producto.

Durante el desarrollo, si resulta que las cosas no son realmente las predichas (es el desarrollo de software después de todo) y existe el riesgo de que el equipo no cumpla con el compromiso, informan al propietario del producto que existe el riesgo de que una o más historias ocurran No se completará.

Y eso está bien. Claro, se siente mal, tener que admitir al final del sprint que el sprint falló, pero no es una derrota, es una oportunidad para mejorar. Porque al final del sprint / inicio del nuevo, puedes hacer una retrospectiva del sprint, y lo primero que alguien preguntará es '¿Por qué fallamos este sprint y qué debemos hacer para no volver a fallar? ? Una opción sería emitir menos compromiso (= tomar menos puntos de historia).

tl; dr: ritmo sostenible. Scrum se trata de cadencia, algo que el equipo puede mantener indefinidamente sobre una base de sprint a sprint. Trabajar horas extras no lo es; el equipo tendrá un exceso de trabajo, el trabajo se volverá descuidado, los miembros se enfermarán o dejarán de fumar por completo, y luego tendrá un problema mucho mayor que un sprint fallido.

— Cthulhu
fuente

0

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.

De la gente del Manifiesto Ágil

Trabajar horas extras todo el tiempo no me parece sostenible.

Dicho esto, no veo ningún problema con un compromiso de primavera que sea fuerte (si esa es la forma en que el equipo quiere trabajar), y tener que trabajar horas extras cuando se compromete demasiado o arruina las estimaciones es un buen incentivo para mejorar en la estimación o comunicación expectativas a PO.

— ptyx
fuente

0

Un gerente de proyecto en particular con el que hablé (sí, dije gerente de proyecto) dijo con orgullo que las personas de su equipo entienden ("me dijeron" es lo que aprendí del contexto) que no te vas a casa cuando terminan las horas de trabajo , te vas a casa cuando el trabajo está hecho, no importa cuánto te lleve. Lo que he leído entre líneas es que agrupamos tantas funciones como sea posible en un sprint y trabajamos horas extras para que esto suceda.

Eso no es Scrum. La carga de trabajo propuesta para un timebox se basa en la velocidad del equipo , no en la lista de deseos del gerente. Simplemente están tratando de engañarte para que creas que trabajar horas extras sin fin es "ágil", lo cual no es así. El equipo se volverá más eficiente mientras trabaja tranquilo y concentrado, pero Scrum no es una varita mágica para obtener ganancias de eficiencia sin fin .

O el gerente tiene un ligero malentendido de Agile, o (lo más probable) piensa que los desarrolladores son tan estúpidos. Por otro lado, cuando el equipo acepta el sprint una y otra vez, sabiendo que necesitarán hacer horas extras, ¿tal vez sean realmente estúpidos y no lo merezcan mejor?

Supongo que sabes la respuesta ... ;-)

— JensG
fuente