Mayo 2009.

Metodologías ágiles – XP / SCRUM. Parte I.

Las metodologías ágiles ( por ejemplo XP, SCRUM, DSDM, Crystal Clear, etc..) forman parte del movimiento de desarrollo ágil de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto.

Intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

Una metodología ágil tiene los siguientes principios:

Los individuos y sus interacciones son más importantes que los procesos y las herramientas.

El software que funciona es más importante que la documentación exhaustiva. La colaboración con el cliente en lugar de la negociación de contratos. La respuesta delante del cambio en lugar de seguir un plan cerrado.

Las metodologías que se tratarán a lo largo de este post son SCRUM y XP (eXtreme programming), se explicarán sus ventajas, desventajas y el porque sería viable el combinarlas con el fin de obtener un mejor resultado al implementarlas en un proyecto.

Comenzaré por definir que es SCRUM, las fases que la componen, así como los principales conceptos y roles que son manejados en esta metodología.

XP – eXtreme Programming.

Definición y aspectos generales:

XP es una metodología liviana basada en cuatro principios:

Simplicidad, comunicación, retroalimentación(feedback) y valor.

Está diseñada para equipos pequeños encargados de desarrollar software en proyectos cuyos requerimientos son ambiguos o de alto riesgo; fue formulada por Kent Beck en 1996. Está diseñada para entornos dinámicos. Se basa en un grupo de gente que programa en estrecho contacto con sus clientes.

XP propone un proceso de desarrollo liviano, eficiente, de bajo riesgo, flexible, predecible y científico. Se recomienda para equipos pequeños de entre 2 y 12 programadores. Está orientada fuertemente hacia la codificación, pruebas y la refactorización.

Se diseñan e implementan las pruebas antes de programar la funcionalidad, el programador

crea sus propios tests de unidad.

La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.

Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

1

Una cosa fundamental de la programación extrema es de programación por parejas, dos personas sentadas delante del mismo ordenador haciendo el mismo código.

Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto.

Una de las críticas a XP es la dificultad de estimar cuánto va a costar un proyecto.Dado que el alcance del mismo no está completamente definido al comienzo, y que la metodología XP es expresamente abierta a los cambios durante todo el proceso, se torna sumamente difícil poder realizar un presupuesto previo. Para desarrollos “in house” este punto puede no ser crítico, pero sí lo es especialmente para empresas desarrolladoras de software, dónde deben presupuestar (y ganar) proyectos.

Prácticas básicas de XP.

Para que todo esto funcione, la programación extrema se basa en 12 "prácticas básicas" que deben seguirse al pie de la letra.

• El juego de la planificación (Planning Game): El usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo..Se hace una reunión diaria (Stand-Up Meeting) con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos a los que se les ha de dar más importancia por su dificultad o por su punto crítico.

• Entregas pequeñas (Short Releases): Son lo más pequeñas posibles. Un sistema simple se pone rápidamente en producción. Periódicamente, se producen nuevas versiones agregando en cada iteración aquellas funciones consideradas valiosas para el cliente

• Metáfora (Metaphor): Cada Proyecto es guiado por una historia simple de cómo funciona el sistema en general, reemplaza a la arquitectura y debe estar en lenguaje común, entendible para todos (Cliente y Desarrolladores), esta puede cambiar permanentemente.

• Diseño simple (Simple Designs): El sistema se diseña con la máxima simplicidad posible. Se plasma el diseño en tarjetas CRC (Clase – Responsabilidad- Colaboración), no se implementan características que no son necesarias, con esta técnica, las clases descubiertas durante el análisis pueden ser filtradas para determinar qué clases son realmente necesarias para el sistema.

• Pruebas (Testing): Los casos de prueba se escriben antes que el código. Los desarrolladores escriben pruebas unitarias y los clientes especifican pruebas funcionales.

• Refactoring (Refactoring): Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo eliminando código duplicado, simplificando funciones,

2

Mejorando el código constantemente, si el código se esta volviendo complicado se debería modificar el diseño y volver a uno más simple. Refactoring (Modificar la forma del código sin cambiar su funcionamiento).

• Programación en parejas (Pair Programming): El código es escrito por dos personas trabajando en el mismo computador. 

• Propiedad colectiva (Collective Code Ownership): Nadie es dueño de un modulo. Cualquier programador puede cambiar cualquier parte del sistema en cualquier momento, siempre se utilizan estándares y se excluyen los comentarios. Los test siempre deben funcionar al 100% para realizar integraciones con todo el código permanentemente.

