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.

Esto de la gestión visual del flujo de trabajo, los daily scrum, los sprints, las retrospectivas, la programación por pares, etc… son vistos por muchos como un juego y no les culpo, yo también lo veía así cuando los árboles del enfoque clásico y su infinidad de problemas me impedían ver el bosque.

Y si quienes tienen que aplicarlas lo ven como un juego difícilmente van a funcionar. Este es uno de los principales problemas que tiene la aplicación de prácticas de estrategias o metodologías ágiles en los proyectos de desarrollo de software.

Quienes están acostumbrados a trabajar con enfoques clásicos con una orientación a producir entregables formales (sirvan o no) y a tener el proyecto clasificado en etapas diferenciadas y especializadas les va a resultar complicado ver esas prácticas como algo serio:

1) Durante años se les ha grabado a fuego que ingeniería de software es lo que ellos hacen (o que la forma de trabajar correcta es esa) y que cualquier cosa que salga de ahí no lo es.

2) También, durante años, se les ha dado el mensaje que el éxito en los proyectos de desarrollo de software está en los procesos y no en las personas. Por tanto, un enfoque en el que lo importante son precisamente las personas y su interacción y en donde las necesidades del producto predominan sobre el proceso, choca, porque se está abriendo la puerta a procesos abiertos en los que las prácticas, estrategias y herramientas se eligen en función de lo que el proyecto requiere (que no es incompatible con intentar armonizar un núcleo reducido de las mismas en diferentes proyectos) y porque no se van a trabajar con especificaciones cerradas sino que van a estar abiertas con el objeto de proporcionar al producto un mayor valor a través del feedback del área usuaria.

Sin embargo, si se echa un poco la vista atrás y vemos los resultados obtenidos en los proyectos en los que se ha trabajado con enfoques clásicos nos daremos cuenta de manera sencilla que algo falla porque el desgaste personal, el esfuerzo real y la inversión realizada en los proyectos no se corresponde con los resultados obtenidos. Sin embargo pese a esa evidencia muchos, muchísimos, siguen sin explorar otras alternativas, en unos casos porque piensan que el desarrollo de software es así, en otros porque no terminan de considerar tan negativos esos resultados y otros muchos que pese a que están convencidos de que esta dinámica de trabajo falla no consiguen sacar tiempo (o tener voluntad) para estudiar o formarse en otros enfoques de desarrollo de software.

También está el caso de quien quiere pero que no encuentra la oportunidad de poner en marcha estas estrategias, en estas situaciones digo lo de siempre, la agilidad es cuestión de actitud y eso está por encima de las circunstancias en las que tengas que trabajar en el proyecto. Lo mejor es tener la posibilidad de poder experimentar (con cabeza, siempre con cabeza y pensando en lo mejor para el proyecto) pero no siempre vamos a tener la oportunidad de ser nosotros quiénes elijan las condiciones en las que se va a realizar el proyecto.

También está el caso de quien quiere pero no se atreve, entiendo el temor, pero es importante darse cuenta de que los cambios deben hacerse de manera paulatina y que, por tanto, no se trata de introducir numerosas prácticas nuevas sino de ir haciéndolo poco a poco, hasta llegar a entenderlas bien. El primer paso lógico es la adopción de un enfoque iterativo incremental y empezar a crecer a partir de ahí.

En el artículo de ayer veíamos la necesidad de tener bien definidas las historias de usuario que van a formar parte de la pila de sprint, en el de hoy veremos una posible estrategia para conseguir esto.

¿Qué hacemos entonces? Mientras se trabaja en un sprint hay que estar preparando el siguiente, si trasladamos esto a una línea de producción, mientras las máquinas y sus operarios trabajan es necesario que alguien vaya a comprar y preparar las materias primas, de lo contrario se interrumpe el proceso.

