El método Scrum. > Respuesta a los cambios, sobre cumplimiento estricto de un plan. Ciclo diario Scrum. Ciclo mensual. Sprint

Transcripción

1 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 54 (Management) El método Scrum crum es, actualmente, uno de los métodos S ágiles para desarrollo de software de mayor difusión en la industria, junto con Extreme Programming (XP). Su nombre proviene del rugby, deporte en el que un scrum es una jugada que permite reiniciar el juego luego de una falta accidental. La elección del nombre busca rescatar el principio de trabajo en equipo que se observa en un scrum de rugby: varios jugadores se toman de los hombros y se esfuerzan para lograr por sí solos y rápidamente un objetivo común, que consiste en adueñarse de la pelota y llevarla hacia delante. El creador de Scrum es Jeff Sutherland, uno de los 17 gurúes agilistas que se reunieron en el año 2001 para establecer los postulados del desarrollo de software ágil, y redactar y firmar el mítico Manifiesto Ágil. En el texto de dicho manifiesto se establecen los objetivos de las metodologías ágiles, entre los cuales se destaca la preferencia de algunos valores por sobre otros, por ejemplo: > Individuos e interacciones, sobre procesos y herramientas. > Software operativo, sobre documentación extensiva. > Colaboración con el cliente, sobre negociación de contratos. > Respuesta a los cambios, sobre cumplimiento estricto de un plan. En estos postulados se observa la intención de los agilistas de rebelarse contra los vicios típicos de los procesos tradicionales de desarrollo de software: planes que no se cumplen o que se extienden más allá de los plazos, documentación que exige demasiado trabajo de elaboración y no refleja la realidad del producto final, contratos que terminan perjudicando a una de las dos partes (desarrollador o cliente) o a ambas, entre otros males. Scrum intenta atacar esos problemas endémicos del desarrollo de software rescatando la filosofía de procesos que llevó a las automotrices japonesas (con Toyota a la cabeza) a abrumar a sus pares estadounidenses, al superarlos en aspectos tales como productividad y eficiencia. El secreto de Toyota era tan simple como dar a cada empleado la posibilidad de crear sus propias reglas, junto con la responsabilidad de maximizar la calidad en la parte del desarrollo que le tocaba llevar a cabo. Características de un proceso Scrum La metodología Scrum asume que el proceso de desarrollo de software es impredecible, y lo trata como a una caja negra controlada, en vez de manejarlo como un proceso completamente definido. Ésta es una de las principales diferencias entre Scrum y otras metodologías, como los modelos de espiral o de cascada, en los cuales el proceso de desarrollo se define por completo desde el inicio. Por tratar de planificar el proceso en forma completa desde el principio, las Backlog de producto Backlog de sprint Ciclo diario Scrum Ciclo mensual Ejecutable incremental Sprint Reunión de demostración post-sprint Reunión de planificación de sprint Estándares, técnicas, procesos, lineamientos, herramientas de desarrollo [Figura 1] En el núcleo del proceso Scrum se observa un ciclo de trabajo de 30 días (sprint) y otro ciclo diario (scrum) delimitado por reuniones breves del equipo de desarrollo. 54

