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?

    3 comentarios to “Agile. La evolución de las metodologías tradicionales?”

    RSS Feed for CBASQA – Desarrollo de Software, SQA, Testing, Servicios Informáticos, Project Management Comments RSS Feed

    Yo por el momento seguiré hablando de las ágiles, creo que son una mejor opción. Es posible que ahora exista mucha mucha basurilla sobre las mismas, pero eso pasa con todo, hay que saber distinguir la buena información de la basura.
    No creo que las ágiles se hayan alimentado demasiado de las metodologías más tradicionales, en todo caso, como revulsivo la situación que han provocado, especialmente a nivel de equipos.
    Eso sí, cuando realmente llegue la revolución, nos pillará buscándola!🙂

    José, en primer lugar gracias por participar y darnos tu opinión.
    Quiero responder a tu comentario, principalmente al asunto que relacionado con esto del equipo balanceado y la participación de perfiles Junior.
    En primer lugar hay que aclarar que pronto, muy pronto, en un equipo Agile, no serán JUNIOR. Por esto insisito en que la búsqueda de personas para la conformación de nuestros equipos, debe basarse en las actitudes, más que en las habilidades técnicas.
    Así mismo insisito en que los entornos de trabajo deben estar adaptados y ser adecuados para las rápidas y eficientes transferencias de conocimientos, de manera que perfiles sin dominio o no tan expertos, puedan adaptarse y tener una curva de participación pronunciada en cada proyecto.
    A esto me refiero con preguntas como :
    * Tiene tu equipo el potencial para Agile?
    * Tienes el potencial para Agile?
    * Tienes la materia prima en las personas, para formar un equipo Agile?

    En segunda instancia me alineo a tu concepto cuando indicas que ninguna práctica de ingeniería del software en particular está excenta en los equipos Ágile. Estas prácticas no son exclusividad de ninguna metodología en particular y pueden adaptarse si la inteligencia organizacional lo permite.

    Por último, creo que pronto dejaré de hablar de metodologías Agiles, principalmente por que estoy cansado de la cantidad de ideas inútiles y conceptos vagos que se desperdigan por toda la red, solo para detrimentar otras metodologías que “le han dado de comer” a las llamadas metodologías livianas.
    Prefiero comenzar a hablar de metodologías híbiridas y sostener este concepto, considerando que también estoy a la espera de la revolución (http://najaraba.blogspot.com/2009/02/tres-preguntas.html)

    Muy interesante tu reflexión.
    Algún comentario: que las metodologías ágiles no hagan explícito el tema de “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” no significa que las tareas implicitas en los mismos no se hagan.
    Por ejemplo, gestión del riesgo, yo diría que Scrum [por hablar de alguna en concreto] diariamente revisa los riesgos del proyecto, además de cada retrospectiva. Y las iteraciones minimizan otro tipo de riesgo, por ejemplo, el de hacer trabajo no válido durante demasiado tiempo…

    También creo que con un equipo balanceado puedes tener perfiles más junior sin problemas. Bueno, eso lo estamos experimentando ahora, ya veremos🙂

    No creo que las metodologías ágiles se hayan inventado ahora como tales, pero sí se han identificado y procedimentado hace poco como tales. Antes la gente hacía los proyectos de una manera, a unos les dio por procedimentar todo usando la gestión típica de proyectos de otras ingenierías, y otros no han dicho nada hasta que han surgido las metodologías ágiles.
    Lo que surgirá dentro de un tiempo es una síntesis de las dos quizás, o algo totalmente nuevo cuando aprendamos realmente las complejidades del desarrollo de soft., y seamos capaces de abstraernos lo suficiente,.


    Los comentarios están cerrados.

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

    A %d blogueros les gusta esto: