Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

IBM

English

Sign in (or register)

Technical topics

Evaluation software

Community

Events
This Wiki

Search developerWorks

Wikis
Rational Team Concert for Scrum Projects

Search

Log in to participate

Welcome Gua del Rational Team Concert Guia de Instalacin para DB2 y RTC SCRUM como metodologa
Index Members Trash

You are in: Rational Team Concert for Scrum Projects > SCRUM como metodologa

SCRUM como metodologa

| Updated November 22, 2010 by javakreator7 | Tags: None Page Actions

Metodologa gil: Scrum

1. Introduccin 2. Qu es Scrum? 3. Beneficios 4. Cmo funciona 5. Fundamentos 6. Historias de Usuario

Tags
Find a Tag

academic concert guia rational scrum team

Cloud List

Members

1. Introduccin
Tanto Scrum como Programacin Extrema (XP) requieren que los equipos completen algn tipo de producto potencialmente liberable al final de cada iteracin. Estas iteraciones estn diseadas para ser cortas y de duracin fija.

1 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

Este enfoque en entregar cdigo funcional cada poco tiempo significa que los equipos Scrum y XP no tienen tiempo para teoras. No persiguen dibujar el modelo UML perfecto en una herramienta CASE, escribir el documento de requisitos perfecto o escribir cdigo que se adapte a todos los cambios futuros imaginables. En vez de eso, los equipos Scrum y XP se enfocan en que las cosas se hagan. Estos equipos aceptan que puede que se equivoquen por el camino, pero tambin son conscientes de que la mejor manera de encontrar dichos errores es dejar de pensar en el software a un nivel terico de anlisis y diseo y sumergirse en l, ensuciarse las manos y comenzar a construir el producto.[1]

2. Qu es Scrum?
Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores 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.

3. Beneficios
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: o Gestin regular de las expectativas del cliente y basada en resultados tangibles. o Resultados anticipados ( time to market). o Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el mercado, etc. o Gestin sistemtica del Retorno de Inversin (ROI). o Mitigacin sistemtica de los riesgos del proyecto. Productividad y calidad. Alineamiento entre el cliente y el equipo de desarrollo. Equipo motivado.

4. Cmo funciona
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 que realiza al inicio de cada iteracin. Planificacin de la iteracin El primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene dos partes:
1. 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. 2. 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 autoasignan 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

2 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

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:
1. 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. 2. 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.

4.1. Actividades
4.1.1. Planificacin de la iteracin (Sprint Planning) La planificacin de las tareas a realizar en la iteracin se divide en dos partes: Primera parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas* : o El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteracin (de manera que ayude a tomar decisiones durante su ejecucin) y propone los requisitos ms prioritarios a desarrollar en ella. o El equipo examina la lista, pregunta al cliente las dudas que le surgen, aade ms condiciones de satisfaccin y selecciona los objetivos/requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita. Segunda parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas*. El equipo planifica la iteracin, elabora la tctica que le permitir conseguir el mejor resultado posible con el mnimo esfuerzo. Esta actividad la realiza el equipo dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cmo realizarlo. o Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de tareas de la iteracin (Sprint Backlog) basndose en la definicin de completado. o Realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea. o Cada miembro del equipo se autoasigna a las tareas que puede realizar. * Estos son tiempos mximos en el caso de iteraciones mensuales. En iteraciones de tamao menor el tiempo es proporcionalmente inferior, y se puede ir reduciendo conforme el equipo va ganando experiencia en este tipo de reuniones, aunque tambin depender de la complejidad a desarrollar en la iteracin.

Beneficios Productividad mediante comunicacin y creacin de sinergias: o Todos los miembros del equipo tienen una misma visin del objetivo y se ha utilizado los conocimientos y las experiencias de todos
para elaborar la mejor solucin entregable en el mnimo tiempo y con el mnimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas, etc.

Potenciacin del compromiso del equipo sobre el objetivo comn de la iteracin: o Es todo el equipo quien asume la responsabilidad de completar en la iteracin los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algn impedimento que bloquea el progreso de la iteracin, especialmente si cuando se est llegando al final de la iteracin es necesaria la participacin de todos para poder completar los objetivos
comprometidos.

o Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que se autoasign) en los tiempos que

3 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

proporcion. Si existe falta de compromiso con respecto al resto de miembros del equipo se har muy evidente en las reuniones diarias de sincronizacin del equipo (Scrum daily meeting). Una estimacin conjunta es ms fiable, dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo. 4.1.2. Ejecucin de la iteracin (Sprint) En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un mes natural y hasta de dos semanas). Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto que sea susceptible de ser entregado con el mnimo esfuerzo cuando el cliente (Product Owner) lo solicite. Cada da el equipo realiza una reunin de sincronizacin, donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado de lalista de tareas de la iteracin (Sprint Backlog) y los grficos de trabajo pendiente (Burndown charts). El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. o Elimina los obstculos que el equipo no puede resolver por s mismo. o Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Recomendaciones
Para poder completar el mximo de requisitos en la iteracin, se debe minimizar el nmero de objetivos/requisitos en que el equipo trabaja simultneamente (WIP, Work In Progress), completando primero los que den ms valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteracin, permite tener ms capacidad de reaccin frente a cambios o situaciones inesperadas.

Restricciones
No se puede cambiar los objetivos/requisitos de la iteracin en curso. o En la reunin de planificacin de la iteracin el equipo adquiri el compromiso de completar en la iteracin unos requisitos concretos, bas su plan y organizacin en ellos. Cambiar los objetivos/requisitos de la iteracin dificulta la concentracin del equipo, baja su moral y su compromiso. o El hecho de no poder cambiar los objetivos/requisitos de la iteracin una vez iniciada facilita que el cliente cumpla con su responsabilidad de conocer qu es lo ms prioritario a desarrollar, antes de iniciar la iteracin. o Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos que se estn desarrollando eran los ms prioritarios justo antes de iniciar la iteracin y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas) como para que la probabilidad de cambios una vez iniciada la iteracin sea mnima.

