Universidad Nacional

Federico Villarreal
Ao de la Diversificacin Productiva y del Fortalecimiento de la
Educacin

Facultad
Sistemas

Escuela
Curso

Facultad de Ingeniera Industrial y de

:
:

Ingeniera de Sistemas

Gerencia de Proyectos de Tecnologa de

Informacin Y Comunicaciones

Profesor

Javier Canchano Miguel Quionez

Tema

Metodologas Agiles

Alumnos

- Chero Vargas Guido Fernando

- Cuevas Tito, Mario
- Pinedo Delgado, Fermn Orlando

2015

Metodologas Agiles

Pgina 1

INDICE
INTRODUCCIN..3
METODOLOGIAS AGILES.4
KAMBAN9
EXTREMA PROGRAMACION XP11
SCRUM..............13

Metodologas Agiles

Pgina 2

INTRODUCCIN

En los ltimos aos se ha percatado que muchos proyectos pblicos y privados, se han
puesto en cuestin, producto de los modelos, mtodos, tcnicas tradicionales, que
escapaban casi siempre de la realidad operativa; y es hoy donde se pone en manifiesto
una nueva tendencia, la denominada el cuerpo de conocimiento de la Gestin de
proyectos (Project Management).
Si bien es claro que las metodologas tradicionales en la gestin de proyectos, tuvo sus
orgenes en el sector industrial, y luego fueron extendindose a otros mbitos y con
dcadas en el sector servicios y tambin en el sector softwares;, se ha demostrado
menos eficaces cuando la gestin de un proyecto presenta ya desde su misma
concepcin- un grado importante de incertidumbre en su desarrollo que finalmente no
permite una planificacin adecuada y lineal; y ante todos estos fracasos demostrados
con altos costos y fracasos organizacionales un sector fue quien decidi apostar por un
denominador diferente y de riesgo y que hoy se est convirtiendo el perfil
organizacional y el de los nuevos profesionales en donde los resultados y el tiempo
(Oportunidad) priman en el xito o fracaso.
La hoy tan llamada agilidad de proyectos, es el competidor fuerte del xito o fracaso,
aunque no se tengan muchas experiencias documentadas y en el mercado se encuentran
distintos modelos y tcnicas, todas ellas agrupadas en un conjunto de experiencias y
modelos que resumen solo la practicidad en el enfoque y desarrollo colaborativo.

Metodologas Agiles

Pgina 3

Metodologas Agiles

Pgina 4

El Manifesto Agil: Engloba metodologias que hasta ese momento se le conocia como "Metodologias de
Desarrollo de Software de peso liviano"

Programacion Extrema (XP): Kent Beck desarrolla el concepto de Programacion Extrema, formulo
conceptos de Historias de Usuarios y Planifcacion de Releases. La metodologia especifca buenas
practicas para la planifcacion, gestion, diseo, codifcacion y pruebas.
Desarrollo de Software Adaptativo: La idea evoluciono hacia las metodoligias de Desarrolllo Rapido de
Aplicaciones (RAD), la metodologia propone un ciclo de vida de 3 fases: "Especulacion, Colaboracion y
Aprendizaje".

Scrum: Ideado por Ken Schwaber y Jef Sutherland, como se sabe Scrum es practicamente el estandar de
facto para el desarrollo agil.

Mtodos Crystal, el punto de inicio de la evolucin de las metodologas de desarrollo de software que
eventualmente resultaron en lo que hoy se conoce como el movimiento gil.

Un Paper de E.A. Edmonds presenta el concepto de "Proceso de Desarrollo de Software Adaptativo" en

1974. Asimismo, tambin durante los 70, Tom Gild publica conceptos sobre la Gestin de Proyectos
Evolutiva (EVO).

Taiichi Ohno inventa el mtodo Kanban en Toyota. El Lean Manufacturing (Manufactura esbelta) es una
fuente de inspiracin y precursor del movimiento gil.

2001
1999
1999
1995
1992
1974
1940
1930

Walter Shewhart propone el ciclo "Planear", "Hacer", "Estudiar" y "Actuar"

Lnea de Tiempo Metodologas Agiles

Las metodologas agiles hace referencia a
tcnicas que nos permiten optimizar la
gestin de proyectos, cuyo nacimiento se
origina con el fin de buscar nuevas
alternativas y dejar atrs los mtodos
clsicos, como por ejemplo: El Modelo de
Madurez o Capability Maturity Model
(CMM).
METODOLOGAS AGILES

Manifiesto gil: Surge de una reunin que fue convocada por Kent Beck, a travs de la
cual 17 crticos buscaron una alternativa de solucin frente a las metodologas formales
como es el caso de CMM, ya que las consideraban herramientas demasiado
complicadas y rgidas por su carcter normativo.
Los cuatro postulados que manifiestan son los siguientes:
1. Valoramos ms a los individuos y su interaccin que a los procesos y las
herramientas:
Existen muchas tareas que requieren talento y
necesitan personas que lo aporten y por ende
trabajen con una actitud adecuada.
El know how o saber cmo hacer los procesos
tiene un valor muy importante es por ello que
se le da el mayor protagonismo a los
individuos, sin dejar de lado la eficiencia que
tienen las herramientas utilizadas.

2. Valoramos ms el Software que funciona que la documentacin exhaustiva:

