MCGA

METODOLOGAS GILES

Ing. Noelia S Franco

Metodologas giles ............................................................................................................................ 3 Qu es una metodologa gil? ....................................................................................................... 3 Valores de una metodologa gil ..................................................................................................... 3 Metodologas giles ms utilizadas ................................................................................................. 4 Lean Software.................................................................................................................................. 4 Los 7 principios del desarrollo Lean ............................................................................................ 4 Kanban............................................................................................................................................. 7 Limitar el trabajo en curso .......................................................................................................... 8 Mtricas Kanban ......................................................................................................................... 8 XP (Programacin extrema) ............................................................................................................ 8 QU ES PROGRAMACIN EXTREMA O XP? ............................................................................... 9 OBJETIVOS. .................................................................................................................................. 9 Principios bsicos ........................................................................................................................ 9 SCRUM........................................................................................................................................... 15 Qu es SCRUM........................................................................................................................... 15 Historia de Scrum ...................................................................................................................... 15 El proceso .................................................................................................................................. 16 Planificacin de la iteracin ...................................................................................................... 17 Ejecucin de la iteracin ........................................................................................................... 17 Inspeccin y adaptacin ............................................................................................................ 18 Fundamentos de Scrum ............................................................................................................ 18 Requisitos para poder utilizar Scrum ........................................................................................ 19 Beneficios de Scrum .................................................................................................................. 19

Metodologas giles

Qu es una metodologa gil?

Una metodologa gil es una metodologa efectiva par a modelar y documentar un proyecto de software. Es una coleccin de valores, principios y prcticas para modelar software que pueden ser aplicados de manera simple y ligera.

Es un mtodo de ingeniera del software basado en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos autos dirigidos y multidisciplinarios.

Valores de una metodologa gil

Los valores de una metodologa gil son: Individuos e interacciones en lugar de procesos y herramientas Software funcionando en lugar de documentacin detallada Colaboracin hacia el cliente en lugar de negociacin del contrato Responder al cambio en lugar de seguir un plan

Metodologas giles ms utilizadas

A continuacin se muestra un grfico de las tecnologas giles ms utilizadas:

Lean Software
El Desarrollo de Software Lean tiene sus inicios en el Sistema de Produccin de Toyota (TPS) y ayuda a las organizaciones de software a optimizar sus procesos y sus mtodos de produccin de manera de poder entregar sus productos al mercado de manera ms rpida y con mejor calidad. El movimiento Lean puede considerarse como un nuevo mtodo de desarrollo que intenta identificar y erradicar todos los problemas y "desventajas" de metodologas antiguas, como Cascada. Los 7 principios del desarrollo Lean El Desarrollo de Software Lean fue la base para los mtodos del Desarrollo gil de Software, y sus representantes principales como Scrum o Crystal Clear. En uno de los libros ms populares sobre Lean (Implementing Lean Software Development - from Concept to Cash), Mary y Tom Poppendieck explican cmo implementar Lean siguiendo siete principios.

1. Eliminar el desperdicio

Brindar un liderazgo tcnico y de mercado - la organizacin puede ser exitosa si produce productos innovadores y tecnolgicamente avanzados, pero es importante comprender lo que valoran nuestros clientes y conocer la tecnologa que se est usando. Crear solamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos son tiles y estn enfocados en crear valor. Escribir menos cdigo - mientras ms cdigo se tenga, ms pruebas se va a necesitar, por lo que se necesitar ms trabajo. Si escribimos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.

2. Crear conocimiento

Crear equipos de diseo y construccin - el lder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo ms pronto posible con los problemas que surgen, o con las soluciones inventadas. Mantener una cultura de mejora continua - crear un ambiente en donde las personas estn mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algn rea que pueden mejorar. Ensear mtodos de resolucin de problemas - los equipos de desarrollo deberan comportarse como pequeos centros de investigacin, estableciendo hiptesis y realizando varios experimentos rpidos para verificar su validez.

3. Embeber a la calidad

Sincronizar - para lograr una alta calidad en el software nos debemos empezar a ocupar de l antes de empezar a escribir una sola lnea de cdigo. Automatizar - automatizar las pruebas, la construccin, las instalaciones, y cualquier cosa que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualquier cosa que quieran sin preocuparse por si el cambio hace que las cosas dejen de funcionar. Refactorizar- eliminar la duplicacin de cdigo a CERO - cada vez que aparezca la oportunidad, realizar el refactor del cdigo, de las pruebas y de la documentacin para minimizar la complejidad.

4. Postergar el compromiso

Agendar las decisiones irreversibles hasta el ltimo momento responsable - debemos saber hacia dnde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo da a da - lo ms importante es mantener la direccin correcta.

Romper con las dependencias - los componentes deben estar lo ms desacoplados posible para que puedan implementarse en cualquier orden. Mantener opciones - desarrollar mltiples soluciones para todas las decisiones crticas y ver cuales funcionan mejor.

