Gestión de procesos Scrum: consejos, trampas e ideas [cerrado]

Question

He estado haciendo scrum con un equipo por un tiempo, pero las cosas parecen complicadas por algunas razones.He estado pensando en cómo podrían cambiarse y tengo un par de preguntas que me gustaría plantear aquí.

En primer lugar, ¿cuál debería ser el papel de los evaluadores, diseñadores y no desarrolladores en su conjunto en el proceso Scrum?Si son iguales a otros miembros del equipo, surgen un par de problemas.Los diseñadores y evaluadores suelen trabajar en una tarea una vez finalizado el desarrollo, por lo que no pueden planificar adecuadamente un sprint debido a esta dependencia.

En segundo lugar, tenemos plazos.Estos son estrictos y tienen un gran impacto en la priorización.El resultado final son cambios en el trabajo pendiente en medio de un sprint debido a cambios en las fechas límite o malos resultados al final del sprint.También tenemos mucho trabajo no técnico, como la atención al cliente, que debe realizarse mientras tanto y no se puede planificar, ya que varía mucho.Entonces creo que la estructura, la cultura y las prácticas del equipo no son compatibles con Scrum.Para mí, Scrum es una herramienta de gestión de procesos para equipos que trabajan en el desarrollo de un único producto de software.

¿Qué opinan ustedes sobre aplicarlo en escenarios más específicos y complicados?¿Tienes alguna experiencia para compartir?

Answer 1

En general, los evaluadores y documentadores (y otros no desarrolladores) son todos miembros iguales de un equipo scrum.La idea detrás de esto es minimizar el riesgo.

Exigir una definición de terminado, que incluya un producto potencialmente comercializable que esté completamente probado y documentado, obliga al proyecto a concretarse al final de cada sprint.

Si la prueba no comienza hasta DESPUÉS del desarrollo.Una vez hecho esto, lo que sucede es que se descubren muchos errores después de que los desarrolladores terminan con una tarea.Así que ahora hay que corregir esos errores, y eso es muy lento y costoso porque los errores interactúan y porque la regla general es:"El gasto de arreglar un error crece exponencialmente con el tiempo". Los errores que atrapas temprano son baratos y fáciles de solucionar, los errores tardíos son una pesadilla.

Es por eso que desea que las pruebas (y la documentación) avancen al mismo ritmo que el desarrollo.Y ahora mismo deberías preguntarte ¡cómo!Las pruebas son lentas, ¿cómo diablos pueden avanzar al ritmo del desarrollo?

La respuesta es la automatización, es decir, SCRUM siempre se ubica por encima de XP o Agile; ambos exigen una excelente cobertura de pruebas unitarias y TDD.Aquí hay otro problema al que debemos prestar atención.Los desarrolladores de funciones deben ser quienes escriban las pruebas unitarias y del sistema.Toda la automatización de las pruebas debe ser realizada por el desarrollador de funciones.equipo.Algunos lugares dividen el desarrollo de funciones.del desarrollador de automatización.y eso es malo.

Bien, ahora tienes excelentes pruebas automatizadas y las ejecutas AL MENOS una vez al día.Y obviamente practicas la integración continua, ¿verdad?Esto reduce enormemente la carga de trabajo de los evaluadores.Y así es como las pruebas pueden mantenerse al día con el desarrollo.Una cosa más, los evaluadores ahora trabajan en cosas realmente duras y creativas que son imposibles o muy difíciles de automatizar, cada vez que encuentran un error de esa manera, todo lo necesario para exponer el error se automatiza y se convierte en parte de las pruebas de regresión diarias. .¡Uf, esa es una respuesta larga!

Ahora a la segunda parte de tu pregunta.Scrum se trata de disciplina.Los sprints son cortos y los cambios en el trabajo pendiente durante un sprint NO deberían ocurrir.El trabajo no técnico debe derivarse a un equipo de atención al cliente y ellos pueden hacer Scrum en torno a eso.Tienes razón cuando dices que parece que tu cultura y tus prácticas son incompatibles con scrum.

En mi experiencia, la transición a Scrum/Agile es un proceso muy doloroso y estresante y la mayoría de los intentos de transición fracasan.Una de las claves del éxito es un campeón de Scrum/Agile en el equipo ejecutivo.Según tu descripción parece que no tienes uno.

Scrum tiene costos y beneficios, pero si lo está haciendo mal, es posible que esté incurriendo en costos con poco o ningún beneficio.Si estás haciendo Scrum mal y mal, quizás sea mejor que no lo hagas en absoluto.

