archivo

Archivo de la etiqueta: estimación

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.

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…

Forzar a que un equipo de proyecto admita más trabajo que el que soporta su capacidad en un momento dado del tiempo no suele funcionar. Tal vez se desarrollen las funcionalidades pretendidas pero es más que probable que el grado de acabado de las mismas no sea bueno, de tal forma que la calidad del resultado final se resentirá: más bugs, deficiencias funcionales y funcionalidades que no están totalmente rematadas?.

Y no solo eso, será complicado que se respeten los plazos fijados, así como los compromisos adquiridos. El triángulo de hierro es poco maleable y si mueves uno de sus vértices el resto se resiente, esa flexibilidad adicional te la da el esfuerzo adicional del equipo de proyecto que si bien puede salvar la situación durante un tiempo no podrá sostener un nivel de presión y de overtime de manera sostenida sin que afecte a su propia productividad y a la calidad de los trabajos. Esto es un hecho y seguro que lo has vivido en primera persona.

Se llega a este antipatrón, por un lado por el deseo de avanzar más rápido y en muchos casos por la desconfianza en las estimaciones que se realizan. La confianza requiere un tiempo cimentarla, mientras tanto, pide explicaciones si no terminas de entender alguna de las estimaciones y admítela salvo que entiendas que la desviación respecto a lo que debería ser es flagrante (si tienes dudas, dala también por válida), al final, pasado un tiempo, el propio proyecto irá poniendo las cosas en su sitio.

¿Por qué dejar que sea el equipo quién estime? Pues porque es el equipo al que se le exige el cumplimiento de los compromisos. Puedes exigir si ellos establecen sus límites, si los pones tú no solo te arriesgas a los inconvenientes indicados en párrafos anteriores sino que estás dejando la puerta abierta a que te pongan la excusa de que las condiciones que has planteado eran imposibles.

A la hora de realizar una estimación existen dos problemas principales, primero la ingerencia de los gestores de proyecto y de los responsables funcionales que normalmente pretenden acomodar los plazos a sus necesidades (que lo mismo son las necesidades reales del proyecto) y segundo cuando el equipo de proyecto pierde la objetividad y opta por actitudes demasiado optimistas o pesimistas (defensivas) al margen del contexto real del proyecto.

Si la estimación no se ajusta a los plazos deseables en el proyecto y no es posible mejorar esos tiempos metiendo más personal, intentando aplicar algunas estrategias que puedan mejorar la productividad o cualquier otra posible solución, lo mejor es negociar bien otros plazos o una reducción de las expectativas del sistema para ese marco temporal.

Es cierto que, en algunos casos (menos de los que creemos y admitimos), los plazos son los plazos y no tendremos más remedio que convivir con ellos, en esos casos hay que buscar fórmulas para intentar llegar a ellos, sin renunciar a eliminar toda funcionalidad que no sea absolutamente necesaria para conseguir los objetivos (aunque se tenga que desarrollar más tarde).

Todos, y me incluyo, nos sentimos tentados a intervenir en las estimaciones, pero es algo que tenemos que intentar evitar, salvo que sea algo tan evidente que nos haga actuar (si no entendemos algo, tenemos que preguntar, si vemos que algo es disparatado, hay que pedir explicaciones y si procede, rechazar la estimación).

Para Jeff Sutherland: “Las personas que están realizando el trabajo son los que siempre deben estimar el trabajo” y la experiencia me ha demostrado que así debe ser.

Una de las citas más conocidas de Horning es la siguiente: “Nada es tan simple como esperamos que sea”.

¿Es este un enfoque pesimista que aplicar al desarrollo de software o refleja una realidad?, ¿según ese planteamiento deberíamos optar a la hora de hacer una estimación o una planificación por la opción más conservadora?.

La respuesta a estas preguntas es compleja.

Es cierto que el desarrollo de software está sometido a la incertidumbre y que el grado de incertidumbre no es siempre el mismo, ya que dependerá de muchas variables: tipo de cliente, el cliente en sí, la complejidad del proyecto, la tecnología, etc…

En base a esto tengo claro que una estimación o una planificación tiene que estar acorde a ese contexto. Puedes hacerlas teniendo en cuenta la existencia de circunstancias ideales, pero después debes aplicar un factor corrector que adapte las mismas a la realidad del contexto en el que se va a trabajar, tú lo agradecerás, pero el cliente a la larga también (aunque eso implique unas estimaciones en coste o planificación superiores a las que tal vez tenía pensado).