5. Optimizar el total

Enfocarse en el flujo completo de valor - enfocarse en ganar la carrera completa (que es el software). No hay que gastar esfuerzo en optimizar ineficiencias locales, sino en ver el todo y optimizar a la organizacin en su totalidad. Entregar un producto completo - los equipos necesitan tener buenos lderes, y tambin buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.

6. Entregar rpido

Trabajar en bloques pequeos - reducir el tamao del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo, repetir lo bueno y erradicar las prcticas que crean obstculos. Limitar el trabajo a la capacidad - limitar la cola de tareas al mnimo (una o dos iteraciones por delante es suficiente), no hay que tener miedo al quitar elementos de la cola rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. Enfocarse en el tiempo del ciclo, no en la utilizacin - agregar tareas pequeas a la cola que no puedan atascar al proceso por un tiempo largo - reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola

7. Respetar a las personas

Capacitar a los lderes de equipo - darles a los lderes de equipo entrenamiento, guas y espacio libre para implementar el pensamiento Lean en su ambiente. Mover la responsabilidad y la toma de decisiones al nivel ms bajo posible - dejar que las personas piensen y decidan por su cuenta - ellos saben mejor que nadie cmo implementar algoritmos difciles y aplicar tecnologas de ltima generacin. Fomentar orgullo por el trabajo - fomentar la pasin y la participacin del equipo hacia lo que hacen y cmo lo hacen.

Ms info en: http://agilesoftwaredevelopment.com/leanprinciples

Kanban
La palabra Kanban, de origen japons, se compone de dos trminos: Kan que puede traducirse como "visual" y ban, como "insignia", siendo una traduccin aproximada, "insignia visual". El sistema Kanban, orientado al desarrollo de software, est fuertemente ligado al uso del tablero o pizarra Kanban. La pizarra Kanban contiene las tareas que tenemos que desarrollar. La pizarra est estructurada por columnas, que identifican cada una a los distintos estados por los que puede pasar (ms o menos secuencialmente), la tarea: Solicitada Asignada En desarrollo En pruebas Completada Se podra pensar en ms estados: validada por el usuario, implementada en produccin, etc. Lo importante aqu es el aspecto visual, ya que las distintas tarjetas (una por tarea), siguen de izquierda a derecha en la pizarra, los estados. El aspecto de la pizarra sera tal que as:

Limitar el trabajo en curso Otro aspecto fundamental del Kanban es mantener acotado dentro de unos lmites, el trabajo "en curso". La pizarra ayuda mediante su gestin visual. Adems, hay dos conceptos importantes: No podemos comenzar una nueva tarea hasta que la anterior la hayamos terminado. El nmero mximo de trabajo en curso tiene un lmite, que es nuestra capacidad por ciclo o iteracin.

Mtricas Kanban Para cada tarea deberemos obtener los siguientes datos: Fecha y hora de inicio Fecha y hora de fin Tiempo real invertido

Como adems, tendremos la estimacin inicial para la tarea, con los datos anteriores ya tenemos la desviacin respecto a lo estimado. El tiempo promedio para completar una tarea, es tambin importante y a veces conocido como "tiempo de ciclo", ya que es el ciclo medio que nos cuesta pasar una tarea de izquierda a derecha de la pizarra hasta que cogemos una nueva. Ms info: printed.pdf http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-

XP (Programacin extrema)
La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.

QU ES PROGRAMACIN EXTREMA O XP? Metodologa liviana de desarrollo de software Conjunto de prcticas y reglas empleadas para desarrollar software Basada en diferentes ideas acerca de cmo enfrentar ambientes muy cambiantes Originada en el proyecto C3 para Chrysler En vez de planificar, analizar y disear para el futuro distante, hacer todo esto un poco cada vez, a travs de todo el proceso de desarrollo

OBJETIVOS. Establecer las mejores prcticas de Ingeniera de Software en los desarrollo de proyectos. Mejorar la productividad de los proyectos. Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente. Principios bsicos

La Programacin Extrema se basa en 12 principios bsicos agrupados en cuatro categoras:

Retroalimentacin a escala fina

1. El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del

programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java Otros ambientes de pruebas para otros lenguajes como C, C++, JavaScript, XML y servicios Web.
2. Proceso de planificacin: en esta fase, el usuario tendr que escribir sus necesidades,

definiendo las actividades que realizar el sistema. Se crear un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por regla general, cada una de las Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones peridicas durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y sealar aquellos puntos a los que se les ha de dar ms importancia por su dificultad o por su punto crtico.

3. El cliente en el sitio: se le dar poder para determinar los requerimientos, definir la

