Traducido del inglés al español - www.onlinedoctranslator.

com

7
Estimación de costos y horarios

No hay datos sobre el futuro, solo estimaciones.1

Es muy difícil hacer una defensa enérgica, plausible y arriesgada en el trabajo de una estimación
que no se deriva de ningún método cuantitativo, respaldada por pocos datos y certificada
principalmente por las corazonadas de los gerentes.

Dr. Fred P. Brooks, Jr.2

Módulo 1: La naturaleza de las estimaciones

Hacer un juicio sobre el futuro, incluso con incertidumbre

Módulo 1 — Objetivos
• Discutir y explicar los aspectos únicos de las estimaciones ágiles.
• Discutir y explicar cómo la complejidad se abre paso en estimaciones ágiles.
• Discutir y explicar por qué lo suficientemente bueno es lo suficientemente bueno

Introducción a las estimaciones

Entonces, ¿qué es una estimación? Tenemos la versión del diccionario bastante fácil, como se proporciona a
través de google.com:
Estimar: Un cálculo o juicio aproximado del valor, número, cantidad o
extensión de algo.
Hay muchas cosas con las que podemos trabajar allí:

• Solo se necesitan aproximaciones sobre el futuro, por lo que podemos aplicar el

principio ágil de sólo lo suficiente precisión y exactitud para servir a nuestros
propósitos.

167
168 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

• Las estimaciones pueden ser un cálculo o un juicio, por lo que también funciona para Agile. A
algunos patrocinadores les gustan los números, pero otros dependen más de factores
subjetivos.
• Se pueden aplicar a casi cualquier cosa. Una vez más, desde una perspectiva de la acumulación sin
restricciones, eso también es bueno para la agilidad.

Aquí hay uno más:

• Deben incluir y ser consistentes con hechos del pasado. Ciertamente, este es
el punto de la amonestación del Dr. Brooks en la cita inicial.

Las estimaciones hablan de eventos futuros que pueden solamente describirse

probabilísticamente. Algunos gerentes pueden pensar que pueden apostar el futuro
al estimar que el costo o el cronograma alcanzarán un solo valor de puntos planeado,
pero estimar las soluciones de puntos suele ser una tontería. De manera más
realista, el objetivo de la estimación debería ser estimar los límites de un rango que
debería abarcar el resultado, y para ese rango, proporcionar una estimación de
confianza de si el resultado real estará dentro del rango.
He aquí un ejemplo: El equipo confía en que en 8 de cada 10 ensayos, la
acumulación se reducirá por completo en un rango de seis a ocho semanas.
¿Qué sucede en los otros dos ensayos? No se nos da información. Solo podemos
tomar de la estimación que en 2 de cada 10 ensayos, el proyecto tomará más de ocho
semanas; o el proyecto podría durar menos de seis semanas. En todos los casos, sin
embargo, el estándar es que la acumulación esquemado por completo.

Las estimaciones no son hechos

Un proyecto
consejo de gestión Invariablemente, lo más irritante de las estimaciones es su
propensión a confundirse con hechos, o peor aún, ¡un compromiso!

Estimaciones ágiles

Además de los requisitos, las estimaciones son probablemente el factor más influyente en
la previsibilidad de los resultados del proyecto. Los proyectos ágiles se gestionan en
función del rendimiento y los resultados, no de la actividad y tampoco tanto de la entrada
(es decir, el costo, el cronograma, el alcance). Como se discutió en el Capítulo 4, el enfoque
de gestión dominante es entregar un producto funcional.

Estimaciones ágiles

Un proyecto
consejo de gestión El primer principio de la estimación de proyectos ágiles es estimar
los resultados, no la actividad.
 Estimación de costos y horarios 169

Actividad y rendimiento
La estimación de los resultados sacará a la superficie la eterna tensión entre el
esfuerzo de buena fe y la finalización. El esfuerzo de buena fe es un compromiso de
trabajar con diligencia y consideración; de hecho, participar en la actividad. La
finalización, por otro lado, es un compromiso para producir un resultado medible y
valioso, en una palabra, rendimiento:

• Cada proyecto incluye alguna actividad que es un esfuerzo de buena fe, de hecho, un
nivel de esfuerzo
• El punto a comprender es que la actividad es solo un medio y no el fin
• Porque el fin es lo único que valoran los clientes, la estimación ágil cambia el
enfoque a los artículos finales que son útiles y deseados

Los diagramas de Gantt tradicionales orientados a la actividad y las redes de actividad dan paso a la
programación de iteraciones y lanzamientos orientados al rendimiento. En lugar de centrarse en la
actividad, el objetivo final es lograr el rendimiento de la manera más eficaz posible.
Como se estableció anteriormente, el rendimiento y la complejidad de la
acumulación son los dos parámetros que gobiernan la producción del equipo. Si es
difícil o incluso imposible imaginar todos los requisitos, es igualmente difícil imaginar
los esfuerzos necesarios para implementarlos. Estos problemas se resumen en dos
palabras: complejidad e incertidumbre.

Complejidad e incertidumbre

• La complejidad es la calidad descrita por la cantidad de formas en

que las unidades pueden interactuar, una medida de cuántos
estados únicos puede estar un sistema y cuántas respuestas provoca
Un proyecto
un estímulo.
consejo de gestión
• La complejidad es lo que transforma una oportunidad de costo-beneficio
en una amenaza de costo a consecuencias.
• La incertidumbre es lo que no se puede conocer hasta el momento oportuno.

• La incertidumbre es un riesgo sin conocimiento de un evento

desfavorable o mitigación neutralizante.

Entendiendo la complejidad
Para manejar la complejidad se requiere cierta comprensión de sus propiedades. La
complejidad no tiene nada mejor que una definición imprecisa. De hecho, hay decenas de
definiciones. Sin embargo, para simplificar las cosas, decimos que son las interacciones
conocidas, cognoscibles y posiblemente incognoscibles de un gran número de elementos
del sistema.
170 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

La complejidad también puede significar redundancia; más de un elemento del

sistema es capaz de manejar una función. Sin embargo, es posible que no se sepa
qué elemento actúa en qué momento y en qué condiciones. También puede significar
que se soliciten diseños y funciones innecesarios pero que no se utilicen realmente.
La complejidad no es la ausencia de simplicidad.

Complejo y simple

Un proyecto
consejo de gestión El sistema más simple que es mínimamente satisfactorio puede ser
complejo, pero el corolario es cierto: la simplicidad es la ausencia de
complejidad innecesaria.

La complejidad coloca a los sistemas al borde del caos, lo que significa que un estímulo
relativamente menor podría generar resultados difíciles de manejar e impredecibles. Los
sistemas complejos tienen una alta entropía, lo que significa que los sistemas complejos
pueden adquirir o estar en muchos estados, algunos más estables que otros, y no todos
los desarrolladores y evaluadores los conocen. La complejidad está influenciada por la N2
efecto (discutido en el Capítulo 11 y el glosario), por el cual el número de interacciones
entre elementos aumenta casi como el cuadrado del número de elementos. Incluso una N
pequeña, digamos 20, significa casi 400 formas de que ocurra una interacción, y cada una
de ellas tiene condiciones, desencadenantes y efectos posteriores.
Los sistemas que nos preocupan tienen muchos elementos, de hecho, muchísimos
elementos, más de los que una persona puede tener en cuenta. Extendido a sus
interdependencias, los números pueden ser abrumadores. Como se discutió en el Capítulo
4, la complejidad influye en las pruebas, la garantía de calidad y el soporte posterior al producto.

Complejidad organizada

• Warren Weaver describe los sistemas de elementos interrelacionados

como si tuvieran una complejidad organizada.3
Un proyecto
consejo de gestión • La complejidad organizada significa que, con el tiempo,
dominarán determinadas interacciones; sus propiedades se
pueden observar, probar y medir.
• Otras interacciones, aunque posibles, ocurren con tan poca
frecuencia que son operacionalmente intrascendentes.

La complejidad complica la estimación:

• Los parámetros clave de estimación, como la velocidad, están sujetos a la incertidumbre

que surge de interacciones imprevistas entre los elementos de la solución.
 Estimación de costos y horarios 171

• Las interacciones con los sistemas heredados ponen en juego muchos más elementos, lo
que impulsa la N2 efectos más altos y haciendo las pruebas mucho más complicadas.

• Las pruebas unitarias automatizadas simples son menos reveladoras; la integración con la base
instalada, siempre más complicada que las pruebas unitarias, se convierte en un factor cada vez
más importante en el rendimiento.
• Permitir lo imprevisible requiere descontar el rendimiento, al igual que
descontar los beneficios futuros por circunstancias imprevistas.

En el dominio ágil, la complejidad es un problema económico y un problema de

rendimiento. Cuanto más compleja sea la acumulación, más tiempo se necesita para que
un rendimiento determinado elimine la acumulación. El tiempo, a su vez, afecta el valor
presente de los beneficios y los gastos operativos del proyecto. Se requerirán intercambios
entre lo bueno, lo mejor y lo mejor.

Las estimaciones se convierten en compromisos, un problema para los gerentes

Todos los patrocinadores de proyectos solicitan estimaciones: estimaciones de los recursos financieros
necesarios, estimaciones de los principales hitos y estimaciones para respaldar otros indicadores clave
de rendimiento del cuadro de mando.
Este último es donde entra el problema; Se debe tener cuidado. Todo director
de proyecto sabe que las estimaciones no son estimaciones por mucho tiempo.
Incluso si el patrocinador ha usado la palabra estimación, más a menudo está
pensando, no exceda, o me diga cuánto va a costar y cuándo lo voy a conseguir.
Y cuanto más arriba en la cadena se reenvía la estimación, más salvedades
pierde.
Lamentablemente, con demasiada frecuencia las estimaciones se convierten en
compromisos casi tan pronto como se pronuncian. Sabiendo esto, la prudencia exige algunos
ajustes por riesgo para establecer un intervalo de confianza adecuado. En el contexto ágil, se
encuentran disponibles varias técnicas:

• Solo proporcione gama de posibilidades estimados; evitar compromisos de un solo

punto
• Almacene cada lanzamiento con un sin contenido cuadro de tiempo para proteger el hito del
resultado
• Programe menos del 80% de la referencia de rendimiento para salir
espacio en blanco para absorber resultados imprevistos
• Estimar tareas basadas en el consenso de estimadores independientes, para reducir
así el sesgo.
• Considere la experiencia previa para ajustar los puntos de referencia a la situación actual.
172 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

Intervalo de confianza

• Un intervalo de confianza expresa la probabilidad de que una

estimación caiga dentro de los límites de un rango, llamado
Un proyecto intervalo de confianza.
consejo de gestión
• Por lo general, se expresa una confianza sobre la probabilidad
de que una estimación supere el valor máximo del intervalo y
otra expresión de confianza sobre la probabilidad de que una
estimación sea menor que el valor mínimo del intervalo. En el
Apéndice de este capítulo se muestra un ejemplo.

Siguiendo los principios ágiles, la mejor manera de transmitir comprensión y resolver

diferencias es cara a cara con la empresa. Aun así, es probable que haya una brecha
residual entre el plan del proyecto y el plan de negocios. Cuando la brecha residual está lo
suficientemente cerca, el gerente del proyecto sigue adelante, aceptando algún riesgo.
¿Qué riesgo? El riesgo es que al adaptarse a la oportunidad, iteración por iteración, se
encontrarán los medios para lograr los objetivos comerciales y satisfacer al cliente. Lo
suficientemente cerca es a menudo tanta precisión como necesita un proyecto; lo
suficientemente cerca es ágil.

Las estimaciones caen dentro de un rango

Todas las estimaciones, independientemente de la metodología, son, por definición,

probabilísticas, lo que significa que un resultado real no se conoce con certeza, pero es
probable que esté contenido dentro de un rango de valores. Como ejemplo, un
desarrollador puede estimar que un objeto requiere 100 horas + 20 - 10 horas, lo que
significa que el desarrollador tiene una gran confianza en que el rango de 90 a 120 horas
cubre el esfuerzo real.
Una forma de tener en cuenta todas las posibilidades es promediar todas las
posibilidades, pero un promedio aritmético simple supone que todos los valores en el
rango son igualmente probables, aunque generalmente no lo son. Se obtiene una mejor
estimación cuando se tiene en cuenta la información sobre probabilidades dentro del
rango. Entonces, en lugar de simplemente sumar todos los valores y dividir por el número
de posibilidades, haga esto:

• Tome la cantidad de posibilidades como un conjunto de puntos

• Pondere cada valor, usando puntos, a su juicio sobre su peso total o
contribución en la suma (el total de pesos debe sumarse al total del
grupo)
• Multiplique cada valor de rango por los puntos asignados y sume los productos
de valor-puntos
• Luego, como antes, divida la suma total por el número de puntos
 Estimación de costos y horarios 173

El resultado es un promedio ponderado por riesgo llamado valor esperado.

El valor esperado es el número que mejor representa todo el rango de
posibilidades de 90 a 120 horas.
Un ejemplo de este enfoque se encuentra en el Apéndice de este capítulo.

Suficientemente bueno

Todo esto sugiere que la precisión y exactitud en las estimaciones solo necesitan ser
suficientemente bueno—En otras palabras, lo suficientemente bueno para cumplir el propósito del
proyecto de asignar suficientes recursos pero no demasiados, y ciertamente no muy pocos.
No existe una definición objetiva de suficientemente bueno. Para fines ágiles,
suficientemente bueno significa tener solo suficiente precisión y exactitud de
estimación para que se alcance una comprensión razonable del rango. No tiene
sentido esforzarse en estimar un 98 por ciento, o incluso más, de certeza acerca de
un número que es muy probable que cambie. La naturaleza de los proyectos ágiles
es ser flexible y adaptable a los requisitos, lo que requiere estimaciones adaptables y
flexibles.