Se logra un efectivo y enriquecedor Feedback cuando
se anticipa cmo ser el funcionamiento del producto
final, observando prototipos previos o partes ya
elaboradas.
El manifiesto gil no da por intil la documentacin, solo
la documentacin que es innecesario, as mismo los
documentos permiten la transferencia de conocimiento,
registran la informacin histrica y en muchas cuestiones
legales o normativas son obligatorios.
La comunicacin a travs de documentacin no ofrece la
riqueza y generacin de valor que logra la comunicacin
directa entre las personas, por eso siempre que sea
posible debe preferirse reducir al mnimo el uso de
documentos.

Metodologas Agiles

Pgina 5

3. Valoramos ms la colaboracin con el cliente que la negociacin

contractual:
Las practicas agiles estn destinadas para productos cuyo detalle resulta difcil
prever al principio del proyecto; y si se
detallara al inicio, el resultado final tendra
menos valor.
El objetivo de un proyecto gil no es controlar
la ejecucin conforme a procesos y
cumplimiento de planes, sino proporcionar el
mayor valor posible al producto.
En conclusin es recomendable una relacin
de implicacin y colaboracin continua con el
cliente; ms que una contractual de delimitacin de responsabilidades.

4. Valoramos ms la respuesta al cambio que el seguimiento de un plan:

Los principales valores de la gestin gil son la anticipacin y la adaptacin,
diferentes a los de la gestin de proyectos ortodoxa: Planificacin y control que
evite desviaciones del plan.

Metodologas Agiles

Pgina 6

Principios del Manifiesto gil;

Prioridad satisfacer al cliente mediante la entrega temprana

y continua de software de valor

Aceptamos que lso requisitos cambien, incluso en etapas tardias del

desarrollo. Los procesos Agiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente

Entregamos software funcional frecuentemente, entre dos

semanas y dos meses, con preferencia al periodo de timepo mas
corto posible.

Los responsabels de negocio y los desarrolladores

trabajamos juntos de forma cotidiana durante todo el
proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay

que darles el entorno y el apoyo que necesitan y confarles la
ejecucion del trabajo.

El mtodo ms efciente y efectivo de comunicar informacin al

equipo de desarrollo y entre sus miembros es la conversacin cara
a cara.

El software funcionando es la medida principal de progreso

Los procesos giles promueven el desarrollosostenible. Los promotores,

desarrolladores y usuariosndebemos ser capaces de mantener un ritmo
constantede forma indefnida

La atencin continua a la excelencia tcnica y albuen

diseo mejora la Agilidad

10

La simplicidad, o el arte de maximizar la cantidad de trabajo

no realizado, es esencial

11

Las mejores arquitecturas, requisitos y diseos emergen de

equipos auto-organizados

12

A intervalos regulares el equipo reflexiona sobre cmo ser ms

efectivo para a continuacin ajustar y perfeccionar su
comportamiento en consecuencia

Por qu usar Mitologas Agiles?

Metodologas Agiles

Pgina 7

1. Econmicas: Permiten reducir el nmero de actores implicados en un proyecto y

suele contar con tiempos de entrega bastante ajustados que un desarrollo
tradicional, lo cual va a disminuir precios.
2. Rpidas: Focalizan su estructura a disponer un producto mnimo viable el cual
puede ser probado por el usuario en el menor tiempo posible, construye toda la
empresa en torno a esta premisa. Permite lanzar al mercado productos de
software a una gran velocidad
3. Flexibles: Las fases tradicionales de anlisis, implementacin, pruebas e
implementacin se confunden y entremezclan cuando utilizamos metodologas
agiles para programar un proyecto, lo que favorece un entorno en el que la
introduccin de cambios es ms sencilla.
4. La organizacin del equipo es ms Sencilla: En un entorno como Scrum
comprobar cmo est organizado el equipo y la asignacin de tareas es tan
sencillo como acercarse el panel de gestin del proyecto y echar un vistazo. Una
organizacin sencilla elimina niveles de administracin y control y acerca ms al
cliente final y al equipo de desarrollo.
5. Implica ms a todo el equipo: Los integrantes implicados en el proyecto tienen
en mayor medida una visin global del proyecto. El xito de un desarrollo gil
esta en evitar la encapsulacin de responsabilidades, contrario a lo que sucede
con las metodologas tradicionales.
6. El producto final se ajusta ms a lo que quiere el cliente: La principal
problemtica del desarrollo tradicional es que se realiza una captura de
requisitos al principio y el cliente no puede comprobar que significa la
implementacin de lo que l ha pedido hasta la entrega del primer prototipo del
proyecto. Sin embargo, en muchos mtodos de desarrollo gil est contemplado
el feedback del cliente como parte estructural del proceso de desarrollo, lo cual
va a favorecer el producto final se ajuste a las necesidades del cliente.

Metodologas Agiles

Pgina 8

KANBAN

Es la metodologa gil para gestin de proyectos creada en Japn en la empresa Toyota,

que significa Tarjetas Visuales.
Se utiliza para controlar cmo avanza el proceso de trabajo en la produccin de un
producto o servicio.
Se basa en la divisin del trabajo en pequeas tareas que van representadas en una
tarjetas que contienen adems de la descripcin del trabajo, el tiempo de duracin de la
tarea, etc. Gracias a una pizarra, puede visualizarse el trabajo a realizar en todo
momento, pudiendo determinar en cada momento qu tareas estn realizndose y cules
hay que realizar.
Bsicamente las tareas se establecen tres columnas:
Pendientes
En proceso
Terminada
Primero, las tareas que estn por realizar van en la columna de pendientes. Cuando
alguien est haciendo dicha tarea pasara a la columna de en proceso y una vez se
haya acabado esta tarea, la tarjeta pasa a la columna de terminadas.
En caso de que no se haya podido acabar alguna tarea por cualquier motivo, se marcan
con una cruz roja o se ponen una cuarta columna de impedidas.

