El mejor software sólo puede hacerse con la mejor metodología

El mejor software sólo puede construirse con la mejor metodología de desarrollo, es por esto que en ekon llevamos años utilizando SCRUM para el desarrollo y la evolución de nuestros productos ekon.

El desarrollo de software de gestión empresarial , tradicionalmente, pasaba por las etapas: Toma de requerimientos, análisis, diseño, programación, pruebas y lanzamiento. Era una forma de trabajar poco flexible, en la que incorporar novedades, cambios de funcionalidad, o simplemente cambiar prioridades suponía tener grandes dificultades. Por otro lado, habitualmente los requerimientos eran difusos y poco atomizados, con la consecuente incertidumbre sobre si lo que estábamos desarrollando estaba en la línea con lo que el mercado demandaba o deseaba el cliente. Trabajábamos por tanto con un plan rígido, predictivo y basado en fases secuenciales, también conocido como waterfall.

Todo esto queda resuelto con la metodología ágil SCRUM. Una metodología dinámica, que nos permite adaptarnos a requerimientos cambiantes o poco definidos, además permite una colaboración activa con el cliente en todo momento, porque facilita las entregas de software frecuentes con funcionalidad terminada, podemos decir, por tanto, que el software que funciona es la principal medida del proceso.

Hacer un resumen de SCRUM en un artículo es complicado, pero a grandes rasgos podemos decir que es una metodología que tiene un modelo ágil de desarrollo de software basado en:

Requisitos funcionales llamados historias. Son requisitos no técnicos, en los que se indica lo que se desea y para qué se desea, pero no el cómo hacerlo. Las historias deben estar atomizadas lo máximo posible, y si una es muy grande se subdivide en historias más pequeñas, independientes dentro de lo posible. Deben ser completas, incluyendo todo el ciclo de desarrollo (Diseño, construcción, pruebas y documentación) y demostrables. Las historias se incorporan en lo que denominamos Product Backlog. El Product Backlog es, por tanto, el inventario de funcionalidades y mejoras que deben realizarse en el producto. Todas las historias deben estar priorizadas y valoradas en puntos por el equipo.

Tiempo de desarrollo. Se trabaja con iteraciones rápidas, con entregas periódicas 100% funcionales llamados Sprints. Dependiendo del tipo de software que se desarrolle los sprints pueden durar entre 1 y 4 semanas. El contenido del sprint viene dado directamente por el Product Backlog priorizado, y el contenido de un sprint no cambia una vez iniciado. El equipo se compromete, por tanto, a la finalización del desarrollo incorporado dentro del sprint.

Actores. En la metodología participan los siguientes actores:

El Product Owner es el representante de todas las personas interesadas en el proyecto (Internas o externas a la organización, promotores y usuarios finales), actúa por tanto de interlocutor único ante el equipo y tiene la autoridad para tomar las decisiones funcionales necesarias, podríamos decir que es el «gurú» del producto. También se encarga de tener el backlog correctamente priorizado.
El Scrum Master actúa como líder del equipo. Debe asegurarse que la metodología SCRUM se aplica correctamente. Se encarga de organizar las reuniones y asegurarse de que el software se realiza con calidad. Debe encargarse de quitar los impedimentos que el equipo tiene en su camino para conseguir los objetivos del sprint.
El Equipo es el encargado del desarrollo de las historias de forma que estén preparadas para ser entregadas al finalizar el sprint. Por tanto, el equipo al inicio del sprint, se compromete a finalizarlo con éxito. En una reunión inicial de Sprint planning el equipo desglosa cada una de las historias en Tareas, de manera que puedan ser realizadas de forma individual. El equipo puede estar compuesto por diferentes perfiles: Business Analist, Developer, Tester, Technical Author,…

Reuniones eficaces: Las reuniones eficaces son una de las claves del correcto funcionamiento de la metodología, todas ellas deben realizarse y ser respetadas para el fin para el que se destinan. Además deben ser «time boxing» (Fijar un tiempo máximo para conseguir unos objetivos, tomar una decisión o realizar unas tareas, evitando que sea sobrepasado). Las reuniones habituales son:

Sprint planning: La reunión de sprint planning se realiza al inicio del sprint para desglosar las historias en tareas, es entonces cuando el equipo monta los paneles que se utilizarán para realizar el seguimiento de todo el sprint.
DailyScrum: Es una reunión diaria que tiene como objetivo detectar y eliminar los posibles impedimentos, medir el progreso y detectar desviaciones. Es una reunión de sincronización de todo el equipo. Se realiza de pie, al lado del panel de SCRUM y la duración máxima es de 15 minutos. Todos los miembros del equipo hablan por turnos respondiendo a las 3 siguientes preguntas:

¿Qué hice desde la última reunión de Daily?
¿Qué voy a hacer hoy?
¿He tenido algún problema que me impida avanzar?

Esta reunión facilita no sólo detectar posibles impedimentos, sino que también todos los miembros del equipo sepan lo que está haciendo el resto (Sincronización del equipo).

Sprint review: El sprint review se realiza al finalizar el sprint, tiene como finalidad comunicar el avance de lo que se ha finalizado (y lo que no se ha podido terminar) realizando una demostración del contenido.
Sprint retrospective: Se analizan los posibles problemas e impedimentos surgidos durante el sprint, se plantean mejoras en las formas de trabajar y se acuerda la realización de acciones. También se refuerzan los aspectos positivos del sprint.

Paneles de seguimiento del sprint: Aunque parezca que no son importantes, en ocasiones son la clave para conseguir que el equipo se comprometa a la finalización del sprint. El panel se compone de 3 partes: Tareas pendientes, Tareas en curso y Tareas finalizadas. Cada miembro del equipo, se asigna una tarea, pasándola del «Pendiente» al «En curso», por tanto cada tarea va ligada a la acción física de coger una tarjeta del panel y asignarse el trabajo como suyo propio. Cuando la tarea se finaliza, debe pasarse del “En curso” al “Finalizado”. En algunos casos los paneles se virtualizan, para que tanto la asignación de tareas como el seguimiento del sprint se realice en formato digital. En el mercado podemos encontrar cantidad de aplicaciones que nos permiten trabajar con SCRUM, algunas de ellas son gratuitas y otras de pago.

Herramientas de control: SCRUM dispone de una serie de herramientas que facilitan el avance de los desarrollos. Disponemos por ejemplo del burndown chart, es un gráfico en el que vemos en una línea temporal cuantas tareas deberíamos haber finalizado y las que quedan pendientes, así vemos si el sprint va en línea con lo previsto.

Si bien es cierto que SCRUM puede mejorar el desarrollo del software, no es oro todo lo que reluce. También deben tenerse en cuenta algunas desventajas antes de decidir utilizar la metodología:

Es imprescindible que para que la metodología funcione se vean involucrados todos los niveles de la empresa en la que se aplica, todos deben ser conocedores de la existencia de la metodología y respetarla, en caso contrario sería comparable a meter un Ferrari en una carretera de montaña sin asfaltar, en la que sólo hay baches, en lugar de dar rienda suelta al objetivo principal, que es centrarse en los resultados. Uno de los mayores impedimentos para que la metodología arranque en las empresas no suele venir de abajo, sino de arriba, donde en ocasiones no acaban de entender la necesidad de “tantas reuniones” o la existencia de “paneles con papeles enganchados”. Es necesario, por tanto, una directiva que sepa aceptar y abrazarse a los cambios.
La definición de las historias debe ser precisa. Uno de los errores típicos es la poca definición de las historias de desarrollo, y que el equipo asuma el compromiso de realizarla. Es algo que normalmente acaba en fracaso de la historia y del propio sprint.
El objetivo final es que el equipo sea autosuficiente, es por esto que es ideal que los perfiles sean senior, gente con cierta experiencia y conocimiento como para asumir los compromisos. Como ejemplo: La siguiente tarea a realizar la escoge el propio miembro del equipo, y debe por tanto escoger aquella que le dé más valor a la finalización del sprint y no la más sencilla de hacer.
No es aconsejable superar equipos de 9 personas. La comunicación entre los miembros con equipos tan grandes se hace más difícil de lo normal. En estos casos siempre es mejor formar más de un equipo.

SCRUM es una de las formaciones de rugby. (Trabajo en equipo)

Por otro lado, es una metodología que no sólo se está aplicando en el desarrollo del software, también hay otros sectores donde su uso empieza a ser cada vez más frecuente para facilitar la organización del trabajo, como puede ser en laboratorios o en enseñanza a través de grupos cooperativos en institutos.

¿Y vosotros conocéis la metodología?