Tengo la intención de introducir sprints en mi empresa, yo mismo soy bastante nuevo. No estoy seguro de si es apropiado para mi situación actual, tenemos varios proyectos en curso, todos ellos son del tamaño de una escala ERP y diría que la mayoría de ellos están a punto de completarse (listos para entregar).
Sin embargo, durante este tiempo, hay algunos clientes a los que no tenemos más remedio que establecerlos como prioridades, ya que los errores aún están presentes, por lo tanto, si descubren problemas con el sistema, se comunicarán con nosotros y tendremos al equipo para solucionarlo lo antes posible. . Por ahora, esta es la práctica actual. En tal caso, si se introduce Agile y comenzamos a usar Sprint, ¿qué se puede hacer para clientes adicionales, urgentes o agresivos que requieren atención casi inmediata?
El problema es que a la empresa le falta mano de obra, solo 3 desarrolladores en total y no hay evaluadores dedicados, por lo tanto, hasta la fecha, siempre habrá errores y los clientes seguirán regresando. Entiendo que una vez que comienza un sprint, no debería haber cambios en él.
¿Algún consejo?
Hay diferentes formas de abordar esto:
Política de cero errores Si planifica su sprint solo con nuevas funciones, pero mantiene una política de cero errores, su velocidad disminuirá. Con el tiempo, sabrá cuántas historias puede hacer el equipo mientras corrige primero los errores abiertos y nuevos. Comprenda el clima de ayer y planifique en consecuencia.
PBI de marcador de posición Cada sprint agrega una historia que cuenta como un marcador de posición para cualquier error que entre. Reservas una parte fija del sprint para el trabajo de mantenimiento. Si toma mucho más tiempo, interrumpa el sprint y comience uno nuevo.
Asignar un Batman : lea esta respuesta a otra pregunta para obtener más detalles :)
Sprints más cortos Si tiene sprints de una semana y siempre pone defectos en la cartera de pedidos, entonces lo más que debe esperar un cliente es dos semanas para una solución.
Kanban Use kanban en lugar de sprints y concéntrese en comenzar el trabajo, comience a trabajar en defectos de alta prioridad al seleccionar un nuevo trabajo. Use INVEST para mantener sus tareas pequeñas, de modo que pueda seguir terminando el trabajo en pequeños pasos. Publique todo el trabajo realizado en una fecha determinada o publíquelo cuando llegue a un punto determinado en su cartera de pedidos.
Para los equipos de mantenimiento, preferiría Kanban; de lo contrario, use la variante sin errores para obtener una visión realista de la cantidad de trabajo nuevo que puede realizar un equipo.
Tenga en cuenta que desea que los desarrolladores se concentren en su tarea actual. Encuentre una manera de evitar molestarlos durante el trabajo real con defectos entrantes. Un stand-up diario sería un buen momento para discutir el nuevo trabajo entrante y reorganizar un sprint si es necesario.
Esto se puede gestionar activamente a través de Kanban emprendedor y un método de equipo de entrega normal de Scrum. Algunos entrenadores ágiles luchan con el concepto de que una organización puede tener un solo equipo Scrum que genere el cambio comercial a partir de una cartera de programas con múltiples proyectos, todos con su propio ' backlog '. A veces, los métodos ágiles deben adaptarse independientemente de las pautas. Sugiero humildemente la siguiente solución.
Me parece que está trabajando en un centro/función de inteligencia comercial, ¿me equivoco?
Divide tu sprint en dos componentes separados.
Decide cuánto de tu sprint estás dispuesto a sacrificar al trabajo BAU. Para ayudar a enfocar su entrega, sugiero usar el mantra
"Hay que obligar a la gente a tomar decisiones".
Simplemente no puede ofrecer un nuevo cambio si las partes interesadas del negocio desean continuamente reparar la funcionalidad en el sistema anterior. Obligar a la gente a hacer cambios.
Para este ejemplo, sugeriré dedicar el 20% de su capacidad de sprint quincenal como trabajo BAU.
Calcula tu capacidad de trabajo por sprint en horas.
Para este ejemplo, utilizaremos codificación de recursos de tiempo completo 3 x durante 7 horas por día durante 8 días por sprint. Se dedica un día completo a la planificación y un día completo a revisiones y retrospectivas.
Eso te da una capacidad aproximada para 21 horas de trabajo * 8 días = 168 horas de capacidad de trabajo.
Cree una pila de tarjetas de usuario en un color diferente para el Tablero Kanban. Estas son sus tarjetas BAU. Asigne a cada una de estas tarjetas un valor de horas aproximadas que sume 34 y colóquelas en el tablero en blanco. Por ejemplo: 1,1,1,1,1,2,2,2,2,3,3,5,10
Utilice las tarjetas para asegurarse de ceñirse a su presupuesto BAU. Cualquier tarea que entre en el equipo recibe una estimación de planificación de alto nivel en horas y luego se utilizan las tarjetas correspondientes para realizar un seguimiento de la tarea.
Si te quedas sin tarjetas para ese sprint, sabes que has agotado tu capacidad BAU.
Informar sobre los flujos de trabajo de BAU como un informe de entrega separado que rastrea la cantidad de horas planificadas y realizadas para las tareas de BAU, incluida la naturaleza de las tareas y el rendimiento de la inversión del trabajo completado.
Con la implementación de Scrum, tendrá un conjunto de Historias con tareas asociadas para completar dentro de un marco de tiempo fijo de aprox. 2-3 semanas. Ahora, si surge algo nuevo en lo que el equipo debe trabajar, debe priorizarse para el próximo Sprint (suponiendo que pueda esperar hasta este momento). De lo contrario, alguien tiene que hacer una llamada prioritaria y si el equipo debe trabajar en la nueva pieza dentro de las historias actuales. Una parte interesada (PM) podría mover una historia de prioridad del arrendador para el próximo Sprint, si eso es posible. De lo contrario, todas las historias deben completarse dentro del plazo acordado.
Alternativamente, puede configurar un proceso de Soporte entre Desarrollo y los Clientes (si no son miles) y asignarle parte del tiempo del equipo y trabajar en estas tareas en paralelo con las Historias de Sprint planificadas asignadas.
Las cosas pueden cambiar dentro de un Sprint si hay una buena razón para que cambien. Agile tiene que ver con la entrega de valor. Si evita un cambio significativo dentro de un Sprint por seguir estrictamente las pautas de Scrum, ya no está siendo ágil en su implementación de Scrum y está reduciendo el valor que un cliente obtiene de sus servicios debido a que sigue ciegamente un proceso.
La pauta de scrum para evitar cambios en el compromiso de historia/prioridad/defecto dentro del sprint está ahí para proteger al equipo de la mayoría de los cambios que son cambios innecesarios introducidos por reacciones instintivas, el síndrome de la persona más ruidosa en la sala y malas prácticas de planificación de iteraciones. .
Si surge un defecto de alta prioridad (P0 o P1) dentro de una iteración, es completamente aceptable diferir el trabajo de la historia si la corrección es más valiosa para el cliente que el trabajo diferido. Siempre debe comunicar el impacto de aplazar el trabajo comprometido para abordar una nueva prioridad. Tiene el PO en el equipo Scrum durante todo el ciclo de iteración para ayudar al equipo a adaptarse continuamente a las prioridades cambiantes, así como a comunicarse con las partes interesadas externas cuando se produzcan cambios. Muchos equipos establecen SLA en torno a sus defectos para dictar automáticamente el marco de tiempo en el que se debe resolver un determinado tipo de defecto, independientemente de en qué parte de la iteración se encuentre el equipo.
pablodonny
alex leonov
aventura2099