Pudiendo tener ms columnas dependiendo de los estados a los que pasan las tareas:

Metodologas Agiles

Pgina 9

Bsicamente lo que necesitas para definir una tarea es:

Nombre descriptivo. Describe precisamente la tarea.

Descripcin de la tarea.

Fecha de entrega de la tarea.

Persona asignada.

Razones por las que usar Kanban

Permite visualizar el trabajo de un simple vistazo.
Adems, te permitir detectar a tiempo ciertos problemas en tu flujo de trabajo como:
saturacin de algn miembro de tu equipo, tareas crticas, flujo mximo de trabajo que
puedes asumir, conflicto entre tareas,
Permite focalizarte en la ejecucin de tareas independientemente.
Permitir saber mucho mejor qu es lo que se tiene que hacer.
La definicin de tareas debe ser Independientes, negociables, valorables, estimables,
verificables (testable).
Permite mltiples variaciones y evolucionar Kanban a las necesidades de la
empresa o equipo.
La metodologa es clara pero es adaptable a cada equipo o proyecto. Podrs modificar,
quitar o poner casi cualquier cosa si respetas la metodologa.

Metodologas Agiles

Pgina 10

Podra que necesitaras ms columnas para diferencias otros estados de las tareas. O
podras ser que necesitaras utilizar los colores no para diferencias proyectos sino
subtareas de una misma tarea, por ejemplo. Todo es vlido.
Porque te permite ver grandes avances en el proyecto
Al final de la semana cuando se ve la evolucin del tablero Kanban, se ver qu se ha
hecho exactamente y que has avanzado mucho.

EXTREME PROGRAMMING XP

Por sus siglas en ingls, Programacin Extrema

es una metodologa gil enfocada al
desarrollo de software creada por Kent Beck ingeniero de software estadounidense en
1999.
Este mtodo trata las relaciones entre las personas como clave para el xito en el
desarrollo del proyecto, teniendo como base la interaccin continua entre el cliente y el
equipo.
Fomenta la interaccin permanente entre ambos, que facilita la introduccin de cambios
y minimiza las posibilidades de error. Requiere de la organizacin de los equipos en
pequeas clulas, con un nmero de integrantes limitado, no demasiado amplio; por lo
que no es recomendable para proyectos de larga duracin.
Es especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes,
y donde existe un alto riesgo tcnico.
PROCESO

Metodologas Agiles

Pgina 11

Qu conseguimos?
OBJETIVOS:

Dominar los cambios que aparecen en todo proyecto, estableciendo un sistema

de resolucin de los mismos.

Mejorar la productividad y el control del tiempo requerido para realizar el

proyecto.

Garantizar la calidad y la satisfaccin del cliente, hacindolo partcipe del

proceso.

Puede darnos soluciones a:

Retrasos en la produccin: Ya que las acciones son cortas y continuas.

Cancelacin del proyecto: Se tiene una constante interaccin con el cliente.

Costos por los cambios que surgen en el proyecto

Si el producto no cumple con las necesidades del cliente: El cliente es parte del
equipo y est presente en la toma de decisiones.

Rigidez frente a los cambios: Los cambios son tomados como parte natural del
proceso.

Otros Ejemplos:

Metodologas Agiles

Pgina 12

Tambin se disponen de metodologas especficas para el desarrollo de software que

pretenden ser alternativas a estndares como ISO/IEC 15504, ISO/IEC 12207 y CMMI.
Por ejemplo:
Dynamic Systems Development Method (DSDM): Metodologa gil ms
veterana y la que ms se aproxima a los mtodos tradicionales.
Feature Driven Development (FDD): Metodologa de desarrollo de software
orientada a la generacin de valor para el cliente.
Agile Modeling: Metodologa para el modelado y la generacin de
documentacin que se encuentra alineado con los principios del desarrollo gil y
que puede ser utilizado como substituto del UML estndar.
Adaptative software development (ASD): Reemplaza el ciclo tradicional de
catarata, con una serie de procesos de especulacin.
Tiene tres caractersticas principales que son:

Especulacin
Colaboracin y
Aprendizaje.

Crystal Clear: Est enfocada en la eficiencia de las personas (talentos,

interacciones, comunicacin) y no tanto de los procesos.

Metodologas Agiles

Pgina 13

METODOLOGAS SCRUM

Antecedentes histricos

Los primeros en introducir el trmino Scrum en desarrollos de nuevos productos

