Estimación de costos de software en la gestión ágil de proyectos

Introducción

Una de las cosas más difíciles de hacer en el desarrollo de software es determinar cuánto tiempo y cuánto llevará entregar un nuevo producto de software. ¿Debería ser tan difícil? La respuesta no es sencilla.

La estimación de costos de software es inherentemente difícil, y los humanos son terriblemente malos para predecir resultados absolutos. No hay dos proyectos iguales; cada uno es único en lo que se propone lograr y único en la miríada 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 desafiante de implementar en la realidad. Y, sin duda, habrá 'incógnitas' con el proyecto que solo podrán identificarse cuando surjan.

Además, no hay dos personas iguales, ya sea un cliente, un desarrollador o un usuario. Venimos precargados con nuestro propio conjunto de conocimientos, experiencias, valores, expectativas, actitud ante el riesgo y capacidad de adaptación.

Escribir software de buena calidad es el pan de cada día para los ingenieros senior; crear productos de software asombrosos puede ser un esfuerzo mucho más difícil para todos los involucrados.

Pero cuando se trata de software, comprender la duración y el costo son clave para tomar decisiones comerciales estratégicas y esto es cierto ya sea que esté creando una nueva empresa, aprovechando una nueva oportunidad comercial o permitiendo que su negocio funcione mejor. El tiempo, el retorno de la inversión y el beneficio entregado pueden hacer, sacudir o deshacer su negocio. Te estarás preguntando: ¿Qué obtenemos por nuestro dinero? ¿Podemos predecir nuestros costos? ¿Cuánto costará crear el producto que queremos? ¿Cuándo podemos lanzar? ¿Obtendremos un producto de calidad por nuestra inversión? ¿Crecerá con nuestro negocio? ¿Ofrecerá valor comercial?

Entonces, ¿cómo se hace para estimar el tamaño, la duración y el costo de un proyecto? Exploremos la estimación ágil de proyectos y los costos de desarrollo de software, y cómo lo hacemos en Toptal.

Estimación y fijación de precios de contratos tradicionales

Tradicionalmente, utilizando prácticas no ágiles, los proyectos de software han buscado fijar la funcionalidad o el alcance y permitir que el tiempo y el costo sean una variable. Esto causa problemas:

1. ¿Cómo sabe que la funcionalidad que corrige al comienzo de un proyecto es realmente la funcionalidad que mejor sirve a su negocio o clientes? La mayoría de las veces, la funcionalidad o el alcance cambiarán, razón por la cual escuchamos sobre el "desplazamiento del alcance", el resultado de las necesidades deseadas que se identifican a lo largo del ciclo de vida de un proyecto y se determinan como necesarias u obligatorias.

2. Cuando el costo se convierte en una variable, perdemos el control sobre el retorno de la inversión (ROI) que buscamos lograr. El aumento de costos a menudo es producto de riesgos no identificados o requisitos cambiantes, lo que significa que tenemos que agregar miembros del equipo para hacer más trabajo en el mismo período de tiempo o mantener a los miembros del equipo por más tiempo. Tampoco es deseable

3. Cuando el tiempo es una variable, perdemos el control sobre la posición en nuestro mercado. Quizás nos perdemos una fecha importante de la industria o nuestros competidores sacan su producto antes que nosotros, perdiendo así cualquier ventaja competitiva que pudiera haber tenido nuestro proyecto.

Hay muchos otros resultados de tiempo y costo variables, que a menudo son negativos e indeseables.

Por supuesto, muchos clientes y organizaciones buscan arreglar los tres componentes de este 'triángulo mágico'. Desafortunadamente, es casi imposible de lograr de manera realista. Hay demasiados elementos que conspiran para desestabilizar este ideal, que finalmente terminan en productos que no satisfacen una necesidad, tardan demasiado en beneficiar a sus clientes o cuestan demasiado para obtener valor comercial.

Contratos ágiles para proyectos de software

El costo es un producto del tiempo y las personas (miembros del equipo). Agregue más tiempo y agregará costos por emplear a personas por más tiempo. Agregue más miembros del equipo y aumentará el costo para ofrecer el mismo valor comercial. Las cosas que realmente queremos evitar. Es por eso que los principios ágiles creen en fijar el tiempo y los miembros del equipo y permitir que el alcance sea el componente variable.

¿Qué suena mejor y aumenta la confianza de las partes interesadas, el costo fijo o el costo variable?

