mejora de la metodologia scrum martin casamayor

Universidad de BelgranoFacultad de Tecnologa Informtica Ingeniera en Informtica Tesina de Grado

MEJORA DE LA

Metodologa Scrum

Por Martn Alejandro Casamayor Carrera: 502 Matricula: 9804 Tutora: Paula Angeleri. Buenos Aires, febrero de 2010 Contacto: [email protected]

Firma del alumno

MEJORA DE LA METODOLOGA SCRUM

Martn A. Casamayor

ResumenScrum es el nombre de una metodologa gil de gestin de proyectos formulada en el ao 1989 por Horitaka Takeuchi y Ikujiro Nonaka. Sobre la base del conocimiento ganado en la carrera de grado acerca de metodologas de desarrollo de software, la investigacin realizada ms dos aos experiencia personal en su utilizacin intensiva, el presente trabajo se propone descubrir y analizar sus puntos dbiles, con el fin de identificar oportunidades de mejora. Como resultado, se espera ofrecer las empresas y grupos de personas que desean utilizarla, orientaciones para aplicarla con mayor eficiencia y para resolver mejor los problemas que enfrentan, minimizando as las probabilidades de fracaso.

1


Martn A. Casamayor

ndiceRESUMEN ......................................................................................................... 1 NDICE ............................................................................................................... 2 NDICE DE FIGURAS Y TABLAS ..................................................................... 5 11.1 1.2 1.3 1.4

INTRODUCCIN: ........................................................................................ 6Planteamiento y contexto del problema y trabajos relacionados .............................. 7 Objetivo ............................................................................................................................ 8 Justificacin..................................................................................................................... 8 Delimitaciones ................................................................................................................. 8

2

MARCO TERICO .................................................................................... 10

2.1 Metodologa gil ............................................................................................................ 10 2.1.1 El Manifiesto gil ......................................................................................................... 10 2.1.2 Principios: producto, cliente y equipo .......................................................................... 11 2.1.3 Metodologa Tradicional versus Metodologa gil ...................................................... 12 2.2 Scrum ............................................................................................................................. 17 2.2.1 La historia de Scrum.................................................................................................... 17 2.2.2 La metodologa ............................................................................................................ 18 2.2.3 Datos generales de Scrum .......................................................................................... 18 2.2.3.1 Las reuniones .................................................................................................. 19 Los elementos ......................................................................................................... 20 2.2.3.2 .............................................................................................................................. 20 2.2.3.3 Los roles o responsabilidades ......................................................................... 20 2.2.3.4 Responsabilidad del producto: El propietario del producto ............................. 20 2.2.3.5 Responsabilidad del desarrollo: El equipo ...................................................... 21 2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager) ................. 21 2.2.4 Reglas de Scrum ......................................................................................................... 21 2.2.4.1 Las reglas de Scrum (I): El Sprint Planning Meeting ...................................... 22 2.2.4.2 Las reglas de Scrum (II): Durante el Sprint ..................................................... 23 2.2.4.3 Las reglas de Scrum (III): El Sprint Review Meeting ....................................... 24 2.2.4.4 Las reglas de Scrum (y IV): El Sprint Retrospective Meeting (Reuniones retrospectivas) ................................................................................................................. 26 2.2.5 Burn Down ................................................................................................................... 29 2.2.6 Herramientas para la gestin de proyectos ................................................................ 30 2.2.7 Modelo de proceso de Scrum actual ........................................................................... 31

3

ANLISIS .................................................................................................. 33

2


Martn A. Casamayor

3.1 Anlisis comparativo entre metodologas .................................................................. 33 3.1.1 Scrum versus XP ......................................................................................................... 33 3.2 Inconvenientes de Scrum ............................................................................................. 34 3.2.1 Inconvenientes al utilizar Scrum .................................................................................. 34 3.3 Qu intentamos realizar? ........................................................................................... 36

4

DISEO ..................................................................................................... 39

4.1 Cmo saber si Scrum est funcionando? Puntos claves y dbiles de la metodologa ............................................................................................................................... 39 4.1.1 La falta de atencin a los detalles ............................................................................... 39 4.1.2 Entender y formar el equipo multidisciplinario ............................................................ 40 4.1.3 Crear y mantener un Product Backlog ........................................................................ 41 4.1.4 Recursos humanos no dedicados ............................................................................... 41 4.1.5 Integracin de las tareas de soporte y mantenimiento ............................................... 42 4.1.6 Estimacin ................................................................................................................... 42 4.1.7 Documentacin............................................................................................................ 43 4.1.8 Calidad ........................................................................................................................ 43 4.2 Mejora de la metodologa de Scrum ............................................................................ 44 4.2.1 Requisitos .................................................................................................................... 44 4.2.1.1 Ingeniera de Requisitos (IE): .......................................................................... 44 4.2.1.2 En qu podra mejorar Scrum con IE .............................................................. 47 4.2.2 El equipo: ..................................................................................................................... 48 4.2.2.1 El Product Owner ............................................................................................ 48 4.2.2.2 Esfuerzos Individuales..................................................................................... 49 4.2.3 Desarrollo .................................................................................................................... 50 4.2.3.1 Test Driver Development (TDD) ...................................................................... 50 4.2.3.2 Pair Programming............................................................................................ 50 4.2.3.3 Diseo incremental .......................................................................................... 51 4.2.3.4 Integracin continua ........................................................................................ 52 4.2.3.5 Propiedad colectiva del cdigo ........................................................................ 52 4.2.3.6 Ambiente de trabajo informativo ...................................................................... 52 4.2.3.7 Estndares de codificacin ............................................................................. 53 4.2.3.8 Ritmo sostenido ............................................................................................... 53 4.2.4 Calidad ........................................................................................................................ 54 4.2.4.1 Quality Assurance (QA) ................................................................................... 54 4.2.4.2 Por qu la calidad no es negociable ............................................................... 55 4.2.5 Diagrama de funcin de Scrum para tareas ............................................................... 56 4.2.6 Nuevas Reglas ............................................................................................................ 57 4.2.6.1 Las reglas de Scrum (VI): Procesos y herramientas de ingeniera de software 57

5 6

CONCLUSIN ........................................................................................... 60 GLOSARIO ................................................................................................ 61

3


Martn A. Casamayor

7 8

BIBLIOGRAFA ......................................................................................... 63 ANEXO 1 ................................................................................................... 668.1.1 Modelo iterativo e incremental .................................................................................... 66 8.1.1.1 Etapa de inicializacin ..................................................................................... 66 8.1.1.2 9.1.2 Etapa de iteracin................................................................................... 66 8.1.1.3 Lista de control de proyecto ............................................................................ 67

4


Martn A. Casamayor

ndice de figuras y tablasTabla 2.1.3-1 Metodologa gil vs Metodologa Tradicional (Jos H. Cans P. L.). .............. 13 Tabla 2.1.3-2 Uso de las metodologas giles ........................................................................ 14 Grfico 2.1.3-1 Uso de las metodologas giles ..................................................................... 14 Tabla 2.1.3-3 Comparacin de metodologas (Schwaber, SCRUM Development Process, pgs. 10-11) ............................................................................................................................ 16 Grfico 2.2.3-1 El flujo de trabajo en Scrum ........................................................................... 19 Grfico 2.2.4.1-1 Sprint Planning Meeting .............................................................................. 22 Grfico 2.2.4.4-1 Ciclo de Scrum ............................................................................................ 28 Grfico 2.2.5-1 Burn Down detallado ...................................................................................... 29 Grfico 2.2.5-2 Burn Down ...................................................................................................... 30 Grfico 2.2.7-1 Proceso actual de Scrum segn reglas (Autor M. Casamayor) ..................... 32 Tabla 3.1.1-1 Scrum Vs XP ..................................................................................................... 34 Grfico 3.3-1 Mejora de productividad de software ................................................................ 37 Grfico 4.1.6-1 Scrum enfocado a proyectos informticos - Autor: Martn Casamayor. ........ 56

5


Martn A. Casamayor

1

Introduccin:En el inicio de todo proyecto informtico es necesario averiguar de qu manera van a

ser gestionadas todas las tareas a realizar. Esto es lo que se conoce como gestin de proyectos de software. Existen numerosas herramientas, mtodos y tcnicas que ayudan a lograr una mayor precisin en cuanto a los plazos, costos, esfuerzo y riesgos que puede implicar la tarea (Garreta, 2003). Este gran nmero se debe a que no hay una nica metodologa que resulte ptima para todos los proyectos, sino que cada proyecto puede funcionar mejor con una determinada metodologa que con otra, ya sea por alcance, dimensiones del proyecto, por la cantidad de personas involucradas, por el tema de que se trata, tecnologa a utilizar, etc. (Charvat, 2003). Al optar por una metodologa, para llevar a cabo su implementacin se requerir tiempo y esfuerzo: se hace necesario comprar o conseguir las herramientas adecuadas y adems capacitar al personal. Esto tambin ocurre en algunos casos en menor grado, si ya se est aplicando una determinada metodologa y se decide cambiar por otra. Es por eso que, antes de decidirse por una metodologa es conveniente estudiarla y evaluar si ser la ms adecuada para el desarrollo de nuestro proyecto. Dentro de la gran variedad existente, encontramos metodologas tradicionales (conocidas como metodologas pesadas por su gran cantidad de documentacin) y metodologas giles. Las metodologas giles tienen como caracterstica su tendencia a enfocarse ms en el producto final sin concentrarse tanto en la documentacin, el anlisis y el diseo exhaustivo, etc. para que, de esta forma, el proyecto pueda entrar cuanto antes en la fase de produccin. La tendencia demuestra que, en general, debido a su nivel de complejidad, al tiempo necesario para desarrollarlos y a la cantidad de personal requerido, los proyectos pequeos suelen aplicar metodologas giles, mientras que los proyectos de gran envergadura son tratados con metodologas tradicionales. Entre las metodologas giles encontramos la Metodologa Scrum la cual, en la actualidad, es aplicada con mucha frecuencia a la gestin de proyectos. Como ocurre con toda metodologa o proceso, al aplicar Scrum se descubren problemas, dificultades con las reglas o dudas acerca de cmo aplicarlas correctamente. En muchas oportunidades se observa que son los propios equipos los que modifican las reglas, adaptndolas para utilizarlas mejor o descartando aqullas que no estiman tiles para un proyecto en particular (Abrahamsson, 2008) (Rossberg, 2008). Esto no siempre resulta conveniente ya que, a veces, la intencin de mejorar la metodologa de un proyecto termina por generar un problema an mayor. Esto llev a pensar en una nueva forma de aplicarla, agregando a la forma actual de la Metodologa Scrum, reglas y procesos propios de la ingeniera de software, propuesta que se desarrolla a lo largo del presente trabajo.