comerciales, fueron Hirotaka Takeuchi e Ikujiro Nonaka en el ao 1986. Ellos
describieron un nuevo enfoque sobre del proceso de desarrollo1. El mismo indicaba que
las distintas fases del proceso de desarrollo pueden solaparse y todo el proceso puede
ser llevado a cabo por un solo equipo que est a cargo de las distintas fases del proceso
de desarrollo. En aquella poca esto marcaba una gran diferencia con el proceso de
desarrollo tradicional, dnde cada fase del proceso era realizada por un grupo distinto de
personas con especialidades diferentes.
A partir de esta diferenciacin, Takeuchi y Nonaka llegaron a las siguientes analogas:
1 El sistema de desarrollo tradicional es anlogo a una carrera de relevos.
2 El nuevo enfoque propuesto es anlogo a un scrum de rugby.
En el ao 1990 Ken Schwaber emple las tcnicas mencionadas por Takeuchi y
Nonaka en su compaa. Advanced Development Methods. Al mismo tiempo Jeff
Sutherland desarroll, en Easel Corporation, un enfoque similar al propuesto por
Schwaber y fue el primero en darle el nombre Scrum.
Finalmente en el ao 1995 Schwaber, con la ayuda de Sutherland, present un
paper formalizando el proceso Scrum para la industria del software. El mismo fue
presentado en la conferencia OOPSLA95 (Object-Oriented Programming, Systems,
Languages & Applications).
En los aos siguientes, Schwaber y Sutherland siguieron colaborando juntos
para integrar sus escritos, experiencias y prcticas sugeridas para terminar de definir lo
que hoy se conoce como Scrum.

Metodologas Agiles

Pgina 14

Descripcin de Scrum
Segn sus creadores, Scrum es un proceso gil que puede utilizarse para
administrar y controlar desarrollo de software utilizando prcticas que involucran
iteraciones con incremento de funcionalidad.

ROLES
En un proyecto scrum, a las personas que participan en el mismo, las podemos
dividir en dos grandes grupos: Pigs que son todas aquellas personas comprometidas
con la realizacin del proyecto y las prcticas de scrum y Chickens que son aquellas
personas que no forman parte del proceso de Scrum pero que son importantes y
necesarias en el proyecto dado que pueden ocupar roles como especialistas del negocio
o de alguna tecnologa particular. Esta divisin tiene su origen en un viejo chiste sobre
Pigs & Chickens.
A pig and a chicken are walking down a road. The Chicken looks at the pig and says
"Hey, why don't we open a restaurant?" The pig looks back at the chicken and says
"Good idea, what do you want to call it?" The chicken thinks about it and says "Why
don't we call it 'Ham and Eggs'?" "I don't think so" says the pig, "I'd be committed but
you'd only be involved"
Para la descripcin de scrum, solamente se hablar sobre los Pigs y los distintos
roles que ellos pueden adquirir. Los mismos se dividen, segn sus responsabilidades
dentro del proceso scrum, en tres roles que se detallan a continuacin:

PRODUCT OWNER
Se encarga de crear una versin inicial muy general de los requerimientos,
objetivos sobre el retorno de la inversin y planes de entrega. Este rol se encarga de
establecer prioridades sobre los requerimientos asegurndose que la funcionalidad ms
valiosa e importante se produzca en tiempo y forma como es debido. En scrum no existe
ningn criterio para la definicin de los requerimientos; lo importante es que los
mismos se encuentren relacionados con el sistema/aplicacin a desarrollar.

SCRUM MASTER
Es responsable de velar por la correcta implementacin del proceso scrum. Debe
ensear a toda persona involucrada en el proyecto, las tcnicas y procedimientos de
scrum teniendo en cuenta, que los mismos no deben estar desalineados con las polticas,

Metodologas Agiles

Pgina 15

prcticas y cultura de la empresa en la cual se est llevando a cabo el proyecto.

Asimismo debe asegurarse que las prcticas y procedimientos realizados produzcan los
beneficios esperados.
Para cumplir con todas estas exigencias, el Scrum Master deber estar al tanto de
los avances y del da a da de las actividades de los miembros del Team.
El Scrum Master debe actuar como intermediario entre el Product Owner y el
Team, por lo tanto no se recomienda que la persona que ocupe este puesto posea,
adems del rol de Scrum Master, otro rol dentro del mismo proyecto. Es decir, no es
aconsejable que una misma persona sea Scrum Master y analista funcional/arquitecto de
sistemas en el mismo proyecto.

TEAM
Es un grupo de personas encargadas de desarrollar e implementar la
funcionalidad pactada. El equipo se auto administra y auto organiza. Las personas que
lo componen, deben utilizar su ingenio para incrementar la funcionalidad cumpliendo
con los requerimientos a lo largo de cada iteracin. Los miembros del equipo son
responsables del xito de cada sprint.
La auto administracin y auto organizacin es un aspecto crucial en Scrum. Es
indispensable que todos los miembros del Team estn comprometidos con su trabajo y
para ello es necesario contar con la motivacin de los mismos. En un Team que se auto
organiza y auto administra, no hay una persona encargada de controlar que todos los
miembros estn cumpliendo sus tareas en tiempo y forma. Sino que cada uno de los
integrantes es responsable de realizar sus tareas y adems debe asegurarse que el resto
de los miembros hagan lo propio con sus tareas respectivas. El Team debe trabajar en
conjunto como un bloque. Sus resultados son producto del trabajo colectivo y no de
esfuerzos individuales.

Idealmente, se recomienda que el Team est formado por no ms de siete

personas. A medida que el Team aumenta en cantidad de personas, aumenta la
posibilidad que el Team no funcione como tal, dado que habr miembros que perdern
la motivacin y el compromiso necesario para el correcto funcionamiento del Team.
En algunas situaciones, cuando se cuente con un Team formado por ms de diez
personas, es recomendable dividir este equipo en distintos sub equipos. La subdivisin
puede hacerse segn las responsabilidades (un equipo de desarrolladores, un equipo de
qa, un equipo de analistas funcionales) o segn las necesidades del negocio en sub
equipos que incluyan todos los roles. Cuando se armen sub equipos formados solamente
por desarrolladores, qa o analistas funcionales, es necesario encontrar una forma para