Terminacin anormal de la iteracin

Slo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminacin anormal de la iteracin. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteracin para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el compromiso adquirido. En ese caso, se dar por finalizada la iteracin y se dar inicio a otra mediante una reunin de planificacin de la iteracin. 4.1.3. Reunin diaria de sincronizacin del equipo (Scrum Daily Meeting) El objetivo de esta reunin es facilitar la transferencia de informacin y la colaboracin entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros. 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 al finalizar la reunin poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso conjunto que el equipo adquiri para la iteracin (en la reunin de planificacin de la iteracin). Cada miembro del equipo debe responder las siguientes preguntas en un timebox de cmo mximo 15 minutos: Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que tena planeado? Cul fue el problema? Qu voy a hacer a partir de este momento? Qu impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteracin y en el proyecto? Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la iteracin, donde se actualiza el estado y el esfuerzo pendiente para cada tarea, as como con el grfico de horas pendientes en la iteracin.

Beneficios
Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto: o Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o por que hay dependencias (especialmente si existe un retraso). o Los impedimentos con que se encuentra. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realizacin de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargar de solucionar los impedimentos que el equipo no puede solucionar por s solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos. o Las tareas no planeadas que est realizando que el equipo no conoce y puede que no estn alineadas con el

4 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

compromiso del equipo, aunque l crea que lo que est haciendo es lo mejor que se puede hacer. o Cules son sus necesidades. Cada miembro entiende las necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el mximo valor y no realizar tareas que no proporcionan ningn beneficio al resto del equipo. o Cul es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo est realizando tareas por debajo del rendimiento esperado. Se evita que una persona seale con el dedo a otra, dado que la reunin de sincronizacin pone a todos los miembros del equipo en la misma situacin de tener que explicar en qu tareas estn trabajando. o Cules son los criterios que est utilizando para realizar sus tareas, de manera que estn alineados con los objetivos comunes del equipo. Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cmo trabajan los otros segn sus especialidades y experiencias. Conocer el estado de la iteracin, ver si es posible completar los requisitos a que se comprometi el equipo, en vista de las desviaciones y de las tareas pendientes.

Restricciones
La reunin diaria de estado y sincronizacin del equipo no es para resolver problemas, los problemas se resuelven despus de la reunin. o No a todos los miembros del equipo les interesan todos los detalles de cada tema. o En la reunin los miembros del equipo programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando a resolver problemas, etc. o No puede haber una persona explicando su estado mientras otras "se han apartado" de la reunin para comentar un tema particular. Si apareciese alguna conversacin de inters comn (que debe ser rpida), debe poder ser escuchada por todo el equipo sin distraer el principal objetivo de que todos conozcan en qu estn trabajando los dems. Si la mini conversacin no es del inters de todos, debe hacerse despus de la reunin. El equipo debe contar con unos criterios consensuados sobre el proceso de ejecucin de las de tareas o El proceso de ejecucin de las tareas debe estar consensuado para evitar que cada reunin sea una exposicin de discrepancias entre los miembros del equipo.

Recomendaciones
Realizar la reunin diaria de sincronizacin de pie, para que los miembros del equipo no se relajen ni se extiendan en ms detalles de los necesarios. Realizar las reuniones de colaboracin entre miembros del equipo justo despus de la de sincronizacin.

4.1.4. Demostracin de los requisitos completados (Sprint Review) Reunin informal donde 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, haciendo un recorrido por ellos lo ms real y cercano posible al objetivo que se pretende cubrir. 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.

Se realiza en un timebox de cmo mximo 4 horas.

Beneficios
El cliente puede ver de manera objetiva cmo han sido desarrollados los requisitos que proporcion, ver si se cumplen sus expectativas, entender ms qu es lo que necesita y tomar mejores decisiones respecto al proyecto. El equipo puede ver si realmente entendi cules eran los requisitos que solicit el cliente y ver en qu puntos hay que mejorar la comunicacin entre ambos. El equipo se siente ms satisfecho cuando puede ir mostrando los resultados que va obteniendo. No est meses trabajando sin poder exhibir su obra.

Restricciones
Slo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en funcin de la velocidad de desarrollo y el resultado realmente completado. Un requisito no completado quedar como un requisito ms a replanificar. 4.1.5. Retrospectiva (Sprint Retrospective) Con el objetivo de mejorar de manera continua su productividad y la calidad del producto que est desarrollando, el equipo analiza cmo ha sido su manera de trabajar durante la iteracin, por qu est consiguiendo o no los objetivos a que se
comprometi al inicio de la iteracin y por qu el incremento de producto que acaba de demostrar al cliente era lo que l esperaba o no:

Qu cosas han funcionado bien. Cuales hay que mejorar. Qu cosas quiere probar hacer en la siguiente iteracin. Qu ha aprendido.

5 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

Cules son los problemas que podran impedirle progresar adecuadamente. El Facilitador se encargar de ir eliminando los obstculos identificados que el propio equipo no pueda resolver por s mismo. Notar que esta reunin se realiza despus de la reunin de demostracin al cliente de los objetivos conseguidos en la iteracin, para poder incorporar su feedback y cumplimiento de expectativas como parte de los temas a tratar en la reunin de retrospectiva Se realiza en un timebox de cmo mximo 3 horas (si la iteracin es mensual).