6


Martn A. Casamayor

Por tratarse de una metodologa nacida a mediados de la dcada de los 80, existe sobre el tema una rica bibliografa y abundantes acreditaciones internacionales. Existen tambin herramientas informticas para administrar los proyectos de desarrollo de software que aplican Scrum. Esto dio lugar al surgimiento de mltiples foros de discusin, en los cuales se puede obtener informacin, lo cual contribuye a llevar a Scrum un paso ms adelante.

1.1 Planteamiento y contexto del problema y trabajos relacionadosScrum es una metodologa de gestin de proyectos relativamente reciente. A pesar de esto, ya son muchos los equipos que la han implementado. As se hizo conocida como una metodologa valiosa para proyectos pequeos y cambiantes. Su buena reputacin en relacin con ese tipo de proyectos contribuy tambin a que sus desventajas hayan sido menos conocidas o analizadas. La documentacin existente acerca de una metodologa pocas veces describe experiencias de aplicacin; ms escasa an en este caso, por tratarse de una metodologa joven. Muchas veces no se especifica ni estudian detalladamente sus posibilidades de aplicacin al proyecto que se emprende, al tipo de personal y de cliente que se tiene, o a la tecnologa que se implementar. Tambin suele suceder que, por tratarse de una metodologa gil, se aplique la regla de priorizar el producto terminado a la documentacin, resultando que la documentacin al final del proyecto es escasa o nula, lo cual generar inconvenientes en el futuro. Con la experiencia de haber aplicado esta metodologa a distintos proyectos de software, adoptando los roles de desarrollador como de Scrum Master, se hizo evidente que no existen acerca de ella herramientas y procesos de la ingeniera para el desarrollo, o existen poca cantidad de experiencias documentadas, que permitan decidir las acciones a tomar ante sucesos inesperados, cmo detener una tarea a raz de cambios o cundo no es necesario o no conviene hacerlo. Ninguna de estas circunstancias est prevista en la metodologa y slo se aprenden a partir de la experiencia y de la modificacin de algunas de sus reglas o caractersticas. En la actualidad la cantidad de foros de discusin acerca de temas relacionados con Scrum se ha incrementado, as como tambin los trabajos relacionados con el problema de la documentacin, la no existencia de procesos de ingeniera o la forma de utilizar partes de otras metodologas para cubrir alguna falencia de sta. Sin embargo, aun cuando toda la informacin necesaria est disponible, con frecuencia se recurre a ella cuando el proyecto est en marcha y enfrenta problemas graves.

7


Martn A. Casamayor

1.2 ObjetivoBuscar y encontrar alternativas para mejorar la implementacin de la Metodologa gil Scrum, de manera que resulta ms eficaz en sus primeras etapas de implementacin en un equipo nuevo.

1.3 JustificacinLas metodologas giles son un recurso relativamente nuevo. No fue sino hasta mediados de la dcada de los 90 cuando Scrum surgi como una metodologa gil para proyectos de software. Sin embargo, a pesar de ser relativamente nueva, el uso de Scrum ha crecido significativamente. Al momento de comenzar a utilizar una metodologa gil, comienzan a surgir eventualidades que no favorecen al desarrollo del proyecto. En el mbito del desarrollo informtico se suele decir que, por tratarse de una metodologa gil, hay muchos aspectos en los cuales las decisiones quedan a criterio de quien la est implementando. Un ejemplo de esto es la documentacin. La libertad propia de este tipo de metodologas genera muchas veces un resultado negativo, ya que no existe una solida base sobre la cual referenciarse, lo que conduce a entregas tardas, con calidad mediocre, disconformidad del cliente y/o del equipo, etc. Por otra parte, a pesar que en este tipo de metodologas existen reglas, stas se pueden aplicar de diferente manera segn el proyecto o el equipo de que se trate. Esto no debera ocurrir, ya que una regla debe ser invariable. Sin embargo, la variacin en cuanto a la forma de aplicacin de las reglas se observa constantemente en los diferentes equipos. Estos son, precisamente, los puntos que llevan a replantear el tema y proponer una solucin. La solucin consiste en establecer una base ms robusta y slida, en la cual no existan ambigedades ni tal grado de libertad que d lugar confusin o errores en el equipo. Asimismo,, se procurar reducir los retrasos, las deficiencias en la calidad y todo otro tipo de inconvenientes en los desarrollos que aplican Scrum. Se espera lograr este objetivo por medio de la incorporacin a la Metodologa Scrum de buenas prcticas como la Ingeniera de Requisitos de Desarrollo, utilizada por otras metodologas y teniendo en cuenta otras exigencias de calidad propias de los proyectos de software.

1.4 DelimitacionesLas recomendaciones que surgen de este trabajo se basan en la experiencia personal y en el anlisis detenido de las cuestiones planteadas. Sin embargo, no han sido puestas a prueba debido a que aplicar una metodologa requiere de un proyecto adecuado, as como de tiempo suficiente para adaptar un equipo y para pulir detalles que estas recomendaciones necesiten, todo lo cual excede el periodo de preparacin de una tesina.

8


Martn A. Casamayor

La ltima delimitacin consiste en la tecnologa de codificacin a emplear para el desarrollo del proyecto. En la Metodologa Scrum, la programacin deber ser Programacin Orientada a Objetos (POO). Esto se debe a que las tareas pueden ser divididas y fcilmente reflejadas en cdigo como objetos o mtodos especficos.

9


Martn A. Casamayor

2

Marco Terico

2.1 Metodologa gilPara comenzar a hablar de Scrum es necesario definir, en primer lugar, qu es una metodologa gil y en qu aspectos difiere de una tradicional. Las metodologas tradicionales se dividen en fases que son, por lo general, y Mantenimiento. Las metodologas giles, por su parte, se dividen en pequeos proyectos que se van llevando a cabo en forma incremental. A continuacin se presentan las bases y significado de las metodologas giles. Anlisis, Diseo, Desarrollo, Implementacin

2.1.1

El Manifiesto gil

