Agile Planning / Planificación Agile

Revelación

Hacer la estimación y la planeación del desarrollo de un producto puede ser una tarea desalantadora que se hace más complicada por nuestra ignorancia o mala interpretación acerca de los proyectos, como concepto y en proyectos específicos. Hace tiempo leí (enlaces al final) que un proyecto no debía ser visto sólo como una secuencia de pasos, sino que también debía ser visto como un flujo rápido que genera nuevas capacidades y nuevo conocimiento. Las nuevas capacidades se entregan como parte del nuevo producto y el nuevo conocimiento se utiliza para hacer un mejor producto (Cohn 2006). Esto es la base para el enfoque Agile sobre la planeación.

Al comenzar a leer sobre admintración de proyectos trabajaba como desarrollador, y esa frase (del párrafo anterior) fue una de mis primeras revelaciones serias acerca de porque trabajaba tan duro codificando para funcionalidades que al final no se utilizaban o bien en proyectos que no lograban sus objetivos plenamente. Parte de las fallas de esos proyectos fueron desde luego, aveces no planear en lo absoluto, pero también tratar de planear todo desde el principio. En un proyecto Agile utilizamos las nuevas capacidades y el nuevo conocimiento obtenido como guía para el trabajo mismo que se está realizando. El conocimiento obtenido puede ser acerca del producto o del mismo proyecto en general, lo importante es que este nuevo conocimiento nos da mejor idea de cómo debería ser el producto en el cual trabajamos o bien se convierte en mejor entendimiento sobre una tecnología, sobre el equipo, sobre los riesgos, etc.

Cuando pretendemos planear todo desde el principio (ni hablar cuando no planeamos) estamos fallando en integrar nuevo conocimiento al plan, y por lo tanto eso nos lleva a caer en suposiciones erróneas, como creer que estamos incluyendo TODO los necesario en nuestro plan (lo que en el mundo del software rara vez sucede).

Mis amigos desarrolladores son mayormente gordos y feos (pero aun así los quiero 😃) y no les gusta correr, pero a mí sí, por lo que utilizaré la siguiente analogía: Una aproximación tradicional a un proyecto puede ser como una carrera de 10km donde usted sabe exactamente dónde está la meta y trata de alcanzarla tan rápido como sea posible. Un proyecto Agile es como cuando usted se toma el tiempo y ve que tan lejos puede llegar en 60 minutos. Un equipo Agile sabe cuándo termina, pero no exactamente que entregará al final. Por lo tanto, planear se convierte en proceso en donde crean y revisan objetivos periódicamente que eventualmente llevan a una meta de más largo término.

Niveles de planificación Agile

Cuando estamos preparando los objetivos de un plan es importante reconocer que no podemos ver más allá de cierto horizonte y que la exactitud de nuestro horizonte será cada vez menor entre más lejos queramos ver. En mis cursos menciono los primeros capítulos de una seria llamada Vikings en donde plantean someramente el uso regular de un compás solar, un piedra solar y cuervos para poder corregir el rumbo periódicamente y mantener un curso correcto; de esta misma manera nosotros debemos revisar el estado de nuestro proyecto y ajustar nuestro plan de acuerdo a ello. Desde este punto ya estamos hablando de la elaboración de una planeación estratégica con el enfoque Agile.

Como ya expresé el riesgo de un plan se incrementa de acuerdo a que tan lejos en el futuro queramos planear, por ello cada cierto tiempo debemos levantar nuestra vista para ver el nuevo horizonte y ajustar el plan. Los equipos Agile hacen esto planeando en por lo menos 3 distintos horizontes (podrían ser más dependiendo de la aproximación de su organización, pero en esta entrada solo explicare estos). Los 3 horizontes son el Release (Liberación), Iteración y Diaria (actual). Puede tomar como referencia el siguiente diagrama (este no es un estándar, puede encontrar diferentes diagramas similares, pero los 3 horizontes princiaples no cambian):

Niveles de Planeación
Horizontes de Planificación

Planificación del Release (Liberación).

Aquí determinamos respuestas a preguntas que se relacionen con el alcance, el calendario y los recursos del proyecto. Este plan deber ser actualizado a lo largo del proyecto, usualmente al inicio de cada iteración para reflejar las expectativas actuales que serán incluidas en el Release.

Planificación de la Iteración.

Esta se lleva a cabo al inicio de cada iteración y basada en el trabajo que se hizo en la iteración anterior (si no es la primera desde luego). El cliente o sus representantes (el Product Owner) debe identificar los elementos de mayor prioridad en los cuales el equipo concentrará sus esfuerzos en la nueva iteración. Esto porque estamos en un horizonte más cercano que el del Release. En este horizonte se establecen las tareas requeridas para obtener una parte funcional y probada de nuestro producto.

Planificación Diaria.

Puede sonar muy excesivo (y quizá lo es) llamar planificación a este horizonte, esto no son más que reuniones diarias e informales (que usualmente se hacen de pie ya que solo deben durar unos minutos) en donde se sincronizan los esfuerzos diarios individualmente. Esto es que cada miembro del equipo comparte que ha hecho el día anterior, que piensa hacer hoy y comunica los obstáculos que afronta.

Con estos tres horizontes (Release, Iteración y Diaria) los equipos ágiles se concentran sólo en lo que es visible e importante en el plan que han creado. De esta manera han adoptado el enfoque de la planificación Agile.

Condiciones de Satisfacción.

En una futura entrada dedicaré más detalle a esto (lo merece) pero no quiero dejar de mencionar esto en esta entrada, por lo menos de manera breve. Todo proyecto debe comenzar con una meta, quizá de esta se deriven varios objetivos relacionados con fechas, presupuesto, recursos humanos, etc., pero típicamente solo habrá una meta. No dé por hecho que usted deber crear el mejor auto del mundo, la mejor puerta del mundo, el mejor ERP del mundo; los objetivos sólo deben alinearse con las condiciones de satisfacción del Producto Owner (la voz del cliente); esto es, los criterios que serán utilizados para evaluar y determinar el éxito del proyecto.

Enlaces relacionados:

El Origen Y Los Valores De Agile

El Enfoque del Equipo Agile

Planeación, Cono de Incertidumbre y Estimaciones en IT

Estos son alguno libros recomendables para saber más:

IT professional with several years of experience in management and systems development with different goals within public and private sectors.

Facebook
Facebook
Google+
Google+
https://internet80.com/blog/el-enfoque-agile-planificacion/
YouTube
YouTube
LinkedIn
Follow by Email
RSS