Agile. La evolución de las metodologías tradicionales?

Posted on 9 febrero 2009. Filed under: Empresa, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo, Uncategorized, Waterfall | Etiquetas: , , , , , , , , , , |

“Agile se ha vuelto tan popular entre los profesionales del software, que muchos se abstienen de criticarlo por miedo a ser etiquetados como “retrazados”, “de la vieja escuela”, o incluso “estúpido”.
Afortunadamente los profesionales IT con experiencia saben mejor y reconocen las limitaciones de Agile”

Así rezan las las declaraciones en un blog de Project Management, bastante conocido TheProjectManagmenteHut

Agile fue creado en gran parte en reacción al modelo predominante, WATERFALL, y en menor medida al resto de las tradicionales metodologías y aunque está en boca de todos y en manos de muchos, Agile hasta el día de hoy no ha demostrado ser superior a estas metodologías que le dieron razón y motivo para su existencia.
De hecho existe amplia y variada información que puede avalar tanto el éxito como el fracaso de las metodologías tradicionales, más su acoplamiento con los modelos y estándares de calidad reconocidos mundialmente y las culturas organizacionales más importantes del mundo, inclusive hablando de la industria del software.

Aunque no prentendo ser defensor de lo indefendible, ni “abogado del diablo” de Agile, es conveniente hacernos las siguientes preguntas:

  • cuando Agile es comparable con metodologías tradicionales?
  • cómo podemos combinar Agile con procesos tradicionales para abordar mejor una situación concreta?

Para responder a estas preguntas, es mejor reconocer las limitaciones de Agile

Un equipo de estrellas

Agile ha sido diseñado por experimentados y para experimentados.
Este es un aspecto a considerarse si se ha de intentar una incursión en las metodologías Agile, no como regla general, sino como un ítem de peso, sobre todo si se debe sostener el concepto de “equipo autogestionado”.

En lo personal y por la experiencia de participación en equipos Waterfall y en equipos en búsqueda de la agilidad, puedo decir que es mucho más dificil adaptarse a procesos Agile que a los procesos Waterfall, inclusive si se sigue un modelo de calidad como CMMI.

En los procesos Waterfall, el atributo de “equipos autogestionado” no es remarcable y aunque puede existir mucho trabajo individual, se hace bajo las premisas estrictas de la planificación, siguiendo los métodos y técnicas sugeridas y aceptadas por la organización. No se hace de otro modo o no lo estarías haciendo correctamente.

En estos procesos tradicionales, es cierto que existe también una gran carga administrativa pero en realidad no todos están afectados por ella y solo lleva una porción pequeña de tiempo y a muy baja complejidad realizarlas, principalmente para quienes no lideran los proyectos y solo rinden su progreso del día.

En los equipos Ágile, es un tanto más complicado la adaptación de las personas, siempre hablando de aquellas que no tienen la experiencia suficiente y el tren de trabajo disciplinado sin controles estrictos.
Aquí las entradas de algunos son fuertemente dependiente de las salidas de otros, no existe un trabajo individual o “individualista”, o no debería existir.

Las técnicas de gestión de tareas tradicionales pueden perder por completo su sentido y también debe existir una readaptación del mecanismo de estimación, de equilibrio de carga y del seguimiento. Los controles aunque parecieran ser menores, en realidad se incrementan por que el ciclo de vida en si mismo es mucho más corto y los cambios se presentan con mayor velocidad, pero parecieran ser de otra naturaleza y los resultados deben ser inmediatos, como también deben ser inmediatas las correcciones y a gran velocidad para que en la misma jornada laboral se tenga una aproximación del resultado, cuando no el resultado en si mismo.

El cáos está siempre al acecho…pero en que proyecto no lo está? La diferencia es la velocidad de detección de los inconvenientes, el análisis del problema y las soluciones, más su implementación, verificación y/o validación.
Entonces, preguntas simples pueden ser:

  • Tiene tu equipo el potencial para Agile?
  • Tienes el potencial para Agile?
  • Tienes la materia prima en las personas, para formar un equipo Agile?

Si la respuesta es “no” a algunas de estas preguntas, no significa que no puede transformase en Agile, solo quiere decir que puede haber algunos pasos intermedios a tomar antes de llegar allí.

Estos pasos suelen incluir la adaptación de la cultura del trabajo por equipos y la progresiva potenciación de los individuos, la formación y la contratación de las personas adecuadas.

Encaje con la cultura organizacional (los procesos son secundarios a la gente)

Habilitar el comportamiento Agile requiere de una gran dosis de libertad individual (no individualismo) y de equipo, que se traduce en una cruz funcional en constante adaptación del trabajo y funciones de conmutación, según sea necesario.

Se trata también de ajustar continuamente los procesos a fin de reflejar la situación actual. Más que nada, significa que los procesos son secundarios a la gente.

Otras organizaciones hacen incapié con estrechéz en los roles y responsabilidades, políticas y procesos, y han sido la clave de la supervivencia las mismas.