Las estimaciones son valiosas incluso si son imprecisas e inexactas

• No se debe gastar dinero y no se debe hacer ningún esfuerzo

Un proyecto sin prestar atención al valor devuelto.
consejo de gestión • En todos los aspectos, el objetivo y propósito del proyecto es
mejorar las cosas para todos sus beneficiarios.
• Aunque las estimaciones, por diseño, no son demasiado precisas, no
obstante tienen un propósito valioso para enmarcar el valor.

Módulo 1: Discusión para el pensamiento crítico

Si ha experimentado que el negocio lo mantiene firmemente en las estimaciones, en
lugar de comprender que existe un grado de incertidumbre en torno a cualquier
estimación, ¿cree que la práctica ágil de estimar con una granularidad de una
iteración o versión ayudaría a mitigar los malentendidos?

Módulo 2: Impulsores en el costo y el cronograma

Complejidad de la cartera de pedidos, productividad y escala de los equipos

Módulo 2 — Objetivos
• Examinar los factores que impulsan los costos y programar el consumo de recursos
con métodos ágiles.
174 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

Backlog y Productividad
La acumulación, la productividad de los equipos y la cantidad de equipos que trabajan impulsan
en gran medida los costos y el cronograma. Estos son los puntos más importantes:

• La productividad del equipo solo es estable para una ola de planificación; a partir de entonces, las
circunstancias pueden cambiar.
• Las estimaciones se aplazan hasta justo a tiempo basado en un examen detallado de
la acumulación.
• Luego, las estimaciones se extienden a las iteraciones posteriores en la ola,
entendiendo que la parte de verificación y acción del ciclo de iteración afectará la
acumulación de requisitos y requerirá refinamientos de las estimaciones.

La mayor incertidumbre es la cantidad de requisitos, historias y casos de uso

procesables y su complejidad. La acumulación del proyecto es el punto de partida,
pero los equipos esperan que la acumulación se modifique durante el transcurso de la
proyecto.

Cambio de pronóstico
Un proyecto
consejo de gestión Por lo general, no existe un pronóstico confiable para el grado de
cambio esperado.

Por otro lado, hay algunos componentes de la productividad que entran en una
estimación que son relativamente estables:

• Los cuadros de tiempo son fijos y deterministas.

• El trabajo en curso de Kanban (WIP) es controlable.
• Todos los equipos esperan una baja rotación y están integrados en un pequeño rango de 7
a 12 miembros.
• Cada equipo tiene una capacidad de rendimiento (velocidad) que se estima o se conoce mediante
evaluaciones comparativas dentro de un rango razonablemente pequeño.
• La confianza en el valor esperado de la velocidad es alta.

Por lo tanto, el cronograma estimado, y en gran medida el costo estimado,

depende del número de iteraciones necesarias para liquidar la acumulación, del
número de iteraciones que el patrocinador elige pagar o de la productividad del
equipo durante una iteración. El material de la Tabla 7.1 resume estas ideas.

Los factores ambientales que influyen en las estimaciones de productividad se resumen

en la Tabla 7.2.
 Estimación de costos y horarios 175

Cuadro 7.1 Resumen de factores de complejidad relacionados con el costo y el cronograma

Parámetro Fuerza de influencia Efectos de costo y cronograma

Número estimado de • Alto costo • Impulsa directamente la cantidad total de unidades de

requisitos en el • Moderado en rendimiento necesarias para liquidar la acumulación.
nivel de historia de usuario
cronología
• Cada unidad tiene un costo

• Cada unidad se desarrolla dentro de una iteración

Complejidad estimada • Alto costo • Impulsa directamente el número total de unidades de

de requisitos individuales • Moderado en rendimiento necesarias para liquidar la acumulación.
mentos cronología
• Cada unidad tiene un costo

• Cada unidad se desarrolla dentro de una iteración

Velocidad estimada Alto costo y • Impulsa directamente el cronograma y el costo

unidades de rendimiento cronograma general
por unidad de tiempo • El rango de la estimación de velocidad afecta
la predictibilidad del éxito de la iteración.

Cuadro 7.2 Resumen de los impulsores ambientales sobre el costo y el cronograma

Fuerza de
Parámetro influencia Efectos de costo y cronograma

Número de miembros del equipo y Gran influencia en • El rendimiento por encima o por
combinación de habilidades, debajo de la velocidad esperada afecta la velocidad
experiencia y cohesión. • La pérdida de mano de obra del 15 por ciento es
una métrica de buenas prácticas para
proyectos que duran siete meses o más.

Disponibilidad de factores ambientales Influencia moderada El entorno afecta el desempeño del

favorables como colocación, ence en la velocidad equipo
herramientas, entrenamiento y soporte
de infraestructura.

Dependencias con otros equipos y • Bajo si se secuencia • Las dependencias afectan la capacidad de una

flujos de trabajo correctamente y iteración para comenzar según lo planeado.

amortiguado
• Las dependencias entre equipos pueden
• No incluido afectar el orden de la funcionalidad
en la velocidad entregada sin afectar el costo general y el
estimados cronograma.

Ruta crítica o ruta no crítica No todas las iteraciones Escasez de recursos del tema
está en el camino los expertos afectan el alcance entregado
crítico Puede surgir la oportunidad de
compensar el déficit en el alcance sin
afectar el cronograma, pero a un costo
Si la iteración no es parte de la ruta
crítica, puede carecer de un recurso
necesario y perder el objetivo del
alcance.
176 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

Alcance, complejidad y velocidad

La estimación en el espacio ágil se centra en tres parámetros:

1. Alcance: Número de requisitos, historias o casos de uso, para incluir la deuda

técnica y funcional, en la cartera de pedidos del proyecto al comienzo del
proyecto, más las otras iteraciones auxiliares para la planificación y la
ingeniería, y la liberación para integración y producción.
2. Complejidad: Las interrelaciones de los componentes del backlog y las
interrelaciones con la base instalada con la que debe ocurrir la
integración.
3. Velocidad del equipo: El ritmo al que se puede entregar el rendimiento; el
ritmo al que el WIP puede moverse a través de los pasos Kanban

A partir de estos tres, se puede estimar el cronograma y el costo del proyecto inicial. Pero, como
se señaló anteriormente, el cambio en la cartera de pedidos del proyecto simplemente no es
predecible. A medida que madura cada ola de planificación, la estimación comienza de nuevo
para la próxima ola que llega.
Por supuesto, esto nos devuelve a la discusión en el Capítulo 4 sobre cuándo el
proyecto está hecho. Ciertamente, una estimación de la programación es el número
de iteraciones de duración. T que se ajuste al presupuesto. Y el número de
iteraciones debe incluir todas las iteraciones de planificación, arquitectura e
ingeniería, búferes y versiones, en otras palabras, el paquete completo de alcance. La
tabla 7.3 enumera las prácticas de estimación que son habituales en la industria.

