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.

Antes de nada, me gustaría agradecer tu comentario. En cierto modo, me ha hecho retomar la actividad en el blog. Desde hace unos meses la falta de tiempo y, en algún que otro momento, de motivación, me estaban llevando a la desidia bloguera.

¿Qué es peor? ¿Un pollaque o la ignorancia? Te comentaré mis conclusiones (mías, propias) después de varias experiencias que he tenido últimamente, analizadas desde distintas perspectivas (todas ellas, como podrás ver, desprenden cierto pesimismo). Tras estas experiencias desagradables soy incapaz de sintetizar la respuesta, así que te respondo en un post, al que he titulado Pollaques vs Ignorancia.

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

Voy a seguir leyendo los siguientes. Mientras tanto me queda la duda de si son peores o los “pollaques” a la ignorancia.

Saludos y felicidades por el blog.

Como dices, la idea es la misma, pero aplicada a las métricas de los requisitos, que poco o nada tienen que ver con las que proporciona Sonar. Creo que el evangelista que pronunció esa frase originariamente es bastante anterior a Tom DeMarco, y lo hizo con las palabras You can’t manage what you don’t measure, pero aplicadas al ámbito empresarial.

Un saludo.

Un saludo.

PD: publicaste el blog hace unos días y ya tienes más comentarios que yo en siete meses, ¿cómo lo haces crack?

Algo muy relacionado con el aseguramiento de la calidad, medir es la clave para mejorar.

Un saludo

Ese comentario que has hecho es muy interesante, y será el tema de discusión de sucesivos posts (digo sucesivos porque tenía varios en mente), bajo el título Si no puedes medirlo, no puedes mejorarlo.

Un saludo.