Por supuesto, es importante que un producto cumpla sus promesas y las necesidades de sus clientes. De nada sirve gastar una cantidad exacta de tiempo y una cantidad exacta de dinero si al final tienes un producto que nadie quiere ni puede usar de manera efectiva.

Entonces, los contratos Agile se enfocan en lo siguiente:

• Paquetes de trabajo de precio fijo : todo el proyecto se divide en 'mini' lanzamientos lógicos que contribuyen al resultado completo del producto. Cada lanzamiento es un paquete de trabajo que tiene un precio acorde. A medida que se completa un paquete de trabajo, los paquetes de trabajo futuros se vuelven a estimar en función de lo que hemos aprendido del anterior. Esto evita contingencias innecesarias y permite que el cliente defina un nivel de repriorización y características nuevas/revisadas.

• Terminación anticipada: esto permite que el cliente busque terminar el proyecto antes de tiempo si se ha entregado una cantidad suficiente del producto y no se puede lograr un ROI adicional al retener un equipo de proyecto que solo continuará brindando ganancias marginales. Esta cláusula generalmente se permite en cualquier momento y es válida siempre que el equipo del proyecto y el cliente hayan mantenido una relación de colaboración estrecha, de confianza y sólida. El beneficio para el cliente es que el proyecto terminará temprano, habiendo entregado todas las características valiosas necesarias para que el producto sea viable. A cambio, al proveedor se le paga el 20 por ciento del valor restante del contrato y compensa el riesgo de retener al personal.

• Cambios flexibles : el cambio es un tema que corre fuertemente por las venas de la entrega de software Agile. Esperamos no saber todo lo que necesitamos para que un producto tenga éxito desde el principio. Por lo tanto, promovemos el cambio, en función de los datos y comentarios relevantes, para garantizar que se entregue el producto correcto. Al final de una iteración, los cambios se pueden cambiar por funciones antiguas que ya no se consideran necesarias o prioritarias. Siempre que el cambio sea de igual valor, no hay ningún costo adicional. Si el cambio es de menor valor, se puede identificar o sacar adelante trabajo adicional del trabajo pendiente restante. Esta cláusula es válida siempre que el equipo del proyecto y el cliente hayan mantenido una relación de colaboración estrecha, de confianza y sólida durante todo el proyecto.

• Trabajo adicional : a lo largo de la vida de un proyecto, se pueden identificar más características que no se podrían lograr con el contrato de precio fijo existente. Para este escenario, se pueden agregar paquetes de trabajo adicionales con precios nuevos al final del proyecto o volver a tiempo y materiales.

• Estimaciones por rango: hay dos formas en que las estimaciones se pueden variar en un contrato de proyecto Agile: un rango de duración o un rango de características. Un rango de duración permite una estimación para decir que el proyecto o paquete de trabajo tomará de 12 a 16 semanas para un conjunto determinado de alcance. Sin embargo, agregar duración agrega costos ya que mantiene a los miembros del equipo del proyecto por más tiempo, o significa que no pueden ser liberados para trabajar en otros proyectos de desarrollo. En Toptal, preferimos clasificar las características en una variedad de puntos de la historia, manteniendo el alcance como variable pero prometiendo entregar un nivel mínimo de valor al cliente dentro del marco de tiempo fijo del paquete de trabajo o proyecto general.

Vale la pena recordar que siempre puede agregar más alcance más tarde. Tal vez haya comenzado a obtener ingresos, haya aumentado los usuarios o reducido los costos. De cualquier manera, es mucho más fácil pedir más dinero y tiempo si ya demostró un retorno o mejora y está entregando valor comercial.

Nuestro enfoque de los costos y precios del software

En Toptal, trabajamos en estrecha colaboración con nuestros clientes e ingenieros para emplear técnicas que promuevan la confianza de las partes interesadas en la duración y los costos del proyecto. Trabajamos en la elaboración y adaptación continuas de la planificación desde un alto nivel inicial hasta detalles más granulares cuando es apropiado y necesario para evitar el desperdicio y permitir el cambio gestionado.

Para la elaboración de un proyecto de presupuesto y precio fijo se siguen los siguientes pasos:

1. Alcance inicial de alto nivel

Al comienzo de un proyecto, sabemos menos acerca de su resultado final. Es una locura imaginar que es posible saber exactamente qué características necesitan nuestros clientes y usuarios desde el principio.

