Pregunta: El caso comercial de la agilidad “La batalla no siempre es para el más fuerte, ni la carrera para el más rápido, ¡pero esa es la forma de apostar!” -C. morgan cofer En este capítulo En este capítulo se analiza el caso comercial de la agilidad y se presentan seis beneficios para los equipos y la empresa. También describe un modelo financiero que muestra por

El caso comercial de la agilidad

“La batalla no siempre es para el más fuerte, ni la carrera para el más rápido, ¡pero esa es la forma de apostar!” -C. morgan cofer

En este capítulo

En este capítulo se analiza el caso comercial de la agilidad y se presentan seis beneficios para los equipos y la empresa. También describe un modelo financiero que muestra por qué funciona el desarrollo incremental.

comida para llevar

La agilidad no se trata solo del equipo. Hay problemas de gestión de productos, gestión de proyectos y técnicos que escapan al control del equipo. Lean-Agile proporciona beneficios para todos, tales como:

• Lograr que los clientes le digan todo lo que van a necesitar de usted con algún tipo de precisión; tienden a la especulación, gran parte de la cual es inevitablemente errónea.

• Diseños emergentes que son tolerantes al cambio, lo que aborda la necesidad de desarrollo de software para obtener un retorno de la inversión lo más rápido posible para responder a las condiciones cambiantes del mercado a medida que los competidores avanzan y ajustan sus propios productos.

• La entrega de valor de forma incremental proporciona mucho más valor empresarial a sus clientes.

• Los métodos Lean-Agile brindan a la gerencia una mayor visibilidad de los proyectos de desarrollo de software que los métodos Waterfall.

Lean-Agile aborda todos estos puntos. Sin embargo, requiere que el equipo preste atención a algunas cosas que están bajo su control:

• Retrasos y palizas, que son impedimentos

• Planificación de recursos y productos

• Calidad del código, estándares de codificación y planificación para futuras modificaciones

Los beneficios de la agilidad

A pesar del rumor sobre la agilidad, es importante tener en cuenta que el principal impulsor es, y siempre debe ser, el beneficio para la empresa a través de la adición de valor para sus clientes. Ayudar a los equipos a ser más ágiles es bueno. Es una parte necesaria del viaje para ayudar a la empresa a ser más ágil. Enterprise Agility permite que una organización reaccione a las necesidades del mercado y a los cambios competitivos y la ayuda a obtener el máximo valor de los recursos disponibles. Al final, el uso de métodos ágiles debe mejorar los resultados de la empresa. Si no es así, debemos preguntarnos por qué estamos usando Agile o si lo estamos usando correctamente.

Agile puede beneficiar a una empresa y sus equipos de las siguientes maneras:

• Agregar valor al negocio rápidamente

• Ayudar a aclarar las necesidades de los clientes

• Promover el desarrollo de productos basados en el conocimiento y una mejor gestión de proyectos

• Motivar a los equipos y permitir fallar (es decir, aprender) temprano

• Centrarse en el desarrollo centrado en el producto

• Mejorar la eficiencia del equipo

Cada uno de estos es importante y se analiza a continuación individualmente. Sin embargo, también hay un efecto sinérgico. El crecimiento en un área estimula el crecimiento en otras áreas, lo que resulta en una mayor capacidad para crear valor.

Agregue valor al negocio rápidamente

Ya sea que esté en una tienda de TI que produce software para clientes internos o en una empresa que produce productos de software para clientes externos, existe un gran valor cuando los productos se pueden lanzar al cliente rápidamente ¹ . Los beneficios para el negocio incluyen lo siguiente:

1. El mero lanzamiento de un producto o software que soporta un servicio no agrega valor si los clientes del

organización no puede realmente utilizar el producto o servicio de la empresa.

• Ingresos/Retorno de la inversión Cuanto antes los clientes puedan comenzar a usar un producto, antes la empresa comenzará a recibir un retorno de su inversión, ya sea en forma de ingresos directos o como una forma de satisfacer las necesidades comerciales.

• Mayor satisfacción del cliente En igualdad de condiciones, los clientes prefieren obtener características nuevas o mejoradas más temprano que tarde para poder comenzar a usarlas.

