Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Iteraciones. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Iteraciones. Mostrar todas las entradas

miércoles, julio 17, 2019

Estimaciones en los tiempos de la agilidad



Presentación

Hace algunos días, mis amigas Valeria Vásquez y Alejandra García, un par de cómplices caleñas convencidas de esto de generar espacios para compartir conocimiento que nos permita cambiar, me invitaron al cierre de una iniciativa que decidieron liderar desde el día mundial de la Retrospectiva en 2019, la cual consistía en realizar reuniones virtuales abiertas sobre distintos temas seleccionados por la gente. Mi tema era precisamente este de las estimaciones. Aquí les presento algunas conclusiones, no sin antes felicitar en grande a estas dos intrépidas que se han tomado este asunto de ser líderes de una comunidad que sigue expandiéndose y creciendo y que cada día presenta nuevos retos, como lo es Ágiles Colombia.

Ahora sí, vamos a lo que nos ocupa.

Sobre estimaciones bajo el manto ágil

Decíamos en la reunión que una Estimación es un proceso analítico e imparcial para predecir la duración o el costo de un proyecto o desarrollo de producto, de una iniciativa en general. Y hacíamos énfasis en que la estimación es una predicción, no es una planificación, ¡no es un compromiso! Además, “una estimación es buena cuando quienes estimaron consideraron toda la información que tenían a su disposición para el momento y el propósito de la estimación”, o algo así nos contaba mi gran amigo Wilmar Hincapié en una conversación anterior.

Pero ¿qué es eso de “considerar toda la información” disponible? Bien, debemos considerar el entorno VUCA en el que nos movemos hoy día, donde la volatilidad, la incertidumbre, la complejidad y la ambigüedad están a la orden del día, en donde no es posible predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo vamos a entregar y cuánto será su costo. Lo que sí podemos hacer es empezar con planes iniciales, planes cuya elaboración no tome mucho tiempo y sobre los cuales haya certeza de que van a cambiar, quizás tanto como todos los días. Después de todo, la meta es entregar el mejor producto o servicio posible, no la planificación en sí y mucho menos la estimación. Es lo que hemos dado en llamar “filosofía ágil”. Más sobre esto en mi artículo “Cultura ágil: ese oscuro objeto del deseo”.

No estimamos en el universo de lo simple ni de lo complicado, sino en el entorno de lo complejo, de lo caótico y hasta del desorden (Cynefin). Por ello es que no existen las “buenas” técnicas de estimación ágil, aunque tampoco existen las malas, son simplemente técnicas, experimentos que hacemos para tratar de calmar el ansia de todos los interesados en temas como la duración de una iniciativa o en las fechas de entrega de producto.

Debemos deshacernos de una vez por todas y para siempre de las cadenas que nos impuso el triángulo de hierro de los proyectos tradicionales, ese que establecía el éxito de un proyecto si este se encontraba dentro de los límites de tiempo, alcance y costo estimados. En este orden de ideas los invito a que consideren mi enfoque integral de gestión de personas y desarrollo de productos (resultados y restricciones) que expongo en el triángulo ágil extendido.

Técnicas de Estimación



Sobre este asunto de las técnicas o experimentos para estimar también hablamos un poco.

1. Planning Poker

La experiencia nos ha enseñado a usarla cuando tenemos un número relativamente pequeño de elementos a estimar y con un equipo pequeño de personas. Más sobre esta técnica en https://www.mountaingoatsoftware.com/agile/planning-poker.

2. Tallas de camiseta

Esta es una técnica muy buena para estimar un backlog grande de producto. Especialmente cuando tenemos varios equipos concurrentes trabajando en el mismo producto. Es una manera informal y rápida de tener una idea aproximada del esfuerzo requerido para hacer algo. Para saber más sobre la técnica, accede a http://getskillsblogs.com/agile-estimation-with-t-shirt-sizes/.

3. Puntos de votación (dot voting)