funcionalidad, sealar las prioridades y responder las preguntas de los programadores. Esta fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la cantidad de documentacin, junto con los altos costes de su creacin y mantenimiento. Este representante del cliente estar con el equipo de trabajo durante toda la realizacin del proyecto.
4. Programacin en parejas: uno de los principios ms radicales y en el que la mayora de

gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los experimentos, este principio puede producir aplicaciones ms buenas, de manera consistente, a iguales o menores costes. Aunque el pair-programming puede no ser para todo el mundo.

Proceso continuo en lugar de por lotes 1. Integracin continua: permite al equipo hacer un rpido progreso implementando las nuevas

caractersticas del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema varias veces al da. Esto reduce los problemas de integracin comunes en proyectos largos y estilo cascada.

2. Refactorizacin: permite a los equipos de programadores XP mejorar el diseo del sistema a

travs de todo el proceso de desarrollo. Los programadores evalan continuamente el diseo y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimizacin del cdigo duplicado y/o ineficiente.
3. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza

de forma rpida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como mximo.

Entendimiento compartido 1. Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma sencilla. 2. Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo

a definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas). 3. Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando en una pieza, menos errores aparecern. 4. Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. 1. La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad. Como dice Beck, est bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas.

PROCESO DE DESARROLLO La programacin extrema parte del caso habitual de una compaa que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo de diseo, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologas tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validacin posterior al mismo.

1. Interaccin con el cliente. En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es mxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificacin. Tiene un papel importante de interaccin con el equipo de programadores, sobre todo despus de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programacin existirn pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms provechosa posible. Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se elimina la fase inicial de recopilacin de requerimientos, y se permite que stos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista de caractersticas que el cliente necesita que existan en el producto final. Estas constan de dos fases: En la primera fase, el cliente describe con sus propias palabras las caractersticas y, es el responsable del equipo, el encargado de informarlo de las dificultades tcnicas de cada una de ellas y de su coste. A consecuencia de este dilogo, el cliente deja por escrito un conjunto de historias y las ordena en funcin de la prioridad que tienen para l. De esta manera ya es posible definir unas fechas aproximadas para ellos. En la segunda fase, el cliente coger las primeras historias a implementar y las dividir en trabajos a realizar. El cliente tambin participa, pero hay ms peso por parte del equipo de desarrolladores, esto dar como resultado una planificacin ms exacta. Este mtodo se repetir para cada historia.

A diferencia de otras tcnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo tcnico ser el 'encargado de catalogar las historias del cliente y asignarles una duracin. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programacin. Las que requieran menos tiempo sern agrupadas, y las que necesiten ms sern modificadas o divididas. Finalmente decir que las historias de los usuarios sern escritas en tarjetas, lo que facilitar que el

cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, as como el trabajo de los programadores que podrn catalogarlas correctamente. Este formato tambin es muy til en el momento de las pruebas de aceptacin.

PLANIFICACIN DEL PROYECTO En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn diferentes iteraciones. Para hacerlo ser necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partcipes de la decisin tomada. Las entregas se tienen que hacer cuanto antes mejor, y con cada iteracin, el cliente ha de recibir una nueva versin. Cuanto ms tiempo se tarde en introducir una parte esencial, menos tiempo se tendr para trabajar con ella despus. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene ms posibilidades de detectarse rpidamente. Una de las mximas a aplicar es, los cambios, no han de suponer ms horas de programacin para el programador, ya que el que no se termina en un da, se deja para el da siguiente. Se ha de tener asumido que en el proceso de planificacin habrn errores, es ms, sern comunes, y por esto esta metodologa ya los tiene previstos, por lo tanto se establecern mecanismos de revisin. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificacin. Cada iteracin necesita tambin ser planificada, es lo que se llama planificacin iterativa, en la que se anotarn las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptacin. Estas planificaciones tambin se harn en tarjetas, en las que se escribirn los trabajos que durarn entre uno y tres das. Es por esto que el diseo se puede clasificar como continuo. Aade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que an no han estado programados. Este tipo de planificacin en iteraciones y el diseo iterativo, hace que aparezca una prctica que no exista en la programacin tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicacin, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cmo van con sus trabajos.

DISEO, DESARROLLO Y PRUEBAS El desarrollo es la parte ms importante en el proceso de la programacin extrema. Todos los trabajos tienen como objetivo que se programen lo ms rpidamente posible, sin interrupciones y en direccin correcta. Tambin es muy importante el diseo, y se establecen los mecanismos, para que ste sea revisado