• Posición en el mercado La mejor manera de mantener o aumentar la posición en el mercado en relación con la competencia es ofrecer funciones valiosas antes de lo que pueden. Los productos que se ven más frescos y más capaces satisfacen a los clientes más profundamente, lo que crea credibilidad para el negocio y genera lealtad en los clientes. En el mundo actual, la competencia a menudo proviene de empresas más pequeñas y ágiles (como en Agile), por lo que la liberación rápida es más importante que nunca.

• Liberación de menor riesgo acorta rápidamente el ciclo de retroalimentación con el cliente, lo que le permite descubrir errores en su proyecto antes. Le da la oportunidad de arreglar el producto, o abandonarlo, para minimizar sus pérdidas.

• Mayores márgenes de beneficio Los costos de inversión se recuperan antes en productos que se lanzan más rápidamente y se mitigan aún más con la entrega incremental de lanzamientos más pequeños. Además, a menudo es posible cobrar más por sus productos si se le considera líder del mercado.

Un modelo financiero para el software

Suponga que está respondiendo a una Solicitud de propuesta (RFP) que detalla lo siguiente:

• Alcance

• Fecha de vencimiento

• Calidad

• Costo

La RFP dice que ninguno de estos cuatro puede ser modificado. Es decir, no puedes cobrar menos por el producto o dar mejor calidad sin ser descalificado. ¿Dónde puedes competir? La credibilidad puede venir a la mente, pero eso puede ser difícil de establecer. ¿Qué otra cosa podría ser?

Mark Denne y Jane Cleland-Huang ofrecen una guía valiosa aquí en su brillante libro, Software by Numbers (Denne & Cleland-Huang 2003). Lo siguiente se basa en su análisis.

La figura 2.1 muestra el costo y el rendimiento de un proyecto de software exitoso típico. En este gráfico, el "Período de inversión" representa el tiempo dedicado a crear el software. Esto es cuando el trabajo se está haciendo antes de que se pueda ganar dinero. El período de recuperación comienza cuando los clientes comienzan a obtener valor del producto y comienzan a pagar por él.

Figura 2.1 Un proyecto de desarrollo de aplicaciones exitoso

¿Cómo sería esta curva si pudiera lanzar el mismo producto en dos fases? Cada fase del sistema contendría la mitad de las características requeridas. Suponga que el equipo puede construir y lanzar la primera fase en la mitad del período de tiempo y la segunda fase durante el resto del período de tiempo. Cada uno de estos lanzamientos tendría una curva financiera similar a la que se muestra en la Figura 2.1, excepto que ocurrirían en momentos diferentes. Por ejemplo, en un proyecto de 10 meses con 100 funciones, puede lanzar las funciones 1 a 50 después de cinco meses y las funciones 51 a 100 después de otros 5 meses. La figura 2.2 muestra estas dos curvas superpuestas.

Figura 2.2 Desarrollo de un sistema en dos

Figura 2.2 Desarrollo de un sistema en dos mitades

Cada mitad aporta algo de valor y algo de ingresos. Si es una empresa de productos, obtiene ingresos por la mitad del sistema; si es una organización de TI, está brindando un nuevo valor a su cliente interno. Suele ocurrir que la primera mitad del sistema proporciona más de la mitad del valor (recuerde la regla de Pareto, “el 80 por ciento del valor proviene del 20 por ciento del trabajo”). Sin embargo, también es posible que no se devuelva ningún valor hasta que todo el sistema esté en su lugar (por ejemplo, no puede liberar un sistema de control de guía de un avión que solo funciona parcialmente). Supongamos que tenemos el primer caso, en el que la mitad del sistema proporciona la mitad del valor. La figura 2.3 muestra el beneficio total generado por estas dos fases.

Figura 2.3 El rendimiento neto de un proyecto de software exitoso construido en etapas

La figura 2.4 compara dos estrategias de lanzamiento: una estrategia de lanzamiento único, en la que todas las funciones se entregan en un paquete de lanzamiento, y una estrategia de lanzamientos por etapas (iterativos), en la que las funciones se entregan cuando están listas. Con la estrategia de lanzamiento único, la empresa debe esperar mucho más tiempo para obtener ingresos que con la estrategia de lanzamiento por etapas. La cantidad de dinero que la empresa debe financiar por sí misma, antes de que el dinero comience a ingresar, es significativamente mayor, el punto de equilibrio se extiende significativamente y la ganancia final es significativamente menor. La empresa obtiene menos valor general y también lo hace el cliente. Demasiada demora en realidad puede impedir que la empresa ingrese o se extienda por completo al mercado.