• Integración continua (Continuous Integration): L os cambios se integran en el código base varias veces por día. Todos los casos de prueba se deben pasar antes y después de la integración, se dispone de una máquina para la integración y se realizan test funcionales en donde participa el cliente.

• Semana de 40 horas (4 0-Hour Week): Cada Trabajador trabaja no más de 40 Horas por seman a. Filosofía: “Los programadores que descansan son más productivos”. El exceso de trabajo es un serio problema en un proyecto. La gente está más fresca y tiene mejores ideas

• Cliente in situ(On Site Customer): Cliente real (Aquel que usará el sistema cuando esté en producción). El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual está disponible para responder preguntas, fijar prioridades, discutir mejoras, etc.

• Estándares de programación (Coding Standard): Todo el código debe estar escrito de acuerdo a un estándar de codificación. Son fundamentales cuando los programadores cambian de pareja o hacen refactoring del código de otros. Se consigue un código con el mismo estilo, homogéneo, legible.

3

Fases de XP.

El ciclo de vida de un proyecto XP incluye, al igual que otras metodologías, entender lo que el cliente necesita, estimar el esfuerzo, crear la solución y entregar el producto final al cliente. Sin embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente que, en muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de un proyecto.Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con entregables funcionales al finalizar cada ciclo. En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas que caracterizan a XP.

Las iteraciones son relativamente cortas (iteración = 2 o 3 semanas) ya que se piensa que entre más rápido se le entreguen desarrollos al cliente, más retroalimentación se va a obtener y esto va a representar una mejor calidad del producto a largo plazo.

- Fase de la exploración: En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto.Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

- Fase de planificación: La planificación es una fase corta, en la que el cliente, los gerentes y el grupo de desarrolladores acuerdan el orden en que deberán implementarse las historias de usuario, y, asociadas a éstas, las entregas. Típicamente esta fase consiste en una o varias reuniones grupales de planificación. El resultado de esta fase es un Plan de Entregas, o “Release Plan”. Se priorizan las historias de usuario, seleccionando aquellas más importantes para el negocio.

Los programadores estiman cuánto esfuerzo requiere cada historia y a partir de allí se define el cronograma. La duración del cronograma del primer release no excede normalmente dos meses. La fase de planeamiento toma un par de días. Se deben incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa de planeamiento se realiza a un número de iteraciones, cada una toma de una a cuatro semanas en ejecución. La primera iteración crea un sistema con la arquitectura del sistema completo. Esto es alcanzado seleccionando las historias que harán cumplir la construcción de la estructura para el sistema completo. El cliente decide las historias que se seleccionarán para cada iteración. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteración. Al final de la última iteración el sistema está listo para producción.

- Fase de iteraciones: Esta es la fase principal en el ciclo de desarrollo de XP. Las funcionalidades son desarrolladas en esta fase, generando al final de cada una un entregable funcional que implementa las historias de usuario asignadas a la iteración. Como las historias de usuario no tienen suficiente detalle como para permitir su análisis y desarrollo, al principio de cada iteración se realizan las tareas necesarias de análisis, recabando con el cliente todos los datos que sean necesarios. El cliente, por lo tanto, también debe participar activamente durante esta fase del ciclo.Las iteraciones son también utilizadas para medir el progreso del proyecto. Una iteración terminada sin errores es una medida clara de avance.

- Fase de producción: Si bien al final de cada iteración se entregan módulos funcionales y sin errores, puede ser deseable por parte del cliente no poner el sistema en producción hasta tanto no se tenga la funcionalidad completa.En esta fase no se realizan más desarrollos funcionales, pero pueden ser necesarias tareas de ajuste (“fine tuning”).

4

- Fase de mantenimiento: Requiere de un mayor esfuerzo para satisfacer también las tareas del cliente. Así, la velocidad del desarrollo puede desacelerar después de que el sistema esté en la producción. La fase de mantenimiento puede requerir la incorporación de nueva gente y cambiar la estructura del equipo.

- Fase de muerte: Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

Conceptos básicos de planificación.

- Historias de usuario: Sustituyen a los documentos de especificación funcional, y a los “casos de uso”. Estas “historias” son escritas por el cliente, en su propio lenguaje, como descripciones cortas de lo que el sistema debe realizar, es un texto de una o dos frases en las que se dice algo que debe hacer el sistema. La diferencia más importante entre estas historias y los tradicionales documentos de especificación funcional se encuentra en el nivel de detalle requerido. Las historias de usuario deben tener el detalle mínimo como para que los programadores puedan realizar una estimación poco riesgosa del tiempo que llevará su desarrollo. Cuando llegue el momento de la implementación, los desarrolladores dialogarán directamente con el cliente para obtener todos los detalles necesarios.