Beneficios
Incrementa la productividad en el proyecto, la calidad del producto (cosa que permite hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo de manera sistemtica, iteracin a iteracin, con resultados a corto plazo. Aumenta la motivacin del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y ms sostenibles) para ir eliminando lo que molesta e impide que sea ms productivo.

Restricciones
En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es frustrante encontrar sistemticamente los mismos obstculos y no poder solucionarlos

4.1.6. Replanificacin del proyecto En las reuniones de planificacin de entregas y/o durante el transcurso de una iteracin, el cliente va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto, aadiendo requisitos, modificndolos, eliminndolos, repriorizndolos, cambiando el contenido de iteraciones y definiendo un calendario de entregas que se ajuste mejor a sus nuevas necesidades [1]. Los cambios en la lista de requisitos pueden ser debidos a: Modificaciones que el cliente solicita tras la demostracin que el equipo realiza al final de cada iteracin sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto. Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc). Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto. Etc. Para realizar esta tarea, el cliente colabora con el equipo: Para cada nuevo objetivo/requisito conjuntamente se hace una identificacin inicial de sus condiciones de satisfaccin (que se detallarn en la reunin de planificacin de la iteracin). El cliente obtiene del equipo la re-estimacin de costes de desarrollo para completar los objetivos/requisitos siguientes, segn la definicin de completado. El equipo ajusta el factor de complejidad, el coste para completar los requisitos y su velocidad de desarrollo en funcin de la experiencia adquirida hasta ese momento en el proyecto. El cliente re-prioriza la lista de objetivos /requisitos en funcin de estas nuevas estimaciones. Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la iteracin en curso, (que de hecho eran los ms prioritarios al iniciar la iteracin). No es posible cambiar los requisitos que se desarrollan durante la iteracin. En la reunin de planificacin de la iteracin el cliente presentar la nueva lista de requisitos para que sea desarrollada.

Beneficios
De manera sistemtica, iteracin a iteracin, se obtienen los siguientes beneficios: El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y posibles desviaciones: o Replanificar el proyecto para obtener un nuevo calendario de entregas que cumpla con sus necesidades actuales. o Incorporar nuevos recursos. o Cancelar el proyecto con los requisitos completados hasta el momento plenamente operativos, si el beneficio pendiente de obtener es menor que el coste de desarrollo [2]. El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan sorpresas de ltima hora.

4.2. Roles
4.2.1. Product Owner
Las responsabilidades del Product Owner (que puede ser interno o externo a la organizacin) son:

Ser el representante de todas las personas interesadas en los resultados del proyecto (internas o externas a la organizacin, promotores del proyecto y usuarios finales [idealmente tambin debera ser un usuario clave] o consumidores finales del producto) y actuar como interlocutor nico ante el equipo, con autoridad para tomar decisiones. Definir los objetivos del producto o proyecto. Dirigir los resultados del proyecto y maximizar su ROI (Return Of Investment). o Es el propietario de la planificacin del proyecto: crea y mantiene la lista priorizada con los requisitos necesarios para

6 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

cubrir los objetivos del producto o proyecto, conoce el valor que aportar cada requisito y calcula el ROI a partir del coste de cada requisito que le proporciona el equipo. o Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas. o Antes de iniciar cada iteracin replanifica el proyecto en funcin de los requisitos que aportan ms valor en ese momento, de los requisitos completados en la iteracin anterior y del contexto del proyecto en ese momento (demandas del mercado, movimientos de la competencia, etc.). Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de cada iteracin: o Participar en la reunin de planificacin de iteracin, proponiendo los requisitos ms prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer. o Estar disponible durante el curso de la iteracin para responder a las preguntas que puedan aparecer. o No cambiar los requisitos que se estn desarrollando en una iteracin, una vez est iniciada. o Participar en la reunin de demostracin de la iteracin, revisando los requisitos completados.

4.2.2. Scrum Master (facilitador)

Lidera al equipo llevando a cabo las siguientes responsabilidades:

Velar por que todos los participantes del proyecto sigan las reglas y proceso de Scrum, encajndolas en la cultura de la organizacin, y
guiar la colaboracin intraequipo y con el cliente de manera que las sinergias sean mximas. Esto implica: o Asegurar que la lista de requisitos priorizada est preparada antes de la siguiente iteracin. o Facilitar las reuniones de Scrum (planificacin de la iteracin, reuniones diarias de sincronizacin del equipo, demostracin, retrospectiva), de manera que sean productivas y consigan sus objetivos. o Ensear al equipo a autogestionarse. No da respuestas, si no que gua al equipo con preguntas para que descubra por s mismo una solucin.

Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteracin (proporcionar un resultado til al
cliente de la manera ms efectiva) y poder finalizar el proyecto con xito. Estos obstculos se identifican de manera sistemtica en lasreuniones diarias de sincronizacin del equipo y en las reuniones de retrospectiva.

Proteger y aislar al equipo de interrupciones externas durante la ejecucin de la iteracin(introduccin de nuevos requisitos, "secuestro"
no previsto de un miembro del equipo, etc.). De esta manera, el equipo puede mantener su productividad y el compromiso que adquiri sobre los requisitos que completara en la iteracin [notar, sin embargo, que el equipo debe reservar tiempo para colaborar con al cliente en la preparacin de la lista de requisitos para la prxima iteracin].

