El año pasado Rebeca nos hablaba sobre los MOOC que últimamente están tan de moda, en concreto nos hacía referencia a MiriadaX y a un curso sobre Agilidad y Lean (lee el artículo completo aquí) y yo quería hablaros sobre Scrum, que es un modelo de desarrollo ágil del software que me llama mucho la atención y se adapta mejor a los tiempos que corren.
Los modelos tradicionales de desarrollo, en los que hay una planificación casi invariable del alcance, el tiempo y el coste del proyecto tras un análisis exhaustivo de los requerimientos, son buenos para otras ingenierías o arquitecturas, como por ejemplo las construcciones de viviendas o edificios donde es muy fácil distinguir las diferentes fases del proyecto que han de llevar un orden concreto, pero esto no siempre pasa en las aplicaciones software puesto que nos aparecen clientes que no pueden esperar a que se finalice el edificio para utilizar un aseo, o no tienen presupuesto para abarcar un proyecto completo, o no tienen claros todos sus requerimientos sino una pequeña parte de los mismos o simplemente no quieren casarse contigo hasta la finalización del proyecto.
Scrum da respuesta a este tipo de problemas ya que adopta una estrategia de desarrollo incremental e iterativa, en lugar de la planificación y ejecución completa del producto solapando las fases del desarrollo, consiguiendo de este modo que los cambios de alcance (ya sea por nuevos requerimientos o por mala interpretación de los mismos por parte de los analistas o el equipo de desarrollo) no interfieran en absoluto.
Como ya he comentado anteriormente, en los desarrollos tradicionales los requisitos han de estar desde el comienzo y el equipo de desarrollo ha de adaptar el trabajo a los plazos y criterios definidos en el análisis al principio, y no se comienza el desarrollo hasta que dicho análisis quede finalizado. Mencionar que las estadísticas hablan de que la incertidumbre de un análisis aumenta un 4% con cada mes que analizamos por adelantado, un proyecto analizado a 1 año tendría un 50% de incertidumbre. En cambio Scrum define la sucesión de una serie de ciclos al final de los cuales el cliente recibe un trozo del producto que puede ser considerado terminado y completo pese a contener únicamente la implementación de unos pocos requisitos del cliente. La clave está en que después del ciclo obtenemos feedback del cliente y podemos adaptar el siguiente ciclo a posibles cambios de los requisitos y lo que en ese momento es prioritario, aprendiendo con cada iteración lo que es importante para el cliente y reduciendo la incertidumbre a la mínima expresión.
¿Cómo es esto? Al principio de cada reunión el equipo de desarrollo elige de entre el listado ordenado por importancia para el cliente, qué requisitos va a implementar en ese ciclo. Y no solo los elige sino que se compromete a tenerlos terminados y probados para la fecha concretada y se pone a trabajar en ellos. Durante el tiempo de trabajo nadie puede interrumpirles ni influir en su ritmo de trabajo.
 |
| Marco de trabajo Scrum |
Tras esta breve introducción al Scrum (puedes aprender más en los cursos de Scrummanager o visitar el blog de mi amigo Alex quisiera comentar desde mi experiencia, por qué me parece interesante y que dificultades le veo en la implantación de este modelo de desarrollo.
Por un lado Scrum da importancia al equipo y al conocimiento tácito de las personas. Desde que comencé a trabajar y tras mi paso por varias empresas lo importante siempre han sido los compañeros. Cuando hemos tenido buen ambiente entre nosotros y hemos cogido un compromiso con un plazo de entrega, hemos puesto toda la carne en el asador para llegar a ello intentando hacer las cosas bien, aprendiendo de los demás del equipo y compartiendo con ellos mis propios conocimientos. En cambio no pasa lo mismo cuando las decisiones no las tomas tú sino que te las imponen o el equipo no está cohesionado o aparecen interrupciones en el trabajo diario o cuando antes de terminar lo que estás realizando te cambian de repente el alcance del proyecto y tu trabajo no ha servido para nada.
Por un lado Scrum da importancia al equipo y al conocimiento tácito de las personas. Desde que comencé a trabajar y tras mi paso por varias empresas lo importante siempre han sido los compañeros. Cuando hemos tenido buen ambiente entre nosotros y hemos cogido un compromiso con un plazo de entrega, hemos puesto toda la carne en el asador para llegar a ello intentando hacer las cosas bien, aprendiendo de los demás del equipo y compartiendo con ellos mis propios conocimientos. En cambio no pasa lo mismo cuando las decisiones no las tomas tú sino que te las imponen o el equipo no está cohesionado o aparecen interrupciones en el trabajo diario o cuando antes de terminar lo que estás realizando te cambian de repente el alcance del proyecto y tu trabajo no ha servido para nada.
Por otro lado cuando el cliente recibe entregas funcionales que puede utilizar cada breve espacio de tiempo se involucra más en el desarrollo de algo que será suyo. Le es más fácil percibir que sus impresiones, ideas y opiniones son tomadas en cuenta y se reflejan al poco tiempo en el producto que recibe, dándose cuenta de la dificultad que tiene implementar sus peticiones, de modo que está también más receptivo ante retrasos y/o errores.
De todos modos cabe destacar que no es fácil llegar a implantar esta metodología de trabajo ya que hay que conseguir cambiar el modo de pensar de toda la organización, desde la directiva y la gerencia hasta el propio: hace poco a comienzos de un proyecto personal a pequeña escala intenté implantar Scrum para su desarrollo, pero al final con los plazos de entrega tan ajustados acabamos desarrollando un Extreme Programming de libro.
Referencias:
- Recomendación - Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI (2ª edición) (artículo de Rebeca en este mismo blog)
- Scrummanager (http://www.scrummanager.net/)
- El blog de un apóstol de Scrum y Kanban (http://scrum.menzinsky.com/)
- Wikipedia (http://es.wikipedia.org/wiki/Scrum)