Desarrollo de software. Estimaciones poco afortunadas

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

– La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

– Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

– Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

– Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

– No estima quien va a realizar el trabajo.

– La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

Desarrollo de software. ¿Son las estimaciones una guerra perdida?

El tamaño y la incertidumbre importan. Para un proyecto donde se prevé el desarrollo de un nuevo sistema de información de medio o gran tamaño o un mantenimiento evolutivo importante del mismo resulta muy complicado acertar, es más, soy de la opinión de que si se acierta es por casualidad.

Un gran desarrollo tiene incertidumbre inherente porque es sabido que en la mayoría (aplastante) de los casos, los usuarios no saben realmente lo que quieren hasta que se va avanzando en la construcción del producto y esto sucede independientemente del enfoque de desarrollo que se le quiera dar. Si a eso le sumas otros factores como la inestabilidad de los procesos de la organización cliente, de la propia organización, el mercado, etc…, todo se hace mucho más complicado.

Por ese motivo es importante que todas las partes sean conscientes de lo complicado que resulta acertar en un contexto como ese. Desgraciadamente en muchos casos, los usuarios y los clientes no atienden a razones y dan lugar a una gestión orientada a la agenda (a intentar mantener un equilibrio en el triángulo de hierro) en la que se sufrirá mucho si la desviación entre lo estimado y la realidad es sensible y que fracasará seguro si se superan los umbrales del Death March Project.

¿Por qué es importante tener en cuenta que estimar en esas condiciones es una batalla perdida? Pues precisamente para considerar la estimación como una referencia pero no como una losa que llevar a la espalda durante todo el proyecto, es decir, no se debe malgastar el presupuesto pero se debería ser flexible en su gestión y tener la mente abierta a la necesidad de contar con más presupuesto en el caso de que sea necesario.

Las estimaciones irán mejorando conforme se vaya avanzando en el conocimiento del producto y el equipo de trabajo se vaya familiarizando con el entorno tecnológico y el negocio. También se reducirá el margen de error si las historias de usuario o funcionalidades a desarrollar no son de gran tamaño.

Aún así se seguirá fallando y será necesario gestionar esas desviaciones, sobre todo en lo que al cumplimiento de los compromisos de la iteración se refiere, ya que en este caso, al estar más acotada la estimación y ser mayor el conocimiento que existe, las desviaciones a nivel de esfuerzo serán poco significativas (lo suficiente para fastidiarte o ponerte muy difícil cumplir con los objetivos del sprint) pero con escaso impacto a nivel presupuestario,.

Ciclo de vida iterativo incremental de ciclos cortos, conocimiento más real

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.

La efectividad del burndown

Si no has probado a hacer un seguimiento del sprint utilizando un gráfico de burndown te recomiendo que lo hagas porque te permitirá detectar desviaciones de manera temprana y poder tomar decisiones que permitan eliminarlas o paliarlas en el caso de que se considere necesario (y se pueda).

El concepto es igualmente aplicable a ciclos más largos o a otras estrategias de desarrollo, si bien, resulta maś efectiva en contextos donde el nivel de acierto en las estimaciones sea más alto.

El burndown por otra parte no puede ser más simple, en el eje X tenemos la división en días del sprint (puedes poner día 1, día 2, etc… o fechas reales) y en el eje Y el esfuerzo restante para terminarlo, en la unidad de medida que se considere (horas, jornadas, puntos por historia, etc…). Sobre esa gráfica se dibuja una recta que representaría la proporción entre el esfuerzo restante en el proyecto con respecto al día de desarrollo suponiendo que el nivel de avance es lineal.

Lo realmente importante es la segunda línea, la que representa el avance real y que se calcula a partir del tiempo que resta para la finalización de cada tarea o historia de usuario (en función del grado de desagregación que hayas decidido utilizar). Los momentos en que esta segunda línea esta por encima de la recta representa retraso respecto a lo previsto y cuando está por debajo representa un adelanto.

