Actualmente estamos siguiendo muchas de las Scrumrutinas como stand ups, refinements, planning 1/2, demo, retro...
En los últimos meses, nos dirigíamos hacia abajo mostrando un rendimiento deficiente y entregando un producto/código deficiente al final del sprint. A primera vista, parece que somos demasiado optimistas cuando planificamos y nos comprometemos. Después de eso, durante el sprint nos encontramos con muchos problemas, y debido a la falta de tiempo, que en parte se debe al poco compromiso, terminamos con lo que dije al comienzo de la publicación: características mal implementadas con mucho de bichos Nuestro PM sugirió tratar de incluir algún tipo de gestión de riesgos durante nuestros refinamientos/planificación, lo que suena razonable, ya que es obvio que hay cosas que no tomamos en consideración durante el refinamiento y cuando realmente encontramos un problema, generalmente es durante el sprint cuando ya estamos comprometidos.
Después de investigar un poco sobre la gestión de riesgos en Scrum, terminé con la idea de que tal vez Scrum tiene su propia gestión de riesgos implementada en su propia naturaleza. Los stand ups diarios con las preguntas "¿Qué he hecho ayer?", "¿Qué problemas me encontré?", "Qué voy a hacer hoy" me suenan a una investigación de riesgos bastante buena y la reunión retro al final del sprint. ser mucho más largo que una reunión de pie habitual está dando la oportunidad de analizar con más profundidad las cosas que el equipo cree que son importantes.
Dado que la metodología Scrum en sí misma tiene muchos rituales que se llevan desde el momento del equipo, junto con algunas adiciones específicas para nuestro equipo, como tener intenciones escritas para cada historia, tener un documento de diseño técnico (uno de muy alto nivel pero aún así...) ya tengo un proceso algo pesado y me pregunto si realmente hay algo de verdad en lo que pienso, que retros y stand ups podrían ser un buen reemplazo de la gestión de riesgos estándar y podrían estos u otros rituales/rutinas de Scrum usarse para mejorar nuestro gestión de riesgos en lugar de incluir una metodología completamente nueva en nuestro trabajo?
Parece que Scrumlas prácticas se han adoptado utilizando un cargo cultenfoque. Si constantemente entrega resultados de baja calidad, entonces se está perdiendo algunas prácticas.
Consideraría "¿Qué problemas encontré?" como una pregunta importante. Se necesitan detalles adicionales. ¿Se resolvió? Si es así, ¿cómo se resolvió? Si no es así, ¿qué debe suceder para que se resuelva? ¿Qué impacto tendrá en el sprint?
Desde una perspectiva de gestión de riesgos, examine sus procesos con miras a responder a la pregunta: "Si eliminamos el proceso, ¿cuál es el riesgo de que la calidad del código disminuya?". Antes de adoptar un nuevo proceso, considere la probabilidad de que aumente la calidad del código. Hay datos bien investigados sobre la eficacia de una serie de técnicas.
Al planificar, considere el riesgo de que la estimación sea incorrecta. Para cosas que son muy similares a otras que has hecho con éxito, el riesgo debe ser bajo. Si su equipo no tiene una comprensión clara de cómo implementar la solución, entonces el riesgo normalmente sería alto. Haga lo mismo con la certeza de su comprensión de la historia.
Tómese un tiempo para comprender las técnicas que está utilizando. Una de las mejores decisiones que he tomado fue pasar un par de meses investigando procesos de desarrollo antes de lanzar un proyecto importante. Ese proyecto se entregó antes de lo previsto con una calidad superior a la normal. Considere mis comentarios sobre ¿Quién paga la curva de aprendizaje?
Creo que te estás perdiendo uno de los aspectos clave de Scrum .
Así es como funciona:
En primer lugar, el equipo decide su definición de hecho . Esto es todo lo que espera hacer cuando entrega características terminadas de buena calidad.
A continuación te pones a trabajar. Al final de un sprint de tiempo limitado, mide cuánto trabajo llegó a su definición de terminado (no incluya el trabajo que aún está en progreso). Esta cantidad se convierte en su guía para lo que puede lograr en futuros sprints. Es posible que en algunos sprints futuros hagas un poco más o un poco menos. Muchos equipos calcularán su capacidad (llamada velocidad ) utilizando un promedio móvil de lo que hicieron en los últimos 3-4 sprints.
De esta forma el equipo averigua cuál es su verdadera capacidad de trabajo. No existe tal cosa como 'ser optimista en su planificación'. Solo existe lo que has medido para ser la capacidad de tu equipo.
Si encuentra que su equipo regularmente no completa todo el trabajo planificado en un sprint, entonces la respuesta es muy simple. Ponga menos en futuros sprints.