Las historias de usuarios deben poder ser programadas en un tiempo entre una y tres semanas. Si la estimación es superior a tres semanas, debe ser dividida en dos o más historias. Si es menos de una semana, se debe combinar con otra historia.

- Plan de entregas (“Release Plan”): El cronograma de entregas establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de las mismas. Este cronograma será el resultado de una reunión entre todos los actores del proyecto (cliente, desarrolladores, gerentes, etc.). XP denomina a esta reunión “Juego de planeamiento” (“Planning game”), pero puede denominarse de la manera que sea más apropiada al tipo de empresa y cliente (por ejemplo, Reunión de planeamiento, “Planning meeting” o “Planning workshop”). Típicamente el cliente ordenará y agrupará según sus prioridades las historias de usuario. El cronograma de entregas se realiza en base a las estimaciones de tiempos de desarrollo realizadas por los desarrolladores.Luego de algunas iteraciones es recomendable realizar nuevamente una reunión con los actores del proyecto, para evaluar nuevamente el plan de entregas y ajustarlo si es necesario.

- Plan de iteraciones (“Iteration Plan”): Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden preestablecido. Al comienzo de cada ciclo, se realiza una reunión de planificación de la iteración. Cada historia de usuario se traduce en tareas específicas de programación. Asimismo, para cada historia de usuario se establecen las pruebas de aceptación. Estas pruebas se realizan al final del ciclo en el que se desarrollan, pero también al final de cada uno de los ciclos siguientes, para verificar que subsiguientes iteraciones no han afectado a las anteriores. Las pruebas de aceptación que hayan fallado en el ciclo anterior son analizadas para evaluar su corrección, así como para prever que no vuelvan a ocurrir.

- Reuniones diarias de seguimiento (“Stand-up meeting”): El objetivo de tener reuniones diarias es mantener la comunicación entre el equipo, y compartir problemas y soluciones. En la mayoría de estas reuniones, gran parte de los participantes simplemente escuchan, sin tener mucho que aportar. Para no quitar tiempo innecesario del equipo, se sugiere realizar estas reuniones en círculo y de pie.

5

Roles que maneja XP.

Existen diferentes roles (actores) y responsabilidades en Xp para diferentes tareas y propósitos durante el proceso:

Programador (Programmer).

- Responsable de decisiones técnicas. - Responsable de construir el sistema. - Sin distinción entre analistas, diseñadores o programadores. - En XP, los programadores diseñan, programan y realizan las pruebas.

Jefe de Proyecto (Manager).

- Organiza y guía las reuniones.

- Asegura condiciones adecuadas para el proyecto.

Cliente (Customer).

- Es parte del equipo.

- Determina qué construir y cuándo.

- Establece las pruebas de aceptación.

Encargado de Pruebas (Tester)

- Ayuda al cliente con las pruebas de aceptación.

- Se asegura de que las pruebas aceptación se superan.

Rastreador (Tracker)

- Metric Man.

- Observa sin molestar.

- Conserva datos históricos.

Entrenador (Coach)

- Responsable del proceso.

- Tiende a estar en un segundo plano a medida que el equipo madura.

6

Aplicabilidad.

Cada metodología tiene sus escenarios de aplicabilidad. Ninguna de las metodologías de desarrollo de software son buenas para todos los proyectos. Para proyectos que requieran varias decenas de desarrolladores, y en los que las especificaciones estén claramente determinadas desde el comienzo, los métodos en cascada o espiral pueden ser los más adecuados. Por el contrario, para proyectos medianos, y en los que las especificaciones no se puedan obtener hasta luego de comenzado el proyecto, XP puede ser la metodología recomendada.

Propiedad compartida del código.

Para lograrlo, XP exige dos cosas: mover a los desarrolladores de sus asignaciones a otras y desarrollar en parejas de modo que la toma de decisiones y el conocimiento sobre ellas no sea un secreto.

Adicionalmente, cada día las reuniones permiten notificar estas decisiones al resto del grupo. El desarrollo en parejas puede ser perjudicial si no se mantiene la disciplina necesaria para concentrarse en el código.

Documentación en XP.

Una de las cosas más importantes de la programación extrema es que no se hace documentación en absoluto si no es necesaria para algo concreto.XP NO dice que NO se haga documentación. Sólo dice que se haga la estrictamente NECESARIA para algo concreto.

