Gestión económica de la distribución de software

Murray Cantor y Walker Royce, IBM

// Los métodos ágiles son convencionales, y las empresas de software los están adoptando en diversos
contextos de distribución a escala empresarial. La amplia experiencia de la industria de IBM con
transformaciones ágiles y un profundo conocimiento interno revela tres principios clave para ofrecer
mejoras sostenidas en los resultados comerciales del software: medir los costos de cambio, agilizar los
gastos generales y orientarse con la gestión económica y el análisis bayesiano. //
Las prácticas ágiles de hoy en día no son novedosas ni extremas: muchas ideas prácticas han sido
puestas a prueba, practicadas y evolucionadas.
¿Qué diferencia a aquellas empresas que mejoran significativamente la productividad del software de
las que fracasan? Un factor crítico es un modelo de gestión apropiado que complemente la dinámica
de las prácticas ágiles. La gestión económica proporciona una base para la planificación cuantificada,
la toma de decisiones y la medición que resuelve la incertidumbre previa y unifica los límites para
gestionar un conjunto compartido de resultados esperados. La transformación de la gestión de
ingeniería convencional a la gestión económica cambia los principios y las perspectivas que impulsan
el liderazgo técnico y comercial. Una orientación de ingeniería se centra en objetivos estáticos,
actividades planificadas, y predicciones deterministas para impulsar el proceso de desarrollo, mientras
que una orientación económica dirige las prioridades y resultados del proyecto en función de las
predicciones dinámicamente cambiantes de los resultados probables del proceso de desarrollo. La
distribución exitosa de software de manera predecible y rentable requiere un estilo de liderazgo ágil
en el que los líderes deben esperar una mezcla emergente de descubrimiento, producción, evaluación
y refactorización. La agilidad es la capacidad de reaccionar rápidamente o cambiar de dirección
libremente y con fluidez. Las organizaciones y proyectos que pueden explotar la agilidad tienen una
ventaja. Cuando los cambios son menos costosos de implementar, es más probable que un proyecto
aumente la cantidad de cambios, idealmente mejorando la calidad, la eficiencia y la puntualidad con
cada iteración. La verdadera agilidad se produce cuando los cambios en el ciclo de vida se vuelven
más predecibles y directos con el tiempo. La agilidad se mide mejor cuantificando los costos del
cambio a lo largo del tiempo. Cuando encuentre equipos que han mejorado su tiempo de respuesta con
cambios de software de unas pocas semanas a unos pocos días, sabe que se han vuelto más ágiles. En
lugar de verse empantanados en retrospectivas y reprocesos tardíos, consumidos con defensa de juego,
pueden ir a la ofensiva innovando, agregando más funciones, mejorando el rendimiento y entregando
antes. La gestión económica es un complemento natural para el desarrollo ágil y las técnicas de
transformación ajustada. Aquí, resumimos la década de experiencia de IBM con transformaciones
ágiles e identificamos los principios clave de administración para ofrecer mejores resultados de
negocio a través de mejoras en la competencia en la distribución de software.

Distribución de software: economía triunfa en ingeniería