y mejorado de manera continuada a lo largo del proyecto, segn se van aadiendo funcionalidades al mismo. La clave del proceso de desarrollar XP es la comunicacin. La mayora de los problemas en los proyectos son por falta de comunicacin en el equipo. En XP, aparece un nuevo concepto llamado Metfora. Su principal objetivo es mejorar la comunicacin entre todos los integrantes del equipo, al crear una visin global y comn de lo que se quiere desarrollar. La metfora tiene que ser expresada en trminos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollar con alguna cosa de la vida real. Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir una prueba sencilla, y despus escribir el cdigo para que la pase. Una vez pasada se ampla y se contina. En XP hay una mxima que dice "Todo el cdigo que puede fallar tiene que tener una prueba". Con estas normas se obtiene un cdigo simple y funcional de manera bastante rpida. Por esto es importante pasar las pruebas al 100%. Respecto a la integracin del soft, en XP se ha de hacer una integracin continua, es decir, cada vez se tienen que ir integrando pequeos fragmentos de cdigo, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la integracin final. En todo buen proyecto de XP, tendra que existir una versin al da integrada, de manera que los cambios siempre se realicen en esta ltima versin. Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integracin diaria. Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programacin en parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarn con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el ratn. El principio fundamental de este hecho es realizar de manera continua y sin parar el desarrollo de cdigo. Las parejas tienen que ir cambiando de manera peridica, para hacer que el conocimiento se difunda en el grupo. Est demostrado que de esta manera el trabajo es ms eficaz y tambin se consigue ms y mejor cdigo.

Ms info: http://www.cyta.com.ar/ta0502/b_v5n2a1.htm

SCRUM
Qu es SCRUM Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum est especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovacin, la competitividad, la flexibilidad y la productividad son fundamentales. Scrum tambin se utiliza para resolver situaciones en que no se est entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reaccin ante la competencia, cuando la moral de los equipos es baja y la rotacin alta, cuando es necesario identificar y solucionar ineficiencias sistemticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. Historia de Scrum El concepto de Scrum tiene su origen en un estudio de 1986 [1] sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japn y los Estados Unidos (cmaras de fotos de Canon, fotocopiadoras de Xerox, automviles de Honda, ordenadores de HP y otros). Los equipos que desarrollaron estos productos partan de requisitos muy generales, as como novedosos, y deban salir al mercado en mucho menos del tiempo del que se tard en lanzar productos anteriores. Estos equipos seguan patrones de ejecucin de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboracin entre los jugadores de Rugby y su formacin de Scrum (mel en espaol).

El proceso En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si as se necesita). Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que acta como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversin mediante la replanificacin de objetivos del producto, que realiza durante la iteracin con vista a las siguientes iteraciones. Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificacin de la iteracin
El primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene dos partes:

Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita. Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de tareas de la iteracin necesarias para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera conjunta y los miembros del equipo se auto-asignan las tareas.

Ejecucin de la iteracin Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo). Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunin cada miembro del equipo responde a tres preguntas: Qu he hecho desde la ltima reunin de sincronizacin? Qu voy a hacer a partir de este momento? Qu impedimentos tengo o voy a tener?

Durante la iteracin el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. Elimina los obstculos que el equipo no puede resolver por s mismo. Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Inspeccin y adaptacin El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:

Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo. En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin, replanificando el proyecto. Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules son los problemas que podran impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargar de ir eliminando los obstculos identificados.

Fundamentos de Scrum Scrum se basa en: El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si as se necesita). La priorizacin de los requisitos por valor para el cliente y coste de desarrollo en cada iteracin. El control emprico del proyecto. Por un lado, al final de cada iteracin se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en funcin de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias. La potenciacin del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo. La sistematizacin de la colaboracin y la comunicacin tanto entre el equipo y como con el cliente. El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantacin de una gestin gil de proyectos como Scrum: Cultura de empresa basada en trabajo en equipo, delegacin, creatividad y mejora contina. Compromiso del cliente en la direccin de los resultados del proyecto, gestin del ROI y disponibilidad para poder colaborar. Compromiso de la Direccin de la organizacin para resolver problemas endmicos y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestin basada en la colaboracin y en la facilitacin llevada a cabo por lderes al servicio del equipo. Compromiso conjunto y colaboracin de los miembros del equipo. Relacin entre proveedor y cliente basada en ganar-ganar, colaboracin y transparencia. Facilidad para realizar cambios en el proyecto. Tamao de cada equipo entre 5 y 9 personas (con tcnicas especficas de planificacin y coordinacin cuando varios equipos trabajan en el mismo proyecto). Equipo trabajando en un mismo espacio comn para maximizar la comunicacin. Dedicacin del equipo a tiempo completo. Estabilidad de los miembros del equipo

Beneficios de Scrum Los principales beneficios que proporciona Scrum son: Entrega mensual (o quincenal) de resultados (los requisitos ms prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas: Gestin regular de las expectativas del cliente y basada en resultados tangibles. Resultados anticipados (time to market). Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el mercado, etc. Gestin sistemtica del Retorno de Inversin (ROI). Mitigacin sistemtica de los riesgos del proyecto. Productividad y calidad. Alineamiento entre el cliente y el equipo de desarrollo. Equipo motivado.