En el ao 2001 un grupo pionero en las metodologas giles reuni y estableci las bases para desarrollarlas. Este enunciado se conoce como Manifiesto gil (Kent Beck, 2001) (Larman, Agile and iterative development: a manager's guide, 2004) (Doug Rosenberg, 2005) y propone: Dar ms importancia a la interaccin entre personas, que a los procesos y herramientas. Dar ms importancia a los productos que funcionan, que a la documentacin extensiva. Incentivar la colaboracin con el cliente, ms que la negociacin del contrato. Responder al cambio es mejor que seguir el plan. Existen tambin doce principios para el desarrollo gil de software, redactados por los mismos autores. Estos son: La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte valor. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 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. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. El software que funciona es la principal medida de progreso.

10


Martn A. Casamayor

Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener constante armona. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. La simplicidad es esencial. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados que se organizan a s mismos. Peridicamente, el equipo reflexiona acerca de cmo ser ms eficaces, y ajusta su conducta en consecuencia.

2.1.2

Principios: producto, cliente y equipo

El principio de metodologa gil tambin modifica el concepto de lo que se conoce como producto, cliente y equipo. Otorga prioridades y significados diferentes segn los mencionados doce principios expresados para el desarrollo gil de software (Castro, Metodologa de Trabajo gil y Eficiente: El mtodo Scrum aplicado a la Gestin de Proyectos en general). Estos son: Cliente La mayor prioridad es satisfacer al cliente a travs de la entrega temprana y continua de productos con valor. Se aceptan requisitos cambiantes, incluso en etapas avanzadas. Esto es una ventaja competitiva de los procesos giles. Los responsables del negocio y los empleados deben trabajar juntos diariamente, a lo largo de todo el proyecto. Producto El producto que funciona es la principal medida del progreso. Se entregan productos con frecuencia. La simplicidad es esencial. Los procesos giles promueven el desarrollo sostenible. La atencin continua a la excelencia tcnica y los buenos diseos mejoran la agilidad. Equipo Se construyen proyectos con profesionales motivados. Se prioriza la comunicacin cara a cara. Las mejores propuestas, requisitos y diseos surgen de los equipos que se auto-organizan. Peridicamente, el equipo reflexiona acerca de cmo ser ms efectivo.

11


Martn A. Casamayor

2.1.3

Metodologa Tradicional versus Metodologa gil

Hasta hace poco, la tarea de desarrollo llevaba asociado un marcado nfasis sobre el control del proceso por medio de una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamao (en cuanto a tiempo y recursos), en los cuales, por lo general, se exige un alto grado de formalidad en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales, donde el entorno del sistema es muy cambiante, y en los cuales se exige reducir drsticamente los tiempos de desarrollo, manteniendo una alta calidad. Ante las dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de las reglas de las buenas prcticas de la ingeniera del software, asumiendo el riesgo que esto implica. En este escenario, las metodologas giles surgen como una alternativa para llenar ese vaco metodolgico. Por estar especialmente orientadas a proyectos pequeos, las metodologas giles representan una solucin a medida para ese entorno, aportando una notable simplificacin que, sin embargo, no renuncia a las prcticas esenciales para asegurar la calidad del producto. Las metodologas giles son uno de los temas que en la actualidad despiertan gran inters en la ingeniera de software, y estn ganando espacio en la mayora de las conferencias y workshops. Su impacto es tan grande que, inclusive, son el tema central de muchas conferencias internacionales. (Ciencia y Tcnica Administrativa). En la comunidad de la ingeniera del software, se est viendo con frecuencia un debate abierto entre los que siguen las metodologas tradicionales y aquellos que apoyan las ideas del manifiesto gil. La mayora de los ingenieros de software y de los usuarios de estas nuevas prcticas sienten que las metodologas giles tienen un gran futuro por delante en el campo del desarrollo de software y en el mbito industrial. Por un lado, para muchos equipos de trabajo las metodologas tradicionales representan algo muy diferente de la forma de trabajo actual, considerando las dificultades para introducirlas y la inversin que implican en cuanto a capacitacin y equipos. Por otra parte, las caractersticas de los proyectos para los cuales las metodologas giles han sido especialmente pensadas, se ajustan a un amplio rango de proyectos industriales de desarrollo de software. Precisamente aquellos en los cuales los equipos de desarrollo son pequeos, con plazos reducidos, requisitos y alcances cambiantes, y basados en nuevas tecnologas. (Jos H. Cans P. L.) Se debe a esto que est siendo tan investigada y utilizada por grupos de desarrollo y gestin de proyectos? Actualmente la gran mayora de los proyectos de software son proyectos de pequeos a medianos, con plazos menores de un ao para cumplir las etapas de anlisis, diseo, desarrollo e implementacin. Adems, no se puede comenzar por hacer un anlisis de los requisitos del momento actual porque, por lo general, cambiarn en el transcurso del

12


Martn A. Casamayor

desarrollo. Los requisitos no slo cambian de manera rpida, sino que tambin es muy difcil definirlos por la cantidad de informacin de que se dispone en la actualidad (Jos H. Cans). A continuacin se presenta una tabla comparativa entre ambos tipos de metodologa.

Metodologa gil En qu se basa Basada en heursticas provenientes de prcticas de produccin de cdigo.

Metodologa Tradicional Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo Cierta resistencia a los cambios.

Cambios durante el proyecto

Especialmente preparada para los cambios durante el proyecto Impuesta internamente (por el propio equipo) Procesos menos controlados, ms libertad a la hora de aplicar procesos, pocos principios. No existen contratos tradicionales. El cliente es parte del equipo de desarrollo.

Quin la impone

Impuesta por un tercero.

Procesos

Procesos muchos ms controlados con numerosas polticas / normas.

Tipo de contratos existentes

Existe un contrato prefijado.

Como acta el cliente en el proyecto

El cliente interacta con el equipo de desarrollo mediante reuniones. Grupos grandes y probablemente distribuidos. Muchos artefactos. Muchos roles. La arquitectura del software es esencial y se expresa mediante modelos. El cliente ve solo la versin final.

El equipo

Grupos pequeos (menos de 15 integrantes). Pocos artefactos. Pocos roles. Menos nfasis en la arquitectura del software.

Artefactos Roles Diseo y arquitectura

Entregas

El cliente ve progresos en intervalos cortos de tiempo. Los requisitos pueden cambiar.

Definicin de requisitos

Los requisitos se establecen al principio sin poderse cambiar.

Tabla 2.1.3-1 Metodologa gil vs Metodologa Tradicional (Jos H. Cans P. L.).

13


Martn A. Casamayor

En consecuencia, en lneas generales, una metodologa gil puede resultar muy til para corregir requisitos mal formulados, mal definidos o incompletos. Por otra parte, al ser ms libre y no basarse tanto en el cumplimiento de normas, su costo tiende a ser menor. A continuacin se presenta un grfico sobre la cantidad de proyectos que utilizan metodologas giles. Agile journal (N Marzo-2006 )1. 1,

Tabla 2.1.3-2 Uso de las metodologas giles

Grfico 2.1.3-1 Uso de las metodologas giles

En esta encuesta, tambin se consult por qu utilizan estas metodologas. Las respuestas fueron las siguientes: Para reducir el tiempo de desarrollo: 45% Para mejorar la calidad: 43% Para reducir costes: 23% Para alinear el desarrollo con los objetivos de negocio: 39% Otras razones: 12%. Y cul es el ranking de preferencias entre los modelos giles? Estos fueron los resultados: 1. Extreme Programming (28%) 2. FDD (26%) 3. Scrum (20%) 4. Crystal (6%)

1

Encuesta realizada por CM Crossroad en el ao 2006 en los Estados Unidos. (CM Crossroad).

14


Martn A. Casamayor

5. DSDM (4%)

Llegada la hora de elegir una metodologa gil, estas encuestas permiten prever cules son las metodologas que probablemente tendrn mayor soporte en foros de debate y grupos, as como documentacin acerca de casos ocurridos. Todas estas consideraciones resultan muy valiosas al momento de decidirse por una. Sin embargo, existen otros aspectos a tener en cuenta. Cuando se pretende cambiar de una metodologa de desarrollo por otra, el costo del cambio resulta, por lo general, grande. Este costo, expresado en tiempo y dinero, comprende: Capacitacin: Del equipo que va a emplear la metodologa, del cliente en caso de que ste participe en el equipo, y a su vez para informarlo de cmo sern las entregas de versiones del producto, etc. Tiempo de adaptacin de las personas del equipo. Tiempo de adaptacin del cliente, si es que este pasa a involucrarse directamente con el equipo de desarrollo. Sin embargo, los estudios realizados tambin revelan que, si se utilizan metodologas tradicionales que implican normas y polticas a cumplir, aunque comenzar a utilizar una metodologa gil implica un costo inicial mediano, ste tiende a ser bajo a largo plazo, ya que las metodologas giles en general son gratuitas, hay mucho software para implementarlas y herramientas para aplicarlas que son gratuitos, todo lo cual representa grande ventajas. A continuacin se presenta un cuadro que refleja las diferencias entre Scrum y otro tipo de metodologas no giles. Comparacin de procesos Cascada Procesos definidos Producto final Requerido Determinado durante la planificacin Determinado durante la planificacin Determinado durante la planificacin En etapa de planificacin nicamente Espiral Requerido Determinado durante la planificacin Variable parcialmente Variable parcialmente En la planificacin principalmente Iterativo Requerido Determinada durante el desarrollo Determinada durante el desarrollo Determinada durante el desarrollo Al final de cada iteracin Scrum Planificacin y acercamiento Determinada durante el desarrollo Determinada durante el desarrollo Determinada durante el desarrollo En todo momento

Costo del proyecto Fecha de finalizacin Estudio del impacto del contexto

15


Martn A. Casamayor

Cascada Flexibilidad y creatividad del equipo Transferencia de conocimiento Limitado

Espiral Limitado

Iterativo Limitado

Scrum Ilimitado durante las iteraciones El equipo trabaja en conjunto durante el proyecto Alta

El entrenamiento es ms importante para el proyecto Baja

El entrenamiento es ms importante para el proyecto

El entrenamiento es ms importante para el proyecto Media

Probabilidad de xito

Media - Baja

Tabla 2.1.3-3 Comparacin de metodologas (Schwaber, SCRUM Development Process, pgs. 1011)

16


Martn A. Casamayor

2.2 ScrumScrum (Schwaber, 2004) (Ken, 2007) (Ken Schwaber, 2001) (Cohn, 2004) es una metodologa de gestin de proyectos de software iterativa e incremental. Se aplica sobre la base de reglas propias, que se deben aplicar en todo momento. Tambin incluye dentro del equipo de desarrollo a un usuario o dueo del proyecto (Product Owner) y a un lder de proyecto (Scrum Master). En la metodologa se plantean todas las reglas necesarias para saber si se est gestionando correctamente un proyecto. Sin embargo, no se plantea ninguna prctica ni proceso de ingeniera de software para aplicarla. Esto se debe a que Scrum no se enfoca en la gestin de proyectos de una rama especfica, sino que puede aplicarse a proyectos de informtica, de electrnica, de construccin de automviles, etc. En la actualidad, Scrum resulta exitosa en el desarrollo de proyectos de informtica, ya que plantea reglas claras acerca de cmo gestionarlos y ofrece libertad a la hora de utilizar prcticas de ingeniera de software. Esto ltimo puede representar tanto una ventaja como una dificultad. En varias experiencias se ha visto que surgen problemas al momento de decidir cules procesos de la ingeniera de software aplicar, o qu herramientas para el desarrollo de la aplicacin se va a utilizar, ya que Scrum no recomienda ni menciona ninguna en particular. Esto puede traer como consecuencia que un equipo sin experiencia en una nueva metodologa utilice, tal vez, herramientas y procesos de la ingeniera que no son los ms adecuados o, peor an, no utilice ninguno. A continuacin se explicar qu es Scrum en la actualidad, y cules son sus diferencias y similitudes con otras metodologas existentes. A partir de estas definiciones, se procurar encontrar formas de reducir las desventajas que presenta la metodologa al momento de iniciar la gestin de un proyecto informtico.

2.2.1 La historia de Scrum Scrum es una metodologa gil de gestin de software, que ayuda a administrar, controlar y desarrollar la gestin de un proyecto por medio de un proceso iterativo. Es por esto que Scrum es una metodologa que se aplica en proyectos de toda ndole. Surge en el ao 1986 cuando Hirotaka Takaeuchi e Ikijiro Nonaka describieron una nueva forma que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales. El trmino Scrum proviene del vocabulario del Rugby, y en ella el desarrollo del producto emerge de una constante interaccin de mano en mano, donde los miembros de un equipo multidisciplinario trabajan en conjunto, desde el principio hasta el final. (Rossberg, Pro Visual Studio Team System Application Lifecycle Management, 2008)

17


Martn A. Casamayor

En el ao 1993 se aplic por primera vez Scrum2 en un desarrollo de software y luego, en el ao 1995, se formaliz3. Desde entonces, miles de proyectos en todo el mundo han utilizado Scrum, tanto en pequeas empresas, como en grandes multinacionales. En la actualidad, Scrum se est utilizando en diferentes tipos de negocio y, especialmente, en el desarrollo de software. Existen organizaciones, como Scrum Alliance o Scrum Management, que se encargan de difundir esta metodologa en el mbito de la Informtica.

2.2.2 La metodologa Scrum se basa en reglas para saber si se est aplicando correctamente la gestin del proyecto. Estas reglas son la gua para poder aplicar y gestionar la metodologa de manera correcta, de manera que nos diga cmo aplicarlas en los proyectos, al realizar las reuniones, reaccionar a los cambios de requisitos (Schwaber, 2004) (Corral, 2006). A continuacin se presentan datos generales de Scrum. De esta forma se tiene un concepto ms completo de la metodologa para poder comprender de mejor manera las reglas antes mencionadas.4

2.2.3 Datos generales de Scrum

Las mencionadas reglas que presentaremos ms adelante sirven para llevar a cabo el proyecto. Sin embargo, es necesario saber cmo comenzar a gestionar un proyecto con Scrum. Antes de presentar las reglas se relevarn los datos generales de Scrum como el vocabulario propio de la metodologa, los roles que se involucran y los puntos bsicos que cada uno de stos implica. Una vez presentada esta informacin, se tratar con mayor detalle cada punto.

2

Jeff Sutherland, John Scumniotales y Jeff McKenna fueron los primeros en concebir, ejecutar y documentar el desarrollo gil en proyectos de software en el ao 1993. 3 En 1995 Ken Schwaber formaliz el proceso para la industria de desarrollo de software. 4 Otros datos que son tiles, tipos de reuniones, duraciones y reglas dentro de estas. (10)

18


Martn A. Casamayor

Grfico 2.2.3-1 El flujo de trabajo en Scrum

Los componentes y conceptos empleados en Scrum son: 2.2.3.1 Las reuniones Planificacin del sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cul es el trabajo y los objetivos que se deben cubrir con esa iteracin. Esta reunin genera la sprint backlog o lista de tareas que se van a realizar, y en ella tambin se determina el objetivo del sprint: lema que define la finalidad de negocio que se va a lograr. Seguimiento del sprint: Breve reunin diaria para dar repaso al avance de cada tarea, y al trabajo previsto para la jornada. Slo interviene el equipo, y cada miembro responde a tres preguntas: 1. Trabajo realizado desde la reunin anterior. 2. Trabajo que se va a realizar hasta la prxima reunin de seguimiento. 3. Problemas que es necesario resolver para poder realizar el trabajo.

19


Martn A. Casamayor

Revisin de sprint: Anlisis y revisin del incremento generado. Esta reunin no debe tomarse como un acontecimiento especial sino como la presentacin normal de los resultados. 2.2.3.2 Los elementos

Product Backlog: Requisitos del sistema. Se parte de la visin del resultado que se desea obtener; y evoluciona durante el desarrollo. Es el inventario de caractersticas que el propietario del producto desea obtener, ordenado por orden de prioridad. Es un documento vivo, en constante evolucin. Es accesible a todas las personas que intervienen en el desarrollo. Todos pueden contribuir y aportar sugerencias. El responsable del product backlog es una nica persona y se la denomina: propietario del producto. Sprint Backlog: Lista de los trabajos que realizar el equipo durante el sprint para generar el incremento previsto. El equipo asume el compromiso de la ejecucin. Las tareas estn asignadas a personas, y tienen estimados el tiempo y los recursos necesarios. Incremento: Resultado de cada sprint. Se trata de un resultado completamente terminado y en condiciones de ser utilizado. 2.2.3.3 Los roles o responsabilidades

El grado de funcionamiento de Scrum en la organizacin depende directamente de estas tres condiciones: Caractersticas del entorno (organizacin y proyecto), adecuadas para desarrollo gil. Conocimiento de la metodologa de trabajo por parte de todas las personas de la organizacin y las personas implicadas por el lado del cliente. Asignacin de responsabilidades: o o o 2.2.3.4 Sobre el producto. Sobre el desarrollo. Sobre el funcionamiento de Scrum

Responsabilidad del producto: El propietario del producto

En el proyecto hay una persona y slo una conocedora del entorno de negocio del cliente y de la visin del producto. Representa a todos los interesados en el producto final y es el responsable del Product Backlog. Se le suele denominar propietario del producto y es el responsable de obtener el resultado de mayor valor posible para los usuarios o clientes. Es responsable de la financiacin necesaria para el proyecto, de decidir cmo debe ser el resultado final, del lanzamiento y del retorno de la inversin. En desarrollos internos, quien asume este rol puede ser el Product Manager (o el responsable de marketing).

20


Martn A. Casamayor

En desarrollos para clientes externos lo ms aconsejable es que sea el responsable del proceso de adquisicin del cliente. 2.2.3.5 Responsabilidad del desarrollo: El equipo

Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodologa Scrum, y son los autnticos responsables del resultado. Es un equipo multidisciplinario, que incluye todas las habilidades necesarias para generar el resultado. Se auto-gestiona y auto-organiza, y dispone, dentro de la organizacin, de atribuciones suficientes para tomar decisiones sobre cmo realizar su trabajo. 2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager)