Figura 2.4 Comparación de beneficios y puntos de equilibrio para estrategias de lanzamiento

Lanzar funciones antes significa que todos obtienen valor antes: ganancias, penetración de mercado y utilidad. Además, ayuda a aclarar cuál debería ser el conjunto de características del producto final: a medida que los clientes entienden más sobre el producto, pueden especular menos sobre lo que creen que necesitan.

Por supuesto, hay otras consideraciones como los costos de entrega e instalación; pero aun así, hemos subestimado el caso. Por ejemplo, en muchos proyectos grandes, la mitad de las características solicitadas a menudo representan el 80 por ciento del valor total del proyecto. En ese caso, la primera curva tendría una pendiente más alta de lo que hemos mostrado.

Aunque no todo el software se puede entregar por etapas, muy a menudo se puede, especialmente en las organizaciones de TI. ¿Cómo determinamos qué aspectos de un producto se pueden entregar rápidamente? Denne y Cleland-Huang (2003) sugieren identificar “características mínimas comercializables” (MMF). Una característica comercializable mínima es la cantidad más pequeña de funcionalidad que tiene sentido para el mercado.

Esto se puede llevar más allá: planifique qué características ofrecer primero para que la empresa y el cliente obtengan el máximo valor lo antes posible. Un enfoque implacable en agregar valor es el núcleo del pensamiento Lean.

Ayude a aclarar las necesidades de los clientes

Con frecuencia, los desarrolladores se quejan de que los clientes no saben realmente lo que quieren. Cambian de opinión; no pueden especificar qué debe hacer el software; sus requisitos son imprecisos e incompletos.

Es fácil

Creo que si esto es cierto, debe ser un problema del cliente. Pero profundiza más. El equipo de desarrolladores también está involucrado. Considere el siguiente estudio de caso.

Estudio de caso: componentes de construcción

Alan estaba trabajando en un sistema que involucraba cuatro componentes: programación, contabilidad, administración de recursos y entrega de contenido. El enfoque de desarrollo previsto, como se muestra en la Figura 2.5, era construir y lanzar cada componente por turnos hasta completar el producto. Desde la perspectiva de aportar valor, la entrega con cuatro iteraciones sería buena porque los clientes obtendrían los componentes antes.

Figura 2.5 Marco de tiempo para la secuencia de desarrollo inicial

Desafortunadamente, estaba claro que los clientes no entendían realmente el aspecto de programación bastante complejo del producto. Al principio, Alan pensó que si cada componente podía entregarse por etapas, tal vez los clientes tendrían que saber menos por adelantado y podrían aprovechar lo que sabían. Entonces le preguntó al equipo: "Si construimos la mitad del componente de programación, ¿eso proporcionaría valor?" Esto requeriría que el cliente supiera sólo la mitad. Entregaríamos la mitad de cada componente, lo liberaríamos, pasaríamos al siguiente y lo liberaríamos hasta que se terminara la primera mitad de cada componente. Luego repetiríamos el proceso para agregar las características que aún no habíamos creado. La idea era que después de que los clientes hubieran usado cada componente por un tiempo, sabrían cómo describir el resto de las características. Esto se muestra en la Figura 2.6.

Figura 2.6 Construyendo los componentes en etapas

La respuesta del equipo fue decepcionante. “Sí, podríamos entregar la mitad y encontrar valor, pero nuestros clientes ni siquiera saben la mitad de lo que se necesita”. ²

2. No sugerimos que siempre pueda realizar la entrega por etapas; por eso tuvimos que preguntarle al equipo. Pero siempre debe buscar la oportunidad de entregar valor en etapas cuando pueda.

Fue entonces cuando hizo una pregunta simple que resultó en una epifanía para él. “¿Cuánto saben realmente los clientes?” ¿Con qué frecuencia los desarrolladores tenemos la actitud de que los clientes realmente no están seguros de nada ? La verdad es que sí tienen certeza de algunas cosas, aunque no sea de todo. Parece razonable que por lo general entiendan entre el 20 y el 25 por ciento del dominio de su problema.