4.2.3. Team (equipo) Grupo de personas que de manera conjunta desarrollan el producto del proyecto. Tienen un objetivo comn, comparten la responsabilidad del trabajo que realizan (as como de sucalidad) en cada iteracin y en el proyecto. El tamao del equipo est entre 5 y 9 personas. Por debajo de 5 personas cualquier imprevisto o interrupcin sobre un miembro del equipo compromete seriamente el compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al finalizar la iteracin. Por encima de 9 personas, la comunicacin y colaboracin entre todos los miembros se hace ms difcil y se forma subgrupos (ver los requisitos de Scrum). De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado en proyectos con 250 personas en varios equipos. Cuando es necesario que ms de un equipo trabaje de manera gil en un mismo proyecto, existen diferentes tcnicas que permiten esta colaboracin, desde el Scrum de Scrums hasta equipos de integracin que dedican parte de su tiempo a trabajar con los equipos de desarrollo, siempre completando incrementos de producto de manera regular. Es un equipo autoorganizado, que comparte informacin y cuyos miembros confan entre ellos. Realiza de manera conjunta las siguientes actividades: Seleccionar los requisitos que se compromete a completar en una iteracin, de forma que estn preparados para ser entregados al cliente. Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto o proyecto. En la reunin de planificacin de la iteracin decide cmo va a realizar su trabajo: o Seleccionar los requisitos que pueden completar en cada iteracin, realizando al cliente las preguntas necesarias. o Identificar todas las tareas necesarias para completar cada requisito. o Estimar el esfuerzo necesario para realizar cada tarea. o Cada miembro del equipo se autoasigna a las tareas. Durante la iteracin, trabajar de manera conjunta para conseguir los objetivos de la iteracin. Cada especialista lidera el trabajo en su rea y el resto colaboran si es necesario para poder completar un requisito. Al finalizar la iteracin: o Demostrar al cliente los requisitos completados en cada iteracin. o Hacer una retrospectiva la final de cada iteracin para mejorar de forma continua su manera de trabajar. El equipo es multidisciplinar: Los miembros del equipo tienen las habilidades necesarias para poder identificar y ejecutar todas las tareas que permiten proporcionar al cliente los requisitos comprometidos en la iteracin. Tienen que depender lo mnimo de personas externas al equipo, de manera que el compromiso que adquieren en cada iteracin no se ponga en peligro. Se crea una sinergia que permite que el resultado sea ms rico al nutrirse de las diferentes experiencias, conocimientos y habilidades de todos. Colaboracin creativa. Los miembros del equipo dedicarse al proyecto a tiempo completo para evitar daar su productividad por cambios de tareas en diferentes proyectos, para evitar interrupciones externas y as poder mantener el compromiso que adquieren en cada iteracin.

7 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

Todos los miembros del equipo trabajan en la misma localizacin fsica, para poder maximizar la comunicacin entre ellos mediante conversaciones cara a cara, diagramas en pizarras blancas, etc. De esta manera se minimizan otros canales de comunicacin menos eficientes, que hacen que las tareas se transformen en un pasa pelota o que hacen perder el tiempo en el establecimiento de la comunicacin (como cuando se llama repetidas veces por telfono cuando la persona no est en su puesto). El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mnimo posible, para poder aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales, engranarse y establecer su organizacin del trabajo.

4.3. Artefactos
4.3.1. Product Backlog (Lista de objetivos / requisitos priorizada) La lista de objetivos/requisitos priorizada representa la visin y expectativas del clienterespecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de completar cada requisito). Dado que reflejar las expectativas del cliente, esta lista permite involucrarle en la direccin de los resultados del producto o proyecto. Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen expresar en forma de historias de usuario. Para cada objetivo/requisito se indica el valor que aporta al cliente y el coste estimado de completarlo. La lista est priorizada balanceando el valor que cada requisito aporta al negocio frente al coste estimado que tiene su desarrollo, es decir, basndose en el Retorno de la Inversin (ROI). En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos completados hasta ese momento), en funcin de la velocidad de desarrollo del (los) equipo(s) que trabajar(n) en el proyecto. Es conveniente que el contenido de cada iteracin tenga una
coherencia, de manera que se reduzca el esfuerzo de completar todos sus objetivos.

La lista tambin tiene que considerar los riesgos del proyecto e incluir los requisitos o tareas necesarios para mitigarlos.

Antes de iniciar la primera iteracin, el cliente debe tener definida la meta del producto o proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni que todos los requisitos estn detallados al mismo nivel. Basta con que estn identificados y con suficiente detalle los requisitos ms prioritarios con los que el equipo empezar a trabajar. Los requisitos de iteraciones futuras pueden ser mucho ms amplios y generales. La incertidumbre y complejidad propia de un proyecto hacen conveniente no detallar todos los requisitos hasta que su desarrollo est prximo. De esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos prioritarios) est repartido en el perodo de ejecucin del proyecto. En el caso del desarrollo de un producto, la lista va evolucionando durante toda la vida del producto (los requisitos "emergen"). En el caso de un proyecto, conforme ste avance irn apareciendo los requisitos menos prioritarios que falten. Esto produce varias ventajas: Se evita caer en parlisis de anlisis al inicio del proyecto, de manera que se puede iniciar antes el desarrollo y el cliente puede empezar a obtener resultados tiles. Se evita analizar en detalle requisitos no prioritarios que podran cambiar durante el transcurso del proyecto, dado que el cliente
conocer mejor cul ha de ser el resultado a conseguir, o bien por que podran ser reemplazados por otros.

Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los requisitos restantes, dado el poco retorno de inversin (ROI) que tienen.