La organizacin debe garantizar el funcionamiento de los procesos y metodologas que emplea, y en este sentido Scrum no es una excepcin. En el modelo de Scrum definido por Jeff Sutherland, esta responsabilidad se garantiza integrando en el equipo a una persona con el rol de. Considerando que las realidades de unas y otras empresas pueden ser muy diferentes, y que siempre que sea posible es mejor optar por adaptar las prcticas de trabajo a la empresa, y no al revs, en ocasiones puede resultar ms aconsejable: Que en lugar de una persona con la funcin de Scrum Master, sean las personas y puestos ms adecuados en cada organizacin los que reciban la capacitacin adecuada y asuman las funciones necesarias para cubrir esta responsabilidad. Que al compromiso de funcionamiento del proceso se sume tambin la direccin de la empresa, con el conocimiento de gestin y desarrollo giles, y facilitando los recursos necesarios. Scrum Manager designa por tanto, ms que el rol, la responsabilidad de funcionamiento del modelo. Puede ser al nivel del proyecto o al nivel de la organizacin. En algunos casos resultar ms apropiado un rol exclusivo (tipo Scrum Master), mientras que en otros puede ser mejor que las responsabilidades de funcionamiento sean asumidas por los responsables del Departamento de Calidad o Procesos, o del rea de Gestin de Proyectos.

2.2.4 Reglas de Scrum Las reglas de Scrum son claras, simples y fciles de implementar. En general, se sabe que si hay un problema con las reglas, hay un problema con la gestin del proyecto. Sin embargo, el principal problema que suele aparecer es que algunos integrantes no se saben adaptar a las reglas. A continuacin se resumen las reglas de Scrum.

21


Martn A. Casamayor

2.2.4.1

Las reglas de Scrum (I): El Sprint Planning Meeting

Product Owner

Equipo de Scrum

Clientes

Product Backlog Capacidades del equipo

Sprint Planning MeetingCondiciones de negocio Tecnologa Producto actual

Metas del Sprint Sprint Backlog

Gestin / ManagementGrfico 2.2.4.1-1 Sprint Planning Meeting

La Reunin de Planificacin del Sprint (o Sprint planinng meeting) tiene una duracin mxima de 8 horas, divididas en dos partes. La Primera Parte sirve para seleccionar cual ser el Product Backlog y en la Segunda Parte se prepara el Sprint Backlog con el cual se trabajar. Los asistentes obligatorios son el equipo, incluyendo al Scrum Master y el Product Owner. Adems puede haber otras personas como los usuarios que conocen las necesidades o personas que puedan brindar ms informacin acerca del negocio o la tecnologa. Sin embargo, estas personas debern retirarse una vez que proporcionen la informacin. El Product Owner debe preparar el Product Backlog antes de la reunin. De estar ausente el Product Owner, ser reemplazado por el Scrum Master. El objetivo de la primera parte es decir, de las primeras 4 horas es que el Equipo seleccione aquellos elementos del Product Backlog que cree que puede comprometerse a transformar en un incremento de funcionalidad

potencialmente entregable. El Equipo deber mostrar este incremento de funcionalidad al Product Owner y a los involucrados en la Reunin de revisin de sprint (o Sprint review meeting) al final del Sprint.

22


Martn A. Casamayor

o

El Equipo puede hacer sugerencias, pero la decisin acerca de qu elementos del Product Backlog pueden formar parte del Sprint es responsabilidad del Product Owner.

El Equipo es responsable de determinar qu parte del Product Backlog, seleccionado por el Product Owner para ese Sprint, va a tratar de implementar durante el mismo. Limitar el tiempo de la Primera Parte a 4 horas significa que ste es todo el tiempo disponible para analizar el Product Backlog. Un anlisis ms profundo debe ser realizado durante el Sprint. Si el Product Backlog no es muy detallado y est detallado en un muy alto nivel, es probable que no sea comprendido con suficiente profundidad durante esta parte de la Reunin de Planificacin del Sprint y que, como consecuencia, el equipo no sea capaz de completar todos los elementos del Product Backlog que seleccione. La Segunda Parte del Sprint Planning Meeting ocurre inmediatamente despus de la Primera y durar tambin 4 horas, como mximo. Durante la Segunda Parte, el Product Owner debe estar disponible para el Equipo para fin de responder aquellas dudas que el Equipo pueda tener acerca del Product Backlog. Es labor del Equipo actuar solamente en su propio nombre y sin ninguna direccin externa al mismo, para encontrar durante esta Segunda Parte cmo transformar la parte seleccionada del Product Backlog en un incremento de funcionalidad potencialmente entregable. Nadie ms tiene permiso para hacer nada que no sea observar o preguntar para obtener ms informacin. El resultado de la Segunda Parte del Sprint planning meeting es una lista llamada Sprint Backlog de tareas, estimaciones de tareas y asignaciones, que dar comienzo al trabajo del Equipo para desarrollar la funcionalidad. La lista de tareas puede no ser exhaustiva, pero debe ser lo suficientemente completa como para reflejar el compromiso mutuo por parte de todos los miembros del Equipo y guiarlos durante la primera parte del Sprint, etapa en la cual el Equipo puede encontrar ms tareas a aadir en el Sprint Backlog. 2.2.4.2 Las reglas de Scrum (II): Durante el Sprint