Aunque estas empresas estén bastante alejada de las dogmas de la agilidad, no es imposible que algunas unidades puedan realizar un trabajo diferenciado para experimentar, conocer y adaptar el nuevo paradigma.

Dado que la innovación es parte de la cultura de cualquier organización exitosa, entonces las personas que la integran tienen buenas habilidades y potencial para realizar “adaptaciones situacionales” y saltar de un modelo a otro.

Agile está restringido a equipos pequeños

  • Los equipos deben ser autogestionados, lo cual implica un orden eficiente emergente de un caos temporal. Este tipo de adopción del orden será mucho más prolongado en equipos grandes y perdería efectividad.
  • Los miembros del equipo de trabajo deben estar habilitados para comunicarse entre ellos espontáneamente, e inclusive con clientes y otros interesados en los proyectos.
  • La gestión diaria del equipo depende por completo de todo el equipo y no está centralizada en una sola persona. Es necesario el reconocimiento y visualización por parte de todo los miembros del equipo, de los cronogramas, tareas, cambios, impedimentos, etc.
  • Los miembros del equipo deben conocer exactamente que es lo que otros miembros están realizando, ayudar a otros que el proceso de su trabajo sea fácil, en forma colaborativa y sin un control centralizado.
  • Los miembros del equipo deben trabajar en la misma locación, facilitando el trabajo cara-a-cara y fortaleciendo los canales de comunicación inmediatos, sin tener las limitaciones típicas de las distancias, diferentes horarios e inclusive herramientas de gestión.

    Lo que se quiere expresar con estos puntos, es que equipos que superan un cierto límite en el número de integrantes (típicamente ocho) pierden eficiencia en las habilidades comunicacionales requeridas para equipos Agile. Así mismo la tarea de un Scrum Marster, se vería dificultada si tuviera que gestionar tareas, avances e inconvenientes de más cantidad de miembros y otros atributos como conocer las tareas y actividades entre todos los miembros se verían cada vez más en merma.

    Una forma de adaptación de equipos mucho más grandes, sería la división del mismo en equipos cross-funcionales más chicos y dinámicos.

    En este sentido necesariamente se deberá contar con un “nivel de gestión superior” que permita centralizar la información de todo el proyecto. Sin duda esto está lejos de ser puramente Agile, sino más bien una combinación de metodologías tradiciones y agilísmo.

    Hay que tener en cuenta también que si se divide un proyecto grande, se minimiza la dependencia arquitectónica del proyecto, para pasar de una medición del avance típicamente medido por su avances arquitectónicos, a una medición basada en la entrega de características funcionales. Esto da como resultado que la definición de “progreso” de Agile, deba ser adaptada a un nuevo contexto con un nivel de gestión superior.
    De nuevo la adaptación situacional “es un buen jugador”.

    Una gran limitación tiene que ver justamente con el especto comunicacional, dado que Agile promueve la comunicación cara-a-cara, con resoluciones dinámicas y proactivas, sin documentación más que la que oriente al desarrollo.

    El trámite comunicacional con otrás áreas es un trastorno que Agile debe aprender a dominar, puesto a que los modelos agilístas actuales exigen que otros interesados del proyecto deban siempre estar en la misma locación de trabajo, inclusive evitandose el traslado desde una oficina a otra para realizar simples consultas.

    La tecnología colaborativa y de multimedios, permiten actualmente realizar trabajos perfectamente coordinados y con esquemas de reuniones cara-a-cara, aunque virtualizadas, muy eficientes. Sin embargo esto no está bien aceptado en el mundo actual del agilísmo.

    Donde está mi metodología?

    Metodologías de desarrollo de software, tradicionalmente incluyen procesos como, Análisis, Arquitectura, Implementación, Gestión de Proyecto, Gestión de la Configuración, Gestión de Riesgos, Gestión de Cambios y una larga lista de procesos dependientes de Áreas de Procesos y Grupos de Procesos. Sin embargo, las metodologías

    Agile no promueven estos grupos de procesos y de hecho no los definen para sus marcos de trabajo, como tampoco definen un marco de gestión de proyectos.

    Esto puede verse justificado por el hecho de que las metodologías Agile tienen como insignia, que lo que demuestra y garantiza el proceso es el producto entregado y no la documentación que puedas presentarle a tu cliente.

    Las metodologías Agile delinean un marco conceptual, pero no explicitan de ninguna manera la exclusión de alguna de las prácticas tradicionales, aunque se asume que solo sobrevivirá lo estrictamente necesario para la obtención de los incrementos (entregables de software)

    Metodologías Agile completas parecen estar emergiendo y el soporte a la organización podrías ser total con adaptaciones sencillas de ambos metodologías, donde la substracción de las buenas prácticas de ambas, de como resultado el éxito y calidad total de la organización.

    Dado el contexto planteado es que me hago las siguientes preguntas para reflexionar:

    • ¿Existe la evolución de las metodologías Agiles?
    • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?
    • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?
    Anuncios
    Leer entrada completa | Make a Comment ( 3 so far )

    Gestión de Proyectos

    Posted on 5 septiembre 2008. Filed under: Metodologías de Desarrollo, Procesos Ágile, Waterfall | Etiquetas: , , , , , |

    Prácticas del PMBOK relacionadas a prácticas ÁgilesRecientemente lancé el debate en LINKEDIN en el grupo IAAP sobre cuan aplicable son las prácticas de PMI a las metodologías Ágiles. El volúmen de respuesta no fue alto pero los que quisieron aportar lo hicieron bien, y de allí rescato una lectura interesante:
    Relating PMBOK Practices to Agile Practices

    Básicamente en este artículo la autora explica como se ha relacionado de manera indebida a los procesos Waterfall con las prácticas PMI, al igual que se lo ha relacionado al CMMI de manera injustificada, cuando en realidad PMBOK es solo una guía de “mejores prácticas” y debe ser utilizado con criterio organizacional cuando se implementen sus prácticas.
    Por otro lado reprende a los practicantes de metodologías agilístas al tildarlos de “promotores del Cowboy Coding” lo cual conlleva a una situación de caos indeseada para cualquier proyecto.
    Según las observaciones de la autora, si las metodologías Ágiles son seguidas con diciplina y rigor, cumplen con el modelo CMMI y las prácticas PMBOK, tal cual como lo haría una metodología Waterfall. Indica también que más allá de lo visible, la única diferencia entre proyectos bajo controles de planificación PMI y controles de equipos autogestionados, es el momento y la manera en que se ejecutan las prácticas, las cuales son símiles difiriendo más que nada en el léxico pero no en su escencia.

    Al respecto del core de cualquier proceso a ser administrado, en el gráfico de arriba puede visualizarse el mapeo entre las convenciones PMBOK y APM o Agile Project Management Framework.
    La autora explica que existen “Seis Claves de Gestión” definidas en el PMBOK y que merecen especial atención y las cuales tienen sus relaciones en las metodologías Ágiles, aunque se diferencian en su implementación:

    • Gestión de la Integración del Proyecto
    • Ámbito de Aplicación del Proyecto de Gestión de Proyecto
    • Gestión del Tiempo
    • Gestión de la Calidad
    • Gestión de Riesgos
    • Gestión de Recursos Humanos

    Los invito a ver el artículo y sus ampliaciones y a opinar en mi blog.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Gestión de Proyectos )

    Ágile resulta más económico?

    Posted on 18 agosto 2008. Filed under: Metodologías de Desarrollo, Procesos Ágile, Uncategorized | Etiquetas: , , , , , |

    En términos de rendimientos económicos puede demostrarse con relativa facilidad la diferencia entre modelos de gestión Ágiles y Waterfall.
    Basados en la idea de que todo proyecto tiene objetivos concretos que alcanzar en tiempos y costos limitados, es fácil observar que mientras los modelos Waterfall administran sus entregables a lo largo de una escala de tiempo significativamente grande, los modelos Ágile planifican entregas a una escala mucho más corta. Siendo así es entendible que el valor apreciativo de cada entrega pactada se devalúe con el paso del tiempo, por el solo hecho de los cambios naturales en los requerimientos de los negocios que dan vida a los proyectos. Entonces son estos mismos cambios la razón principal para que una solución ofrecida para una versión de software “X.Y.Z” en poco tiempo deje de ser una solución efectiva para el negocio.
    El “
    valor esperado para una solución de negocio” es cada vez menor por cada una de las nuevas versiones promovidas por tales cambios, y aunque esta situación está presente en cualquier modelo de trabajo, hay que hacer una comparativa de la “devaluación” de la solución esperada entre entregables.
    Los modelos Waterfall típicamente tienen espacios
    de tiempos muy grandes entre entrega y entrega, y la depreciación del valor tiende a ser mayor que el revalúo que promueven las próximas entregas. Entonces la línea de valor esperado para una solución de negocio termina siendo sensiblemente menor con el transcurrir de la variable tiempo.
    Los modelos Ágile promueven entregas en iteraciones mucho más pequeñas, con lo cual si bien el cliente puede tener una baja apreciación inicial, a corta data puede observar el verdadero valor de tener soluciones efectivas en mucho menor tiempo, y aún cuando las misma no representan en si mismas la solución general, si representan soluciones integrales que para cada entrega representan mayor revalúo que depreciación.
    En lo particular tengo alta estima por los modelos ágiles, más que nada por el valor agregado que implican las iteraciones recurrentes con el cliente, quien no solo redirecciona los pasos del proceso de construcción de las soluciones, sino que revaloriza el modelo de trabajo al promover mejores alternativas para ser utilizadas en cortos plazos de tiempo. Esta iteración magnifíca la percepción del
    valor esperado” para muchas soluciones del mismo negocio.
    GoogleTech presenta en forma sintética esta idea donde se explica gráficamente como Ágile permite generar valor agregado con iteraciones más cortas:

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Ágile resulta más económico? )

    Liked it here?
    Why not try sites on the blogroll...