¿Es “agile” una moda, tendencia, la mejor opción … la única opción?

Hola a todos, es cierto, hace tiempo que no escribía, una mezcla entre pereza, falta de “creatividad”, acumulación de trabajo, etc., bueno quizás más de lo primero, pero espero volver a reincorporarme poco a poco.

La cosa es que leyendo hoy uno de los blogs que sigo bastante habitualmente: http://navegapolis.net/ (y que recomiendo a cualquiera interesado en Scrum), leo un post acerca de la inversion de tendencias entre CMMI y agile, en las búsquedas de google.

Y como no, me viene a la cabeza, todas las opiniones que leo y escucho (bueno algunas sólo las oigo), y me empiezo a preguntar, ¿es la “agilidad” sólo una moda?, cada vez si que es cierto que veo más interés por este tipo de metodologías, incluso en personas, que hace un tiempo, eran bastante incrédulos ante las ideas de la “agilidad”, es más, y lo que más me preocupa, ya empiezo a escuchar las voces que propugnan agile, o algunos de sus proceso y prácticas, como la única verdad.

Y me preocupa porque, o yo no entiendo el tema de “agile” (me considero un mero aprendiz pero eso da para otro post), o la gente se hace muchos líos en la cabeza, ahora resulta que el que no hace ciertas cosas está equivocado, vaya, yo que pensaba que precisamente el manifiesto ágil iba, entre otras cosas, en contra de las balas de plata, y que lo que funciona para unas personas puede no funcionar para otras (people over processes and tools).

Y es que, como siempre decimos muchos, no hay una bala de plata, llámese “agile” (partiendo de lo más genérico), scrum o CMMI.

También es cierto, que soy un poco, como decirlo hmmm, toca narices??? por no decir otra cosa, y es que cuando veo que mucha gente empieza a crear uina “moda”, tiendo a desconfiar de eso, lo se, no debería de desconfiar inmediatamente, pero soy así y lo hago.

Y es que, ¿si haces agile no puedes hacer CMMI?, si que es cierto que muchos de sus principios son contrapuestos, pero ¿dónde dice en scrum que no se puedan tratar los entregables de CMMI como parte del producto a entregar en un sprint?, o ¿dónde dice en CMMI que no se pueden hacer sprints, retrospectivas o daily scrums?.

En definitiva, que me gusta que la gente se interese por el movimiento “agile”, pero ojo con esto de las modas, ni todo es tan bonito como lo pintan los que lo venden, ni todo es tan feo como lo pintan los que se oponen, hay que probar, investigar, adaptar, hay mucho trabajo que hacer antes de poder empezar a sacar provecho de cualquier cosa.

Ojo, tampoco defiendo que cada uno haga lo que buenamente le venga en gana sin fijarse en más, hay que leer mucho, compartir opiniones, probar las cosas “según el libro”, antes de poder adaptar o afirmar si algo funciona o no, y siempre teniendo en cuenta que lo que me funciona a mí, puede no funcionarte a tí, y eso no lo hace ni mejor ni peor.

Lo dicho, a empaparse de las cosas, a aprender, a probar, y no sólo dejarse guiar por las tendencias.

