archivo

Archivo de la etiqueta: estimació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).

¿Sabrías de una manera objetiva indicarme la capacidad de producción de una persona de tu equipo o de algunos de tus equipos en base a algún tipo de unidad de medida (como por ejemplo, puntos de historia de usuario)?

Si no lo sabes, ¿no entiendes que existe mucho riesgo de incumplimiento de las tareas planificadas?.

Un gestor que no dirija los equipos a años luz (son menos de los que pensamos) sabe quién es más productivo y menos, tanto a nivel individual como en equipos de trabajo y considera eso como suficiente a la hora de gestionar y planificar, pero, ¿realmente es suficiente? A tenor de lo que se suele fallar en las estimaciones, parece que no.

¿Es fácil obtener una métrica objetiva?. Si la métrica se refiere a un proyecto concreto existen estrategias que permitirían obtener su valor, como por ejemplo, media por iteración o valor de la última iteración, si nos referimos en términos generales es más complicado ya que habría que armonizar los mecanismos de medición, lo que obligaría a tener como objetivo a nivel de organización la posibilidad de conocer con un umbral de error concreto la capacidad de producción individual y colectiva (hay personas que funcionan muy bien trabajando en equipo y otras que no, a lo que hay que sumar también que la capacidad de producción variará también de las personas con las que trabajes).

¿Teniendo una métrica objetiva me asegura no equivocarme? Si fuera tan sencillo todo sería maravilloso ya que si un proyecto fracasa será por otros factores no por el hecho de haber estimado y planificado de forma incorrecta. La realidad es que habría que tener un proceso muy maduro en la organización para reducir el umbral de riesgo, sin embargo a nivel de proyecto, si se divide en piezas más pequeñas y se aplica un enfoque iterativo incremental, seremos capaces a las pocas iteraciones de conocer la capacidad real del equipo.

Que sea algo difícil o si queréis en determinados contextos organizativos casi una quimera, no quiere decir que debamos renunciar a medir y a obtener información que permita conocer la capacidad de producción y no solo porque permita planificar mejor, sino porque a nivel organizativo, conocer si se mejora o se empeora la capacidad de producción global puede resultar muy importante.

Solo en circunstancias ideales un proyecto de desarrollo de software no está sometido a incertidumbre. Y en muy contadas ocasiones, en proyectos de pequeño tamaño y/o con procesos muy estables se puede producir algo parecido a esas circunstancias ideales.

Por eso las técnicas de estimación tienen un grave problema para determinar el coste final del software, si bien es importante realizar la mejor estimación posible con el conocimiento disponible ya que un proyecto debe contar con un presupuesto, independientemente de que posteriormente se pueda ampliar o no (si hay circunstancias que lo justifican).

Pero, ¿tantas variables del proyecto pueden cambiar a lo largo del proceso de desarrollo?.

Scott L. Bain es un desarrollador, consultor, conferenciante y autor especializado en metodologías ágiles y TDD que cuenta con más de treinta y cinco años de experiencia en este negocio y responde de manera adecuada a esa cuestión en su siguiente reflexión: “La inutilidad de la lucha contra el cambio: Requisitos, tecnologías, equipos, las prioridades, las empresas, el uso, los usuarios, todo cambiará. Hay cosas que no se pueden saber hasta que se nos presentan. Date por vencido. El cambio es inevitable. Nuestro proceso debe ser un proceso, por lo tanto, de cambio.”

La incertidumbre inherente a los proyectos de desarrollo de software requiere que el proceso de desarrollo pueda responder de manera ágil y flexible ante ella. De lo contrario estamos abocados a desarrollos que no se adaptarán a las expectativas del usuario o que para acercarse a las mismas requieran un sobrecoste importante, así como un incumplimiento de los plazos.

¿Qué estoy exagerando? Hace poco os puse los datos publicados por el Cutter Consortium, en el que quedaba patente que la crisis del software sigue sin superarse.

Barry Boehm, uno de los mayores expertos a nivel mundial en estimación de costes software y en la aplicación de estrategias de gestión económica en los proyectos de desarrollo de software, lo manifiesta de manera patente en la siguiente reflexión (traducción libre): “Será importante tener en cuenta a la hora de organizar proyectos en el futuro contar con la agilidad suficiente como para ser capaz de adaptarse a la aparición de nuevas fuentes adicionales de cambios imprevisibles”.

Cuando se va a afrontar un proyecto de desarrollo de software es necesario realizar una estimación del coste necesario para su desarrollo basándonos para ello en el alcance conocido del proyecto y de todas aquellas variables que podamos anticipar (tipo de cliente, tipo de usuarios, experiencia en otros trabajos anteriores con ese cliente, con esos usuarios, con esa tecnología, con ese tipo de proceso de negocio, la metodología a aplicar, los umbrales de calidad esperados, etc…).

Cuantos más datos conozcamos mejor, pero en la mayoría de los casos estaremos lejos de saber lo suficiente como para que la incertidumbre entre lo estimado y lo real sea residual.

En cualquier caso es necesario estimar (y analizar riesgos) porque te determina un marco y lo mismo se determina que lo más recomendable es no seguir con el proyecto. Pocos proyectos conozco, aunque los hay, donde el dinero no es un problema.

Ahora bien, la estimación debe tener en cuenta un aspecto esencial y es que conforme vayamos avanzando en el proceso de desarrollo se tendrán que ir realizando ajustes sobre el producto, fruto del feedback del usuario y sobre el alcance final, de ahí la necesidad de priorizar los requisitos del usuario, ya que de quedarnos sin presupuesto, lo más importante debe estar desarrollado y ajustado a las expectativas del usuario.