Entonces, comenzamos con un acta de constitución del proyecto y un conjunto de características "épicas" de alto nivel que guían la dirección del proyecto, con base en una visión y objetivos sólidos.

un. Definición de Visión y Objetivo ¿Qué necesitamos construir? ¿Qué necesita lograr y cuáles son sus objetivos comerciales? Comprender estas preguntas nos permite establecer la escala del proyecto. ¿Necesitas un prototipo para probar una idea, concepto o tecnología inicial? ¿Ha identificado una propuesta clara que ha sido probada con su mercado y está listo para construir su primer Producto Mínimo Viable (MVP)? ¿O está ampliando su negocio o producto existente para llevarlo al siguiente nivel?

B. Características “épicas” de alto nivel Sin entrar en demasiados detalles, querrá definir las características que tiene su producto para satisfacer las necesidades de sus clientes. Esta es una "lista de compras" estructurada que describe los huesos básicos de su producto; a menudo se les conoce como "Historias de usuarios" o epopeyas

C. Análisis MoSCoW El análisis MoSCoW es una técnica que, en pocas palabras, ayuda a identificar qué es realmente necesario para que el producto sea viable y qué es bueno tener. Aquellos que se identifican como "Obligatorios" satisfacen lo que alentará a los usuarios a participar y adoptar su producto. Esas características identificadas como "Debería" sorprenderán y deleitarán a sus clientes, pero podrían construirse más adelante. Los artículos "Podrían" a menudo no agregan un valor comercial significativo, es posible que no aumenten el rendimiento y son los más bajos de sus prioridades. Las funciones "no" bien podrían ser importantes algún día, pero están fuera del alcance de esta iteración del proyecto. Sin embargo, identificarlos ahora puede ayudar a tener en cuenta la escala y el tamaño potencial del producto para el futuro.

2. Propuesta

Para tomar una decisión sobre si continuar con un proyecto, es necesario basar esa decisión en datos bien informados: costo y duración. Estos son los mínimos que debes preguntarte: ¿Qué se necesita para crear el producto que queremos? ¿Cuándo podemos lanzar? ¿Esto se alinea con nuestra estrategia comercial y finanzas?

Con los detalles anteriores, estamos en condiciones de ofrecer una propuesta. Nuestros ingenieros son cuidadosamente seleccionados para los requisitos específicos del proyecto y trabajan junto con un gerente de proyecto para derivar al menos una solución técnica, una duración estimada que brinde el alcance conocido y un costo estimado para completar el proyecto.

Como mencionamos antes, al comienzo de un proyecto sabemos menos sobre lo que se entregará. Mantenemos deliberadamente vagas las características y el alcance, ya que hacer lo contrario sugiere que sabemos exactamente lo que se requiere. Una estimación en esta etapa sería la menos precisa, pero brinda orientación sobre si vale la pena continuar con el proyecto.

La propuesta es la primera herramienta para elaborar la duración y el costo de un proyecto. Una vez que se acepta una propuesta, podemos avanzar para proporcionar una cotización de precio fijo.

3. Planificación de lanzamiento

El siguiente nivel de elaboración de estimaciones es crear un plan de lanzamiento que ofrezca una variedad de funciones en un período de tiempo determinado. Derivamos esto de una lista de características, el tamaño del proyecto, la rapidez con que nuestro equipo puede desarrollar software de calidad que cumpla con las expectativas del cliente y las técnicas para administrar el riesgo de la incertidumbre.

un. Lista de pedidos del producto La lista de pedidos del producto es simplemente una lista ordenada de "épicas" o "historias de usuarios" que representan las características requeridas para un producto. Esta lista comienza como las épicas discutidas anteriormente, pero entre el equipo de proyecto asignado, el gerente de proyecto y el cliente, ahora las desglosamos en elementos más significativos. Cada uno de los artículos representa una parte del valor comercial para el cliente. No entramos en más detalles en esta etapa, no necesitamos saber los criterios de aceptación, no necesitamos saber si un botón es azul o verde, solo necesitamos saber que hay un botón que permite alguna tarea. a realizar.

B. Estimación Ahora que tenemos nuestra lista de funciones descritas como historias de usuarios, el equipo estima estos elementos discretos de funciones utilizando una técnica llamada "Planning Poker". Esta es una técnica útil que asegura resultados rápidos y confiables basados ​​en la opinión de expertos y dimensionamiento análogo. Planning Poker asigna un número acordado a cada elemento que representa su tamaño y complejidad. Esto se llama un punto de la historia. Hay disponibles otras técnicas y tamaños de estimación Agile, como 'días ideales'.

