Estimación de Costos de Software en Gestión de Proyectos Ágiles
Introducción
Una de las cosas más difíciles en el desarrollo de software es determinar el tiempo y esfuerzo que tomará entregar un nuevo proyecto de software. ¿Debería ser tan difícil? La respuesta no es tan sencilla.
La estimación de costos de software es esencialmente difícil, y los seres humanos son bastante malos prediciendo resultados absolutos. No hay dos proyectos iguales; cada uno es único en cuanto a lo que se propone alcanzar, y en la cantidad de parámetros que forman su existencia. A menudo, lo que parece ser un problema simple en la superficie es mucho más difícil o técnicamente problemático al implementarse en la realidad. Y sin duda, habrán “desconocidos” en el proyecto que solo serán identificados cuando salgan a flote.
Adicionalmente, dos personas no son iguales, ya sea que eres un cliente, desarrollador, o usuario. Venimos programados con nuestros propios conocimientos, experiencias, valores, expectativas, nuestra actitud a tomar riesgos, y habilidad de adaptarse.
Escribir un software de buena calidad es el pan y la mantequilla para ingenieros senior; crear productos de software extraordinarios puede ser una tarea aún más difícil para todos los involucrados.
Tradicionalmente, el uso de prácticas no-Ágil, proyectos de software han buscado arreglar la funcionalidad o el alcance, y dejan el tiempo y el costo como variables. Esto causa problemas:
1. ¿Cómo sabes que la funcionalidad en la que te concentras desde el principio del proyecto es en realidad la que mejor servirá para tu negocio o clientes? Más a menudo que nunca, la funcionalidad o el alcance cambiará, por eso es que solemos escuchar sobre la “corrupción del alcance”, lo cual es el resultado de necesidades deseadas siendo identificadas a través del ciclo de vida de un proyecto, y siendo determinadas de acuerdo a lo necesario u obligatorio.
2. Cuando el costo se convierte en una variable perdemos el control sobre el retorno de la inversión (ROI) que intentamos alcanzar. El incremento del costo es a menudo el producto de riesgos no identificados o requisitos cambiantes, lo cual significa que tenemos que añadir miembros al equipo para hacer más trabajo en el mismo rango de tiempo, o dejar miembros de equipo por más tiempo. Ninguna de las dos es deseable.
3. Cuando el tiempo es una variable, perdemos control sobre la posición en nuestro mercado. Quizás perdamos un plazo de entrega importante o los competidores sacan su producto antes que nosotros, perdiendo de esta manera cualquier ventaja competitiva que nuestro producto pueda tener.
Existen diferentes resultado a las variables de tiempo y costo, las cuales son a menudo poco deseables y negativas.
Por supuesto, muchos clientes y organizaciones buscan solucionar los tres componentes de este “triángulo mágico”. Desafortunadamente, es casi imposible lograrlo de forma realista. Hay demasiados elementos que conspirar para alterar este ideal, lo cual termina en productos que no cumplen con la necesidad, toman demasiado para beneficiar a los clientes o los costos son muy altos para darse cuenta de los valores del negocio.
Vale la pena recordar que siempre puedes agregar más alcance en el futuro. Tal vez comenzaste a tener ingresos, has incrementado la cantidad de usuarios y reducido los costos. De cualquier forma, es mucho más fácil pedir más dinero y tiempo si ya has demostrado un beneficio o mejora y estas entregando el valor del negocio.
1. Alcance inicial de alto nivel
Al comienzo de un proyecto, se conoce poco acerca de sus posibles resultados. Es una locura imaginar desde el principio qué características posiblemente quieran el cliente y los usuarios, por lo que empezamos con un gráfico del proyecto y un conjunto de alto nivel de las características “épicas” que guiarán la dirección del proyecto, basándose en una visión y objetivos concisos.
a. Ajuste de Visión y Objetivos - ¿Qué necesitamos construir? ¿Qué necesitamos lograr y cuáles son tus objetivos de negocio? Entender estas preguntas nos permite establecer la escala del proyecto. ¿Necesitas un prototipo para probar un idea inicial, una concepto o una tecnología? ¿Has identificado una proposición clara que haya sido probada en tu mercado y estás preparado para construir tu primer Mínimo Producto Viable (Minimum Viable Product MVP))? ¿O estás amplificando tu negocio existente o producto para llevarlo al siguiente nivel?
b. Características “Épicas” - de Alto Nivel Sin entrar en detalles, querrás definir las características que tu producto tiene que cumplir de acuerdo a las necesidades de tu cliente. Esto se denomina como una “lista de compra” estructurada que describe el esqueleto de tu producto; usualmente estas se refieren como “Historias de Usuario” (User Stories) o Épicas.
c. Análisis MoSCow (MoSCoW Analysis) - Es una técnica que, simplemente, ayuda a identificar lo que en realidad se necesita para hacer que el producto sea factible y que es bueno tener. Aquello que se identifica como “debe” abarca lo que alentará a los usuarios a comprometerse y tomar el producto. Las características identificadas como “debería” sorprenderán y le encantarán a tus clientes pero se puede trabajar en ellas después. Los ítems denominados “podría” a menudo no añaden un valor de negocio importante, puede que no incrementen el beneficio y son lo más bajo en tu lista de prioridades. Las características de “no hacer” o solo “no” podrían ser importantes un día pero están fuera del alcance para la iteración del proyecto. Sin embargo, identificar todos estos ítems o características pueden ayudar a establecer la escala potencial y el tamaño del producto para el futuro.
Al comienzo de un proyecto, se conoce poco acerca de sus posibles resultados. Es una locura imaginar desde el principio qué características posiblemente quieran el cliente y los usuarios, por lo que empezamos con un gráfico del proyecto y un conjunto de alto nivel de las características “épicas” que guiarán la dirección del proyecto, basándose en una visión y objetivos concisos.
a. Ajuste de Visión y Objetivos - ¿Qué necesitamos construir? ¿Qué necesitamos lograr y cuáles son tus objetivos de negocio? Entender estas preguntas nos permite establecer la escala del proyecto. ¿Necesitas un prototipo para probar un idea inicial, una concepto o una tecnología? ¿Has identificado una proposición clara que haya sido probada en tu mercado y estás preparado para construir tu primer Mínimo Producto Viable (Minimum Viable Product MVP))? ¿O estás amplificando tu negocio existente o producto para llevarlo al siguiente nivel?
b. Características “Épicas” - de Alto Nivel Sin entrar en detalles, querrás definir las características que tu producto tiene que cumplir de acuerdo a las necesidades de tu cliente. Esto se denomina como una “lista de compra” estructurada que describe el esqueleto de tu producto; usualmente estas se refieren como “Historias de Usuario” (User Stories) o Épicas.
c. Análisis MoSCow (MoSCoW Analysis) - Es una técnica que, simplemente, ayuda a identificar lo que en realidad se necesita para hacer que el producto sea factible y que es bueno tener. Aquello que se identifica como “debe” abarca lo que alentará a los usuarios a comprometerse y tomar el producto. Las características identificadas como “debería” sorprenderán y le encantarán a tus clientes pero se puede trabajar en ellas después. Los ítems denominados “podría” a menudo no añaden un valor de negocio importante, puede que no incrementen el beneficio y son lo más bajo en tu lista de prioridades. Las características de “no hacer” o solo “no” podrían ser importantes un día pero están fuera del alcance para la iteración del proyecto. Sin embargo, identificar todos estos ítems o características pueden ayudar a establecer la escala potencial y el tamaño del producto para el futuro.
3. Planificación de Lanzamiento
El siguiente paso en la elaboración de estimado es crear un plan de lanzamiento (release plan)que otorgará una gama de características en un plazo de tiempo determinado. Esto se deriva de una lista de características, del tamaño del proyecto, que tan rápido podría nuestro equipo desarrollar un software de calidad acorde a las expectaciones del cliente y las técnicas de gestión de riesgo de incertidumbre.
a. Backlog del Producto: El backlog del producto es simplemente una lista ordenada de “épicas” o “historias de usuario” que representa las características requeridas para un producto. Esta lista comienza como las épicas que se indicaron anteriormente, pero entre el equipo asignado al equipo del proyecto, jefe de proyecto y el cliente, ahora los desglosamos en ítems más significativos. Cada uno de estos ítems representan una porción de valor de negocios para el cliente. No entramos en más detalles en esta etapa, no necesitamos saber el criterio de aceptación, no necesitamos saber si un botón es azul o verde, solo necesitamos saber que hay un botón que permite que alguna tarea se realice.
b. Estimación - Ahora que tenemos nuestra lista de características descrita por las historias de usuario, el equipo estima estos elementos discretos de funciones utilizando la técnica de “Planificación Poker” (Poker Planning). Esta una técnica útil que garantiza resultados rápidos y fiables basados en la opinión de expertos y dimensionamiento análogo. La Planificación Poker asigna un número acordado a cada ítem representando su tamaño y complejidad. A esto se le llama punto en la historia (story point). Otras técnicas de estimación Ágil (Agile estimation) y dimensionamientos, como “días ideales” (ideal days) también están disponibles.
El final de este proceso determinará el tamaño del proyecto y las dependencias entre las características. El tamaño o la dimensión es determinado al agregar todos los puntos de historia desde los ítems en el backlog del producto. Si ese número es igual a 120, entonces el tamaño de nuestro proyecto tiene 120 puntos de historia.
c. Priorización - Una vez se tiene el backlog y el tamaño para el proyecto, estamos en la posición de priorizarlo con el cliente. Esto se trata de identificar qué es lo más valioso para el cliente para poder obtener los resultados deseados. El ítem que se encuentre a la cabeza de la lista es considerado el más importante, el segundo ítem es menos importante que el primero, y así a lo largo de la lista. Dos ítems no pueden ser tan importante entre sí, cada prioridad de ítem tiene su importancia relativa o valor con referencia a los otros ítems.
Este enfoque de la asignación de prioridades es un hito importante en la planificación de un proyecto de software. Sabemos lo que es importante para el cliente y cuál es el orden para completar el trabajo, tomando en cuenta las dependencias, para entregar un producto que cumpla con las expectativas.
d. Planificación de Lanzamiento - A la fecha, hemos determinado como sería el producto y que tan grande sería el mismo.
Ahora se determina que tiempo se tardará en entregar un producto factible. El cliente y el equipo, incluyendo los diseñadores, ingenieros, verificadores (testers), scrum master, y jefe de proyecto, trabajarán juntos para identificar qué se puede lograr y qué tan rápido se podría trabajar para crear un plan de lanzamiento.
El plan de lanzamiento también otorga una visión de cómo el proyecto se alineará con los planes estratégicos del cliente.
Finalmente, este plan asegura que el equipo del proyecto tiene una luz guía que ilumina el camino y define un punto final lógico a desarrollar.
Antes de comenzar, nos aseguraremos que entendemos la definición acordada de “terminado”. Esto se trata de un conjunto determinado de criterios que el cliente aceptará como completado y también cumplirá con todos los requisitos de los ingenieros para ser considerado terminado y factible.
Para realizar un escenario básico, tomamos el número total de puntos de historia que obtuvimos del dimensionamiento del backlog y lo dividimos para nuestro equipo de velocidad (velocity) anticipada. (Velocidad NB es normalmente expresada como un rango, pero para simplificarlo utilizamos un número). Trabajamos en iteraciones de dos semanas para que nuestra velocidad sea reflejada por lo que se puede lograr en un ciclo de dos semanas con la capacidad de disponibilidad del equipo.
Si nuestros puntos de historia suman un total de 120 y anticipamos completar 20 puntos por iteración el total de la duración del desarrollo del proyecto sería de 12 semanas o seis iteraciones. A esto se le suma un sprint de 0 a 2 semanas y un sprint de preparación de lanzamiento de 2 semanas. En total nuestra duración del proyecto es 16 semanas. Existen técnicas que podemos utilizar que ayudarían a construir un regulador intermedio de riesgos adecuado a nuestra planificación, lo cual se discutirá más adelante. En resumen se utiliza el amortiguador o regulador para poder controlar el riesgo de incertidumbre y para llegar a un acuerdo de puntos de historia que se esperan producir. El resultado podría ser un rango de entre 90 y 150 puntos historia, 90 siendo el mínimo que sería aceptable para crear un producto factible.
De manera alternativa, si el proyecto se debe completar en una fecha determinada, por ejemplo en 10 semanas, el equipo determinaría qué parte del backlog se puede completar en ese momento. Si anticipamos 20 puntos de historia por sprint, más un sprint 0 y un sprint hecho público, tendríamos como objetivo completar 60 puntos al finalizar el proyecto. Por supuesto, se buscaría manejar el riesgo mediante la adición de un amortiguador apropiado, esto podría resultar en un objetivo de 45 a 75 puntos de historia terminados y listos para lanzar al público. Los 45 puntos de historia se alinearían con el mínimo aceptable para entregar un producto viable y valioso. Esta es una situación en la que se podría anticipar añadir un miembro del equipo para aumentar la velocidad, si lo cree apropiado.
Por supuesto, todo lo anterior se apoya en una comunicación de buena calidad y la colaboración entre todas las partes para obtener un plan de lanzamiento que sea factible, realista y plausible para el cliente.
El siguiente paso en la elaboración de estimado es crear un plan de lanzamiento (release plan)que otorgará una gama de características en un plazo de tiempo determinado. Esto se deriva de una lista de características, del tamaño del proyecto, que tan rápido podría nuestro equipo desarrollar un software de calidad acorde a las expectaciones del cliente y las técnicas de gestión de riesgo de incertidumbre.
a. Backlog del Producto: El backlog del producto es simplemente una lista ordenada de “épicas” o “historias de usuario” que representa las características requeridas para un producto. Esta lista comienza como las épicas que se indicaron anteriormente, pero entre el equipo asignado al equipo del proyecto, jefe de proyecto y el cliente, ahora los desglosamos en ítems más significativos. Cada uno de estos ítems representan una porción de valor de negocios para el cliente. No entramos en más detalles en esta etapa, no necesitamos saber el criterio de aceptación, no necesitamos saber si un botón es azul o verde, solo necesitamos saber que hay un botón que permite que alguna tarea se realice.
b. Estimación - Ahora que tenemos nuestra lista de características descrita por las historias de usuario, el equipo estima estos elementos discretos de funciones utilizando la técnica de “Planificación Poker” (Poker Planning). Esta una técnica útil que garantiza resultados rápidos y fiables basados en la opinión de expertos y dimensionamiento análogo. La Planificación Poker asigna un número acordado a cada ítem representando su tamaño y complejidad. A esto se le llama punto en la historia (story point). Otras técnicas de estimación Ágil (Agile estimation) y dimensionamientos, como “días ideales” (ideal days) también están disponibles.
El final de este proceso determinará el tamaño del proyecto y las dependencias entre las características. El tamaño o la dimensión es determinado al agregar todos los puntos de historia desde los ítems en el backlog del producto. Si ese número es igual a 120, entonces el tamaño de nuestro proyecto tiene 120 puntos de historia.
c. Priorización - Una vez se tiene el backlog y el tamaño para el proyecto, estamos en la posición de priorizarlo con el cliente. Esto se trata de identificar qué es lo más valioso para el cliente para poder obtener los resultados deseados. El ítem que se encuentre a la cabeza de la lista es considerado el más importante, el segundo ítem es menos importante que el primero, y así a lo largo de la lista. Dos ítems no pueden ser tan importante entre sí, cada prioridad de ítem tiene su importancia relativa o valor con referencia a los otros ítems.
Este enfoque de la asignación de prioridades es un hito importante en la planificación de un proyecto de software. Sabemos lo que es importante para el cliente y cuál es el orden para completar el trabajo, tomando en cuenta las dependencias, para entregar un producto que cumpla con las expectativas.
d. Planificación de Lanzamiento - A la fecha, hemos determinado como sería el producto y que tan grande sería el mismo.
Ahora se determina que tiempo se tardará en entregar un producto factible. El cliente y el equipo, incluyendo los diseñadores, ingenieros, verificadores (testers), scrum master, y jefe de proyecto, trabajarán juntos para identificar qué se puede lograr y qué tan rápido se podría trabajar para crear un plan de lanzamiento.
El plan de lanzamiento también otorga una visión de cómo el proyecto se alineará con los planes estratégicos del cliente.
Finalmente, este plan asegura que el equipo del proyecto tiene una luz guía que ilumina el camino y define un punto final lógico a desarrollar.
Antes de comenzar, nos aseguraremos que entendemos la definición acordada de “terminado”. Esto se trata de un conjunto determinado de criterios que el cliente aceptará como completado y también cumplirá con todos los requisitos de los ingenieros para ser considerado terminado y factible.
Para realizar un escenario básico, tomamos el número total de puntos de historia que obtuvimos del dimensionamiento del backlog y lo dividimos para nuestro equipo de velocidad (velocity) anticipada. (Velocidad NB es normalmente expresada como un rango, pero para simplificarlo utilizamos un número). Trabajamos en iteraciones de dos semanas para que nuestra velocidad sea reflejada por lo que se puede lograr en un ciclo de dos semanas con la capacidad de disponibilidad del equipo.
Si nuestros puntos de historia suman un total de 120 y anticipamos completar 20 puntos por iteración el total de la duración del desarrollo del proyecto sería de 12 semanas o seis iteraciones. A esto se le suma un sprint de 0 a 2 semanas y un sprint de preparación de lanzamiento de 2 semanas. En total nuestra duración del proyecto es 16 semanas. Existen técnicas que podemos utilizar que ayudarían a construir un regulador intermedio de riesgos adecuado a nuestra planificación, lo cual se discutirá más adelante. En resumen se utiliza el amortiguador o regulador para poder controlar el riesgo de incertidumbre y para llegar a un acuerdo de puntos de historia que se esperan producir. El resultado podría ser un rango de entre 90 y 150 puntos historia, 90 siendo el mínimo que sería aceptable para crear un producto factible.
De manera alternativa, si el proyecto se debe completar en una fecha determinada, por ejemplo en 10 semanas, el equipo determinaría qué parte del backlog se puede completar en ese momento. Si anticipamos 20 puntos de historia por sprint, más un sprint 0 y un sprint hecho público, tendríamos como objetivo completar 60 puntos al finalizar el proyecto. Por supuesto, se buscaría manejar el riesgo mediante la adición de un amortiguador apropiado, esto podría resultar en un objetivo de 45 a 75 puntos de historia terminados y listos para lanzar al público. Los 45 puntos de historia se alinearían con el mínimo aceptable para entregar un producto viable y valioso. Esta es una situación en la que se podría anticipar añadir un miembro del equipo para aumentar la velocidad, si lo cree apropiado.
Por supuesto, todo lo anterior se apoya en una comunicación de buena calidad y la colaboración entre todas las partes para obtener un plan de lanzamiento que sea factible, realista y plausible para el cliente.
Técnicas de Estimación
Estimaciones Compartidas - Las estimaciones no se realizan de forma aislada. Se llevan a cabo en colaboración por parte de todo el equipo de ingeniería e incluyen el diseño, la base de datos, el servidor, la interfaz del usuario front-end (Front end UI), el control de calidad (QA) y otros expertos de funcionalidad cruzada. Así se evitan problemas de no considerar todos los aspectos del trabajo necesario para terminar una función, al igual asegura que nadie tenga la obligación o la desgracia de subestimar o no el tamaño de una función. El equipo combinado tendrá una visión que puede ser debatida y luego acordar una decisión.
Estimaciones Análogas - Con estas se considerarán dos características discretas y se decidirá que una es relativamente más pequeña o grande que la otra. Podríamos mirar una historia y estar de acuerdo en que no es de gran tamaño, y si se usan puntos de historia se podría darle un tamaño de dos. La próxima historia podría ser considerada tan grande como la primera, y le daríamos un tamaño de cinco. Ello sugiere que una característica grande puede ser dos veces el tamaño de una pequeña.
Este ejercicio se haría con todas las historias. Y una vez completado, podemos tener todas nuestras historias, ya sean pequeñas, medianas, largas y extra largas una al lado de la otra y comprobar el tamaño para asegurarnos que hay un nivel de uniformidad en la estimación.
Planificación Póker - Se ha hablado mucho sobre Planificación Póker; la mencioné en otro blog (Ultimate Introduction to Agile Project Management). Y uno de los mejores recursos para entenderla puede ser visto aquí.
Básicamente combina la opinión de expertos, la analogía y la colaboración del equipo en un proceso fácil, rápido y confiable.
La misma reúne a varios expertos los cuáles son los más adecuados para realizar un estimado basado en experiencia técnica y dominio, un diálogo dinámico y una justificación firme.
Estimaciones Compartidas - Las estimaciones no se realizan de forma aislada. Se llevan a cabo en colaboración por parte de todo el equipo de ingeniería e incluyen el diseño, la base de datos, el servidor, la interfaz del usuario front-end (Front end UI), el control de calidad (QA) y otros expertos de funcionalidad cruzada. Así se evitan problemas de no considerar todos los aspectos del trabajo necesario para terminar una función, al igual asegura que nadie tenga la obligación o la desgracia de subestimar o no el tamaño de una función. El equipo combinado tendrá una visión que puede ser debatida y luego acordar una decisión.
Estimaciones Análogas - Con estas se considerarán dos características discretas y se decidirá que una es relativamente más pequeña o grande que la otra. Podríamos mirar una historia y estar de acuerdo en que no es de gran tamaño, y si se usan puntos de historia se podría darle un tamaño de dos. La próxima historia podría ser considerada tan grande como la primera, y le daríamos un tamaño de cinco. Ello sugiere que una característica grande puede ser dos veces el tamaño de una pequeña.
Este ejercicio se haría con todas las historias. Y una vez completado, podemos tener todas nuestras historias, ya sean pequeñas, medianas, largas y extra largas una al lado de la otra y comprobar el tamaño para asegurarnos que hay un nivel de uniformidad en la estimación.
Planificación Póker - Se ha hablado mucho sobre Planificación Póker; la mencioné en otro blog (Ultimate Introduction to Agile Project Management). Y uno de los mejores recursos para entenderla puede ser visto aquí.
Básicamente combina la opinión de expertos, la analogía y la colaboración del equipo en un proceso fácil, rápido y confiable.
La misma reúne a varios expertos los cuáles son los más adecuados para realizar un estimado basado en experiencia técnica y dominio, un diálogo dinámico y una justificación firme.
Entradas
No hay comentarios:
Publicar un comentario