Durante el tiempo del contrato, se nos dan los detalles de los requisitos y no tenemos historias.
Si tenemos que optar por un contrato de oferta fija, ¿creamos historias en el momento?
Lo dudo, ya que nadie tiene tiempo en la etapa de contrato para crear historias y decidir sobre los puntos de la historia.
Entonces, ¿cómo te acercas a esto?
¿Creas epopeyas y les das un punto de historia y planificas en base a eso? Pero creo que las epopeyas no se pueden dividir en historias de tamaño equivalente. StackLink
o
¿Simplemente estima el esfuerzo de desarrollo en forma de cascada? ¿Y crear un costo a su alrededor y firmar un contrato? En el plan que menciona, se proporcionará un plan Agile después de que se creen las historias y se conozca la velocidad. ¿Pero no creo que esto realmente pueda funcionar siempre?
o
¿Hay alguna otra manera?
Realice el dimensionamiento relativo de las características.
Cuando está mirando un contrato de oferta fija, está diciendo: "No me tomará más que esta cantidad de dinero entregar el alcance completo". Esto es problemático en Agile porque reconocemos que la mayoría de los proyectos de software no comprenden su alcance hasta muy tarde en el proyecto. Este no es el resultado de Agile: la mayoría de los proyectos en cascada tampoco entienden su alcance; la diferencia es que Agile no pretende hacerlo.
Tamaños de características
Cuando miramos el tamaño total de un proyecto, todavía queremos usar el tamaño relativo. Es posible que tenga una característica de referencia de proyectos anteriores (siempre tiene que comenzar con algo que realmente haya hecho) y eso puede ser un medio. Luego puede ver las características de los nuevos proyectos y preguntar "¿Es aproximadamente del mismo tamaño, un poco más grande, mucho más pequeño?" Su grupo de desarrollo tendrá una velocidad en este nivel tal como lo hace en el nivel de sprint.
Si su equipo tiene una velocidad de sprint promedio de alrededor de 30 puntos de historia y usted tiene 3 historias de 8 puntos y 4 historias de 5 puntos, probablemente las completarán en 2 sprints. Los tamaños de características funcionan de la misma manera. Las características medianas (si está haciendo el tamaño relativo correctamente) costarán lo mismo con un cierto margen de error.
¿Por qué no simplemente agregar puntos de historia?
Si detallas todas las historias y las estimas todas, asumes que el alcance es fijo y lo entiendes completamente. Tan pronto como asume eso, está asumiendo un riesgo increíble para usted y su cliente y derrotando muchos de los principios básicos de Agile.
Al observar el tamaño de la característica y aplicar allí una estimación relativa, deja mucho espacio para la incertidumbre y las modificaciones en los detalles. ¿Cómo puedes empezar? Mira tu trabajo anterior. Además de utilizar una función anterior como referencia, también puede realizar una estimación relativa de forma retroactiva para obtener una base de datos con la que trabajar. Sin embargo, aquí hay un gran escollo: sabes cuánto tiempo tomó; naturalmente querrás usar la realidad para influir en tus estimaciones. Puede tratar de evitar esto conscientemente o tal vez hacer que personas que no trabajaron en la función hagan la estimación relativa.
Ten cuidado
Al igual que la forma en que jugar con la composición del equipo reduce la velocidad de los puntos de la historia y los puntos de la historia no son comparables entre grupos, si cambia constantemente la estructura de su grupo de desarrollo o divide a las personas en proyectos, este enfoque se desmoronará y no podrá ver las tendencias en el costo de las funciones.
Usted dijo:
...nadie tiene tiempo en la etapa de contrato para crear historias y decidir sobre los puntos de la historia?
Cuando llamo a un proveedor para un proyecto de mejoras para el hogar, su enfoque es así. Un representante visitará mi casa para revisar estas cosas:
El vendedor me cobrará por preparar esta estimación. Aunque normalmente se ofrecerán a descontar este cargo de estimación del precio final del contrato, si realizo el pedido con ellos. Algunos contratistas dan estimaciones gratuitas, pero a menudo encuentro que los contratistas confiables y experimentados no dan estimaciones gratuitas. Los recién llegados que están tratando de hacer una entrada en el mercado son los que ofrecen presupuestos gratuitos.
Tu preguntaste:
¿Hay alguna otra manera?
Sí. Cobrar por el presupuesto y hacer un trabajo adecuado. Esa es la práctica en industrias maduras que funcionan con éxito durante mucho tiempo.
Además de las historias de usuario, cree un documento de requisitos:
Habría sido desafiante y arriesgado para nosotros estimar el trabajo basado únicamente en estas historias de usuarios y luego comprometernos con un contrato de precio fijo. Necesitábamos más información, que podíamos obtener a través de conversaciones con nuestro cliente. Pero también necesitábamos documentar algunas suposiciones y decisiones clave que resultarían de esas conversaciones. Lo que hicimos fue identificar una pequeña cantidad de criterios de aceptación de alto nivel para cada historia de usuario. Hoy me refiero a éstas como condiciones de satisfacción de la historia. Luego producimos documentos de requisitos que incluían cada historia de usuario junto con sus condiciones de satisfacción.
Además, use una redacción específica sobre cómo se realizará el trabajo de posproducción en la sección Supuestos de la RFP:
Suponemos que cualquier solicitud de mejora/cambio comunicada después de la aprobación de la cartera de pedidos del producto/lanzamiento que es el punto central de este acuerdo se tratará como una solicitud de cambio de proyecto (PCR). La gestión de un PCR se describirá en el plan de gestión de cambios. Una solicitud de cambio debe requerir la eliminación del alcance (es decir, una historia similar o de igual tamaño) de la sección "me gustaría tener" un alcance del 40 % de este contrato de artículos de igual valor, o se convierte en una nueva fijación de precios. consideración. Si se agrega un nuevo alcance, aumentará el alcance establecido en la sección de alcance de este acuerdo. De cualquier manera, los cambios en el alcance se manejarán como una solicitud de cambio de proyecto.
Esto suena como un proyecto ágil:
Tenemos una cartera de productos con prioridades, pero comenzamos a trabajar en un lanzamiento con una larga lista de características ya comprometidas con el negocio.
Conocemos las fechas de lanzamiento de nuestros productos con varios meses de antelación. Hay una larga lista de fechas objetivo que deben cumplirse antes de la fecha de lanzamiento.
Hacemos demostraciones de nuestro software en desarrollo para los clientes, pero solo después de que estamos satisfechos con él. Para cuando llegue el momento de tener una demostración, podría ser demasiado tarde para cambiar mucho.
Referencias
Daniel
danny schoemann