archivo

Archivos diarios: abril 11, 2012

No se pueden entender desarrollos ágiles si no se disminuye la resistencia hasta unos umbrales mínimos aceptables.

¿Qué es la resistencia? Toda aquella actividad que dificulta el progreso del proyecto y esto se extiende desde el propio proceso de desarrollo (incluida la implantación del sistema en sus diversas iteraciones) hasta el conjunto de stakeholders que intervienen en el mismo, pudiendo incluso trascender a lo que es el propio proyecto: tanto en aspectos de políticas y normas como en aspectos de infraestructura (estabilidad de la aplicación, del CPD en el que se encuentra, etc…).

No entiendo como resistencia actividades propias del proceso de desarrollo independientemente de que no tengan influencia directa sobre el producto. Habrá quienes piensen que lo que no tenga influencia directa en el desarrollo se considere resistencia en todos los casos y lo respeto y hasta puedo llegar a estar de acuerdo, no obstante hay que entender que habrá tareas que son necesarias de realizar con el objeto, por ejemplo, de cumplir con los procesos establecidos en la organización, pero, ¿dónde está la frontera entre lo que es resistencia y no lo es? cuando se pierde la visión de los principios ágiles.

Es muy difícil encontrar un contexto de trabajo sin resistencia, por lo que será algo con lo que tendremos que convivir. Ahora bien, No se puede hacer un desarrollo ágil si se superan unos ciertos límites. Claro que podrás aplicar metodologías, tácticas o actitudes ágiles pero otra es que las puedas aplicar en condiciones y sean realmente efectivas.

Hay otra cita de Jef Raskin que resulta complementaria o incluso podría considerarse una continuación de la indicada en el artículo de ayer: [Refiriéndose a los ordenadores] “Los usuarios no se preocupan por lo que hay dentro de la caja, siempre y cuando la caja haga lo que necesiten”.

Trasladando esta cita al desarrollo de software, ese punto de vista es compartido por la inmensa mayoría de usuarios, que no tienen por qué entender de deuda técnica, de calidad del código, de tecnologías o frameworks de desarrollo, etc…, por eso el cumplimiento de las expectativas de usuario es la variable más significativa de la calidad del software.

Es responsabilidad de los responsables técnicos del cliente que esas otras variables también se encuentren alineadas con los objetivos de la organización y con los umbrales establecidos para cada una de ellas.