Los resultados exitosos del software dependen en gran medida de negociaciones continuas,
predicciones precisas, juicios de valor, innovaciones, colaboración en equipo, arquitectos, agilidad,
condiciones del mercado y demanda del usuario. El éxito depende mucho menos de la calidad del
contrato, los diagramas de Gantt, los horarios de las rutas críticas, la medición del valor ganado, las
leyes de la física, las propiedades de los materiales, los códigos de construcción maduros y los
ingenieros certificados. Dicho de otra manera, la gestión de la distribución de software es más una
disciplina de economía que de ingeniería. Es un esfuerzo no determinista con mucha más
incertidumbre adjunta. Los principios de liderazgo empresarial y la gestión económica prevalecen
sobre la doctrina convencional de la gestión de ingeniería. Los esfuerzos de ingeniería generalmente
se rigen por leyes bien entendidas de la física y las propiedades de los materiales, así como por siglos
de experiencia precedente. Todavía se intentan realizar esfuerzos de ingeniería de alta incertidumbre,
como limitar la fuga de petróleo del Golfo de México en 2010, pero estas son las excepciones. La
distribución de software, en comparación, es una disciplina dominada por la creatividad humana, el
pronóstico del mercado, los juicios de valor y los niveles de incertidumbre similares a los esfuerzos
económicos, como producir una película o una obra de teatro,
escribir un libro o participar en la gestión de capital de riesgo. 4,5 Considere las siguientes
observaciones:
• La mayoría de las actividades de software no tienen leyes de física o propiedades de materiales para
limitar sus problemas o soluciones. Están obligados solo por la imaginación humana y las limitaciones
económicas.
• En un proyecto de software, puede cambiar casi cualquier cosa en cualquier momento: planes,
personas, financiación, requisitos, diseños y pruebas. Los requisitos, probablemente la palabra más
mal utilizada en nuestra industria, rara vez especifican algo que realmente se requiera. Casi todo es
negociable.
• Las métricas de calidad para productos de software tienen pocos puntos de referencia aceptados.
Con la posible excepción de la confiabilidad, la mayoría de los aspectos de la calidad (como la
capacidad de respuesta, la capacidad de mantenimiento y la usabilidad) conllevan una gran
incertidumbre y aún se miden en gran medida subjetivamente, a través de los ojos de sus espectadores
en la comunidad de usuarios.
La mayoría de los gerentes de proyectos de software, productores de películas y empresarios manejan
equipos que crean una red única y compleja de propiedad intelectual limitada solo por una visión
abstracta y creatividad humana. Este cambio de mentalidad está bien articulado por Eric Ries en The
Lean Startup. Su enfoque comienza capturando el caso de negocio como una hipótesis clara (una
predicción de la propuesta de valor) y luego prueba esa predicción a través de una secuencia de
experimentos que validan empíricamente una estrategia . Al elegir entre las muchas afirmaciones en
un plan de negocios, tiene sentido económico probar primero los supuestos más riesgosos. Esto da
como resultado las reducciones más significativas en la incertidumbre. Un producto mínimo viable
constituye el primer experimento crítico.

Transición hacia la gestión económica

Las empresas de software se enfrentan a un desafío importante cuando realizan una transformación
cultural del mundo determinista de la gestión de la ingeniería convencional a la mentalidad
probabilística inherente de la gestión económica. Este es un salto cuántico para la mayoría de las
partes interesadas, desde objetivos estáticos a objetivos dinámicos, desde el manejo de la certeza hasta
el manejo de la incertidumbre, y desde las decisiones deterministas hasta las decisiones
probabilísticas. Esto no es fácil para la mayoría de nosotros. La Tabla 1 ilumina algunos de los
cambios en la mentalidad de gestión. En las últimas dos décadas, hemos trabajado colectivamente con
cientos de proyectos relacionados con la gestión de la ingeniería y hemos experimentado quizás 20
que claramente tuvieron éxito con los patrones de gestión económica. Las técnicas convencionales de
gestión de proyectos de ingeniería suponen poca incertidumbre en sus requisitos y explotan los
precedentes maduros para la producción y el despliegue. Los proyectos de software gestionados con
tales modelos de gestión de ingeniería generalmente descubren cambios sofocantes y malignos al
final del ciclo de vida y gastan el 40 por ciento o más de su esfuerzo consumido en chatarra tardía y
retrabajo. La ley de hierro de la ingeniería de software tradicional es la siguiente: cuanto más tarde se
encuentre en el ciclo de vida, más costoso será arreglarlo. Si está experimentando esta ley de hierro,
probablemente esté anclado en un proceso convencional de modelo en cascada. Su proceso puede ser
maduro, o podría describirse con mayor precisión como geriátrico. Los gerentes de proyecto con
experiencia y capacitación en disciplinas tradicionales de gestión de proyectos, tales como
planificación detallada, análisis de rutas críticas y gestión del valor ganado tienen una transición
particularmente difícil. Deben pasar de un mundo de gestión de certeza y precisión a un mundo de
resolución de la incertidumbre basada en juicios probabilísticos imprecisos. Aunque estas ideas están
lejos de ser nuevas, también están lejos de ser una práctica estándar en la mayoría de las empresas de
software. La base de gestión de riesgos subyacente al modelo espiral y las ideas básicas de la
economía de la ingeniería de software fueron presentadas por primera vez por Barry Boehm en la
década de 1980. La aplicación de la teoría de la probabilidad para lidiar con la incertidumbre también
está bien establecida.

