Es obligado hacer una retrospectiva para conocer lo que es una metodología y para qué sirve. No sólo se aplican al mundo del software, sino también a la industria en general y a todo lo que conlleve un proyecto o servicio. Comenzaron a gestarse sobre los años 50, en el ejército estadounidense, como una forma de reducir las consecuencias caóticas de proyectos que se descontrolaban, generando demoras en las agendas, el descontrol de los costes, las sorpresas de riesgos no previstos, la entrega de productos no terminados o de baja calidad y eficiencia. Para ello, se fueron definiendo mejores prácticas, fases bien definidas y normas de obligado cumplimiento. Con ello se pretendía (se pretende), que todo siga un orden establecido, en donde se involucran a ciertos responsables, se recoge una entrada de tareas y documentos, se definen unas tareas clave, y se obtienen unos resultados determinados, imponiendo qué y cómo ha de hacerse.
Han ido apareciendo metodologías a lo largo de las décadas para ir haciendo frente a una cada vez mayor y exigente industria. Así tenemos las ISO, PMI, CMMI, Prince2, Métrica o ITIL.
A lo largo de mis 25 años de experiencia en TI, he aplicado en mis proyectos todas ellas (y alguna propia del cliente), a excepción de ITIL. El resultado ha sido más o menos bueno, ya que si una metodología puede ser buena, puede no serlo el enfoque de qué metodología aplicar y el alcance de la misma. Hablo concretamente de la omisión del "tailoring" (traje a medida). Esto significa que se aplica toda la metodología indistintamente a proyectos pequeños y a proyectos grandes. Así, si un proyecto, en condiciones normales, hubiese durado un mes, al final termina durando dos o tres meses, con un sobreesfuerzo desorbitado en cuanto a documentación y a rectificaciones constantes de los entregables.
Asimismo, aún haciendo "tailoring", las normas y tareas pueden resultar excesivas para lo que realmente se necesita. En este sentido, se está haciendo más trabajo y esfuerzos en documentación, reuniones, actas, etc., que lo que es realmente el trabajo a realizar. Esto llega a desesperar, especialmente a los gestores de proyecto.
Otro problema importante es que en las planificaciones no suele incluirse el tiempo o los esfuerzos de aplicación de las metodologías, tan sólo el trabajo que se requiere para desarrollar el producto. Ello se debe a que muchas veces los clientes se niegan a ver ese trabajo en el project, o que no se prevé o que para ajustar los costes para ganar la oferta se omite este trabajo que puede llegar a ser el mismo o superior al del trabajo de desarrollo.
Otro añadido es que se asume que el jefe de proyecto es también el gestor del proyecto y el que aplica la metodología. Esta es una sobrecarga de trabajo que no se suele tener en cuenta. No es extraño ver un project en el que el jefe de proyecto tiene una dedicación de un 50%, pero en realidad tiene que llevarse trabajo a casa porque se le complica con las otras tareas y no llega a los hitos impuestos.
Lo anterior son sólo algunos inconvenientes de una metodología intransigente, estricta y vetusta, y que sin embargo es impuesta por las empresas para "asegurar la calidad", cuando en realidad es por imagen, creando una "burrocracia" innecesaria, molesta y lapidaria. Las cifras a lo largo de la historia del software están ahí, y aún mejorando las expectativas, hoy en día, tan sólo un tercio de los proyectos acaban en tiempo, y la calidad final siempre es la esperada o la prometida. El resto son proyectos que no acaban, o son ruinosos, o los costes se superan, o se extienden en el tiempo, o el producto es defectuoso, o la calidad no se cumple... ¿Qué ocurre entonces? Las metodologías, aún aplicándose no garantizan completamente el propósito para el cual fueron creadas. ¿Cómo es posible ésto? Si las mejores prácticas definidas en la metodología son recogidas de proyectos que tuvieron éxito. Si la idea de las prácticas son buenas, y está demostrado que funcionan.
Hay explicaciones que pueden ser más o menos discutibles. Una práctica, de forma aislada, puede funcionar en un proyecto, pero en otro proyecto puede no funcionar o funcionar a medias. También influye lo que apunté antes, y es que en la planificación no se incluyen las tareas de la metodología, y si las tareas del desarrollo ya están infradimensionadas para una oferta ganadora, estamos hipotecando el tiempo y el esfuerzo real a costa de tiempo y esfuerzo extra que no es pagado ni agradecido. Las prisas y la sobrecarga no son buenas, y muchas prácticas se omiten o se realizan parcialmente o mal para poder llegar a los hitos.
Voy a comentaros una anécdota que me pasó hace unos años en un importante banco que impone su propia metodología, y tienen a todo un departamento velando por esta metodología. Estaba con un diseño conceptual de nuestro aplicativo. Este diseño fue rechazado cinco veces en una semana, una vez cada día, porque no cumplía los requisitos de calidad de la metodología, la cual había sido cambiada sin avisar ese mismo día o la tarde anterior, mientras adaptaba el diseño a los nuevos requerimientos. Obviamente, eso retrasó mi proyecto una semana más, con el consiguiente cabreo mío, de mi equipo y del responsable del proyecto en el cliente. Se convocó una reunión a un alto nivel, con la protesta de estos hechos. Increíblemente, la cabeza de la organización dictaminó que el departamento de metodología tiene prioridad sobre las decisiones, y que la calidad era la filosofía suprema de la entidad, y que había que bailar a su son, nos gustase o no. Por tanto, nuestro aplicativo o cualquier aplicativo debía ceñirse a los últimos requisitos de la metodología. Entonces dije algo por lo cual me crucificaron: "bien, entonces, ¿cuántos aplicativos que se realizaron el año pasado, o hace dos años, o a lo largo de los últimos cuarenta años en la entidad, cumplen con esos requisitos? Por esa regla de tres, hay que adaptar todos los aplicativos del banco para que cumplan con la metodología liberada esta misma mañana, porque no la cumplen". No hay nada peor que tener a un rebelde que tiene razón.
Si bien el concepto y la idea de estas metodologías son buenos, lo son en proyectos y productos estables en el tiempo, tales como una construcción, como un edificio, un puente, un túnel, etc.
Para la industria de TI, supone un lastre muy importante, ya que el software y el hardware son muy dinámicos e innovadores, cada día aparecen nuevas tecnologías y proyectos, y los productos tienen un período de vida muy corto. Hoy en día no hay muchos proyectos que duren más de un año. Suelen ser proyectos de muy corta duración, de apenas unos meses. Y no es sólo por la tecnología, sino también por la dinámica del negocio, que requiere nuevas ideas y prácticas para llevarse a cabo. En proyectos tan cortos, demorarse un sólo día impacta de forma importante en los costes y en el margen de beneficio. Asimismo, la sobrecarga de una metodología tradicional puede exasperar hasta lo indecible, pues cuanto más corto es el proyecto, más porcentaje de dedicación requiere la metodología. Para que no haya malentendidos con este último argumento, imaginaros un proyecto de apenas un mes. Aplicar una metodología a rajatabla, puede llegar a superar el 50% de esta dedicación.
Entonces uno se plantea si no hay algo más flexible y ágil para aplicar a los proyectos actuales. Indagando uno encuentra las metodologías Agile, entre las que se encuentra Scrum. Cuando alguien acostumbrado a metodologías tradicionales toma contacto con Scrum puede sorprenderse e incluso ser reacio a las ideas y prácticas que profesan, pues suponen un cambio importante. Con una mente abierta, uno descubre que realmente son ágiles y flexibles, y que van directamente "al tajo", en lugar de entretenerse en cosas que no aportan mucho o nada. A mí, por lo menos, me parecen de sentido común, y si me diesen la oportunidad, recomendaría este tipo de metodologías.
Voy a dar un repaso somero a algunas de sus características sin entrar en detalles. Ante todo, en estas metodologías prima la sencillez y el sentido común. Por ejemplo, en el caso de Scrum, se realizan sprints o períodos de trabajo y entregables cortos, de apenas 3 semanas. Al principio de un sprint se reúne todo el equipo con el dueño del producto y el cliente, donde se revisan las historias (actividades funcionales), se establecen las prioridades de las mismas y los puntos (días de esfuerzo) de las mismas. Los puntos son estimados exclusivamente por los componentes del equipo. Se estiman cuántos puntos se pueden realizar durante ese sprint, y se deciden qué historias formarán parte en ese sprint. Cada sprint tiene al final una demo con las historias comprometidas.
Cada día, el equipo tiene una reunión muy breve (media hora, quince minutos), y sobre una pared se van actualizando el estado de las historias: cuáles están pendiente de acometer, cuáles están en curso y cuáles están terminadas. Asimismo, se va ajustando la estimación de las tareas de la historia, y en un gráfico de tipo breakdown, se va observando las desviaciones. Todo es muy participativo y colaborativo. En el equipo, no hay distinción jerárquica típica. Todos hacen algo y participan en los problemas y decisiones.
Quizá más de uno piense que si sólo se desarrolla, no hay documentación, o que la calidad puede ser pésima. Ese fue mi primer pensamiento, pero no es así. Se desarrolla la documentación suficiente, pero no una documentación excesiva como ocurre en otras metodologías. En cuanto a la calidad, aquí entra lo que se conoce como TDD, un framework que permite definir antes de tirar una sola línea de código, los ejemplos que han de cumplir las historias. Esto es, que en lugar de un análisis funcional extenso, redundante, excesivo y lleno de interpretaciones dispares, se define qué cosas debe hacer el aplicativo y en posibles escenarios. Esta información se centra en el qué y no el cómo. No se va al detalle de la interfaz de usuario ni en el modelo de datos. Se escribe un lenguaje de frases de pocas palabras, que va directo al grano ("se añade el producto seleccionado al carrito", "búsqueda combinatoria con el tipo de producto y el precio máximo", "al superar el saldo da mensaje 'no tiene saldo suficiente'). Estos ejemplos definen las funcionalidades que se necesitan así como los factores a cumplir que sirven como base para un plan de pruebas. No hay un lenguaje o una jerga. El desarrollador entiende estas especificaciones, y el usuario también. Ahora el desarrollador crea el código para que estos ejemplos se cumplan, y se definen los recursos de pruebas automatizados para llevarlo a cabo. Una vez el código se realiza y cumple con los ejemplos (y pruebas), se realiza una refactorización del código, eliminando ambigüedades y partes repetidas, optimizando el código para que cumpla nuevamente con dichos ejemplos. Posteriormente, si hay tiempo se realiza una retrospectiva para afinar aún más.
Así pues, al final del script tenemos un producto sólido, estable y de calidad (también se aplican pruebas de caja negra, de estrés, etc.), con lo que se pueden acometer nuevas historias con la seguridad de que lo entregado cumple en su mayor parte con los requisitos de calidad. Obviamente, no todo el código es perfecto 100%, y que el usuario pueda encontrar errores a posteriori. Estos errores son mínimos (situaciones no previstas en los ejemplos) o mejoras, y el desarrollo continúa mientras las historias entregadas pueden ser ya utilizadas por los usuarios, en lugar de esperar varios meses para una entrega final.
¿Qué ocurre con los diseños? Bueno, los diagramas de clases, por ejemplo, se crean al final, con el código ya funcionando y libre de errores, realizando una ingeniería inversa. Por experiencia, coincido con todos los gestores de Scrum, en que el diseño preliminar ralentiza el desarrollo, y que un diagrama de clases va a estar contínuamente cambiando a medida que se desarrolla, ralentizando aún más nuestras tareas y con el riesgo de terminar con una documentación desactualizada o imprecisa. Veo bien hacerlo a la hora de refactorizar, pues se ve claramente dónde se puede mejorar y optimizar el código, y además el desarrollo es reciente, con lo que las peculiaridades y detalles son frescos.
Existen muchos detalles interesantes acerca de este tipo de metodologías. He expuesto quizá las que me han parecido más interesantes y prácticas. Desde luego, puede chocar con nuestra tradicional forma de pensar, pero si abrimos nuestra mente veremos las posibilidades y los beneficios de estas prácticas. Sobre todo, se busca agilidad y flexibilidad.
Siendo crítico, se pueden encontrar algunas pegas. La primera de ellas es que normalmente los clientes son los que exigen la metodología a aplicar, e intentar convencerles de que cambien a Scrum puede llevarnos a distanciarnos y a perder proyectos en el futuro. Hay que adaptarse a sus metodologías, nos guste o no.
Otro problema que veo es que aún no exigiendo la metodología a aplicar, si proponemos Scrum hay que argumentar todos los beneficios en las ofertas. Si otros licitadores proponen una metodología tradicional y reconocida, es más que probable que opten por ésta por la "tranquilidad" y la "garantía" que da una metodología ya consagrada y extendida.
El cambio de mentalidad o de ideas choca, y ese es un obstáculo. Veo más viable implantar una metodología Scrum en un cliente que no sea exigente en este sentido, o que el cliente conozca esta metodología y la desee aplicar.
Otro punto muy importante y a considerar, es que para llevar a cabo los sprints, previamente hay que tener muy bien definidas las historias, y que éstas estén muy claras para el dueño del producto y el cliente, para no llevarnos la sorpresa de cambios de cosas que no se han tenido en cuenta. Esto no suele ser así ni en la metodología tradicional, donde incluso teniendo el documento de requisitos, el documento funcional y el documento técnico y una demo de interfaz de usuario, encontraremos cambios de especificaciones, errores y mejoras durante el desarrollo o durante la fase de pruebas.
Aunque expertos en Scrum coincidan en que el desarrollo sin preocuparse por la arquitectura, yo creo que no hay que ir del extremo de tener una arquitectura robusta y fuerte antes de plantear el proyecto, al extremo de ir desarrollando sin arquitectura definida, y montar ésta a medida que va surgiendo. Hay que tener por lo menos una arquitectura mínima prediseñada y definida, y sobre ella ir construyendo el resto. No es bueno ir haciendo las cosas sobre la marcha, ya que no se prevén riesgos, algo crítico y fundamental en todo proyecto. Las metodologías tradicionales en este punto son muy buenas, aunque por exceso demoren el inicio real del desarrollo. En Scrum hay una previsión mínima, y lo acertado de esta previsión y no llevarse sorpresas dependerá de la experiencia y de los conocimientos de la arquitectura y de las tecnologías que tenga el equipo. En este punto sobresale Scrum, pues la participación del equipo puede discernir riesgos que un jefe o un gestor de proyectos pueda no abarcar. Pero, repito, el equipo Scrum debe tener mucha experiencia en esa arquitectura y en esa tecnología, y yo lo desaconsejaría en caso de tener un equipo nuevo, no hay capacitación suficiente, o el escenario de arquitectura y tecnología son nuevos.
Algo que podría rechazar un cliente es que la documentación no sea tan elaborada y tan extensa como la de una metodología tradicional. Si terminado el proyecto surge algún problema o un cambio fuera de garantía y ya no hay relaciones con nosotros, y hay que tirar de otra empresa, ¿va a ser suficiente la documentación "básica" que hemos generado como para que el legado no sea problemático? Esa duda es un punto crucial a la hora de que un cliente pueda optar por Scrum, ya que PMI o Métrica (por poner algún ejemplo de metodología) genera una documentación abundante. En este punto hay que ser cuidadoso, pues si bien una documentación excesiva es hasta contraproducente (por la interpretación y el tiempo que requiere su estudio y capacitación), una documentación menos extensa debe ser más concisa y libre de interpretaciones. Esta documentación, aún siendo buena, podría chocar si en el futuro el legado lo recoge un equipo que no haya trabajado con Scrum y siga trabajando a la antigua usanza. Bajo mi punto de vista, al igual que se incorpora un rol especial para las pruebas en un equipo Scrum, el rol de documentador estaría bien para dar más consistencia en este sentido. Una idea interesante, para no aburrir, es alternar en cada sprint este rol a un miembro del equipo.
En los últimos tiempos hay una modalidad de trabajo en la que Scrum podría apoyar de forma significativamente, incluso mejor que las metodologías tradicionales. En algunas organizaciones se prevé un presupuesto anual, donde el responsable de cada departamento lo invierte en el desarrollo de actividades que libera una oficina de proyectos. Este presupuesto se puede invertir en bolsas de horas. El trabajo está dirigido principalmente a las tareas a abordar por un equipo a lo largo del tiempo, de forma constante. El trabajo se extraería de una pila de actividades (puede ser de varios proyectos), definiendo historias, y con arreglo al ritmo de puntos a acometer por presupuesto y tiempos, poder ejercer Scrum. En este sentido, Scrum sería el mejor candidato.
Las metodologías nos ayudan a ejecutar un proyecto o un servicio con mayores garantías de éxito. Son una herramienta, y conocer dicha herramienta y usar debidamente dicha herramienta es responsabilidad nuestra. Usar una metodología sin tener en cuenta las necesidades reales del producto a elaborar, nos llevará a deformar las expectativas de la planificación, bien demorando los tiempos, incrementando los costes y generando un producto con errores o de baja calidad.
Una metodología puede no ser mejor ni peor que otra. Es nuestra visión de cómo plantear y desarrollar el proyecto la clave para optar por una u otra metodología. Si el proyecto es corto o se requieren entregables constantemente, Scrum, desde luego, es una opción muy buena. En un proyecto muy extenso también recomendaría Scrum, ya que ahorraría en tiempos de ejecución y en costes, pero podría caer en el riesgo de crear un producto insuficiente al estar realizado casi sobre la marcha. Para ello, una metodología tradicional define bien desde el principio el producto y los controles necesarios para asegurar de forma constante que el producto se realiza acorde a ese diseño.
Lecturas recomendadas
Scrum y XP desde las trincheras. Por Henrik Kniberg
Flexibilidad con Scrum. Por Juan Palacio
Diseño ágil con TDD. Por Carlos Blé Jurado