El final de este proceso determinará el tamaño del proyecto y las dependencias entre características. El tamaño se determina sumando todos los puntos de la historia de los elementos de la cartera de productos. Si ese número es igual a 120, entonces el tamaño de nuestro proyecto es de 120 puntos de historia.

C. Priorización Ahora que tenemos un backlog y un tamaño para el proyecto, estamos en condiciones de priorizarlo con el cliente. Se trata realmente de identificar qué es lo más valioso para el cliente a fin de lograr los resultados deseados. El elemento en la parte superior de la lista se considera el más importante, el segundo elemento es menos importante que el primero, y así sucesivamente a lo largo de la lista. Dos elementos no pueden ser tan importantes como otro, la prioridad de cada elemento es de importancia o valor relativo a cada uno de los otros elementos.

Este enfoque de priorización es un hito importante en la planificación de un proyecto de software. Ahora sabemos qué es importante para el cliente y en qué orden completar el trabajo, cuidando las dependencias, para entregar un producto que cumpla con las expectativas.

D. Planificación del lanzamiento Hasta la fecha, hemos determinado lo que creemos que es el producto y su tamaño.

Ahora, determinamos cuánto tiempo tomará entregar un producto liberable. El cliente y el equipo, incluidos los diseñadores, ingenieros, probadores, scrum master y gerente de proyecto, trabajan juntos para identificar qué se puede lograr y qué tan rápido se puede trabajar para crear un plan de lanzamiento.

El plan de lanzamiento también brinda información sobre cómo se alineará el proyecto con los planes estratégicos de un cliente.

Y finalmente, este plan asegura que el equipo del proyecto tenga una luz que guíe el camino y defina un punto final lógico para el desarrollo.

Antes de comenzar, nos aseguramos de entender la definición acordada de "hecho". Este es un conjunto dado de criterios que un cliente aceptará como completo y también cumple con todos los requisitos de ingeniería para ser considerado liberable.

Para tomar un escenario básico, tomamos la cantidad total de puntos de historia que obtuvimos al dimensionar nuestro trabajo pendiente y lo dividimos por la velocidad anticipada de nuestros equipos. (Nota: la velocidad normalmente se expresa como un rango, pero para simplificar, usaremos un solo número aquí). Trabajamos en iteraciones de dos semanas, por lo que nuestra velocidad se reflejará en cuánto podemos completar en un ciclo de dos semanas con el disponible. capacidad del equipo. Si nuestra historia sumó 120 puntos y anticipamos completar 20 puntos por iteración, la duración total del desarrollo sería de 12 semanas o 6 iteraciones. A eso le sumamos un sprint 0 de 2 semanas y un sprint de preparación de lanzamiento de dos semanas. En total, la duración de nuestro proyecto es de 16 semanas. Hay técnicas que podemos usar que ayudarían a construir un colchón de riesgo apropiado en nuestra planificación, que discutiremos más adelante. Pero, en resumen, usamos el amortiguador para gestionar el riesgo de incertidumbre y llegar a un acuerdo mínimo de los puntos de historia esperados que se entregarán. El resultado podría ser un rango de 90 a 150 puntos de historia entregados, siendo 90 el mínimo aceptable para crear un producto viable.

Alternativamente, si el proyecto debe completarse en una fecha determinada, digamos en 10 semanas, el equipo determinaría cuánto de la cartera de pedidos se puede completar en ese tiempo. Si anticipamos 20 puntos de historia por sprint, más Sprint 0 y un sprint de lanzamiento, estaríamos apuntando a 60 puntos completados al final del proyecto. Nuevamente, buscaríamos administrar el riesgo agregando un margen adecuado, lo que podría resultar en un objetivo de 45 a 75 puntos de historia completados y listos para publicar. Los 45 puntos de la historia se alinearían con el mínimo aceptable para entregar un producto viable y valioso. Este es un escenario en el que puede esperar agregar un miembro del equipo para aumentar la velocidad, si corresponde.

Por supuesto, todo lo anterior está respaldado por una comunicación y colaboración de buena calidad entre todas las partes para derivar un plan de lanzamiento que sea factible, realista y aceptable para el cliente.

4. Contrato de precio fijo

Una vez que se acuerda un plan de lanzamiento, podemos crear una cotización para un contrato de proyecto de precio fijo. Como se mencionó anteriormente, es recomendable mantener la duración y el equipo del proyecto fijos y el alcance variable.

La cotización para un contrato de precio fijo se entrega junto con una declaración de trabajo y el cronograma de pago acordado.

Siempre que haya confianza, comunicación, colaboración y disposición para entrar en el espíritu de un proyecto de software Agile, todos los pasos anteriores nos permiten entregar una cotización con un grado realista de confianza de que un proyecto se entregará a tiempo y dentro del presupuesto. Por supuesto, habrá ocasiones en las que un proyecto se entregue antes o después y tratamos estas variaciones con la máxima transparencia.

Técnicas de Estimación

La planificación y la estimación ágiles están respaldadas por una serie de técnicas que un equipo de desarrollo puede usar para ganar confianza en su tamaño, esfuerzo, duración y costo. Estos son algunos de los que usan nuestros equipos para estimar el tamaño y el costo de un proyecto de software.

Estimación del tamaño

El tamaño del proyecto es realmente una apreciación de su alcance, complejidad, dimensiones, riesgo y magnitud. Para usar una analogía, se trata de entender si estamos construyendo la Torre Eiffel o la Gran Muralla China. La torre Eiffel es una estructura alta, pesada y compleja construida en un entorno urbano estrecho. La Gran Muralla China es una estructura relativamente simple, pero larga y resistente que abarca muchas millas de terreno ondulado.

Si bien ambos serían grandes proyectos para entregar, su alcance, complejidad, dimensiones, magnitud y, por lo tanto, tamaño son diferentes.

Es importante manejar las expectativas con estimaciones. Nunca son predicciones, compromisos o garantías. Cuando discutimos el tamaño total, la duración total y el costo total, siempre trabajamos dentro de rangos, para mitigar el riesgo, la incertidumbre y las incógnitas.

Las historias que representan características de su producto se dimensionan individualmente y se estiman utilizando puntos de historia o días ideales. El número total de estas unidades define el tamaño total del proyecto.

Puntos de historia

Los puntos de historia son una unidad de medida que expresa el tamaño total de una historia de usuario. El tamaño de una historia, cuando se estima, incluye todos los aspectos de diseño, ingeniería, pruebas, revisión de código, integración, etc.

Cada tamaño de una historia es relativo a otra historia. Entonces, por ejemplo, el Piso A puede tener el tamaño de un punto, el Piso B como dos puntos y el Piso C como tres puntos. Aquí, el Piso C es al menos tres veces más grande que el Piso A y al menos la mitad del tamaño del Piso B.

Si las siguientes historias en nuestra cartera de productos tienen los tamaños asociados:

El tamaño total del proyecto es de 12 puntos de historia.

Días Ideales

Esta es una medida de tamaño expresada en días. Elimina el concepto de gastos generales como interrupciones, actividades de planificación ágil, lectura de correos electrónicos y otras actividades ajenas al proyecto. Solo se concentra en cuánto tiempo tomaría si trabajara en algo continuamente sin interrupción, en lugar del tiempo transcurrido de principio a fin.

Por lo general, al estimar a un nivel alto cuando sabemos menos sobre un proyecto, estimaríamos en días ideales, ya que este es un concepto más fácil de correlacionar con la historia y la experiencia pasadas que un número abstracto como un punto de la historia. Especialmente cuando las historias de alto nivel son de naturaleza más épica con pocos detalles y posiblemente contienen elementos adicionales cuando se desglosan en una fecha posterior.

Al estimar a un nivel más granular, por ejemplo, una historia en un backlog de producto establecido, se puede usar cualquiera de los enfoques y el equipo de ingeniería lo decidirá. Hay beneficios para ambos enfoques y cada equipo tendrá su preferencia.

Técnicas para estimar

Estimaciones compartidas Las estimaciones no se realizan de forma aislada. Se realizan en colaboración por todo el equipo de ingeniería e incluyen diseño, base de datos, servidor, interfaz de usuario front-end, control de calidad y otros expertos multifuncionales. Esto evita los problemas de no considerar todos los aspectos del trabajo involucrado para completar una característica y asegura que ninguna persona tenga la carga o la desgracia de sobreestimar o subestimar el tamaño de una característica. El equipo combinado tendrá una visión que puede ser discutida y acordada.

