¿Cómo aprovechar los beneficios del desarrollo ágil en un proyecto de costo fijo?

Scrum es un marco ágil que se enfoca en adaptarse al cambio y brindar valor comercial. Fomenta la retroalimentación y busca entregar lo que se necesita, que a menudo no es lo mismo que se planeó originalmente.

Combinar Scrum con un precio fijo, contrato de alcance fijo es un desafío. A menudo, puede dar lugar a discusiones entre el cliente y el proveedor sobre qué es un cambio válido y qué debe pagarse como funcionalidad 'nueva'.

Esto es particularmente difícil para usted, ya que parece que no está en un rol genuino de propietario del producto, ya que no puede tomar decisiones sobre el alcance.

Mi recomendación sería utilizar un enfoque muy transparente para su trabajo. Asegúrese de que todas las decisiones sobre la funcionalidad se describan claramente y que también se aclaren las implicaciones del cambio.

Valdría la pena hacer una planificación de lanzamiento frecuente. Aquí es donde observa la velocidad del equipo y ve cuánto tiempo les llevará completar el trabajo que queda por hacer. Puede encontrar que si el cliente realiza cambios y si el equipo encuentra problemas técnicos, la fecha límite del proyecto (y el costo del proyecto) también cambia. El mejor enfoque es hacer que estos cambios y su impacto sean lo más públicos posible, de modo que sean discutidos tanto por su cliente como por el equipo de gestión de su organización.

Algunas partes de Scrum pueden ayudarlo a hacer que las cosas sean transparentes. Asegúrese de que el trabajo pendiente sea público y que el progreso se muestre claramente. Hable con frecuencia con sus partes interesadas y asegúrese de que estén completamente comprometidos con el proyecto.

La metodología ágil y los proyectos de precio fijo no van bien juntos, ya que al hacer una entrega de precio fijo no podrá obtener los mejores beneficios de hacer un proyecto de manera ágil. Para citar un ejemplo, es difícil incorporar cambios de demostración y cambios comerciales cuando se ejecuta dentro de límites fijos.

Habiendo dicho eso, aún puede hacerlo en sprints/de manera ágil con los siguientes pasos/preparaciones realizadas.

1. Asegúrese de comprender las especificaciones y la funcionalidad claramente definidas antes de comprometerse con la oferta fija.
2. No omita elementos abiertos/elementos ambiguos; o los incluye en su entrega de precio fijo después de considerar los factores de riesgo o los deja fuera.
3. Planifique sus iteraciones y objetivos de sprint. El sprint cero es una buena fase para hacer esto, ya que puede agrupar elementos en sprints que pueden reducir el esfuerzo. (Tenga en cuenta que esto va en contra de los principios ágiles de hacer una planificación "suficiente").
4. Haga una lista de elementos/funciones excluidas de esta fase de entrega (si es posible, agregue estimaciones aproximadas).
5. Realice un seguimiento de su progreso y sea transparente acerca de los retrasos y los problemas inesperados.
6. Comprometerse con las partes interesadas tanto como sea posible para que pueda gestionar las expectativas de manera eficaz.
7. Manténgase cerca del equipo y asegúrese de que comprendan y sigan los requisitos correctamente. Podría suceder que se alejen y creen código/datos de prueba innecesarios, lo que significa que perderá tiempo.
8. Realizar demostraciones en este viaje predefinido es un desafío. Probablemente tendría que agregar las sugerencias/cambios a la cartera de pedidos con miras a abordarlos en la siguiente fase en lugar de implementarlos en el próximo sprint. Si por algún motivo (por ejemplo, el valor comercial) se le pide que implemente alguno, asegúrese de intercambiar un artículo de igual peso.
9. Aconseje al equipo que trabaje de manera muy colaborativa para que los escenarios sean claros y esto reducirá los errores y también hará que las correcciones sean fáciles y rápidas.
10. Sobre todo, es importante que discuta el enfoque y las limitaciones con el equipo y el propietario del producto/negocio y otras partes interesadas y obtenga su aceptación antes de comenzar.

Se parece mucho a una cascada y es menos satisfactorio, ¡pero puede planear generar valor comercial en cada sprint y continuar!

Fijar el alcance, luego fijar el precio. Actualiza constantemente a medida que avanzas.

Intente estimar el proyecto en un rango de acuerdo con los aspectos aproximados que tenga. Debido a que son 'aproximados', los rangos estimados de costo y tiempo pueden estar relativamente separados. 10k - 20k o 3T - 4T de 2016.

Usar iteraciones para el desarrollo. Después de cada iteración, obtendrá más conocimiento sobre el proyecto y las especificaciones. Cualquier conocimiento nuevo que pueda afectar el costo debe comunicarse adecuadamente. Trabaje con el equipo y actualice las estimaciones en consecuencia.

Analizar el progreso y el trabajo que queda. Determine qué es más importante: entregar el producto o no sobrepasar el presupuesto. Sobre la base de ese equilibrio, el proyecto entregará los resultados necesarios.

Deben suceder dos cosas durante el proyecto, mientras adquiere más conocimiento y disminuye la incertidumbre sobre los requisitos:

1. Se da cuenta de que no es posible entregar este Alcance a este Costo. En cuyo caso solicita aumento de presupuesto y lo obtiene

o

2. El costo sigue siendo el mismo, pero usted equilibra el Alcance para que se ajuste al presupuesto.

Las mejores prácticas ágiles que puede utilizar: - Enfoque iterativo (trabajo en Sprints); - Planificación de Sprint/Lanzamiento; - Refinamiento del Backlog (volver a priorizar el trabajo antes de cada Sprint, según la situación del proyecto). Puede utilizar la relación Riesgo - Valor para priorizarlo mejor; - Estimaciones de puntos de historia que, con el tiempo, le traerán velocidad. Con eso, puede calcular y predecir el costo de los artículos futuros en los que trabajará a partir de la acumulación. Esto lo ayudará a administrar el presupuesto; - Realice un seguimiento de los cambios, calcule su impacto en el cronograma de costos; - Hacer que el proyecto sea lo más transparente posible para los Stakeholders. Debe administrarlo de manera que entiendan "POR QUÉ" el proyecto costará más o tomará más tiempo, si este fuera el caso.

No estoy seguro de qué tiene que ver Agile (o cualquier otra metodología) con esta pregunta.

Sin una especificación aprobada, está disparando a un objetivo en movimiento. Podría trabajar en algo por un tiempo, completarlo, pasar a otras partes y luego tener que reorganizar la pieza inicial, lo que puede afectar a todas las piezas posteriores.

La regla #1 en el desarrollo de software eficiente es " NUNCA trabajes con especificaciones aproximadas ". El trabajo solo se realiza en especificaciones aprobadas tanto por el cliente como por la persona de su empresa con la autoridad pertinente.

Cuanto más detallada sea la especificación, más rápida será la codificación y menos cambios. Esto puede sorprenderlo, ¡pero en algunas empresas las especificaciones tienden a declararse completas! en algún momento. Cualquier cambio adicional tiene un costo, como una solicitud de cambio .

^{Una vez trabajé para un contratista que ganó una licitación a un precio muy bajo; debajo del costo. Todo su margen de beneficio se basaba en solicitudes de cambio . Su plan de juego era definir la especificación de tal manera que pareciera completa, pero en realidad le faltaban piezas clave. Cuando el cliente los solicitaba, se le cobraba.
"¿Qué? ¿La puerta no tiene manija?"
"No, no está en la especificación. Solo se especificó un ojo de cerradura".}

Parece que su cliente está trabajando al revés; mantenga la especificación abierta para que se pueda incluir cualquier cosa en ella.