6 comentarios en “¿Es “agile” una moda, tendencia, la mejor opción … la única opción?

  1. Muy buenas Luis.

    Cuando hace ya casi tres años y medio escribí lo de Explicando Scrum a mi abuela (http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx), indicaba allí algo que tu comentas en tu entrada.

    Allí indicaba: “Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas.”

    Es aquí donde me quiero parar a comentar:

    Si bien estoy en contra de las modas, cada vez que aparece una la estudio y analizo (puntos fuertes vs puntos débiles). Una vez estudiada, probada y ¿aprendida?, trato de aplicarla si se puede.

    Sin embargo, la aplicación de una “moda” no es trivial.
    El responsable del equipo debe analizar pros y contras, evaluar las posibilidades, conocer el equipo de trabajo, la cultura de empresa, los objetivos a corto, medio y largo plazo, etc., y una vez estudiado todo eso y teniendo claro que se conoce la “moda” bastante bien, decidir que hacer.

    Ni las metodologías ágiles son la solución a todos nuestros problemas en la gestión de proyectos, ni tampoco es el patito feo del que todos reniegan.

    Hay muchos condicionantes alrededor, muchos de ellos técnicos, otros psicológicos y otros sociales, que condicionan enormemente la adopción de “modas”.

    Estos aspectos son olvidados por muchísimas personas, y son casi más importante que la propia “moda”.

    Estoy de acuerdo contigo en que la única forma de saber si algo está bien o no es aprendiendo, probando y no dejándose guiar por las tendencias, o mejor dicho, teniendo los ojos bien abiertos para saber si debe aplicarse o no esa “moda” en el sitio en el que uno está trabajando.

    Que se puede aplicar la moda, seguro, pero decidir si se debe o no aplicar esa moda es lo que es realmente complicado y en el fondo es lo que debemos realmente hacer, al menos las personas que tenemos determinada
    responsabilidad en la toma de decisiones.

    P.D.: y ya no comento si trabajas con clientes que exigen trabajar de una forma concreta en un proyecto dado con una metodología determinada que no encaja con la que uno tiene y con la que un equipo está familiarizado. Ahí el gestor del proyecto debe hacer encaje de bolillos para hacer una “especie de wrapper” para encajar las piezas.

    Un saludete.

  2. Me gusta tu aportación Jorge 🙂

    La cosa es que esto, en nuestro ámbito, pasa con muchas cosas, hoy es Scrum, también está DDD que se intenta meter a veces a presión, y un montón más de cosas, que al final lo que crea es proyectos fallidos, y rechazo a ideas, que en principio son buenas, pero que se han aplicado fatalmente mal.

  3. De acuerdo con el post Luis, pero es que resulta que esa reflexión a la que apelas, estudiar alternativas, ver si algo encaja en un escenario concreto con todos sus condicionantes de equipo, cliente, carcaterísticas del proyecto, plazos, expectativas, etc. muchas veces escasea no sólo en el ámbito de las metodologías, sino prácticamente en cualquier aspecto.

    Ocurre también con las tecnologías, si hoy sale MVC hay que dejar atrás ASP.NET porque sí, sin estudiar los escenarios concretos o algo tan importante como “qué sabe mi equipo, en qué es realmente productivo a día de hoy” y “qué exigencias de plazo y presupuesto tiene este proyecto”, cosas que pueden avocar al suicidio o la entrega de algo sin la calidad necesaria por la adopción sin reflexionar de una tecnología concreta que no era el momento ni el proyecto adecuado para utilizar. Lo mismo se puede decir con un largo etcétera de tecnologías que hemos visto aparecer en los últimos tiempos, como las fiebres por LINQ to SQL o EF, estilos de arquitecturales como SOA que lleva a empresas a montar proyectos con SOA sin realmente beneficiarse de sus ventajas porque no las necesitan en su escenario, etc.

    En definitiva, largo y tendido he tenido conversaciones muchas veces sobre estos temas con diferente grupos de personas y siempre desde la misma perspectiva, intentar promover el sentido crítico y estudiar realmente si una tecnología, metodología, arquitectura, resuelve mejor los problemas de tu escenario concreto o no, y en tal caso adoptarla si se tiene la posibilidad teniendo en cuenta los condicionantes antes mencionados (y otros) o no adoptarla si no procede. Hay veces que se resuelven problemas que no se tienen, directamente.

    A veces da la sensación de que lala vorágine del mundo tecnológico hace que muchas veces la gente sólo esté pendiente de “estar a la última moda” sin reflexionar si realmente le vale de algo o no, si le mejora su solución actual o si incluso se la empeora.

  4. Muy bien Luis, esta es una entrada reflexiva y equilibrada. No sé hace cuantos años que planteo lo mismo y siempre termino tirado en la hoguera.
    Creo que hoy la industria está haciendo una síntesis de las posturas agiles vs. ingenieriles y está reflexionando y tomando posturas propias sin escuchar tanto a los vendedores y evangelistas de una y otra parte.
    Creo que voy a escribir de esto una vez más.
    Saludos.

  5. Buuff aquí hay mucho de que hablar y discutir…

    Me gusta mucho el tono de incertidumbre que pones al post.
    La pregunta es: ¿Que es ser ágil? y la siguiente es ¿No puedo ser ágil y utilizar una metodología tradicional?
    ¿Acaso no puedo hacer TDD con CMMi? ¿No puedo hacer un acta de reunión si hago Scrum? ¿No puedo utilizar la métrica de velocidad del equipo en CMMi?

    Los extremos nunca fueron buenos.
    Personalmente no soporto a los que se creen con la verdad absoluta, ni a los que hacen del termino “agile” una secta!!

    Yo creo que ser ágil es tener una serie de cualidades en el desarrollo de software y la agilidad se puede aplicar a cualquier metodología.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *