Hace ya mucho tiempo que desarrolladores, testers, project leader, capacitadores, pensadores, hasta el SEI y en general todos los actores de la industria del software, venimos enfrascándonos en discusiones casi mortales por defender alguno de los extremos de la dicotomía "ágiles vs. maduros" o "ñoño vs. trajes". Estas charlas se suceden todo el tiempo y en todo lugar, en las cafeterías de las empresas, en las oficinas, en las horas de almuerzo, en los blogs, revistas, todo el mundo habla de lo mismo.
Que es ser ágil y que es ser maduro? ¿Puedo ser como el señor de la foto? y si implemento SCRUM soy más ágil o simplemente me habilita a autodenominarme como tal? ¿Una empresa que implementa CMMI level 5, está condenada a tardar 1.000 años en proveer un producto costosísimo a un cliente agotado?
Así planteada la discusión entre dos extremos, uno blanco y el otro negros, casi nadie distingue la infinidad y continuidad de la escala de grises intermedios y se toman posiciones más rápido que en la bolsa de valores, a favor de una u otra fase, según las preferencias de la tribu a la que se pertenece, y es cierto que ningún hobbista (termino utilizado por Bill G. y que refleja como pienso sobre los apasionados del soft) puede alucinarse con CMMI, es casi como ver un adolecente ultraconservador, ni puede a un MBA simpatizarle la idea de una metodología "liviana", con poca o ninguna "evidencia" de "control". Así que existe un perfil de los "ágiles" y los "maduros" que, sin perjuicio de sus justificaciones, parece hacer de sus ideales algo irreconciliable, pero que sin embargo forman las dos caras de una misma moneda porque ambos se centran en los aspectos administrativos que rodean a la escritura de código, a mi entender, el verdadero proceso de convertir capital y trabajo en software de valor para el cliente.
La discusión entre si ser agiles o formales es una de las más estériles en las que he participado por lo siguiente:
- Sus promesas son marketineras y contradictorias: basta solo con ver los charts que muestran tanto los ágiles como los formales para darse cuenta que los dos prometen lo mismo, mayor productividad/calidad y menores costos/defectos/rework. Es claro, al menos uno está mintiendo.
- Esto es quizás producto de la ausencia de verdaderos científicos (actuales) del desarrollo de software. Faltan personas que experimenten realmente con desarrolladores, al mejor estilo tayloriano, para determinar a ciencia cierta cuales son las mejores formas de desarrollar. Si hoy existiese un Taylor del software yo no tendría dudas como: ¿como deben distribuirse los escritorios?, ¿donde deben estar los pizarrones?, ¿cuantos mails por hora puede recibir un desarrollador antes de perder totalmente la concentración?, ¿cuantas claves distinta puede manejar?, ¿como lo afectan las políticas de paga/performance?, ¿cuantas tools, tareas, meetings puede manejar simultáneamente?, etc., etc.
- La adhesión de una empresa a alguna de estas alternativas se debe más a la tendencia (quien hace más ruido), moda, afinidad cultural con alguna de las corrientes, necesidad de certificarse y cualquier otra, más que por cuestiones de fondo y esto en gran mediada se debe a la falta de credibilidad sobre las promesas realizadas por ambas, en el caso de los agiles porque no presentan números y en el caso de los formales porque los números presentados parecen estar peleados con la realidad.
Por esto es que existen 2 perfiles de empresas que se deciden por lo ingenieril y 2 perfiles que se deciden por lo ágil. En el primer caso estos son, la pyme que quiere (o a la que le exigen) certificarse para quizás exportar y la empresa de trayectoria reconocida que quiere certificarse. Muchas de las pymes han logrado darle la fama a CMMI de certificación comprable y han popularizado los cursos intensivos, de entre treinta minutos y una hora, "Lo que te van a preguntar en el Assessment". Muchas de las compañías reconocidas, en cambio, han sido las que le han dado la fama de lenta, pesada y burocrática aun cuando ellas ya eran compañías lentas, pesadas y burocráticas mucho antes de certificarse. Por el otro lado, los que se deciden por alguna metodología ágil, son pymes desordenadas que pretenden justificar su desorden aduciendo ser agiles y las empresas (o equipos) que desean realmente ordenarse.
Parece cierto que las empresas tienen un "perfil" que muchas veces las condicionan en sus elecciones respecto de la metodología a utilizar, como es claro que existen para ambos bandos, apóstoles y verdades a medias. Pero una verdad que no se lee muy seguido, ya que no se encuentra en ninguno de los dos extremos, es que ni CMMI, ni SCRUM, ni RUP, ni XP son la solución. Y es justamente por lo antes dicho, muchas de las grandes empresas que hoy implementan CMMI ya eran muy burocráticas antes de lograr la certificación y muchas empresas que implementan alguna metodología de las llamadas ágiles ya contaban con una cultura de trabajo dinámica y veloz antes de "ordenarse". Por esto es que cuando se hablamos de la pesadez y lentitud del CMMI, en gran parte estamos hablando en realidad de la lentitud y pesadez de las empresas que lo implementan y no tanto del modelo en si. De igual manera, cuando hablamos de lo ágil que es SCRUM, seguramente nos estamos refiriendo a los atributos de dinámica, practicidad y velocidad en el desarrollo de software que poseen las empresas que lo incorporan a sus prácticas operativas y no tanto de si la manera en que gestiona los requerimientos es o no una maravilla.
Resumiendo, las discusiones sobre las metodologías, no dejan ver, a mí entender, problemas ambientales, administrativos y operativos de los que depende en mayor medida el éxito de los proyectos. Según mi experiencia, lo que más condiciona la productividad del staff, como así también la calidad, el tiempo de entrega y el costo de los productos de trabajo de una consultora de software, es la "CULTURA organizacional". Es como se acostumbra a pensar y actuar en esa empresa, sus herramientas, el ambiente (hasta la iluminación, ventilación, disposición de los escritorios, edad promedio de la gente, oficinas con música o sin música, con o sin acceso a internet, messenger, carteles en las paredes o sin carteles, de camisa y corbata o de bermudas, con oficinas dispersas por muchos pisos o planas, etc.), sus políticas no escritas con respecto a los proyectos, con respecto a los clientes, con respecto a los compañeros, sus criterios de selección de personal, sus niveles jerárquicos, el nivel de rotación, la estabilidad de los equipos de proyectos, etc.
No son pocas las empresas que implementando a conciencia todas las recomendaciones de los institutos de calidad internacionales, y obteniendo sus certificados correspondientes, fallan en lograr valor real para sus clientes. También es sabido que muchísimas empresas fallan en este objetivo independientemente de haber implementado alguna metodología ágil. En otras palabras, esto no asegura nada. Solo la experiencia, la experimentación, la intransigencia en nuestra voluntad de mejora y nuestra gente pueden lograr los milagros que muchas empresas necesitan. Cada empresa debe ser o al menos poseer un laboratorio y la masa critica para crear sus propio sistema, refinar su cultura y por qué no importarla (no solo traer un CEO de una empresa que admiramos) y mejorar todo todo el tiempo.
Lucas Ontivero