archivo

Archivos Mensuales: noviembre 2012

Una buena estimación es fundamental en los proyectos de desarrollo de software ya que condicionan en gran medida su éxito.

Lo primero que hay que tener en cuenta es que resulta prácticamente imposible acertar en una estimación cuando todavía ni siquiera se ha comenzado a trabajar en el proyecto. La experiencia, el conocimiento del cliente, de la tecnología pueden minimizar el error que, sin duda, se producirá.

Esto que es algo evidente y que se repite una y otra vez y debería estar siempre presente tanto para clientes como para proveedores, para entender que lo realmente importante es el valor del producto, un valor que se sitúe o supere el de las expectativas puestas en él y que sea adecuado a la inversión que se está realizando. Siempre te queda la posibilidad de engañarte pensando que vas a cumplir con una agenda absolutamente irreal porque si la desviación en la estimación es sensible alguien la terminará pagando, cuando no todos: cliente, proveedor y producto.

¿Entonces qué hacer? Lo primero es saber qué quiere el cliente, ¿realmente apuesta por el valor o por la agenda? Reconozco que es complicado poner encima de la mesa la necesidad de presupuestos abiertos sobre todo cuando pueden tener la agenda amarrada contractualmente y todavía más cuando hay proveedores dispuestos a firmar y a comprometerse con lo que sea (otra cosa bien distinta es que después cumplan algo).

El gran error de los clientes es pensar que la orientación al cumplimiento de agendas solo ata al proveedor y no es así, también le ata a él. Tanto si abordas un enfoque clásico o divides el proyecto en fases (que no es lo mismo que aplicar un enfoque iterativo incremental) estás sometiendo el producto a las especificaciones que se realicen antes de la etapa de construcción, limitando el valor del producto a las mismas y sin poder incrementarlo a través del feedback.

En el momento en el que el cliente empieza a modificar requisitos en etapas tardías ya está rompiendo las condiciones iniciales, como esos requisitos se añaden sin orden y sin organización, el coste sobre el producto y el impacto sobre la agenda es importante.

Sin embargo, si desde el principio se sigue un enfoque iterativo incremental, con una adecuada priorización de las funcionalidades y aprovechando el feedback del usuario (fruto de un conocimiento cada vez mayor de qué es lo que quiere), se conseguirá un mejor aprovechamiento de los recursos económicos ya que se ha desarrollado con una mayor intención y el producto tendrá un mayor valor.

A priori no se sabe el número de iteraciones necesarias ya que el usuario puede equivocarse, puede cambiar de enfoque, pueden cambiar las condiciones y sea necesario adaptarnos al cambio, puede que el umbral de valor aceptable del producto varíe, por ese motivo es fundamental dejar la puerta abierta a ampliaciones presupuestarias.

Como es lógico, se requiere un product owner con sentido común y con sentido del trabajo que se está realizando. Si no tiene esas características el proyecto incumplirá agendas, el producto verá mermada su calidad y el desgaste entre las partes será cada vez más ostensible.

Si el product owner se cierra en banda en el contrato es posible que cumpla agenda (salvo que estemos en un Death March Project) pero tenga un producto que deje muchísimo que desear porque por un lado con esa actitud no puede esperar que el equipo de proyecto sea flexible y por tanto el enfoque iterativo incremental pierde la esencia del feedback y por otro el producto final verá mermada su calidad porque con exceso de presión y overtime no se trabaja bien y porque se habrá dedicado menos tiempo a tareas de testing y a afinar el código.

A todo esto habrá que sumar el overhead provocado por el formalismo que será necesario introducir en el proyecto, ya que en este tipo de situaciones todo debe hacerse con pies de plomo, ya que de lo contrario y en caso de conflictos, quien no tenga las cosas bien atadas, sufrirá.

Por tanto, el product owner (y es importante que tenga el nivel de autoridad suficiente como para tomar decisiones o que sus decisiones las refrende alguien con ese nivel de autoridad) es la clave para conseguir una convivencia entre agenda y enfoque iterativo incremental.

¿Todo es negativo en las agendas? Como he venido comentando, una agenda se convierte en una resistencia importante en el proyecto si no se interpreta la misma en función de las circunstancias del proyecto y del valor que queramos conseguir en el producto (esa interpretación debe ser consensuada entre las partes). En esas circunstancias, sí que puede resultar interesante partir con unas fechas y con un presupuesto de referencia porque ayudará a que todos estén más centrados en el proyecto, con la dedicación que requiere y tomando decisiones y desarrollando con iteración, disminuyendo el número de iteraciones provocadas por situaciones de prueba y error o por no haber prestado suficiente atención en las especificaciones.

¿Qué hacemos?, ¿aplicamos un enfoque clásico? Salvo que la naturaleza del proyecto aconseje que sea la mejor opción, no lo recomiendo, porque en este caso los problemas se centrarán sobre todo en el nivel de satisfacción del producto final y además, las solicitudes de modificación de los requisitos por parte del usuario en fases avanzadas del proyecto terminarán también por afectar a la agenda.