2 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 55 Desde los inicios del desarrollo de software, se ha intentado, sin mucho éxito, lidiar con los problemas típicos de esta disciplina. Ahora veremos cómo se pueden resolver. Gustavo du Mortier Gerente de desarrollo en la empresa MasterSoft gustavo.dumortier@ mastersoft.com.ar metodologías tradicionales fallan al toparse con algunos problemas habituales del desarrollo de software, como la falta de comprensión de los requerimientos al empezar el proceso, el cambio en los requerimientos durante el proceso, o la dificultad para prever los resultados del uso de nuevas herramientas y tecnologías. Otra diferencia de Scrum con las metodologías tradicionales es que no trata el proceso de desarrollo de software como un proceso lineal, en el que se sigue la secuencia de análisis, diseño, codificación y testing. En Scrum, el proyecto puede iniciarse con cualquier actividad, y cambiar de una a otra en cualquier momento. Un proyecto administrado mediante Scrum se organiza en iteraciones, llamadas sprints, que normalmente tienen entre dos y cuatro semanas de duración. Al principio de cada sprint se establece una lista de requerimientos llamada backlog, que debe completarse cuando éste finalice. A diario se realizan breves reuniones del equipo de desarrollo, en las que se exponen los avances y los problemas encontrados, y se señalan posibles caminos para resolverlos (la resolución detallada de estos problemas no debe determinarse durante la reunión, para mantener su brevedad). Su majestad el backlog Un proceso Scrum reconoce tres tipos de backlog: el backlog de producto, el backlog de versión y el backlog de sprint. El backlog de producto es un repositorio de requerimientos enunciados por los interesados en el éxito del proyecto (los llamados stakeholders, que pueden ser usuarios, administradores, técnicos de soporte, etc.). Por lo general, los requerimientos incluidos en este backlog son de alto nivel, evitan detallar cuestiones técnicas o de implementación, y tienen asociadas estimaciones de tiempos también de alto nivel, realizadas por los stakeholders. El backlog de versión (release backlog) consiste en una lista de requerimientos extraída del backlog de producto, priorizada para la próxima versión (release) del producto. Los elementos de este backlog tienen un mayor nivel de detalle en cuanto a los requerimientos y tienen asociadas estimaciones más precisas, realizadas por los miembros del equipo de Scrum. El backlog de sprint se arma al principio de cada sprint, y reúne aquellos requerimientos que el equipo se compromete a completar para cuando finalice dicho sprint. Completar un requerimiento implica codificarlo, testearlo y documentarlo. El backlog de sprint se arma dividiendo los requerimientos del backlog de release en tareas que comúnmente pueden completarse en períodos de 8 a 16 horas. El equipo de trabajo En Scrum, los equipos de desarrollo deben estar formados por una cantidad aproximada de siete miembros. El líder del equipo es el denominado Scrum Master, y su trabajo consiste en implementar y administrar el proceso Scrum en el proyecto. Al inicio del proyecto, el equipo debe ponerse de acuerdo en cuanto a las prácticas que se van a implementar, la frecuencia de las reuniones, los artefactos por utilizar, etc. A partir de allí, es responsabilidad del Scrum Master asegurar que el equipo se atenga a las normas establecidas. El Scrum Master asume el rol de facilitador, y su autoridad es, en su Revisión de planes de versión (release). Sprint Distribución, revisión y ajuste de estándares de producto. Desarrollo Empaquetado Revisión Ajuste Revisión de Sprint Revisión del software. Comparación del backlog con el software desarrollado. Edición del backlog. Agregado de nuevos puntos al backlog. Asignar puntos del backlog a los equipos de desarrollo. Planificar próxima versión. [stakeholders] Análisis de variables: tiempo, requerimientos, costo, calidad. Concuerdan con los objetivos de la versión? Cierre. [stakeholders] [Figura 2] Fases detalladas del proceso Scrum. Sí 55