Estimaciones análogas Aquí es donde consideramos dos características discretas y decidimos que una es relativamente más pequeña o más grande que la otra. Podemos mirar una historia dada y estar de acuerdo en que es de tamaño pequeño, y si usamos puntos de historia, podríamos darle un tamaño de dos. La siguiente historia podría considerarse grande en comparación con la primera, y le daríamos un tamaño de cinco. Esto sugiere que una característica grande es al menos el doble del tamaño de una característica pequeña.

Continuaríamos este ejercicio con todas las historias. Una vez completado, podemos colocar todos los pisos pequeños, medianos, grandes y extra grandes uno al lado del otro y verificar nuestro tamaño para asegurarnos de que haya un nivel de uniformidad en nuestra estimación.

Planning Poker Mucho se ha escrito sobre Planning Poker; También lo mencioné en mi blog anterior. Uno de los mejores recursos para entenderlo está aquí.

En esencia, combina la opinión de expertos, la analogía y la colaboración en equipo en un proceso fácil, rápido y confiable.

Reúne a varios expertos que son los más adecuados para crear una estimación basada en la experiencia técnica y de dominio, un diálogo animado y una justificación sólida.

Velocidad

La velocidad es una medida de la capacidad de un equipo para realizar el trabajo en una iteración determinada (o sprint).

Se expresa como un rango, por ejemplo, de 23 a 32 puntos de historia por sprint, especialmente al principio de la vida de un proyecto. En general, esto se debe a que, a menos que el mismo equipo haya trabajado antes en el mismo problema, es difícil describir exactamente cuál será la velocidad del equipo. ¡Observa que nos referimos a la velocidad de un equipo y no a la de un individuo!

Usamos la velocidad para planificar nuestros lanzamientos y adaptar nuestros planes y paquetes de trabajo a medida que avanzamos en un proyecto, lo que nos permite ajustar nuestro pronóstico de finalización de manera regular y precisa durante la ejecución.

Cuando comenzamos, nos vemos obligados a definir un rango de velocidad con muy pocos datos. Podemos usar valores históricos si el equipo y el espacio del problema son los mismos, lo que suele ser lo menos probable. Podemos ejecutar una iteración para tener una idea de la velocidad de un equipo que realmente está trabajando en el proyecto, pero esto es costoso y no funciona si aún se deben tomar decisiones para aceptar iniciar un proyecto. O bien, podemos hacer un pronóstico.

Pronosticar una velocidad implica tomar las historias de un sprint y dividirlas en tareas que se realizan para completar la historia. Estimaríamos la cantidad de horas que llevará cada tarea, lo que incluye diseño, desarrollo, pruebas, etc., y evaluaríamos cuánta capacidad tendría el equipo en un sprint determinado. Una capacidad del 70 por ciento para un equipo sin trabas es una buena línea de base. Entonces, en una situación simple, si el total de horas disponibles para el equipo es:

• 4 miembros del equipo * dos semanas * 40 horas por semana = 320 horas
• Multiplicado por nuestro 70 por ciento de capacidad = 224 horas
• Sume todas las tareas de características y deje de contar en 224
• Tome todas las características completadas, sume sus puntos de historia y obtendrá su velocidad, digamos 36
• Aplique un 20 por ciento a cada lado para obtener un rango del más bajo y más alto, para llegar a una velocidad estimada de 29 a 43 puntos de historia.

La velocidad generalmente varía en las primeras dos a cuatro iteraciones y luego se estabiliza dentro de un pequeño rango de puntos. Entonces, donde nuestro rango inicial antes del sprint uno era de 29 a 43, para el sprint cuatro, puede estabilizarse de 34 a 38. Esto nos da una mayor confianza para pronosticar nuestra fecha final de finalización.

Planes de amortiguamiento para el riesgo y la incertidumbre

Todos los proyectos de software vienen atados con un nivel de incertidumbre. Esa incertidumbre se reduce a medida que avanzamos en el proyecto y se conoce más sobre nuestra tecnología, entorno, rendimiento y las necesidades del cliente y los usuarios.

Mitigamos esta incertidumbre o riesgo con una reserva en el cronograma, lo que representa un margen de error en nuestra estimación y las incógnitas que no podemos determinar antes de que comience el desarrollo.

Por lo general, hay dos tipos de búfer: Función y Programación. Como a menudo estamos definiendo un precio fijo para una fecha de entrega fija, es preferible usar el búfer de características.