Útil cuando nos enfrentamos a un conjunto relativamente pequeño de elementos y necesitamos una técnica súper simple y efectiva para estimar. El método se originó a partir de la toma de decisiones. Funciona bien tanto para equipos pequeños como para grandes, pero tenemos que limitar el número de elementos estimados. Más sobre la técnica en http://www.informit.com/articles/article.aspx?p=2117898&seqNum=3.

4. El sistema del cubo

Mucho más rápido que el planning poker es el sistema de cubos. Este sistema es una buena alternativa al estimar un gran número de elementos con un gran grupo de participantes. Más sobre este curioso método en:

5. Grande / Incierto / Pequeño

Un método muy rápido de estimación aproximada es el método Grande / Incierto / Pequeño. Se le pide al equipo que coloque los artículos en una de estas categorías. El primer paso es categorizar los elementos obvios en las dos categorías extremas (Grande y Pequeño). A continuación, el equipo puede discutir los elementos más complejos. Esto es en realidad una simplificación del sistema de cubos. El sistema es especialmente bueno para usar en equipos más pequeños con elementos comparables. Como siempre, podemos asignar tamaños numéricos a estas 3 categorías.

6. Mapeo de afinidad

Funciona mejor con un grupo pequeño de personas y un número relativamente pequeño de elementos. Más información sobre la técnica en:

7. Método de ordenamiento

Este es un ejercicio donde se obtiene una imagen precisa del tamaño relativo de los elementos. Funciona mejor con un pequeño grupo de expertos. Todos los elementos se ponen en orden aleatorio en una escala que va de “pequeña” a “grande”. A cada participante se le pide que mueva un elemento en la escala. Cada movimiento es solo un punto más bajo o uno más alto en la escala (muy pequeños, pequeños, medianos, grandes, muy grandes), o simplemente el participante cede el turno. Esto continúa hasta que ningún miembro del equipo quiera mover elementos o ceda su turno.

El método funciona mejor con un grupo relativamente pequeño de personas y una gran cantidad de elementos.

Más sobre una “buena” estimación


  • Siempre demos un rango, nunca demos un número. Los números son para hechos, los rangos son para estimaciones
  • Siempre preguntemos para qué serán usadas nuestras estimaciones. ¿A qué nos hemos comprometido? ¿Basados en qué información?
  • La estimación es diferente de un compromiso. Realizar una estimación “errónea” no hace daño.
  • Primero tratemos de medir, contar y calcular. Estimemos solo cuando sea necesario.
  • Por sobre todas las cosas, ¡nunca negociemos las estimaciones! Siempre preguntemos las razones y los supuestos detrás de las estimaciones.
Juegos de estimación dañinos que debes evitar

La estimación es un juego pero evita los juegos de estimación dañinos:
  • ¡Adivina el número que estoy pensando!
  • ¡Un equipo increíble como el de ustedes puede hacer mucho más que esto!
  • Esta vez será mucho más rápido porque hemos aprendido mucho del proyecto anterior.
  • ¡Este proyecto será muy diferente!
  • Si trabajamos un poco más duro, aumentaremos la velocidad.
  • ¡Puedo programar esto en la mitad del tiempo! O el infame arte de hacer el doble de trabajo en la mitad del tiempo.
  • Si bajamos la estimación, el proyecto se hará más rápido (esto realmente funciona en algunos escenarios).
