Professional Documents
Culture Documents
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.
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 paratrabajar 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 enentornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde
la innovacin, la competitividad, la flexibilidad y laproductividad 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.
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 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
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
mscondiciones 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
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.
o Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que
se autoasign) en los tiempos que proporcion. Si existe falta de compromiso con
respecto al resto de miembros del equipo se har muy evidente en lasreuniones 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
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.
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 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.
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
laiteracin, 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.
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:
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
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
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.
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.
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.
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
delclienterespecto 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
elvalor 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
unademostracin 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.).
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
ungrfico de trabajo pendiente (Burndown chart).
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.
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.
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.
6. Historias de Usuario
6.1. Definicin
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.
6.3. Estructura
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.
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
seleccionaNuevo->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
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.
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)