¿Y si el enfoque es iterativo incremental?

Vamos a ver en primer lugar las implicaciones que tiene trabajar con plazos predefinidos. Tener en el horizonte esas fechas límites lo podemos asemejar a las fechas límite que tenemos en cada sprint, con la diferencia de que la capacidad de trabajo asumible en cada sprint la define el equipo de proyecto, mientras que la fecha límite del plazo se ha definido sin conocer el alcance y complejidad real del proyecto y probablemente por un tercero.

¿Esto que quiere decir? De base nos comprometemos a cumplir los objetivos definidos en cada sprint, si esto es así, para el plazo especificado tendremos una serie de funcionalidades implementadas y listas para pasar a producción, ahora bien, ¿son las que estaban previstas conseguir en ese plazo? Ahí es donde está el problema y en donde hay que aplicar soluciones.

El product owner debe ser consciente en cada momento de lo que está hecho, de lo que se está haciendo y de lo que se tiene previsto hacer, si sabe que el equipo está trabajando bien, cuando vea que es complicado cumplir los plazos, afinará más en la priorización de las tareas, intentará acertar lo máximo posible en las especificaciones y tenderá a buscar soluciones más simples. Es posible que tenga que sacrificar algunas funcionalidades y retrasarlas a fases posteriores del proyecto, al principio mostrará resistencia, después se dará cuenta que pedir imposibles no lleva a ninguna parte.

El equipo de proyecto probablemente tendrá que ampliarse para poder asumir una mayor cantidad de trabajo y por otro tendrá que intentar ser lo más productivo posible. Ampliar el equipo produce resultados si nos anticipamos lo suficiente a esa demanda y si las personas que entran conocen la tecnología y entorno de desarrollo. Es muy posible además, que el equipo tenga que hacer un sobreesfuerzo. Esto no me gusta y debe ser la última opción porque afecta a las personas y si están cansadas y presionadas sufre también el producto.

Esto tiene implicaciones sobre la agenda, ya que estamos gastando más presupuesto del inicialmente definido para esta fase y evidentemente lo que gastemos de más ahora será dinero de menos que tendremos después. Es el product owner quien debe autorizar esto y lo mejor es que se llegue a una solución de consenso.

En un enfoque iterativo incremental se pretende que el producto vaya adquiriendo un mayor valor en cada iteración como consecuencia de la propia evolución del mismo y el feedback que el usuario proporciona al final de cada ciclo.

Esto puede dar lugar (y dará lugar) a una mejora continua de las especificaciones que se han realizado sobre el producto ya que resultará muy complicado que el product owner, por muy bien asesorado que esté, acierte siempre a la primera.

Cuanto más complejas sean las funcionalidades a especificar más probabilidad existirá de que se tenga que iterar varias veces sobre ellas.

Por otro lado, trabajar en base a una agenda implica partir de base con unos plazos y con un presupuesto fijo, los cuales probablemente se han definido sin tener una visión completa del producto a desarrollar, que además será abstracta y sin tener en cuenta los riesgos (imaginando, por tanto, unas condiciones ideales).

De entrada, si los plazos y presupuesto no se corresponden con el trabajo a realizar, el proyecto nace tocado y si la desviación importante, nace hundido (Death March Project) y será muy complicado, cuando no imposible, darle la vuelta salvo que la agenda pueda ser modificada.

Por tanto, en el momento en que estamos iterando y, por tanto, repitiendo determinado trabajo, nos estamos cargando la agenda, es decir, si ya es difícil cumplir con los objetivos de una agenda definida en las condiciones que he indicado anteriormente, más lo será si aplicamos un enfoque iterativo incremental.

La cuestión es, ¿qué se prefiere?, ¿cumplir agendas o intentar que el producto tenga el mayor valor posible?. En muchos casos, la respuesta a estas cuestiones no es negociable, hay por contrato un presupuesto, unos plazos y un alcance.

Una historia de usuario no es una descripción de una tarea en un post-it. O tal vez sí. Depende de lo que requiera el proyecto o del contexto actual del mismo.

Sobre esa base, habrá opiniones para todos los gustos. La mía es que las historias de usuario requieren ser descritas con el suficiente nivel de detalle para poder ser estimadas con fiabilidad y para que el programador pueda trabajar con ellas.

Es importante no olvidar que el objetivo no son historias de usuario que lleguen al máximo nivel de detalle, sino la que se necesite. No es fácil alcanzar ese equilibrio pero con la experiencia (desde una visión general) y tras algunas iteraciones (centrándos en el proyecto en el que estamos trabajando) nos iremos aproximando a ello.

Esto desde un punto de vista de la producción, ya que habrá determinados tipos de proyecto que requieran además que el cliente y el proveedor vayan aprobando hitos de trabajo (y su presupuesto correspondiente), en estos casos, el hecho de que las historias de usuario estén por escrito y con el suficiente nivel de detalle es absolutamente necesario.