Sin embargo es lógico que sea necesaria para que cualquier persona fuera del proyecto se ponga en contexto. O pensando en que el posterior mantenimiento del proyecto. Al final todo dependerá del proyecto y del equipo.La documentación puede llegar a ser necesaria si por ejemplo, al finalizar el proyecto serán otras las personas encargadas del mantenimiento.

No hay mejor documentación en extreme programming que el mismo código y las pruebas unitarias del mismo. A esto se le pueden añadir las historias de usuario y las planificaciones de tiempo para esas historias de usuario.

7

¿Cuándo usar XP?

Alguna de las situaciones en las que XP es adecuada son:

Los requerimientos no están claros o cambian mucho: El cliente no tiene una idea

clara de lo que el sistema debería hacer.

Los riesgos son altos: Si el cliente tiene una fecha tope o si el proyecto representa

una novedad para el equipo de desarrollo.

Se trabaja con un equipo de desarrollo pequeño: Se recomienda equipos de entre 2

y 12 programadores.

Se dispone de un equipo multidisciplinario: El equipo debe no solo ser de

desarrolladores, sino también los gerentes y clientes, todos trabajando en conjunto. El código debe poder ser probado: Debe ser posible automatizar las pruebas

unitarias y funcionales.

Fuente:

http://www.forosdelweb.com/f50/metodologia-extreme-programming-468203/

http://es.wikipedia.org/wiki/Desarrollo_ágil_de_software

http://es.wikipedia.org/wiki/Programación_Extrema

http://tech.groups.yahoo.com/group/xpspanish/

http://www.xprogramming.com/xpmag/whatisxp.htm

http://www.chuidiang.com/ood/metodologia/extrema.php

http://aikon.com.ve/metodologias-desarrollo-software-extreme-programming/

http://www.monografias.com/trabajos51/programacion-extrema/programacion-extrema.shtml

http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf

http://www.agile-software-development.com/2008/04/extreme-programming-versus-scrum.html

http://weblogs.asp.net/rosherove/archive/2006/11/17/scrum-vs-xp-why-scrum-is-easier-to-sell.aspx

http://www.elraul.com/?cat=24

http://www.cristalab.com/blog/introduccion-a-la-programacion-extrema-c44013l/

8

Metodologías ágiles – XP / SCRUM. Parte II.

SCRUM.

Es un proceso de desarrollo de software iterativo y creciente utilizado comúnmente en entornos basado en el desarrollo ágil de software.

Conceptos y Roles.

Para comprender mejor esta metodología es necesario conocer primero los conceptos y tecnicismos que utiliza para referirse a determinados artefactos, roles y actividades (desde el punto de vista de la terminología RUP), stakeholders y demás, es por ello que a continuación se explican cada uno de ellos:

- Product Backlog: Documento en el cual se detallan, de forma priorizada, los requisitos del sistema.

- Sprint: Cada una de las iteraciones de que se compone el desarrollo con Scrum. Si existe razón de suficiente peso, puede abortarse el sprint y comenzar uno nuevo.

- Sprint Backlog: “trozo” de backlog que nos comprometemos a implementar de forma satisfactoria en el sprint (iteración) actual.

- ProductOwner: Cliente fundamental del sistema. El que desea o propone el software. El propietario del producto. El ‘input’ principal para poner en marcha el nuevo proyecto. Es fundamental que la persona que desempeña este rol se implique al máximo en el proyecto, para que éste tenga garantías de éxito.

- ScrumMaster: Gestor del proyecto un poco especial: motiva al equipo. Crea un clima en el cual el equipo trabaje a gusto y sin interrupciones: protege a su equipo. Sin embargo, le deja trabajar libremente. No debe fallar al equipo. No debe faltar a ninguna reunión. Siempre estará ahí, para atender las necesidades del equipo. Es más un “líder” que un “gestor” al uso. Ken Schawber dice que es como el perro pastor de un rebaño de ovejas. Vigila y protege a las ovejas, pero sin molestarlas, sin intervenir prácticamente en sus cometidos.

- Team: Equipo de desarrollo. Cada equipo estará compuesto por 7 +-2 personas (es decir: entre 5 y 9 personas, preferiblemente 7). El ScrumMaster jamás intervendrá aquí. El equipo debe estar cohesionado y debe promoverse la filosofía de “todos ayudan a todos”. El equipo se autogestiona a sí mismo. Los miembros del equipo no tienen roles: colaboran entre ellos y “todos hacen de todo”: análisis, diseño, implementación, pruebas y documentación. De este modo no se rompe la continua colaboración y desarrollo de las funcionalidades del proyecto.

