archivo

Archivo de la etiqueta: estimación

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 …

En potencia todo, salvo el papel en blanco (y seguro que conocemos casos donde se han realizado estimaciones con un nivel de conocimiento del trabajo a realizar que se aproxima muy mucho a ese papel en blanco), es estimable, sin embargo, lo que queremos son estimaciones que se ajusten lo máximo posible a la realidad y para ello se requiere que cada historia de usuario esté lo suficientemente desarrollada como para conseguirlo.

Vuelvo a insistir en lo que comenté en el artículo de ayer, suficientemente desarrollada no es lo mismo que absolutamente detallada y/o llena de formalismos, sino que se adapte a lo que el proyecto (y su contexto actual) necesite.

Otra cosa es que nos equivoquemos en la estimación, cosa que sucederá sobre todo en los primeros sprints y/o hasta que se tenga dominada la tecnología y entorno sobre el que se va a desarrollar.

¿Para que sirven entonces las reuniones de planificación de sprint? Para terminar de perfilar el sprint. ¿No se hacen todas las actividades necesarias para poder estimar? La base son las historias de usuario y aunque puedas invitar al product owner a participar y aclarar dudas con él, cuando el proyecto se encuentra en una fase inicial o se incorporan funcionalidades con una cierta complejidad, no da tiempo en una reunión de planificación de sprint a tener lo suficientemente claro el alcance de la tarea por lo que la estimación corre más riesgos a lo que hay que sumar las consultas que de forma más que probable habrá que hacerle al product owner durante el sprint y que podrían bloquear determinados trabajos si no se han resuelto antes de que esas tareas se lleven a cabo.

Un error muy frecuente que nos encontramos con las estimaciones lo tenemos en pensar que se van a dar condiciones ideales: no se van a sufrir interrupciones inesperadas, no vamos a sufrir contratiempos técnicos y la capacidad calculada para cada persona no va a sufrir cambios (en el momento en que una persona por el motivo que sea no puede ir a trabajar un día, rompe ya los esquemas).

Si a eso le sumamos lo difícil que resulta acertar, estamos sometiendo cada sprint a una presión que los desarrolladores no van a poder aguantar porque la realidad será que para cumplir los compromisos se tendrá que incrementar la capacidad de todos y eso se traduce en overtime. El otro camino es dejar historias de usuario comprometidas para más adelante (sacarlas de la pila de sprint). Ambas soluciones son malas. La primera porque no es sostenible, ya que incluso los equipos más motivados no pueden aguantar un ritmo por encima de sus capacidades físicas durante un tiempo prolongado y la segunda porque perdemos predecibilidad y fiabilidad.

Ten en cuenta en que fase del proyecto te encuentras, no tienes el mismo conocimiento al principio que tras la sexta o séptima iteración y ten en cuenta que no se puede asegurar capacidades del 100% de nadie. Se puede estar asignado al proyecto un 100% pero prever una capacidad para el sprint inferior a esa, si después resulta que no han existido contratiempos y puede estar al 100% pues mejor, ya que así aprovechará para ayudar a otros compañeros, para ayudar a resolver contingencias que hayan podido ocurrir en la iteración, para refactorizar, etc…).

El equipo recibe muchas presiones (y quién esté libre de pecado que tire la primera piedra) para que asuma el mayor número de historias de usuario posible. Se tiene que aprender a decir que no y a respetar las condiciones para que un conjunto de personas puedan cumplir sus compromisos sin tener que reventarse.

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

Estimar es difícil y resulta muy complejo cuando nuestro desconocimiento del sistema es importante.

Por eso, hacer un presupuesto inicial que condicione al proyecto y al producto y considerarlo como algo inamovible es temerario porque la probabilidad de un error sensible en la estimación es importante salvo que se haya optado por la opción de sobreestimar los costes con el objeto de tener un colchón al que acudir cuando nos encontremos con contingencias.

Veo necesario estimar porque es conveniente tener una referencia y tan necesario como eso es hacer un seguimiento del valor que vamos ganando con el producto con el objeto de ver que la inversión realizada va obteniendo sus resultados, a la par de que se tenga conciencia de que el desarrollo de software es un proceso evolutivo y que a veces un paso pequeño hacia atrás supone después un producto de mayor calidad y valor.

Si planteas un proyecto llave en mano con un alcance difuso y un presupuesto fijo, estás sentando las bases de un proyecto que producirá mucho desgaste entre las partes y donde el principal perjudicado de todo será el producto final que se obtiene.

Lo importante es el valor final del producto y que sea acorde con la inversión realizada dentro del contexto en el que se ha desarrollado el proyecto. Que sea acorde con la inversión y el contexto quiere decir que el retorno de la misma sea asumible teniendo en cuenta las condiciones en que se ha desarrollado el proyecto porque no es lo mismo encontrarnos con múltiples problemas y con gran incertidumbre que unas condiciones más favorables.

