Vous êtes sur la page 1sur 12

SCRUM

El cliente no sabe lo que quiere.


El cliente puede comenzar el proyecto con requisitos de alto nivel, quizs
no del todo completos, de manera que se vayan refinando en sucesivas
iteraciones. Slo es necesario conocer con ms detalle los requisitos de
las primeras iteraciones, los que ms valor aportan. No es necesario
realizar una recoleccin completa y detallada de todos los requisitos antes de
empezar el desarrollo del proyecto.
Los mismos integrantes del equipo se auto-asignan las tareas.
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al receptor del proyecto.
Desarrollo incremental de los requisitos en bloques temporales cortos
(iteraciones. Ej.: 30 das).
Priorizacin de los requisitos por el valor dado por el cliente.
En un desarrollo iterativo e incremental el proyecto se planifica en
diversos bloques temporales (en el caso de Scrum de un mes natural o hasta
de dos semanas, si as se necesita) llamados iteraciones. Las iteraciones se
pueden entender como miniproyectos: en todas las iteraciones se repite
un proceso de trabajo similar (de ah el nombre iterativo) para
proporcionar un resultado completo sobre producto final, de
manera que el cliente pueda obtener los beneficios del proyecto de forma
incremental. Para ello, cada requisito se debe completar en una nica iteracin:
el equipo debe realizar todas las tareas necesarias para completarlo
(incluuyendo pruebas y documentacin) y que est preparado para ser
entregado al cliente con el mnimo esfuerzo necesario. En cada iteracin el
equipo evoluciona el producto (hace una entrega incremental) a partir de los
resultados completados en las iteraciones anteriores, aadiendo nuevos
objetivos/requisitos o mejorando los que ya fueron completados.

RECOMENDACIONES
Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad
del proyecto, dado que el equipo trabaja de forma ms eficiente cuando tiene
objetivos a corto plazo. Asmismo, con iteraciones cortas la precisin de
las estimaciones aumenta.

PERFILES
Product Owner representa la voz del cliente y del resto de interesados no
implicados directamente en el proyecto. Este perfil es el encargado de definir
los objetivos del proyecto y de garantizar que el equipo trabaja del modo
adecuado para alcanzar dichos objetivos.
El Scrum Master es el encargado de asegurar que el resto del equipo no tiene
problemas para abordar sus funciones y tareas. Gua y ayuda al Scrum Team
para garantizar el cumplimiento de objetivos. En otras palabras, este perfil
ayuda al equipo a mantenerse activo y productivo.

El Scrum Team es el equipo encargado de desarrollar y entregar el producto.

Stakeholders. Este grupo comprende aquellos perfiles interesados en el


producto: directores, dueos, comerciales. Se trata de perfiles que si bien no
forman parte del Scrum Team deben ser tenidos en cuenta.

COMO FUNCIONA SRUM


(1) El proceso comienza con la elaboracin del llamado Product Backlog. Se
trata de un archivo genrico que recoge el conjunto de tareas, los
requerimientos y las funcionalidades requeridas por el proyecto. Cualquier
miembro del equipo puede modificar este documento pero el nico con
autoridad para agregar prioridades es el Product Owner, responsable del
documento.

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, aade condiciones 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). (2) El equipo elabora


la lista de tareas de la iteracin necesarias para desarrollar los requisitos
a que se ha comprometido (Sprint Backlog). La estimacin de esfuerzo
se hace de manera conjunta y los miembros del equipo se autoasignan
las tareas.

(2) La segunda etapa pasa por la definicin del Sprint Backlog,


documento que recoge las tareas a realizar y quin las desempea. Es
interesante asignar las horas de trabajo que va a suponer realizar cada
una de ellas y asignarlas un coste. Si su volumen es muy grande, crear
metas intermedias ser un acierto.

(~)El Sprint es el periodo en el que se realizan todas las acciones pactadas en


el Sprint Backlog y supone entregas parciales para ir testeando el producto
final. El ciclo anterior deber repetirse hasta que todos los elementos del
Blacklog hayan sido entregados. Entre los distintos Sprints no se deben dejar
tiempos sin productividad.
-Se realizan reuniones diarias (15 minutos)

CONTROL: Todas las acciones que realicemos han de tener un control. Es en el


Burn Down donde marcamos el estado y la evolucin del mismo indicando las
tareas y requerimientos pendientes de ser tratados.

REUNIONES
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 (Scrum Master) 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.

Durante la iteracin, el cliente junto con el equipo refinan la lista de requisitos


(para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o
replanifican los objetivos del proyecto para maximizar la utilidad de lo que se
desarrolla y el retorno de inversin.

TERMINO DE LA ITERACIN
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 (Sprint Retrospective) (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

Las reuniones se deben planificar para no perder tiempo. En este Sprint


Planning Meeting el Product Owner prioriza las tareas contenidas en el
Product Backlog.
Con estas tareas en mente se determina el objetivo del nuevo sprint
priorizando las tareas a realizar por el Scrum Team y asignando tiempo a cada
una de ellas. El objetivo debe ser alcanzable y el equipo slo abordar un
conjunto de tareas asumible.

Diariamente se hace un seguimiento del proyecto en esta reunin en la que se


controla el cumplimiento de las tareas asumidas. Daily Scrum En dicha cita se
pactan los objetivos para el da siguiente y se analizan los posibles problemas
que hayan limitado o impedido directamente el cumplimiento de los objetivos.
BENEFICIO
Los beneficios son amplios y repercuten en el equipo, en los Stakeholders y en
la organizacin en su conjunto.

Se fomenta el trabajo en equipo, focalizando todos los esfuerzos en


alcanzar un objetivo comn. Se trata de un modelo basado en la auto-disciplina
y la auto-gestin, lo que repercute positivamente en la responsabilidad.
Respecto al aspecto comunicativo, esta metodologa fomenta la comunicacin
entre los distintos miembros del equipo.

Los Stakeholders tienen un mayor control y transparencia sobre el


proyecto, permitiendo una mejor organizacin. El cliente puede hacer
seguimiento ms cercano de lo que pasa, sin tener que esperar a un resultado
final que no le convenza. Con las metas intermedias se minimizan riesgos.

En definitiva, la adopcin de estas buenas prcticas permite reducir el tiempo


de desarrollo de productos, ms capacidad de adptacin y flexibilidad
frente a un entorno y unos requisitos cambiantes aumentando el valor que se
aporta a los clientes.

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantacin de una gestin gil
de proyectos como Scrum:

Cultura de empresa basada en trabajo en equipo, delegacin,


creatividad y mejora continua.

Compromiso del cliente en la direccin de los resultados del proyecto,


gestin del ROI y disponibilidad para poder colaborar.

Compromiso de la Direccin de la organizacin para resolver problemas


endmicos y realizar cambios organizativos, formando equipos
autogestionados y multidisciplinares y fomentando una cultura de
gestin basada en la colaboracin y en la facilitacin llevada a cabo por
lderes al servicio del equipo.

Compromiso conjunto y colaboracin de los miembros del equipo.


Relacin entre proveedor y cliente basada en ganar-ganar, colaboracin
y transparencia.

Facilidad para realizar cambios en el proyecto.

Tamao de cada equipo entre 5 y 9 personas (con tcnicas especficas


de planificacin y coordinacin cuando varios equipos trabajan en el
mismo proyecto).

Equipo trabajando en un mismo espacio comn para maximizar la


comunicacin.

Dedicacin del equipo a tiempo completo.

Estabilidad de los miembros del equipo

Cultura de empresa

La cultura de la empresa proveedora del proyecto debe estar alineada con la


filosofa de una gestin gil de proyectos como Scrum. Debe fomentar:

El trabajo en equipo y la colaboracin entre todas las personas


implicadas en un proyecto.

Equipos autogestionados a los que se ha delegado la responsabilidad


y autoridad para hacer su trabajo, en contraposicin a la direccin y
control de personas que ejercera un jefe de proyecto tradicional (en
lugar del jefe de proyecto existe la figura del Facilitador).

La creatividad del equipo.

La transparencia y la mejora continua, tanto del contexto de la


organizacin y del proyecto y como de las herramientas del equipo.

Scrum sistematiza la identificacin de obstculos que pueden impedir el


correcto progreso del proyecto. Los problemas previamente existentes en la
organizacin (procesos, personas, herramientas, etc.) y que atentan contra la
productividad se harn ms evidentes cuando se aplique Scrum y ser
necesario irlos solucionando.

Compromiso del cliente


Scrum exige del cliente una alta implicacin y una dedicacin regular:

El cliente tiene la responsabilidad de dirigir los resultados del producto o


proyecto:

o El cliente debe disponer de una visin de alto nivel del producto o


proyecto y tener reflejadas sus expectativas en forma de lista de
requisitos priorizada donde ha indicado el valor que le aportar
cada uno. A partir de los costes de desarrollo que le proporcione el
equipo, priorizar los requisitos en funcin del Retorno de la
Inversin (ROI) ms rpido.

o El cliente replanifica el proyecto en cada iteracin para maximizar


este ROI de manera continua.

Al tratarse de un proyecto que va entregando resultados en iteraciones


regulares, el cliente debe colaborar participando en el inicio de cada
iteracin (reunin de planificacin) y en el fin de cada iteracin
(demostracin), y debe estar disponible durante la ejecucin de cada
iteracin para resolver dudas.

Compromiso de la Direccin

La Direccin debe estar comprometida y apoyar el uso de Scrum:

Se harn muy evidentes los obstculos ya existentes y por venir


que impiden el correcto desarrollo de los proyectos (a nivel de
expectativas del cliente, productividad, calidad, etc.), sean
organizativos, tcnicos, procesos, relaciones entre
personas/departamentos, habilidades de los equipos, etc.

Ser necesario tomar decisiones, realizar cambios organizativos,


alinear a personas y proporcionar recursos para hacer la transicin.
Gestores y equipos debern desaprender formas de trabajar y de
relacionarse a las que estaban habituados y aprender nuevas dinmicas.

o Un proyecto ya no consistir en que cada


Departamento/rea/Unidad realice su parte del trabajo y se la
pase al siguiente. Ser necesario formar equipos autogestionados
y multidisciplinares capaces de conseguir un objetivo por ellos
mismos.

o Habr gestores que tendrn que cambiar sus roles para ser
Facilitadores (Ver el artculo "El buen gestor de un equipo gil") o
Clientes, en una jerarqua de equipos haciendo Scrum de Scrums.
o Se tendr que gestionar aquellas conductas personales que no
permiten que otras personas puedan aportar ideas sobre el qu y
el cmo de un proyecto, que defienden a toda costa su parcela de
responsabilidad, que les cuesta mucho cederla al equipo y dejar
de controlarlo, que no son capaces de delegar tareas o de
colaborar con otras personas en la resolucin de problemas.

Compromiso del equipo

Scrum se basa en el compromiso conjunto y la colaboracin entre los


miembros del equipo. La transparencia entre todos es fundamental para
poder inspeccionar la situacin real del proyecto y as poder hacer las mejores
adaptaciones que permitan conseguir el objetivo comn. Por ello, ser difcil
trabajar utilizando Scrum para las personas que:

No confan en los dems, no permiten que otras personas puedan


aportar ideas sobre el qu y el cmo, no son capaces de colaborar en la
resolucin de problemas ni de delegar tareas.

No son transparentes respecto a su trabajo personal, sea por que


defienden a toda costa su parcela de responsabilidad o por inseguridad
para comunicarse o colaborar, cosa que no permite que sean ayudados.

Su modo de relacin se basa en la generacin de conflicto o bien evitan


entrar en conflictos sanos en que ambas partes ganen (ganar/ganar),
con lo que los problemas realmente no se resuelven sino que crean
conversaciones veladas, de manera que estas personas no acaban de
adquirir un compromiso real con el equipo.

Priorizan su ego, sus intereses personales, de carrera o de


departamento, por encima de los intereses del equipo.

No son capaces de cambiar sus hbitos y salir de su zona de confort,


tienen miedo al cambio, prefieren que se les diga qu tienen que hacer o
quieren decir a los dems qu tienen que hacer.

Quieren seguir siendo los hroes que solucionan los proyectos y/o las
personas de las que depende la empresa.

Relacin entre proveedor y cliente

La relacin entre el cliente y el proveedor del proyecto debe estar


basada en el principio de ganar ganar. En lugar de estar ligados por
un contrato frreo de alcance, tiempo y coste, las dos partes asumen
que habr cambios para que cliente pueda obtener lo que realmente
necesita, no lo que est escrito en un documento inicial o seguir un plan
inicial que vaya perdiendo su sentido. La relacin contractual se
aproxima a un contrato de un equipo por meses, donde el cliente dirige
mes a mes los resultados que el proyecto debe ir proporcionando.

Debe existir transparencia en la ejecucin del proyecto para facilitar


esta relacin. Esta transparencia la facilita de manera regular el propio
proceso de Scrum, especialmente en la actividad de demostracin de los
requisitos completados al final de cada iteracin.

Facilidad para realizar cambios en el proyecto

Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera


incremental en el producto del proyecto y realizar cambios de forma
controlada sin un coste prohibitivo para el cliente. Para ello es necesario:

Disponer de tcnicas y herramientas que faciliten el crecimiento


incremental y la introduccin de cambios.

Mantener la simplicidad y calidad interna del producto que se est


creando. Para cubrir los requisitos actuales del cliente no hay que
realizar ms esfuerzo del que sea necesario y, a la vez, se debe vigilar
no hacer nada en contra de futuros requisitos.

Dado que los requisitos se desarrollan priorizados por su valor, es ms


improbable que ocurran cambios sustanciales en los primeros requisitos
desarrollados, cuando se construye la base del producto. Se fomenta que los
cambios que suelen aparecen cuando el proyecto ya est avanzado se realicen
sobre requisitos que no son tan importantes.

La arquitectura emerge conforme se va necesitando, iteracin a iteracin, con


lo que se asegura que todo lo que se disea se utiliza y se prueba.

Tamao del equipo

El tamao de un 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.

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, con el resultado integrado de los diferentes equipos.

Equipo trabajando en un mismo espacio comn

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, tarjetas en el
tabln de tareas, etc. De esta manera se minimizan otros canales de
comunicacin menos eficientes (llamadas telefnicas, correos electrnicos,
documentos, etc.), 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 tiene que llamar repetidas veces por telfono a una persona
que no est en su puesto, o cuando se interrumpe con una llamada telefnica a
una persona que est concentrada en una tarea).

Dedicacin del equipo a tiempo completo

Los miembros del equipo dedicarse al proyecto a tiempo completo para de esta
manera:

Evitar daar su productividad, que se vera afectada si tuviesen que


ir cambiando de tarea para diferentes proyectos o duplicando el nmero
de reuniones para estos diferentes proyectos. Si el equipo est dedicado
a un nico proyecto es ms sencillo mantener el compromiso que
adquiere en cada iteracin. Como ayuda adicionala conseguir la mxima
productividad, el Facilitador se encarga de proteger al equipo
de interrupciones externas.
Facilitar la gestin de recursos humanos de la organizacin. Esta
gestin se simplifica si en la organizacin las personas se reservan a un
proyecto por iteraciones completas.

Por otro lado, el cliente y el facilitador deben estar dedicados al proyecto el


tiempo necesario para cumplir con sus responsabilidades.

Estabilidad del equipo

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.

BIBLIOGRAFA
SCRUM
http://comunidad.iebschool.com/iebs/general/metodologia-scrum/ (leido)

https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-
scrum.html

https://proyectosagiles.org/que-es-scrum/

https://proyectosagiles.org/requisitos-de-scrum/

https://proyectosagiles.org/fundamentos-de-scrum/

https://proyectosagiles.org/beneficios-de-scrum/

https://proyectosagiles.org/como-funciona-scrum/ {punto x punto}

https://proyectosagiles.org/desarrollo-iterativo-incremental/
Actividades

https://proyectosagiles.org/planificacion-iteracion-sprint-planning/

https://proyectosagiles.org/ejecucion-iteracion-sprint/

https://proyectosagiles.org/reunion-diaria-de-sincronizacion-scrum-daily-
meeting/

https://proyectosagiles.org/demostracion-requisitos-sprint-review/

Ejemplos y detalle de Scrum

https://proyectosagiles.org/base-conocimiento-agil/#metricas-scrum

Vous aimerez peut-être aussi