En esta metodología existen dos roles bastante graciosos que dan forma a Scrum: Cerdos (pigs) y gallinas (chicken). La denominación viene de un popular chiste:

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: “Hey, ¿por qué

no abrimos un restaurante?” El cerdo mira a la gallina y le dice: “Buena idea, ¿cómo se llamaría

el restaurante?” La gallina piensa un poco y contesta: “¿Por qué no lo llamamos “Huevos con

jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente

estarías involucrada”.

9

En Scrum, los cerdos (aquellos que están comprometidos de forma seria con el proyecto) son desempeñados por los subroles Team, ScrumMaster y ProductOwner.

El rol gallina está constituido por otros clientes y stakeholders (ejecutivos, etc.). Al final, todos los roles “cerdo” son gestores (managers), desde el momento en el que se dice que están comprometidos con el proyecto.

Aspectos generales.

Scrum entiende el desarrollo de software como algo empírico, y no determinista. Esto significa que Scrum comprende que crear software es algo muy complejo, sujeto a multitud de variaciones e incertidumbres, sobre todo al comienzo. Además cada problema es diferente y no existe una solución mágica que se pueda aplicar a cualquier proyecto. Por ello trata de acometer esta incertidumbre y estos riesgos desde el propio modelo de desarrollo.

Scrum trata de que todo el mundo involucrado en el proyecto conozca perfectamente en qué punto del desarrollo se encuentra el proyecto y qué falta por hacer. Esto se consigue a través de las numerosas reuniones de control, que no tratan de informar al jefe de proyecto o los stakeholders, sino más bien a TODAS las personas involucradas en el proyecto. El objetivo no es sólo el control del proyecto, sino la involucración y el conocimiento por parte de todos. Además, es importante que el equipo esté cohesionado y colaboren unos miembros con otros y se apoyen mutuamente.

Scrum no es una metodología “mágica”, sino un marco de posibles estrategias, respetando unas reglas prefijadas. Una plantilla a la que después se puede acoplar distintas técnicas de planificación, gestión, control, estimación, análisis, diseño, implementación y pruebas. En esta simplicidad radica su potencial. Las reglas del juego son rápidas de aprender.

Otra idea fundamental de Scrum es que trata todo el desarrollo del software desde el punto de vista del sentido común y es una metodología flexible.

Utilizar Scrum permite entregar al cliente un producto que le satisface, que cumple mejor los requisitos que él pedía, y con la calidad adecuada. Además el equipo es productivo y trabaja más a gusto, se compromete con el proyecto y la organización haciendo lo que más le gusta.

El uso de Scrum permite reducir la estimación temporal hasta en un 40%, debido precisamente a este aumento en la productividad, fruto de los rápidos desarrollos en los Sprints y los compromisos adquiridos por los miembros del equipo.

Debido a su alto carácter iterativo y variable, no es en absoluto necesario realizar complejas planificaciones iniciales.

10

Aplicabilidad.

Scrum es aplicable a cualquier tipo y tamaño de proyectos, si bien es especialmente útil en proyectos medios y grandes en cuanto a complejidad o a tamaño, o bien en aquellos proyectos donde la incertidumbre es grande, bien por el campo en el cual se desarrolla, o bien porque los requisitos no están bien definidos desde el principio y son muy susceptibles de cambiar durante el desarrollo.

Metodología.

Tres fases fundamentales:

1.- Fase de planificación, en la cual se realizan las labores básicas de una planificación breve: visión general del proyecto (estimación muy general, viabilidad del sistema) y construcción del Backlog, por un lado y por otro el desarrollo de la arquitectura al detalle.

2.- Fase de desarrollo, en la cual tienen lugar los famosos Sprints.

3.- Fase de entrega y balance de los éxitos y fracasos logrados.

La fase fundamental de la metodología, es la fase de Sprint. Las otras dos no difieren mucho con las fases de Planificación y Entrega de otras metodologías.

El desarrollo en la fase Sprint es iterativo, en uno o más Sprints. (¿Cuántos? ¡Los que hagan falta!), hasta que el proyecto se da por finalizado por el ProductOwner.

De este modo se resuelve el problema de la variabilidad de los requisitos. No hay una estimación prematura fiable: los requisitos probablemente cambiarán y la metodología está preparada para ello.

Reuniones, toma de decisiones.

Existen cuatro tipo de reuniones durante el desarrollo de un proyecto con Scrum:

- Encuentro de Planificación (4 horas): Al comienzo de un Sprint se decide qué parte del

