SCRUM
1. Introducción
“Tanto
Scrum como Programación Extrema (XP) requieren que los equipos completen algún
tipo de producto potencialmente liberable al final de cada iteración. Estas
iteraciones están diseñadas para ser cortas y de duración fija.
Este
enfoque en entregar código funcional cada poco tiempo significa que los equipos
Scrum y XP no tienen tiempo para teorías. No persiguen dibujar el modelo UML
perfecto en una herramienta CASE, escribir el documento de requisitos perfecto
o escribir código 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 también son
conscientes de que la mejor manera de encontrar dichos errores es dejar de
pensar en el software a un nivel teórico de análisis y diseño y sumergirse en
él, ensuciarse las manos y comenzar a construir el producto.
2. ¿Qué
es Scrum?
Scrum
es un proceso en el que se aplican de manera regular un
conjunto de mejores prácticas para trabajar
colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen
en unestudio
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 innovación, la competitividad,
la flexibilidad y la productividadson
fundamentales.
Scrum
también 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 reacción ante la competencia,
cuando la moral de los equipos es baja y la rotación alta, cuando es
necesario identificar y solucionar ineficiencias sistemáticamente o
cuando se quiere trabajar utilizando un proceso especializado en el
desarrollo de producto.
3. Beneficios
Entrega mensual (o quincenal)
de resultados (los requisitos más prioritarios en ese
momento, ya completados) lo cual proporciona las siguientes ventajas:
4. Cómo
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 iteración tiene que proporcionar un resultado completo, un incremento de
producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite.
El
proceso parte de la lista
de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta
lista el clienteprioriza
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 inversión mediante la replanificación
de objetivosque realiza al inicio de cada iteración.
El
primer día de la iteración se realiza la reunión de planificación de la
iteración. Tiene dos partes:
1. Selección de requisitos (4 horas máximo). 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 más
prioritarios que se compromete a completar en la iteración, de manera que
puedan ser entregados si el cliente lo solicita.
2. Planificación de la iteración (4 horas
máximo). El equipo elabora la lista
de tareas de la iteración necesarias para desarrollar los
requisitos a que se ha comprometido. La estimación de esfuerzo se hace de
manera conjunta y los miembros del equipo se autoasignan las tareas.
Cada
día el equipo realiza una reunión
de sincronización (15 minutos máximo). Cada miembro
del equipo inspecciona el trabajo que el resto está realizando (dependencias
entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden
impedir este objetivo) para poder hacer las adaptaciones necesarias que
permitan cumplir con el compromiso adquirido. En la reunión cada miembro del
equipo responde a tres preguntas:
·
¿Qué he
hecho desde la última reunión de sincronización?
·
¿Qué
voy a hacer a partir de este momento?
·
¿Qué
impedimentos tengo o voy a tener?
Durante
la iteración el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de
que no se merme su productividad.
·
Elimina los obstáculos que el equipo no
puede resolver por sí mismo.
·
Protege al equipo de interrupciones
externas que puedan afectar su
compromiso o su productividad.
Inspección y adaptación
El
último día de la iteración se realiza la reunión de revisión de la iteración.
Tiene dos partes:
1. Demostración (4 horas máximo). El
equipo presenta al cliente los requisitos completados en la iteración, en forma
de incremento de producto preparado para ser entregado con el mínimo esfuerzo.
En función 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 iteración, replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El
equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas
que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad.
El Facilitador se encargará de ir eliminando los obstáculos identificados.
Actividades
Planificación de la
iteración (Sprint Planning)
·
El cliente presenta al equipo la lista
de requisitos priorizada del producto o proyecto, pone
nombre a la meta de la iteración (de manera que ayude a tomar decisiones
durante su ejecución) y propone los requisitos más prioritarios a desarrollar
en ella.
·
El equipo examina la lista, pregunta al cliente las dudas que le surgen,
añade más condiciones
de satisfacción yselecciona los
objetivos/requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente
lo solicita.
·
Segunda parte de la reunión. Se realiza en
un timebox de cómo máximo 4 horas*. El equipo planifica la
iteración, elabora la táctica que le permitirá conseguir el mejor resultado
posible con el mínimo 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 cómo realizarlo.
·
Define las tareas necesarias para poder
completar cada objetivo/requisito, creando la lista
de tareas de la iteración (Sprint Backlog) basándose en la definición
de completado.
·
Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
·
Cada miembro del equipo se autoasigna a las tareas que puede realizar.
·
Estos son tiempos máximos en el caso de iteraciones
mensuales. En iteraciones de tamaño menor el tiempo es proporcionalmente
inferior, y se puede ir reduciendo conforme el equipo va ganando experiencia en
este tipo de reuniones, aunque también dependerá de la complejidad a
desarrollar en la iteración.
Beneficios
·
Productividad mediante comunicación y creación de sinergias:
·
Todos los miembros del equipo tienen una
misma visión del objetivo y se ha utilizado los conocimientos y las
experiencias de todos para elaborar la mejor solución entregable en el mínimo
tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias, detectando
conflictos y dependencias entre tareas, etc.
·
Potenciación
del compromiso del equipo sobre el objetivo común de la iteración:
·
Es todo el equipo quien asume la
responsabilidad de completar en la iteración los requisitos que selecciona.
Facilita la ayuda de cualquier miembro si se detecta algún impedimento que
bloquea el progreso de la iteración, especialmente si cuando se está llegando
al final de la iteración es necesaria la participación de todos para poder completar los objetivos
comprometidos.
·
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 las reuniones
diarias de sincronización del equipo (Scrum daily meeting).
·
Una estimación conjunta es más fiable,
dado que tiene en cuenta los diferentes conocimientos, experiencia y
habilidades de los integrantes del equipo.
En
Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de
un mes natural y hasta de dos semanas). Cada iteración tiene que proporcionar un resultado completo, un
incremento de producto que sea susceptible de ser entregado con el mínimo
esfuerzo cuando el cliente
(Product Owner) lo solicite.
·
Cada día el equipo realiza una reunión
de sincronización, 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 iteración (Sprint Backlog) y
los gráficos
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.
·
Elimina los obstáculos que el equipo no
puede resolver por sí mismo.
·
Protege al equipo de interrupciones
externas que puedan afectar su compromiso o su productividad
Recomendaciones
Para
poder completar el máximo de requisitos en la iteración, se debe minimizar
el número de objetivos/requisitos en que el equipo trabaja
simultáneamente (WIP, Work In Progress), completando primero los que den
más valor al cliente. Esta forma de trabajar, que se ve facilitada por la
propia estructura de la lista
de tareas de la iteración, permite tener más capacidad de reacción
frente a cambios o situaciones inesperadas.
Restricciones
·
No se
puede cambiar los objetivos/requisitos de la iteración en curso.
·
En la reunión
de planificación de la iteración el equipo adquirió el compromiso de completar en la iteración unos
requisitos concretos, basó su plan y organización en ellos. Cambiar los
objetivos/requisitos de la iteración dificulta la concentración del equipo,
baja su moral y su compromiso.
·
El hecho de no poder cambiar los
objetivos/requisitos de la iteración una vez iniciada facilita que el cliente cumpla con su responsabilidad
de conocer qué es lo más prioritario a desarrollar, antes de iniciar la iteración.
·
Notar que Scrum minimiza esta necesidad ya
que, por un lado, los objetivos/requisitos que se están desarrollando eran los
más prioritarios justo antes de iniciar la iteración 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 iteración sea mínima.
Terminación anormal de la iteración
Sólo en
situaciones muy excepcionales el cliente o el equipo pueden solicitar una
terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el
contexto del proyecto ha cambiado enormemente y no es posible esperar al final
de la iteración para aplicar cambios, o si el equipo encuentra que es imposible
cumplir con el compromiso adquirido. En ese caso, se dará por finalizada la
iteración y se dará inicio a otra mediante una reunión
de planificación de la iteración.
El
objetivo de esta reunión es facilitar la transferencia de
información y la colaboración entre los miembros del equipopara
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 iteración,
obstáculos que pueden impedir este objetivo) para al finalizar la reunión poder
hacer las adaptaciones necesarias que permitan cumplir con el compromiso conjunto que el
equipo adquirió para la iteración (en la reunión
de planificación de la iteración).
Cada
miembro del equipo debe responder las siguientes preguntas en un time box de cómo máximo 15 minutos:
·
¿Qué he hecho desde la última reunión
de sincronización? ¿Pude hacer todo lo que tenía planeado? ¿Cuál 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 iteración y en el proyecto?
·
Como apoyo a la reunión, el equipo cuenta
con la lista
de tareas de la iteración, donde se actualiza el estado y el
esfuerzo pendiente para cada tarea, así como con el gráfico
de horas pendientes en la iteración.
Beneficios
·
Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto
delante del resto:
·
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).
·
Los impedimentos con que se encuentra. El
resto de miembros del equipo pueden ofrecer ayuda a otros en
la realización 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.
·
Las tareas no planeadas que está
realizando que el equipo no conoce y puede que no estén alineadas con el
compromiso del equipo, aunque él crea que lo que está haciendo es lo mejor que
se puede hacer.
·
Cuáles 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 máximo valor
y no realizar tareas que no proporcionan ningún beneficio al resto del equipo.
·
Cuál 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 señale con el dedo a otra, dado que la reunión de
sincronización pone a todos los miembros del equipo en la misma situación de
tener que explicar en qué tareas están trabajando.
·
Cuáles son los criterios que está
utilizando para realizar sus tareas, de manera que estén alineados con los
objetivos comunes del equipo.
·
Fomentar
el aprendizaje de los
miembros del equipo, ya que pueden ver cómo trabajan los otros según sus
especialidades y experiencias.
·
Conocer el estado de la iteración,
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
reunión diaria de estado y sincronización del equipo no es para resolver
problemas, los problemas se resuelven después de la reunión.
·
No a todos los miembros del equipo les
interesan todos los detalles de cada tema.
·
En la reunión los miembros del equipo
programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando
a resolver problemas, etc.
·
No puede haber una persona explicando su
estado mientras otras "se han apartado" de la reunión para comentar
un tema particular. Si apareciese alguna conversación de interés común (que debe
ser rápida), debe poder ser escuchada por todo el equipo sin distraer el
principal objetivo de que todos conozcan en qué están trabajando los demás. Si
la mini conversación no es del interés de todos, debe hacerse después de la
reunión.
·
El equipo debe contar con unos criterios
consensuados sobre el proceso de ejecución de las de tareas
·
El proceso de ejecución de las tareas debe
estar consensuado para evitar que cada reunión sea una exposición de
discrepancias entre los miembros del equipo.
Recomendaciones
·
Realizar
la reunión diaria de sincronización de pie, para que los miembros del equipo no
se relajen ni se extiendan en más detalles de los necesarios.
·
Realizar las reuniones de colaboración
entre miembros del equipo justo después de la de sincronización.
Reunión
informal donde el equipo presenta al cliente los requisitos completados en la iteración, en
forma de incremento de producto preparado para ser entregado con el mínimo
esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al
objetivo que se pretende cubrir.
En
función 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 iteración, replanificando
el proyecto.
Beneficios
·
El cliente puede ver de manera objetiva
cómo han sido desarrollados los requisitos que proporcionó, ver si se cumplen
sus expectativas, entender más qué es lo que necesita y tomar mejores
decisiones respecto al proyecto.
·
El equipo puede ver si realmente entendió
cuáles eran los requisitos que solicitó el cliente y ver en qué puntos hay que
mejorar la comunicación entre ambos.
·
El equipo se siente más satisfecho cuando
puede ir mostrando los resultados que va obteniendo. No está meses trabajando sin poder exhibir su obra.
Restricciones
Sólo se
pueden mostrar los requisitos completados, para que el cliente no se haga
falsas expectativas y pueda tomar decisiones correctas y objetivas en función
de la velocidad de desarrollo y el resultado realmente completado. Un requisito
no completado quedará como un requisito más a replanificar.
En las
reuniones de planificación de entregas y/o durante el transcurso de una iteración,
el cliente va trabajando en la lista
de objetivos/requisitos priorizada del producto o proyecto, añadiendo requisitos, modificándolos,
eliminándolos, repriorizándolos, 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 demostración que el equipo realiza al final de cada iteración
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:
o Para
cada nuevo objetivo/requisito conjuntamente se hace una identificación inicial
de sus condiciones
de satisfacción(que se detallarán en la reunión
de planificación de la iteración).
o El
cliente obtiene del equipo la re-estimación de costes de desarrollo para
completar los objetivos/requisitos siguientes, según la definición
de completado. El equipo ajusta el factor de complejidad,
el coste para completar los requisitos y su velocidad de desarrollo en función
de la experiencia adquirida hasta ese momento en el proyecto.
o El
cliente re-prioriza la lista de objetivos/requisitos en función de estas
nuevas estimaciones.
·
Hay que notar que el equipo sigue
trabajando con los objetivos/requisitos de la iteración en curso, (que de hecho
eran los más prioritarios al iniciar la iteración). No es
posible cambiar los requisitos que se desarrollan durante la iteración. En la reunión deplanificación
de la iteración el cliente presentará la nueva
lista de requisitos para que sea desarrollada.
Beneficios
·
De manera sistemática, iteración a
iteración, se obtienen los siguientes beneficios:
·
El cliente puede tomar decisiones con
tiempo respecto al progreso del proyecto y posibles desviaciones:
·
Replanificar el proyecto para obtener un
nuevo calendario de entregas que cumpla con sus necesidades
actuales.
·
Incorporar nuevos recursos.
·
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.
·
El plan de
proyecto se actualiza con la velocidad
de desarrollo del equipo, se evitan sorpresas de última hora.
Roles
Product Owner
Las
responsabilidades del Product Owner (que puede ser interno o externo a la
organización) son:
·
Ser el representante de todas las personas interesadas en los resultados del proyecto (internas o externas a la
organización, promotores del proyecto y usuarios finales [idealmente también
debería 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).
·
Es el propietario de la planificación del
proyecto: crea y mantiene la lista
priorizada con los requisitos necesarios para 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.
·
Reparte los objetivos/requisitos en
iteraciones y establece un calendario de entregas.
·
Antes
de iniciar cada iteración replanifica
el proyecto en función de los requisitos
que aportan más valor en ese momento, de los requisitos completados en la
iteración 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
iteración:
·
Participar
en la reunión
de planificación de iteración,
proponiendo los requisitos más prioritarios a desarrollar, respondiendo a las
dudas del equipo y detallando los requisitos que el equipo se comprometer a
hacer.
·
Estar disponible durante el curso de la
iteración para responder a las preguntas que puedan aparecer.
Scrum Master (facilitador)
·
Velar por que todos los participantes del
proyecto sigan las reglas y proceso de Scrum, encajándolas en la cultura
de la organización, y guiar la colaboración intraequipo y con el
cliente de manera que las sinergias sean máximas. Esto implica:
·
Facilitar las reuniones de Scrum (planificación
de la iteración, reuniones
diarias de sincronización del equipo, demostración, retrospectiva), de
manera que sean productivas y consigan sus objetivos.
·
Enseñar al equipo a autogestionarse. No da respuestas, si no que guía al equipo
con preguntas para que descubra por sí mismo una solución.
·
Quitar los impedimentos que el equipo
tiene en su camino para conseguir el objetivo de cada iteración (proporcionar
un resultado útil al cliente de la manera más efectiva) y poder finalizar el proyecto con
éxito. Estos obstáculos se identifican de manera sistemática en lasreuniones
diarias de sincronización del equipo y en las reuniones de retrospectiva.
·
Proteger y aislar al equipo de
interrupciones externas durante la ejecución
de la iteración(introducción 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 completaría en la iteración [notar, sin
embargo, que el equipo debe reservar tiempo para colaborar con al cliente en
la preparación
de la lista de requisitos para la próxima iteración].
Team (equipo)
Grupo
de personas que de manera conjunta desarrollan el producto del proyecto. Tienen
un objetivo común, comparten la responsabilidad del trabajo que realizan (así
como de sucalidad) en
cada iteración y en el proyecto.
El
tamaño del equipo está entre 5 y 9 personas. Por
debajo de 5 personas cualquier imprevistas o interrupción 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 iteración. Por encima de 9 personas, la comunicación y
colaboración entre todos los miembros se hace más difícil 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 más de un equipo trabaje de manera ágil en
un mismo proyecto, existen diferentes técnicas que permiten esta colaboración,
desde el Scrum de Scrums hasta equipos de integración 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
información y cuyos miembros confían entre ellos. Realiza de manera conjunta
las siguientes actividades:
·
Seleccionar los requisitos que se
compromete a completar en una iteración, de forma que estén preparados para ser
entregados al cliente.
·
Estimar la complejidad de cada requisito
en la lista
de requisitos priorizada del producto o proyecto.
·
En la reunión de planificación de la
iteración decide cómo va a realizar su trabajo:
·
Seleccionar los requisitos que pueden
completar en cada iteración, realizando al cliente las preguntas necesarias.
·
Identificar todas las tareas necesarias
para completar cada requisito.
·
Estimar el esfuerzo necesario para
realizar cada tarea.
·
Cada miembro del equipo se autoasigna a
las tareas.
·
Durante la iteración, trabajar de manera
conjunta para conseguir los objetivos de la iteración. Cada especialista lidera
el trabajo en su área y el resto colaboran si es necesario para poder completar
un requisito.
·
Al finalizar la iteración:
·
Hacer una retrospectiva la final de cada iteración 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 iteración.
·
Tienen que depender lo mínimo de personas
externas al equipo, de manera que el compromiso que adquieren en cada iteración
no se ponga en peligro.
·
Se crea una sinergia que permite que el
resultado sea más rico al nutrirse de las diferentes experiencias,
conocimientos y habilidades de todos. Colaboración creativa.
·
Los miembros del equipo dedicarse al
proyecto a tiempo completo para evitar dañar su productividad por cambios de tareas en
diferentes proyectos, para evitar interrupciones externas y sí poder mantener
el compromiso que adquieren en cada iteración.
·
Todos los miembros del equipo trabajan en
la misma localización física, para
poder maximizar la comunicación entre ellos mediante conversaciones cara a
cara, diagramas en pizarras blancas, etc. De esta manera se minimizan otros
canales de comunicación menos eficientes, que hacen que las tareas se
transformen en un “pasa pelota” o que hacen perder el tiempo en el
establecimiento de la comunicación (como cuando se llama repetidas veces por
teléfono cuando la persona no está en su puesto).
·
El equipo debe ser estable durante el proyecto, sus
miembros deben cambiar lo mínimo posible, para poder aprovechar el esfuerzo que
les ha costado construir sus relaciones interpersonales, engranarse y
establecer su organización del trabajo.
Artefactos
Product Backlog (Lista de objetivos / requisitos
priorizada)
La
lista de objetivos/requisitos priorizada representa la visión 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 dirección
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, basándose en el Retorno de la
Inversión (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 función de la velocidad
de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto. Es conveniente que el contenido de cada iteración tenga una
coherencia, de manera que se reduzca el esfuerzo de completar todos sus
objetivos.
·
La lista también tiene que considerar
los riesgos del proyecto e incluir los requisitos o tareas necesarios
para mitigarlos.
·
Antes de iniciar la primera iteración, 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 estén detallados al mismo nivel. Basta con que estén
identificados y con suficiente detalle los requisitos más prioritarios con los
que el equipo empezará a trabajar. Los requisitos de iteraciones futuras pueden
ser mucho más amplios y generales. La incertidumbre y complejidad propia de un
proyecto hacen conveniente no detallar todos los requisitos hasta que su
desarrollo esté próximo. De esta manera, el
esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos
prioritarios) está repartido en el período de ejecución 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 irán apareciendo los requisitos menos
prioritarios que falten. Esto produce varias ventajas:
·
Se evita caer en parálisis de análisis 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 podrían cambiar durante el transcurso del proyecto, dado que
el cliente conocerá mejor cuál ha de ser el resultado a conseguir, o bien por
que podrían 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 inversión (ROI) que tienen.
·
Definición de completado (definition of
done)
·
El cliente y el equipo tienen que acordar
la "definición de completado” de los objetivos / requisitos en
el proyecto:
·
Debe asegurar que el incremento de
producto es potencialmente entregable al cliente al finalizar cada
iteración, 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 iteración el equipo le haga
una demostración
de los requisitos completados:
cambiar las prioridades en función 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 según sus criterios de
entregables y de calidad (producto construido, probado, documentado,
refactorizado para conseguir calidad interna, etc.).
·
Además de esta definición de
completado, a cada objetivo hay que asociarle sus condiciones
de satisfacción, preferiblemente en forma de casos de
prueba de aceptación, en el momento de crear la lista
de requisitos priorizada (Product Backlog).
·
Notar que la definición de completado
también sirve como base para identificar las tareas necesarias para conseguir
cada objetivo/requisito, en la reunión de planificación
de la iteración (Sprint planning). Para
cada objetivo se crearán más tareas que la definición de completado (o menos) y
con más 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.
Iteración de entrega (release sprint)
Cuando
el cliente solicita una entrega de los objetivos/requisitos completados hasta
ese momento, el equipo puede necesitar añadir una iteración de entrega,
más 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 demostración.
Uso de la lista
·
Para medir la velocidad de desarrollo del
equipo, ver una progresión constante y extrapolar la fecha de las entregas, es
conveniente seguir las siguientes recomendaciones:
·
Los requisitos deben tener un esfuerzo
semejante para ser completados.
·
La estimación de un requisito no debe
ser superior a 10 días (si las iteraciones son de 20 días laborables).
·
Cada requisito tiene asociado un factor de
complejidad, que permite ajustar su coste estimado en función 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 tecnologías que utiliza.
·
Si un requisito depende de otro, se coloca
en algún punto por debajo del que depende.
·
Si un requisito no se finaliza en una
iteración, se le vuelve a poner en alguna de las siguientes iteraciones,
indicando el coste pendiente de desarrollo.
·
El "origen" permite saber quién
podría participar en la definición de un objetivo/requisito y sería conveniente
que estuviese presente en el momento de su demostración.
·
El progreso del proyecto y su velocidad
con respecto a requisitos completados se muestra en un gráfico
de trabajo pendiente (Burndown chart).
Lista
de tareas que el equipo elabora en la reunión
de planificación de la iteración (Sprint planning) como plan para completar los objetivos/requisitos seleccionados
para la iteracióny que
se compromete a demostrar al cliente al finalizar la iteración, 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 autoasignación que han hecho los miembros del equipo.
El
progreso de la iteración y su velocidad con respecto a tareas u horas
pendientes se muestra mediante un gráfico
de trabajo pendiente (Burndown chart).
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 priorización
de los requisitos por valor para el cliente y coste de desarrollo en cada iteración.
·
El control
empírico del proyecto. Por un lado, al
final de cada iteración se demuestra al cliente el resultado real obtenido, de
manera que pueda tomar las decisiones necesarias en función 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 potenciación
del equipo, que se compromete a entregar unos
requisitos y para ello se le otorga la autoridad necesaria para organizar su
trabajo.
·
La sistematización de la colaboración
y la comunicación 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
prácticas se apoyan unas a otras y su selección tiene origen en un estudio
de la manera de trabajar de equipos altamente productivos.
Historias
de Usuario
Definición
Una historia
de usuario es una representación de un requerimiento de software escrito
en una o dos frases utilizando el lenguaje común del usuario. Las historias de
usuario son utilizadas en las metodologías de desarrollo ágiles para
la especificación de requerimientos (acompañadas de las discusiones con los
usuarios y las pruebas de validación). Cada
historia de usuario debe ser limitada, esta debería poderse escribir sobre una
nota adhesiva pequeña.
Las
historias de usuario son una forma rápida 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 rápidamente a los requerimientos cambiantes.
Características
·
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 explícita como para considerarse un contrato, la discusión
con los usuarios debe permitir esclarecer su alcance y éste debe dejarse
explícito bajo la forma de pruebas de validación.
·
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 más que para el
desarrollador.
·
Estimables: Un resultado de la discusión
de una historia de usuario es la estimación del tiempo que tomará completarla.
Esto permite estimar el tiempo total del proyecto.
·
Pequeñas: Las historias muy largas son
difíciles de estimar e imponen restricciones sobre la planificación de un
desarrollo iterativo. Generalmente se recomienda la consolidación 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 verificación debe automatizarse, de manera que pueda ser
verificada en cada entrega del proyecto.
Estructura
·
ID: Identificador de la historia de usuario
·
TÍTULO: Título descriptivo de la historia de usuario
·
DESCRIPCIÓN: Descripción sintetizada de la historia de usuario
·
ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo
(estas unidades representarán el tiempo teórico de desarrollo/hombre que se
estipule al comienzo del proyecto)
·
PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto
al resto de las historias de usuario. A mayor número, mayor prioridad. Otra
aproximación a la priorización de tareas se hace a través del método
MoSCoW:
·
M – Must, se debe completar este
requerimiento para finalizar el proyecto
·
S – Should, se debe completar este
proyecto por todos los medios, pero el éxito del proyecto no depende de él.
·
C – Could, se debería completar este
requerimiento si su implementación no afecta a la consecución de los objetivos
principales del proyecto.
·
W – Would, se puede completar este
requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)
·
DEPENDENCIAS: Una historia de usuario no
debería ser dependiente de otra historia, pero a veces es inevitable. En este
apartado se indicarían 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 inglés (Card, Conversation, Confirmation):
·
TARJETA (Card), la creación de la tarjeta en sí, con la estructura
definida anteriormente y que sirve para determinar QUÉ se debe hacer y cómo
planificarlo.
·
CONVERSACION (Conversation), representado por pequeños documentos y anotaciones
que sirven para aportar detalles y refinar los datos sobre las características
del requerimiento.
·
CONFIRMACIÓN (Confirmation), o pruebas de aceptación. Pruebas consensuadas
entre el cliente y el desarrollador y que el código debe superar para dar como
finalizada la implementación del requerimiento.
No hay comentarios. :
Publicar un comentario