Definicin de completado (definition of done) El cliente y el equipo tienen que acordar la "definicin de completado de los objetivos / requisitos en el proyecto: Debe asegurar que el incremento de producto es potencialmente entregable al cliente al finalizar cada iteracin, que no hay tareas pendientes que puedan impedir utilizar los resultados del proyecto lo antes posible. De este modo, el cliente podr tomar decisiones correctas cuando al final de cada iteracin el equipo le haga una demostracin de los requisitos completados: cambiar las prioridades en funcin de la velocidad de desarrollo, solicitar una entrega del producto desarrollado hasta ese momento, etc. Debe incluir lo necesario para considerar de manera clara que el cliente obtendr lo que necesita segn sus criterios de entregables y de calidad (producto construido, probado, documentado, refactorizado para conseguir calidad interna, etc.). o Adems de esta definicin de completado, a cada objetivo hay que asociarle sus condiciones de satisfaccin, preferiblemente en forma de casos de prueba de aceptacin, en el momento de crear la lista de requisitos priorizada (Product Backlog). o Notar que la definicin de completado tambin sirve como base para identificar las tareas necesarias para conseguir

8 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

cada objetivo/requisito, en la reunin de planificacin de la iteracin (Sprint planning). Para cada objetivo se crearn ms tareas que la definicin de completado (o menos) y con ms significado. Por ejemplo, respecto a que el objetivo tiene que estar construido, pueden aparecer varias tareas, del estilo construir el componente X, modificar la pantalla Y, modificar la BBDD, preparar el script de carga, etc.

Iteracin de entrega (release sprint) Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta ese momento, el equipo puede necesitar aadir una iteracin de entrega, ms corta que las iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta el momento de la entrega final y acabar de corregir defectos detectados en la ltima demostracin.

Uso de la lista Para medir la velocidad de desarrollo del equipo, ver una progresin constante y extrapolar la fecha de las entregas, es conveniente seguir las siguientes recomendaciones: o Los requisitos deben tener un esfuerzo semejante para ser completados. o La estimacin de un requisito no debe ser superior a 10 das (si las iteraciones son de 20 das laborables). Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste estimado en funcin de la incertidumbre de la complejidad de su desarrollo en el momento de introducirlo en la lista. Este factor de coste se ir ajustando conforme las iteraciones avancen y el equipo conozca mejor el producto o proyecto, su contexto y su velocidad de desarrollo con las herramientas y tecnologas que utiliza. Si un requisito depende de otro, se coloca en algn punto por debajo del que depende. Si un requisito no se finaliza en una iteracin, se le vuelve a poner en alguna de las siguientes iteraciones, indicando el coste pendiente de desarrollo. El "origen" permite saber quin podra participar en la definicin de un objetivo/requisito y sera conveniente que estuviese presente en el momento de su demostracin.
El progreso del proyecto y su velocidad con respecto a requisitos completados se muestra en un grfico de trabajo pendiente (Burndown

chart).

4.3.2. Lista de tareas de la iteracin (Sprint Backlog) Lista de tareas que el equipo elabora en la reunin de planificacin de la iteracin (Sprint planning) como plan para completar los objetivos/requisitos seleccionados para la iteraciny que se compromete a demostrar al cliente al finalizar la iteracin, en forma de incremento de producto preparado para ser entregado. Esta lista permite ver las tareas donde el equipo est teniendo problemas y no avanza, con lo que le permite tomar decisiones al respecto. Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y la autoasignacin que han hecho los miembros del equipo.

El progreso de la iteracin y su velocidad con respecto a tareas u horas pendientes se muestra mediante un grfico de trabajo pendiente

(Burndown chart).

Uso de la lista
Los objetivos/requisitos estn ordenados por orden de prioridad para el cliente. o Por ello, signos de falta de foco, problemas o impedimentos seran que se estn completando objetivos que no son los primeros de
la lista, as como tener demasiados objetivos/requisitos en progreso simultneamente.

Si una tarea depende de otra, se coloca en algn punto por debajo de la que depende. Las tareas deben estar identificadas de manera que tengan un coste semejante para ser completadas, entre 4 y 16 horas. Este tamao permitir: o Que las tareas sean suficientemente pequeas como para poder detectar progreso o estancamiento de manera diaria. o Que las tareas no sean muy pequeas, que sean suficientemente relevantes, no generen ruido ni microgestin. o Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas dentro de la iteracin.

El tablero de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteracin (Product Backlog Items) se puede gestionar mediante un tabln de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para cada miembro del equipo se puede utilizar adhesivos de colores ms pequeos sobre cada tarea, de manera que se pueda ver en qu tareas est trabajando cada cual.

El equipo elabora esta lista de tareas en la segunda parte de la reunin de planificacin de la iteracin. La lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo pendiente) a medida que la iteracin avanza, especialmente durante la reunin diaria de sincronizacin.

9 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

Este tabln o cuadro de mandos acta como radiador de informacin tanto para el equipo como para cualquier otra persona relacionada con el proyecto. En el siguiente artculo se muestra cmo construirlo y un ejemplo de su uso: Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard).

4.3.3. Grficos de trabajo pendiente (Burndown Chart) Un grfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se est completando los objetivos/requisitos. Permite extrapolar si el Equipo podr completar el trabajo en el tiempo estimado. Se pueden utilizan los siguientes grficos de esfuerzo pendiente: Das pendientes para completar los requisitos del producto o proyecto (product burndown chart), realizado a partir de la lista de requisitos priorizada (Product Backlog). Horas pendientes para completar las tareas de la iteracin (sprint burndown chart), realizado a partir de la lista de tareas de la iteracin (Iteration Backlog). Este tipo de grfico permite realizar diversas simulaciones: ver cmo se aplazan las fechas de entrega si se le aaden requisitos, ver cmo se avanzan si se le quitan requisitos o se aade otro equipo, etc.

5. Fundamentos
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.

10 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

6. Historias de Usuario 6.1. Definicin