Derivaciones de costos y cronogramas

Cada gerente de proyecto tiene experiencia en la gestión de costos y cronogramas, y todos

saben que uno afecta al otro. Todos sabemos que el costo y el cronograma son
interdependientes, por lo que sus planes y estimaciones están entrelazados. Por razones que se
discutirán y como era de esperar, el costo de la mano de obra sigue muy de cerca el esfuerzo. A
medida que aumenta el esfuerzo, también lo hace su costo de la misma manera: el doble del
esfuerzo, el doble de su costo, al menos en una primera aproximación. Pero el esfuerzo no tiene
el mismo efecto en el horario. Sin duda, el cronograma a menudo se extiende cuando el esfuerzo
va por encima del plan. ¿Qué director de proyecto no ha oído hablar de la ley de Brooks?4

Ley de Brooks

Agregar mano de obra a un proyecto de software tardío lo hace más tarde.

"añadir más efectivos a un proyecto de software en retraso, lo retrasará

más".
 Estimación de costos y horarios 177

Cuadro 7.3 Prácticas convencionales de estimación

Práctica Comentario
De arriba hacia abajo No tanto una estimación como un juicio de valor, un presupuesto de tiempo, dólares
asignación o ambos se distribuye proporcionalmente entre características y funciones de
acuerdo con la actitud del cliente sobre la importancia y la urgencia.

Similar a o • La estimación se toma del historial de costos de un sistema, producto o tarea

análogo similar.
• La estimación se ajusta para los factores que pueden haber cambiado,
como la inflación, el entorno y los requisitos específicos que ya no son
relevantes.
Los nuevos requisitos se estiman proporcionalmente a su análogo más cercano.

Parámetro o • La estimación se toma en base a la multiplicación de unidades por un parámetro, como

impulsado por modelo dólares por página por el número de páginas.

• Los parámetros provienen de puntos de referencia históricos.

Los modelos como COCOMO II se completan con datos paramétricos, se aplican

varios multiplicadores y los resultados de muchos factores paramétricos se suman en
un resultado final.1

Construido con palo • Cada elemento se evalúa individualmente por el costo probable.
de abajo hacia arriba
• Estimaciones similares, estimaciones de parámetros, modelos y simulaciones pueden
combinarse con evaluaciones detalladas, análisis y creación de prototipos para construir
una estimación a partir del elemento no divisible más bajo.

Desde que Brooks proclamó su ley en 1975, muchos analistas han examinado el
comportamiento de los horarios a medida que se agregan más personas a la mezcla
de proyectos. De su trabajo, ahora hay mucha evidencia empírica disponible para
respaldar la previsión. Parte de esa información se utilizará en el material que sigue.
El Capítulo 6 discutió el proceso de planificación para proyectos ágiles comenzando con
el plan de negocios. Los hitos comerciales de alto nivel y los objetivos de asequibilidad se
originan en el plan comercial. Sin embargo, ese es el aspecto comercial del balance
general del proyecto. Las estimaciones de costos y cronogramas correspondientes
realizadas por el proyecto completan el otro lado, de acuerdo con estos dos puntos
importantes:

1. La duración del cronograma se obtiene aplicando el rendimiento disponible al

alcance del caso de negocio y continúa derivándose después de cada
iteración.
2. El costo se deriva del esfuerzo por cumplir con los requisitos, como en todas
las metodologías, pero el giro ágil es que los requisitos nunca se congelan; la
plataforma de requisitos permanece abierta durante casi toda la duración
del proyecto.

En el panorama general, los requisitos pueden cambiar a medida que el maestro del producto
busca una solución de mejor valor. Obviamente, una plataforma de requisitos abierta significa
178 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

que el costo y la duración siempre están en juego, limitados en última instancia por el
límite de asequibilidad establecido en el plan de negocios. La duración no se estima de la
manera habitual en las metodologías de ciclo de vida de desarrollo de proyectos
impulsados por planes porque los requisitos solo se estabilizan gradualmente para
cada iteración.

Costo y duración

• Los planes cambian con cada iteración.

• El costo y la duración del cronograma se derivan del
Un proyecto rendimiento total requerido para reducir todos los requisitos.
consejo de gestión
• Los requisitos, sin embargo, no son fijos; en las
metodologías ágiles, se anima al cliente, ya sea interno o
externo, a interpretar constantemente lo que necesita.
• El costo y la duración no son fijos, pero las partes interesadas
pueden votar después de cada lanzamiento si continúan.

Módulo 2: Discusión para el pensamiento crítico

En este módulo decimos que las estimaciones se aplazan hasta justo a tiempo, de modo
que la estimación se aplica a la cartera de pedidos en su composición más estable. Algunos
podrían decir que tales prácticas justo a tiempo equivalen a ninguna estimación en
absoluto, argumentando que si no ha hecho una estimación cuando el trabajo es incierto,
¿cuál es el punto de hacer una estimación justo antes de que comience el trabajo cuando
se conoce el trabajo? ? ¿Qué les diría a los críticos de hacer estimaciones?

Módulo 3: Estimaciones de construcción

Ninguna estimación sobrevive al contacto con la realidad

Módulo 3 — Objetivos
• Discutir y explicar varias prácticas de estimación comunes en proyectos
ágiles.
• Discutir y explicar los efectos de la dotación de personal en las estimaciones.

Elaboración de una estimación: métrica y escala

Para construir una estimación, concéntrese primero en los elementos de la Tabla 7.1, que
requieren estimación o evaluación comparativa: complejidad y velocidad de los requisitos.
El enfoque fundamental para la estimación se basa en dos principios:
 Estimación de costos y horarios 179

1. La diversificación reduce el riesgo

2. Los puntos de referencia brindan un puerto seguro en caso de tormenta

Para diversificar el riesgo de que un estimador pueda estar equivocado, contrate a muchos
estimadores independientes. Indique a cada experto que analice el mismo problema al mismo
tiempo y proporcione una estimación. Luego combine todas las estimaciones independientes de
alguna manera acordada para llegar a un consenso.
Para incorporar puntos de referencia, compare su esfuerzo con un estándar
comprendido, haciendo ajustes para circunstancias únicas. Se necesitan cuatro
elementos para diversificar y comparar:

• Un proceso de evaluación independiente por más de un estimador

• Un proceso y un medio para combinar los resultados del estimador para obtener una estimación de
consenso.
• Un proceso para comparar y hacer ajustes a un punto de referencia.
• Un sistema de puntuación de peso relativo para la complejidad

Estos elementos se amplían aún más:

• Proceso de evaluación y consenso: Un proceso recomendado para la evaluación
independiente con resultados combinados se denomina Delphi de banda ancha. El
Delphi de banda ancha se describirá en las secciones siguientes.
• Comparar y hacer ajustes: Un buen punto de referencia será una unidad de
alcance ya completada y en producción sobre la que el equipo tiene un buen
conocimiento. Realizar ajustes proporcionales para la complejidad funcional y
de las características, el estado de los requisitos a medida que iban entrando, el
entorno que prevalecía, la experiencia y cohesión del equipo en ese momento y
la participación del cliente.
• Sistema de puntuación: un sistema de puntuación tendrá dos elementos:

1. Una definición inequívoca de qué puntuar

2. La escala y la métrica de la puntuación.

Hay muchas ideas sobre qué puntuar: historias de negocios, escenarios y temas, casos de
uso e historias de usuarios; todos estos y cualquiera de estos son candidatos.

Consistencia sobre métrica

Un proyecto
consejo de gestión El punto importante no es qué métrica elegir, ¡sino elegir
una y luego ser consistente y repetible!

La métrica, o unidad de medida, puede ser cualquiera de muchas posibilidades. La lista común son los puntos
de función, los puntos de características, los puntos de la historia o los puntos estándar o ideales.

La métrica, o unidad de medida, puede ser cualquiera de muchas posibilidades. La lista común
son los puntos de función, los puntos de características, los puntos de la historia o los días
estándar o ideales.
180 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

dias. Estos no son medidas de actividad; son medidas de pro-

inducidos. Estas no son medidas de actividad; son medidas del producto producido.

Actividad versus producto

Un proyecto • No caiga en la trampa de centrar las estimaciones en la actividad.

consejo de gestión
• Lo que se necesita para una estimación unitaria es el esfuerzo que debe
realizarse dentro de un cuadro de tiempo prescrito para producir una
unidad de producto en un nivel estimado de complejidad.

Estimación de puntos de historia

Para fines de discusión e ilustración, nos centraremos en el punto de la historia. Los

puntos de la historia no son particularmente mejores que los demás, pero en el espíritu de
¡elegir uno!, El punto de la historia es nuestra elección. No hay una dimensión asignada a un punto de
la historia; la métrica es un número adimensional. No existe una definición exacta de un punto de la
historia, pero definimos un punto de la historia de esta manera:

Punto de historia

Un punto de la historia es una cantidad de esfuerzo para desarrollar una unidad de producto con una
complejidad relativa mínima; en efecto, un punto de la historia da como resultado una unidad de resultado.

En este sentido, pensamos en una iteración que ofrece tantos puntos de resultado de la historia.
Cuanto más se valora un requisito en los puntos de la historia, más alcance y complejidad se
representa. El esfuerzo registra los puntos con una proporción de 1 a 1: el doble de puntos, el
doble del esfuerzo.

Requiere calibración
Para calibrar el esfuerzo de un punto de la historia, el equipo hace estas cosas:

• Primero, acuerde la granularidad: el grano de la descomposición de los requisitos. Un

grano demasiado fino pierde cohesión; un grano demasiado grande oscurece los
detalles. Decidir el grano es un juicio que debe ser considerado, debatido y
acordado por el equipo.
• Una vez que se han descompuesto los requisitos, el equipo selecciona un
ejemplo del requisito más simple y también uno que parece un punto
medio en complejidad.
• Luego, al requisito más simple se le asigna el valor más bajo de puntos en la escala y
se convierte en un punto de referencia para la complejidad más baja.
 Estimación de costos y horarios 181

• De manera similar, al requisito de complejidad media se le asigna un valor de escala

media. Los valores numéricos reales dependen completamente de la escala elegida.

La escala es el número de puntos asignables. La escala es simplemente un

medio para establecer la diferencia relativa entre unidades. La escala puede ser
los números del 1 al 20 o del 10 al 200; la escala real es irrelevante para el
resultados.

Hacer frente a la magnitud

Un proyecto
consejo de gestión En general, se acepta que las personas pueden afrontar eficazmente un orden
de magnitud: de 1 a 10. Más allá de ese rango, a las personas les resulta muy
difícil asignar valores diferentes de manera significativa.5

Una idea importante a tener en cuenta es que, si un objeto que se estima no parece
encajar dentro del rango, entonces el objeto se juzga muy complejo y por lo tanto
fuera de rango. En este caso, una buena práctica es descomponer el objeto muy
complejo en componentes menos complejos y estimarlos como una colección.

Recuerde del Capítulo 4 que la descomposición es una forma de diversidad. La

diversificación de un objeto complejo por descomposición reducirá la incertidumbre
general que rodea al objeto. Sin embargo, el rendimiento de los objetos descompuestos
puede inducir a error con respecto a cómo se comportará el objeto complejo cuando todas
las partes estén presentes e interfuncionen.

Estimación de la velocidad

En el ejemplo anterior, se asumió que el equipo se había comparado a sí mismo con un

rendimiento de 20 puntos de historia por iteración, ± 2 puntos. Hay algunas formas de
establecer este punto de referencia:

• Si el equipo ha estado unido por un tiempo, entonces el desempeño pasado en otras

iteraciones es el mejor indicador
• Si el equipo no ha estado unido o si el entorno ha cambiado con frecuencia,
entonces el equipo podría ejecutar un desarrollo de práctica o ejecutar una
simulación en un par de historias para comparar su desempeño.

• El líder del equipo y el gerente del proyecto pueden estar de acuerdo en que el equipo es
similar a otros equipos para los que existe un buen punto de referencia. Después de las
primeras dos iteraciones, el equipo encontrará su propia marca.
182 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

Estimación de la complejidad

Al hacer estimaciones, la coherencia se valora más que la precisión para las

primeras dos iteraciones, porque con un enfoque coherente, la mejora
continua es posible. Considere estos dos puntos:
1. Las mismas personas deben hacer la estimación cada vez. Las experiencias y
sesgos de los estimadores tendrán una gran influencia en los resultados. Los
métodos ágiles cuentan con la corrección adaptativa para suavizar las cosas,
pero dicha adaptación requiere que el equipo permanezca unido y se
involucre constantemente en todas las estimaciones.
2. Se deben utilizar las mismas herramientas o práctica de estimación, porque
nuevamente, existen sesgos en cualquier práctica que solo pueden neutralizarse
con el tiempo y la experiencia.

Hay varias alternativas de escala. Las alternativas más populares se dan en la Tabla
7.4. Dos de las tres escalas que se muestran son no lineales. El propósito de la no
linealidad es forzar alguna separación entre las estimaciones de complejidad. En
otras palabras, es más significativo decir que algo es dos o tres veces más complejo
que decir que algo es 1,25 veces más complejo. La precisión solo debe ser lo
suficientemente buena para que el equipo haga su trabajo; demasiada precisión es
injustificada. Por estas razones, tanto el binario como el de Fibonacci
las escalas se utilizan con mayor frecuencia.

Cuadro 7.4 Escalas de estimación populares

Escala Comentario
• Una escala lineal de aproximadamente 1 a 10, todos los números enteros disponibles como una posible puntuación