Backlog global del proyecto se implementará en este Sprint. Una vez decididas las

funcionalidades a implementar, en base a estimaciones de tamaño, tiempo, esfuerzo, etc.,

el Sprint Backlog no se toca durante todo el Sprint, bajo ninguna circunstancia. Si algo falla,

el ScrumMaster podrá cancelar el Sprint y comenzar otro.

- Encuentro Diario (15 minutos): Diariamente el equipo se reúne en un rápido encuentro,

de unos 15 minutos, para responder, individualmente, a 3 preguntas básicas:

11

-

1.- ¿Qué hiciste ayer?

2.- ¿Qué vas a hacer hoy?

3.- ¿Qué te está impidiendo alcanzar tus objetivos?

De este modo se realiza el control del proyecto y el seguimiento de los posibles riesgos.

- Encuentro de Revisión (4 horas): Al final del Sprint, se realizará una reunión con el

ProductOwner y otros clientes (gallinas) para exponer la funcionalidad desarrollada junto

con las posibles preguntas y ampliaciones del Backlog que se les pueda ocurrir a los

diferentes stakeholders (clientes+ejecutivo). Con esto se logra un ‘feedback’ con el cliente,

que ve cómo el producto progresa.

- Encuentro Retrospectivo (4 horas): Reunión del ScrumMaster con el Team para revisar

cómo fue el Sprint: qué se consiguió realizar bien y cómo se podría mejorar. Esto no es

más que una revisión de lecciones aprendidas y un intento de recabar información histórica

del propio proyecto, útil para futuras estimaciones y Sprints.

Desarrollo de la fase Sprint.

Cada Sprint tendrá una duración aproximada de unos 30 días (en algunas fuentes se habla de

entre 2 y 6 semanas); se entiende que esta cantidad de tiempo es suficiente como para

desarrollar algo entregable y funcional al ProductOwner.

Se comprende como jornada laboral aquella que dura 8 horas. No se contempla, bajo ningún

concepto, por lo dañino y lo poco productivo, la realización de horas extra.

El Sprint comienza con un Encuentro de Planificación en el cual se decide qué se va a

desarrollar del Backlog general y se elabora el Sprint Backlog. A la hora de seleccionar las

funcionalidades a desarrollar se tendrá en cuenta la prioridad de los requisitos, establecida por

el ProductOwner. Se descomponen los requisitos en tareas simples, realizables en poco más

de una jornada laboral de 8 horas como máximo. Como se ha indicado, una vez decidido el

Sprint Backlog éste no se toca en absoluto y bajo ninguna circunstancia durante el Sprint.

Las funcionalidades seleccionadas NO se asignan a los miembros del Team, sino que cada

miembro ELIGE qué desea desarrollar. Una vez comenzado el Sprint, el ScrumMaster no se

implicará lo más mínimo en el Team; realizará sus labores de planificación, estimación, control

y gestión y solamente contactará con el Team en los Encuentros Diarios.

Aparte de esto solamente tratará con algún miembro del Team cuando éste desee preguntarle

algo o solicitar algún tipo de ayuda. Libertad de desarrollo para el equipo; que no significa

ausencia de control o anarquía, ni mucho menos.

El ScrumMaster tratará de favorecer el flow o máxima productividad de su Team y tratará de

crear un clima en el cual se pueda trabajar sin interrupciones.

12

Cada miembro se responsabilizará de entregar la parte que se ha comprometido a realizar en

el plazo fijado. Si es incapaz de ello hablará con el ScrumMaster para solicitar ayuda o detener

el Sprint, de forma muy excepcional. Si el Sprint Backlog se termina antes de tiempo, se puede

dialogar con el ProductOwner para añadir más funcionalidad al Sprint.

El avance Sprint a Sprint se visualiza mediante un artefacto o diagrama de burn down que

representa la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada

Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, se podrá

ver el progreso del proyecto. Lo ideal es que esta línea sea descendente (en casos en que todo

va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían

nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay

más requisitos pendientes de ser completados en el Backlog).

Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en

determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso

valdrá cero en algunos tramos.

Scrum of Scrums.

En la fase Sprint se ha supuesto que existía un solo equipo. ¿Qué ocurre cuando se tienen

varios equipos?

Aquí entra en juego un añadido a la metodología Scrum, el concepto de Scrum of Scrums, que

consiste en realizar un Scrum diario con un representante o portavoz de cada equipo, el cual

explicará al resto los avances diarios que está realizando su grupo (responderá a las 3

preguntas antes mencionadas).

13

Documentos.

Product backlog. 