Recomendaciones finales
  • Si sigues estimando como hace dos años o más seguramente no eres  ágil, es más, quizás ni estés haciendo estimaciones propiamente dichas.
  • Experimenta con muchos tipos de estimación
  • Estimas trabajo de conocimiento, trabajo creativo, no trabajo predecible y repetitivo.
  • Toma la estimación como un juego, un juego serio pero juego al fin y al cabo.
  • Usa técnicas de estimación relativa.
  • Con cautela, hazle caso a La ley de los grandes números.
  • Fija objetivos y resultados clave (OKR), no números fríos.
  • No estimes, a nivel de iteraciones, si no conoces la Definición de Terminado ni los criterios de aceptación.
  • Cuando se trate de productos o de características de producto, estima en iteraciones o, a lo sumo, en días. Deja las horas para las actividades diarias.
  • Estima para un rango que va desde la Mínima Entrega Viable hasta la Entrega Completa. Es decir, asegúrate de que en ese rango de tiempo harás una entrega de valor.
  • Evita a los “influenciadores” expertos y, en general, a quienes pueden crear distractores al momento de realizar la estimación.
  • Estima valor de negocio, no puntos de historia.
  • Experimenta, crea tu propio método de estimación. Por ejemplo, el método 1 – 5 – 9 es una técnica simple que consiste en establecer si el elemento se puede elaborar o no en una iteración junto a otros 5 a 9 elementos. De ser afirmativo, es porque contamos con la suficiente información para desarrollarlo a continuación. Útil para usar durante la planificación de una iteración de menos de un mes de duración.
  • ¡O simplemente no estimes del todo! Enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.


miércoles, julio 13, 2016

SCRUM CARD GAME – Un juego para experimentar Scrum


SCRUM CARD GAME es un juego simple que permite a los jugadores experimentar el trabajo en sprints de Scrum discutir muchas cuestiones y temas que suceden en la vida real mientras trabajan en un equipo Scrum. La discusión sobre la mesa  de juego será muy cercana a la experiencia real del trabajo en un equipo Scrum. Este juego usualmente se juega durante un entrenamiento o taller. Los participantes ya deben conocer y entender el marco de trabajo Scrum o pueden aprenderlo mientras participan del juego. También puede servir como método para hacer que un equipo experimentado reflexione sobre sus rituales y reglas establecidas de Scrum.

El eje del juego es que cada equipo (de 4 a 6 personas) es un centro de desarrollo competitivo contratado para llevar una nueva aplicación al mercado. El equipo más productivo gana.

Los materiales para el juego incluyen:
  • Un juego de cartas de Historias, Eventos, Problemas y Soluciones. Estas son las cartas de Oportunidad. Estas se encuentran en el manual oficial del juego del que comento más abajo.
  • Dos dados de seis lados (para cada equipo)
  • Rotafolio
  • Marcadores

Podrán imaginar ustedes que los sucesos del juego ocurren durante los sprints, se pueden jugar hasta tres sprints aunque es posible jugar 4 o más. Los sprints son de tres días de duración y durante cada día cada uno de los miembros del equipo trabaja en el sprint. En cada Sprint los equipos realizar Planificación, Revisión y Retrospectiva y durante la ejecución del sprint se experimentan conceptos como impedimentos o bloqueos, definición de Terminado, trabajo, Tablero de tareas, Backlog, entre muchos otros.

Al final del juego es posible hacer un análisis de temas tan importantes para los equipos ágiles como:
  • Esfuerzo planeado versus Real
  • Variaciones en la velocidad
  • Horas Estimadas versus Tamaño (Estimado Original)
  • Riesgos mayores que sucedieron (Técnicos, Personas, Eventos No Planeados)
  • ¿Cuáles son los tipos de riesgos más difíciles de tomar?
  • ¿Podemos proyectar eventos malos?
  • Entre otros

El autor del juego es Timofey Yevgrashyn, un agilista de Europa del Este, Gerente Ágil con experiencia en consultoría, coaching y entrenamiento. Timofey  tiene experiencia en el lanzamiento y liderazgo de transformaciones Ágiles/Lean que conducen a alinear las entregas con los objetivos del negocio. Hasta este año (2016) ha ayudado a más de 50 equipos de más de 10 países y ha completado cerca de 3000 horas de entrenamiento Ágil a más de 4000 personas. ¡Eso es estar en el campo de batalla!

