Actualmente estamos trabajando en un proyecto en el que recibimos muchas solicitudes de cambio, ¡y el cliente insiste en que debemos entregar los cambios en el sprint actual!
¿Puedo agregar el nuevo trabajo al backlog del sprint como una nueva tarea? A veces el esfuerzo de las tareas cambia, como antes era un trabajo de 18 horas pero ahora es un trabajo de 32 horas.
¿Cómo puedo acomodar estos cambios sin hacer un gráfico de trabajo pendiente extraño? ¿Está bien agregar tareas a un sprint en curso?
¿Puedo agregar eso a la acumulación de sprint como una nueva tarea?
Sí, puede agregar historias a un sprint en ejecución, si el equipo está de acuerdo. Sin embargo, no es una buena práctica, ya que reduce la utilidad y la capacidad predictiva de la metodología.
Algunas veces el esfuerzo de la tarea cambia como antes era un trabajo de 18 horas ahora es un trabajo de 32 horas
Esto es relativamente poco importante: es por eso que las historias no se miden en horas, sino en puntos: las estimaciones de tiempo pueden variar durante el sprint. Dicho esto, solo necesita realizar un seguimiento del tiempo restante , no del tiempo transcurrido .
Si cree que las historias se consideraron simples y se vuelven más complejas a medida que se desarrolla el sprint, es posible que haya algunos problemas subyacentes:
¿Tuvo suficiente información durante la reunión de planificación para estimar la historia correctamente? En otras palabras, ¿el alcance se mantuvo constante pero la complejidad de la tarea resultó ser mayor de lo previsto?
¿Estimaste correctamente la historia original, pero el cliente cambió de opinión durante el sprint? Si lo hicieron porque cambiaron de opinión legítimamente, entonces debes abandonar la historia y comenzar una nueva. Si, en cambio, están agregando alcance, entonces debe agregar nuevas historias a la cartera de pedidos para eso.
¿Cómo puedo acomodar estos cambios sin hacer un gráfico de quemado extraño? ¿Está bien agregar tareas al sprint en curso?
Sí, los gráficos de quemado pueden subir a veces en lugar de bajar. ¡Sin embargo, probablemente no sea algo que quieras!
En general, estas son las reglas básicas que debe observar:
Solo el equipo puede aceptar nuevas historias en un sprint. No se les puede obligar. Hacerlo es simplemente contrario a los principios ágiles básicos.
El nuevo alcance siempre debe ser una nueva historia.
Se puede agregar una nueva historia a un sprint si elimina una historia del tamaño correspondiente (el equipo debe estimar la nueva historia y el equipo debe aceptar este cambio como factible).
Se puede abandonar un sprint significativamente modificado. Puede detener el sprint y comenzar uno nuevo desde cero, con una nueva reunión de planificación. Obviamente, trata de evitar esto si puedes.
A medida que surge nueva información, el equipo puede descubrir que llevará más tiempo (¡o menos!) desarrollar una historia. Esto se espera. Los puntos de la historia no cambian, las horas restantes cambian.
A medida que surge nueva información, el propietario del producto puede descubrir que necesita más historias (¡o menos!) de lo que pensó originalmente. Esto se espera. Agregue o elimine historias del backlog con impunidad. Agregue o elimine historias del sprint solo si el equipo acepta el cambio y se compromete con él.
Actualmente estamos trabajando en un proyecto en el que recibimos muchas solicitudes de cambio, ¡y el cliente insiste en que debemos entregar los cambios en el sprint actual!
Esta es una señal de que estás haciendo Scrum Wrong™. Si bien hay casos extremos en los que se pueden agregar o eliminar historias del Sprint, o cuando el Sprint Backlog gana o pierde tareas necesarias para completar el Sprint Goal actual, ese no es realmente el problema aquí. En cambio, el problema parece ser que el cliente no está trabajando a través del propietario del producto para revisar el progreso y ajustar el alcance en los puntos de inflexión definidos por el marco:
No se debe permitir que las partes interesadas cambien el alcance dentro del sprint actual sin la cooperación activa del propietario del producto y una terminación anticipada explícita del sprint actual. La violación de este principio creará un trabajo invisible y una sobrecarga sin seguimiento para el proyecto, lo cual es un gran no-no.
Eso no quiere decir que el equipo de desarrollo no pueda trabajar con las partes interesadas o un usuario final definido en una historia de usuario para aclarar una historia en un sprint u obtener información sobre la implementación óptima de una característica, pero tales interacciones no deberían cambiar el alcance o comprometer el Sprint Goal definido durante la Planificación del Sprint.
El propietario del producto y el Scrum Master deben trabajar junto con las partes interesadas para hacer cumplir la integridad del sprint y educarlos sobre cuándo (y cómo) realizar cambios en el alcance del proyecto dentro del marco de Scrum.
El ideal
Todos los requisitos son completamente predecibles. Al hacer suficiente análisis por adelantado, se descubrirá trabajo adicional antes de que comience el sprint. Por lo tanto, será posible una estimación precisa y esta pregunta nunca se planteará.
La realidad
Partes de su proyecto serán cosas nuevas que nunca ha hecho antes (de lo contrario, sería exactamente el mismo proyecto que hizo antes, y eso nunca sucede). Los descubrimientos son inevitables, tanto en el análisis como en el desarrollo. No puede estimar cosas que nunca ha hecho antes, y tratar de hacerlo por lo general dará como resultado un tambaleo y/o un relleno de estimación.
Qué hacer al respecto
Reconocer que siempre hay incertidumbre en el desarrollo y ser adultos al respecto. El final del sprint está ahí para que usted se concentre en obtener retroalimentación de sus partes interesadas, y esa retroalimentación es mucho más importante que cualquier estimación del punto de la historia.
Las discusiones sobre estos descubrimientos a menudo dan como resultado que las personas pasen más tiempo tratando de analizar los elementos más nuevos y riesgosos de un proyecto antes de tiempo. El análisis no es tan bueno para eliminar esos descubrimientos como lo es entregar algo (o las metodologías de Waterfall funcionarían), por lo que cuando se hacen esos descubrimientos, es muy importante concentrarse en la entrega y la retroalimentación.
De lo contrario, se produce la parálisis del análisis y esos elementos terminan siendo empujados al final del proyecto, cuando no hay tiempo para reaccionar ante ellos.
El propósito de la estimación y la medición de la velocidad es triple:
Pure Scrum no exige puntos de historia y mediciones de velocidad. En lugar de hacer promesas sobre puntos, considere hacer promesas sobre aspectos de las necesidades de las partes interesadas sobre las cuales entregará o exhibirá algo con fines de aprendizaje y retroalimentación. Al abordar los aspectos más riesgosos de un proyecto desde el principio, aprenderá rápido, reducirá el riesgo del proyecto (y ayudará a hacer planes más precisos) y ganará la confianza de las partes interesadas al abordar las cosas que les impiden dormir por la noche.
Bajo ninguna circunstancia se deben usar los puntos de la historia para "castigar" al equipo. Eso solo creará una brecha entre el PO y otros miembros del equipo, y el PO debe ser parte de ese mismo equipo.
Si está buscando un mecanismo de seguimiento y los cambios de alcance ocurren regularmente, considere un gráfico de quemado o CFD en su lugar. Eso le permitirá realizar un seguimiento de su trabajo contra el alcance a largo plazo, y también podrá ver cómo está cambiando el alcance en sí.
Hay bastantes opciones para manejar el trabajo no planificado durante un sprint. Como practicante ágil, tiene varios enfoques. Idealmente, el equipo de desarrollo determina qué se puede y qué no se puede hacer durante un sprint. Pero si se requiere insertar un problema planteado por el PO en el sprint, entonces puede:
1/ Absorberlo.
2/ Divida las historias afectadas y transfiéralas a los siguientes sprints
3/ Reemplace el elemento para que coincida con la velocidad.
4/ Cree un elemento de "búfer de problemas ad-hoc". Permite órdenes de compra no autorizadas o problemas complejos que no se pueden solucionar por completo hasta que se ha iniciado el trabajo.
5/ Mejorar la priorización (es decir, decir "No").
6/ Identifique y elimine las dependencias (es decir, elimine los bloqueadores del sprint hasta que se resuelva la causa de origen)
7/ Adaptar proceso a Kanban.
(fuente: https://medium.com/agilelab/strategies-for-handling-unplanned-work-durante-sprint-2f89697509ff )
Definitivamente creo que debe abordar el tema de las "solicitudes de cambio del cliente", quizás a nivel contractual. El cambio es el enemigo mortal del desarrollo de software, especialmente cuando esos cambios llegan mientras se escribe la pieza afectada. Se debe hacer entender al cliente que un enfoque tan indisciplinado terminará costándole dinero y amenazando la estabilidad del producto en el que pretende confiar.
En mis primeros días de consultoría, leí un libro sobre contratos de consultoría del difunto Herman Holtz (de soltera "Hermann Holz"), en el que describía un contrato general y órdenes de trabajo. El trabajo debía llevarse a cabo creando órdenes de trabajo, obteniendo la aprobación del cliente para cada una, asignándole un costo y luego ejecutando la orden. Usé este sistema durante más de treinta años con gran éxito.
(El caballero escribió varios libros excelentes. Los recomiendo).
La "ganancia" clave es que formaliza el proceso de solicitud de cambio a los ojos del cliente y lo vincula a "gastar dinero". El proceso de definir ese orden, hasta el punto en que el cliente tiene que ponerle su John Hancock, es en sí mismo extremadamente valioso. También reduce en gran medida la posibilidad de malentendidos. Siempre lo dejé en claro con cortesía: "Su firma es una autorización vinculante para realizar el trabajo como se describe. Si cambia de opinión, esa es otra orden de trabajo".
Obtuve la mayor parte de mi trabajo a través de referencias, y varios clientes potenciales dijeron que se sintieron atraídos por mi consultoría porque usamos un sistema de orden de tareas. Sé que fue clave para nuestra rentabilidad a largo plazo.
Los contratistas de la construcción y otros fabricantes de cosas tangibles utilizan estas prácticas de forma rutinaria. Se aplican igualmente bien a la construcción de cosas intangibles como software de computadora, que son mucho más complicadas.
Paweł Polaczyk
harish