Esto lleva a una pregunta aún más útil: "¿Qué parte del sistema conocen?" ¿Conocen las cosas básicas o conocen las cosas extra y sofisticadas? De hecho, los clientes generalmente saben más sobre las cosas principales, las cosas que llevaron al proyecto y las mejoras del producto en primer lugar. En otras palabras, los clientes saben con qué podemos empezar.

La idea clave es esta: comience con lo que los clientes saben.

Alan le preguntó al equipo si sería valioso construir y entregar los componentes en piezas que representen solo el 25 por ciento del sistema. Ellos respondieron: “Sí”. Esto se convirtió en el plan que se muestra en la Figura 2.7.

Figura 2.7 Construcción de componentes 25 por ciento a la vez y ciclo a través de ellos hasta que todo el proyecto esté terminado

Esto tiene

convertirse en un enfoque fundamental para nosotros:

Comience a construir el sistema en función de lo que el cliente tenga claro, incluso si es solo el 20 por ciento de lo que se requiere. Construya un poco, muéstreles, gane más claridad y repita. Esa es la mejor manera de hacer frente a los requisitos en constante cambio.

Cuando los clientes cambian de opinión con frecuencia, probablemente se deba a que los desarrolladores les piden que especulen y traten de aclarar cosas que aún no saben. ¿Lo que sucede? Cualquier cosa que se construya bajo esas circunstancias será, por supuesto, inadecuada. Tenga en cuenta que la palabra "especular" nunca se usa, pero la presión por obtener más información hace que los clientes hagan precisamente eso.

La realidad es que los clientes suelen saber algo de lo que quieren, al menos las características que son más importantes para ellos en ese momento. Lo que muchos no pueden hacer bien es especular sobre lo desconocido. (“Este es un proyecto de seis meses, así que dime qué necesitarás dentro de seis meses”). La especulación es arriesgada.

Para mitigar el riesgo de incertidumbre, Agile prescribe iteraciones cortas con muchos comentarios. A medida que los clientes aprenden más sobre el aspecto del sistema y lo que puede hacer, obtienen ideas más claras sobre lo que realmente necesitan y pueden solicitarlo con mayor precisión. El diseño surge con la experiencia a lo largo del tiempo.

El desarrollo de productos Lean lleva esto más allá con su enfoque en la entrega de valor. Guía a los equipos para que se concentren en lo que sus clientes tienen más claro: la funcionalidad principal del producto. La funcionalidad central está estrechamente ligada al proceso comercial, a lo que ya están haciendo, incluso si no está automatizado o está mal hecho. Los clientes pueden ser muy específicos acerca de estas características. Lo que no tienen claro, y sobre lo que tienen que especular, involucra la interfaz de usuario, las características esotéricas y otras campanas y silbatos geniales. A menudo, estos ofrecen el menor valor real para el cliente pero son los más seductores, tanto para el cliente como para el desarrollador, y por lo tanto es más probable que los desvíen.

El principio Lean aquí es crear conocimiento todo el tiempo. ¡Enfócate en entregar valor! Comience con lo que el cliente tiene claro, en los procesos centrales. Permítales adquirir experiencia y conocimiento y luego especificar el siguiente bit.

Este es un mejor enfoque para la planificación de productos que tratar de especificar cada requisito al principio. Incluso si no es posible lanzar por etapas, aún puede ser útil construir por etapas porque al hacerlo se concentra primero en la parte del sistema que el cliente tiene clara; desarrolla la claridad del cliente. Les hacemos un favor a los clientes al no pedirles que especulen, centrándonos en aquello con lo que se sienten cómodos. Y les hace un favor a los desarrolladores al reducir el riesgo, lo que hace que sea menos probable que creen características innecesarias. Y no crear características innecesarias significa menos tiempo perdido y, lo que es más importante, un sistema menos complejo.

El objetivo es involucrar a la empresa y al cliente en la planificación de una entrega más rápida en múltiples iteraciones, agregando valor en etapas. Este es el pensamiento Lean.

Promover el conocimiento-

-Desarrollo de productos basado y mejor gestión de proyectos