Metodologas Agiles

Pgina 16

hacer interactuar a los distintos sub equipos. Para ello puede realizarse, semanalmente,
una reunin de Scrum con un representante de cada sube quipo. De esta forma los
equipos estarn al tanto de las actividades de los otros equipos.

La composicin del Team es algo que no puede ser absoluta, dado que cada
proyecto de software tiene sus propias caractersticas. Es decir algunos proyectos
necesitarn mayor presencia de personas para ocupar ciertos roles que otros. Por
ejemplo, en un proyecto relacionado a data Ming, es necesario contar con algn experto
en dicha tecnologa y un administrador de bases de datos, pero en un proyecto
empresarial estos roles pueden no ser necesarios. Existe la posibilidad que el objetivo de
un sprint sea Encontrar la mayor cantidad de fallas en el sistema, con lo cual en ese
caso, el Team puede estar formado solamente por personal de testing. Tambin puede
ser factible, que el objetivo de un sprint sea Presentar el diseo de la refactorizacin
necesaria para utilizar una nueva librera de un tercero, por lo tanto en ese caso, es muy
probable que el Team est formado por un grupo de arquitectos, diseadores y
desarrolladores sin contar con analistas funcionales ni personal de testing.

Sin embargo, para proyectos involucrados en aplicaciones empresariales, un

equipo podra estar compuesto de la siguiente manera: un analista funcional, un
diseador, tres desarrolladores y dos quality assurance.
El rol de analista funcional se encarga de definir los requerimientos del negocio.
Es importante que sepa diferenciar entre requerimientos funcionales y no funcionales.
La persona que ocupe el puesto de diseador deber establecer los distintos
componentes y sus colaboraciones que el sistema debe poseer.
Por su parte los/las desarrolladores se encargan de desarrollar el software que
formar el sistema o producto. Siguiendo las buenas prcticas deben realizar pruebas de
unidad para garantizar el correcto uso de los componentes que desarrollan.
Las personas que ocupan el puesto de quality assurance deben asegurar la
calidad del producto o sistema. Estn encargadas de verificar y validar la funcionalidad
del producto, ya sea mediante testing manual o automatizado.

Aunque cmo se mencion anteriormente, no existe un absoluto para la

composicin del Team, cada proyecto demandar un Team concreto que sea capaz de
responder a sus necesidades.

Metodologas Agiles

Pgina 17

CICLO DE VIDA
El ciclo de vida de Scrum puede verse en la siguiente imagen obtenida de
www.controlchaos.com (sitio creado y mantenido por el creador de scrum Ken
Schwaber).

Todo proyecto se divide en una o ms iteraciones denominadas sprints que

consisten de un conjunto de actividades de desarrollo llevadas a cabo a lo largo de un
perodo de tiempo preestablecido. Es aconsejable que cada sprint, posea una duracin de
30 das. Si bien este tiempo puede variar, se aconseja que la duracin del sprint sea de
un mes, dado que es un tiempo prudencial para que el equipo sea capaz de producir un
entregable que produzca valor agregado al Product Owner y cualquier otro stakeholder.
Tambin es un tiempo adecuado, para que el cliente espere sin perder inters en lo que
el Team est desarrollando y no se impaciente sabiendo que el mismo est desarrollando
algo positivo para l.
Sin embargo, vale la pena destacar que este intervalo de tiempo no es algo fijo y
absoluto, sino que el mismo puede variar de acuerdo a la complejidad del producto y a
otros factores como por ejemplo un anlisis de riesgos o exigencias propias del negocio
o propias del cliente.
Sprint (Iteracin segn la nomenclatura agile)

Metodologas Agiles

Pgina 18

Cada sprint tiene como objetivo brindar un incremento de funcionalidad. A continuacin

defino los pasos que deben cumplirse en cada sprint.
1. Planeamiento del sprint.
2. Implementacin del sprint.
3. Revisin del sprint.

Planeamiento del sprint

El objetivo de esta reunin es identificar, definir y estimar los tiempos de los
requerimientos a desarrollar en la iteracin o sprint.

Participantes: Product Owner, Scrum Master, Team

A esta reunin el Product Owner se presenta con una lista de requerimientos

clasificados segn su prioridad. A partir de dicha lista, el Product Owner y los miembros
del Team trabajarn en conjunto para obtener lo que en trminos de scrum se conoce
como Product Backlog: lista de requerimientos propios del proyecto.