Una parábola sobre el quid de la gestión económica

Una versión corta en video de la siguiente parábola está disponible en https: / / ww wy outube. com /
watch? v = ghAM8ifyeV I & feature = youtube_gdata_player. Supongamos que tiene un producto de
software que debe entregarse en 12 meses para satisfacer una necesidad comercial crítica. Como líder
de la organización, usted decide solicitar propuestas a dos gerentes de proyecto en competencia.
Gerrard Hattrick es un veterano gerente de proyectos de software; Shirley Nimble es un administrador
de software más contemporáneo. Utilizando modelos de estimación empírica, ambos estiman que el
proyecto debería tomar 11 meses. A partir de aquí, sus enfoques divergen.
Gerry, un fanático del hockey franco-canadiense, está certificado en técnicas tradicionales de gestión
de proyectos. Su apellido lo obliga a iniciar proyectos con tres objetivos: planifique los 12 meses
completos en detalle, especifique los requisitos con precisión y realice una revisión de diseño
temprana para demostrar los elementos que son más fáciles de simular. Al demostrar un rápido
progreso en un hito temprano, puede definir los requisitos, tomar decisiones de diseño y evitar
cambios tardíos en el final. Confía en que puede entregar un mes antes de lo previsto.
Shirley ve las cosas de manera diferente. Ella entiende que el resultado del modelo de estimación es
simplemente la media de una variable aleatoria más compleja. Ella pide ver la distribución completa
de los posibles resultados. Ella quiere entrar en el proyecto con un 95 por ciento de posibilidades de
entregar a tiempo. Su equipo de liderazgo le muestra la estimación de referencia en la parte superior
de la Figura 1. Después de evaluar la distribución completa, El equipo de Shirley se da cuenta de que
aproximadamente la mitad de los resultados tomarán más de 12 meses, por lo que solo tienen una
probabilidad de 50-50 de entregar a tiempo. Existe una incertidumbre significativa en los diversos
parámetros de entrada, lo que refleja la falta de certeza del equipo sobre el alcance, el diseño, el plan y
la capacidad del equipo. En consecuencia, la variación de la distribución de resultados es bastante
amplia. Existen tres caminos alternativos para garantizar que el 95 por ciento de los resultados se
encuentren dentro de la fecha objetivo:
• opción 1, solicitar al patrocinador que traslade la fecha objetivo de entrega a 15 meses;
• opción 2, solicite al patrocinador que vuelva a realizar el trabajo, eliminando algunas de las
características o retrocediendo en la calidad para que la estimación del horario promedio aumente
aproximadamente un mes; y
• opción 3, reducir explícitamente las incertidumbres en el alcance, diseño, planes, equipo, plataforma
y proceso; Esto reduce la dispersión de la distribución y aumenta la probabilidad de entrega en la
fecha objetivo.
Las dos primeras opciones generalmente son consideradas inaceptables por las partes interesadas
externas, dejando la tercera como la alternativa preferida de Shirley.
Gerry prioriza sus esfuerzos en función de lo que sabe ahora. Ignora las grandes incertidumbres,
pospone su resolución hasta después de que acumula el impulso inicial del proyecto al abordar las
tareas sencillas y muestra el progreso temprano en la construcción de las partes más fáciles y bien
entendidas. Al principio, el equipo de Gerry parecerá estar progresando. Sin embargo, al final del
proyecto, una de las grandes incertidumbres probablemente explotará en un obstáculo formidable, lo
que resultará en una sorpresa tardía con un retraso significativo del proyecto. Los métodos de Gerry
Hattrick son viejos. Shirley adopta el enfoque más inteligente y valiente. Continúa con una serie de
experimentos construyendo versiones tempranas para probar el diseño y obtener retroalimentación de
los usuarios objetivo sobre el progreso. Exige que las pruebas de integración se completen en su
mayoría antes de invertir en la cobertura de pruebas unitarias. Estos experimentos dan como resultado
un aprendizaje validado, que es una mayor comprensión (o disminución de la incertidumbre) en el
caso de negocios, el alcance y el diseño del sistema de destino. Primero resuelve los desafíos más
difíciles, entregando menos artefactos tangibles temprano pero aprendiendo más sobre lo que
constituye una entrega exitosa. Ella aumenta la probabilidad de éxito a largo plazo y disminuye la
probabilidad de futuros desperdicios y reprocesos que agregan fricción e impiden una entrega exitosa.
Es más probable que Shirley entregue el software correcto a tiempo. La orientación de ingeniería
anticuada de Gerry se centra en objetivos estáticos y predicciones deterministas ante una
incertidumbre significativa. La orientación económica de Shirley dirige proyectos con predicciones
dinámicamente cambiantes de resultados probables y una discusión más honesta de las
incertidumbres. Está operando como una emprendedora inteligente, luchando y midiendo el
aprendizaje validado, como se discutió en The Lean Startup. Una discusión relacionada sobre la
aplicación de opciones para técnicas de valoración a los árboles de decisión es una perspectiva
esclarecedora sobre la cuantificación del aprendizaje validado, como es su trabajo inicial. 10