3 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 56 [management] Jeff Sutherland creó una metodología de procesos de desarrollo que demostró su efectividad para elevar la productividad. mayor parte, indirecta. Su trabajo consiste en atajar las interferencias externas para que el equipo de desarrollo optimice su productividad, resolviendo los impedimentos que no pueden ser resueltos por los miembros del equipo. Su responsabilidad también incluye el hecho de asegurar la transparencia del proceso de desarrollo, manteniendo los artefactos definidos para el proceso (ver el recuadro Los roles de un Scrum ). Las reuniones de Scrum Las reuniones de Scrum deben llevarse a cabo diariamente, aunque el equipo puede ponerse de acuerdo al inicio para realizarlas con una periodicidad diferente; por ejemplo, día por medio. Es importante que se efectúen siempre en el mismo lugar y a la misma hora, y que su duración no exceda los 30 minutos. Durante la reunión, el Scrum Master hace a cada miembro del equipo tres preguntas: qué hizo desde la última reunión de Scrum, qué obstaculizó su trabajo y qué planea hacer desde ese momento hasta la próxima reunión. La conversación debe limitarse a las respuestas de los miembros del equipo a las tres preguntas anteriores. Sobre la base de las respuestas obtenidas y de los problemas que éstas reflejen, pueden agendarse reuniones para llevar a cabo en forma inmediata luego de la reunión de Scrum, entre un subgrupo del equipo, para dar solución a los inconvenientes detectados. El Scrum Master señala los caminos de solución a los problemas y es responsable de identificar impedimentos externos que puedan frenar el proceso. Fases de un proceso Scrum El proceso de desarrollo Scrum se compone de cinco actividades principales: revisión de los planes de release; distribución, revisión y ajuste de los estándares de producto; sprint; revisión de sprint, y cierre (ver [Figura 2]). La fase de sprint es en la que se realiza el desarrollo de software propiamente dicho. Dentro de un sprint se efectúan varias sub-actividades: desarrollo, empaquetado, revisión y ajuste. No existe secuencia dentro de esta fase. Algunas veces, un ítem del backlog debe ser desarrollado, empaquetado y revisado, y otras veces, el ítem sólo debe ser revisado y ajustado; todo depende de las características del ítem en cuestión. Cada sprint es seguido por un proceso de revisión. Durante esta etapa, se revisa el software desarrollado en el sprint que acaba de finalizar y, de ser necesario, se agregan nuevos ítem en el backlog. El grupo de revisores debe incluir a los stakeholders, los administradores del proyecto, los desarrolladores y los usuarios. Las actividades de sprint y revisión de sprint tienen que repetirse hasta que el producto está en condiciones de ser distribuido por los accionistas. Luego, el proyecto entra en la fase de cierre, tras la cual el producto queda en condiciones para el cierre de versión (release) y distribución. En la fase de cierre, se realizan las últimas tareas de Controles Compuesto por Afecta Backlog Versión Formado por Cuestión Punto del backlog Paquete Componente / objeto del producto Produce Solución Implementa Cambio Resuelve Problema Riesgo [Figura 3] Controles que se aplican durante el proceso Scrum. 56