Cada tem que pertenece al Product Backlog posee una prioridad y un tiempo
estimado para convertirlos en funcionalidad del producto. Los tiempos siempre deben
ser das y su precisin es mayor a mayor prioridad del requerimiento
Normalmente suele dividirse est reunin en dos etapas. En la primer etapa el
Product Owner presenta al equipo, una lista de los requerimientos que poseen mayor
prioridad al Team. Luego ambos, el Product Owner y los miembros del Team trabajan
en conjunto para determinar cules son los requerimientos que se desarrollarn en el
siguiente sprint. Al finalizar esta primera etapa, el Team se compromete a desarrollar un
conjunto o toda la funcionalidad especificada a travs del Product Backlog resultante.
En la segunda etapa, los miembros del Team definen cmo llevarn a cabo el
compromiso asumido en la primera etapa de la reunin y crearn una primera versin de
lo que se conoce como Sprint Backlog. El mismo consiste de un documento que
contiene una lista de tareas indicando, para cada tarea, la persona asignada y la cantidad
de trabajo pendiente estimada en algn(os) da(s) particular(es).
Aqu debe definirse la arquitectura del sistema. Si bien los miembros del Team
pueden estar en condiciones de hacerlo, en algunas ocasiones es aconsejable contar con
la presencia de un(a) arquitecto(a) que pueda aportar su experiencia. En el caso que el
arquitecto no forme parte del Team, sus propuestas deben contar con la aprobacin del
Metodologas Agiles

Pgina 19

Team; es decir sus sugerencias de arquitectura no deben ser impuestas a los integrantes
del Team.
Implementacin del sprint
En esta etapa, los miembros del equipo se encargaran de proveer un incremento
de funcionalidad del producto o sistema,
tomando como entrada, aquellos
requerimientos provenientes del Product Backlog con los cuales han asumido el
compromiso de implementarlos en la reunin de planeamiento del sprint. Para ello ser
necesario uno o ms equipos realizando las siguientes tareas:

Desarrollo
Deployment de una versin con sus Release notes.
Revisiones
Ajustes

Para la realizacin de las mismas deben tenerse en cuenta las siguientes

consideraciones:
Una vez comenzado el sprint, est prohibido realizar cualquier tipo de cambio al
Product Backlog.
Los miembros del Team pueden buscar informacin, o solicitar soporte y ayuda;
pero ninguna persona puede ni debe interferir con el trabajo del Team.
Algunas formas de interferir con el trabajo del Team, son: solicitarle uno o ms de los
miembros del Team la realizacin de tareas no contempladas en el Sprint Backlog, dar
instrucciones sobre cmo realizar su trabajo, o reunir al equipo para indicarle qu se
pretende de l.
Aunque esto no es deseado y debera evitarse con un correcto planeamiento, si el
sprint no es viable, ya sea por una tecnologa incompatible, por cambios en el negocio
que haran que la funcionalidad del sprint no produzca valor alguno o porque una
persona exterior al Team interfiere con su trabajo, el ScrumMaster es el nico que
cuenta con la autoridad necesaria para dar por finalizado el sprint. Si bien el
ScrumMaster es la nica persona que puede realizar este cambio, puede hacerlo segn
su propio criterio o segn la recomendacin de algn miembro del equipo o del Product
Owner.
Sin embargo, en algunas ocasiones existe la posibilidad que el Team no pueda
completar todo el Sprint Backlog asumido en la reunin de Sprint Planning. Si esto
ocurre el Team puede consultar al Product Owner si existe la posibilidad de remover
algunos tems y relegarlos para el sprint futuro. En el caso que la cantidad de tems a
remover sea muy elevada el Sprint habr perdido su significado, y el ScrumMaster
puede terminar el sprint segn se ha mencionado anteriormente.
En el caso opuesto, en el que el Team haya cumplido con toda la funcionalidad
pactada en una fecha anterior a la finalizacin del Sprint, el mismo puede darse por
Metodologas Agiles

Pgina 20

terminado o puede consultarse con el Product Owner si es conveniente agregar al sprint

algn tem del Product Backlog.
A lo largo de todo el sprint, adems de sus tareas correspondientes (anlisis,
diseo, desarrollo, testing) los miembros del Team cuentan con dos tareas
administrativas. Una de ellas es asistir a las reuniones diarias de scrum (scrum daily
meetings o stand up meeting) y mantener actualizado el Sprint Backlog.
Las reuniones de stand up o daily scrum deben llevarse a cabo, como su
denominacin lo indica, diariamente. A ella asisten el Product Owner, el ScrumMaster y
el Team. Al ser reuniones diarias, las mismas no deben durar ms de 15 minutos. En
dicha reunin cada integrante debe responder las siguientes preguntas:
Qu he estado haciendo desde la ltima stand up meeting hasta ahora?
Qu planeo hacer desde ahora hasta la prxima stand up meeting?
Existe alguna complicacin o impedimento que no me permita realizar los
compromisos asumidos para este sprint?
Estas reuniones tienen como propsito sincronizar el trabajo de todas las personas
comprometidas con el proceso de scrum. Asimismo, brindar una herramienta para lograr
mayor cohesin y compromiso en los miembros del equipo permitiendo su interaccin y
cooperacin
entre
s.

Revisin del sprint

Consiste de una reunin en la cual se presenta al Product Owner y a los
stakeholders el incremento de funcionalidad que ha sido implementado a lo largo de
dicha iteracin. La reunin comienza con un miembro del Team presentando el objetivo
del sprint, el Product Backlog comprometido y el Product Backlog implementado.
La funcionalidad debe presentarse en las estaciones de trabajo de los miembros
del Team simulando un ambiente muy cercano al ambiente de produccin. De ninguna
manera puede presentarse un prototipo o una presentacin con diapositivas.
A lo largo de la presentacin, los stakeholders y el Product Owner pueden
realizar las preguntas que consideren necesarias. Las mismas deberan referirse a la
presentacin o a los cambios de funcionales productos del incremento de funcionalidad
provisto mediante la implementacin del sprint. Asimismo, tambin deben mencionar
toda nueva funcionalidad que se les ocurra mientras estn viendo la presentacin. Esta
nueva funcionalidad debe agregarse al Product Backlog.
Al finalizar la presentacin, es importante que los destinatarios de la misma
provean feedback a los miembros del equipo, dado que ello puede servir como un
Metodologas Agiles