Otro aspecto a valorar es que además de esa estimación inicial, lo más razonable es realizar estimaciones parciales sobre cada incremento del software (enfocándolo a un esquema iterativo incremental) y cada una de esas valoraciones será cada vez más exacta, ya que el conocimiento del sistema y su contexto será cada vez mayor, además de definirse entregas con un tamaño moderado para adaptarse a unos ciclos de evolución del sistema cortos (un mes, dos meses, etc…).

Todo lo comentado en este artículo lo resume perfectamente Jim Highsmith en la siguiente reflexión: “Convertirse en ágil significa aceptar la incertidumbre sobre el futuro como una forma de tratar con el futuro. Cualquier esfuerzo de un proyecto de desarrollo debería ser el resultado de un equilibrio entre la anticipación (planificación sobre la base de lo que sabemos ahora) y adaptación (en respuesta a lo que aprendemos con el tiempo)”.

Cuanto mayor sea el número e importancia de variables conocidas para poder realizar una estimación de costes y tiempo menos desviación existirá con respecto a los datos reales.

Esta máxima podemos considerarla como válida para cualquier tipo de proyecto en cualquier ámbito.

Sin embargo hay que tener en cuenta que nunca se tendrá suficiente conocimiento para realizar una estimación sin riesgo (salvo que la hagas a posteriori, en cuyo caso no estaríamos hablando de una estimación sino de un conteo de horas) y que siempre te tiene que partir de una estimación inicial para realizar la primera tarea del proyecto en la cual no se dispone del mismo conocimiento que cuando ya se tenga más maduro el contacto con el proyecto y su contexto.

Yo soy partidario de la realización de estimaciones parciales, ya que supone menos riesgos para todos, ahora bien, hay que entender que puede darse el caso de que nos pidan una fecha objetivo para tener listas ciertas funcionalidades del proyecto y también es probable que nos soliciten una previsión de esfuerzo para el proyecto, ya que la inversión requiere ser prevista a nivel de gestión en la organización y en ambos casos la posibilidad de desviación es evidente, la clave en ambos casos es dar la estimación más objetiva posible con los datos actualmente disponibles, guste o no guste su valor a quien la espera.

Si no le gusta pedirá explicaciones y se le deberá comentar que eso es lo que se necesita para desarrollar el software y que se puede acortar alcance para ajustarlo a lo que quiere y que en el caso de no hacerlo se arriesga a que el producto no tenga el umbral de calidad esperado porque las cosas valen lo que valen.

La planificación del proyecto supone la base para la realización del mismo, por lo que es habitual que la mayor parte de las tareas que lo componen se realicen de una manera más o menos formal: Determinar un alcance inicial (aunque sea a alto nivel), hacer un análisis de riesgos, hacer una estimación del coste/esfuerzo, de los recursos en materia de personal (¿quiénes van a participar?, ¿cuándo?, ¿con qué dedicación?, ¿necesitan algún tipo de formación antes de enfrentarse al proyecto?) y materiales (software y hardware), definir el ciclo de vida/metodología a utilizar, proponer un cronograma, definir los hitos, las personas que los apruebas, etc…

Buena parte de la suerte del proyecto se juega al principio, una mala negociación, una mala estimación, en general, una mala planificación puede condicionar negativamente el proyecto, hasta tal punto de que si no hay posibilidad de enmendar la situación a tiempo puede afectar incluso a su viabilidad.

La incorporación de esta tarea y darle un grado de formalidad en los proyectos software, resulta por tanto, lógica en el nivel 2 de CMMI.

Es decir, a partir de ahora y en cada proyecto, es necesario que esas tareas preparatorias del proyecto se realicen, siguiendo un proceso, una estrategia, un plan. Se entiende que de esta manera las decisiones que se tomen se harán siguiendo una lógica que vendrá definida por las distintas soluciones y técnicas que se utilicen para realizar las diferentes actividades del mismo (estimación de proyecto, análisis de riesgos, etc…), si bien, la existencia de un proceso de guíe a la definición del plan de proyecto no asegura nada si la ejecución no es buena (ya sea por un incorrecto desempeño del que la realiza y/o porque la información que tiene para realizar la planificación no es adecuada o válida).

Se entiende que este área de proceso debería tomar como partida los requisitos del área de proceso “Gestión de requisitos”, sin embargo esto no va a ser siempre posible. Es cierto que es deseable conocer el mayor detalle posible antes de realizar por ejemplo una estimación de costes, pero también lo es que no siempre se van dar las condiciones para poder realizar esta tarea ya que la contratación del servicio de desarrollo de software se puede realizar en base a un pliego de condiciones técnicas o incluir dentro del mismo las tareas de análisis.

A lo anterior hay que sumar la volatilidad de los requisitos, ya que lo mismo la estimación se ha realizado teniendo en cuenta unos, pero después cambian las condiciones y se rompen los esquemas.

Dependerá de la organización tomar parte o no en un proyecto en función del grado de incertidumbre existente, de las características del cliente y de la propia cultura y experiencia de la misma.

Desde mi punto de vista la planificación inicial del proyecto es muy importante, independientemente del grado de incertidumbre y es importante que todas las partes entiendan que se trata de un plan inicial que se deberá ir ajustando a la evolución real del proyecto.