Jim Highsmith es miembro fundador de la alianza ágil, y uno de los “agilistas” más reconocidos internacionalmente. Sus libros “Agile Software Development Ecosystems” y “Agile Project Management” son lecturas fundamentales para el entendimiento y adopción de Ágil. Recientemente, Jim estuvo en México para impartir un taller organizado por Cutter Consortium. Aprovechando la ocasión, platicamos con él para conocer más sobre su visión de la administración de proyectos ágil.
Patrones para la Adopción de Ágil
En general, yo veo que las organizaciones de TI pasan por tres etapas de madurez en su forma de administrar proyectos de software. Empiezan en un estatus de caos, o ausencia de control. Al darse cuenta de este problema, deciden adoptar metodologías con alto grado de definición, documentación y puntos de control/autorización. Es lo que yo llamo “control prescrito” y básicamente consiste en generar un plan y adherirse a él. Esta estrategia ayuda a tener las cosas bajo control, y funciona durante un tiempo o para cierto tipo de proyectos. Sin embargo, cuando las organizaciones se enfrentan con proyectos más innovadores, donde se utilizan nuevas tecnologías, o donde los requerimientos van cambiando conforme se va aprendiendo sobre el negocio, la estrategia de control prescrito tiende a fracasar. Es entonces que las organizaciones entienden la necesidad de administrar estos proyectos de una forma más flexible y adaptable, llegando a lo que llamo “control adaptable”.
Estas son las etapas que típicamente veo en grandes organizaciones de TI. En el caso de organizaciones más pequeñas, sobre todo organizaciones cuyo negocio es el software, he notado una tendencia de pasar directamente del caos al control adaptable. Para ellos, no tiene mucho sentido pasar por el control prescrito, ya que no se adecua a sus necesidades. De hecho, el tipo de organizaciones donde más se está usando Ágil, son empresas cuyo negocio principal es el software. En cambio, las áreas de sistemas en empresas de otro giro, van a un ritmo de adopción más lento.
Debo decirles que en el último año y medio he notado un cambio muy importante en la postura de las organizaciones hacia Ágil. Anteriormente, lo que sucedía es que dentro de una organización de TI encontrarías a un grupo rebelde, que probablemente estaba trabajando en algún proyecto novedoso, y decía “nosotros queremos usar Ágil”. Así que acercaban a gente como yo, y los asesorábamos para adoptar Ágil en su equipo. En cambio, lo que me ha estado sucediendo más y más en los últimos 18 meses, es que son los CIOs y CTOs los que están interesados en adoptar Ágil, y quieren hacerlo en toda su organización. Actualmente estoy colaborando con una empresa en Boston donde estamos implantando Ágil para 500 ingenieros, en un periodo de tiempo bastante corto. Ese tipo de adopciones no sucedían hace un par de años.
Las Fases de un Proyecto Ágil
Visualizar. Se genera una visión colectiva sobre el producto de software a desarrollar.
Especular. Se establecen hipótesis sobre las especificaciones del producto, sabiendo que conforme el proyecto avance, estas especificaciones irán evolucionando.
Explorar. Se implementan las especificaciones de forma iterativa.
Adaptar. Se analizan los resultados de dichos experimentos y se realizan los ajustes necesarios para las siguientes iteraciones. Se evalúan cuatro aspectos: funcionalidad del producto, calidad técnica del producto, estatus del proyecto, y desempeño del equipo.
Cerrar. El cierre de cada iteración sirve para dar un pequeño break y tomar fuerza para la siguiente.
Como pueden ver, estas fases asemejan más un proceso de investigación científica, que un proceso de gestión de la producción (la forma tradicional de administrar proyectos).
Equipos Distribuidos
Existe la noción esuivocada de que Ágil no se puede aplicar con equipos distribuidos geográficamente. Los equipos distribuidos son más complicados, pero esto aplica tanto para Ágil como para tradicional. Todas las organizaciones donde yo estoy implantando Ágil actualmente tienen equipos distribuidos.Así que sí es posible, sólo hay que apoyarse en herramientas adicionales (wikis, instant messengers, videoconferencia, etc). Lo que hay que evitar es tratar de sustituir la colaboración y comunicación con documentación. Así que en lugar de buscar documentar todo e intercambiar documentos de un lado a otro, es preferible intercambiar miembros de equipos durante un periodo de tiempo.
Nuevas Habilidades
Ágil requiere que los desarrolladores sean mejores testers. Ahora decimos que el ciclo para un desarrollador es rojo, verde, reorganizar. Esto se refiere a escribir una prueba unitaria (rojo), escribir el código que la hace funcionar (verde) y reorganizar (refactor) el código para optimizarlo.
- Log in to post comments