Pgina 21

primer paso para la definicin de tems potenciales del Product Backlog del prximo
sprint.
Tanto el Product Owner como los stakeholders destinatarios de la presentacin
pueden identificar funcionalidad que no haya sido implementada o que no haya sido
implementada de la manera esperada. Si esto ocurriese, dicha funcionalidad debe
incluirse nuevamente en el Product Backlog para que sea implementada en el prximo
sprint. Es responsabilidad del Product Owner, la asignacin de la prioridad
correspondiente.
Este tipo de reuniones no debera durar ms de cuatro horas, aunque la duracin
de la misma va a estar condicionada por la duracin del sprint y el incremento de
funcionalidad implementada en el mismo.
Vale la pena destacar, que no debe perderse tiempo en presentar la funcionalidad
que se encuentre a medio implementar. Es decir si no se han completado todas las tareas
necesarias para brindar la funcionalidad correspondiente a un tem del Product Backlog
pero se ha llegado a implementar parte de esa funcionalidad, la misma no debe ser
presentada.
Dado que uno de los lemas de las tecnologas giles es utilizar la mayor cantidad
de tiempo en hacer y no planear lo que hay hacer se aconseja que el Team no
dedique demasiado tiempo a la preparacin de dicha presentacin. Una hora debera ser
ms que suficiente.
Por ltimo, el ScrumMaster es el encargado de agendar y programar esta reunin
invitando a los participantes correspondientes.

Metodologas Agiles

Pgina 22

ARTEFACTOS DE SCRUM

Product Backlog
Los requerimientos a desarrollar se encuentran definidos en el Product Backlog. El
mismo consiste de una planilla que representa los requerimientos iniciales del proyecto.
Los requerimientos que integran esta lista no poseen gran detalle, pero si son lo
suficientemente claros para servir como punto de partida para que el Team pueda ser
capaz de desglosarlos en tareas a realizar. Es muy importante remarcar que los
requerimientos deben estar ordenados segn su prioridad, los primero tems de la lista
son lo que poseen mayor prioridad.
El Product Backlog evoluciona constantemente segn las necesidades del negocio.
Sin embargo, debe tenerse en cuenta que todo cambio al mismo debe estar
documentado. A continuacin se presentan algunos ejemplos de Product Backlog.
Ejemplo 1:
Ken Schwaber propone la siguiente planilla para utilizar como Product Backlog.

En dicha planilla, los tems estn separados por los Sprints en los cuales fueron
realizadas. Es decir todas las filas que se encuentran arriba de Sprint-1 corresponden a
requerimientos que fueron realizados en el Sprint-1. Los tems que se encuentran por

Metodologas Agiles

Pgina 23

debajo de la fila con ttulo Sprint-1 y por encima de la fila con ttulo Sprint-2
corresponden a requerimientos que fueron realizados en el Sprint-2 y as sucesivamente.
Las primeras cuatro columnas se refieren a: una descripcin del tem, un tiempo
estimado inicial, un factor de ajuste y un tiempo estimado ajustado. Las columnas
siguientes representan los Sprints en los cuales el Product Backlog es desarrollado.
Cuando un tem es identificado e ingresado en el Product Backlog, el tiempo estimado
para implementarlo se agrega en la columna correspondiente al Sprint actual. Tal cual
puede apreciarse en el ejemplo anterior todos los tems, salvo Publish Facility For
Entire Project, Publishing It As HTML Web Pages que fue identificado en el Sprint-3,
fue identificado en el Sprint-1.
En dicho ejemplo, tambin puede apreciarse que el tem Display Tree View Of
Product Backlog, Releases, Sprints se encuentra duplicado. Esto es as porque dicho
tem no fue completado en el Sprint-1 y por lo tanto fue movido al Sprint-2.
Alternativamente, si el Product Owner determinara que su prioridad era menor, podra
haberse movido a otro Sprint o incluso podra haberse eliminado.
Es importante que el lector aprecie que este esquema permite saber cundo
fueron identificados los requerimientos y durante que etapa del proyecto fueron
implementados.
Ejemplo 2.
En algunas circunstancias, es deseable utilizar una planilla ms sencilla que
simplemente posee los tems agrupados segn su prioridad indicando un tiempo de
trabajo estimado para implementarlo y la persona que realiz dicha estimacin. Es muy
comn ver tres grupos de niveles de prioridad, como puede apreciarse en la siguiente
imagen.

Metodologas Agiles

Pgina 24

Burndown Chart
Un grfico de burndown indica la cantidad de trabajo pendiente a lo largo del
tiempo. Para la cantidad de trabajo pendiente suele utilizarse das como unidad,
mientras que para el tiempo suelen utilizarse los Sprints como unidad.
El mismo sirve como una forma de visualizar la correlacin entre la cantidad de
trabajo requerida y el progreso del Team reduciendo dicha cantidad. Este grfico no
slo representa el trabajo realizado, sino la velocidad con la cual se realiza el
mismo.
A continuacin se presenta el grfico de burndown correspondiente al Ejemplo 1
del apartado Product Backlog.

Metodologas Agiles

Pgina 25