Razonamiento Bayesiano
Establecer una fecha de entrega esperada o planificar recursos para cualquier proyecto implica una
predicción, y la mejor manera de mejorar las predicciones es aplicar el razonamiento bayesiano. Este
tipo de razonamiento se basa en las matemáticas de siglos de antigüedad y fue históricamente una
forma controvertida de pensar sobre la naturaleza de la probabilidad. Se ha convertido en una mejor
práctica aceptada, central para todo tipo de predicciones. En The Signal and the Noise, por ejemplo,
Nate Silver explica cómo el razonamiento bayesiano es fundamental para predecir los resultados de
las elecciones, los pronósticos económicos, la propagación de enfermedades, el clima, el póker y otros
intereses sociales. Los métodos bayesianos también se han aplicado para administrar la duración de
los proyectos en otros dominios de ingeniería. El razonamiento bayesiano requiere un cambio de
mentalidad de la forma en que la mayoría de nosotros abordamos la estimación de proyectos.
Debemos abandonar la idea de que un proyecto tiene una duración fija o un costo fijo. La mentalidad
bayesiana razona sobre las predicciones como un rango de posibles valores llamados resultados.
Algunos resultados son más probables que otros, por lo que a cada uno se le asigna un valor de
probabilidad. El desafío para el lider del proyecto es identificar una distribución inicial como el
tiempo para terminar y luego actualizar continuamente la distribución a medida que avanza el
proyecto. La forma cambiante de la distribución proporciona información sobre si la probabilidad de
cumplir con el objetivo del cronograma está mejorando. La distribución inicial se llama distribución
anterior y la distribución actualizada la posterior. En la figura 1, la estimación inicial en la parte
superior sería la anterior, y el resultado después de buscar la opción 3 en la parte inferior de la figura
sería la posterior. El proceso es bastante simple:
• Haga una conjetura inicial, pero informada, de una distribución previa.
• Reunir evidencias.
• Use el teorema de Bayes para actualizar una distribución posterior.
• Continúe actualizando la distribución posterior a medida que haya más evidencia disponible.
Una de las características importantes de este enfoque es que converge en el mismo posterior, sin
importar el anterior que se utilizó para sembrar el proceso. Esto es importante: la especificación
perfecta y el plan perfecto no son necesarios para mejorar la previsibilidad. Es mucho mejor hacer una
estimación razonable y luego refinar esa estimación. Este es el espíritu de desarrollo iterativo y ágil
que lo diferencia del pensamiento convencional en cascada.