Si se está en el día a día del proyecto y no en la distancia se sabrá si efectivamente el incremento de la inversión inicialmente prevista está justificado. El problema es que quienes toman estas decisiones suelen estar lejos y no estar debidamente informados.

Conforme se va avanzando en el proyecto, se co.noce mejor sus casuísticas, la tecnología y si se acota suficientemente el trabajo, el nivel de acierto en las estimaciones crece considerablemente, por eso hay que tener paciencia al principio si hay sprints que no cumplen los objetivos marcados

Uno de los problemas más frecuentes que nos solemos encontrar cuando se realiza una estimación es que en la misma no se tiene en cuenta el tiempo que se necesita para hacer un testing de la funcionalidad implementada, que puede ir desde las pruebas unitarias automatizadas hasta pruebas que se tienen que realizar de manera manual.

Como no se suele tener en cuenta, la estimación de la funcionalidad parte ya con un valor negativo que al final tiene su repercusión económica y/o en la calidad del producto ya que de algún sitio se suele recortar para tratar de cumplir los plazos o para equilibrar el presupuesto.

¿Por qué no se tiene en cuenta? Pues porque la realización de un testing adecuado no se encuentra en la primera línea de pensamiento de quienes realizan la estimación, ya sea el propio equipo de desarrollo o un gestor apoyado o no en ese equipo. ¿Por qué? Porque siempre se piensa en construir, en avanzar rápido, pero se piensa mucho menos en verificar que ese avance es real.

Por tanto, lo que se tiene en mente es el tiempo que se tarda en desarrollar, que puede incluir o no, algunas pruebas básicas, pero no se tiene en cuenta un testing más riguroso, entendiéndose por riguroso, lo que la funcionalidad o el producto necesita realmente.

¿Cuándo queda para que el proyecto termine?.

Interesante visión la que plantea la Ley de Hartree: “El tiempo desde ahora hasta la finalización del proyecto tiende a ser constante”.

Sería más exacto si en lugar de hablar de proyecto hablásemos de ciclo de vida del producto software, ya que se entiende al proyecto como un conjunto de actividades que se realizan en el tiempo para conseguir unos resultados (mucho más cortoplacista y concreta de lo que sería el ciclo de vida).

Si bien, nos encontramos pese a todo, con proyectos que prácticamente no parecen tener fin, ya sea porque los objetivos (para los cuales se realizan esas actividades) son demasiado abiertos o ambiguos y/o porque la ejecución de las trabajos por parte del equipo de desarrollo es deficiente, teniéndose que volver a realizar de nuevo o parcialmente determinadas funcionalidades, por una deuda técnica elevada, lo que hace que la mantenibilidad o evolución del sistema requiera más tiempo y esfuerzo, etc…

Ya sea tomando como referencia los proyectos o el ciclo de vida, lo que sí resulta interesante de esta ley son los mensajes que podemos interpretar a partir de ella:

– Los proyectos de desarrollo de software suelen tener objetivos demasiado abiertos o ambiguos.
– Las estimaciones son menos precisas cuanto más cerca nos encontremos del inicio del proyecto.
– La deuda técnica de manera paulatina hace más complejo el proceso de desarrollo de software.
– Un producto software de manera inherente tiende a ser evolucionado (ver leyes de Lehman).

El triángulo de hierro: alcance, coste y plazos, determina unas condiciones de partida para el proyecto basadas en la mayoría de los casos en hipótesis realizadas con un gran desconocimiento sobre el sistema que se va a realizar, estando además, condicionadas por el hecho de que el área usuaria va a tratar de que se abarque el mayor alcance, con el menor coste posible.

Después el proyecto evoluciona y nos iremos dando cuenta de cómo la estimación inicial ha fallado (y por mucho) y el alcance varía porque conforme el usuario vea materializada sus ideas, le surgirán otras nuevas, se dará cuenta de que determinadas funcionalidades ya implementadas son mejorables y que también se ha equivocado en otras, provocando que se tengan que modificar sensiblemente o reconstruirlas.

Y no solo eso, habrá riesgos que impacten y que supongan una resistencia al desarrollo, cambios de rumbo en el proyecto, etc… y todos ellos provocarán que sea necesario modificar alguno de los vertices del triángulo de hierro porque seguir creyendo en su foto inicial es engañarnos.

¿Cómo poder actuar contra esto? Trabajando sobre el alcance y gestionando las expectativas. Estas dos variables se tienen que modular a la realidad del proyecto y subordinarse al estado económico real en cada momento (costes) y a los plazos que se definan.

De esta forma podemos trabajar sobre unas condiciones de partida de tiempo y presupuesto y haciendo una estimación del alcance que se pretende.