Una historia de usuario es una representacin de un requerimiento de software escrito en una o dos frases utilizando el lenguaje comn del usuario. Las historias de usuario son utilizadas en las metodologas de desarrollo giles para la especificacin de requerimientos (acompaadas de las discusiones con los usuarios y las pruebas de validacin). Cada historia de usuario debe ser limitada, esta debera poderse escribir sobre una nota adhesiva pequea. Las historias de usuario son una forma rpida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rpidamente a los requerimientos cambiantes.

6.2. Caractersticas

Independientes unas de otras: De ser necesario, combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes. Negociables: La historia en si misma no es lo suficientemente explcita como para considerarse un contrato, la discusin con los usuarios debe permitir esclarecer su alcance y ste debe dejarse explcito bajo la forma de pruebas de validacin. Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos ms que para el desarrollador. Estimables: Un resultado de la discusin de una historia de usuario es la estimacin del tiempo que tomar completarla. Esto permite estimar el tiempo total del proyecto. Pequeas: Las historias muy largas son difciles de estimar e imponen restricciones sobre la planificacin de un desarrollo iterativo. Generalmente se recomienda la consolidacin de historias muy cortas en una sola historia. Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificacin debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.

6.3. Estructura

ID: Identificador de la historia de usuario TTULO: Ttulo descriptivo de la historia de usuario DESCRIPCIN: Descripcin sintetizada de la historia de usuario ESTIMACIN: Estimacin del coste de implementacin en unidades de desarrollo (estas unidades representarn el tiempo terico de desarrollo/hombre que se estipule al comienzo del proyecto) PRIORIDAD: Prioridad en la implementacin de la historia de usuario respecto al resto de las historias de usuario. A mayor nmero, mayor prioridad. Otra aproximacin a la priorizacin de tareas se hace a travs del mtodo MoSCoW: o M Must, se debe completar este requerimiento para finalizar el proyecto o S Should, se debe completar este proyecto por todos los medios, pero el xito del proyecto no depende de l. o C Could, se debera completar este requerimiento si su implementacin no afecta a la consecucin de los objetivos principales del proyecto. o W Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo) DEPENDENCIAS: Una historia de usuario no debera ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicaran los IDs de las tareas de las que depende una tarea

El ciclo de vida de la tarjeta se compone de tres fases, conocidas como Las 3 C por sus iniciales en ingls (Card, Conversation, Confirmation): TARJETA (Card), la creacin de la tarjeta en s, con la estructura definida anteriormente y que sirve para determinar QU se debe hacer y cmo planificarlo. CONVERSACION (Conversation), representado por pequeos documentos y anotaciones que sirven para aportar detalles y refinar los datos sobre las caractersticas del requerimiento. CONFIRMACIN (Confirmation), o pruebas de aceptacin. Pruebas consensuadas entre el cliente y el desarrollador y que el cdigo debe superar para dar como finalizada la implementacin del requerimiento.

11 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

7. Utilizando la herramienta Rational Team Concert 7.1. Creando una conexin al repositorio En primer lugar debe asegurarse que Jazz Team Server est corriendo y que el cliente est abierto. Para crear una nueva conexin al repositorio, haga click derecho en Conexiones al repositorio y seleccione Nuevo->Conexin a repositorio de Jazz. Ingrese el URI y el ID de usuario con el password correspondiente.

7.2.Agregar usuarios El siguiente paso es crear usuarios con la finalidad de que puedan participar en ms de un rea de proyecto y potencialmente, usar otro tipo de herramientas almacenadas en el servidor. Vamos a asumir que se est usando Tomcat como servidor y necesitas crear usuarios en un nuevo repositorio. Para crear un nuevo usuario, haga click derecho en conexin al repositorio y selecciona Nuevo->Usuario. Seleccione No cuando el cuadro de dilogo para importar usuario se abra. Ingrese la informacin del usuario que pide la herramienta. El ID que usted ingrese, ser la contrasea para el usuario que est creando. Escoja los permisos que va a tener el usuario. El usuario que va a administrar el proyecto debe tener el permiso de JazzAdmins. - JazzUsers: tiene los permisos por defecto en un rea de proyecto. Estos permisos permiten crear tems de trabajo, ver reportes y usar otras caractersticas definidas por las opciones de seguridad del proyecto. - JazzAdmins: pueden acceder a varias opciones relacionadas con Jazz Team Server y proyectos. Seleccione el tipo de licencia para el usuario - Developer (Desarollador): permite crear plantillas de proceso, reas de proyecto, crear o editar pginas. Este tipo de licencia es apropiada para miembros quienes van a programar y correr aplicaciones. - Build and ClearCase Connector: este tipo de licencia es tpico para usuarios administrativos. - Contributor: es aplicado a usuarios que necesitan solo leer informacin del repositorio. Tambin puede crear tems de trabajo.

7.3.Crear reas de Proyecto El siguiente paso es crear un rea de proyecto, el cual servir como contenedor para los planes, tems de trabajo y otras cosas relacionadas al proyecto que ests creando. Para crear un nuevo rea de Proyecto, haga click derecho en Conexin al repositorio en la pestaa Artefactos y seleccione Nuevo->rea de Proyecto. Ingrese un nombre para el proyecto y pulse Next. Cuando sea crea un rea de Proyecto por primera vez, necesitas una plantilla de proceso, as que haga click en Plantillas de Proceso. Escoja Scrum como plantilla de proceso y selecciona Finalizar.