Puede aparecer que esto contradice en cierto modo el tercer principio el Manifiesto Ágil: “Se valora la colaboración con el cliente por encima de la negociación contractual”, pero hay que tener en cuenta que cuando se contratan nuestros servicios por terceros, el nivel de formalidad vendrá definido por el acuerdo al que se llegue con el cliente y por la experiencia que tengamos en trabajar con ese cliente o con clientes de ese sector. En estos contextos, tener registrado qué se hace y con una aprobación formal por parte del product owner, evitará muchos problemas después.

¿Cómo catalogamos las historias de usuario? Mi recomendación es que las historias de usuario se cataloguen a nivel de sprint, pudiendo estar en un documento independiente o en uno que vaya recopilando los diferentes sprints. Hay que tener en cuenta que no estoy creando un excesivo overhead ya que considero fundamental tener bien especificadas las historias de usuario (cuando digo bien especificada siempre hago referencia a lo que la historia de usuario necesita que en función del estado del proyecto puede requerir más o menos nivel de detalle).

Volviendo a la catalogación de las historias de usuario, se tratarían de documentos que no se modificarían como consecuencia de la evolución del sistema, ya que son fotos de cada sprint. Se pueden hacer trabajos de consolidación para hacer fotos no ya a nivel de sprint sino a nivel de sistema en determinados momentos del tiempo, serán las necesidades del proyecto, del producto y de los participantes las que dicten la necesidad o no de hacer esa actividad.

Con las historias de usuario volvemos al lenguaje natural, lo que no limita la utilización de prototipados de interfaz, subconjuntos del modelo de datos, etc…, sin olvidar que su objetivo y funcionamiento debe ser entendible por el product owner (independientemente de que haya especificaciones concretas para los desarrolladores).

Las historias de usuario deben detallar la tarea y también describir las comprobaciones que debe hacer el product owner para dar por válida la misma (antes las deberá hacer el equipo de desarrollo y testers especializados si existen en el proyecto), es importante señalar que una historia de usuario debería ser válida o no válida y no deberían existir estados intermedios como “casi válida”, recordemos que queremos mantener un ritmo sostenido de desarrollo y eso requiere no estar continuamente dejando flecos abiertos.

Una estrategia que me he encontrado muchas veces para imponer un criterio, una opinión o para dar por zanjado un asunto, una tarea o un trabajo y que la verdad es que suele dar buenos resultados (por lo menos para conseguir el objetivo otra cosa es que después tenga consecuencias) consiste en mantenerse en ella digan lo que te digan, intentando lidiar con las peticiones de cambio aguantando el chaparrón.

Una vez superada la fase inicial después resulta mucho más fácil que tu criterio prevalezca, hay mucho trabajo, surgirán otros problemas y la atención de tu interlocutor o interlocutores se centrará en otros asuntos.

No funciona siempre pero sí en más ocasiones de las que parece o debiera.

Como decía antes conseguir tu objetivo no quiere decir que sea gratis y dependerá del impacto que tenga salirte con la tuya ya que puede ser beneficioso para ti pero no para el proyecto o para el cliente. No vale todo.

Ya lo decía Leonardo: “Es más fácil resistirse al principio que al final”.

Pues lo pasamos mal pese a que el resto de la organización suele pensar que lo pasamos muy bien. No tenemos peso, no tenemos influencia a nivel directivo, lo importante es el negocio de la organización y nosotros somos solo un instrumento.

Se nos exige mucho y los recursos que nos suelen dar son muy limitados o por lo menos son inferiores a las necesidades reales. Si hay que recortar se recortará por la parte TIC ya que al fin y al cabo somos algo secundario.

Esa mentalidad no solo hace daño a los departamentos TIC sino que lo hace a la propia organización. ¿Puede la misma plantearse funcionar sin recursos TIC?, ¿sobreviviría a un apagón TIC? Seguro que no y sin embargo el tratamiento es similar a cuando todo funcionaba con papel y archivadores.

Es cierto que muchos departamentos TIC crecieron desmesuradamente (más en volumen de trabajo que en recursos) en la época de bonanza y eso se está pagando ahora pero también lo es que incluso quienes hicieron un esfuerzo en su día por ajustarse a la realidad están sufriendo actualmente.

Recortar sin medida en TIC es bajarle el octanaje al combustible, se piensa que el motor va a rendir igual. Eso no puede ser así porque las tareas siguen siendo X y los medios muchos menores que antes. No es cuestión exclusivamente de productividad (siempre es posible mejorar) se trata ya de una cuestión física.

Y no cabe duda que un Departamento TIC que funcione bien tiene influencia directa en el funcionamiento de la organización y por ese motivo debe cuidarse y tener un peso en la organización que no tiene. El responsable del Departamento TIC debería tener un puesto de nivel directivo y tener un trato de igual a igual con el resto de responsables de área.