Despus de hablar de las reglas relativas al Sprint planning meeting le toca el turno a las reglas que rigen lo que ocurre durante un Sprint: El Sprint se limita en el tiempo a 30 das corridos. Sin considerar otros factores, sta es la cantidad de tiempo necesaria para que un Equipo pueda construir algo de inters significativo para el Product Owner y los involucrados, y llevarlo a un estado en que sea potencialmente entregable. Este es tambin el mximo tiempo que se puede asignar sin que el Equipo tenga que hacer tanto trabajo que requiera artefactos y documentacin para soportar su

23


Martn A. Casamayor

proceso de razonamiento. Es tambin el mximo tiempo que la mayora de los involucrados esperarn sin perder inters en el progreso del equipo y sin perder la conviccin de que el Equipo est haciendo por ellos algo importante.

Durante el Sprint el equipo puede buscar consejo, ayuda, informacin y soporte fuera de s mismo. Nadie puede proporcionar consejo, instrucciones, comentarios o direccin al Equipo durante el Sprint. El Equipo es completamente autogestionado. El Equipo se compromete con el Product Backlog durante el Sprint planning meeting. No se permite que nadie cambie el Product Backlog durante el Sprint. El Product Backlog est congelado hasta el final del Sprint. Si se demuestra que el Sprint no es viable, el Scrum Master puede clausurarlo e iniciar un nuevo Sprint planning meeting para comenzar un nuevo Sprint. El Scrum Master puede hacer este cambio por voluntad propia o a pedido del Product Owner. El Sprint puede no ser viable si la tecnologa planteada no se puede utilizar, si las condiciones del negocio cambian de manera tal que el Sprint no le resultar de valor, o si el Equipo sufre interferencias de personas ajenas a l mismo durante el Sprint. Si el equipo se siente incapaz de completar todo el Product Backlog comprometido durante el Sprint, puede consultar con el Product Owner acerca de qu elementos quitar del Sprint actual. Si se eliminan tantos elementos que el Sprint pierde su valor y significado, el Scrum Master puede clausurar el Sprint. Si el Equipo determina que puede abordar ms Product Backlog durante el Sprint que el seleccionado durante el Sprint planning meeting, puede consultar al Product Owner acerca de qu elementos adicionales del Product Backlog pueden ser aadidos al Sprint. Los miembros del Equipo tienen dos responsabilidades administrativas durante el Sprint: Acudir al Daily Scrum meeting, y mantener actualizado y pblicamente disponible el Sprint Backlog. Se pueden aadir tareas nuevas al Sprint Backlog a medida que se detecte la necesidad; asimismo, es necesario mantener permanentemente actualizada la estimacin diaria para cada tarea. 2.2.4.3 Las reglas de Scrum (III): El Sprint Review Meeting

El Sprint review meeting proporciona un punto de corte para evaluar el progreso del proyecto al final de cada Sprint. Sobre la base de esta evaluacin es posible hacer adaptaciones en el proyecto. El Equipo estim antes en qu punto deba encontrarse al final del Sprint y estableci su camino hasta all. Al final del Sprint, el equipo presenta el incremento del producto que ha sido capaz de implementar. Los gestores, clientes, usuarios y el Product

24


Martn A. Casamayor

Owner determinan el incremento del producto. Se escucha al Equipo acerca de lo sucedido durante el Sprint, mientras se expone qu cosas fueron positivas y cules negativas. Despus de esto, estarn capacitados para tomar una decisin basada en informacin, acerca de qu hacer despus. En otras palabras, determinarn el mejor camino a tomar para alcanzar las metas propuestas. La duracin del Sprint review meeting se limita a 4 horas. El propsito del Sprint review meeting es que el Equipo presente al Product Owner y a todos los involucrados, la funcionalidad que se ha completado. Aunque el significado de "completado" puede variar de una organizacin a otra, habitualmente significa que la funcionalidad est completamente desarrollada y, potencialmente, podra ser entregada o implementada. Si "completado" tiene otro significado, debemos estar seguros de que el Product Owner y los involucrados lo entienden. En caso de existir ms de un equipo, se realiza la presentacin por parte de cada uno. La funcionalidad que no est "completa" no puede ser presentada. Se destaca el trmino completa ya que, para que cada tarea est completa, debe respetar los puntos establecidos en el principio del Sprint. No es posible presentar artefactos que no son funcionales no pueden ser presentados excepto cuando se usan para mejorar el entendimiento de alguna funcionalidad demostrada en alguna demonstracin. Los artefactos no pueden ser mostrados como productos de trabajo, y su uso debe ser minimizado para evitar confundir a los involucrados o exigir que estos entiendan cmo funciona el desarrollo del sistema. La funcionalidad deber ser presentada en las mquinas de los miembros del Equipo y ejecutada desde un servidor lo ms parecido posible a uno de produccin; por lo general, un servidor del entorno de Aseguramiento de la Calidad. El Sprint review meeting comienza con la presentacin de las metas del Sprint, el Product Backlog comprometido y el Product Backlog completado, por parte de uno de los miembros del equipo. Los distintos miembros del equipo pueden alternarse para comentar qu fue lo que anduvo bien y qu fue lo que anduvo mal en el Sprint. La mayor parte del tiempo que insume el Sprint review meeting se utiliza para que los miembros del Equipo encargados de presentar la funcionalidad puedan responder a las preguntas de los involucrados y descubran los cambios que stos desean. Al final de la presentacin, se les pregunta a los involucrados, uno por uno, acerca de sus impresiones, de los cambios que desean y de la prioridad que le otorgan a esos cambios. Por lo general, se hace con el Scrum Master, aunque

25


Martn A. Casamayor

es preferible que se encuentre presente todo el equipo, as todos entienden qu es lo que se quiere. Esto no debe llevar a cambios en el alcance ni a nuevos requerimientos. El Product Owner discute con los involucrados y con el Equipo el potencial cambio del Product Backlog, sobre la base de las impresiones que recibe feedback. Los involucrados son libres de realizar en voz alta cualquier comentario, observacin o crtica sobre el incremento de funcionalidad potencialmente entregable entre presentaciones. Los involucrados pueden identificar una funcionalidad que no ha sido entregada o que no ha sido entregada segn sus expectativas, y solicitar que dicha funcionalidad sea incluida en el Product Backlog para su priorizacin. Los involucrados pueden identificar cualquier funcionalidad que se les ocurra durante la presentacin y solicitar que dicha funcionalidad sea aadida al Product Backlog para su priorizacin. El Scrum Master debe intentar determinar el nmero de personas que se espera que asistan al Sprint review meeting, y organizar la reunin para darles cabida. Al final del Sprint review meeting, el Scrum Master anuncia al Product Owner y a los involucrados el lugar y la fecha del siguiente Sprint review meeting. 2.2.4.4 Las reglas de Scrum (y IV): El Sprint Retrospective Meeting (Reuniones retrospectivas) El Sprint retrospective meeting es una reunin promovida por el Scrum Master en la cual el Equipo discute el Sprint inmediatamente anterior y determina qu se puede cambiar para que el siguiente Sprint sea ms divertido y productivo. Mientras que el Sprint review meeting se centra en 'qu' est construyendo el Equipo, el Sprint retrospective meeting se centra en cmo lo est haciendo. La motivacin para realizar esta reunin es lograr la mejora continua del proceso de desarrollo. Scrum no es una metodologa prescriptiva sino un marco metodolgico que debe ser continuamente adaptado a cada proyecto, equipo o empresa. En caso de que haya ms de un equipo, lo mejor es que cada uno de ellos se rena y realice la tarea descripta ms arriba. Luego de esto, las personas que iban a ver a los otros equipos a la hora de la Daily Meeting se renen y hacen lo mismo. En caso de encontrar una mejor manera de realizar los pasos siguientes, se tomar una decisin junto con el Scrum Master y se la comunicar a cada uno de los equipos. La duracin del Sprint retrospective meeting se limita a 3 horas. Slo asisten el Equipo, el Scrum Master y el Product Owner (la presencia de este ltimo es opcional).

26


Martn A. Casamayor

Al comienzo de la reunin todos los miembros del equipo contestan las siguientes preguntas: Qu ha ido bien durante el ltimo Sprint? Qu se puede mejorar en el prximo Sprint? Qu fallas o problemas se encontraron? El Scrum Master anota las respuestas del Equipo en un formulario de resumen. El Equipo establece en qu orden de prioridades quiere tratar las posibles mejoras. El Scrum Master no est en esta reunin para dar respuestas, sino para facilitar la bsqueda del equipo de las mejores maneras de funcionamiento de Scrum para ellos. Aquellos puntos que merezcan especial atencin pueden ser aadidos al siguiente Sprint, considerado como un Backlog no funcional de alta prioridad. Las reuniones retrospectivas que no aportan nada, que slo se hacen para cumplir resultan frustrantes y negativas y pueden ser un sntoma de que algo no est funcionando bien. Adems de esto, las reuniones retrospectivas son un excelente momento para averiguar si Scrum est funcionando o no: bastar con escuchar al equipo, para saber si Scrum los est ayudando o no. Si Scrum no ayuda al equipo, significa que no est funcionando. Toda metodologa que no ayude al equipo de desarrollo a trabajar mejor y con ms facilidad, sufrir el rechazo de los desarrolladores. De esta manera, por ms que se presione para que el equipo de desarrollo utilice una metodologa, si no le resulta efectiva, la rechazarn.

27


Martn A. Casamayor

Inicio

Cambios y ajustes

Product Backlog

Sprint Retrospective

Sprint Planning MeetingMetas del Sprint

Sprint Review

Fin de Sprint

Sprint Backlog