El cono de incertidumbre de Steve McConnell viene a expresar algo que ya sabemos y es que efectivamente se acierta más cuanto más conocimiento tenemos del proyecto, su contexto, sus problemas, de las personas que participan, etc…

Ese conocimiento se adquiere conforme se va desarrollando el proyecto, con el proceso de definición de las historias de usuario, su construcción, el feedback y las retrospectivas. Cualquier otra actividad de carácter teórico puede producir mejores estimaciones, de base no lo niego, pero siempre limitada y siempre menor que la que se adquiere con la experiencia.

Entonces, ¿de qué valen las estimaciones que se realizan en la definición del proyecto y que tienen como objeto asignarle un presupuesto? Para definir un punto de partida e interesa que el mismo no esté muy equivocado, si bien lo realmente importante es la actitud que cliente (sobre todo el cliente) y el proveedor tienen sobre esas condiciones de partida. Si la orientación es al contrato, a su lectura literal, procura acertar (al cliente porque la satisfacción de sus expectativas respecto al producto final dependerá del acierto y al proveedor porque tendrá que prepararse a sufrir y perder mucho dinero).

En cualquier caso es conveniente dedicar tiempo a hacer la mejor estimación posible con la materia prima disponible, teniendo en cuenta que hay que saber cuándo parar porque si se pretende llegar a un conocimiento muy detallado, además del tiempo que se requiere para ello, se estará suponiendo que después la línea de desarrollo va a ir en esa dirección y lo mismo (lo más probable) se van produciendo cambios conforme el usuario vaya teniendo más claro qué es lo que quiere.

Las estimaciones iniciales no van a ser buenas, las finales estarán más ajustadas y no solo es cuestión de conocimiento técnico y funcional, sino que nos habremos dado cuenta de varios errores que se cometen sistemáticamente con las estimaciones (y que no sería de extrañar que los volvamos a repetir en el siguiente proyecto): considerar condiciones ideales, dejarse llevar por el optimismo, ser demasiado permeable a las presiones externas para admitir más capacidad o para producir estimaciones sin un conocimiento más en detalle de la historia de usuario o del requisito, exceso de ambición, etc…

Volviendo al cono de incertidumbre, hay que tener en cuenta que Steve McConnell lo planteó sobre una secuencia de fases que bien podrían ajustarse a un ciclo de vida clásico o en cascada, si bien podría ser extrapolable, al menos conceptualmente a otros enfoques de desarrollo de software.

McConnell señala que las estimaciones iniciales con un conocimiento insuficiente sobre la visión del producto (visión abstracta del sistema a desarrollar) se suelen desviar hasta cuatro veces por encima o por debajo de lo que viene a ser el esfuerzo real. En el momento en que se avanza más en la definición de la visión del producto, la desviación se ajusta hasta dos veces por encima o por debajo. Vuelve a bajar en la definición de requisitos (un 50%) y así sucesivamente hasta la entrega.

Es muy interesante tener en cuenta a la hora de realizar cualquier tipo de estimación lo que enuncia la Ley de Hofstadter (Douglas Hofstadter): “Siempre se tarda más de lo esperado, incluso cuando tienes en cuenta la Ley de Hofstadter”.

Las estimaciones suelen ser demasiado optimistas incluso en aquellos casos en los que no se cuenta con suficiente conocimiento como para hacerla y/o en aquellos casos donde el tamaño de la historia de usuario, requisito o tarea que se estima es demasiado grande.

Además de la posible falta de información, de la incertidumbre de la tarea o de su complejidad, uno de los principales problemas suele ser también que se suele estimar considerando situaciones ideales: que no nos vamos a encontrar con ningún problema en esta o en otra que impliquen un mayor esfuerzo que el esperado, que la capacidad de trabajo por parte del equipo va a estar disponible tal y como estaba previsto, etc…

¿Se debe creer en las estimaciones? La respuesta es que depende. Si es sobre un conjunto de trabajo moderado, la estimación solo debe ser considerada como una referencia, pero nada más. Tienes la opción de creerla y en base a ella gestionar el triángulo de hierro, más adelante te darás cuenta de que tendrás que renunciar a uno o más de los vértices del mismo: alcance, coste o plazos y/o reducir la calidad final del producto.

Pero incluso en tareas pequeñas, la estimación puede fallar de manera sensible y ponerte en un serio problema a la hora de satisfacer los compromisos del sprint. Una mala estimación siempre hace daño.

Debemos partir de la base de que no es fácil estimar, pero resulta necesario si se quieren definir unos compromisos en un margen de tiempo determinado. Esto hace que se deba mejorar de manera continua los procesos de estimación: reduciendo el alcance de lo que se estima, implicando a maś personas en las mismas, principalmente a los desarrolladores, ya que van a ser ellos los que se enfrentan después a su realización.