|
|
|
Con la retrospectiva se pretende inspeccionar el sprint respecto a individuos, interacciones, procesos, herramientas y su Definición de Hecho.
|
|
|
|
|
|
|
|
En este sentido se indentifican los siguientes aspectos:
|
|
|
|
|
|
|
|
### Individuos
|
|
|
|
- Para el siguiente sprint, generar un documento desde la planning con las reuniones diarias, para tratar recopilar puntos de fallo revisables en los días siguientes antes de llegar al final del sprint.
|
|
|
|
- De acuerdo con lo anterior cumplir con todas las reuniones diarias en el sprint 2 y comprobar su efectividad con respecto al sprint 1.
|
|
|
|
|
|
|
|
### Interacciones
|
|
|
|
- Las reuniones diarias se han realizado comprobando la funcionalidad, sin embargo en algunas ocasiones no se han podido realizar, espaciando su celebración entre ellas, detectando aspectos tanto positivos como negativos que resultan de interés. Por un lado, beneficia la perspectiva que se tiene del producto ya que se identifican ciertas consideraciones durante el sprint o para implementar a futuro, y por otro lado, se pierde el contacto con el producto ya que a diario se orienta de forma más precisa y con margen de corrección la aceptación del desarrollo de acuerdo al objetivo del sprint.
|
|
|
|
|
|
|
|
|
|
|
|
### Procesos
|
|
|
|
- Los criterios de aceptación podrían refinarse con la experiencia del sprint, para poder ser más objetivos. Como la variedad de las pruebas y número de ellas que se han realizado.
|
|
|
|
- No perder el foco en la funcionalidad definida gastando tiempo en funcionalidades secundarias antes de haber finalizado todos los issues. Si bien estas implementaciones resultan de utilidad, puede repercutir negativamente en el alcance del objetivo para futuros sprints.
|
|
|
|
|
|
|
|
- A la hora de cerrar issues, verificar tanto historias de usuario como objetivos y notificar su cierre para poder definir algún issue adicional que complete el pbi antes de cerrarlo.
|
|
|
|
|
|
|
|
|
|
|
|
|