Timofey se basó en su trabajo pragmático y en sus entrenamientos para diseñar este fabuloso juego, además de otros que pueden encontrar en su blog que escribe desde 2009 en lengua Rusa “The Improved Methods” (http://tim.com.ua). Conocí el juego y lo he jugado con algunos equipos mixtos de personas con mediana, poca o ninguna experiencia en Scrum y los resultados han sido grandiosos. Por eso hablé con Tomofey para que trabajáramos juntos en la versión del juego en español y el resultado ya está aquí.

Mientras él termina de implementar un sitio exclusivo para el juego, pueden encontrar la versión en español su sitio actual:

En la sección Переводы. No se preocupen, si no saben ruso, se trata de la sección Translations (Traducciones).

Descarguen el juego con las tarjetas coloridas imprimibles y no dejen de contarme en el foro, más abajo, sus experiencias con el mismo.

jueves, junio 16, 2016

Purga ágil de producto




Nuestro backlog del producto puede no tener una “buena salud”. Es decir, puede contener elementos que lo oscurezcan o que disminuyan su transparencia. Por lo general estos elementos tienden a ir hasta el fondo del backlog y muchas veces no son detectados hasta que es muy tarde en el proyecto, trayendo como consecuencia la extensión innecesaria del esfuerzo de desarrollo y la desmotivación del equipo debido a la gran capacidad energética que sus miembros invierten en estos elementos de poco o ningún valor para el producto y para el negocio.
Una de las técnicas que podemos aplicar al backlog y, por consiguiente, al producto, es esta de la purga del producto. Los detalles de cómo hacerlo lo encuentran en mi artículo en Pulse de LinkedIn:

martes, enero 19, 2016

Agilidad: algunas características intrínsecas

Infografía: Agilidad 101. Clic en la imagen para ampliar.

AGILIDAD

La habilidad de las personas, equipos y organizaciones de crear Valor, a la vez que promover y responder al cambio para tener éxito en un entorno incierto.

Algunas características intrínsecas a la Agilidad son:
RETORNO DE LA INVERSIÓN

Ágil proporciona ROI en forma de beneficios cualitativos como el mejoramiento de la moral del equipo y principalmente ROI en la forma de beneficios cuantitativos, expresado en términos económicos, mediante la entrega continua y frecuente de soluciones con Valor.
MARCOS DE TRABAJO

Estamos descubriendo formas mejores de desarrollar software. Los marcos de trabajo ágiles son iterativos e incrementales y de Valor. Scrum y otros métodos y prácticas ágiles se basan en la teoría empírica, es decir, aprendemos de la experiencia. El propósito final de las prácticas ágiles no es tanto el hacer como el encontrar formas mejores del hacer.
TIEMPO

Entregamos productos frecuentemente, incluso todos los días. Las iteraciones son períodos muy cortos de tiempo que finalizan con la entrega de productos que generan Valor del negocio.
DOCUMENTACIÓN

Valoramos más las soluciones en uso que la documentación exhaustiva. La meta de ágil es encontrar el balance adecuado entre la documentación y la comunicación cara a cara. La documentación es una parte importante de todo producto, pero la documentación exhaustiva como tal no asegura el éxito de un proyecto. De hecho, aumenta la probabilidad de fracaso.
INNOVACIÓN

En la forma de mejoramiento continuo.  Las prácticas ágiles nos permiten encontrar formas innovadoras para crear productos y servicios mejores, más baratos, más livianos, más rápidamente y de una forma más conveniente y personalizada para nuestros clientes.
PERSONAS

Valoramos más las personas y la comunicación cara a cara entre las personas. Lo más importante en el ecosistema ágil somos las personas. Los equipos son autoorganizados y nuestra mayor prioridad es satisfacer al cliente.
MEDICIÓN


Las mediciones se hacen mediante observación directa en el lugar de trabajo, el Gemba, y medimos la realidad de la organización y de los proyectos con el ánimo de encontrar continuamente opciones de mejoramiento. Fomentamos la retroalimentación continua en todas las direcciones. 

miércoles, octubre 28, 2015

El enfoque Iterativo e Incremental, ¡una vez más!


El enfoque Iterativo e Incremental, ¡una vez más!
Mucho se habla de esto, de hecho iba a titular este artículo: “Todavía otra lección más sobre el enfoque iterativo e incremental para construir productos (de software)” pero entonces pensé en cambiar ligeramente la dirección del tema… Pero no tanto.
Iterativo e incremental son de esos principios que pueden resultar artificiosos para quienes intentan aplicarlos por primera vez. Su interpretación se  presta a confusiones y a desacuerdos y finalmente los productos que surgen de los así llamados ‘proyectos iterativos e incrementales’ terminan siendo una colcha de retazos, pedazos de funcionalidades que no se integran bien entre sí y que terminan ocasionando más problemas al usuario de los que intentan resolver.
En breve, ‘iterativo’ quiere decir ‘en períodos cortos de tiempo’. El término clave es ‘cortos’. ¡De menos de un mes, gritamos a los cuatro vientos los agilistas! Durante este período se diseña y se construye, en el sentido extenso de la expresión ‘diseñar y construir’, una parte del producto que llamamos ‘incremento’. Pero no es cualquier parte del producto la que se construye. Sin embargo no voy a detenerme mucho en ello. Pueden consultar más sobre ‘Iterativo e Incremental’ aquí, gracias a Javier Garzás, o en cualquiera de estos lugares:
O algunos de los míos:
Entre muchos otros. Y no puedo terminar esta breve presentación del tema sin referirme a esa imagen que ya se está convirtiendo en icónica y que ilustra muy bien este par de conceptos: se trata de la imagen de Henrik Kniberg, actualizada:

Pero a dónde verdaderamente quiero llegar esta vez es a este asunto del ‘Incremento de Valor’, ¿qué quiere decir eso realmente? Así que empecemos de nuevo:

El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor

Resuelta la trama de ‘Iterativo e Incremental’, lo que queda es entender qué significa ‘producto de Valor para el cliente o usuario’, qué significa ‘Desarrollo de producto dirigido por el Valor’. Vamos a ver si lo logramos entender:
En este enfoque, conocido también como ‘desarrollo guiado por el valor’ o VDD, por sus siglas en inglés, el cliente o usuario juega un papel primordial:
  • Es el cliente o usuario del producto quien determina o establece su valor, no el equipo de desarrollo
  • Es el usuario o cliente quien solicita el producto, o esa porción del producto, es decir, fue ese usuario o cliente quien priorizó el desarrollo de ese incremento en ese momento del tiempo (del proyecto)
  • El incremento resuelve un problema pequeño o parte de un problema grande al usuario
  • Le permite obtener retorno de la inversión que está haciendo (ROI): reduce los costos para el negocio o aumenta las ganancias… ¡o ambas cosas a la vez! En últimas, al entregar el producto hay o se genera una compensación para el usuario, además de la satisfacción aumentada y de la felicidad recargada, no solo de él como receptor de un objeto de valor, sino de todo el equipo de desarrollo y, por qué no, de todos los demás interesados, dado el logro de objetivos.

Foto de FreeDigitalPhoto.Net
  • Varias o muchas personas se benefician de inmediato con el producto (con su uso), ya sea porque lo están usando directamente (usuarios, clientes) o porque otros lo usan (patrocinadores, otros interesados, alta gerencia, etcétera)
  • El producto está diseñado para humanos, sus componentes hacen resonancia unos con otros e impactan el modus vivendi de las personas, aunque solo para mejorarlo
Human-driven development o HDD –Desarrollo de Software Para Personas. Foto de FreeDigitalPhoto.Net 
  • El riesgo del proyecto, inherente a cualquier tentativa de construcción de software, se reduce dramáticamente luego de las primeras entregas. Si hemos de fallar, que sea rápido, en porciones pequeñas y muy barato. A partir de allí, el ascenso hacia el logro de los objetivos es vertiginoso y siempre positivo.
  • El crecimiento del producto es orgánico, se parte de un mínimo producto viable o ‘mercadeable’ (MVP por sus siglas en inglés) y el producto completo va creciendo alrededor de este MVP, en entregas sucesivas y constantes. Y ya que llegamos a este apartado, olvidémonos del “viable” en el MVP, la V ahora es por Valor, como en Mínimo Producto de Valor. Recordemos que este MVP es el primer objeto con el que el cliente o usuario podrá interactuar, así que el impacto a conseguir debe ser máximo, debemos hacer que se convierta en un objeto de deseo. A propósito de deseo, entonces en vez de llamarlo MVP, nombrémoslo MDP, por las siglas en inglés de Mínimo Producto Deseable. Es un juego de palabras, apenas para mi Gazafatonario, pero ayudan a entender lo que queremos realmente con esta generación de valor desde las primeras de cambio.
  • Se disminuye considerablemente la incertidumbre, tanto la del proyecto como un todo, como la del producto que se empieza a usar. Esto ocurre porque con cada entrega el equipo conoce mejor a su usuario y aprende mucho más rápido de sus necesidades y ambiciones. A la postre, el equipo construye el software para aprender y medir el impacto del uso real del producto. Después de todo, el proceso de creación de conocimiento se acelera si ellos entregan rápido un conjunto mínimo de elementos del producto priorizados por los objetivos que el cliente quiere alcanzar.
No son las únicas condiciones, si acaso algunas de las más importantes. En cualquier caso, la próxima vez que te soliciten un plan de trabajo para un proyecto, ya sea a mediano o a largo plazo, ten el coraje de responder: ¿quieres un plan a mediano/largo plazo o Valor en términos cortos?
Nota: este artículo se publicó originalmente en Pulse de LinkedIn en el siguiente enlace: https://www.linkedin.com/pulse/iterativo-e-incremental-luis-antonio-salazar-caraballo

viernes, septiembre 11, 2015

Gerencia de Proyectos Iterativos: de cómo el software se puede construir por incrementos

Divide et impera: ‘divide y vencerás’. Frase atribuida a Julio César.
FreeDigitalPhoto.Net
Los proyectos de construcción de software deben responder con prontitud a los cambios frecuentes e inesperados tanto en los requisitos del negocio como en la tecnología de implementación. Es habitual que en estos proyectos haya una gran incertidumbre en cuanto al alcance, a la fecha de entrega y al presupuesto requerido, lo que conlleva un alto número de riesgos que obstaculizan la consecución de los objetivos propuestos.
Por ejemplo, es un grave error con consecuencias atroces, asumir que los usuarios –generalmente personas de mandos medios y altos– son capaces de suministrar al equipo del proyecto información oportuna y precisa de todos los requisitos para un sistema de software. Además, uno de los problemas principales de la construcción de software tradicional recae en el hecho de que quienes han estado involucrados en ello hasta la fecha no están dispuestos a reconocer que esta actividad es, la mayoría de las veces, un asunto de planeación ocupacional y organizacional.
Corresponde precisamente al gerente del proyecto lidiar con todos estos factores que entorpecen la evolución normal de un proyecto de software. Es el gerente del proyecto quien sabe que los procedimientos tradicionales seguidos tienen un conjunto de riesgos tácitos “indetectables” dada la propia naturaleza del ciclo de vida de los proyectos. Los proyectos iterativos propician la detección temprana de los riesgos y facilitan su manejo anticipado por parte de los responsables. Pero ¿qué es realmente un proyecto iterativo? Para entenderlo, veamos lo fundamental.
¿Qué es una Iteración?
Una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada.
Esta definición lleva implícito un concepto muy importante: la versión o porción de software que se produce en una iteración tiene tales cualidades que se podría no solo mostrar al usuario sino poner en producción. De hecho, en fases avanzadas del proyecto, esto ocurre con regularidad; es decir, en un proyecto iterativo es posible tener versiones del software funcionando antes de terminar el proyecto.
Características de las Iteraciones
Ahora bien, como cualquier proyecto (de software), una iteración pasa por todas las etapas de un proyecto tradicional: inicio, planeación, ejecución y control, y cierre. En el caso particular de los proyectos de software, durante la etapa de ejecución y control de una iteración encontramos el ciclo tradicional del software: modelado de requisitos, análisis y diseño, implementación, pruebas, integración y, opcionalmente, despliegue, aunque una iteración no necesariamente cubre todas las etapas.
Pero la verdadera esencia de las iteraciones radica en otros aspectos que buscan disminuir la incertidumbre en los proyectos, aumentar el desempeño, mitigar los riesgos, sobre todo reducir los riesgos técnicos en las primeras iteraciones, y recibir retroalimentación continua y efectiva de los usuarios. El primero de estos aspectos es la duración de las iteraciones: de unos pocos días hasta unas pocas semanas es lo más eficaz, aunque también depende del tamaño del equipo y de la duración total estimada del proyecto.
Figura 1: esquema de una iteración típica. Cada iteración es un mini-proyecto con todo lo que ello implica.
Excepto quizás en proyectos grandes con más de 40 o 50 personas, la idea es no tener iteraciones de varios meses, ya que en ese tiempo puede ocurrir lo que sucede en los proyectos ejecutados en cascada: hay poca o ninguna mitigación de riesgos técnicos, puesto que no hay entregas “visibles” para los usuarios, recibimos poca retroalimentación de ellos y así no medimos eficientemente el progreso del proyecto, o no podemos reaccionar a tiempo ante una mala decisión técnica que conduzca a un retraso en el proyecto.
Duración de las iteraciones
Número de personas
Duración
2 a 15
2 a 4 semanas
15 a 30
4 a 6 semanas
30 a 50
6 a 8 semanas
Fuente: Bittner, K. Spence, I. Managing Iterative software Development Projects. Addison Wesley Professional. Junio 27, 2006.
Otro aspecto importante es que la duración de las iteraciones no tiene que ser la misma, pero la desviación debe ser pequeña. La idea es no tener iteraciones de dos semanas y otras de seis o más. Scrum, una metodología ágil ampliamente usada hoy día, por ejemplo, promulga iteraciones de 30 días, llamadas Sprint, con equipos de menos de 10 personas. Y ya que menciono Scrum, me parece importante aclarar que no todos los proyectos iterativos son ágiles, pero todos los proyectos ágiles son iterativos; la iteración es una propiedad intrínseca de las metodologías ágiles de construcción de software.
Gestión iterativa de proyectos
Otra de las características principales de este tipo de proyectos es que en las primeras iteraciones se construye la porción de producto que es significativa para la arquitectura del software. El gerente del proyecto se apoya en el arquitecto y en los ingenieros de requisitos para tomar la decisión de cuántas iteraciones “arquitectónicas” tendrá el proyecto, normalmente de 1 a 3, y qué funcionalidad será implementada, de tal manera que al final de esta fase (llamada de Elaboración, de Planeación o de Arquitectura, según la metodología que se use), no solo existe un documento de arquitectura o de diseño de alto nivel, sino que hay software funcionando cuyo propósito es demostrar que esa es la arquitectura correcta para el producto.
Figura 2: Perfil de los riesgos durante la gestión iterativa de proyectos. Los riesgos técnicos disminuyen en las primeras iteraciones. Contrario a lo que sucedía con el método en cascada, donde los riesgos disminuían al final del proyecto, durante las pruebas en el mejor de los casos.
La gestión iterativa de proyectos puede tomar muchas formas, dependiendo de las metas del proyecto: el desarrollo iterativo de prototipos puede ayudar a evolucionar una interfaz de usuario. El desarrollo ágil es una forma de involucrar muy de cerca un usuario en un proceso que podría repetirse diariamente. Entre tanto, el desarrollo incremental permite al equipo del proyecto a producir incrementos semanales o en cortos períodos de tiempo, mientras que un modelo en espiral puede ayudar al equipo a confrontar y a mitigar los riesgos de un producto en evolución.
En estos casos es el gerente del proyecto quien toma la decisión de la estrategia a seguir, teniendo en cuenta el valor de distintas variables: tamaño del proyecto, tamaño del equipo, experiencia del equipo y de los usuarios, criticidad y complejidad del proyecto, los riesgos técnicos y administrativos, el grado de volatilidad detectada de los requisitos y las herramientas de apoyo disponibles.
Foto de FreeDigitalPhoto.Net
La gestión iterativa ayuda a superar las barreras de especificación y de comunicación entre los usuarios y el equipo de trabajo con el único objetivo de alcanzar la más alta satisfacción de los primeros. El factor clave es precisamente que las personas del negocio entiendan los requisitos y retroalimenten a las personas de tecnología. En este apartado, el papel del gerente es de mediador, por lo que debería incluir elementos de comunicación efectiva, como la tolerancia –cuando no se confunde con la pasividad–, la imparcialidad y la empatía, para construir confianza y disciplina entre unos y otros.
Corresponde al Gerente del Proyecto integrar el equipo de trabajo con todos los involucrados tanto internos como externos y la gestión iterativa posibilita una integración paso a paso. Para lograrlo, el gerente del proyecto debe tener en cuenta algo que está fuera de su control: una infraestructura cambiante y un proceso de negocio inestable. También se debe vincular la estructura del proyecto (iterativo) con el éxito del proyecto, de esta forma, no habrá espacio para la ruina del proyecto.
Esto se logra mediante la motivación interna del equipo de trabajo, el desarrollo de competencias blandas (negociación, técnicas de comunicación –escrita, verbal y no verbal–, manejo eficaz del tiempo, creatividad, trabajo en equipo, entre otras) y la “implantación no invasiva de chips de alta efectividad”, como la proactividad y la sinergia.
Ahora bien, puede haber muchas desviaciones de un plan de proyecto de desarrollo de software. En estos casos, el gerente de proyecto decide cómo manejarlas, puesto que cada retraso requiere de una acción de su parte. Sin embargo, las opciones del gerente son muchas veces limitadas y una de las estrategias que puede seguir es esta de la agenda iterativa. Esto permite corregir o ajustar los planes de trabajo a medida que se desvían de las medidas iniciales.
Por ejemplo, si una iteración toma más tiempo del programado debido a un problema técnico que el equipo del proyecto tardó en responder o a la toma de una decisión por parte del usuario, el gerente puede reprogramar las iteraciones subsiguientes de tal forma que el plan original global del proyecto no se vea afectado.

En cualquier caso, todas las formas de gestión iterativa proporcionan una manera de:
  • Integrar y validar la evolución del producto continuamente
  • Demostrar progreso en cortos períodos de tiempo
  • Alertar pronto al equipo del proyecto de los problemas suscitados
  • Entregar funcionalidad de manera temprana
  • Incorporar sistemáticamente el re-trabajo inevitable que ocurre en el desarrollo de software

En resumen, la gestión Iterativa de proyectos facilita procedimientos para el desarrollo exitoso de aplicaciones y minimizan tanto los riesgos como los costos, combinando técnicas de administración bien estructuradas de métodos en cascada con técnicas de validación temprana del modelo evolutivo. Este proceso es más adaptable a situaciones diversas en proyectos de software y da al gerente la flexibilidad necesaria para acomodarse a un rango dinámico de alternativas técnicas.

Información
Este artículo fue publicado originalmente por la Revista de la Asociación Española de Profesionales en Dirección de Proyectos, en marzo de 2012. Para acceder al artículo original, pueden hacer clic aquí.