Sprint Backlog
El Sprint Backlog es una lista de tareas que el Team se ha comprometido a realizar a
lo largo del Sprint. Representa el trabajo necesario para implementar los requerimientos
del Product Backlog correspondientes al corriente Sprint. Esta lista de tareas es
confeccionada en la segunda etapa de la reunin de planeamiento del Sprint y la misma
es actualizada da a da por los miembros del Team a lo largo de todo el Sprint.
Las tareas deben ser definidas de forma tal que todos los miembros del Team
entiendan de qu se tratan y Scrum sugiere que cada tarea posea una duracin de 4 a 16
horas; es decir no ms de dos das. Las tareas que requieran ms de 16 horas son
consideradas como tareas que todava no han sido desglosadas lo suficientemente para
que todos los miembros del Team entiendan de qu se tratan. Sin embargo esto es una
sugerencia y no debe tomarse como un absoluto.
A continuacin se presenta un ejemplo de Sprint Backlog. Las filas representan las
tareas, quin fue la persona que la propuso, la persona a cargo de realizarla, el estado de
la misma y la cantidad de trabajo pendiente para desarrollarla.

Ejemplo 1:

Metodologas Agiles

Pgina 26

La primera columna representa una descripcin de la tarea. La segunda y tercera

columna representan la persona que propuso la tarea y la persona que est a cargo de la
realizacin de la misma respectivamente. La cuarta columna se refiere al estado de la
tarea. Esta columna solamente puede tomar los siguientes valores: Sin Comenzar, En
progreso o Completa. Las columnas subsiguientes representan los das del Sprint. En
cada uno de ellos, debe indicarse la cantidad de trabajo pendiente para completar cada
una de las tareas. Es decir si una tarea requiere 6 horas y la misma permanece en el
estado Sin Comenzar hasta el da 3, en las celdas correspondientes a la interseccin de
las columnas de los das 1 y 2 con la fila de la tarea debe figurar un 6. Si la tarea se
completara en el tercer da del Sprint, en la celda de la interseccin de la tarea con el da
3 debe figurar un 6 y a partir del cuarto da deber figurar un 0. Finalizando con la
explicacin de la planilla es importante que el lector sepa que la imagen presentada
como ejemplo ha sido truncada en el doceavo da por cuestiones de practicidad.
En algunas situaciones slo interesa saber el estado de las tareas sin importar la
persona encargada de la realizacin de la misma, dado que se desea ver el grado de
avance del Team como un todo y no como un esfuerzo individual. Para dichos casos
puede utilizarse el siguiente Sprint Backlog.

Metodologas Agiles

Pgina 27

Ejemplo 2:
Days
Date
Logged

Description

1-Feb-15

UI Object Model

1-Feb-15

UI Framework

1-Feb-15

Learn Struts/Tiles Api

2-Feb-15

Setup
environment

2-Feb-15

Setup testing environment

2-Feb-15

Design Db Model

3-Feb-15

Migrate Sql to MySql

3-Feb-15

Design Person Model

3-Feb-15

Automate DB Test data

upload

9 10

1 0

6 6

0 0

20

17

11

11

15

11

7 6

developer

Effort Remaining in Man

days
38

24

Es importante recordar que slo los miembros del Team estn autorizados a
actualizar y mantener el Sprint Backlog. Este documento permite visualizar el trabajo
realizado y la cantidad de trabajo pendiente para completar la funcionalidad pactada en
el Sprint. Por ende el Sprint Backlog debe ser actualizado diariamente y el mismo debe
reflejar la realidad del da a da del trabajo realizado por los miembros del Team.
Tambin vale la pena destacar que sin importar el grado de avance del Sprint, si
algn integrante del Team identifica una nueva tarea, debe agregarla a dicho documento
indicando el tiempo de trabajo pendiente para su realizacin. Este es el caso de la tarea
Analyse KEG Data Encumbrance del Ejemplo 1 que fue identificada y agregada el
sptimo da del Sprint.

Metodologas Agiles

Pgina 28

BIBLIOGRAFA
AgileAlliance website http://www.agilealliance.org
IBM Staff. Rational Software White Paper. Rational Unified Process Best Practices
for Software Development Teams. Rev. 11/01
Krebs, Joe. RUP in the Dialogue with Scrum. 2005.
http://www-128.ibm.com/developerworks/rational/library/feb05/krebs/#N10162
Kruchten, Philippe. The Rational Unified Process: An Introduction, 3 rd edition. Addison
Wesley. December 2003.
Larman, Craig. Agile and Iterative Development: A Managers guide. Addison Wesley,
2003.
Schwaber, Ken. Advanced Development Methods. SCRUM Development Process.
2006. http://jeffsutherland.com/oopsla/schwapub.pdf
Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press, 2004.
Schwaber, Ken and Beedle, Mike. Agile Software Development with Scrum. Prentice
Hall, 2002.
Schwaber, Ken. Controlled Chaos: Living on the Edge. American Programmer,
April 1996.
Schwaber, Ken. What is Scrum? OOPSLA. 1995.
Scrum. http://www.controlchaos.com/
ScrumAlliance website http://www.scrumalliance.org
Sutherland, Jeff. ScrumWeb Home Page: A Guide to the SCRUM Development
Process. Jeff Sutherlands Object Technology Web Page, 1996
http://www.tiac.net/users/jsuth/scrum/index.html

Metodologas Agiles

Pgina 29