Cerrar Sprint. Mostrar Demo (avances)

Daily Scrum Meeting 24Hs 15 a 30 min.

Grfico 2.2.4.4-1 Ciclo de Scrum

Cabe destacar que, por ms que se trata de respetar y cumplir todas estas reglas, muchas veces Scrum no funciona. En general, los problemas que aparecen no son

consecuencia de las reglas escritas de Scrum sino de aquellas no-escritas. Por ejemplo: Scrum no especfica ningn proceso de software. Por lo tanto no tiene ninguna regla al respecto. Por esta razn, el presente trabajo no se enfoc en las reglas que actualmente tiene Scrum, sino en qu es lo que necesita para transformarla en una metodologa de gestin gil para proyectos de software.

28


Martn A. Casamayor

2.2.5 Burn Down Scrum tiene un grfico tpico llamado Burn Down (Hughes, 2008). Este grfico se muestra abiertamente a todos los que participan en el proyecto y refleja la cantidad de requisitos del Backlog del proyecto que estn pendientes al comienzo de cada Sprint. Si se traza una lnea que conecte los puntos de todos los Sprint completados, podremos apreciar el progreso del proyecto. As tambin, trazando una lnea entre las tareas de un Sprint que est en desarrollo, podemos saber de manera simple cmo viene el proyecto. Lo normal es que esta lnea sea descendente (cuando todo va bien en el sentido de que los requisitos fueron bien definidos desde el principio y no variaron nunca, y la estimacin se realiz de manera correcta), hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes, a completar en el Sprint). Si durante el proceso se aaden nuevos requisitos, la lnea mostrar una pendiente ascendente en determinados segmentos; mientras que, si se modifican algunos requisitos, la pendiente variar o incluso valdr cero en algunos tramos. A continuacin se presentan algunos casos como ejemplo:

Grfico 2.2.5-1 Burn Down detallado

Como se puede ver, en el grfico 2.2.5-1 se permite apreciar lo que es bsicamente el Burn Down. La lnea gris recta representa lo esperado, o el ideal segn el cual se debe llevar a cabo el proyecto. El eje vertical expresa el esfuerzo, o Story points calculados para el Sprint, mientras que el eje horizontal representa el tiempo en el cual se lleva a cabo. Aparece, adems, una la lnea gruesa que no se desarrolla en lnea recta y representa lo real, lo que va ocurriendo en el proyecto. Tal como se observa, el grfico da una idea de cundo puede haber problemas (luego, si se desea, es posible identificar por medio del Sprint Backlog cules son las tareas que estn ocasionando problemas.

29


Martn A. Casamayor

Grfico 2.2.5-2 Burn Down

En el grfico 2.2.5-2 aprecia la situacin real de un Sprint en curso. La lnea gris punteada expresa lo estimado y la lnea azul representa lo que ocurri en la realidad. Antes de comenzar el proyecto, la fecha de finalizacin estimada era el 12/11; sin embargo, se avanz ms rpidamente de lo esperado, por lo que el programa prev que, si se mantiene esa velocidad de ejecucin, ese Sprint estar terminado el 6/11.

2.2.6 Herramientas para la gestin de proyectos Para aplicar la metodologa existen varias herramientas que dan soporte a la gestin de proyectos que utilizan metodologas giles. En general estas herramientas se pueden aplicar a cualquier metodologa gil, ya que su forma en si es similar: slo varan las reglas o procesos que utilizan, las que no se ven reflejadas en el software. Estas incluyen, por lo general, las siguientes funcionalidades: Visin general del proyecto. Seguimiento de control. Bsqueda de tareas. Lanzamientos por release y planificacin por iteracin. Foros internos de discusin. Posibilidad de describir tareas, en forma global o detallada. Reporte de errores, defectos y correcciones. Muchos de estos softwares tambin incluyen otras herramientas, como la posibilidad de realizar el grfico de Burn Down segn los datos disponibles del proyecto, con detalles sobre fechas e hitos, exportacin de tareas y realizacin de grficos de avance, grficos de esfuerzos del equipo y detalle de cada miembro, realizacin de informes de errores, etc.

30


Martn A. Casamayor

Algunos de los softwares ms difundidos son: Team foundation Server. AccuRev. AgileBuddy. Anthill Pro. Bugzilla ScrumWorks Pro. Version One. Cruise Control. Electric Cloud. Out System. SubVersion. WorkLenz. Estos son algunos de los muchos que existen. Varios de stos son gratuitos o tienen sus versiones bsicas gratuitas. Otros son open source. Adems de existir software para la utilizacin de metodologas giles, tambin existen formas de implementarlas manualmente, con papel, recordatorios tipo post-it, y algunos marcadores. Otra forma es hacerlo en hojas de clculo, utilizando sus funciones para realizar los reportes.

2.2.7 Modelo de proceso de Scrum actual En el grfico 2.2.7-1 se muestra el proceso que se lleva a cabo para realizar las tareas en Scrum, segn el texto de Hunt (Hunt, 2005). Estos son los pasos a seguir si se estn aplicando correctamente las reglas de la metodologa. A dicho diagrama se le agregarn los pasos necesarios para que la metodologa ofrezca mayor calidad para terminar una tarea y ms precisin en los tiempos estimados (Hunt, 2005).

31


Martn A. Casamayor

Grfico 2.2.7-1 Proceso actual de Scrum segn reglas (Autor M. Casamayor)

Uno de los inconvenientes de este proceso consiste en que, si se agrega una nueva tarea al Product Backlog el cual tiene duracin determinada en horas, existe la posibilidad de que esta tarea se sub-divida en varias sub-tareas con una duracin total en horas mayor que la original. Aunque en este diagrama no se muestra, luego de una situacin como la descripta hay que actualizar el Product Backlog para adecuarlo a la realidad. Otro gran inconveniente que existe es que se considera que si la tarea realizada paso los test est correctamente realizada. Sin embargo, a veces ocurre que aunque la afirmacin anterior es cierta, la calidad con que se realiz la tarea es baja. Sera necesario, pues, agregar la condicin de buena calidad dentro del trmino Done; sin embargo, esta condicin representa algo ms que una propiedad.

32


Martn A. Casamayor

3

Anlisis

3.1 Anlisis comparativo entre metodologas3.1.1 Scrum versus XP Como se sabe, existen numerosas metodologas giles adems de Scrum. Se eligi Scrum ya que es la metodologa ms conocida en mi experiencia pero, adems, por ser una de las implementadas con mayor frecuencia dentro de la gran cantidad que actualmente existe, y por estar siendo difundida cada da en ms empresas. Scrum posee una gran cantidad de reglas que procuran la aplicacin correcta de la metodologa. Las reglas dejan en claro la manera de gestionar la metodologa y gestionar un grupo. Sin embargo, hace falta conocer algo ms: qu herramientas de software se han de aplicar. Presenta adems otros problemas, que con frecuencia desconciertan al usuario. Por eso resultar del mayor inters comparar la metodologa Scrum con otra metodologa gil muy utilizada, eXtreme Programming (o XP). El porqu es simple, ambas metodologas se a pesar de ser giles, se complementan en diferentes aspectos. Scrum se enfoca en el control y la gestin del proyecto, mientras que XP se enfoca en los procesos, herramientas y tcnicas para desarrollar el proyecto. Si se mira lo que le hace falta a cada una, Scrum no posee procesos, herramientas ni tcnicas para el desarrollo, mientras que XP est muy centrado en el desarrollo, sin importar tanto la gestin del proyecto. EXtreme Programming (XP): La metodologa XP es un enfoque de la ingeniera de software formulado por Kent Beck. Kent es el autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). El primer proyecto llevado a cabo con esta metodologa fue desarrollado en el ao 1996. Es el ms destacado de los procesos giles de desarrollo de software. Resulta exitosa debido a su permanente bsqueda de la satisfaccin del cliente. Impulsa a los desarrolladores a responder de forma segura a los cambios propuestos por los clientes o usuarios, incluso cuando el proyecto se encuentra en una etapa final. (Extreme Programming: A gentle Introduction) Otra razn para comparar Scrum con XP es que esta ltima no se basa tanto en reglas acerca de cmo gestionar o qu hacer para la gestin, sino que se enfoca en aplicar bien las herramientas que incluye por defecto. De marera simple se podra expresar as: Scrum se enfoca en la gestin y organizacin del proyecto mientras que XP se enfoca, en su mayor parte, sobre las actuales prcticas de programacin A continuacin se presenta un cuadro (tabla 3.1.1-1) comparativo entre Scrum y XP:

33


Martn A. Casamayor

Scrum Documentacin Requiere una documentacin mnima para comenzar a construir el Product Backlog, pero luego no es profundizada. No se aplica ninguno en particular. Slo especifican reglas acerca de cmo gestionar el proyecto, pero no indica nada relacionado con prcticas de ingeniera de software. Para resolverlos se aplica nuevamente Scrum, muchas veces realizando un Sprint de correccin de errores o mantenimiento. En general, no duran ms de 1 semana Son bienvenidos. En caso de que el cambio en los requisitos impacte sobre el actual Sprint, el Scrum Master puede tomar la decisin de finalizarlo, para analizar el cambio de requerimiento y estudiar sus impactos.

XP Puede tener o no documentacin. Lo principal es el desarrollo de la aplicacin.

Procesos e ingeniera de software que se aplican

Incluye muchas prcticas de ingeniera. Por ejemplo, desarrollo manejado por tests, arreglos de errores, programacin de a pares, diseos simples, etc.

Errores luego de cada Sprint y mantenimiento

Se aplica lo mismo que Scrum pero durante menos tiempo ya que, en general, los errores se corrigen o el mantenimiento se realiza antes de la entrega, gracias a los tests que ya posee la metodologa. No est tan preparado como Scrum para los cambios de requerimientos. Igualmente los acepta, aunque en muchos casos es necesario programar nuevos Sprints para contemplar el cambio. Es por eso que esta metodologa slo se desarrolla para necesidades actuales y no tan futuras. Si el cambio es muy drstico, puede llegar a afectar el proyecto de manera significativa.

