Me he encontrado con un problema constante. Cuando se inicia un proyecto, el cliente normalmente tiene una lista de funcionalidades para integrar en la aplicación. Como equipo, nos gustaría seguir Scrum. Pero lo siguiente que pide el cliente es una fecha de lanzamiento.
El cliente tiene sus propios plazos para acudir al mercado. Por lo tanto, es válido que necesita saber una fecha para poder informar al resto del negocio cuando llegue la solicitud.
Dado que el equipo no puede planificar más de un sprint a la vez, normalmente no hay visibilidad en la fecha de finalización. El cliente dice: "Ya le dije exactamente qué funcionalidad necesito. Dígame cuándo puede crear esta aplicación".
¿Cómo lidias con una situación como esta en Agile o Scrum?
La planificación ágil de lanzamientos se basa en ciclos de capacidad normada y de longitud fija que operan en funciones planificadas dinámicamente y con alcance dinámico. En Scrum, la planificación del lanzamiento con fecha fija debe manejarse controlando el alcance para cumplir con los plazos, ya que no puede tener fechas límite de fecha fija y de alcance fijo simultáneamente. Esto rara vez es un problema práctico, pero puede ser político en talleres no ágiles.
La planificación ágil de lanzamientos se basa en iteraciones. Para hacer una planificación de lanzamientos basada en el calendario o en el tiempo en Scrum:
estimated velocity * fudge factor.El número de iteraciones para una versión se calcula utilizando las siguientes variables y fórmulas:
e / v = iEl valor i se puede volver a convertir en un calendario o una estimación de tiempo multiplicando las interacciones por la duración de los Sprints en semanas o meses, p i * 2.
Supongamos que tiene una cartera de pedidos total de 200 puntos de historia y planea usar una duración de Sprint de dos semanas. La velocidad histórica de su equipo es 20, pero este es un proyecto completamente nuevo con un gran cono de incertidumbre, por lo que su factor de riesgo es el multiplicador estándar de 0,6; como resultado, su velocidad de planificación es de 12 puntos de historia por Sprint después de aplicar el factor de fudge.
Por lo tanto, su plan de lanzamiento para todos los elementos de la cartera de productos sería:
200 / 12 = 17 Sprints
Luego convierte esto en un calendario o tiempo estimado con:
17 * 2 = 34 weeks
Con base en esta información, el cronograma de su proyecto indicará que tomará aproximadamente 34 semanas enviar todas las funciones que se encuentran actualmente en el Product Backlog. Esta es una estimación basada en la información actualmente disponible, y debe tratarse como un valor de planificación en lugar de una garantía irrefutable.
A medida que avanza el proyecto, el cono de incertidumbre se estrecha y el equipo puede hacer estimaciones más precisas sobre la cantidad de trabajo restante en la cartera de productos. Además, un equipo Scrum que funcione correctamente será más preciso al medir su velocidad a medida que avanza el proyecto, por lo que los cálculos del cronograma de lanzamiento deben rehacerse de vez en cuando para "ajustar" el cronograma en función de datos más precisos a medida que se vuelve. disponible.
Además, el propietario del producto puede agregar o eliminar el alcance (en forma de elementos de la cartera de productos) a lo largo del proyecto. Esto ampliará o reducirá el alcance del proyecto y, obviamente, tendrá un impacto en el cronograma estimado. Cambiar el alcance del proyecto generalmente debería desencadenar un nuevo cálculo de la fecha de lanzamiento cuando eso suceda.
Finalmente, Scrum se esfuerza por proporcionar un producto potencialmente entregable al final de todos y cada uno de los Sprint. Si bien es posible que no tenga todas las funciones en el sentido de que contiene el 100 % de todos los elementos pendientes, el producto debe estar en un estado estable y liberable durante la Revisión del Sprint para que la organización pueda optar por enviarlo antes si hay valor suficiente en el producto. para justificar el envío en su estado actual. Este "recuperar" el valor ganado para enviar un producto viable mínimo que se considere "suficientemente bueno" puede brindarle a la empresa (no solo al equipo de Scrum) una ventaja ágil significativa.
La única herramienta que tiene en Scrum para ayudar en esta situación es su velocidad. Creo que conoce su velocidad, cuántos puntos de historia hace en un sprint, verifica la acumulación de productos y planifica cada historia de usuario. Con estos dos, tendrá una estimación de una posible fecha de entrega.
delivery in weeks = ((number of point in backlog) * (number of weeks of a sprint))
/ velocity
Esto es muy inexacto, pero según lo que tiene, eso es todo lo que puede hacer.
Si tiene un propietario del producto (PO), debe negociar las entregas con el cliente en función de su progreso y las historias de usuario entregadas. El PO debe averiguar qué historias de usuario son imprescindibles para que su cliente inicie su negocio. Es un subconjunto de toda la cartera de productos y, por lo tanto, la fórmula anterior debería proporcionar una mejor estimación, porque la incertidumbre es menor que para toda la cartera de pedidos.
Alternativa, puede verificar sus datos históricos y ver cuánto tiempo tomó entregar una aplicación similar, verificar los riesgos que ve y proporcionar una estimación usando esto.
time to deliver the previous app +
sum(additional length of each risk when they happen)
Alternativa dos, puede probar la forma en que Kanban maneja estas situaciones: http://zsoltfabok.com/blog/2013/02/when-will-it-be-done/
En caso de que no conozca la velocidad y no tenga datos históricos, puede intentar hablar con su cliente y averiguar cuáles son las características más importantes. Siéntese con su equipo y calcule el proyecto a la antigua usanza.
Mientras tanto, puede intentar mostrar los beneficios de la entrega continua a su cliente . Las conversaciones frecuentes y la entrega continua son la clave de Agile , recomiendo comenzar con ellos + la estimación inicial. Si su cliente los entiende y los beneficios (las entregas frecuentes son muy útiles cuando uno programa proyectos upstream), será beneficioso para todos.
Zsolt tiene buenos titulares, le doy mi voto.
Scrum funciona muy bien para fechas de lanzamiento fijas, siempre que reconozca una realidad simple. Que estando con Scrum puedes tener una de dos verdades.
1- O haces todo el trabajo del backlog. Simplemente no sabes cuándo.
2- Liberas en una fecha específica con el trabajo que has logrado completar para esa fecha.
Si su cliente (o jefe interno) le da una fecha fija, entonces tiene que enviar, luego usa técnicas como las que habla Zsolt y estima cuánto trabajo puede hacer. Al comienzo del desarrollo, mi pauta general es que no te comprometas con más del 50 % de lo que crees que puedes hacer. Esto se debe a que la ley de Hofstadter establece que siempre se subestimará el trabajo a realizar, incluso cuando se tenga en cuenta la ley.
Luego, la alegría de Scrum es que a medida que avanza en el proyecto, podrá usar su velocidad para refinar su predicción de lo que entregará. Para cuando haya completado 2/3 del desarrollo, tendrá una idea sólida de lo que se enviará.
Esto significa que debe asegurarse de que el trabajo pendiente esté bien ordenado. Entregue las cosas más importantes primero y luego las cosas menores. Entonces, si no envía todo, no se está perdiendo las cosas de MVP.
Si su cliente dice "Pero todo debe enviarse", tiene un problema diferente. Scrum no solucionará eso, debe agilizar la cadena de valor. Recomiendo Innovation Games Pode el árbol de productos y compre una característica si se enfrenta a esto.
Nota: Una cosa que noté en su publicación es que mencionó "Dado que el equipo no puede planificar más de un sprint a la vez". Esta es una bandera para mí. Los equipos deben trabajar fuera del sprint normal con el propietario del producto para preparar el trabajo pendiente y planificar el trabajo futuro. Para cuando llegue a un sprint, ya debería tener una buena idea de lo que hará en el sprint. Tengo un equipo que acaba de trabajar con su Product Owner y tiene un plan de trabajo (cambiará) para los próximos ocho sprints (4 meses). Un tema aparte de este, solo algo que quería traer a su pensamiento.
La idea de Scrum es que un equipo se concentre en entregar lo que un cliente quiere. Para hacer esto, hacemos un trabajo, lo demostramos, escuchamos los comentarios y luego nos adaptamos. Este enfoque reconoce que es difícil para un cliente obtener sus requisitos desde el principio. Es mucho más fácil construir un producto exitoso cuando tienes retroalimentación y adaptación constantes.
Si un cliente desea fijar el alcance y la fecha de finalización del proyecto, no obtendrá todos los beneficios del enfoque Scrum.
Sugeriría hablar con sus clientes y venderles la idea de que el enfoque de Scrum les da la oportunidad de dar forma al producto como ellos quieren. Habrá cierta incertidumbre sobre la fecha de finalización, pero esto se compensa con el valor de obtener el producto correcto.
Por supuesto, habrá algunas situaciones en las que el cliente tiene una fecha límite difícil. En esas situaciones, trabajamos para reducir la acumulación priorizada de requisitos en la medida de lo posible en el tiempo permitido. Si el cliente introduce nuevos requisitos a medida que avanza el proyecto, puede reducir el nivel de la lista. En efecto, lo que se entrega y cuándo se entrega dependerá tanto del cliente como del equipo de entrega.
Existen dos métodos para pronosticar las fechas de entrega de su cartera de pedidos:
Es muy similar a lo que Todd describe en su respuesta, pero más preciso, porque:
Por lo tanto, vaya al enlace a continuación, mire el video y descargue el archivo de Excel que hace los cálculos por usted; todo lo que necesita es simplemente poner los elementos de su trabajo pendiente, sus estimaciones y en qué sprint se completaron o agregaron.
Es una técnica, cuando ni siquiera necesita estimaciones para los elementos en su trabajo pendiente: simplemente coloca "1" como estimaciones en su archivo Reliable Scrum para todas las Historias de usuario en él, y luego obtiene un pronóstico preciso de cuándo se ejecutará su trabajo pendiente. ser completado.
Parece magia, pero en realidad funciona muy bien, porque, de hecho, tiene en cuenta el tiempo necesario para completar los elementos de trabajo. Es decir, no se ve afectado por el ruido de las estimaciones expertas no precisas de los elementos de su cartera de pedidos.
Cuando comparé ambos métodos en 5 proyectos, se demostró que ambos métodos funcionan muy bien y el último produce resultados aún más precisos que el primero.
Para obtener más información, consulte el video de Troy Magennis . No es necesario que comprenda la teoría subyacente, solo sepa que usar Reliable Scrum con "1" como estimaciones para los elementos de su cartera de pedidos funciona muy bien.
Creo que es este tipo de situación histórica lo que llevó al valor Agile
colaboración del cliente sobre la negociación del contrato
También tome nota de
Responde al cambio sobre el siguiente plan
El PO tiene un problema de compromiso con el cliente que debe resolver antes de que el trabajo pueda comenzar para evitar un lío costoso.
El padre de Scrum , Jeff Sutherland , ideó un patrón de Scrum, 'Cambio gratis y dinero por nada' . Si bien es poco probable que su organización o sus clientes estén listos para suscribirse a dichos contratos Agile, vale la pena revisarlos para comprender cómo la OP debe comprometerse con el valor de optimización del cliente y el ROI.
Usar reglas de Moscú protegidas
Saludos,
yves lehmann