El beneficio más obvio del desarrollo de productos Lean-Agile es que descubres cómo te está yendo muy temprano en el proyecto. En proyectos que no son ágiles, no sabe realmente acerca de la calidad de su código hasta que ingresa a la fase de prueba del proyecto, que generalmente se encuentra al final del cronograma, si no al final. Tampoco sabe cómo reaccionarán los clientes a su producto hasta que los primeros probadores beta lo vean. Esto es un poco tarde en el ciclo. En muchos sentidos, los comentarios que recibe sobre un proyecto en este punto, que se ilustran en la Figura 2.8, en realidad solo son útiles para configurar la próxima versión.

Figura 2.8 Waterfall versus Agile: cuando obtiene una indicación real de dónde se encuentra

Esta retroalimentación cubre tanto el ritmo al que está trabajando como si está construyendo o no lo que el cliente quiere. En un proyecto Waterfall, aunque los clientes pueden ver el sistema mientras se construye, a menudo es difícil incorporar sus comentarios al sistema. Los procesos ágiles están orientados a permitir que el desarrollador utilice la retroalimentación rápidamente, tan pronto como se proporcione.

La mayoría de nosotros hemos estado en proyectos que estaban funcionando bien después de seis meses, pero luego estaban dos meses atrasados después de siete meses sin que se nos dieran nuevos requisitos. A menos que no esté utilizando el control de fuente, esto en realidad no es posible (podría hacer una copia de seguridad de donde estaba hace un mes y tener solo un mes de retraso). La realidad es que no estabas a tiempo en la marca de los seis meses, pero no lo sabías. Ahora sí, pero es un poco tarde en el proyecto para hacer algo al respecto.

Imagine un proyecto ágil de diez meses en el que descubre después de un par de meses que está retrasado. Tiene muchas opciones en este punto inicial: agregue más recursos, elimine el alcance, restablezca la fecha de finalización e incluso cancele el proyecto. Cuando nos enteramos tarde en el juego que un proyecto está en problemas, brinda pocas oportunidades para que la gerencia se ajuste. Hablamos de “marchas de la muerte” al final de muchos proyectos. En ese momento, la gerencia a menudo está enojada y molesta. Y donde hay ira, suele haber miedo. El miedo es rampante en muchos proyectos no ágiles cuando la gerencia siente que el equipo ha perdido el control del trabajo. Eso puede suceder cuando un equipo se basa en demasiadas predicciones y suposiciones que no se confirman.

Lo que es diferente acerca de los proyectos Lean-Agile es la forma en que se planifican, el papel de las pruebas y el sentido de urgencia sobre ellos. Estos presentan nuevos desafíos para el gerente de proyecto, quien debe facilitar la comunicación entre los equipos y los clientes, administrar la sustentabilidad y un sentido constante de urgencia, mantener la visibilidad y comunicar el verdadero ritmo de progreso a todos los involucrados. Pero estos son desafíos relativamente positivos.

Horizontes de planificación cortos

Uno de los mitos de Agile es que no planificas. De hecho, está planificando constantemente, solo que en incrementos más pequeños y con más personas de las que probablemente esté acostumbrado. Planeas

para lanzamientos. Usted planifica antes de cada iteración. Usted planifica en las reuniones diarias de pie. Tal vez el 15 por ciento del tiempo del equipo implica algún tipo de planificación. La diferencia es que, a nivel de proyecto, planifica lo que se sabe: de dos a cuatro semanas, la próxima iteración y el trabajo que haremos hoy. Planificar lo que es casi seguro es mucho más fácil que planificar lo que no se sabe. Esto es lo que hace que los proyectos Lean-Agile sean más fáciles de planificar.

Pruebas para mejorar el proceso y la calidad

Un principio clave de Lean es apuntar a la perfección, mejorar constantemente. En los proyectos Lean-Agile, esto impulsa fuertemente la forma en que se realizan las pruebas. Las pruebas se realizan muy temprano en el proceso de desarrollo para acortar el ciclo de tiempo entre la detección de un defecto y su reparación. Esto hace que sea probable que se entregue un código bastante bien perfeccionado al final de una iteración. También hace más probable que los defectos que se encuentren no tengan consecuencias graves.