4 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 57 Los roles de un Scrum depuración (debugging), luego de lo cual se construyen los entregables y el proyecto se da por finalizado. Debido a lo imprevisible de los procesos de desarrollo de software, no es posible definir exactamente cuándo ocurrirá la fase de cierre, de modo que los proyectos pueden demorarse más o menos de lo planeado. Pero mediante el uso de los controles que provee Scrum, se pueden hacer estimaciones sobre su duración. Cómo evitar que se descontrole el proyecto Hasta aquí hemos explicado cómo se estructura un proceso Scrum y cómo es la dinámica de trabajo, pero aún no vimos las claves para asegurar que concluya exitosamente en tiempo y en forma, y que, a la vez, sea flexible y adaptable a los cambios. En general, en los proyectos de desarrollo que involucran métodos ágiles se fijan los plazos y los costos, pero se permite que los alcances varíen de una forma controlada. Los controles son, entonces, la herramienta imprescindible para que el proyecto arribe a buen puerto. En Scrum se define una serie de aspectos del proceso, que se controlan y miden de forma tal de no anular la cualidad de caja negra que caracteriza a las etapas de desarrollo. Estos aspectos, o controles, son los siguientes: > Puntos del backlog: Requerimientos funcionales del producto que no son cumplidos adecuadamente por la actual versión. Bugs, defectos, mejoras pedidas por el usuario, funcionalidad competitiva y actualizaciones tecnológicas son otros posibles puntos del backlog. > Versión (release): Un conjunto de puntos del backlog que, en un determinado momento, representan una nueva versión viable del producto, sobre la base de las variables de requerimientos, tiempo, calidad y competencia. > Paquetes: Componentes del producto u objetos que deben cambiarse para implementar un punto del backlog en una nueva versión del producto. > Cambios: Cambios que deben ocurrir en un paquete para implementar un punto del backlog. > Problemas: Problemas técnicos que suceden y deben resolverse para implementar un cambio. > Riesgos: Los riesgos que afectan el éxito del proyecto son continuamente evaluados y se planean respuestas. Otros controles se ven afectados como consecuencia del análisis de riesgo. > Soluciones: Soluciones a los problemas y riesgos, que habitualmente derivan en cambios. > Cuestiones (issues): Cualquier otra cuestión que afecte al proyecto, y que no se defina en términos de paquetes, cambios o problemas. En la [Figura 3] se observa cómo los controles se conectan entre sí y qué influencia tienen unos sobre otros. Los controles se usan en varias fases de Scrum. La gerencia del proyecto los emplea para administrar el backlog. Los equipos de desarrollo los utilizan para administrar cambios y problemas. En conjunto, la gerencia y los equipos de desarrollo administran las cuestiones, riesgos y soluciones. Los controles son revisados, modificados y conciliados en cada reunión de revisión de un sprint. La revisión de los controles permite al administrador del El método Scrum reconoce tres roles: Dueño del producto, Scrum Master y Equipo. Las responsabilidades del Dueño del producto incluyen definir las características del producto, determinar la fecha de lanzamiento y el contenido, asegurar la rentabilidad del producto, priorizar las características según el valor de mercado, ajustar las características y las prioridades cada treinta días (según sea necesario), y aceptar o rechazar resultados del trabajo. El Dueño del producto es responsable por la primera de las tres ceremonias de Scrum: la planificación. El Scrum Master es un facilitador y líder de equipo, que trabaja en contacto estrecho con el Dueño del producto. Sus responsabilidades abarcan asegurar que el equipo se mantenga plenamente funcional y productivo; permitir la cooperación estrecha entre todos los roles y funciones; eliminar las barreras que obstaculicen el desarrollo del proyecto; proteger al equipo de las interferencias externas, y asegurar que el proceso se lleve a cabo correctamente, asegurando la concurrencia de los involucrados a las reuniones diarias de Scrum, a las revisiones de sprint y a las planificaciones de sprint. Durante las reuniones diarias de Scrum, el Scrum Master debe saber qué tareas han sido completadas, cuáles se han iniciado, qué nuevas tareas se han descubierto y qué estimaciones cambiaron. Esto hace posible mantener actualizado el diagrama de burndown, que muestra, día tras día, el trabajo que queda pendiente. El Scrum Master debe observar cuidadosamente el número de tareas abiertas en progreso, para asegurarse de mantener este número en valores óptimos. Debe sacar a la luz las dependencias y los bloqueos que actúen como impedimentos para el Scrum, determinando sus prioridades y realizando su seguimiento. Es preciso implementar un plan de solución para estos impedimentos en orden de prioridad. Algunos podrán resolverse con el equipo; otro podrán resolverse entre equipos, y otros requerirán la participación de la gerencia, ya que pueden ser cuestiones de la compañía que estén impidiendo a todos los equipos lograr su óptima capacidad de producción. Por último, el Scrum Master debe detectar problemas personales o conflictos dentro del Scrum que necesiten solución. Estos conflictos deben ser clarificados por él y resueltos mediante el diálogo dentro del equipo, o bien el Scrum Master puede solicitar ayuda a la gerencia o a la oficina de recursos humanos. El Equipo debe ser polifuncional, compuesto por siete miembros (más/menos dos). Su labor consiste en seleccionar el objetivo final de cada sprint, especificar los resultados del trabajo y llevarlo a cabo. Posee el derecho de realizar lo que sea dentro de los límites que impongan los lineamientos del proyecto para alcanzar el objetivo final de un sprint. Debido a que opera como una caja negra, debe organizarse a sí mismo y a su trabajo, y debe preparar una demo de los resultados para exhibir ante el Dueño del producto. 57