Cambios de requisitos

Tabla 3.1.1-1 Scrum Vs XP

3.2 Inconvenientes de Scrum3.2.1 Inconvenientes al utilizar Scrum Hoy en da Scrum est siendo utilizada muy ampliamente, habida cuenta de lo reciente que es la metodologa. Gracias a esto se puede encontrar ms documentacin acerca de cmo utilizarla , cules son las debilidades e inconvenientes que presenta, y cules casos con los que nos podemos enfrentar, todo lo cual ayuda a quien lo conozca, a evitar problemas e incluso fracasos en los proyectos. Sin embargo, tambin existen puntos de debilidad por el hecho de que no existen herramientas de software preparados por defecto para la metodologa, lo que conduce a que con frecuencia se la aplique sin utilizar ninguna, sin aplicar mtricas, segn sea ms cmodo, aunque no resulte lo ms conveniente para el proyecto. Como afirm Dean Wampler5, Scrum, sin las prcticas de ingeniera no funcionar en el largo plazo. Es por esto que incorporar prcticas y proceso de la ingeniera de software a la metodologa Scrum dara una notable mejora. Se vera muy reflejado en proyectos en los5

Lder tcnico para equipos de desarrollo de software(www.deanwampler.com)

34


Martn A. Casamayor

cuales la metodologa nunca fue aplicada anteriormente, ya que la posibilidad de fracaso sera menor. Si no se cuenta con un excelente Scrum Master que guie todo el proceso, que conozca esta metodologa, sepa cmo respetar las reglas y cmo aplicar las prcticas de la ingeniera de software, la obtencin de buenos resultados ser improbable. A poco que se investigue, se observar tambin que son muchos los que advierten que no recurrir a los procesos y prcticas de la ingeniera genera problemas. La solucin a este obstculo no existe formalmente, ya que en ninguna parte de la metodologa se dan indicaciones o explicaciones acerca de esto. De vez en cuando se ha tratado de aplicar parches a la metodologa, adaptndole un par de procesos con intencin de mejorarla; sin embargo, al no tener la metodologa reglas bsicas escritas, tampoco estas innovaciones parciales se respetan y, luego de un corto tiempo, aparecen nuevamente dificultades en los proyectos (el tiempo estimado no es el correcto, hay problemas de definicin de requerimientos, etc.). Entonces, Qu habra que modificar para que la metodologa resulte ms til? Qu respuesta dar a este problema, ya conocido pero an sin resolver formalmente? Ese es, precisamente, el propsito de este trabajo. En primer lugar, se detallarn los problemas que presenta Scrum. Luego se darn puntos claves a tener en cuenta para saber si la metodologa funciona correctamente o no y, por ltimo, se aplicarn reglas y se le agregarn procesos de la ingeniera de software de manera que los proyectos que la aplican tengan mayores probabilidades de xito. Entre los puntos a tratar para mejorar la metodologa, se cuentan los siguientes: Cambios de requerimientos: Cmo afrontar de diferente manera los cambios que se producen en los requerimientos, en el curso de un proyecto. Por lo general, son excesivos y generan retrasos apreciables en su desarrollo. Errores de desarrollo: Ver tiempo necesario para la correccin de errores, as como tambin prever los mismo con tiempos de contingencia que se agrega en las estimaciones. Tambin tiempos de test y otros tipos de forma para minimizar los mismos. Estimacin de tiempos: Se propondrn vas alternativas para estimar con mayor precisin los tiempos asignados a las tareas. Equipo: Se estudiar qu perfiles resultan necesarios para llevar adelante el proyecto con xito. Adems de los perfiles, se apreciarn las aptitudes que pueden presentar el grupo y cada uno de sus integrantes. Documentacin: Aunque se sabe que las metodologas giles estn principalmente enfocadas a mantener en marcha una aplicacin antes que a que contar con la documentacin completa, frecuentemente la mayora de las veces esta ltima es omitida por completo. De esta forma, gran parte de los proyectos realizados terminan con documentacin inexistente. Si luego de

35


Martn A. Casamayor

cierto tiempo de terminado el proyecto, surge un error en la aplicacin o es necesario realizar una modificacin se pierde mucho tiempo en recopilar nuevamente toda la informacin relativa al proyecto, ms an si las personas que lo implementaron no estn presentes. Calidad: Puesto que las metodologas giles se implementan para acelerar el tiempo de desarrollo, muchas veces se pasan por alto las deficiencias en la calidad debido a que alcanzar la excelencia requiere tiempo. La calidad no es en la teora algo negociable, pero no sucede lo mismo en la prctica. En consecuencia, se procurar asegurar la calidad de los proyectos que utilicen la metodologa, sin menoscabo de su brevedad. Entre las propuestas a formular se detallarn, cuando sea posible, herramientas de software que incluyan la metodologa por defecto, de forma que se agilice la aplicacin de la modificacin. Tambin se agregarn las reglas necesarias para saber de qu forma se gestionan estas modificaciones.

3.3 Qu intentamos realizar?Hasta el momento se ha explicado las reglas, la forma en que se utiliza y las desventajas que Scrum presenta, las cuales impactan en el proyecto, por ende en la productividad que tiene el equipo para desarrollar el software. Cuando nos referimos al Equipo en Scrum, estamos hablando del Equipo de desarrollo, el cliente, quienes definen los requisitos. Segn el siguiente grfico6, las oportunidades para mejorar la productividad en equipos de diseo de sistemas se basa en varios aspectos. Cada uno de estos puntos tiene sus factores clave. A continuacin se muestran, en el grfico, los puntos en los cuales es posible mejorar la productividad, y cules de ellos sern tratados.

6

El grfico corresponde a la mejora de productividad de software expuesta por Barry W. Boehms. (Boehms, 2007)

36


Martn A. Casamayor

Grfico 3.3-1 Mejora de productividad de softwareStaff

Obtener lo mejor de las personas

Facilidades

Gestion del personal. Herramientas de software y ambientes. Optimizar la forma de realizacin de las tareas

Estaciones de trabajo.

Automatizaciones.

Automatizar la documentacin.

Eliminar pasos inecesarios.

QA.

Automatizar la programacin. Asistencia de softwares de conocimientos (Wikis, documentacin, etc). Eliminar el re trabajo. Practicas modernas de programacin. Ocultamiento de la correcta informacin. Desarrollos iterativos e incrementales.

Mejoras de productividad

Modelos de procesos. Construccin de productos simples. Prototipados rapidos.

Librerias de componentes.

Componentes y recursos.

Generadores de aplicaciones.

Lenguajes de 4ta generacin.

37


Martn A. Casamayor

De todos estos puntos expuestos en el grfico que antecede, slo algunos estn comprendidos en la gestin de una metodologa. Por ejemplo: la tecnologa a utilizar est muy definida, ya que se sabe que Scrum y otras varias metodologas giles estn diseadas para paradigmas orientados a objetos. Esto se debe a que es posible separar muy bien el cdigo de cada tarea bien definida. De esta manera, resulta fcil mantener el orden y una administracin de lo realizado. Por otro lado, hay otros aspectos mejor cubiertos por otras metodologas giles. La ms importante, muy utilizada y con ciertas similitudes respecto a Scrum es XP. En consecuencia, la combinacin de estas dos metodologas giles, nos puede ofrecer un complemento nico. Esa combinacin es, precisamente, la que se describir a continuacin, con la suma de algunos factores no tenidos en cuenta por ninguna de ambas.

38


Martn A. Casamayor

4

DiseoScrum es una excelente metodologa para llevar adelante proyectos de cualquier

ndole, definiendo reglas para la gestin de proyectos. Sin embargo, como se explic ms arriba, no define herramientas ni procesos para su utilizacin. En la comparacin con la metodologa XP se observa que ambas presentan grandes similitudes. Ambas metodologas son giles y abiertas a los posibles cambios que puedan surgir. La diferencia esta dada en que XP se basa en el desarrollo, procesos y el testeo de la aplicacin y el cdigo respectivo, mientras que Scrum se basa en la gestin del proyecto en s. Dado que XP tiene rasgos que complementan a Scrum, se intent alcanzar una integracin entre ambas, dejando como punto principal la gestin del proyecto que es lo que realiza Scrum, pero agregndole las reglas y objetivos propios de otros puntos que presenta XP. Se advierte, no obstante, que algunos de los puntos dbiles de Scrum tambin lo son en XP. Por ejemplo, la documentacin. En consecuencia, en cuanto a este aspecto no nos referiremos a ninguna de las dos. A continuacin se presentan puntos a tener en cuenta para saber si la metodologa funciona correctamente y las posibles mejoras de los puntos dbiles de Scrum.

4.1 Cmo saber si Scrum est funcionando? Puntos claves y dbiles de la metodologaCuando se comienza a aplicar la metodologa Scrum por primera vez existe una pregunta constante. Cmo saber si Scrum est funcionando? (Corral, Geeks, 2008) La

verdad es que Scrum es simple, ya que se basa en sus reglas para gestionar el proyecto. En consecuencia, si se respetan las reglas, se puede estar casi seguro de que se el proyecto est llevando de manera correcta. De todas maneras, se necesita un perodo de aprendizaje, ms an si la mayora de los miembros del Equipo estn implementando Scrum por primera vez. Existen numerosos casos de fracasos al implementar metodologas nuevas que, por lo general, siempre definen reglas y formas de aplicacin. Esto no es ajeno a Scrum. Entonces, si se respetan las reglas, Por qu se puede fracasar utilizando Scrum? Aqu es necesario hablar de las dificultades presentes en los equipos que la implementan, ver qu detalles se observan y hacerlos objeto de anlisis. Las principales dificultades que surgen son generalmente las ms bsicas y se describen a continuacin:

4.1.1 La falta de atencin a los detalles Muchos equipos fracasan en la implantacin de Scrum porque no le prestan atencin a los detalles. En Scrum, los detalles son vitales. Sin la Daily Scrum, no hay Scrum. Sin Product

