Академический Документы
Профессиональный Документы
Культура Документы
qxd
3/19/07
5:25 PM
Page 54
(Management)
El mtodo Scrum
crum es, actualmente, uno de los mtodos giles para desarrollo de software de mayor difusin 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 eleccin 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 rpidamente un objetivo comn, que consiste en aduearse de la pelota y llevarla hacia delante. El creador de Scrum es Jeff Sutherland, uno de los 17 gures agilistas que se reunieron en el ao 2001 para establecer los postulados del desarrollo de software gil, y redactar y firmar el mtico Manifiesto gil. En el texto de dicho manifiesto se establecen los objetivos de las metodologas giles, entre los cuales se destaca la preferencia de algunos valores por sobre otros, por ejemplo:
> Respuesta a los cambios, sobre cumplimiento estricto de un plan. En estos postulados se observa la intencin de los agilistas de rebelarse contra los vicios tpicos de los procesos tradicionales de desarrollo de software: planes que no se cumplen o que se extienden ms all de los plazos, documentacin que exige demasiado trabajo de elaboracin 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 endmicos del desarrollo de software rescatando la filosofa 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.
> Individuos e interacciones, sobre procesos y herramientas. > Software operativo, sobre documentacin extensiva. > Colaboracin con el cliente, sobre negociacin de contratos.
Backlog de producto
Backlog de sprint
Ciclo mensual
Sprint Reunin de demostracin post-sprint Estndares, tcnicas, procesos, lineamientos, herramientas de desarrollo
[Figura 1] En el ncleo del proceso Scrum se observa un ciclo de trabajo de 30 das (sprint) y otro ciclo diario (scrum) delimitado por reuniones breves del equipo de desarrollo.
54
users.code
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 tpicos de esta disciplina. Ahora veremos cmo se pueden resolver.
Gustavo du Mortier
Gerente de desarrollo en la empresa MasterSoft gustavo.dumortier@ mastersoft.com.ar
metodologas tradicionales fallan al toparse con algunos problemas habituales del desarrollo de software, como la falta de comprensin 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 tecnologas. Otra diferencia de Scrum con las metodologas tradicionales es que no trata el proceso de desarrollo de software como un proceso lineal, en el que se sigue la secuencia de anlisis, diseo, codificacin 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 duracin. 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 sealan posibles caminos para resolverlos (la resolucin detallada de estos problemas no debe determinarse durante la reunin, para mantener su brevedad).
Su majestad el backlog
Un proceso Scrum reconoce tres tipos de backlog: el backlog de producto, el backlog de versin 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, tcnicos de soporte, etc.). Por lo general, los requerimientos incluidos en este backlog son de alto nivel, evitan detallar cuestiones tcnicas o de implementacin, y tienen asociadas estimaciones de tiempos tambin de alto nivel, realizadas por los stakeholders. El backlog de versin (release backlog) consiste en una lista de requerimientos extrada del backlog de producto, priorizada para la prxima versin (release) del producto. Los elementos de este backlog tienen un mayor nivel de detalle en cuanto a los requerimientos y tienen asociadas estimaciones ms precisas, realizadas por los miembros del equipo de Scrum. El backlog de sprint se arma al principio de cada sprint, y rene 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 comnmente pueden completarse en perodos de 8 a 16 horas. Revisin de Sprint Revisin del software. Comparacin del backlog con el software desarrollado. Edicin del backlog. Agregado de nuevos puntos al backlog. Asignar puntos del backlog a los equipos de desarrollo. Planificar prxima versin. [stakeholders]
El equipo de trabajo
En Scrum, los equipos de desarrollo deben estar formados por una cantidad aproximada de siete miembros. El lder 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 prcticas 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
Anlisis de variables: tiempo, requerimientos, costo, calidad. Concuerdan con los objetivos de la versin? S Cierre. [stakeholders]
55
3/19/07
5:25 PM
Page 56
[management]
Jeff Sutherland cre una metodologa 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 tambin 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).
Versin Cuestin
Paquete
Produce
Solucin Resuelve
Problema
Riesgo
56
users.code
3/19/07
5:25 PM
Page 57
depuracin (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 cundo ocurrir la fase de cierre, de modo que los proyectos pueden demorarse ms o menos de lo planeado. Pero mediante el uso de los controles que provee Scrum, se pueden hacer estimaciones sobre su duracin.
57
3/19/07
5:26 PM
Page 58
[management]
proyecto obtener mtricas sobre l. Por ejemplo: el nmero de puntos del backlog define el tamao 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.
desarrollo de software es una tarea complicada, por lo que ofrece un marco de trabajo y un conjunto de prcticas 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 fcil 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 metodologas cometen el error de ocultar los malos resultados hasta el final del proyecto, y en algunos casos, los malos resultados afloran despus 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
En exclusiva, gracias a la gente de Baufest (www.baufest.com), tuvimos la posibilidad de reunirnos con el Dr. Jeff Sutherland, creador de la metodologa Scrum y coautor del Manifiesto gil. l mismo nos cuenta cules son los beneficios de esta metodologa que, da a da, las empresas toman como referente. Scrum es una forma de gestionar proyectos de software. No es una metodologa de anlisis, ni de diseo, como podra ser RUP, sino una metodologa de gestin del trabajo. Una de las caractersticas ms importantes es que es muy fcil de explicar y de entender, lo que contribuye mucho a su implantacin. Cmo ayuda Scrum en la evolucin del desarrollo de software? Scrum puede ser aplicada a distintos modelos de calidad (como podra ser CMMI), puesto que stos dicen qu tendramos que hacer o qu deberamos gestionar en el proyecto, pero no nos dicen cmo hacerlo. Ah es donde entra Scrum como modelo de gestin del proyecto. Los siguientes son los elementos bsicos de esta metodologa: > Una lista, llamada Product Backlog, con las funcionalidades de la apliregla ms importante de todas. > Al final del mes perodo que se denomina sprint, hay que tener un ejecutable con las funcionalidades del Sprint Backlog. > Todos pueden aadir funcionalidades al Product Backlog, pero slo una persona puede ordenarlo. A esta persona se la denomina Product Owner, y es el responsable del producto final. > Cada da se hace una reunin de menos de 15 minutos, en la que se rene todo el equipo ingenieros y gestor (llamado Scrum Master), y cada miembro expone slo los siguientes temas: Qu se hizo el da anterior? Qu se va a hacer hoy? Qu impedimentos tengo para realizar mi trabajo? Slo se tratan estos temas para que la reunin sea rpida y no se malgaste el tiempo de los dems. Si es necesario tratar otro tema, se hace otra reunin slo 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.
users.code
Dr. Jeff Sutherland CTO de PatientKeeper cacin 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 sern realizadas en el siguiente mes. Adems de estos elementos, existen unas cuantas reglas bsicas 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
58