5 54-58 Management - 36.qxd 3/19/07 5:26 PM Page 58 [management] proyecto obtener métricas sobre él. Por ejemplo: el número de puntos del backlog define el tamaño del proyecto, mientras que la cantidad de puntos finalizados exitosamente indica el progreso logrado. A su vez, la cantidad de riesgos define la complejidad del proyecto. No hay balas de plata Los métodos ágiles son comúnmente considerados balas de plata, en especial, por directivos de ingeniería de software que han visto uno o más proyectos riesgosos concluir con éxito luego de aplicar metodologías tales como Scrum o XP. El problema es que el éxito de unos pocos casos es difícil de replicar en la mayoría. La idea detrás de las balas de plata es que, al utilizarlas, se puede poner a cualquier persona a desarrollar software. Los procesos ágiles traen un lema diferente: el desarrollo de software es una tarea complicada, por lo que ofrece un marco de trabajo y un conjunto de prácticas con los cuales se facilitará comprometer y administrar equipos en este dificultoso trabajo. No se hace el intento por hacer creer que el trabajo es fácil o que puede ser realizado por personas sin experiencia, indiferentes o incompetentes. En cambio, los procesos ágiles, simplemente, logran que el impacto del trabajo de profesionales sin la necesaria capacidad se haga visible y evidente en forma temprana, y pueda ser tratado como corresponda. Otras metodologías cometen el error de ocultar los malos resultados hasta el final del proyecto, y en algunos casos, los malos resultados afloran después de terminarlo, cuando alguien intenta efectuar mantenimiento o cambios en el software. Los procesos ágiles, en cambio, comunican las malas noticias apenas éstas se producen, para que puedan ser atacadas antes de que alcancen una magnitud capaz de poner en riesgo al proyecto en su totalidad. Sugerencias de su creador Dr. Jeff Sutherland CTO de PatientKeeper En exclusiva, gracias a la gente de Baufest ( tuvimos la posibilidad de reunirnos con el Dr. Jeff Sutherland, creador de la metodología Scrum y coautor del Manifiesto Ágil. Él mismo nos cuenta cuáles son los beneficios de esta metodología que, día a día, las empresas toman como referente. Scrum es una forma de gestionar proyectos de software. No es una metodología de análisis, ni de diseño, como podría ser RUP, sino una metodología de gestión del trabajo. Una de las características más importantes es que es muy fácil de explicar y de entender, lo que contribuye mucho a su implantación. Cómo ayuda Scrum en la evolución del desarrollo de software? Scrum puede ser aplicada a distintos modelos de calidad (como podría ser CMMI), puesto que éstos dicen qué tendríamos que hacer o qué deberíamos gestionar en el proyecto, pero no nos dicen cómo hacerlo. Ahí es donde entra Scrum como modelo de gestión del proyecto. Los siguientes son los elementos básicos de esta metodología: > Una lista, llamada Product Backlog, con las funcionalidades de la aplicación ordenadas de mayor a menor importancia. No hace falta que contenga todas las funcionalidades inicialmente. > De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y se las anota en otra lista, que se llama Sprint Backlog. Estas tareas serán realizadas en el siguiente mes. Además de estos elementos, existen unas cuantas reglas básicas y sencillas que deberemos cumplir: > Una vez que se pasan las tareas prioritarias del Product Backlog al Sprint Backlog, no se las puede cambiar; esto quiere decir que el trabajo de un mes queda fijado. Ésta es la regla más importante de todas. > Al final del mes período que se denomina sprint, hay que tener un ejecutable con las funcionalidades del Sprint Backlog. > Todos pueden añadir funcionalidades al Product Backlog, pero sólo una persona puede ordenarlo. A esta persona se la denomina Product Owner, y es el responsable del producto final. > Cada día se hace una reunión de menos de 15 minutos, en la que se reúne todo el equipo ingenieros y gestor (llamado Scrum Master), y cada miembro expone sólo los siguientes temas: Qué se hizo el día anterior? Qué se va a hacer hoy? Qué impedimentos tengo para realizar mi trabajo? Sólo se tratan estos temas para que la reunión sea rápida y no se malgaste el tiempo de los demás. Si es necesario tratar otro tema, se hace otra reunión sólo con las personas implicadas. > Al final del mes (es decir, al final del sprint), se presenta el producto y se toman del Product Backlog ordenado las funcionalidades para cubrir en el siguiente mes. 58