Predicciones más honestas

El resultado más probable podría ser la verdad (generalmente algo cercano al valor medio), pero una
representación más honesta, o toda la verdad, sería la distribución completa de los posibles resultados.
Por ejemplo, el resultado más probable de 11 meses es una representación precisa de la fecha objetivo
esperada representada para la distribución superior en la Figura 1. Sin embargo, al expresar cuán
seguros estamos de esa suposición, al exponer la variación en la distribución, es mucho más honesto y
transparente al comunicar esa información a otros. La variación (matemática) de la distribución de
resultados para la estimación hasta su finalización se puede medir periódicamente para cuantificar las
tendencias en la reducción de la incertidumbre. Cada fase de desarrollo debe reducir la incertidumbre
en la evolución de los planes, especificaciones, y lanzamientos demostrables. En cualquier punto del
ciclo de vida, la precisión de los artefactos subordinados, especialmente los planes y la variación en
las estimaciones hasta su finalización, deben estar en equilibrio con la precisión evolutiva en la
comprensión. Stephen Covey acuñó la frase "la velocidad de la confianza" para resaltar la confianza
como el elemento necesario para reducir los gastos generales (es decir, volverse más ágil) y mejorar la
eficiencia.14 La velocidad de la confianza también se puede apreciar a través de su opuesto lógico: la
lentitud de desconfianza. Las actividades en la mayoría de las empresas son directamente
proporcionales a la cantidad de desconfianza en la organización. Debido a que los humanos cometen
errores, cierta desconfianza es saludable y necesaria. Sin embargo, cuando las actividades generales
son demasiado pesadas, el sistema se vuelve ineficiente. Las comunicaciones más honestas mejoran la
confianza entre las partes interesadas, lo que permite una mayor eficiencia. La planificación
determinista mata la confianza porque no coincide con la realidad y las incertidumbres que se
encuentran en el mundo del desarrollo de software. La comunicación probabilística de planes y
objetivos y la cuantificación explícita de cualquier incertidumbre genera confianza porque retrata con
precisión la comprensión de cómo razonar sobre el futuro. Todos los interesados deben colaborar para
converger en objetivos móviles y gestionar las incertidumbres, como lo muestra la Figura 2. Los
cronogramas, el alcance, los diseños y los planes de software deben tratarse como predicciones con
incertidumbre inherente, no como contratos con certezas y requisitos implícitos. Una fecha objetivo es
una predicción, típicamente, la media de una distribución de probabilidad de las fechas de
lanzamiento. Las especificaciones y modelos de requisitos evolucionan de una visión aproximada con
una amplia variación a una especificación precisa y comprobable con relativa certeza. Las
características operativas siguen siendo negociables a medida que las compensaciones evolucionan de
debates especulativos a decisiones fácticas. Se puede capturar un plan de proyecto a medida que el
conjunto previsto de cambios de estado en ruta al estado final deseado. Si se han resuelto las
incertidumbres, los artefactos del ciclo de vida deberían evolucionar con mayor precisión. Los
métodos de desarrollo iterativo, ágil y ágil han surgido orgánicamente de diversas comunidades de
desarrollo de software para mejorar la navegación a través de la incertidumbre. Esta dirección
requiere una mejora medida con controles dinámicos, instrumentación y puntos de control intermedios
que permiten a las partes interesadas evaluar lo que han logrado hasta ahora (la situación "tal como
está"), qué ajustes deben hacer a los objetivos objetivo (la situación "prevista para ser") y cómo
refactorizar lo que han logrado para ajustar esos objetivos de la manera más económica (la hoja de
ruta hacia adelante). Los resultados clave se reducirán los gastos generales y una reducción
significativa (tal vez tan alta como 50 por ciento) en chatarra y retrabajo. La transformación exitosa de
la gestión de ingeniería convencional a una gestión económica más ágil requiere una transformación
cultural significativa, que se logra mejor exigiendo que las pruebas de integración precedan a las
pruebas unitarias. Integrar primero expondrá desafíos arquitectónicamente significativos y ayudará a
resolver grandes incertidumbres antes. La naturaleza humana es abordar las cosas fáciles primero para
mostrar el progreso temprano, pero no se obtiene influencia económica al hacerlo.
Razonamiento y previsibilidad mejorada
Volvamos a nuestra parábola. Shirley planea usar un proceso ágil, descomponiendo las características
en elementos de trabajo y asignando esos elementos de trabajo a una secuencia de compilaciones.
Antes de comprometerse con el proyecto, desarrolla una distribución inicial del tiempo para
completarlo. Esta distribución le proporciona una visión de la probabilidad de lograr ese objetivo. Su
equipo estima el nivel de esfuerzo con distribuciones triangulares simples. Para el nivel de esfuerzo de
cada característica, el equipo de liderazgo acuerda tres valores:
• El valor bajo (el mejor caso) supone que todas las estrellas se alinean y la función se une fácilmente
para cumplir con los requisitos.
• El valor nominal (lo más probable) supone que el nivel de esfuerzo tiene la mezcla esperada de
buena fortuna y mala suerte.
• El alto valor (peor caso) supone que la ley de Murphy domina, presentando desafíos y obstáculos
inesperados.
más que el peor de los casos, por lo que las distribuciones se establecen en cero por debajo del valor
bajo y por encima del valor alto. En el razonamiento bayesiano, esta técnica proporciona a los
expertos en la materia un medio para llegar a un previo honesto basado en la información actual y la
creencia informada. Si la diferencia entre lo bajo y lo alto para una característica es grande, entonces
el equipo está expresando una gran incertidumbre en el esfuerzo requerido para entregar esa
característica. Esto le da al equipo de Shirley una mayor oportunidad para resolver las incertidumbres
de mayor prioridad desde el principio. Con esta estimación previa, Shirley tiene una idea de la
probabilidad de cumplir con el compromiso, y ella negocia el contenido. A través de algunos análisis,
descubre que una de las características relativamente inciertas es más agradable que imprescindible y
agregaría mucho más riesgo que valor. Entonces ella negocia esa característica fuera de alcance para
un compromiso más firme con una entrega en 11 meses. A medida que el equipo de Shirley completa
los elementos de trabajo y los elementos del plan, actualizan el tiempo para completar variables
aleatorias en función de su mayor comprensión del progreso y la calidad. Utilizan el trabajo
completado y el rendimiento real del equipo (hechos), combinados con planes actualizados para
completar (estimaciones), para actualizar el tiempo para completar la distribución (predicciones
honestas) con buenas matemáticas. Con estas predicciones periódicas, Shirley puede discutir con su
equipo interno y partes interesadas externas si las probabilidades de cumplir con el compromiso están
mejorando (como deberían) o no. Con una visión cuantificada y objetiva de las tendencias del
proyecto, todos los interesados pueden tener una discusión más honesta y confiable sobre la mejor
manera de proceder.
La amplia experiencia de IBM en la industria con miles de proyectos durante más de una década de
experiencia de transformación ágil interna señala tres prioridades para ofrecer mejoras sostenidas en
los resultados comerciales de software con mayor confianza:
• medir los costos de cambio,
• dirigir utilizando la gestión económica, y
• racionalizar los gastos generales.
La medición continua en líneas base de software ejecutables es una piedra angular de la agilidad. Las
metricas deben iluminar el progreso y los indicadores de calidad necesarios para dirigir los proyectos
hacia resultados más exitosos. Los principios ágiles de integración continua y desarrollo basado en
pruebas sientan una base sólida para la mejora medida. Las métricas centrales para la dirección se
pueden extraer de las líneas base de lanzamiento que se someten a pruebas de integración continua.
Estas métricas cuantifican el aprendizaje validado para una reducción más objetiva de la
incertidumbre y una evaluación confiable del progreso y la calidad. Dirigir proyectos con gestión
económica exige diferentes prioridades de liderazgo:
• Administre los costos y cronogramas objetivo como reducciones de las distribuciones de resultados.
• Predecir resultados utilizando el razonamiento bayesiano y la información cada vez mejor.
• Optimizar la calidad como una distribución más estrecha de clases y densidad de defectos.
• Comunicar el progreso y las tendencias de calidad de manera transparente y honesta.
Las estimaciones, propuestas y planes de software son predicciones esenciales que representan los
principales intercambios de información entre las partes interesadas de la gestión. La confianza se
gana cuando se combinan integridad y rendimiento. La integridad mejora con predicciones más
honestas que cuantifican las incertidumbres; el rendimiento mejora al reducir de manera considerable
la incertidumbre en las negociaciones y la dirección de manera temprana y continua. La mayoría de
las culturas actuales de ingeniería de software están ancladas en métodos deterministas de
planificación y gestión que compiten con la libertad del profesional. La gerencia debe brindar a los
profesionales más libertad para innovar mediante la automatización de la medición, la trazabilidad, los
informes de progreso, la documentación y la propagación de cambios. Y los profesionales deben
proporcionar a la gestión mecanismos de dirección mejorados, como medidas de progreso y control y
análisis de desarrollo en tiempo real. La plataforma de conocimiento y automatización del proceso
debe ofrecer este quid pro quo crítico: los profesionales deben exigir que las tareas generales se
minimicen, racionalicen y automaticen, y los interesados en la gestión deben exigir medidas más
perspicaces y un ciclo de control de feedback para dirigir el progreso y la calidad con una mejor
previsibilidad de resultados comerciales. La confianza es la clave para desbloquear este intercambio
de libertad por medida. Probablemente hay más libros sobre métodos ágiles que proyectos exitosos
con resultados ágiles bien documentados. Escribir un libro sobre agilidad o gestión de proyectos es
fácil, pero gestionar un proyecto real en el que debe dirigirse a través de un campo minado de
incertidumbres es difícil. Todos deberíamos poner mayor énfasis en la publicación de estudios de
casos de mejoras medidas. Son fundamentales para acelerar la innovación entregada en el software.
Murray Cantor es ingeniero distinguido de IBM y arquitecto principal de productos de análisis y
optimización en IBM Rational. Fue miembro fundador de la junta de revisión de arquitectura OpenGL
y es autor de dos libros: Gestión de proyectos orientados a objetos con UML (John Wiley, 1998) y
Liderazgo de software (Addison-Wesley, 2001). Cantor recibió un doctorado en matemáticas de la
Universidad de California, Berkeley. Póngase en contacto con él en mcantor@us.ibm.com.
Walker Royce es el Economista Jefe de Software en el Grupo de Software de IBM y autor de tres
libros: ¡Eureka! Descubra y disfrute el poder oculto del idioma inglés (Morgan James, 2011), The
Economics of Software Development (Addison-Wesley, 2009) y Software Project Management, A
Unified Framework (Addison-Wesley, 1998). Royce recibió una licenciatura en Física de la
Universidad de California, Berkeley y una maestría en ingeniería informática de la Universidad de
Michigan. Póngase en contacto con él en weroyce@us.ibm.com.