La perfección significa que las pruebas no son solo para encontrar errores. Más aún, la actividad de prueba debe descubrir las causas de los errores y eliminarlos. El análisis de causa raíz es parte de la cartera de trabajo de las pruebas. Este enfoque de prueba es diferente del enfoque habitual, en el que la eliminación de errores se realiza mediante el desarrollo de especificaciones rigurosas y luego la prueba en una fase separada, generalmente después de que se completa el desarrollo. Eliminar la demora entre el desarrollo y las pruebas es lo que facilita la gestión de riesgos en los proyectos Lean-Agile. Muchos errores se derivan simplemente de una mala interpretación de los requisitos del cliente. Crear pruebas de aceptación por adelantado (al menos definirlas, si no implementarlas) cambia las conversaciones entre clientes, desarrolladores y probadores. Discutir las cosas a nivel de implementación, así como el nivel de requisitos, mejora la conversación, lo que ayuda a los desarrolladores a comprender lo que los clientes realmente quieren decir y necesitan.

Planificación sin miedo

Los proyectos Lean-Agile siempre tienen un sentido de urgencia. Los plazos breves y el estrecho contacto con el cliente suelen garantizarlo. Sin embargo, rara vez hay una sensación de pánico o miedo. Incluso si hay un contratiempo, el proyecto nunca se siente fuera de control y eso ayuda a evitar que la gerencia se enoje y tenga miedo por el proyecto. Obtienen una idea desde el principio si el proyecto está en marcha o en riesgo y pueden adaptarse a él; no se sorprenden por la falta de progreso al final de un proyecto largo (y una gestión sorprendente siempre es algo malo). El nivel de estrés entre los equipos de desarrollo Agile parece moderado y saludable. Contraste esto con los enfoques más tradicionales, donde la carga de trabajo en la parte delantera es relativamente baja y luego aumenta a crisis y consume más de 80 horas semanales al final; y luego, cuando hay reveses, las consecuencias se sienten nefastas y aumenta la presión. Tal ritmo y ambiente no pueden sostenerse o ser saludables por mucho tiempo. Los proyectos Lean-Agile tienden a sentirse más en control y a ser más sostenibles en el tiempo.

Motivar a los equipos y permitir el fracaso (aprendizaje) temprano

La retroalimentación que los clientes obtienen con Lean-Agile los ayuda a aclarar sus necesidades y les infunde confianza en que

sus necesidades serán satisfechas. Estos comentarios también ayudan a los desarrolladores.

En general, los desarrolladores disfrutan trabajar con el negocio y con los clientes cuando existe un sentido de propósito común y trabajo en equipo. Les gusta hacer un trabajo que impacte positivamente a los usuarios de su producto; tienen pasión por ayudar. Desarrollar iteraciones cortas y trabajar en estrecha colaboración con los clientes da como resultado muchos buenos comentarios y muchas ganancias rápidas. Este es un gran motivador para los equipos de desarrollo.

En este proceso, tanto los clientes como los desarrolladores descubren muy rápidamente qué no funciona ³ , qué suposiciones no son válidas y qué no saben. Esa información también es un buen motivador. Puede que no los haga felices, pero al menos les presenta desafíos que superar mientras todavía están en condiciones de reaccionar positivamente. Nada se siente peor que descubrir una falla importante al final del ciclo.

3. En la comunidad Agile dicen que quieren “fallar rápido” pero nosotros preferimos decir que queremos “aprender rápido”. Eso puede implicar fallar, pero puede que no. ¡Es mejor no fallar si no es necesario! Pero si estás fallando, aprende rápido. . . y corregir rápidamente.

Al obtener comentarios tempranos sobre cómo funcionan los métodos del equipo, los desarrolladores pueden realizar cambios rápidamente y evitar el desperdicio. A veces, esta retroalimentación tiene más que ver con el progreso del proyecto que con su proceso. Si es más lento de lo deseado, la gerencia puede optar por agregar más recursos, eliminar el alcance del proyecto, retrasar la fecha de finalización o incluso cancelar el proyecto al principio del ciclo. Con una gestión de proyectos sabia y pensamiento Lean, esto debería ser un motivador: Detenerse temprano en el proyecto equivocado o en un proyecto que es más costoso de lo factible es del interés de todos. Evita la agonía de trabajar en un proyecto durante seis meses o un año solo para descubrir que no hay apoyo comercial para él y que se cancelará. Eso se siente terrible, especialmente si el equipo estaba haciendo lo que se le pedía y lo estaba haciendo bien. En última instancia, es mejor trabajar en proyectos que tengan un vínculo comercial sólido.

