La solidez del equipo de rugby, con su líder alerta ante las presiones del entorno es una de las bazas de la metodología de desarrollo Scrum, tal y como refleja la imagen superior. Scrum proporciona un conjunto de reglas para proveer dicha protección y una mayor comunicación entre los miembros del equipo, y recibe precisamente su nombre del de la formación en que se disponen estos jugadores. Está inscrita dentro de las metodologías ágiles, entre ellas Extreme Programming (XP), y sus valores derivan del Manifiesto Ágil.
En cualquier caso, la intención de esta entrada es dar una breve introducción a Scrum, aunque que existen varias muy completas y accesibles que pueden encontrarse al pie del artículo, pero en este caso pretendo estudiarlo desde la perspectiva de la integración de Scrum con Test-Driven Development (TDD) y el Rational Unified Process (RUP).
La definición que para RUP tiene la Wikipedia es:
Un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Por otro lado, TDD ya es conocido por los lectores del blog, y se trata de una metodología de desarrollo que basa el mismo en la guía mediante pruebas unitarias del software. De este modo, tenemos un proceso de desarrollo, RUP, que consta de cuatro fases (Concepción, Elaboración, Construcción y Transición), unas directrices proporcionadas por Scrum, y una metodología que es la aportada por TDD. ¿Cómo encajar todo esto en una organización en la que está implantado RUP? Lo primero, como ya apuntaba en su día respecto a la implantación de TDD en la empresa, es comenzar por pequeños equipos que actúen como motor de transición para el resto de la organización. Además, a esto se suma que Scrum está especialmente indicado para equipos que consten de 7 a 15 miembros, aproximadamente. Comenzaremos, ya que introdujimos TDD en su día, a hacer lo propio con Scrum, para ir ampliando tanto uno como otro en sucesivas entradas.Ante todo, debemos tener claro que Scrum plantea ciclos de desarrollo de unos 30 días, y define unos roles muy específicos en todo el proceso. Comenzando por los roles, tendremos:
- Cliente: en efecto, es quien piensas :).
- Product Owner: muy cercano al cliente, o un miembro de la organización que conozca claramente el producto y los requerimientos asociados al mismo.
- Scrum Master: similar al jefe de equipo, se encargará de definir tareas, y será el “paraguas” que cubrirá al equipo de desarrollo, evitando que se interfiera en el proceso de desarrollo.
- Scrum Team: el equipo de desarrollo. A sus miembros se les suele denominar cerdos (pigs). Antes de que nadie se ofenda, diremos que en Scrum hay dos tipos de individuos: los cerdos, que se comprometen con el desarrollo, y las gallinas (chickens), que se involucran, tienen interés en el producto, pero no se implican. La mejor explicación que he encontrado para estos roles es la siguiente tira cómica:
En cuanto a las actividades definidas por Scrum, tenemos:
- Product Backlog: donde el Product Owner define los requisitos, las nuevas funcionalidades y errores a subsanar.
- Sprint Planning Meeting: El Product Owner se reúne con el Scrum Master y el Scrum Team. Definen DE FORMA REALISTA, last areas a realizar durante los próximos 30 días.
- Sprint Backlog: Durante 30 días se desarrolla para conseguir alcanzar los objetivos, definidos en la Sprint Planning Meeting. Diariamente el Scrum Master se reunirá con el Scrum Team (Daily Scrum Meeting), para dar respuesta a tres cuestiones, para cada miembro del equipo:
- ¿Qué he hecho desde la última reunión?
- ¿Qué haré hasta la próxima?
- ¿Existe algún problema que me impida cumplir con las tareas asignadas?
El Scrum Master deberá actuar como paraguas del equipo, evitando que se interfiera en el trabajo. Durante todo el Sprint Backlog no se redefinirán tareas, ni se incorporarán cambios. Al finalizar los 30 días, existirá un entregable. El Product Owner podrá hacer una presentación del mismo a los clientes o directivos de la empresa. Se llevará a cabo otra reunión, de forma retrospectiva, como evaluación del Sprint Backlog, para ver el grado de alcance de los objetivos fijados, y cuáles han sido los logros y problemas encontrados (lecciones aprendidas).
Se volverá a entregar un nuevo paquete de trabajo del Product Backlog, y se comenzará un nuevo ciclo de Sprint Backlog.
En los sucesivas entradas iremos viendo cómo integrar estos ciclos con TDD y, a mayor escala, con RUP en toda la empresa.
Para saber más:
Excelente artículo, ma ha servido mucho. Comparto otro artículo interesante http://www.conexionit.com/blog/
ResponderEliminarSaludos
Gracias Alejandro :)
ResponderEliminarDe hecho, ayer me daba cuenta de cómo algunos enlaces a las imágenes no funcional del todo bien (debido a un par de migraciones que tuve que realizar este año). Voy a ver si los arreglo pronto. Le echo un vistazo a este enlace que compartes con nosotros.
Un saludo,
Mith.
Hola,
ResponderEliminarUn grupo de personas hemos estado creando una base de conocimientos gratuita de Scrum en español: http://www.proyectosagiles.org . Está elaborada de manera que la gestión ágil de proyectos con Scrum se pueda utilizar en diferentes departamentos y negocios (no sólo el de desarrollo de software) y así comunicar mejor a los "decisions makers" que existe una alternativa a la gestión clásica de proyectos. Te invitamos a contribuir escribiendo allí tus experiencias con Scrum.
Saludos,
Xavier
¡Hola Xavier!
ResponderEliminarMe parece una iniciativa muy, muy interesante, ya que aunque existen recursos en español sobre Scrum, no son demasiados y nunca está de más un lugar común donde compartir ideas y experiencias. Le echo un vistazo al sitio web (que veo que está arrancando desde hace muy poquito) y recomendaré su lectura en el trabajo.
Saludos.