Como podéis ver su mantenimiento es muy simple y los desarrolladores no tienen que realizar ningún esfuerzo significativo para ir actualizando estos datos, si bien deben ser objetivos a la hora de estimar el esfuerzo restante ya que de lo contrario se estarán tomando decisiones a partir de datos incorrectos.

Desarrollo de software. La sobreproducción

La sobreproducción se entiende como la realización de trabajo de más que no resulta necesario en estos momentos. Tiene las siguientes implicaciones:

– Esfuerzo realizado que tal vez no sirva para nada, ya que una vez que el cliente evalúe lo que realmente necesita puede modificar total o parcialmente todo el conjunto de funcionalidades de más que se han realizado.

– División de la atención entre lo realmente importante y lo que no lo es. Ese esfuerzo que se dedica a lo que no es prioritario puede afectar a la calidad, al grado de terminación y a la tasa de errores de lo que sí lo es.

– El usuario, cuando se le presenta la solución en su conjunto (en su versión actual), también pierde el enfoque pudiéndose perderse en detalles que están lejos del objetivo principal de la versión.

– Incremento de la complejidad del sistema tanto a nivel técnico (deuda técnica) como de la usabilidad.

Trabajo de más es resistencia de más para poder adaptarnos al cambio, ya que nos resta flexibilidad. A lo anterior hay que sumarle el coste que se ha invertido en desarrollar funcionalidades que lo mismo nunca se llegan a utilizar o deben ser sensiblemente reajustadas, por lo que disminuye la proporción entre valor y esfuerzo.

William Edwards Deming. El esfuerzo no es suficiente

El esfuerzo denota intención, ganas, el deseo por mejorar y querer conseguir unos objetivos y como tal se debe valorar.

Desgraciadamente, cuanto más lejos está la gestión de las trincheras, más borroso se hace el trabajo que hace cada uno y se confunde la gente que se esfuerza y los que se esfuerzan por aparentar que se esfuerzan.

El efecto desmotivador que tiene esto es devastador.

Sin embargo, al final de todo están los resultados. Deming realizó una reflexión demoledora sobre esto: «Estamos siendo arruinados por los mejores esfuerzos», viniendo a decir que los resultados son los verdaderos jueces de todo esto.

Como decía antes, el esfuerzo se debe valorar pero tarde o temprano tendrás que conseguir resultados. El esfuerzo te dará más cuerda, pero nada más.

Con esfuerzo la recompensa llegará, tal vez no ahora, tal vez no en este proyecto o en esta organización, pero llegará. Para ello, tendrás que asumir la derrota pese a haberte dejado la piel, aprender de los errores (si no es imposible), volverte a levantar y seguir intentándolo con esa actitud.

Desarrollo de software. Adaptar el trabajo a la capacidad del equipo y de las personas I

Uno de los aspectos en los que he cambiado de opinión está relacionado con la carga de trabajo que debe tener asignada ya sea un equipo o una persona. Justificaba y en mi blog hay artículos hablando de ello que cada persona tuviera tareas que en potencia superasen el 100% de su capacidad de manera que siempre (o casi siempre) hubiera la posibilidad de estar trabajando en tareas aunque uno de los proyectos o líneas de trabajo sufriera un parón.

Desde el punto de vista empresarial la situación ideal es aquella en la que la mayor parte de las horas laborables sean facturables o a través de ellas se generen oportunidades de negocio.

Sin embargo esta situación ideal llevada al mundo real presenta inconvenientes que, por supuesto, los ven solo quienes tienen una visión a ese nivel de detalle o se preocupan por analizar qué mecanismos permiten obtener la máxima productividad de las personas o de los equipos.

Es curioso, en propia persona sufría y sufro esa capacidad potencial de trabajo superior al 100%, veía y notaba sus consecuencias y, sin embargo, lo justificaba. ¿El motivo? Lo terminé considerando como algo normal y a partir de ahí trataba de dar una explicación a ese hecho.