En la columna de la izquierda, dentro de la pestaa Artefactos, puede ver el nuevo rea de Proyecto creado con sub-carpetas ya creadas, planes, informes, cdigo fuente y elementos de trabajo. En el editor de rea de Proyecto hay informacin relacionada al proyecto. 7.4. Agregar miembros y especificar roles Como creador del rea de Proyecto, usted es el administrador inicial. Por otro lado, los permisos para modificar la estructura del proyecto dentro del proceso Scrum, les pertenecen al Scrum Master y al Product Owner Haga click derecho en el Proyecto que ha creado y seleccione Abrir. Haga click en la flecha Miembros para expandir el panel. Haga en click en Aadir. Seleccione los usaurios que desea aadir.

12 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

Una vez agregados haga doble click en cada uno de ellos apra asignarles roles.

7.5. Crear lneas de tiempo (Sprints) El siguiente paso es definir lneas de tiempo para el proyecto, lo cual quiere decir especificar fechas de comienzo y de trmino para liberar o terminar un sprint

Seleccione Relealse 1.0 y pulse en Editar propiedades tal como se muestra en la imagen: Usted puede crear una iteracin o seleccionar la que est por defecto. El identificador debe de ser nico, pero puede modificarlo de acuerdo a sus necesidades. Ingrese las fechas de comienzo y trmino. Asegrese que el checkbox para Se ha planificado un release para esta iteracin est marcado. Y seleccione Aceptar. Usted podra hacer ms cambios al rea de Proyecto ms adelante si lo desea. Para abrirlo, haga click derecho en en el Proyecto y seleccione Abrir. 7.6. Especificar un rea de Equipo y agregar miembros La tecnologa Jazz puede soportar equipos grandes con mltiples sub-equipos, Dentro de las reas de Proyecto, existen reas de Equipo para organizar a los miembros. Haga click en la pestaa Organizacin de Equipo, Si no est abierta, vaya a Ventana->Mostrar Vista->Organizacin de Equipo para abrirlo. Haga click derecho en el rea de Proyecto y seleccione Nuevo->rea de Equipo. Ingrese un nombre para el rea de Equipo. Agregue a los usuarios que desee como miembros del equipo. Usted puede seleccionar los roles de cada miembro. Una vez finalizada la configuracin, seleccione Grabar.

8. Especificacin de la disponibilidad de los miembros del equipo Para que los clculos del tiempo del trabajo y desempeo sean precisos, es importante ajustar la disponibilidad de los miembros del equipo. Esto debe hacerse incluso si un miembro del equipo est de vacaciones o tiene su participacin limitada. Todos estos ajustes se realizan en la pgina del usuario. Usualmente, los usuarios son los que deberan mantener su rea activa por ellos mismos; sin embargo, como parte importante del clculo del desempeo del equipo correcto, es importante ilustrarlo aqu. 8.1 Si an no se ha realizado esta accin, es importante seleccionar la pestaa de Team Organization en el panel izquierdo y expandir en HAVANNAH FOLDER y el HAVANNAH TEAM. 8.2 Abrir el editor de usuario para algn miembro. Tambin se pueden editar los detalles de dicho usuario. 8.3 Por ejemplo, un miembro X podra estar disponible slo 75% del tiempo. Entonces, lo que se hace es seleccionar la pestaa del WORK ENVIRONMENT que est en la parte inferior, luego en la seccin de WORK ASSIGNMENT o asignaciones de trabajo, seleccionar la linea del TEAM y cambiar las opciones. 8.4 Por defecto, si un usuario es asignado slo a un equipo, el 100% de su tiempo (recursos) es asociado con el equipo. Para bajar la asignacin para el usuario, seleccin la asignacin y pdale un CHANGE o un cambio. Luego descienda la asignacin a 75%. 8.5 Ahora slo acepte o seleccione OK. 8.6 Ahora, si el usuario, tiene por ejemplo un da de vacaciones que se aproxime, sera conveniente cambiar a la pestaa de ausencias agendadas o SCHEDULED ABSENCES y seleccionar NUEVO o NEW en el lado derecho de la lista e ingresar una descripcin y los das o fechas para ese tiempo destinado a vacacionar. Lo siguiente sera aceptar y guardar los cambios con SAVE. 9. Creando un PRODUCT BACKLOG para el proyecto Una de los ms importantes artefactos en la metodologa SCRUM es el PRODUCT BACKLOG. 9.1 Para crear un PRODUCT BACKLOG en este ejemplo, se deber dirigir a la vista de TEAM ARTIFACTS o artefactos del equipo y, en el proyecto creado, seleccionar RELEASE 1.0, click derecho para obtener el men de contexto y luego se seleccionar un NUEVO PLAN (NEW, PLAN) 9.2 En esta nueva ventana de creacin de nuevo Plan, ingrese el nombre PRODUCT BACKLOG y escoja PRODUCT BACKLOG como tipo de plan (PLAN TYPE). 9.3 Para TEAM MEMBERS, TIMELINE e ITERATION, dejarlos en DEFAULT.

13 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