El product backlog (Pila del producto) es un documento de alto nivel para todo el proyecto.

Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.

priorizadas según su valor para el negocio (business value) . Es el qué va a ser construido.

Es la relación de las funcionalidades, mejoras, tecnología y corrección de errores que deben

incorporarse al producto a través de las sucesivas iteraciones de desarrollo.

Representa todo aquello que esperan los clientes, usuarios, y en general todos los interesados

en el producto.Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar

reflejado en el backlog (por ejemplo, Reducir el tiempo de instalación del programa, Mejorar la

escalabilidad del sistema, Permitir la consulta de obra a través de un API web, etc.).

Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor

para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product

owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas.

A diferencia de un documento de requisitos del sistema, el product backlog nunca se da por

completo; está en continuo crecimiento y evolución.

El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El

Product Backlog no es un documento de requisitos, sino una herramienta de referencia para el

equipo.

El formato debe ser el de una lista que incluya al menos la siguiente información para cada

línea:

Identificador único de la tarea. Descripción de la tarea. Criterio de validación. Campo o sistema de priorización.

Dependiendo del tipo de proyecto y funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:

Observaciones. Estimación. Persona asignada. Nº de Sprint en el que se realiza. Módulo del sistema al que pertenece. Etc.

Es aconsejable no tomar ningún protocolo de trabajo de forma rígida. El formato del product backlog no es cerrado. Los resultados de Scrum no dependen de la rigidez en la aplicación del protocolo, sino de la institucionalización de sus principios y la implementación en un "formato" adecuado a las características de la empresa y del proyecto.

Ejemplo del product backlog:

14

Donde:

- ID: Se trata de un identificador único, simplemente un número auto-incremental. Esto permite no perder la pista a las historias cuando cambia su nombre.

- Orden (Importancia): El ratio de importancia que el Dueño de Producto da a esta historia. Por ejemplo, 10 ó 150. Más alto = más importante.

Se suele evitar el término “prioridad” porque típicamente “1” se considera la “máxima prioridad, lo que es muy incómodo si posteriormente se decide que algo es más importante.

- Descripción: Se trata de una descripción corta de la historia. Por ejemplo, “Ver historial de transacciones”. Suficientemente claro como para que el propietario del producto comprenda aproximadamente de qué se está hablando, y suficientemente clara como para distinguirla de las otras historias. Normalmente, 2 a 10 palabras.

- Estimación inicial: La valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”.

Preguntar al equipo: “Si tuvieran el número óptimo de personas para esta historia (ni muchos ni pocos, típicamente 2) y los encerraran en una habitación con cantidad de comida, y trabajaran sin distracciones, ¿En cuántos días saldrían con una implementación terminada, demostrable, testeada y liberable?”.

Si la respuesta es “Con 3 personas encerrados en una habitación nos llevaría 4 días”, entonces la estimación inicial son 12 puntos.

Lo importante no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2 puntos deba durar 2 días), lo importante es que las estimaciones relativas sean correctas (es decir, que una historia de 2 puntos debería durar la mitad que una historia de 4 puntos).

- Criterio de validación (Como probarlo): Una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Si practicáis TDD (Test-Driven Development, desarrollo orientado a pruebas) esta descripción puede usarse como pseudo-código para el test de aceptación.

- Observaciones (Notas): Cualquier otra información, clarificación, referencia a otras fuentes de información, etc.. Normalmente muy breve.

15

Pueden agregarse campos adicionales en el product backlog ,con la finalidad de facilitar al propietario del producto (Product Owner) la decisión de prioridades, estos campos serían:

- Categoría: Una categorización básica de la historia, por ejemplo “backoffice” o “optimización”. Así, el dueño de producto puede filtrar fácilmente “optimización” y cambiar todas las prioridades de este tipo a “baja”, etc.

- Componentes: El Propietario del Producto puede identificar qué componentes técnicos estarán involucrados en la implementación de la historia. Esto es útil cuando tienes varios equipos Scrum, por ejemplo un equipo de backoffice y otro equipo de cliente, y quieres que sea fácil para cada equipo saber a qué historias deben dedicarse. Por ejemplo “base de datos, servidor, cliente”.

- Solicitante: El propietario del producto puede querer mantener un historial acerca de qué cliente o persona interesada pidió originalmente la historia, para poder así ofrecerle información actualizada sobre el progreso de la misma.

- Bug tracking ID: Si se tiene un sistema de bug tracking (seguimiento de errores), es útil mantener un historial de cualquier correspondencia directa entre una historia y uno o más errores reportados.

