archivo

Archivo de la etiqueta: estimación

¿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.

En todas las etapas de un proyecto de desarrollo de software se pueden tomar decisiones erróneas, una mala ejecución de los trabajos, baja productividad, falta de compromiso, desencuentros entre el cliente, el proveedor, los usuarios, etc… y en todas se produce un impacto en el proyecto que puede ser más o menos grave en función de su intensidad y del momento en que se producen.

Sin embargo hay dos etapas decisivas y que tienen un gran peso en todo lo que va a venir después: la etapa de negociación del proyecto y las primeras fases del análisis que es donde se acota el objeto final de trabajo.

Si la negociación no es buena, se aceptan proyectos por debajo de su precio de mercado, prometiendo lo imposible o se hace una estimación y planificación errónea, está situando al posterior proceso de desarrollo en un contexto difícilmente salvable o incluso en un Death March Project.

No importan tus procesos, no importa que tengas los mejores, no importa que el cliente se vuelque contigo, si el error de partida es grave, remontarlo costará mucho trabajo (cuando se pueda).

Después se puede volver a negociar, pero dependerá de muchos factores conseguir éxito en la misma, sobre todo si el error es tuyo y si desde el primer momento existe desgaste con el cliente.

También resulta muy importante la fase inicial de enfoque del proyecto, determinar su alcance, por lo menos a corto y medio plazo. Una mala elección en lo que es prioritario y en lo que no lo es, será negativo para el cliente, pero también para el que realiza los servicios de desarrollo de software, sobre todo si se trabaja con presupuestos cerrados en proyectos con objetivos abiertos.