de complejidad.

• No “ayuda” directamente a separar los grados de complejidad del curso entre bajo,
Lineal
medio y alto.
• Sin embargo, agrupar como se muestra es una forma eficaz de utilizar la
escala lineal: Bajo 1, 2, 3 ... Medio 4, 5, 7 ... Alto 7, 8, 9 ... Muy alto 10
• Una escala binaria de aproximadamente 1 a 32, la secuencia es 1, 2, 4, 8, 16, 32 como las únicas
puntuaciones de complejidad posibles
Binario
• Ayuda a separar los grados de complejidad del curso al permitir solo los valores específicos
en la escala.

• Una escala de Fibonacci de aproximadamente 1-21, la secuencia es 1, 2, 3, 5, 8, 13, 21. En

esta escala, cada número es la suma de los dos números anteriores.
• A algunos les gusta esta escala mejor que el binario para separar los valores de complejidad, pero es una
Fibonacci cuestión de criterio

• La secuencia de Fibonacci se utiliza en muchos tipos de análisis, pero en el contexto de la

complejidad de los requisitos, sus propiedades no son materialmente superiores a la
escala binaria.
 Estimación de costos y horarios 183

Un proceso de estimación: Delphi y Poker

Las prácticas de estimación, como el método Delphi y el póquer de planificación,
brindan asistencia al proceso de estimación. Para ver cómo se utilizan, los
aplicaremos alestimar el paso de complejidad en el escenario que se presenta en el
Apéndice, Tabla A7.1.

Método Delphi
El método Delphi es un enfoque probado y verdadero desarrollado en 1948 por Rand
Corporation para abordar las incertidumbres que rodean a las tecnologías de
defensa emergentes. En una variante más actualizada, Barry Boehm y John Farquhar
expandieron y popularizaron el trabajo de estudio que Farquhar realizó en 1970.
El estudio de Farquhar comparó la precisión de las estimaciones de Delphi con
estimaciones del mismo problema a partir de una simple colaboración grupal. Boehm y
Farquhar llegaron a un proceso que llamaronDelphi de banda ancha que a su vez ha sido
adaptado y actualizado más recientemente por otros profesionales.6

El método Delphi

Un proyecto • En cualquier variante del método Delphi, la esencia del asunto es

consejo de gestión que cada miembro del equipo estima de forma independiente.
• Un proceso de construcción de consenso proporciona un medio para llegar a
una estimación de equipo a partir de todas las estimaciones independientes.

En un enfoque convencional de Delphi, el proceso funciona así:

• Un facilitador le da a cada estimador información sobre la tarea de estimación;

puede haber una discusión preliminar con el facilitador para comprender los
problemas.
• Los estimadores trabajan de forma independiente y privada para llegar a una estimación. La
privacidad garantiza que el estimador no se vea influenciado por la reputación y los
sesgos de los otros estimadores, ni se vea afectado por lealtades personales y políticas
organizacionales.
• Un facilitador trabaja en privado con cada estimador para comprender su punto
de vista; el facilitador proporciona a cada uno el beneficio de las otras
estimaciones, aunque de forma anónima.
• Los estimadores pueden reconsiderar y cambiar su estimación en función de la
nueva información. El proceso continúa hasta que el facilitador tiene suficiente
información para recomendar un presupuesto.

No hay ningún requisito que indique que todos los estimadores están de acuerdo con la
estimación tomada por el director del proyecto.
184 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

Delphi en el diseño de sistemas

En sistemas de alta confiabilidad, se pueden emplear programas de software redundantes

desarrollados independientemente para votar sobre una respuesta adecuada del sistema a un
estímulo. Esta es una forma de metodología Delphi aplicada al diseño de sistemas.
La teoría es que si una versión de un programa se ejecuta y devuelve una respuesta
incorrecta, otras versiones de programas redundantes pero independientes no tendrán el
error y, colectivamente, votarán por la representación incorrecta.

Delphi y Agile
En su forma original, Delphi es incompatible con los principios ágiles. Los principios ágiles
requieren la colaboración pública entre los miembros del equipo. Por otro lado,
simplemente promediar las respuestas de una colaboración simple tiene algunos
problemas estructurales. Por ejemplo, en un promedio simple, un valor atípico puede
sesgar el promedio. Y están los intangibles a considerar. Por la fuerza de la personalidad,
un estimador agresivo puede sesgar a todo el equipo hacia un solo punto de vista.
Wideband Delphi es el término medio entre Delphi y la colaboración simple.
Es ligeramente diferente de su padre; la etiqueta de banda ancha proviene del
aumento de las comunicaciones y la colaboración agregadas al método Delphi
más privado.
Así es como funciona Delphi de banda ancha:

• El director del proyecto convoca al equipo de estimación para una

colaboración inicial y una discusión grupal.
• Se proporciona información del trabajo atrasado, la narrativa y otras fuentes.
• Luego, cada estimador trabaja de forma privada e independiente en la primera
estimación.
• Las rondas posteriores de reestimación son colaborativas, y cada estimador
tiene la oportunidad de explicar su estimación.
• El proceso finaliza cuando el grupo desarrolla un consenso satisfactorio.

Planificación de póquer

En una implementación popular de Delphi de banda ancha para proyectos ágiles, se juega
un juego llamado póquer de planificación ágil.7 Cada jugador tiene una mano de cartas con
todos los números de la escala. Por lo general, se usa la escala binaria o de Fibonacci,
pero, como sabemos, la escala es en gran medida irrelevante si se aplica consistentemente
de un equipo a otro.
Estos son los pasos:

1. En el primer paso del juego, después de una discusión inicial con el

facilitador y después de recibir una mano, cada jugador hace su primera
En el primer paso del juego, después de una discusión inicial con el facilitador y después de que se le
reparta una mano, cada jugador hace su primera estimación dando la vuelta a la carta que eligió. Para
acercarnos más a la forma en que se juega al póquer real, todos muestran su tarjeta al mismo tiempo.
En parte, la rotación simultánea de tarjetas es para evitar que los estimadores cambien su estimación
después de ver las otras tarjetas. Estimación de costos y horarios 185

estimar dando la vuelta a su elección de tarjeta. Para acercarnos más a la

forma en que se juega al póquer real, todos muestran su tarjeta al mismo
tiempo. En parte, la rotación simultánea de tarjetas es para evitar que los
estimadores cambien su estimación después de ver las otras tarjetas.
2. En el segundo paso del juego, al igual que en cualquier variante de Delphi de banda
ancha, el equipo analiza las estimaciones. Por lo general, solo se analizan las
estimaciones extremas para ahorrar tiempo.
3. Después de la primera jugada y la discusión grupal, se puede jugar una
segunda mano, o el equipo puede tener suficiente información para llegar a
un consenso sin jugar una segunda mano.