También me pasaba con el enfoque de desarrollo clásico y les pasa a muchos que no terminan de considerar los enfoques ágiles como una alternativa.

Siempre suelo poner los mismos ejemplo. ¿Trabaja mejor tu ordenador cuándo lo tienes saturado de procesos abiertos?, ¿funciona mejor tu conexión a Internet cuando tienes prácticamente ocupado de manera continua tu ancho de banda?, ¿verdad que no?, ¿lo mismo nos pasa a nosotros?. Llega a un punto donde la saturación de trabajo bloquea a todo lo demás y el avance en esas tareas será más lento y probablemente con unos resultados de menor calidad y con una finalización de las mismas mucho más tarde de lo que sería deseable.

La saturación no es positiva, tampoco lo es la situación contraria, de ahí que el objetivo deba ser limitar la cantidad de trabajo y adaptarla a la capacidad que esa persona o equipo pueda asimilar en ese momento. El «ese momento» es importante porque la capacidad no tiene por qué ser siempre la misma y eso es inherente a las personas.

Esto no es fácil, habrá veces que nos quedemos cortos o que nos pasemos, sin embargo lo realmente importante es intentar poco a poco que la desviación con respecto a la situación ideal sea la menor posible.

Lo que hay que evitar es que la práctica general sea saturar a personas o equipos, ¿que de esta forma no se llega al límite de la capacidad potencial? Os pongo el siguiente ejemplo: cuando hacéis palomitas en el microondas siempre hay maíz que no se termina de abrir, ¿qué pasa si dejáis más tiempo el microondas para que esas pepitas terminen por abrirse? pues que se te habrán quemado las palomitas y la mayoría de las pepitas pendientes de abrirse (que no serán muchas) seguirán sin hacerlo. En este caso, la estrategia más productiva no es calentar las palomitas al 120% sino hacerlo dentro de unos márgenes apropiados aunque no se consiga que el 100% del maíz se abra.

Desarrollo de software. Antipatrón. Al servicio de Pareto

La regla del 80-20 o principio de Pareto es peligrosa si nos dejamos contagiar por el optimismo que nos trae un progreso rápido en el desarrollo del producto.

No debemos olvidar que el avance es rápido porque no es necesario que se cierren todos los detalles y porque tareas problemáticas o que no terminan de salirnos se terminan dejando para más adelante.

Cuando crees que ya tienes casi todo y te olvidas de que todavía te queda mucho trabajo por hacer, corres el riesgo de caer en este antipatrón.

¿Cuándo surge? En el momento en que se pierde la tensión por parte del equipo (o del área usuaria) y/o cuando se decide dedicar menos esfuerzo al proyecto (porque, al fin y al cabo, está casi listo).

La consecuencia suele hacer mucho daño, porque ese 20% de ejecución restante se termina eternizando, requiriendo mucho más esfuerzo y afectando a las relaciones entre desarrolladores y usuarios, ya que la frustración será cada vez más evidente y las expectativas de cliente y proveedor cada vez estarán más lejos.

Desarrollo de software. Antipatrón. Mal uso del prototipo

El prototipado puede ir desde fórmulas muy simples como dibujos realizados a mano alzada a desarrollos que tienen una cierta lógica implementada. Son muy útiles ya que permiten trabajar sobre algo material y no sobre ideas de carácter abstracto. Nunca van a poder sustituir a la funcionalidad una vez implementada en toda su extensión pero sí que permiten desarrollar con más intención.

Este antipatrón surge cuando no se hace un uso adecuado del prototipo, no se interpreta o se comunica adecuadamente su función y utilidad, pudiendo abarcar diferentes áreas:

– El responsable funcional aprueba el prototipo pero no se ha llegado a un suficiente nivel de detalle en el comportamiento, esto puede provocar que una vez implementado no se alcancen (incluso nos hayamos quedado bastante lejos) las expectativas puestas en la funcionalidad. También puede pasar que se piense que el desarrollo es más simple o más complejo que lo que realmente es.

– En entornos de negociación cerrados, en los que solo existe el contrato como objeto de debate, si se cierran términos del mismo (alcance y coste) en base a un prototipo con muchos detalles por concretar, se corre el riesgo de que las estimaciones realizadas sean fallidas y el cliente se niegue a replantear el alcance del proyecto alegando que se conocía perfectamente el alcance ya que había un prototipo que respondía a todas las dudas.

– Los clientes también incurren en un riesgo importante si consideran un prototipo como la base fundamental para realizar una valoración del alcance, sin haber evaluado si el conocimiento que proporciona es suficiente como para hacerla reduciendo la probabilidad de que haya desviaciones sensibles.

En los dos casos anteriores, el problema lo tenemos por un lado en la falta de flexibilidad a la hora de abordar cambios en el alcance y/o de aportar más recursos económicos al proyecto (y esto ocurre trabajando con o sin prototipos) y por considerar los prototipos como una versión real pero de juguete del producto final, algo que no será así porque a lo largo del proceso de desarrollo los usuarios cambiarán de prioridades, descubrirán nuevas funcionalidades a implementar, etc…, es más, incluso en el caso de que el prototipo sea de una funcionalidad, la implementación real sacará a la luz problemas: de carácter tecnológico, de integración, funcional, etc…, muchos de los cuales son complicados de prever cuando se está trabajando con el prototipo.

Es decir, el prototipo es un facilitador para desarrollar con intención pero nadie (cliente y proveedor) debe tomarlo como la verdad absoluta y que en base a ellos se tomen decisiones inamovibles.

– Si se dedica mucho esfuerzo al prototipo es posible que se caiga en la tentación de convertirlo en el producto definitivo. Esto supone un riesgo importante porque lo más posible es que su desarrollo se haya realizado sin tener en cuenta aspectos relacionados con la calidad y mantenibilidad del software, lo que después puede dar lugar a importante costes de evolución del producto, falta de robustez, efectos colaterales en cada versión, etc…

Desarrollo de software. Antipatrón. Se resuelve con más dinero

Contar con presupuesto te permite el suficiente margen de maniobra para solucionar los posibles problemas que puede tener un sistema de información. Sin embargo, el dinero por sí mismo no arregla nada si las decisiones que se toman son incorrectas, si no se desarrolla con intención o no se resuelven los problemas que existen de raíz.

Puedes echar decenas y decenas de miles de euros a un sistema y no incrementar proporcionalmente su valor.

Este antipatrón surge cuando se cuenta con un importante presupuesto que bien utilizado podría mejorar el producto pero que en lugar de centrarse en los problemas existentes en el sistema, se invierte en un crecimiento desproporcionado y/o difícil de controlar del sistema que mezcla la resolución de esos problemas con una ampliación funcional generalmente de aspectos secundarios.

En esta situación se divide el enfoque y el presupuesto entre lo principal y lo accesorio poniendo ambos al mismo nivel, a la que vez que se dota de una mayor complejidad al sistema, generándose resistencias que afectan al directamente al esfuerzo (y coste) necesario para desarrollar. Por tanto, el presupuesto para arreglar los verdaderos problemas del sistema queda debilitado a la vez que la deuda técnica va creciendo y en consecuencia los costes de desarrollo.

Llegado a un extremo (y a veces no es necesario escorarse tanto) nos habremos «comido» el presupuesto y los problemas (o la mayoría de ellos) seguirán ahí, y lo que es todavía peor, con otros nuevos que posiblemente se han añadido, con un producto más complejo de evolucionar y con una confianza muy erosionada por parte del cliente o del área usuaria (independientemente de que ellos hayan tenido mucho o poco que ver en la priorización de las tareas y en la estrategia utilizada).