Interesante tu comentario. Creo que en cierto modo te doy mi opinión en el post titulado Pollaques vs Ignorancia. Intentaré sintetizar las ideas que en él exponía para responderte.

En mi opinión, los pollaques aparecerán con independencia de la metodología que apliques. Los veo ligados al negocio del cliente y no al proceso, y surgirán cuando hagas Model Storming con los usuarios finales, ya sea durante un ciclo de vida iterativo o durante uno en cascada.

Lo que hay que defender es que el pollaque no estaba presupuestado, y en caso de ser necesario añadirlo, habrá que negociar:
1. Revisar la planificación temporal y económica del proyecto.
2. Cuando éstas sean inamovibles, entonces habrá que revisar el alcance del proyecto (si meto por un lado tendré que quitar por otro). La planificación es un juego donde lo que importa son las cifras totales (qué más da dedicar dos semanas adicionales en la capa de servicio si finalmente para la release candidate se han suprimido requisitos de interoperabilidad que en esfuerzo equivalían a dos semanas de trabajo).

Si las posturas no se aproximan, entonces habrá que estudiar si se le pierde menos dinero al proyecto rechazándolo que ejecutándolo con las nuevas normas del juego. Este estudio es complejo, tal vez interese asumir las pérdidas por cuestiones estratégicas:
1. Fidelizar con el cliente para futuras actuaciones.
2. Es un nuevo cliente con el que nunca se trabajó.
3. Es un cliente que pudo quedar insatisfecho en proyectos anteriores -por los motivos que sea- y se presenta la oportunidad de ofrecerle valor y satisfacción.

Es indudable que para poder aplicar metodologías ágiles se deben presentar una serie de condiciones, tanto en el lado del equipo como en el lado del cliente: asunción de responsabilidades (el cliente también asume las que le corresponden), empatía, concepción del equipo (el cliente también forma parte de él), percepción del tiempo (es perdido o invertido), tolerancia ante el cambio, implicación y motivo de implicación (no es lo mismo implicarte porque tu jefe te lo impone que porque existe un interés sincero en la propia acción de implicarse), grado de interés en alcanzar el éxito y hasta dónde se está dispuesto a llegar para alcanzarlo.

El cliente mayoritario con el que trabajo es la Administración Pública, y hay de todo. Tenemos clientes tan implicados que siguen la evolución de los proyectos día a día y se involucran hasta niveles inimaginables. Tenemos otros que ni siquiera asumen su parte de responsabilidad en la ejecución de los proyectos, y provocan situaciones incómodas haciéndonos responsables de sus errores. El factor común entre todos ellos es la concepción que tienen sobre los proyectos:
1. Lo que se va hacer sí está abierto dentro de unos límites (aunque hayas elaborado presupuestos, ofertas, etc. nunca sabrás al inicio todos los datos que necesitas para que esos presupuestos y ofertas estén ajustados y sean realistas), y nunca oses decir lo contrario.
2. Lo que se va a cobrar no lo estará nunca. Una vez más entra en juego el factor negociación: revisar planificación temporal, económica, y alcance del proyecto, intentar modelar pollaques de gran impacto en el proyecto como futuras ampliaciones del mismo, etc.

Espero haber sabido transmitirte mi opinión.

Un saludo.

Sobre el tema de las metodologías ágiles y la estimación tengo bastantes dudas. La mayoría de los clientes tienen unas restricciones muy férreas en cuanto a plazos y presupuesto. Y no quieren dejar nada abierto (quieren saber cuánto les va a costar el desarrollo, en tiempo y dinero). Esto parece ir un poco en contra de la metodología iterativa de Scrum, donde los requisitos se van revisando, añadiendo, quitando y re-especificando en cada sprint.

Por ejemplo, si una empresa me pide presupuesto, se lo hago y gano el proyecto; si luego aplico Scrum corro el riesgo de que aparezcan incontables “pollaques”. El tiempo de desarrollo se va a incrementar enormemente, con seguridad voy a perder dinero. Además el cliente intentará regatear ya que para él habré tardado más de la cuenta.

Por eso desde mi punto de vista (actual, que no inamovible) SCRUM y demás metodologías ágiles están bien cuando el cliente es consciente de que el proyecto es abierto, y por tanto lo que le vas a cobrar también. Lamentablemente no conozco muchos clientes de este tipo

Me gustaría conocer otras opiniones sobre estos temas que planteo.

Enhorabuena por el blog.
Saludos