Ejemplo del product Backlog en formato Excel:

16

Sprint backlog.

El sprint backlog es la lista que descompone las funcionalidades del product backlog en las tareas necesarias para construir un incremento: una parte completa y operativa del producto. En el sprint backlog se asigna a cada tarea la persona que la va a llevar a cabo, y se indica el tiempo de trabajo que se estima, aún falta para terminarla.

Es útil porque descompone el proyecto en tareas de tamaño adecuado para determinar el avance a diario; e identificar riesgos y problemas sin necesidad de procesos complejos de gestión. Es también una herramienta de soporte para la comunicación directa del equipo.

Las tareas se dividen en horas (en un rango de 4 a 16 horas), ninguna tarea deberá tener una duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

Hay tres opciones para el formato del Sprint backlog:

- Hoja de cálculo.

- Pizarra o pared física.

- Herramienta colaborativa o de gestión de proyectos.

Y sobre la que mejor se adecúa a las características del proyecto, oficina y equipo lo apropiado es diseñar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:

- Incluye la información: lista de tareas, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.

- Sólo incluye la información estrictamente necesaria.

- El medio y modelo elegido es la opción posible que más facilita la consulta y comunicación diaria y directa del equipo.

- Sirve de soporte para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea.

Los siguientes son ejemplos del sprint backlog, el primero y el segundo utiliza el formato de hoja de cálculo y el segundo es un ejemplo de cómo se vería la pizarra.

17

Formato 1.

Formato 2.

Formatos en hoja de cálculo, el segundo ejemplo corresponde al template sugerido por la

metodología SCRUM.

18

19

Formato de la pizarra de trabajo.

20

Burn down.

La burn down es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, se podrá ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Es un gráfico cartesiano que representa en el eje x los días laborables del sprint, y en el y la cantidad de esfuerzo estimada. En la reunión diaria cada miembro del equipo al referirse al trabajo que realizó ayer, y el que tiene previsto hacer hoy, actualiza en el sprint backlog si ha terminado alguna de las tareas en las que ha trabajado, o cuánto esfuerzo estima que les quedan. De esta forma al final de la reunión la columna del día del sprint backlog muestra el esfuerzo que según el equipo falta para terminar el sprint, y el equipo marca en el gráfico el punto que tiene como ordenada ese valor, y como abscisa la fecha del día.

21

La evolución ideal del sprint se representaría por la línea punteada en gris de la figura. La línea

naranja muestra la evolución real diaria. El recorrido sobre la diagonal es síntoma de problemas

o sub-estimación del sprint backlog. El recorrido bajo la diagonal es síntoma de sobre-

estimación del backlog.

Fuente:

Flexibilidad con Scrum, Principios de diseño e implantación de campos de Scrum. Juan Palacio.

http://es.wikipedia.org/wiki/Scrum

http://www.agile-software-development.com/2007/09/how-to-implement-scrum-in-10-easy-steps.html

http://es.debugmodeon.com/articulo/scrum-una-metodologia-agil-i

http://es.debugmodeon.com/articulo/scrum-una-metodologia-agil-ii

http://www.dosideas.com/wiki/Proceso_De_Desarrollo_Con_Scrum

http://www.navegapolis.net/content/view/622/59/

http://infoq.com/minibooks/scrum-xp-fromthetrenches

22

Conclusiones:

Scrum es una metodología ágil de administración mientras que XP es una metodología ágil de ingeniería. Por ejemplo, si lo que se quiere es tener una visión clara de lo que se quiere lograr, un compromiso de negocio, colaboración en equipo, un proceso claro para priorizar, etc. Scrum es la opción. Si lo que se quiere es simplificar la administración de requerimientos y mejorar la calidad del producto, XP es buena opción.

Ambas metodologías, son totalmente complementarias, ya que Scrum se enfoca a llevar a una buena administración de requerimientos y XP se adapta muy bien a un proyecto que requiere un código de calidad, probado y confiable.

Por lo tanto, se puede concluir que XP es un subconjunto de la metodología de Scrum, ya que contiene todas las ideas de administración de esta metodología (iteraciones pequeñas, estimaciones de tiempo confiables, comunicación, retroalimentación, etc.), pero también añade las prácticas que no se encuentran en Scrum, tales como pruebas unitarias, programación en pares, integración continúa, refactorización del código, etc.

Una manera en la que ambas metodologías pueden usarse en conjunto es el iniciar las iteraciones con Scrum y entonces añadir prácticas de XP para incrementar los beneficios de tener un producto funcional al final de cada una de las iteraciones.

23