9.4 Ahora, slo se finaliza. Tip: Si usted no pudiera guardar los cambios que se realizan para el nuevo plan que est creando, debera revisar y asignar el rol de SCRUM MASTER para poder crear este artefacto. Es as como un editor multi-pginas abrir el plan de iteraciones del PRODUCT BACKLOG. 9.5 En la pgina de OVERVIWE, usted podr ingresar informacin acerca de su producto usando formato de estilo wiki. 9.6 El rea de adjuntos, al final de la vista de editor (que es visible slo en modo edicin para esta pgina) es un gran lugar para aadir nuevos requerimientos u otra documentacin general que se pertinente para esta entrega; de modo que sean fciles de leer y disponibles para todos los miembros del equipo. Esta rea de la pgina puede contener tambin vnculos a pginas Web o documentos externos de repositorios segn lo que se requiera. 9.7 Ahora, debera poder ir a la pestaa de PLANNED ITEMS para comenzar a aadir los elementos de BACKLOG. Si bien es cierto, hay muchas formas de ver un plan, estas, son llamadas MODES. En el lado derecho de la ventana, usted podr especificar cmo los elementos en el plan deben ser agrupados y qu tipo de elementos debern ser excludos de la vista. Existen modos de vistas que estn predefinidos. Usted podra definir, incluso, su propia vista personalizada. Para hacer esto, usted puede usar las opciones de EDIT | COPY en el panel derecho, debajo de VIEW AS. Otros modos estn almacenados en el servidor y podrn estar disponibles a otros miembros del equipo, de igual modo, todos los cambios que se hagan afectarn a los dems usuarios del PROJECT AREA o REA DE TRABAJO. Importante: Usted puede agrupar elementos del plan de grupo por tipo (BACKLOG, ITERATIONS, TEAMS y WORK BREAKDOWN)

10. Para llenar o asignar elementos de trabajo al PRODUCT BACKLOG En la pestaa de elementos planeados o PLANNED ITEMS para el BACKLOG, comience por aadir elementos del BACKLOG o BACKLOG items. Para la administracin de proyectos SCRUM, los elementos en el PRODUCT BACKLOG son llamados STORIES o, si son muy extensos, EPICS. Una historia o STORY es una descripcin de la funcionalidad que ser implementada en el producto, usualmente citada en trminos de lo que los usuarios quieren y el valor que desean mediante ese producto. Una historia apropiadamente descrita incluye un resumen o lnea de cabecera, alguna descripcin de la innovacin y las condiciones de aceptacin del PRODUCT OWNER. En el ejemplo de proyecto, los elementos son fraseados como STORIES; de modo que su BACKLOG debe estar asignado con historias. 10.1 Primero, coloque por defecto los nuevos elementos para STORY. Esto le permitir entrar rpidamente a los nuevos elementos de trabajo presionando CTRL + ENTER. 10.2 Lo conveniente sera seleccionar, entonces, la carpeta del equipo de proyecto y aadir un WORK ITEM, SET DEFAULT, STORY. 10.3 Para proceder a la creacin, simplemente, vuelva a seleccionar la carpeta del equipo de proyecto y fjese en la opcin ADD WORK ITEM, luego aada una STORY. 10.4 Lo que quedara sera el ingreso de datos pertintentes. 10.5 Ahora, se deberan aadir todos los elementos que son pedidos por el PRODUCT OWNER. 10.6 Finalmente grabar en la parte superior de la ventana, en todo momento es importante grabar su trabajo. 10.7 Luego de que todas las STORIES son aadidas, el siguiente paso para el PRODUCT OWNER es el poner prioridades para ellas. Los valores HIGH (ALTA), MEDIUM(Media), LOW(Baja) estn disponibles para el atributo prioridad. Usted puede asignar prioridades fcilmente usando la lista desplegable. 10.8 Usted puede darle un puntaje a sus prioridades tambin a modo de RANKING, esto se logra arrastrando los elementos en el orden de prioridad. Recuerde que debe agrupar sus elementos al momento de puntuar, si usted arrastra un elemento de nivel medio a un grupo de nivel alto, el motor de trabajo automticamente asignar el nuevo valor de alto a su trabajo. 10.9 Cuando el equipo aade un estimado para la complejidad del elemento, deber ingresar puntos de STORY usando mens de lista desplegable. Es importante recordar esto para EPICS e STORIES Por defecto, estos dos elementos son objetos de trabajo del PRODUCT BACKLOG. En el caso de que el equipo quisiera ver las tareas en el PRODUCT BACKLOG, usted deber agregar ese elemento como un elemento de trabajo del nivel ms alto en el rea de proyecto de configuracin. Para ello, debera realizar lo siguiente: a. Abrir el PROJECT AREA desde la vista de ARTIFACTS. b. Dentro de la pestaa de PROCESS CONFIGURATION, expandir el PROJECT. c. Ahora, deber seleccionar TOP-LEVEL WIRK ITEM TYPES y aadir TASKS u otro tipo de elemento de trabajo seleccionando las opciones correspondientes con los CHECKS. Por supuesto que, no se puede decir mucho de un PRODUCT BACKLOG si todo lo que se tiene son resmenes de STORIES. Para ello, por cada STORY, usted deber poder seleccionarlo dos veces para mostrar su editor y proceder a ingresar el contenido. En los campos de descripcin podra ingresar informacin adicional o detalles de lo que se espera en la historia. El creador de un elemento es automticamente suscrito a l. En caso de que usted no necesite esta opcin, podra ubicar el vnculo SUSCRIBERS en la seccin de QUICK INFORMATION en la parte inferior izquierda y seleccionar UNSUSCRIBE ME para eliminar su suscripcin. Lo siguiente sera ubicar la pestaa de ACCEPTANCE TEST en la parte inferior y aadir las ACCEPTANCE TESTS identificadas por el equipo y el PRODUCT OWNER como prueba de que la STORY ha sido completada satisfactoriamente y podr darse a conocer mediante las expectativas del STAKEHOLDER.

14 de 15

17/04/2014 03:16 p.m.

Rational Team Concert for Scrum Projects : SCRUM como metodologa

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!...

Comments (0)

Versions (1)

Attachments (0)

About

There are no comments.

Feed for this page

| Feed for these comments

About Help Contact us Submit content

Feeds

Report abuse Terms of use Third party notice IBM privacy IBM accessibility

Faculty Students Business Partners

15 de 15

17/04/2014 03:16 p.m.