Universidad Nacional del Centro de la
Provincia de Buenos Aires
Facultad de Ciencias Exactas
Un mundo virtual para la planificación ágil
Trabajo Final de la Carrera de Ingeniería de Sistemas
Alumno
Laureano Ceschini
Director
Dr. Álvaro Soria
Co-Director
Dr. Marcelo Campo
1
Tabla de contenidos
Resumen ... 6
1. Introducción ... 8
1.1. Objetivos ... 9
1.2. Estructura de la tesis ... 12
2. Estado del arte ... 15
2.1. El Manifiesto Ágil ... 16
2.2. Ejemplos de metodologías ágiles ... 18
2.2.1. Extreme Programming (XP) ... 18
2.2.2. Crystal family ... 19
2.2.3. Dynamic Systems Development Method (DSDM) ... 19
2.2.4. Adaptive Software Development (ASD) ... 20
2.2.5. Feature Driven Development (FDD) ... 21
2.2.6. Lean Development (LD) ... 21
2.2.7. Scrum ... 22
2.2.7.1. Principios de Scrum ... 24
2.2.7.2. Requisitos para poder utilizar Scrum ... 25
2.2.7.3. Scrum distribuido ... 26
2.3. Planificación ágil distribuida ... 26
2.3.1. Planning Poker ... 27
2.3.2. Herramientas de Planning Poker distribuido ... 27
2.3.2.1. eConference3P ... 28
2.3.2.2. PlanningPoker.com ... 30
2.3.2.3. PointingPoker.com ... 31
2.3.2.4. Playscrummy.com ... 33
2.3.2.5. Agile Poker for JIRA ... 34
2.3.2.6. Resumen ... 35
3. SPADE: herramienta virtual para la planificación ágil en contextos distribuidos 39 3.1. Ejemplo conductor ... 41
3.2. Captura de requerimientos ... 41
3.3. Sesión de estimación con la técnica Planning Poker ... 44
3.3.1. Inicio de la sesión de Planning Poker ... 44
2
3.3.3. Selección de User Story a estimar ... 47
3.3.4. Rondas de estimación ... 50
3.3.4.1. Emisión de voto ... 50
3.3.4.2. Resultado de la votación ... 53
3.4. Definición del Sprint Backlog ... 56
3.5. Resumen ... 57
4. Diseño de SPADE ... 59
4.1. Arquitectura del sistema ... 59
4.2. Servidor ... 60
4.2.1. Definición de Zones en Smartfox ... 61
4.2.2. Desarrollo de Server-side extensions ... 62
4.2.3. Acceso a la base de datos ... 64
4.3. Cliente ... 65
4.3.1. Modelo de Scrum ... 66
4.3.2. Manager ... 68
4.3.3. HUD ... 69
4.3.4. Multiplayer ... 71
4.3.5. Chat ... 71
4.3.6. Mesa de Planning Poker ... 72
4.3.6.1. Transiciones de estados ... 74
4.4. Unión a una sala de proyecto ... 75
4.5. Invitación a una Meeting de Planning Poker ... 76
4.6. Comunicación de participantes en la mesa de Planning Poker ... 77
4.7. Sincronización de participantes en la mesa de Planning Poker ... 78
4.8. Resumen ... 79
5. Caso de estudio ... 81
5.1. Diseño del caso de estudio ... 81
5.2. Análisis de resultados obtenidos ... 87
5.2.1. Resultados de usabilidad ... 87
5.2.2. Resultados de calidad de trabajo ... 89
5.2.3. Resultados de proceso y coordinación ... 89
5.2.4. Resultados de fluidez del proceso de estimación ... 90
3
6. Conclusiones ... 93
6.1. Contribuciones ... 93
6.2. Limitaciones de la herramienta y trabajos futuros ... 94
BIBLIOGRAFÍA ... 96
Índice de Figuras
Figura 1.1 - Esquema conceptual de la propuesta ... 10Figura 2.1 - Ciclo de vida de las metodologías ágiles ... 15
Figura 2.2 - Manifiesto ágil ... 16
Figura 2.3 - Prácticas de XP ... 18
Figura 2.4 - Ciclo de vida de un proyecto XP ... 19
Figura 2.5 - Ciclo de vida de DSDM ... 20
Figura 2.6 - Flujo de Adaptive Software Development ... 20
Figura 2.7 - Ciclo de vida de Feature Driven Development ... 21
Figura 2.8 - Conjunto de prácticas de Lean Development ... 22
Figura 2.9 - Ciclo de vida de un proceso con la metodología Scrum ... 23
Figura 2.10 - Captura de pantalla de la herramienta eConference3P ... 28
Figura 2.11 - Captura de pantalla de la herramienta PlanningPoker.com... 30
Figura 2.12 - Captura de pantalla de la herramienta PointingPoker.com... 32
Figura 2.13 - Captura de pantalla de la herramienta PlayScrummy.com ... 33
Figura 2.14 - Captura de pantalla de la herramienta Agile Poker Plugin for JIRA ... 34
Figura 3.1 - Esquema conceptual del enfoque ... 39
Figura 3.2 - Captura de pantalla de reunión virtual con el Product Owner ... 42
Figura 3.3 - Descripción de la User Story capturada ... 42
Figura 3.4 - Interfaz de creación de User Stories ... 43
Figura 3.5 - Menú de inicio de reuniones virtuales ... 45
Figura 3.6 - Mesa de Planning Poker ... 46
Figura 3.7 - Interfaz de selección de mazo a utilizar ... 47
Figura 3.8 - Interfaz de selección de User Story a estimar ... 48
Figura 3.9 - User Story seleccionada para el proceso de estimación ... 48
Figura 3.10 - Interfaz de chat dentro de la sesión de Planning Poker ... 49
4
Figura 3.12 - Interfaz de histórico de estimaciones ... 51
Figura 3.13 - User Story consultada para estimar por analogía ... 52
Figura 3.14 - Votos emitidos en la mesa de Planning Poker ... 52
Figura 3.15 - Votación revelada por el Scrum Master ... 53
Figura 3.16 - Selección de nueva ronda... 54
Figura 3.17 - Definición del valor de estimación para la User Story ... 55
Figura 3.18 - Finalización de la sesión de Planning Poker ... 56
Figura 3.19 - Definición del nuevo Sprint Backlog ... 57
Figura 4.1 - Diagrama de alto nivel de la arquitectura de SPADE ... 60
Figura 4.2 - Pseudo-código: declaración de una Zona en SmartFox ... 61
Figura 4.3 - Pseudo-código: declaración de una Room en SmartFox ... 62
Figura 4.4 - Diagrama de clases de la extensión SPADEExtension ... 63
Figura 4.5 - Clase CrearUserStoryHandler ... 64
Figura 4.6 - Pseudo-código del método de inserción de una User Story ... 65
Figura 4.7 - Diagrama de alto nivel de la implementación del cliente ... 66
Figura 4.8 - Diagrama de descomposición del paquete ModeloScrum ... 67
Figura 4.9 - Diagrama de descomposición del paquete Manager ... 68
Figura 4.10 - Diagrama de descomposición del paquete HUD ... 69
Figura 4.11 - Captura de pantalla del HUD dentro de una sesión de Planning Poker ... 70
Figura 4.12 - Diagrama de descomposición del paquete Multiplayer ... 71
Figura 4.13 - Diagrama de descomposición del paquete Chat ... 72
Figura 4.14 - Diagrama de estados de una sesión de Planning Poker ... 73
Figura 4.15 - Diagrama de descomposición del paquete MesaPoker ... 73
Figura 4.16 - Diagrama de descomposición del paquete EstadoPP ... 75
Figura 4.17 - Unión a la oficina virtual ... 76
Figura 4.18 - Invitación a Meeting de Planning Poker ... 77
Figura 4.19 - Comunicación entre los participantes ... 78
Figura 4.20 - Sincronización de participantes en la mesa de Planning Poker ... 78
Figura 5.1 - Grado de usabilidad de la herramienta ... 88
Figura 5.2 - Opiniones sobre usar la herramienta nuevamente ... 88
Figura 5.3 - Opiniones sobre la calidad de solución obtenida con la herramienta ... 89
Figura 5.4 - Opiniones sobre la experiencia con el proceso ... 90
5
Índice de Tablas
Tabla 2.1 - Roles y Responsabilidades de Scrum ... 24
Tabla 2.2 - Tabla comparativa de los trabajos relacionados... 36
Tabla 4.1 - User Stories resultantes de la reunión con el Product Owner... 44
Tabla 5.1 - Requerimientos propuestos para el caso de estudio ... 82
6
Resumen
En los últimos años se ha manifestado una tendencia creciente hacia el desarrollo de software distribuido y la utilización de metodologías ágiles. Estas metodologías brindan una serie de ventajas con respecto al desarrollo de software de manera tradicional. Sin embargo, esas ventajas dependen de la correcta ejecución de las prácticas propuestas por los métodos, y de las condiciones del entorno, descriptas en los principios del manifiesto ágil. Al combinar el desarrollo distribuido con el desarrollo ágil surgen nuevos desafíos relacionados a la comunicación, coordinación y colaboración entre los miembros de los equipos. Esta combinación vuelve imperiosa la necesidad de contar con herramientas que den soporte a las prácticas ágiles, en contextos distribuidos.
Partiendo de esta problemática, en esta tesis se presenta a SPADE como herramienta para la planificación ágil distribuida. La herramienta permite que un equipo de desarrollo distribuido se reúna en una oficina virtual y desarrolle las actividades de planificación correspondientes a cada una de las distintas iteraciones. Dentro de la oficina, se da soporte para la edición colaborativa de los distintos artefactos requeridos por Scrum: definición de User Stories, conformación del Product Backlog, etc. Además, se incluye una mesa de Meetings donde el equipo se reúne para estimar nuevas User Stories utilizando la técnica Planning Poker.
7
8
1. Introducción
A partir de la expresión del manifiesto ágil en 2001 han surgido cambios relevantes en el campo de la ingeniería de software. Estos cambios no sólo han impactado en la investigación, sino también en la industria [1]. De hecho, los métodos ágiles para el desarrollo de software han cobrado un papel importante dado que están siendo cada vez más frecuentemente adoptados para llevar a cabo todo tipo de proyectos. Varias encuestas muestran esto [2, 3], resaltando una creciente tendencia por parte de las compañías a emplear los métodos ágiles como parte de sus estrategias para entregar el software de manera rápida, fácil e inteligente.
Hay varias razones por las que los métodos ágiles han sido elegidos por la industria. Entre estas razones se destaca la tasa de éxito que tienen los proyectos que siguen estos métodos (42%), siendo tres veces más alta que la de proyectos que siguen procesos de desarrollo tradicionales como el cascada (14%) [3]. Además, el uso de métodos ágiles en el desarrollo presenta potenciales mejoras en la productividad, la calidad y la satisfacción del cliente, especialmente cuando el contexto del proyecto se da en entornos cambiantes que requieren flexibilidad y exigen rapidez en los resultados [4].
Si bien los métodos ágiles son capaces de introducir dichas mejoras, es importante destacar que ellas dependen del correcto desempeño de las prácticas propuestas por el método. Es decir, estas prácticas se convierten en factores claves que influyen directamente en el éxito del proyecto. La planificación y la estimación son ejemplos de dichas prácticas, dado que permiten crear una estimación de los costos y la planificación que requiere un determinado proyecto. De esta manera, una correcta estimación y planificación contribuye directamente con una culminación exitosa del proyecto.
9
Es importante destacar que el desarrollo de software distribuido se ha convertido en algo habitual en los últimos años [9]. Desafortunadamente, las prácticas ágiles y las de desarrollo distribuido son tan diferentes que, cuando se combinan, las características ágiles exacerban los desafíos intrínsecos de los contextos distribuidos, generando nuevos desafíos. Estos desafíos tienen que ver con los efectos que produce la distancia física entre los miembros de los equipos distribuidos [10], los cuales dificultan la coordinación, el control, y la comunicación, que son fundamentales en todo proceso de desarrollo de software. De hecho, las relaciones personales y la comunicación directa son consideradas como los mejores recursos dentro un proyecto [11].
La combinación de las características de los métodos ágiles con las del desarrollo de software distribuido ha dado lugar a un creciente interés sobre nuevos enfoques experimentales [12]. Algunos sostienen que es necesario ajustar las prácticas ágiles convencionales cuando son aplicadas en contextos distribuidos. En contraste, otros sostienen que las prácticas deben ser esencialmente las mismas, pero que las herramientas que les dan soporte son las únicas responsables de proveer un efectivo desarrollo distribuido [5]. En particular, se sostiene que son necesarias nuevas herramientas que provean un mejor soporte a las comunicaciones y las prácticas ágiles como la estimación para poder afrontar los desafíos antes mencionados [13].
1.1. Objetivos
En este contexto, la idea principal de esta tesis se basó en proveer una herramienta que de soporte a la planificación ágil distribuida basada en la técnica de Planning Poker, dentro de un mundo virtual.
10
Figura 1.1 - Esquema conceptual de la propuesta
Cuando un Scrum Team va a llevar adelante un nuevo Sprint, debe realizar la captura de requerimientos, estructurarlos en forma de User Stories y estimarlos a fin de poder definir el Sprint Backlog. Para llevar a cabo estas tareas, SPADE provee las interfaces y mecanismos necesarios para dar soporte a una sesión de planificación distribuida, utilizando la técnica Planning Poker. Este soporte incluye facilidades para la comunicación de los miembros distribuidos del Scrum Team y la sincronización entre la actividad de sus miembros, entre otras características necesarias para brindar soporte a las prácticas ágiles en contextos distribuidos.
11
Una vez que no hay dudas sobre la User Story a estimar, el Scrum Master dará inicio a una ronda de votación. En esta etapa, cada miembro del equipo recibe un mazo completo de cartas que utilizará para emitir su voto. Luego, cada miembro estando físicamente distribuido analizará cuál es el tamaño que tiene la User Story (en Story Points) en su fuero íntimo, eligiendo la carta que representa su decisión y la jugará boca abajo en la mesa (4).
Cuando todos los desarrolladores hayan jugado su carta, es decir, emitido su voto, el Scrum Master procederá a revelar el resultado de la votación. Para esto, revelará de forma simultánea todas las cartas que los miembros del equipo presentaron anteriormente, y el resultado será expuesto a todos los participantes (5).
Dependiendo del resultado de la votación, el próximo paso puede dar lugar a tres casos diferentes. El primer caso surge cuando todos los desarrolladores votan el mismo valor, por lo que el proceso de estimación se concluye y ese único valor se convierte en el valor final de estimación de la User Story. Entonces, el Scrum Master dará por finalizada la estimación de la User Story actual, registrará el valor de esa estimación (7), y reiniciará el proceso con la próxima User Story (8).
El segundo caso surge si el resultado de la votación es mixto, es decir, no existe una tendencia clara hacia algún valor similar. En este caso, el Scrum Master habilitará un espacio de debate, sólo para los desarrolladores que hayan emitido votos correspondientes a valores extremos (respecto de los valores que hayan sido votados). En este punto, por turnos, cada desarrollador expondrá abiertamente el argumento por el cual eligió su valor. Una vez hecho esto, todos los desarrolladores podrán opinar respecto de los argumentos anteriormente expuestos. Cuando el debate haya concluido, el Scrum Master iniciará una nueva ronda de votación de la misma User Story (6). La estimación de esa User Story culmina cuando el valor propuesto por los miembros converge a un valor.
12
propuesto por el Scrum Master, este último iniciará una nueva ronda de votación de la misma User Story.
De esta manera, la propuesta apunta a mejorar el proceso de planificación y estimación ágil en contextos de desarrollo de software distribuidos. Las mejoras esperadas se pueden resumir en una mayor coordinación, motivación y comunicación por parte de los miembros de equipo. Por último, la propuesta apunta a ofrecer una herramienta que facilite la planificación ágil distribuida, así como su validación en un contexto de desarrollo de software real.
1.2. Estructura de la tesis
Hasta aquí se presentó un resumen del avance de los métodos agiles en el campo de la Ingeniería de Software. Además se presentaron las problemáticas que surgen en contexto del desarrollo de software ágil distribuido. Finalmente, se describió el objetivo del enfoque propuesto, que busca dar soporte a las practicas agiles distribuidas, en especial a la planificación distribuida.
En el capítulo 2 se introducen las metodologías agiles, poniendo especial atención en Scrum. Luego se describen conceptos relacionados con la planificación ágil y la técnica Planning Poker. Por último, se presenta el estado del arte en que se encuentra el desarrollo de herramientas de Planning Poker distribuido. Para ello, se expone un relevamiento de herramientas que permiten realizar estimaciones de User Stories con la mencionada técnica, junto a un análisis comparativo de dichas herramientas.
En el capítulo 3 se presenta la solución al enfoque propuesto desde un punto de vista abstracto. Al inicio del capítulo se presenta un ejemplo motivador, que sirve de guía para explicar la solución desarrollada. Luego, a lo largo del capítulo, se va detallando principalmente el funcionamiento de la herramienta y los aspectos tomados en cuenta, sin entrar en detalles técnicos.
13
En el capítulo 5 se expone un caso de estudio, junto con el análisis de los resultados obtenidos. Aquí se evalúa la factibilidad de la solución en un contexto de planificación ágil donde los miembros del equipo se encuentran en distintas ubicaciones físicas.
14
15
2. Estado del arte
Los métodos ágiles surgieron como una propuesta a los desafíos modernos del desarrollo de software, donde no es posible aplicar los métodos clásicos basados en el seguimiento riguroso de procesos. En febrero de 2001, tras una reunión en Utah-EEUU, nació el término “ágil” aplicado al desarrollo de software. En esta reunión participaron un grupo de
17 expertos de la industria del software, incluyendo algunos de los creadores de las metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente, respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación generada en cada una de las actividades desarrolladas.
Los métodos ágiles dan lugar a la creatividad y a la sensibilidad a los cambios de condiciones. Algunos de estos son más bien una colección de técnicas y actividades más que un proceso totalmente definido con roles, responsabilidades, productos, etc. En estos métodos se hace incapié en que el desarrollo de software es una actividad humana, enfatizando al individuo sobre el proceso.
El objetivo de los métodos ágiles es la entrega continua de software funcional y completamente testeado, mediante entregas pequeñas y periódicas. Para lograrlo, estos métodos se enfocan en la comunicación frecuente e informal, con reuniones diarias cara-a-cara. Además, proponen mantener una cooperación continua entre el cliente y el equipo de desarrollo, a comparación de simplemente negociar los términos y productos del proyecto. En la Figura 2.1 se puede apreciar el ciclo de vida de los métodos ágiles.
16
2.1. El Manifiesto Ágil
Los principios que resumen la filosofía ágil fueron plasmados en el Manifiesto Ágil1. Este documento fue confeccionado luego de la creación de The Agile Alliance, una organización sin fines de lucro dedicada a promover los principios y prácticas relacionadas con el desarrollo ágil de software. La Figura 2.2 resume los valores que dan soporte a los métodos ágiles.
Figura 2.2 - Manifiesto ágil
Enfatizar al individuo y a las interacciones del equipo de desarrollo sobre el
proceso y las herramientas. Las personas son el principal factor de éxito de un proyecto de software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que luego el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funcione, más que conseguir una buena documentación. La regla a seguir es “no producir documentación a menos que sea necesario de forma inmediata, para tomar una decisión importante”. Estos
documentos deben ser cortos y centrarse en lo fundamental.
La colaboración con el cliente, más que la negociación de un contrato. Se
propone que exista una interacción constante entre el cliente y el equipo de
1
17
desarrollo. Esta colaboración entre ambos será la que determine la marcha del proyecto y asegure su éxito.
Responder a los cambios, más que seguir estrictamente un plan. La capacidad para responder a los cambios que surjan a lo largo del proyecto –ya sea en los requerimientos, en la tecnología, en el equipo, etc.– resulta un factor que
determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Estos valores diferencian un proceso ágil de uno tradicional, y son los que inspiraron los doce principios del manifiesto. Estos principios son generales y resumen gran parte del espíritu ágil:
1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.
2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.
3. Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre las entregas.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
6. El diálogo cara-a-cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.
7. El software que funciona es la medida principal de progreso.
8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. 9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. 10. La simplicidad es esencial.
11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos organizados por sí mismos.
18
2.2. Ejemplos de metodologías ágiles
En esta sección se mencionan y detallan brevemente las metodologías ágiles más utilizadas, poniendo especial enfasis en Scrum -la metodología a la que se da soporte dentro de la herramienta propuesta en esta tesis-.
2.2.1. Extreme Programming (XP)
Extreme Programming fue creada para equipos de desarrollo pequeños y medianos, donde los requerimientos no están completamente definidos, cambian rápidamente o son demasiados críticos. Se diseñó teniendo en cuenta los problemas tradicionales respecto a plazos de entrega y satisfacción del cliente, tratando de mantener su confianza sobre el producto. Es una metodología centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software. Promueve el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores y por brindar un buen clima de trabajo. Además, se basa en la retroalimentación continua entre el cliente y el equipo de desarrollo, la comunicación fluida entre todos los participantes, y la simplicidad en las soluciones implementadas. La Figura 2.3 ilustra las prácticas correspondientes a XP.
Figura 2.3 - Prácticas de XP
19
prácticas significa que las dos prácticas se refuerzan entre sí. Si bien estas prácticas no son novedosas, el mérito de XP está en integrarlas de forma efectiva, complementandolas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo. Todas estas prácticas entran en juego, junto con los roles de los desarrolladores, quienes en definitiva las llevan a cabo en el ciclo de vida de XP. Un ciclo de vida de XP puede observarse en la Figura 2.4.
Figura 2.4 - Ciclo de vida de un proyecto XP
2.2.2. Crystal family
Crystal family se trata de un conjunto de metodologías para el desarrollo de software, caracterizadas por estar centradas en las personas que componen el equipo y en la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se debe invertir esfuerzo en mejorar su habilidad y destreza, así como también tener políticas de trabajo definidas en equipo. Estas políticas, dependerán del tamaño del equipo, estableciéndose una clasificación por colores. Por ejemplo, Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
2.2.3. Dynamic Systems Development Method (DSDM)
20
estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas etapas son iterativas, existiendo realimentación a todas las fases. En la Figura 2.5 se puede observar el ciclo de vida de esta metodología.
Figura 2.5 - Ciclo de vida de DSDM
2.2.4. Adaptive Software Development (ASD)
Adaptive Software Development fue impulsada por Jim Highsmith. Esta metodología se caracteriza principalmente por ser iterativa, orientada a los componentes de software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas, se inicia el proyecto y se planifican las características del software; en la segunda se desarrollan las características, y finalmente, en la tercera se revisa su calidad y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. ASD intenta lograr el menor rigor estrictamente necesario, ya que propone efectuar el menor control posible. La Figura 2.6 muestra el flujo de etapas en la metodología.
21
2.2.5. Feature Driven Development (FDD)
Feature Driven Development, impulsada por Jeff De Luca y Peter Coad, define un proceso iterativo que consta de cinco pasos, como se muestra en la Figura 2.7. En esta metodología, las iteraciones son cortas, llegando a durar hasta 2 semanas. Se focaliza en las fases de diseño e implementación del sistema, partiendo de una lista de características que debe reunir el software. Ademas, explota aspectos de calidad e incluye pequeños entregables tangibles, junto con un preciso control del progreso del proyecto.
Figura 2.7 - Ciclo de vida de Feature Driven Development
2.2.6. Lean Development (LD)
22
Figura 2.8 - Conjunto de prácticas de Lean Development
2.2.7. Scrum
23
Figura 2.9 - Ciclo de vida de un proceso con la metodología Scrum
Un proyecto basado en Scrum comienza con la gestación de la visión del sistema a ser desarrollado. Con la visión, se consigue un análisis a alto nivel del alcance general del sistema. Será la guía a lo largo de todo el proceso de desarrollo. Luego, se plantean cuáles son los requerimientos que se solicitaron para el sistema, ordenándose en una lista. Dicha lista es conocida como el Product Backlog, donde los ítems que contiene son priorizados y divididos en períodos de tiempos más breves, llamados Sprints. Cada lista perteneciente a un Sprint se conoce como Sprint Backlog.
24
Rol Responsabilidades
Product Owner Representa los intereses de cada uno de los stakeholders del proyecto. Mantiene actualizado el Product Backlog
Scrum Team
(equipo)
Responsable por el desarrollo de la funcionalidad del sistema. Los equipos son auto-manejados y auto-organizados, y son responsables de convertir, al finalizar la iteración, el conjunto de requerimientos del Sprint Backlog en un incremento del producto final. Los miembros del equipo son colectivamente responsables del éxito o fracaso de cada iteración y del proyecto como un todo.
Scrum Master Responsable de manejar el proceso de Scrum. Esto es, enseñar Scrum a cada uno de los miembros involucrados en el proyecto. Se encarga de inculcar la cultura, principios, valores y reglas de Scrum. También es un facilitador de impedimentos o de problemas surgidos debido la falta de comprensión del proceso y sus reglas.
Tabla 2.1 - Roles y Responsabilidades de Scrum
Una vez que se decidió lo que se va a realizar para el siguiente Sprint, el equipo comienza a desarrollar el Sprint Backlog, con las tareas a cumplir para ese Sprint. El resultado es una porción de sistema con funcionalidad testeada que incrementa la funcionalidad total del mismo. Las tareas deberían ser divididas en sub-tareas de modo que cada una lleve de 4 a 16 horas para ser finalizadas.
Finalizado el Sprint, el equipo presenta sus resultados a los stakeholders. Esta presentación es la que permite inspeccionar el desarrollo de la funcionalidad y realizar distintos ajustes en el proyecto.
2.2.7.1. Principios de Scrum
Scrum se basa en los siguientes principios, los cuales se apoyan unos a otros y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos:
El desarrollo incremental de los requisitos del proyecto en bloques temporales
25
La priorización de los requerimientos según el valor para el cliente y el costo de desarrollo en cada iteración.
El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido. Esto permite que el cliente pueda tomar decisiones en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.
La potenciación del equipo, el cual se compromete a entregar los requerimientos y para ello se le otorga la autoridad necesaria para auto-organizar su trabajo.
La sistematización de la colaboración y la comunicación tanto entre el equipo y con el cliente.
El timeboxing (es decir, la fijación de un tiempo máximo) de las actividades del proyecto, para forzar la toma de decisiones y conseguir resultados.
2.2.7.2. Requisitos para poder utilizar Scrum
Para poder aplicar Scrum en el desarrollo de un proyecto, es necesario cumplir con una serie de requisitos. Estos requisitos incluyen:
Una cultura de empresa basada en el trabajo en equipo, delegación, creatividad y mejora continua.
Compromiso del cliente en la dirección del proyecto y disponibilidad para poder colaborar.
Compromiso de la dirección de la organización para resolver problemas endémicos y realizar cambios organizativos, formando equipos auto-gestionados y multidisciplinarios.
Compromiso conjunto y colaboración de los miembros del equipo.
Relación entre el proveedor y el cliente basada en la obtención del beneficio mutuo, colaboración y transparencia.
Facilidad para realizar cambios en el proyecto.
Tamaño de cada equipo entre 5 y 9 personas, con técnicas de colaboración entre equipos que trabajan en el mismo proyecto.
Equipo trabajando en un mismo espacio físico para maximizar la comunicación.
Dedicación del equipo a tiempo completo.
26
2.2.7.3. Scrum distribuido
Uno de los requisitos para la utilización de Scrum es que el equipo trabaje en el mismo espacio físico, esto resulta una limitación cuando se trata de desarrollo en contextos distribuidos. Al utilizar Scrum en un contexto distribuido, un equipo de desarrollo debe apoyarse en un conjunto de herramientas que permitan reducir el impacto de la distancia. En particular, en esta tesis nos enfocamos en las actividades involucradas en la planificación distribuida, y en el soporte software para dichas actividades.
2.3. Planificación ágil distribuida
Cuando un equipo de desarrollo ágil utiliza Scrum y va a comenzar una nueva iteración, debe realizar la planificación del Sprint, y por ende, estimar User Stories. Una User Story es una breve descripción de funcionalidad desde el punto de vista de un usuario o cliente de un sistema. Las User Stories se escriben de manera libre y no existe una sintaxis que resulte mandatoria. Sin embargo, son generalmente formuladas utilizando la siguiente plantilla: “Como <rol> quisiera <objetivo/deseo>, de manera que <beneficio>".
En el desarrollo ágil, la estimación de User Stories no está a cargo de un solo desarrollador, sino que se realiza en forma colaborativa por una parte o la totalidad del equipo de desarrollo, incluyendo aquellos desarrolladores que realizarán la implementación. El tamaño de una User Story puede ser estimado en Story Points o en días ideales. Los Story Points son una unidad de medida relativa, utilizada para estimar el tamaño de una User Story combinando el esfuerzo, complejidad y riesgo involucrado en su desarrollo. En cambio, los días ideales son utilizados para evaluar el tamaño de la User Story en términos de la cantidad de tiempo que llevaría desarrollarla completamente. Para lograr realizar la estimación colaborativa los grupos de desarrollo ágil se basan principalmente en tres técnicas: opinión de expertos, analogía y desagregación.
27
de expertos y analogía. Consiste en particionar una User Story que describe características de forma genérica en otras, cuya descripción sea más puntual, facilitando el proceso de estimación.
2.3.1. Planning Poker
Las tres técnicas anteriormente descriptas pueden combinarse de manera efectiva, como lo hace la técnica llamada Planning Poker [18]. En ella, se le asigna un mazo de cartas a cada miembro del equipo, conformado por todos los valores válidos para indicar una estimación. Luego, una User Story es discutida y cada miembro selecciona la carta que, a su juicio, representa el tamaño de dicha Story. Posteriormente, todas las cartas se muestran al mismo tiempo y los resultados son discutidos, dando lugar incluso a nuevas rondas de votación, hasta llegar a un acuerdo en la estimación alcanzada.
Esta técnica resulta efectiva por al menos por dos razones. La primera es que une la opinión de expertos en distintas disciplinas, cuya estimación tiende a ser más precisa que la que se logra individualmente [8]. La segunda es que fomenta el debate organizado, donde los miembros del equipo deben justificar sus votos, lo que también se ha hallado que conduce a mejores resultados, especialmente en casos de gran incertidumbre y falta de información [9]. Además, la técnica permite evitar que la opinión de un miembro condicione la de otro que aún no haya formado la suya de manera independiente [15].
2.3.2. Herramientas de Planning Poker distribuido
28
En esta sección se realiza un relevamiento de las herramientas disponibles para dar soporte a la estimación de User Stories mediante la técnica de Planning Poker, en contextos distribuidos. Para cada una de ellas se explica brevemente su funcionamiento, incluyendo capturas de pantalla. Por último, se realiza un análisis de las características y limitaciones que presenta cada una de ellas. Este análisis permite revelar aspectos a mejorar que son incluidos en nuestro enfoque.
2.3.2.1. eConference3P
eConference3P es una herramienta bastante completa para la estimación de User Stories con la técnica de Planning Poker. Puede ser ejecutada en modo stand-alone o incorporada como plugin en entornos de desarrollo como Eclipse. En la Figura 2.10 se muestra una captura de pantalla de la herramienta.
29
El área de trabajo de la herramienta está divida en 5 secciones:
Message Board: el área donde se presentan los mensajes correspondientes a las
discusiones que hayan surgido respecto del proceso de estimación. Cada conjunto de mensajes se almacena relacionado a la User Story en estimación en ese momento.
Decisions place: contiene notas y decisiones relevantes, cargadas por miembros
que fueron designadas por el Product Owner para realizar la tarea.
Backlog: permite empezar y terminar la sesión, así como importar y exportar US,
que son listadas junto a su valor de estimación.
Card deck: panel en el que se muestra el mazo a partir del cual cada miembro
puede emitir su voto.
Presence: panel que muestra a los miembros que están participando en la sesión,
incluyendo su rol, y sus permisos: estimar, registrar decisiones y utilizar el chat.
eConference3P tiene un diseño orientado a garantizar un buen orden del proceso de estimación, esto es reflejado en la organización de la interfaz, así como también en la definición de distintos roles para los participantes y distintos permisos. Incluye la diferenciación entre Product Owner y los desarrolladores (developer, analyst, tester, etc.). En cuanto a permisos, define tres, los cuales son administrados por el Product Owner (que actúa como el moderador de la sesión):
El permiso para estimar, que es concedido a los desarrolladores cuando el
moderador da lugar a la votación de una User Story.
El permiso para utilizar el chat, que es utilizado por el Product Owner para
garantizar una buena organización en los debates que transcurren durante el proceso de estimación.
30
En cuanto a la carga de User Stories, la herramienta posee gran flexibilidad ya que permite importarlas desde entornos de desarrollo colaborativos como Google Code, Assembla, Github, Trac y JIRA. Además, permite la edición colaborativa de User Stories, ya sea antes de comenzar el proceso de estimación o durante la sesión de estimación.
Una de las características a resaltar es que la herramienta brinda mecanismos de comunicación para los participantes de la sesión, tanto por texto como por audio. Para esto se requiere poseer una cuenta en Gmail o Skype, eliminando el requerimiento de instalar un servidor. Esto se puede ver como una ventaja, pero a la vez constituye una desventaja: el funcionamiento de la herramienta queda ligado a la disponibilidad y cambios en servicios de terceros. Hoy en día la disponibilidad de dichos servicios se pueda dar por sentado, pero los continuos cambios en sus tecnologías provocan que la herramienta deba ser adaptada continuamente para seguir funcionando.
2.3.2.2. PlanningPoker.com
PlanningPoker.com es una herramienta web que da soporte a algunos de los mecanismos necesarios para realizar una sesión de Planning Poker distribuido. Entre ellos se incluye: la posibilidad de conformar el Product Backlog, la administración de roles y los mecanismos para llevar a cabo las estimaciones. En la Figura 2.11 se muestra una captura de pantalla de la interfaz de estimaciones.
31
En cuanto a la conformación del Product Backlog, la herramienta permite realizar la carga de User Stories en forma manual o importándolas desde un archivo (con extensión .csv). Solo permite importarlas antes de iniciar la sesión de Planning Poker, aunque la carga o modificación manual puede ser realizada antes o durante la sesión de estimación. Sin embargo, la herramienta no permite la edición colaborativa de User Stories en ningún momento.
La herramienta define tres tipos de participantes: el moderador de la sesión (que puede incluirse como votante o no), los votantes y los espectadores. El moderador es el único que tiene permiso de definir del tipo de mazo a utilizar, establecer temporizadores para los debates, pre-cargar las User Stories y coordinar el flujo de la sesión de estimación.
En lo que respecta a mazos utilizables, la herramienta provee cierta variedad de mazos ya definidos: Fibonacci, Fibonacci modificada, T-Shirts y potencias de 2. Además, permite que el moderador defina una sucesión personalizado para ser utilizada como mazo.
Para poder utilizar la herramienta se requiere disponer de una cuenta registrada, la cual será utilizada para almacenar la información de las distintas sesiones que se hayan creado. Para cada sesión se almacenan las User Stories ingresadas, y su estimación, producto de la última votación que se haya realizado.
Por último, es importante resaltar que si bien brinda lo necesario para poder llevar a cabo una sesión de Planning Poker, varios de sus mecanismos resultan un tanto rígidos. Además, no cuenta con ningún tipo de soporte para comunicar a los participantes, lo cual es fundamental cuando se trata de un contexto distribuido.
2.3.2.3. PointingPoker.com
32
Figura 2.12 - Captura de pantalla de la herramienta PointingPoker.com
Como se puede ver en la captura de pantalla, la herramienta no brinda ningún mecanismo para la conformación del Product Backlog. En cambio, sólo provee un cuadro de texto donde se puede detallar la descripción de la User Story a estimar. Esta descripción puede ser editada de forma colaborativa entre los participantes, aunque el mecanismo que provee no resulta eficiente.
33
La herramienta se puede utilizar sin necesidad de disponer de una cuenta, lo que resulta en una mayor facilidad de acceso. Pero por otro lado es una desventaja, ya que no existe ningún tipo de persistencia de información.
A pesar de su diseño minimalista, la herramienta cuenta con una función que resulta importante: mantiene un historial de las votaciones. Mientras dure la sesión se puede consultar el historial de los votos que se han emitidos. Esto resulta muy útil en aquellos casos en que el moderador limpia la votación justo antes de que otro participante alcance a exponer una duda.
2.3.2.4. Playscrummy.com
PlayScrummy.com es una herramienta web básica que solo provee el mecanismo de cartas correspondiente al proceso de Planning Poker. En la Figura 2.13 se muestra una captura de pantalla de la herramienta.
34
PlayScrummy.com solo simula una mesa donde jugar las cartas, por lo tanto no incluye ningún mecanismo para conformar el Product Backlog, ni tampoco para exhibir o editar la descripción de una User Story.
En cuanto a la definición de roles, la única distinción entre los participantes es respecto de los que votan y los que se unen como espectadores. No define ningún tipo de separación de privilegios, cualquier participante puede revelar o resetear la votación.
2.3.2.5. Agile Poker for JIRA
Agile Poker for JIRA es un plugin para JIRA que permite llevar a cabo sesiones de Planning Poker. Es una herramienta que, integrada con el resto de las características de JIRA, resulta muy completa. La Figura 2.14 muestra una captura de pantalla de la herramienta.
Figura 2.14 - Captura de pantalla de la herramienta Agile Poker Plugin for JIRA
El area de trabajo esta divida en 5 paneles que agrupan distintas funciones:
35
Panel de User Story: este panel es propio de la versión base de JIRA, en él los participantes pueden consultar y editar la información relacionada a la User Story seleccionada.
Panel de votación: en este panel se presentan los valores válidos para emitir el
voto.
Panel de chat: este panel es utilizado por los participantes para comunicarse
mediante envió de mensajes.
Panel de participantes: este panel informa el estado de cada uno de los
participantes. Dicho estado tiene tres valores posibles: "Votando", "Ausente", "Votó".
Dentro de la herramienta, el miembro establecido como administrador del proyecto será implícitamente designado como moderador. Este será el único que pueda personalizar el mazo a utilizar, y además, tener acceso a los controles de coordinación de la sesión.
Una de las características más interesantes de la herramienta es la implementación del mecanismo de chat. Los participantes se comunican por mensajes de texto, los cuales son automáticamente adjuntados a la User Story estimada. Esto resulta muy útil a la hora de querer consultar lo que se expuso durante la reunión, ya sea en medio de la sesión de estimación o posteriormente durante el desarrollo de la User Story.
2.3.2.6. Resumen
Hasta aquí se han presentado las herramientas relevadas que dan soporte a sesiones de estimación distribuidas utilizando la técnica de Planning Poker. En la Tabla 2.2 se muestra un cuadro comparativo de las mismas considerando los siguientes criterios:
1. Backlog: indica si la herramienta cuenta con soporte para definir un Backlog persistente, integrado, que pueda ser accedido fuera de la sesión de estimación. 2. Comunicación: indica si la herramienta cuenta con funciones para permitir que
los participantes puedan comunicarse sin tener que recurrir a herramientas externas.
36
4. Independencia: indica si la herramienta depende de servicios de terceros para realizar su función.
5. Instalación: indica si se necesita instalar o configurar la herramienta antes de utilizarla o si puede ser directamente accedida, por ejemplo desde el navegador. 6. Espacio: indica si la herramienta provee interfaces planas en 2D o hace uso del
3D. eConferen ce3P Planning Poker.com Pointing Poker.com Playscrum my.com Agile Poker for JIRA
Backlog Sí Sí No No Sí
Comunicación Sí No No No Sí
Logging Sí Sí No No Sí
Independencia No Sí Sí Sí Sí
Instalación Sí No No No Sí
Espacio 2D 2D 2D 2D 2D
Tabla 2.2 - Tabla comparativa de los trabajos relacionados
La herramienta eConference3P resulta ser una herramienta muy completa en cuanto al soporte para sesiones de Planning Poker distribuido. Sin embargo, se presentaron problemas para poder unirse a la sesión virtual debido a la dependencia de servicios de terceros.
PlanningPoker.com cubre los mecanismos esenciales para una sesión de Planning Poker, se puede gestionar el Product Backlog, personalizar los mazos a utilizar, y es flexible a la hora de seleccionar que User Story estimar. La principal desventaja de esta herramienta es que carece de soporte para la comunicación de los participantes.
37
Agile Poker for JIRA es un plugin que cubre los mecanismos necesarios para poder estimar colaborativamente con la técnica de Planning Poker. Si bien depende de la integración con JIRA, es una herramienta de la misma empresa. Esto hace que se eviten los problemas que surgen en eConference3P.
38
39
3. SPADE:
herramienta
virtual
para
la
planificación ágil en contextos distribuidos
En los últimos años, se ha manifestado una tendencia creciente hacia el desarrollo ágil distribuido [20,21]. Esto ha generado la necesidad de herramientas que faciliten las tareas involucradas en los contextos distribuidos. No sólo se requiere que estas herramientas brinden soporte a los principios fundamentales de los métodos agiles, sino que además hagan frente a los desafíos que emergen al estar trabajando en dichos contextos. Es decir, el foco de dichas herramientas no sólo deberá estar centrado en la edición colaborativa de artefactos, sino también en mecanismos que minimicen el efecto de la distancia entre los miembros del equipo. Para ello, resulta fundamental la inclusión de mecanismos de comunicación que cubran tanto la comunicación verbal como la no-verbal, y la inclusión de características que permitan fortalecer el compromiso de los miembros del equipo de desarrollo. En este contexto, con el objetivo de brindar soporte para las prácticas de Scrum y, además, atacar los desafíos propios de los contextos distribuidos,
40
se propone a SPADE (por Sprint Planning Assistant for Distributed Environment, en español Asistente para la Planificación de Sprints en Entornos Distribuidos). SPADE es una herramienta integrada dentro de Virtual Scrum, que da soporte a un equipo de desarrollo para realizar la planificación distribuida de un proyecto basado en Scrum. La Figura 3.1 muestra el esquema conceptual del enfoque.
En este enfoque, tanto el Scrum Team como el Product Owner se encuentran distribuidos geográficamente, por lo que la reunión de planificación se realiza en la oficina virtual. Ésta pretende simular un entorno físico de desarrollo ágil basado en Scrum, compuesto principalmente por radiadores de información y una mesa de Meetings. Además, dentro de la oficina, cada participante es representado a través de un avatar 3D. Dicho avatar refleja la posición del participante, que no sólo permite ganar en términos de inmersión, sino que también actúa como un indicador indirecto de la actividad que el participante está realizando dentro de la oficina. Esto último ayuda a acortar la brecha de comunicación no-verbal propia de los contextos distribuidos.
Como paso inicial, el Product Owner y el Scrum Team deben reunirse en la oficina virtual. Para esto, cada uno de los participantes –físicamente distribuidos– se une a la oficina virtual desde su computadora.
Una vez reunidos, la primera etapa de nuestro enfoque consiste en realizar la captura de nuevos requerimientos. En esta etapa, el equipo dialoga con el Product Owner sobre las nuevas características a implementar en la iteración. Esto se logra a través del intercambio de mensajes de texto, utilizando el chat integrado en la herramienta. Luego, el equipo toma los requerimientos capturados, los escribe en formato de User Story y actualiza el Product Backlog. Para ello, la herramienta dispone de un panel 3D que actúa como visor del Product Backlog, donde el equipo puede consultar, modificar o agregar nuevas User Stories.
41
herramienta provee las interfaces gráficas necesarias para que el equipo se pueda comunicar y pueda acceder al detalle de estimaciones anteriores.
Por último, habiendo estimado las nuevas User Stories, el equipo de desarrollo puede definir –junto al Product Owner– cuáles de ellas serán incluidas para el desarrollo del nuevo Sprint. Para esta última etapa, se dispone de un panel 3D en otra de las paredes, que actúa como visor del Sprint Backlog. En él, los desarrolladores pueden consultar, crear y modificar la conformación de los distintos Sprint Backlogs.
En resumen, el enfoque propuesto facilita la planificación ágil distribuida de los distintos Sprints de un proyecto. El empleo de la herramienta SPADE permite llevar a cabo sesiones de Planning Poker distribuido dentro de un mundo virtual. Las siguientes secciones exponen en mayor detalle cada uno de los pasos seguidos en el proceso, a través de un ejemplo conductor.
3.1. Ejemplo conductor
El ejemplo conductor se basa en el caso de un equipo de desarrollo ágil distribuido, que utiliza Scrum, y en el pasado se ha encargado de incorporar funcionalidad a VirtualScrum. El equipo planifica las iteraciones utilizando el esquema Commitment-based Planning, que consiste en acordar –junto al Product Owner– las User Stories que el equipo se compromete a desarrollar durante el Sprint.
El equipo de desarrollo realizará una nueva iteración para incorporar funcionalidad a VirtualScrum. Para ello deberán realizar la captura de requerimientos, luego definir las nuevas User Stories resultantes, y finalmente, estimarlas para poder conformar el Sprint Backlog y comenzar el desarrollo.
3.2. Captura de requerimientos
En esta primera etapa, el Scrum Team realiza la actualización del Product Backlog. Para ello, se reúnen con el Product Owner y capturan los nuevos requerimientos. Como todos los participantes se encuentran distribuidos geográficamente, la reunión se realiza en la oficina virtual. Todos los miembros del Scrum Team –junto al Product Owner– se reúnen
42
Owner, mediante la utilización del chat. En la Figura 3.2 se muestra una captura de pantalla de la reunión virtual.
Figura 3.2 - Captura de pantalla de reunión virtual con el Product Owner
Luego de la reunión, el grupo de desarrollo formula una User Story con las características requeridas por el Product Owner, la cual se detalla a continuación en la Figura 3.3.
User Story
Título Gestión de panel de métricas
Descripción Como usuario de VirtualScrum quisiera poder gestionar un panel de métricas del proyecto, de manera que pueda supervisar su avance.
Figura 3.3 - Descripción de la User Story capturada
43
sola. Como consecuencia, su estimación se dificulta, ya que hay que considerar varias características al mismo tiempo. Además, las ambigüedades propias de las épicas aumentan el margen de error en las estimaciones, lo cual no resulta un efecto favorable. Por lo tanto, los miembros del equipo aplican la técnica de desagregación, es decir, particionan la épica en varias User Stories de menor tamaño. El resultado de dicho proceso se refleja en User Stories escritas en una granularidad más fina, con límites mejor definidos, lo que permite alcanzar una mayor precisión en la estimación. En la Figura 3.4 se ilustra la carga de User Stories dentro de SPADE para conformar el Product Backlog.
Figura 3.4 - Interfaz de creación de User Stories
El agregado al Product Backlog se detalla en la siguiente tabla:
Product Backlog
ID - Título Descripción
98 - Panel de métricas
44 99 - Transición
de métricas
Como usuario de VirtualScrum quisiera disponer de botones de selección de la métrica que deseo visualizar en el panel, de manera que me permita concentrarme en una métrica a la vez.
100 - Selección de
desarrollador (métricas)
Como usuario de VirtualScrum quisiera poder seleccionar el desarrollador sobre el cual deseo visualizar la métrica, de manera que me permita analizar el desempeño de cada integrante del grupo.
101 - Filtro de rangos
(métrica)
Como usuario de VirtualScrum quisiera poder filtrar el rango de valores sobre el que deseo visualizar una métrica, de manera que me permita realizar un análisis más personalizado.
Tabla 3.1 - User Stories resultantes de la reunión con el Product Owner
3.3. Sesión de estimación con la técnica Planning Poker
Habiendo actualizado el Product Backlog, el próximo paso a realizar es tomar las User Stories aún sin estimar, y estimarlas. A partir del resultado de este proceso, el equipo podrá definir cuáles son las User Stories que se incluirán en el Sprint Backlog, y que por tanto, se comprometerán a entregar al finalizar el Sprint.
Para realizar la estimación colaborativa de las User Stories mencionadas, el equipo utiliza
SPADE. En este momento, el Scrum Team lleva a cabo una sesión de Planning Poker, la cual se divide en cuatro etapas: Inicio de la sesión, Selección de mazo, Selección de User Story y Ronda de votación. En las siguientes sub-secciones se presenta el detalle de las mismas.
3.3.1. Inicio de la sesión de Planning Poker
Dentro de una sesión de Planning Poker se destacan diferentes roles dentro de los participantes. Se diferencian los desarrolladores (Scrum Members), el moderador de la sesión (Scrum Master) que será el encargado de coordinar el desarrollo de toda la sesión, y el Product Owner que será quien aclare detalles de requerimientos en caso de ser necesario.
45
Scrum Master crea una nueva sesión desde el panel de Meetings e invita a todo el equipo a unirse a ella. Esta actividad solo puede ser iniciada por el Scrum Master, ya que es el único miembro del equipo con ese permiso. En la Figura 3.5 se muestra una captura de pantalla de la interfaz para iniciar una sesión de Planning Poker.
Figura 3.5 - Menú de inicio de reuniones virtuales
46
Figura 3.6 - Mesa de Planning Poker
3.3.2. Selección de la mazo
Una vez que todos los participantes se han unido a la mesa, el Scrum Master comienza con las actividades de estimación. Como primer paso, debe seleccionar el mazo a utilizar para el proceso de estimación.
Los mazos de estimación pueden pertenecen a sucesiones numéricas (como por ejemplo la sucesión de Fibonacci o Fibonacci modificada), o también a otras formas de diferenciar tamaños (por ejemplo el uso de talles de remeras, en inglés denominado mazo “T-Shirts”).
La elección del mazo a utilizar depende de las preferencias del Scrum Team. En este caso, el grupo de desarrollo estima con el mazo correspondiente a la sucesión de Fibonacci modificada. Ésta sucesión está compuesta por los siguientes valores: 0,½,1,2,3,5,8,13,20,40,100; además de dos comodines: “Infinito” utilizado para indicar que
47
de la sucesión presenta una característica importante: a medida que los números aumentan, aumenta también la distancia entre ellos. Esto resulta útil para reflejar que a mayor valor numérico, mayor es la incertidumbre que se tiene con respecto al esfuerzo requerido para implementar la User Story [7]. Sin embargo, puede suceder que un grupo inexperto tienda a estimar con los valores centrales de la sucesión, dando como resultado estimaciones pequeñas en contraste con el uso de una sucesión lineal [17].
Cabe aclarar que la selección de mazo se realiza una única vez para toda la sesión de Planning Poker. En la Figura 3.7 se muestra una captura de pantalla de la selección de mazo.
Figura 3.7 - Interfaz de selección de mazo a utilizar
3.3.3. Selección de User Story a estimar
48
contenidas en el Product Backlog y que aún no han sido estimadas. En la Figura 3.8 se muestra la interfaz para seleccionar la User Story a estimar, en ella se puede observar que sólo han sido incluidas las User Stories resultantes de la nueva captura de requerimientos, ya que son las únicas sin estimar.
Figura 3.8 - Interfaz de selección de User Story a estimar
En este caso el Scrum Master selecciona la siguiente User Story:
User Story
ID 99
Título Transición de métricas
Descripción Como usuario de VirtualScrum quisiera disponer de botones de selección de la métrica que deseo visualizar en el panel, de manera que me permita concentrarme en una métrica a la vez.
49
Antes de comenzar con la estimación de la User Story seleccionada, es importante que el equipo cuente con un buen entendimiento de lo que ella implica. Por lo tanto, se abre un espacio de debate donde el Scrum Team –utilizando el chat– formula preguntas al Product Owner y resuelve las dudas existentes. Lo expuesto durante el debate será registrado automáticamente para futura referencia. De esta manera, cada miembro del Scrum Team puede consultarlo, ya sea durante la sesión de estimación (para aplicar la técnica de estimación por analogía) como también al momento de desarrollar. Cabe mencionar que cada participante recibe la descripción de la User Story por chat, de forma automática, cada vez que el Scrum Master selecciona una nueva User Story. En la Figura 3.10 se muestra la interfaz del chat, que ilustra una de las conversiones ocurridas durante el proceso de estimación.
Figura 3.10 - Interfaz de chat dentro de la sesión de Planning Poker
50
3.3.4. Rondas de estimación
Habiendo evacuado las dudas sobre la User Story seleccionada, el grupo puede iniciar la ronda de votación. Para emitir su voto, cada Scrum Members tiene acceso a un mazo de cartas –que dependerá de la sucesión que haya elegido previamente el Scrum Master– en
este caso correspondiente a la sucesión de Fibonacci Modificada, como se muestra en la Figura 3.11.
Figura 3.11 - Interfaz de emisión de voto
3.3.4.1. Emisión de voto
51
su valor de estimación y lo debatido sobre ella. La Figura 3.12 muestra una captura de pantalla del uso de dicha interfaz.
Figura 3.12 - Interfaz de histórico de estimaciones
En este caso, Juan (diseñador 3D) analiza que, desde su experiencia, habrá que adaptar el diseño 3D de botones ya existentes, pero que esto resulta bastante directo. Además, Juan utiliza la interfaz de estimaciones anteriores para consultar la estimación de User Stories de similares características. En particular, consulta la User Story descripta en la Figura 3.13.
User Story
ID 85
Título Botón nuevas User Stories
52
que pueda reflejar dentro de la oficina virtual los requerimientos capturados.
Figura 3.13 - User Story consultada para estimar por analogía
En dicha User Story, se incorporó funcionalidad mediante botones 3D. Juan analiza, entonces, que la User Story 85 (estimada con un valor de 3) comparte características similares a la User Story en votación. Por lo tanto, considerando que los cambios involucrados resultan bastante directos (estimación por opinión experta) y que además, se parece a la User Story 85 (estimación por analogía), se decide por un voto de valor 3.
De la misma manera, el resto de los participantes va emitiendo su voto, el cual se va reflejando en la mesa: habrá una carta boca abajo frente a cada participante que haya emitido su voto. En la Figura 3.14 se muestra una captura de pantalla del momento en que todo el Scrum Team ha emitido su voto.
53
3.3.4.2. Resultado de la votación
A continuación, se procede a revelar el resultado de la votación y tomar acciones dependiendo su resultado. En esta etapa, el Scrum Master espera que todo el equipo emita su voto y luego revela el resultado de la ronda. En este caso la votación no converge por presencia de valores extremos: hay tres votos con valor 5 –conformando mayoría–, un voto con 3 y un voto con 8 (como se muestra en la Figura 3.15). En este
contexto, el Scrum Master pide la justificación del voto a los participantes que votaron los valores extremos: Juan (3) y Ezequiel (8).
Figura 3.15 - Votación revelada por el Scrum Master
54
animaciones. Esto hace a Ezequiel recordar sobre esa guía, y estar de acuerdo con el argumento de Juan. Luego, el resto del equipo también manifiesta estar de acuerdo con lo expuesto.
Finalizado el debate, el Scrum Master dispone de una interfaz donde puede decidir el curso de acción (como se muestra en la Figura 3.16). En este caso, como la votación no logró converger, el Scrum Master presiona el botón de nueva ronda.
Figura 3.16 - Selección de nueva ronda
En esta nueva ronda, los Scrum Members emitirán sus votos considerando lo debatido en la ronda anterior. Así, repitiendo el proceso ya descripto, se llega nuevamente a la etapa de resultados de la votación. En este caso los valores están cercanos a converger: todos han votado el valor 3, excepto Guillermo que votó nuevamente el valor 5. El Scrum Master –haciendo uso del chat– le pregunta a Guillermo si está de acuerdo con establecer la
55
3.17 se muestra una captura de pantalla donde el Scrum Master define el valor final de estimación de la User Story.
Figura 3.17 - Definición del valor de estimación para la User Story
56
Figura 3.18 - Finalización de la sesión de Planning Poker
3.4. Definición del Sprint Backlog
57
Figura 3.19 - Definición del nuevo Sprint Backlog
3.5. Resumen
A través del ejemplo conductor, se presentó el funcionamiento de SPADE, dando soporte a una reunión de Sprint Planning entre miembros de un equipo distribuido. El ejemplo muestra la sencillez con la que el equipo puede planificar un nuevo Sprint, partiendo desde la captura de requerimientos hasta la definición del Sprint Backlog. En este sentido,
58
59
4. Diseño de SPADE
En este capítulo se expone el desarrollo de la herramienta desde un punto técnico. En cuanto a la organización del mismo, en primer lugar se describe la arquitectura general del sistema. Para ello, se incluyen diagramas junto a una breve descripción de cada componente, siguiendo un enfoque top-down. Es decir, se parte desde la vista de más alto nivel y luego se va añadiendo más detalle sobre cada uno de los componentes. Concretamente, para este caso se utiliza la vista de módulos, que presenta la funcionalidad de un sistema mediante unidades estáticas que agrupan un conjunto de responsabilidades.
En segundo lugar, se describe el funcionamiento de la herramienta utilizando la vista de componentes y conectores. Esta vista muestra elementos del sistema en tiempo de ejecución. Cada una de las interacciones expuestas se detalla mediante diagramas de secuencia, acompañados de una breve descripción de los mismos.
4.1. Arquitectura del sistema
60
Figura 4.1 - Diagrama de alto nivel de la arquitectura de SPADE
4.2. Servidor
El servidor se encarga de brindar acceso seguro a los archivos almacenados y además, actúa como coordinador de la comunicación entre los clientes. Para la implementación del servidor se utilizan un conjunto de tecnologías que proveen los servicios requeridos por el cliente.