En un estudio de planificación del póquer frente a solo un promedio simple de las estimaciones,
los investigadores encontraron que las estimaciones del póquer, después de completar el juego,
eran menos optimistas y, en general, más precisas que una simple combinación aritmética de
estimaciones independientes.

Efectos de la dotación de personal en las estimaciones

Una regla útil que ha surgido de aquellos que han estudiado la ley de Brooks en
situaciones reales es que, aunque el cronograma se extiende cuando se agrega esfuerzo,
la sensibilidad es mucho menor que una proporción de 1 a 1. Los resultados empíricos
muestran que el programa se extiende aproximadamente por la raíz cúbica del esfuerzo en
pliegue.

Efecto del esfuerzo sobre la duración del programa

Un proyecto
consejo de gestión Es probable que duplicar el esfuerzo aumente la duración de la programación
solo en un factor de 1,27.8

Efectos de equipo versus plantilla

Brooks imaginó agregar esfuerzo de una manera que aumentaría el tamaño del equipo
(número de personas en cada equipo), amenazando así la cohesión del equipo e
impactando las comunicaciones debido a la N2 problema de comunicación discutido en
capítulos anteriores. En los métodos ágiles, el tamaño del equipo es fijo, excepto por la
adición ocasional de un experto en la materia de forma temporal. Por lo tanto, la forma de
agregar esfuerzo es agregar equipos completos. Ciertamente, otro equipo complicará la
comunicación y la colaboración con todos los demás equipos, pero el impacto no será tan
interpersonal como hacer que los equipos existentes sean más grandes.
En la gestión de proyectos tradicional con cronogramas de red basados en
actividades, nivelar la carga de trabajo de las personas siempre es una tarea difícil. En ágil
186 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

métodos, este problema casi desaparece, ya que el bloque de construcción básico es un equipo y
no un individuo. La carga de trabajo en equipo está diseñada para ser casi constante, de modo
que el ritmo y la productividad se puedan mantener durante un largo período. Habrá
excepciones para talentos especiales en escasez que deben compartirse entre equipos, pero el
problema de la nivelación de recursos ha disminuido considerablemente.

Despliegue de recursos
Incluso sin aumentar el esfuerzo, la programación puede verse afectada por la forma en
que se implementan los recursos, es decir, la forma en que los equipos se aplican a los
requisitos. El hecho es que así como Brooks desacreditó el mes-hombre al mostrar que el
esfuerzo y el calendario no son intercambiables debido a las limitaciones de secuenciación
y las tareas indivisibles, lo mismo ocurre cuando se escala al equipo y la iteración.9

En igualdad de condiciones, el cronograma siempre se extiende cuando los

recursos que actúan de manera independiente se correlacionan por dependencias.
Esto lo sabemos intuitivamente y por observación, pero también existe una base
matemática para el fenómeno que está más allá del alcance de esta sección.
Las opciones de mitigación son:

• Búferes de tiempo planificados para que cada equipo finalice su trabajo y, por lo
tanto, no retrase el inicio del siguiente ciclo de desarrollo.
• Complejidad planificada para permitir la secuencia lógica requerida por la
arquitectura, las dependencias funcionales y la viabilidad técnica

Módulo 3: Discusión para el pensamiento crítico

En los últimos años, antes de esta segunda edición de este libro, algunos de los
métodos abstractos de estimación (como los puntos de la historia) han caído en
desgracia, dando paso a un retorno a las estimaciones concretas de horas y / o
financiación. . Según su experiencia, ¿podría trabajar fácilmente en abstracto con
puntos de la historia o se sentiría tan incómodo que solo una estimación concreta
con horas será suficiente?

Resumen y puntos para llevar

No hay datos sobre el futuro, solo estimaciones. Una buena estimación ágil da cuenta
de la complejidad de los intangibles y la incertidumbre de los requisitos. Una buena
estimación combina los hechos de la historia con un juicio sobre posibles resultados
futuros.
 Estimación de costos y horarios 187

En el Módulo 1, examinamos muchos factores, como la complejidad, el rendimiento y el

compromiso, ya que afectan las estimaciones. Desarrollamos la idea de que toda buena
estimación es en realidad una gama de posibilidades, algunas muy probables y otras no
tan probables. El rango se hace más significativo con una estimación de la confianza.

A partir del Módulo 2, es evidente que hay una serie de factores que afectan las
estimaciones, pero no existe una fórmula mágica o un algoritmo que sustituya el
juicio y la consideración cuando se enfrenta la complejidad de los requisitos
intangibles. La experiencia muestra que una gran cantidad de interacciones ocultan
muchos efectos, hasta que se prueba el producto, a veces hasta que se usa por
primera vez. Aquí es donde entra en juego el poder del desarrollo y la entrega
incrementales. La complejidad se aborda mejor en fragmentos digeribles que se
pueden planificar en oleadas y estimar en segmentos que se pueden estabilizar para
el desarrollo.
Del Módulo 3, aprendemos que existen múltiples prácticas para estimar en métodos
ágiles, varias de las cuales aplican estimadores abstractos, como puntos de historia. Pero,
por supuesto, no es necesario utilizar métodos abstractos; Los métodos tradicionales de
estimación también son aplicables.

Apéndice del Capítulo 7

Apéndice Ejemplo 1: Estimación con puntos de historia
Aquí hay un ejemplo rápido de cómo funciona la estimación con puntos de historia. Los pasos
del proceso y los datos se muestran en la Tabla A7.1 y continúan en la Tabla A7.2.
Una vez que se realizan las estimaciones, es posible que sea necesario volver a priorizar y volver a
secuenciar historias para optimizar un flujo de beneficios o ajustar el esfuerzo dentro de los límites de
una iteración. En la Tabla A7.2 se ofrece un resumen de los pasos.
Estimar de esta manera es más un arte que una ciencia. Las primeras una o dos
iteraciones pueden estar un poco desviadas si no hay un buen punto de referencia para un
modelo de referencia. Pero la precisión se corregirá por sí sola después del primer par de
iteraciones a medida que los equipos realicen la autoinspección, la reflexión y la
adaptación a los resultados medidos, actualizando el modelo de referencia con cada
iteración.10
188 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

Cuadro A7.1 Ejemplo de estimación

Paso de ejemplo Comentario

Equipo de referencia Suponga que hay un equipo trabajando y que el equipo ha evaluado el
rendimiento rendimiento del equipo de velocidad.
Punto de referencia: 20 puntos de historia por iteración, ± 2 puntos, para un rango
de 18 a 22

(Nota: sin un modelo de referencia objetivo en forma de punto de

referencia, estimar con puntos de historia es solo adivinar)
Establecer un objetivo de Objetivo: El equipo elige asumir 17 puntos del trabajo de mayor prioridad,
rendimiento para la iteración dejando la capacidad restante en relación con el punto de referencia como
espacio en blanco para la resolución de problemas imprevistos.

Al seleccionar solo 17 puntos en lugar de 18 a 22, el equipo tiene en