¿Quién hace eso? Posibilidades hay muchas. Hay bibliografía que recomienda reservar entre un 5% y un 10% de la capacidad del equipo del sprint a realizar estas tareas o lo que es lo mismo, el equipo de sprint considera en cada iteración que tiene entre un 5 y un 10% de capacidad menos para asumir tareas. Estos límites pueden fluctuar en función del momento del proyecto en el que no encontremos a la vez que podrían sobrepasarse en el caso de que fuera necesario (y se tuviera en cuenta en la definición de la capacidad asumible en el sprint).

¿Mi opinión? Como siempre, os advierto que no hay soluciones únicas. Es fundamental que las tareas con mayor prioridad de cara al siguiente sprint estén lo suficientemente detalladas para que se pueda hacer una buena estimación y se pueda comenzar a trabajar con el objetivo de que la línea de producción pueda funcionar fluida y podamos cumplir los compromisos.

Por tanto no debemos quedarnos cortos a la hora de dedicar esfuerzo a esta actividad (que suele recibir el nombre de refinamiento de la pila de producto). Es posible que para conseguir ese objetivo tengamos que poner un cierto colchón de seguridad por si el proceso de definición es más complejo de lo que parecía (algo que es, por otro lado, bastante frecuente), desde mi punto de vista es mejor que no se llegue a ese tope y corramos el riesgo de “tirar” capacidad (algo que no tiene por qué ser así porque ese tiempo extra lo podría dedicar a echar una mano en el sprint en curso ya que siempre hay tareas que hacer y nunca está de más contar con ayuda extra) que poner en riesgo los compromisos del sprint o lo que es lo mismo, perder más tiempo por bloqueos en el proceso de desarrollo motivados por no tener todos los “ingredientes” necesarios para trabajar.

Con esto estoy diciendo que quien realice esa tarea (que podría ser siempre el mismo o no) es parte del equipo, es decir, sufrirá o se beneficiará de la calidad de su trabajo, de esta manera evitamos antipatrones del tipo “arrojar al otro lado del muro”. Esto implicará que parte de su dedicación (prevista y cuantificada en cada iteración) tiene que estar en el sprint y ser tenida en cuenta la hora de definir los compromisos.

Por tanto, estoy de acuerdo con lo que indica la bibliografía pero no tanto en los porcentajes que expresa porque me parecen demasiado optimistas sobre todo para proyectos que empiezan.

Otro aspecto que resulta complicado de entender cuando se comienza a trabajar con prácticas basadas en Scrum es cómo se va poder realizar una estimación con calidad en la reunión de definición de la pila de sprint sobre historias de usuario que están descritas a muy alto nivel.

Es más fácil de entender en contextos donde el equipo tiene un conocimiento importante del producto y tecnología sobre la que se desarrolla y las tareas se basan en evoluciones de componentes o pantallas ya desarrolladas. Sin embargo, en los primeros sprints o en situaciones donde se incorpora funcionalidad adicional a las ya existentes (nuevos módulos) se necesita tener una definición más detallada de las historias de usuario.

Si el equipo de proyecto se compromete a tener terminadas (listas para un hipotético paso a producción) las tareas definidas en la pila de sprint al final del mismo, es fundamental que acierte en las estimaciones y para hacerlo resulta importante tener lo suficientemente desarrollada la historia de usuario antes de empezar a trabajar con la misma, de lo contrario se tendrá que invertir tiempo de sprint en hacer ese trabajo y lo mismo resulta que lo que quiere el product owner es más complejo de lo previsto (se pierde tiempo en perfilar la historia de usuario y el exceso de complejidad sobre lo previsto se come capacidad del equipo en el sprint), lo que hará que probablemente no se puedan cumplir con los objetivos definidos.

Si de manera recurrente se incumplen los objetivos perdemos confianza en el esquema de trabajo y la predecibilidad que estamos buscando dentro del contexto del sprint. Esto quiere decir que algo falla y en este caso es que las historias de usuario no están lo suficientemente definidas al comienzo del sprint. Es importante hacer una diferenciación entre consultar detalles al product owner algo que resulta del todo razonable y otra hacer un análisis más en detalle en pleno sprint.

En el artículo de mañana veremos una posible solución a este problema.