Enfoque en el desarrollo centrado en el producto

Supongamos que está trabajando en un proyecto para el cual se cumple lo siguiente:

• No hay beneficio de una liberación parcial del producto; todo el producto debe estar terminado antes de que pueda ser lanzado. (Esto no es raro.)

• El cliente tiene perfecta claridad sobre lo que necesita. (Esto casi nunca sucede; incluso con reescrituras, el cliente suele tener mejores ideas la segunda vez).

• La gerencia confía en que el equipo producirá el resultado que se necesita; por lo tanto, el proyecto no tiene que ser controlado a través de iteraciones. (Esto sucede en ocasiones.)

• El equipo entiende Agile perfectamente. No hay curva de aprendizaje.

¿Seguiría queriendo usar Agile y un enfoque iterativo? ¡Sí!

¿Por qué? Porque la creación de software por etapas le permite aprovechar lo que ha aprendido a medida que lo crea. Todos los desarrolladores saben mucho más en

al final de un proyecto que al principio. Cuando diseñas todo por adelantado, hay una tendencia a exagerar la arquitectura, a incluir más de lo que necesitas. Esto agrega complejidad con la que el equipo tiene que lidiar durante la vida del proyecto.

Lean brinda información sobre cómo administrar los requisitos y el diseño en desarrollo, como se describe en detalle en Diseño emergente: la naturaleza evolutiva del desarrollo de software profesional (Bain 2008).

Mejore la eficiencia del equipo

Un problema al que se enfrentan muchos equipos es que las personas clave están ocupadas con varios proyectos. Esto degrada su eficiencia no solo porque se ven empujados en múltiples direcciones y deben cambiar continuamente de tareas, sino porque crea demoras para todos los demás que necesitan su ayuda. Los proyectos grandes tienden a tener más personas trabajando en varios proyectos a la vez, lo que reduce la eficiencia de los equipos.

Lean nos ayuda a minimizar el tiempo que lleva completar las soluciones comerciales y de clientes prioritarias. Para la mayoría de las organizaciones heredadas, esto significa que deben organizarse en torno a la secuenciación y la finalización de solicitudes más pequeñas y de alto valor antes de iniciar otras nuevas. En estas organizaciones, el impulso de mantener ocupada a la gente (para maximizar la eficiencia) parece motivar a los profesionales a iniciar más y más proyectos sin preocuparse por las consecuencias. El enfoque Lean es terminar el trabajo y entregarlo al usuario final antes de comenzar algo nuevo. En términos simples: deje de permitir que se acumulen colas de trabajo sin terminar. Esto tiende a reducir la competencia por recursos críticos porque los proyectos pasan por la tubería de desarrollo más rápido; esto por sí solo puede generar enormes mejoras en la eficiencia.

Resumen

Este capítulo describe seis beneficios de usar Agile para el desarrollo de software:

• Agrega valor al negocio rápidamente.

• Ayuda a aclarar las necesidades de los clientes.

• Se centra en el desarrollo de productos basados en el conocimiento, lo que conduce a una mejor gestión de proyectos.

• Motiva a los equipos y permite “fallar temprano”.

• Promueve el desarrollo centrado en el producto.

• Mejora la eficiencia del equipo.

También ofrece un modelo financiero que describe los beneficios de obtener el valor de los productos de forma incremental en lugar de versiones finales. Además de los beneficios financieros, todos los miembros del equipo (clientes y desarrolladores) pueden aprender más rápidamente e incorporar ese aprendizaje nuevamente en el producto y el proceso mientras todavía hay tiempo para hacerlo.

Prueba esto

Estos ejercicios se realizan mejor como una conversación con alguien en su organización. Después de cada ejercicio, pregúntense si hay alguna acción que puedan tomar para mejorar su situación.

P 1• ¿Qué tan involucrados están los clientes y las partes interesadas en el desarrollo diario del producto?

P 2• ¿Cuáles son los impedimentos para la retroalimentación frecuente de los usuarios de productos en desarrollo?

P 3• ¿Cómo ayudarían las entregas más pequeñas y más frecuentes de componentes verificables a mejorar la capacidad de los clientes y las partes interesadas para proporcionar comentarios?