Answer 2

En primer lugar, ¿cuál debería ser el papel de los evaluadores, diseñadores y no desarrolladores en su conjunto en el proceso de scrum?Si son iguales a otros miembros del equipo, surgen un par de problemas.Los diseñadores y evaluadores suelen trabajar en una tarea una vez finalizado el desarrollo, por lo que no pueden planificar adecuadamente un sprint debido a esta dependencia.

Si los diseñadores y evaluadores no pueden planificar un sprint debido a una dependencia del desarrollo, eso significa que su desarrollo no se está planificando correctamente.Ése es un problema que debe solucionarse.

Su equipo debería poder decir "La tarea B requiere que la tarea A se realice primero".La tarea A tardará 8 horas y la tarea B tardará 4 horas".Si las estimaciones de sus tareas son precisas, entonces las dependencias no son un problema en absoluto.

En segundo lugar, tenemos plazos.Estos son estrictos y tienen un gran impacto en la priorización.El resultado final son cambios en el trabajo pendiente en medio de un sprint debido a cambios en las fechas límite o malos resultados al final del sprint.También tenemos mucho trabajo no técnico, como la atención al cliente, que debe realizarse mientras tanto y no se puede planificar, ya que varía mucho.

Si esto sucede, entonces el problema es que no estás haciendo Scrum.La única forma en que Scrum funciona es si la gerencia acepta completamente el proceso.Esto significa dejar a sus desarrolladores solos durante 30 días mientras trabajan en su sprint planificado y agregar nuevo trabajo a través de los métodos que Scrum tiene implementados para hacerlo.Agrega elementos de la lista de deseos al trabajo pendiente del producto y luego, durante la planificación del sprint, los desarrolladores y las partes interesadas acuerdan en qué se trabajará en el próximo sprint.

Si constantemente tiene problemas de atención al cliente que interrumpen el desarrollo normal, entonces debería considerar seriamente dividir el equipo y tener un grupo dedicado a trabajar en el desarrollo en Scrum y otro grupo que se encargue de los problemas de atención al cliente.Luego, podrías rotar a las personas hacia adelante y hacia atrás al final de cada sprint.

Answer 3

Realmente no debería agregar cambios al trabajo pendiente del Sprint en función de los cambios generados a mitad del Sprint, solo deberían ingresar al trabajo pendiente del Producto e ignorarse hasta que finalice el Sprint.

Deberías alinear tus plazos con los Sprints.Creo que es aceptable retirar una tarea a mitad del Sprint, pero no introducir una nueva.

Si descubre que está agregando muchas tareas a mitad del Sprint, sus Sprints probablemente sean demasiado largos.Recuerde que su objetivo es aproximadamente 20 días de trabajo en cada Sprint, ¡más tiempo comenzará a tener los problemas que está describiendo!

Los evaluadores son importantes para cualquier proceso ágil, pero realmente no encajan en Scrum, donde la teoría es que cualquier persona sin una tarea activa elige la siguiente tarea.Tratar de elegir asociaciones entre tareas y personas comienza a involucrarse en la programación, ¡lo cual todo estaba tratando de evitar!

Los evaluadores, si trabajan muy cerca de los desarrolladores, pueden ayudar a determinar si un elemento de trabajo está realmente completo.

Answer 4

En primer lugar, no estás usando Scrum en absoluto, es posible que estés usando algunas prácticas de scrum, pero no todo el proceso.

Los diseñadores y evaluadores suelen trabajar en una tarea una vez finalizado el desarrollo, por lo que no pueden planificar adecuadamente un sprint debido a esta dependencia.

No existe relación entre la dependencia de la tarea, algo que rara vez ocurre, y la capacidad de planificar adecuadamente.En la planificación del sprint, el equipo debe estimar las historias relacionadas con la Definición de Hecho.Si incluye, y realmente debería, diseñar y probar la historia, la estimación del esfuerzo necesario para cumplir con los criterios de aceptación de la historia debe incluir tareas de diseño y prueba.

El resultado final son cambios en el trabajo pendiente en medio de un sprint debido a cambios en las fechas límite o malos resultados al final del sprint.

Parece que la longitud de tu sprint es más amplia de lo que necesitas.¿Por qué no intentas hacerlo más corto?Una buena duración de sprint es la que puedes comprometerte a mantener los cambios fuera del sprint.Supongo que 1 semana funcionaría.

Y este comportamiento demuestra que su Scrum Master no está haciendo su trabajo correctamente porque no elimina los impedimentos.