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.
Cuando se trate de software, la clave es entender la duración y el costo para realizar decisiones estratégicas de negocios y esta es la verdad ya sea que estás creando una nueva empresa, ejecutando una nueva oportunidad de negocios, o habilitando tu negocio para obtener mejores resultados. La sincronización, el retorno de la inversión y el beneficio entregado pueden crear, sacudir o romper tu negocio. Te encontrarás preguntándote a ti mismo: ¿Qué obtenemos por nuestro dinero? ¿Podemos predecir los costos? ¿Cuánto costará crear el producto que queremos? ¿Cuándo podemos lanzarlo? ¿Obtendremos un producto de calidad por nuestra inversión? ¿Crecerá con nuestro negocio? ¿Ofrecerá valor empresarial?
Entonces, ¿cómo se puede estimar el tamaño, la duración, y el costo de un proyecto? Exploremos la estimación de los costos de desarrollo de software en gestión de proyectos ágiles, y cómo lo hacemos en Toptal.
Precio Tradicional de Contrato y Estimación
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:
- ¿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.
- 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.
- 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.
Contratos Ágiles para Proyectos de Software
El costo es un producto que surge del tiempo y las personas (miembros del equipo). Añade más tiempo y se incluirán costos por contratar personas por más tiempo. Agrega más miembros de equipo, y aumentarás el costo para entregar el mismo valor de negocio, lo cual es algo que queremos evitar. Es por esto que los principios Ágiles creen en solucionar tiempo y 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?
Obviamente, es importante que un producto cumpla con lo prometido y con las necesidades del cliente. No es nada bueno invertir una cantidad de tiempo y dinero estrictos, si al fina tienes como resultado un producto que nadie quiere o puede usar eficientemente.
Los contratos Ágiles se enfocan en lo siguiente:
- Paquetes de trabajo a precio fijo: Todo el proyecto se desglosa en “mini” versiones lógicas que contribuyen al resultado total del producto. Cada lanzamiento es un paquete de trabajo que tiene un precio en consecuencia. A medida que los paquetes de trabajo se completan, los futuros paquetes de trabajo se estiman nuevamente guiándonos por lo que hemos aprendido del anterior. Así se evita una contingencia innecesaria y permite un nivel de reorganización de prioridades y nuevas/reconsideradas características a ser definidas por el cliente.
- Terminación anticipada: Esto le permite al cliente terminar el proyecto antes si se ha entregado un gran porcentaje del producto, y no hay más retorno de inversión que deba alcanzarse mediante la retención de un equipo que solo dará ganancias marginales. Esta cláusula está permitida generalmente en cualquier momento y es válida siempre y cuando el equipo del proyecto y el cliente hayan mantenido una fuerte, sincera y estrecha relación de trabajo colaborativo. El beneficio para el cliente es que el proyecto terminará antes, al haber entregado todas las características ventajosas necesarias para hacer el producto factible. A cambio, al proveedor se le paga el 20 por ciento del valor del contrato restante y se compensa el riesgo de retención de personal.
- Cambios flexibles: El cambio es un tema que corre con fuerza por las venas de la entrega de software Ágil. Esperamos no saber todo cuando tenemos hacer un producto exitoso desde el principio. Así que promovemos el cambio, basándonos en datos relevantes y comentarios sobre el producto para asegurarnos que el adecuado sea entregado. Al final de un iteración, los cambios se pueden intercambiar por características viejas que ya no sean consideradas necesarias o una prioridad, siempre y cuando el nuevo cambio sea de igual valor, y no haya un costo adicional. Si el cambio es de menor valor, un trabajo adicional puede ser identificado o se puede realizar desde el backlog. Esta cláusula es válida siempre y cuando el equipo del proyecto y el cliente hayan mantenido una sincera, fuerte y estrecha relación de trabajo colaborativo durante todo el proyecto.
- Trabajo adicional: A lo largo de la vida de un proyecto, pueden ser identificadas más características que no serían alcanzables dentro de un proyecto ya estimado. Ante este escenario, cualquier paquete de trabajo nuevo puede ser agregado al final del proyecto o enfocarse en tiempo y materiales.
- Estimaciones distanciadas: Hay dos formas por las cuales los estimados pueden ser a distancia en un contrato de proyecto Ágil: un intervalo de duración o un intervalo de características. Con el intervalo de duración la estimación puede determinar si el paquete de proyecto tomará de 12 a 16 semanas para un alcance final. Sin embargo, agregar duración añade costo mientras mantienes a los miembros del equipo de proyecto por más tiempo, o significa que no estarán libres para trabajar en otros proyectos de desarrollo. En Toptal preferimos medir características a lo largo de una historia de puntos, manteniendo el alcance como la variable pero prometiendo entregar un nivel mínimo de valor al cliente dentro del marco de tiempo establecido para el paquete de trabajo o todo el proyecto.
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.
Nuestro enfoque en costos y precios de software
En Toptal trabajamos estrechamente con nuestros clientes e ingenieros para emplear técnicas que promueven la confianza de los interesados en la duración del proyecto y sus costos. Trabajamos continuamente en la elaboración y adaptación de la planificación desde un nivel inicial alto hasta los detalles más granulares cuando es apropiado y necesario para evitar un desperdicio y para permitir un cambio gestionado.Los siguientes pasos son tomados para la elaboración de una estimación y precio fijo para proyectos: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.
2. Propuesta
Para tomar una decisión acerca de proceder o no con un proyecto, es necesario basar dicha decisión en datos bien establecidos: costo y duración. Esto es lo mínimo que deberías preguntarte: ¿Qué hace falta para crear el producto que queremos? ¿Cuándo podemos lanzarlo? ¿Se alineará con nuestra estrategia de negocio y finanzas?
Con los detalles mencionados, estamos en la posición de presentar una propuesta. Nuestros ingenieros son elegidos cuidadosamente de acuerdo a los requerimientos específicos del proyecto y trabajan junto con un jefe de proyecto para obtener al menos una solución técnica, un estimado de duración que nos diga el alcance conocido y un estimado de costo para completar el proyecto.
Como mencionamos antes, al principio de un proyecto es cuando sabemos menos sobre lo que se entregará. Deliberadamente mantenemos las características y el alcance en términos vagos, ya que si lo hiciéramos de otra forma indicaría que sabemos exactamente lo que hace falta. Un estimado en esta etapa sería impreciso, pero sería una guía en cuanto a seguir con el proyecto o no.
La propuesta es la primera herramienta para elaborar la duración y el costo del proyecto. Una vez que la propuesta es aceptada, podemos continuar y proveer una cotización de precio fijo.
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.
- Contrato de Precio Fijo
Una vez se acuerda el plan de lanzamiento, somos capaces de crear un presupuesto para un proyecto de contrato de precio fijo. Como ya se mencionó anteriormente es aconsejable mantener la duración del proyecto y el equipo fijo, y el alcance variable.
La cotización de un contrato de precio fijo se entrega junto a la declaración de trabajo y el calendario de pagos.
Mientras haya confianza, comunicación, colaboración y la disposición para entrar en el espíritu de un proyecto de software Ágil, todos los pasos mencionados nos permitirán dar una cuota con un grado realista de confianza que un producto sea entregado a tiempo y dentro del presupuesto. Por supuesto existen ocasiones en las que el proyecto será entregado antes o después de lo estipulado, por lo que lidiamos con estas variaciones con la mayor transparencia.
Técnicas de Estimación
La planificación y estimación Ágil está basada en un número de técnicas que un equipo de desarrollo pueden utilizar para ganar más confianza en su tamaño, esfuerzo, duración y costo. A continuación están algunas de las técnicas que usan nuestros equipos para estimar el tamaño y costo de un proyecto de software.
Tamaño de la Estimación
El tamaño del proyecto es en realidad un cálculo de su alcance, complejidad, dimensiones, riesgo y magnitud. Una analogía de esto sería saber si estamos construyendo la Torre Eiffel o la Gran Muralla China. La Torre Eiffel es una estructura alta, pesada y compleja que se construyó en un pequeño ambiente urbano. La Gran Muralla de China es una estructura relativamente sencilla pero larga y robusta que se expande por muchas millas en un terreno sinuoso.
Mientras que ambos serían grandes proyectos al entregar, su alcance, complejidad, dimensiones, magnitud y por ende su tamaño son diferentes.
Es importante manejar las expectaciones con estimados. Jamás son predicciones, compromisos o garantías. Cuando se discute el tamaño, duración, y costo total, siempre se trabaja dentro de rangos, para disminuir el riesgo, la incertidumbre y las incógnitas.
Las historias que representan las características de un producto tienen tamaños y estimados individualizados usando puntos de historia o días ideales. El número total de estas unidades define el tamaño general del proyecto.
Puntos de Historia
Los puntos de historia son una unidad métrica que representa el tamaño general de una historia de usuario. El tamaño de una historia, cuando se estima, puede incluir todos los aspectos de diseño, ingeniería, testing, revisión de código, integración, etc.
Cada tamaño de historia es relativo a otra historia. Por ejemplo, Historia A puede ser medida como 1 punto, Historia B como 2 puntos e Historia C como 3 puntos. Por lo que, Historia C es al menos tres veces el tamaño de la Historia A y al menos la mitad de lo grande que es la Historia B.
Si las siguientes historias en el backlog del producto tienen tamaños asociados:
| Historia | Tamaño |
| A | 1 |
| B | 5 |
| C | 3 |
| D | 1 |
| E | 2 |
El tamaño total del proyecto es 12 puntos de historia.
Días Ideales
Se trata de una medida de tamaño expresada en días. Elimina el concepto de los gastos generales, tales como interrupciones, actividades de planificación ágil, leer correos y otras actividades fuera del proyecto. Se concentra nada más en cuanto tardará en terminarse el mismo si trabajarás continuamente en algo sin interrupción, en lugar del tiempo transcurrido de principio a fin.
Normalmente, cuando se estima en un nivel alto en el que sabemos poco sobre el proyecto, se estimaría en días ideales ya que se trata de un concepto más sencillo para correlacionar con la experiencia e historia pasada que con un número abstracto como lo es un punto de historia. Cuando las historias están un nivel alto son más épicas con pocos detalles y posiblemente teniendo elementos adicionales cuando se desglosan más adelante.
Cuando se estima en un nivel más granular, por ejemplo una historia en un backlog de producto establecida, se puede utilizar cualquier enfoque y el equipo de ingeniería decidiría exactamente cual usar. Hay beneficios para ambos enfoques y cada equipo tendrá sus preferencias.
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.
Velocidad
La velocidad es una medida de la capacidad del equipo para terminar un trabajo en una determinada iteración (o sprint).
Se expresa como un rango, por ejemplo de 23 a 32 puntos de historia por sprint, sobre todo al principio de un proyecto. Generalmente, esto se debe a que a menos que el mismo equipo haya resuelto un problema similar, es difícil determinar cuál sería la velocidad del equipo. Nótese que nos referimos a la velocidad de un equipo y no la de un individuo.
Se utiliza la velocidad para planificar el lanzamiento y adaptar los planes y paquetes de trabajo mientras se progresa durante el proyecto, lo que permite ajustar nuestra suposición de cumplimiento con regularidad y precisión a lo largo de la ejecución.
Cuando comenzamos, nos vemos en la obligación de definir un rango de velocidad con pocos datos. Se pueden utilizar valores históricos, si el equipo y área de problema son iguales, lo cual no es probable. Existe la posibilidad de realizar una iteración para tener una idea de la velocidad con un equipo que esté trabajando en el proyecto, sin embargo esto es costoso y no funciona si aún se están tomando decisiones acerca de comenzar un proyecto. También se podría hacer un pronóstico.
El pronóstico de una velocidad incluye tomar varios sprints de historias y dividirlos en tareas que se realizan para completar la historia. Se estimaría el número de horas para cada tarea, lo cual incluye diseño, desarrollo, testing, entre otros, y evalúa la capacidad que el equipo tendría en un determinado sprint. Una capacidad de 70% para un equipo comprometido es una buena base. Por esto, en una situación simple, si el total de horas disponibles de un equipo es por ejemplo:
- 4 miembros de equipo * 2 semanas * 40 horas por semanas = 320 horas
- Multiplicado por el 70% de capacidad = 224 horas
- Súmale todas las tareas de características y deja de contar en 224
- Toma todas las características completadas, súmale los puntos de historia y tendrás la velocidad, digamos 36
- Designa 20% a cada lado para obtener un rango de lo más bajo y alto, para llegar a una velocidad estimada de 29 a 43 puntos de historia
La velocidad usualmente varía en las primeras 2 a 4 iteraciones y luego se estabiliza dentro de un pequeño rango de puntos. Por ello, se tiene un rango inicial antes de que el primer sprint fuera 29 a 43, al llegar al sprint 4, puede estabilizarse de 34 a 38. Lo que nos da más confianza en el pronóstico de la fecha de finalización.
Planes de Buffering para Riesgo e Incertidumbre
Todos los proyectos de software vienen ligados con un nivel de incertidumbre. Esa incertidumbre se convierte en menos a medida que avanza el proyecto y se conoce más sobre la tecnología, ambiente, rendimiento y las necesidades del cliente y usuarios.
Se disminuye esta incertidumbre con un buffer o regulador en la programación, lo cual se representa con un margen de error en la estimación y las incógnitas que no se pueden determinar antes que comience el desarrollo.
Normalmente, hay dos tipos de buffer: característica y programación. Como siempre se está definiendo un precio fijo para una fecha de entrega fija, es preferible usar el buffer de característica.
Este enfoque ofrece una estrategia de mitigación de riesgo creíble y le da al cliente confianza en lo que respecta a la entrega del proyecto, o lo que verán al finalizar el mismo.
Buffers de Características
Con un buffer de característica, se pronostica que se entregará un determinado conjunto de características pero más adelante se completará otro set de características. Esto debería mostrar el mínimo conjunto de características que el cliente considera necesarias para lanzar un producto factible, pero se podrían entregar más en el rango de tiempo determinado si las diferentes influencias internas y externas lo permiten.
Entonces, un cliente podría decidir que las características de mayor prioridad del backlog de un producto, sumando hasta 100 puntos de historia, son más importantes. Luego el cliente podría considerar características adicionales que agregan otros 30 puntos de historia. Si es así el equipo planearía entregar 130 puntos de historia, con un mínimo de 100 siendo completados al final de la fecha prevista para el contrato de precio fijo.
Reflexiones finales
El concepto Ágil puede ser de comprender y adaptar. Lo cual no es menos cierto cuando se trata de manejar temas sensibles como lo son el precio, alcance y duración. Desafortunadamente, sé que clientes exigentes desean que todo se arregle de inmediato y usualmente culpan al proveedor cuando todo comienza a desmoronarse. De igual forma, soy consciente de que algunos vendedores que no les gusta ceder, son insensibles y no responden a las necesidades del cliente. Cuando se decide tomar el camino de la metodología Ágil es fundamental tener confianza, buenas relaciones y excelente comunicación. Estos valores deben ser mantenidos por ambas partes a fin de mantener un proyecto saludable que beneficie a ambos, y brinde satisfacción y éxito para todos. Hay que mantener una mente abierta y una actitud constructiva para la colaboración y negociación, esta es la mejor forma de evitar que las relaciones decaigan.
En ocasiones a algunos clientes se les hace difícil ajustarse a la naturaleza adaptativa de la metodología Ágil y dejar la actitud de control y comando. No es fácil poner toda tu fe y confianza en un equipo que no conoces. La mayoría de las veces, los clientes querrán crear todas los requerimientos por adelantado a modo de especificación de lo que esperan recibir al momento de la entrega. Esto les da una impresión de confianza que el alcance de un proyecto está bien definido. Pero al final, esto es algo que no se materializa como un buen enfoque. Si el alcance y las demandas no son reales y se tiene que trabajar en base a ello debido al contrato, surgirán muchos problemas rápidamente.
Se sabe que al tomar este enfoque en métodos tradicionales, el alcance podría cambiar, incógnitas podrían revelarse o lo que creía el cliente quería ya no es verdad o es completamente diferente. Si se toma un enfoque adaptativo en cuanto a la fijación de precios, planificación y alcance le permite al cliente identificar su producto para que sea justo lo que necesita el mercado que busca alcanzar. Esto le permite a un proveedor ser receptivo, imaginativo y eficiente. Aprovechar la colaboración entre cliente y vendedor cuando se trata de una negociación de contrato es clave.
Los vendedores tienen que ser honestos y los clientes tienen que ser realistas desde el principio en cuanto a lo que se puede lograr. Un proveedor que hace promesas poco realistas sobre los objetivos y luego aumenta el costo podría obtener el contrato, pero pronto tendrá en sus manos un cliente insatisfecho. A menudo, relaciones se desmoronan debido a la falta de confianza entre ambas partes. La confianza debe construirse desde el principio y mantenerse a lo largo de un proyecto. Un vendedor debe ser flexible y cooperar cuando las necesidades cambian. Los clientes siempre quieren más; se trata de una consecuencia natural de hacer negocios. Debe haber un intercambio igualitario de valores que beneficie a ambos. Los clientes buscan crear un valor para su negocio. Los vendedore, deberían intentar crear un valor que les permite tener largas relaciones con sus clientes. Estudiar el Manifiesto de valores de la metodología Ágil al igual que sus principios es una base sólida para formar una larga, fuerte y equilibrada relación.
Conclusión
Ojalá esto te haya dado una idea de planificación, estimación, y definición de precios para un proyecto de software Agile. Todos los enfoques y técnicas descriptos aquí fueron diseñados para fomentar la confianza en un equipo y para promover la confianza de clientes en lo que se refiere a cuánto durará y costará construir un producto de software. Finalmente, fomentar la confianza cuando se trata de tomar una decisión para proceder.
Sigue estas guías y seguramente encontrarás una ruta satisfactoria para darle vida a tu próximo producto de software.
No hay comentarios:
Publicar un comentario