cuenta que se necesita un colchón para garantizar el éxito
Un búfer proporciona un margen para que el usuario tenga cierta flexibilidad
para interpretar los requisitos durante la iteración.

Requisitos de recuento Se ha reunido un conjunto candidato de requisitos para la acumulación de

en cartera para la primera iteraciones de acuerdo con la prioridad.
iteración Recuento: la selección es aproximadamente el 20 por ciento de la acumulación total, por lo
que la acumulación total es aproximadamente 5 veces mayor que la selección.

Estimar la complejidad La complejidad estimada de la selección es de 25 puntos de historia, ± 3

puntos; demasiado para este equipo para una sola iteración
Además: la acumulación total es aproximadamente 5 veces mayor, o 125, ± 15

La acumulación de iteraciones tendrá que volver a priorizarse a solo 17 pisos.

puntos

Cuadro A7.2 Gestión de estimaciones

Paso de ejemplo Comentario

El director del proyecto hace estimaciones de la cartera de proyectos: 125
puntos, ± 15 puntos
Proyecto de estimación
Usando el punto de referencia en la Tabla A7.1, para quemar 125 puntos, ±
duración
15 puntos, podría tomar hasta 9 iteraciones, calculadas como (125 + 15) / 17
iteraciones, y redondeando al siguiente número entero
El maestro de producto selecciona un backlog de iteraciones que se ajusta al punto de referencia de
Seleccionar iteración
rendimiento del equipo (consulte la Tabla A7.1 con respecto al punto de referencia)
atrasos y set
El maestro de producto establece una prioridad para los requisitos en la capacidad del
prioridades
backlog de iteraciones del equipo.
 Estimación de costos y horarios 189

Apéndice Ejemplo 2: Promedio ponderado por riesgo (valor

esperado)
Configuración (se asume todo para este ejemplo):

• Valores de rango (seis en total), en orden: 90, 95, 100, 105, 110, 120
• Ponderaciones de grupo para cada valor de rango (como una proporción de un grupo de 6
puntos) en orden: 0.25, 0.75, 2.0, 1.75, 1.0, 0.25

Cálculos:
• Promedio de valores de rango: (1/6) × (90 + 95 + 100 + 105 + 110 + 120)
= 103,3
• Cálculo del promedio ponderado por riesgo (valor esperado), teniendo en cuenta los
valores ponderados
◆ Suma de los valores del rango multiplicado por los pesos del grupo: (90 ×
0,25) + (95 × 0,75) + (100 × 2,0) + (105 × 1,75) + (110 × 1,0) + (120 ×
0,25) = 617,5
◆ Promedio ponderado por riesgo: 617/6 = 102,9

Apéndice Ejemplo 3: Estimación de la confianza

El rango de estimación no está absolutamente acotado, es decir, existe la posibilidad
de que el resultado real quede fuera del rango. La palabra para describir qué tan
bien está el rango donde encontraremos el resultado real es confianza.
La confianza es la probabilidad de que el valor real esté realmente dentro del
rango estimado.

• Las estimaciones de confianza siempre tienen un límite de rango superior y un límite

de rango inferior
• Las estimaciones de confianza tienen probabilidades sobre cada límite.

Por ejemplo, se podría estimar que el resultado será menor de 120 horas
pero mayor de 90 horas con una confianza del 90 y 80 por ciento,
respectivamente. Esto significa que:
• De 100 oportunidades de desarrollo de proyectos similares disponibles, 90
instancias deberían tomar menos de 120 horas; en 10 casos, el esfuerzo
puede ser de más de 120 horas
• En 80 casos, el esfuerzo será de más de 90 horas; en 20 casos, el
esfuerzo puede llevar menos de 90 horas
La figura A7.1 ilustra este análisis de la estimación de la confianza. La figura muestra
muchas mediciones o estimaciones que se agrupan alrededor de un valor central. los
190 Gestión de proyectos de forma ágil: cómo hacer que funcione en la empresa, 2ª ed.

La confianza es una estimación de un valor dentro de un rango

Probabilidades de valor,%

90

20

10

90 105 120
Valores de rango

• 90% de confianza en que el resultado será inferior a 120;

10% de confianza que el resultado será superior a 120
• 20% de confianza en que el resultado será inferior a 90; 80% de
probabilidad de que sea mayor que 90

Figura A7.1 Estimación de confianza

las estimaciones cercanas al valor central son más probables que las estimaciones más
alejadas y cercanas a las colas.
La curva de campana es una representación de la probabilidad frente al valor del
rango. La otra curva es la curva S, que es una representación de la probabilidad
acumulada de 0 a 1. La confianza se expresa mediante la acumulación de
probabilidad de un punto de rango a otro.

Notas al final del capítulo

1. La cita es un dicho favorito del Dr. David Hulett, dado al autor.
en 1997 durante un compromiso para evaluar el riesgo de un proyecto del milenio.
2. Brooks, El mes del hombre mítico, 21.
3. Weaver, Ciencia y Complejidad.
4. Ibíd, 25.
5. Cohn, Estimación y planificación ágiles, 52. Para obtener autoridad, Cohn hace referencia
el trabajo de 1997 de Thomas Saaty, un reconocido investigador en el campo de la
toma de decisiones y el análisis. Saaty llama a su trabajo el Proceso de Jerarquía
Analítica (AHP); Ver Saaty,El proceso de jerarquía analítica. Saaty ha documentado su
trabajo en muchos artículos. Por ejemplo, vea Saaty.Toma de decisiones con el
 Estimación de costos y horarios 191

proceso de jerarquía alítica 83-98, en el que Saaty utiliza la escala lineal del 1 al 9 para
demostrar la asignación de valores a los elementos de decisión.
6. Boehm, Economía de la Ingeniería de Software, Capítulo 22. El método es suma-
marizado en la pág. 335. Farquhar, Una consulta preliminar sobre el proceso de estimación de
software. Consulte también una buena explicación para profesionales. Stellman y Greene,
Gestión de proyectos de software aplicado, Capítulo 3.
7. La planificación del póquer se escribió por primera vez en un breve artículo de James Gren-
ning. Luego se hizo más popular por autoridades como Mike Cohn. Ver Cohn,Estimación y
planificación ágiles, Capítulo 6; Grenning,Planificación del póquer, o cómo evitar la
parálisis del análisis durante la planificación del lanzamiento. Ahora, las versiones
comerciales y en línea del juego están disponibles.
8. McConnell, Estimación de software: desmitificando el arte negro, 223.
La raíz cúbica de 2 es aproximadamente 1,27, lo que significa 2 = 1,27 × 1,27 × 1,27 en una
aproximación bastante cercana. La ecuación para el aumento de la duración del programa es: nueva
duración = duración anterior × (esfuerzo nuevo / esfuerzo anterior), 173.
9. Brooks, El mes del hombre mítico, 17-19.
10. Para una discusión más completa de los puntos y la velocidad de la historia, vea
Cohn, Estimación y planificación ágiles, 35-40.