39


Martn A. Casamayor

Backlog, no hay Scrum. Sin Product Owner, sin Equipo y sin Scrum Master, no hay Scrum. Sin Sprint Planning Meeting, no hay Scrum. Sin Sprint Review, no hay Scrum. En definitiva, sin seguir de manera estricta las reglas de Scrum, no hay Scrum. La solucin para este problema es simple: seguir rigurosamente las reglas de Scrum. Es fcil caer en la tentacin de hacer adaptaciones a la metodologa para cubrir los aspectos que no son satisfactorios en el proyecto. Sin embargo, cuando esto sucede en un equipo que es nuevo en la metodologa es probable que resulte contraproducente. Si se contara con procesos de ingeniera de software que ayuden, las cuales se tengan que cumplir mediante reglas de la metodologa, es altamente factible que no exista necesidad de realizar modificaciones en la metodologa cuando se comienza a utilizar. Si bien es posible realizar estas adaptaciones, no es recomendable. Es mejor volver al procedimiento normal ya que, por lo general, luego de una adaptacin que no funciona, se trata de adaptar otra cosa y as sucesivamente, hasta que se deja de aplicar Scrum por completo. El que ms atento debe estar a todo esto es el Scrum Master.

4.1.2 Entender y formar el equipo multidisciplinario Construir un equipo es muy difcil y construir uno multidisciplinario an ms. Es una de las metas que se debe alcanzar para poder lograr utilizar Scrum y es una tarea muy dura. Un equipo multidisciplinario es muy productivo y, adems, minimiza los riesgos asociados a la rotacin de personal. Los miembros de este equipo se deben llevar bien entre s, colaborar, y cada uno de ellos debe asumir los roles que les corresponden. Slo de esta manera se puede decir que esta tarea est cumplida. Adems, cada integrante del equipo debe poner la misma cantidad de esfuerzo en el proyecto. Y ninguna persona debe restar motivacin a las dems. Cuando se va a asignar una tarea a un miembro del equipo, es necesario tratar de que ste resulte conforme con la tarea que debe desarrollar. Es posible que esto no siempre ocurra pero, si se puede, es lo recomendable. De esta forma, el Scrum Master lograr que, al estar conforme con la tarea que est desarrollando, la calidad del producto de la tarea de cada uno sea superior. Por otra parte, es importante tratar de evitar los cambios de tareas una vez que stas fueron iniciadas. Aunque las reglas de Scrum prohben esto, la realidad es que ocurre muchas veces. Una tarea muy importante del Scrum Master es mantener al equipo constantemente motivado. Debe encontrar la forma de hacerlo en todo momento, de modo que todos sigan enfocados en el proyecto. Adems de esto, debe mantenerse atento a cualquier detalle o sntoma que el equipo o cualquier miembro del mismo manifieste. Algunos libros (como Agile Project Management with Scrum por Ken Schwaber) ofrecen consejos recomendaciones de suma utilidad respecto de este punto.

40


Martn A. Casamayor

4.1.3 Crear y mantener un Product Backlog Construir y estimar el Product Backlog es una tarea compleja. Es ac cuando se capturan todos los requisitos de alto nivel, y es tarea del equipo de Scrum hacerlo de manera correcta. Segn mi experiencia, la captura de requisitos suele ser difcil, pero la mayor dificultad est a la hora de mantener actualizado e ir refinndolo de manera continua. Cuando se comienza a trabajar en las tareas del Product Backlog, por lo general aparecen algunas tareas nuevas que no estaban previstas por desconocimiento del sistema o del negocio, o por algn otro motivo. A veces se decide dividir estas tareas nuevas en subtareas. Si estas nuevas tareas o sub-tareas no se insertan en el Product Backlog, este ltimo deja de ser real, ya que habr horas trabajadas que no quedarn reflejadas en l. De esta forma, al final del Sprint, probablemente no se alcanzar a realizar todas las tareas, a pesar que stas aparentemente no deban demandar ms horas de las previstas. Lo mismo ocurre si una tarea demanda ms horas que las estimadas; en ese caso, stas deben ser actualizadas en el Product Backlog. Por otra parte, cada vez que se realicen tareas de mantenimiento o soporte, stas tambin deberan ser agregadas en un Product Backlog. Si el proyecto es muy grande y luego de varios Sprint queda varias tareas por implementar o corregir, se debe agregar al nuevo Sprint o, en caso de ser necesario, armar un Sprint solo para la realizacin de las mismas.

4.1.4 Recursos humanos no dedicados Muchas empresas no son capaces de mantener recursos dedicados a un proyecto. Si no se mantienen recursos dedicados se tiene a daar la productividad por los continuos cambios de contexto. Muchas organizaciones pasan por alto el costo que representan los cambios de contexto, y no lo incluyen de sus planificaciones. Sin embargo, los cambios de contexto son el problema silencioso de muchos equipos de desarrollo. Un equipo que es sometido continuamente a cambio de contexto, de enfoque, de alcance, difcilmente resultar productivo. La solucin a esto est fuera del alcance del equipo de Scrum, debido a que pasa en general por culturas o situaciones de las empresas. Segn Stephen R. Covey (Covey, 1989) hoy en da las empresas e individuos tienden a priorizar lo urgente, reemplazandolo por lo importante. Y es esto lo que se cree que sucede. Debido a la costumbre de tratar todas las cuestiones como prioritarias, atendiendo en cada momento el asunto que ms ruido provoca y dejando de lado, con este comportamiento, a la posibilidad de establecer una planificacin razonable. Y la ausencia de esta lleva a problemas de productividad relacionadas con la ausencia de objetivos.

41


Martn A. Casamayor

4.1.5 Integracin de las tareas de soporte y mantenimiento Existe una gran dificultad en integrar las tareas de mantenimiento con el nuevo desarrollo, ya sea de tareas o de proyectos. En general los problemas se deben tambin a los recursos no dedicados. Aqu lo fundamental tambin es minimizar los cambios de contexto. Lo ideal sera que quienes realizan mantenimiento de los proyectos pasados sea un equipo diferente al que realiza el desarrollo de los nuevos. Por el contrario, si se trata de correccin y mantenimiento de un proyecto reciente lo ideal es que el mismo equipo que lo desarrollo sea el encargado de esta tarea ya que todava se tiene en conocimiento como se desarrollo el mismo. Sin embargo, esto no es siempre posible. Otra tctica habitual consiste repartir el da entre actividades; por ejemplo, dedicar las maanas para desarrollar un nuevo producto y las tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores. Evidentemente, a la hora de planificar un Sprint, tendremos que restar de la capacidad de nuestro equipo el esfuerzo que estimamos que ser necesario dedicar a tareas de mantenimiento y soporte. Se debe tener en cuenta que una tarea a desarrollar a la hora de elaborar un nuevo producto es la documentacin, la cual tiene mucha importancia para el mantenimiento, como as tambin para el soporte.

4.1.6 Estimacin La estimacin de proyectos es una tarea compleja, este es uno de los puntos ms crticos en todo proyecto de software, ya que si no se hace se es considerablemente preciso, puede conducirlo al fracaso. En Scrum, al igual que en otras metodologas, la estimacin es un aspecto central y se trata de mejorarla Sprint tras Sprint. Estimamos el Product Backlog y estimamos las tareas de cada Sprint. La estimacin es el primer paso para todo el proceso de planificacin, tanto a mediano como a corto plazo. Aqu el principal problema con en el que nos encontramos es que los equipos no tienen experiencia en estimar, sea porque nunca estimaron o porque no conocen la tecnologa o la aplicacin sobre la cual van realizar un desarrollo y, por lo tanto, se les vuelve costoso hacerlo con acierto. Esta dificultad hace que muchos equipos omitan las actividades que Scrum propone en relacin con la estimacin. Resulta imposible hacer una planificacin realista sin realizar las actividades de estimacin. Ejecutar los procesos de estimacin propuestos por Scrum permite obtener una estimacin realista y, adems, aprovechar el propio proceso de estimacin para obtener informacin acerca de qu debemos y qu se pretende construir.

42


Martn A. Casamayor

Existen muchos libros acerca de cmo estimar correctamente, algunos de ellos redactados especficamente para metodologas giles8. Sin embargo, a menos que se conozcan y se tenga idea de cules son las mejores tcnicas a aplicar, es conveniente seguir las pautas bsicas que proporciona Scrum y aplicar mtricas avanzadas para asegurarnos de que las estimaciones realizadas son acertadas. (Schwaber, SCRUM Development Process, pg. 18).

4.1.7 Documentacin El Manifiesto gil afirma que hay que preferir el software desarrollado por sobre la documentacin completa y correcta. La frmula para analizar el retorno de inversin de Scrum es la siguiente: Valor Generado / Costo = RIO (Retorno de inversin). Este RIO se calcula por cada tarea. Consecuentemente, las principales tareas sern aquellas que tienen un RIO mayor. Este valor producido es establecido por el cliente. Y he aqu que la documentacin, especialmente la documentacin tcnica, es algo que al cliente le genera un valor nulo. Sin embargo, este punto de vista cambia cuando piensa ve a mediano o largo plazo. De surgir la necesidad de modificar el software desarrollado hace ya algn tiempo o de implementar en l nuevas funcionalidades, el valor de tener una documentacin clara y real es muy alto. Porque evita perder tiempo (que implica un mayor costo) en desentraar cmo funciona la aplicacin desde el punto de vista tcnico. Por lo general, se documentan datos bsicos como mtodos, alto los principales rasgos y algunos procesos del negocio. No obstante, con frecuencia, el cdigo fuente termina por ser la nica documentacin acerca de la aplicacin. Es por eso que, por lo general, se deberan agregar tareas orientadas a documentar con sus respectivas horas, o bien agregar a la definicin de terminado la documentacin acerca de lo realizado. La documentacin tambin puede ser til para el usuario final. Aunque se piense que el usuario

mejora de la metodologia scrum martin casamayor

Documents