El año pasado dirigí un proyecto para un instituto de investigación. Los requisitos habían estado en progreso durante todo el proyecto, y tuve muchos problemas al planificar, presupuestar y proporcionar otras estimaciones.
Ahora, en 2011, el cliente solicita una oferta de precio fijo para evolucionar el sistema entregado. Una vez más, los requisitos son tan indefinidos que en la primera fase planeo una tarea de análisis de aproximadamente dos meses para simplemente DEFINIR los requisitos.
Después de pensarlo un poco, estoy casi convencido de que un enfoque ágil sería la respuesta para satisfacer a ese cliente (y no tener otro año doloroso;)). Mis preguntas son:
Entiendo que estas no son preguntas fáciles de responder. Gracias
En realidad, a diferencia de otros, creo que ágil podría ser una buena respuesta aquí. Dicho esto, considero que firma algún tipo de contrato ágil con el cliente, lo que significa que puede rescindir el contrato después de cada sprint. Por supuesto, no es tan fácil negociar este tipo de contratos: puede encontrar la presentación de Paul Klipp sobre la venta ágil muy útil si desea ir por este camino ( también hay diapositivas ).
El contrato clásico de precio fijo con requisitos vagos debería generar señales de alerta, como señala DaveParillo, por lo que me centraría en especificaciones bien definidas o en convencer al cliente de cambiar al contrato que limita los riesgos para ambas partes en esta situación.
El uso de un enfoque ágil dentro del equipo del proyecto es otra historia que no está tan estrechamente relacionada con el formulario del contrato. Puede emplear un enfoque ágil en un proyecto que está bajo términos de precio fijo y puede funcionar bastante bien. Si el cliente está listo para tomar su parte del proceso, por ejemplo, demostraciones de productos después de cada sprint o priorizando características repetidamente, probablemente sea una buena idea. Entonces, mi respuesta a la pregunta 1 es: sí, Agile puede ayudarlo.
La transición a Agile sin ningún miembro que tenga experiencia en Agile probablemente será difícil. Un mínimo razonable es alguien que tenga experiencia en diferentes proyectos y diferentes organizaciones para que sepa qué puede funcionar y qué no. Además, el equipo debe estar muy abierto para aprender y mejorar con el tiempo.
Por supuesto, sería mucho mejor si pudieras encontrar un entrenador que te ayudara con el arranque. De lo contrario, es posible que visite algunos callejones sin salida antes de encontrar una forma que funcione bien para su equipo.
No existe una respuesta general fácil sobre cuánto tiempo lleva cambiar a un nuevo método, sin importar si es ágil o no. Depende en gran medida de las personas, la situación, el proyecto, los plazos, etc. Puedo darte un ejemplo cuando estábamos cambiando a Kanban, un enfoque que ninguno de nosotros conocía de la práctica anterior. Nos tomó alrededor de medio año llegar al punto en el que teníamos bastante fluidez con la forma en que trabajábamos, sin embargo, no fue un punto único en el tiempo: vimos las primeras mejoras después de solo unas pocas semanas desde el principio. Contábamos con una persona con experiencia en diferentes enfoques y el equipo estaba dispuesto a aprender y adaptarse. Es realmente difícil responder con exactitud, pero creo que entre un mes y dos meses estábamos mejor que antes del cambio.
Ágil no es la respuesta. Pruebe la planificación de olas rodantes con amplias reservas en el contrato.
No dejes que te convenzan de un precio fijo sin darte suficientes recursos para acomodar las iteraciones necesarias para obtener una mejor definición del proyecto. La investigación está llena de incógnitas.
Esta publicación y los comentarios pueden ser útiles.
¿Está planeando comprometerse con un contrato de precio fijo para "evolucionar" algo con poca o ninguna estabilidad de requisitos? Precio fijo + requisitos inciertos son una mala combinación. Esto debería ser una señal de peligro y no, Agile no es una panacea que mágicamente hará que este problema sea más fácil para usted en 2011. Todo el proyecto es arriesgado: agregar un compromiso de "cambiar a Agile" no lo hace mucho. peor de lo que ya es. Perdón.
No estoy seguro de cuáles son las expectativas de sus clientes, pero eche un vistazo al Manifiesto Ágil . Si cree que su proyecto futuro podría beneficiarse al cambiar el enfoque de los elementos de la derecha a los elementos de la izquierda, tal vez algunas prácticas ágiles puedan ayudarlo.
Según su pregunta, parece que nadie en el equipo del proyecto tiene experiencia con el desarrollo ágil y no planea pagar la capacitación. Otra señal de peligro. Necesita al menos un entrenador o un mentor, una persona que realmente comprenda el modelo de proceso que está tratando de implementar. Si envía a uno de los suyos a recibir este tipo de capacitación, tiene la ventaja de tener un mentor con una excelente comprensión de las necesidades y limitaciones de su organización. Aún puede beneficiarse de consultores externos, ya que los mentores locales pueden tener menos objetividad que un consultor.
En lugar de cambiar a ágil (o no) porque alguien en esta página dice que debería (o no), le sugiero que examine de cerca los problemas que experimentó el año pasado y cree estrategias para eliminarlos o minimizarlos. Por ejemplo:
Considere un taller de reflexión o una retrospectiva . Haga esto independientemente de si acepta su trabajo de precio fijo o no. Parece que tiene algo que aprender de un proyecto anterior que fue más difícil para el equipo de lo que le hubiera gustado.
Creo que puede depender del proyecto. Agile funciona extremadamente bien cuando puede comenzar a entregar de forma incremental y, para ser justos, esos podrían ser incluso sus documentos de requisitos.
Lo que sugeriría es que no solo intente "ser ágil": asegúrese de comenzar con un enfoque probado y comprobado, como scrum, cuando esté comenzando y no tenga experiencia. Comenzamos tratando de ser ágiles inicialmente y nos metimos en un lío correcto hasta que dimos un paso atrás e implementamos un marco adecuado. Siempre puedes adaptarlo a tus necesidades a medida que pasa el tiempo.
gracias a todos por los comentarios El
precio fijo es una obligación administrativa para el cliente y ya estamos presionando para alcanzar el precio más alto posible, para mantener un margen más alto para lo desconocido.
El problema son las expectativas del cliente que, con demasiada frecuencia, el año pasado cambiaron. En mi idea, adoptar Agile significaría "obligar" al cliente a centrarse en las iteraciones y en lo que lanzaremos en cada una, realizar un seguimiento del trabajo pendiente y ajustar la prioridad según sus comentarios. De esta manera, creo/espero poder lograr que las expectativas del cliente se mantengan más adheridas al alcance del proyecto, limitando el enfoque de sus investigadores que tienden a hacer que el proyecto sea tan arriesgado.
De hecho, hay un gran problema político oculto aquí, porque el cliente quiere investigación, pero el proyecto producirá un portal de servicios para los ciudadanos en nombre del gobierno.
No puedo impulsar la política, pero necesito una forma de mantener el proyecto bajo control.
En mi opinión, los métodos ágiles cambian la relación que tienes con tus clientes cuando eres un proveedor de servicios de TI. Los precios y la facturación pueden convertirse en un problema.
Creo que una solución es proceder por paquetes. Creo que debería ser particularmente adecuado para Scrum: define un conjunto de historias para cada sprint y factura cada sprint, por lo que el proyecto avanza, mantiene una visibilidad (el alcance de un sprint no se puede cambiar mientras está en desarrollo) , pero el proyecto está abierto a cambios y el cliente está involucrado.
Yoda
Todd A. Jacobs