Me di cuenta en las reuniones de scrum, que los desarrolladores a menudo dan estimaciones realistas sobre las historias. Sin embargo, incluso las historias más simples requieren mucho esfuerzo para la configuración, la configuración de componentes de terceros, las pruebas y la compilación final, y el sistema ha acumulado bastante deuda técnica, por lo que las estimaciones a menudo parecen demasiado altas para el propietario o la administración del producto.
La orden de compra con frecuencia trata de vencer esas estimaciones, como: "¿Qué, quieres 13 puntos de historia [4 días] por esta historia, esto no puede ser! No puedo explicar esto a la gerencia, alguien debería poder codificar esto con 3 SP [en 4 horas] ". Como resultado, los desarrolladores se tuercen los brazos para comprometerse con una estimación de 5 u 8 puntos de historia [1.5 a 2 días] (las estimaciones de Scrum todavía se toman como compromisos, no solo como pronósticos).
Por supuesto, sin ningún plan para reducir las expectativas (principalmente en pruebas y calidad), estos sprints frecuentemente fallan. La estimación de los desarrolladores es honesta y realista, y superar la estimación no supera el trabajo real que se debe hacer.
Uno puede decir: "¡No debes hacer un compromiso imposible, solo porque alguien te obliga a hacerlo!" Pero, en mi opinión, el trabajo de un desarrollador es el diseño y codificación de software, ¡no negociar ni resistir la presión! Puede haber tomas de todos los comercios, generalmente aquellos que tratan directamente con clientes externos, ¡pero esta no es la mayoría de los desarrolladores de oficina!
Para mí, esta práctica solo hace que los programadores se vean como imbéciles, causa fallas constantes en el sprint y evita estimaciones realistas, además de buscar mejoras reales.
¿Qué dicen las pautas de Scrum sobre este tema, o dicen algo al respecto?
EDITAR: tiempos reemplazados por puntos de historia. Me refería a la fase de estimación inicial con Planning Poker y los puntos de la historia, no a la planificación detallada de la tarea. Simplemente puse los días / horas allí, porque a veces era un diálogo típico como este, también con tiempo en lugar de puntos. Perdón por cualquier confusión! Los ejemplos de puntos de la historia representan períodos de tiempo más largos que los ejemplos de tiempo.
EDITAR 2 Actualmente no hay un scrum master dedicado, y el PO toma ese papel, cuando se trata de reuniones de estimación. Por lo tanto, es probable que el conflicto de roles empeore esta negociación inapropiada, ya que aparece como una autoridad, en lugar de un maestro scrum neutral o desarrollador. Quizás, esto se puede solucionar tomándolo como un participante parcial en lugar de un "maestro", siempre que no haya ninguno disponible.
fuente
Respuestas:
La situación que describe es tóxica. Este tipo de negociación ignora la realidad y la experiencia del equipo, oculta deliberadamente información del equipo y la organización en general, e impide que el equipo mejore con el tiempo.
Si desea la ciudad http://www.scrumguides.org/scrum-guide.html como autoridad, destacaría:
y
El propietario de su producto puede desear que una tarea sea posible en solo 4 horas. Ese podría incluso ser un objetivo razonable. Una reacción saludable podría ser aceptar la estimación del equipo, medirla si es precisa y preguntar "¿qué necesitaríamos cambiar para poder completar este tipo de tarea más rápidamente?" Negociar el alcance del trabajo involucrado en la tarea también puede ser razonable y resaltar una diferencia importante en la forma en que los desarrolladores y el propietario del producto entienden ese trabajo en cuestión. Exigir que el equipo modifique sus estimaciones sin nueva información solo garantiza estimaciones inexactas.
Hay muchas estrategias que el equipo de desarrollo podría usar para tratar de cambiar este patrón, pero cuando da una respuesta de ejemplo de "No puedo explicar esto a la gerencia" me pongo muy nervioso. Parece que el propietario de su producto no tiene la confianza de la administración (las estimaciones inexactas que están produciendo probablemente no ayudan) y es posible que no esté dispuesto a ser transparente sobre las fallas actuales del proceso.
fuente
En mi opinión, uno de los mayores logros de SCRUM es el desarrollo de puntos de la historia, con la intención explícita expresada de evitar los problemas de negociación mencionados aquí. El objetivo de los puntos de la historia es evitar una conexión directa entre una tarea y cuántos días llevará. En cambio, esos dos conceptos están conectados por la idea de velocidad.
Si yo fuera un desarrollador, y estuviera siendo forzado a llamar a una historia de 13 puntos una historia de 8 puntos, me complacería. Sus capacidades de estimación están impactando. Simplemente escalaré todas mis dificultades para que coincidan. Eventualmente, la velocidad del equipo disminuirá en términos de puntos de historia por semana para igualar la voluntad de la gerencia de "repartir" los puntos de historia. Los números entregados a la gerencia deben coincidir: "Hemos reducido con éxito la cantidad de puntos de trabajo de la historia necesarios para lograr el hito en un 50%. Sin embargo, hemos visto una disminución correspondiente en la velocidad en un 50%, por lo que el efecto neto es que nosotros vamos a lograr exactamente lo que íbamos a lograr exactamente en la cantidad de tiempo que iba a tomar ". El concepto de velocidad existe para combatir las ilusiones de la alta dirección.
Ahora hay dos extremos que creo que vale la pena ver. Uno es un fracaso completo de la administración y el otro es en realidad una preocupación muy válida para que la administración se preocupe. El primer caso es una sentencia de muerte para SCRUM, cuando a los desarrolladores se les dice "no estás siendo lo suficientemente productivo. Necesitas producir más puntos de historia por valor de trabajo". Si eso sucede, en realidad no estás usando SCRUM, eres un Cookoo, que echó a SCRUM del nido y está tratando de ser alimentado por la madre ave que regresa al siguiente.
Ahora hay un caso en el que creo que la gerencia deberíaser capaz de participar en torcer el brazo de esta manera. Debería ser razonable que el cliente diga "No puedo permitirme 50 puntos de historia para completar esta tarea si su velocidad es de 20 puntos / semana. Necesito que lo logre en 30 puntos de historia", si ese cliente está dispuesto renegociar el contenido de esas historias para disminuir su alcance en un 40%. SCRUM no es un boleto de comida gratuito para que los desarrolladores hagan lo que quieran, es una herramienta de comunicación para ayudarlos a ellos y a la administración a conversar abiertamente sobre lo que hay que hacer. También es válido para un cliente presionar al desarrollador y decir "hacer la tarea en 30 puntos" si está dispuesto a aceptar el riesgo inherente de que el trabajo simplemente no se complete a tiempo. Cuando se vence el plazo, si los desarrolladores pueden decir " y luego acepta lo que realmente se hizo. Creo que hay mejores formas de medir la productividad de un equipo, pero debo admitir que es un proceso que funciona. y luego acepta lo que realmente se hizo. Creo que hay mejores formas de medir la productividad de un equipo, pero debo admitir que es un proceso que funciona.
fuente
Por un lado, el PO no debería estar dando información de tareas a la gerencia. Las estimaciones de la tarea son estrictamente para el beneficio del equipo. Lo único que cualquier persona fuera del equipo necesita saber es en qué historias están trabajando, cuáles son sus valores de puntos y cuál es la velocidad promedio del equipo. T
En segundo lugar, a menos que el PO sea un desarrollador de nivel superior con un profundo conocimiento del software, su opinión sobre las estimaciones de tareas no debería tener mucho peso. Los desarrolladores son los que tienen el conocimiento del sistema y los que están haciendo el trabajo. A menos que todos estén recién salidos de la escuela con habilidades de estimación cero, sus estimaciones deben ser exceptuadas.
Eso no quiere decir que las estimaciones a veces no se puedan cuestionar. Si es así, esto debe suceder de manera positiva. Por ejemplo, "¿ha considerado que ya hemos hecho la mitad del trabajo para" x "" o "¿recordó incluir el tiempo para hacer Y?".
En pocas palabras: los desarrolladores deben sentirse seguros para hacer las estimaciones que deseen, siempre que hagan un intento de buena fe para ser precisos. Si dicen que algo lleva cuatro horas, debes aceptar eso.
No dicen nada en absoluto. La estimación de tareas no es parte del scrum. Con scrum, la estimación se detiene en los puntos de la historia. La estimación de la tarea es simplemente una herramienta para ayudar a los equipos a mejorar la estimación de los puntos de la historia al asegurarse de que hayan pensado en todo el trabajo necesario para completar una historia.
fuente
Es tarea del Scum Master asegurarse de que se siga el proceso scrum. Esto incluye asegurarse de que el equipo no se compromete (consistentemente) en la cantidad de trabajo que pueden realizar en un sprint.
Por un lado, eso significa reinar un equipo demasiado entusiasta, pero por otro lado también presionar al Propietario del Producto si está presionando al equipo.
Una buena manera de mantener el compromiso / pronóstico realista es mirar las historias que se hicieron realidad en los últimos sprints. Eso es lo que el equipo ha demostrado que pueden lograr, por lo que no tiene sentido dedicar mucho más trabajo a una carrera, ya que no se completará.
Como también indican otras respuestas, la negociación sobre las estimaciones proporcionadas por el equipo no es parte del proceso Scrum. El equipo está más familiarizado con el software, por lo que deberían saber mejor cuánto trabajo es algo.
Lo que se puede negociar es el alcance de una historia. Si el Propietario del producto cree que una historia se estima como mucho más grande o más pequeña de lo que razonablemente esperaban, puede solicitar una aclaración del equipo para ver si la visión del trabajo que debe realizarse coincide con las partes.
Si la historia es realmente tanto trabajo, el propietario del producto puede decidir dividirla en varias historias más pequeñas y distribuir la funcionalidad sobre esas historias más pequeñas.
El equipo es responsable de brindar calidad y eso nunca debe abrirse a la negociación.
fuente
Si y no.
Sí, el equipo de sprint debería negociar con el propietario del producto sobre lo que entra en el sprint.
No, el propietario del producto no tiene voz en cuanto a cuánto tiempo tomarán las cosas. Ustedes son los expertos, no ellos.
Mire, no debería tener que lidiar con ese tipo de basura: su gerente o líder de equipo están allí para prepararlo para el éxito. Eso significa tratar con el primer ministro (o su jefe) para que tenga éxito. Dicho eso, no es tan difícil.
"No."
Qué van a hacer? ¿Escribir el código ellos mismos?
fuente
Permitir este comportamiento es una falla del Scrum Master. Su trabajo, ante todo, es proteger al equipo. El PO, por las razones descritas anteriormente, es miope. El Scrum Master debería intervenir y, de manera positiva, replantear el contexto de la discusión.
Tal presión, por supuesto, conducirá a una presión descendente sobre la velocidad, algo que el OP ya citó. Si los equipos no terminan constantemente sus sprints, el Scrum Master debería intervenir nuevamente y preguntar por qué podría ser así. En entornos verdaderamente tóxicos, los miembros del equipo podrían no sentirse libres para ser honestos en las Retrospectivas. Pero en esa situación, el Scrum Master tiene la responsabilidad de denunciar el mal comportamiento y proteger al equipo.
Si te encuentras en una situación en la que tu Scrum Master no puede o no hará estas cosas, entonces probablemente necesites un Scrum Master diferente. El PO está respondiendo a presiones típicas. El equipo, en espeleología, también está respondiendo como lo hacen a menudo los humanos. Es el trabajo del Scrum Master ver esto por lo que es y detenerlo. La responsabilidad del OP aquí es plantear esto en la Retrospectiva y, si es necesario, a los líderes y gerentes. Si eso aún no lo resuelve, actualice su perfil de LinkedIn y encuentre mejores personas para trabajar.
fuente
Un equipo de desarrollo de productos (es decir, todos, desde el propietario del producto hasta los desarrolladores y los probadores) puede seguir el proceso ágil y obtener buenos resultados con personas razonablemente competentes y expectativas realistas.
O pueden seguir un proceso que se parece superficialmente al proceso ágil.
Ese PO probablemente piensa que obtendrá mejores resultados al tratar de obtener estimaciones de tiempo más bajas para las tareas. Por supuesto que no funciona. Si algo toma tres días, me das mucho efectivo y te daré un estimado de que puedo hacerlo en una hora. Todavía llevará tres días. Si vienes y me gritas porque no está terminado en una hora como lo prometiste, tomará cinco días.
Todo lo que logra es romper el proceso ágil y renunciar a todos los resultados positivos que podría obtener. El scrum master debe tener la experiencia, el poder y el coraje para evitar esto. Si la administración convierte a alguien en scrum master que no tiene la experiencia, o no le da al scrum master el poder para evitar esto, es su culpa que se agilice la agilidad. Si el maestro scrum no tiene el coraje, entonces comparte la culpa con el primer ministro.
fuente
Yo diría que depende mucho de la motivación aquí. El objetivo general de la estimación es tener una idea de cuánto puede lograr el equipo durante un sprint determinado, lo que permite pronosticar el trabajo futuro en función de esa velocidad. Por ejemplo, si el equipo está completando 30 puntos de historia en cada sprint, y hay aproximadamente 60 puntos de historia por delante del Artículo X en la lista de pedidos pendientes, el Propietario del Producto puede decir razonablemente que el Artículo X estará completo en algo así como 6 semanas (basado en un Sprint estándar de dos semanas).
Para que esta estimación sea lo más precisa posible, no es extraño tener un desacuerdo sobre cuántos puntos de la historia es un elemento en particular. Scrum en realidad lo alienta. Ese desacuerdo puede a veces incluso calentarse. Sin embargo, el objetivo final final debe ser estimar con precisión la complejidad del PBI, no desinflar artificialmente el esfuerzo para que pueda intentar meter más PBI en una velocidad dada.
Así es en realidad cómo funciona la planificación del póker, en principio. Todos exponen su estimación. El Scrum Master, luego toma la estimación alta y baja y pregunta por qué el miembro del equipo piensa que debería ser tan alto / bajo. Esto le da al equipo la oportunidad de escuchar perspectivas alternativas del trabajo involucrado y tener una mejor idea de cuán compleja es realmente la tarea. Después de la discusión, todos lanzan sus estimaciones nuevamente. Este proceso se enjuaga y repite hasta que haya un consenso general sobre la complejidad.
En otras palabras, no está mal cuestionar su estimación, dado que el retador tiene una justificación de por qué no está de acuerdo, aparte de que solo quiere que sea más bajo. Es su responsabilidad, entonces, convencer a su equipo de que su estimación es correcta, si cree que todavía lo es.
fuente