Este enfoque nos brinda una estrategia creíble de mitigación de riesgos y brinda confianza al cliente sobre lo que debe esperar ver como resultado cuando el proyecto esté completo.

Búferes de características

Con un búfer de funciones, estamos pronosticando que entregaremos un conjunto determinado de funciones, pero idealmente completaremos un conjunto adicional de funciones. Esto debe reflejar al menos el conjunto mínimo de funciones que el cliente considera necesario para lanzar un producto viable, pero se pueden entregar más dentro del marco de tiempo si todas las influencias internas y externas lo permiten.

Por lo tanto, un cliente puede decidir que las características de mayor prioridad de la cartera de productos, sumando hasta 100 puntos de historia, son las más importantes. Luego pueden considerar características adicionales que se suman a otros 30 puntos de historia. El equipo, por lo tanto, planificará en base a la entrega de 130 puntos de historia, con un mínimo de 100 completados al final de la fecha de finalización programada para el contrato de precio fijo dado.

Algunos pensamientos finales

Agile puede ser un concepto muy difícil de comprender y adoptar por completo. Esto no es menos cierto cuando se manejan temas sensibles como el precio, el alcance y la duración. Desafortunadamente, sé de primera mano que los clientes exigentes quieren que todo se arregle por adelantado y están ansiosos por culpar al proveedor cuando todo comienza a desmoronarse. Del mismo modo, soy consciente de los proveedores que se mantienen firmes, no responden y no responden a las necesidades de los clientes. Tomar un camino ágil se basa fundamentalmente en la confianza, las buenas relaciones y la comunicación estelar. Estos deben ser valores sostenidos por ambas partes para mantener un proyecto saludable para el beneficio, la satisfacción y el éxito de todos los involucrados. Mantener una mente abierta y una actitud constructiva hacia la colaboración y la negociación es la mejor manera de evitar que las relaciones se agrien.

He trabajado con clientes a los que les ha resultado difícil adoptar la naturaleza adaptativa de Agile y renunciar a una actitud de mando y control. Es difícil dejarse llevar y poner toda tu fe y confianza en un equipo que no conoces. A menudo, los clientes pueden desear crear todos los requisitos por adelantado como una especificación de lo que se entregará. Esto les da una sensación de confianza de que el alcance de un proyecto está bien definido. Pero en última instancia, esto no se materializa como un enfoque exitoso. Si estamos limitados por el alcance y las demandas poco realistas en un contrato, los problemas surgen muy rápidamente.

Sabemos, al adoptar este enfoque en los métodos tradicionales, que el alcance cambia, se descubren incógnitas o lo que pensamos que el cliente quería ya no es cierto o está fuera de lugar. Adoptar un enfoque adaptativo para la fijación de precios, la planificación y el alcance permite a los clientes identificar verdaderamente que su producto es exactamente lo que necesita su mercado. Permite que un proveedor sea receptivo, imaginativo y eficiente también. Aprovechar la colaboración entre el cliente y el proveedor sobre la negociación del contrato es clave.

Los proveedores deben ser honestos y los clientes deben ser realistas sobre lo que se puede lograr desde el principio. Un proveedor que promete objetivos poco realistas y luego aumenta los costos puede ganar el contrato inicial, pero pronto perderá el favor de un cliente descontento. Con demasiada frecuencia, las relaciones se rompen debido a la falta de confianza entre las partes. La confianza debe construirse desde el principio y mantenerse a lo largo del curso de un proyecto. Un proveedor debe ser flexible y cooperar con las necesidades cambiantes. Los clientes siempre quieren más; es una consecuencia natural de hacer negocios. Debe haber un intercambio de valor equitativo y beneficioso entre ambas partes. Los clientes buscan crear valor para su negocio. Para los proveedores, deberían buscar crear valor al formar relaciones duraderas con los clientes. Observar los valores y principios rectores del Manifiesto Ágil es una base sólida para formar relaciones sólidas, equilibradas y duraderas.

Resumen

Espero que esto le haya dado una idea de cómo planificar, estimar y definir un precio para un proyecto de software Agile. Todos los enfoques y técnicas anteriores están diseñados para generar confianza en un equipo y generar confianza en las mentes de los clientes sobre cuánto tiempo y cuánto llevará construir un producto de software. Y, en última instancia, para generar confianza al tomar la decisión de proceder.

Siga estas pautas y se asegurará de encontrar una ruta satisfactoria para dar vida a su producto de software.