Ing.

Jos Lpez Izquierdo, MSIG

MAGISTER EN SISTEMAS DE INFORMACIN GERENCIAL
MICROSOFT CERTIFIED PROFESSIONAL
MICROSOFT CERTIFIED APPLICATION DEVELOPER
MICROSOFT DEVELOPER SUPPORT
Ing. Jos Lpez Izquierdo
Sesin IV: Desarrollo gil

Ing. Jos Lpez Izquierdo

 Vistazo rpido: Desarrollo gil
Qu es?
Combina una filosofa y un conjunto de
directrices de desarrollo.
La filosofa busca satisfaccin del cliente y
cumplir con el tiempo de entrega.
Las direcciones de desarrollo resaltan la
entrega del software y la comunicacin
activa y continua entre los desarrolladores
y los clientes..
Cules son los pasos?
Las actividades bsicas del marco de
trabajo se conservan, pero stas se
conforman como un conjunto mnimo de
tareas que empuja al equipo de proyecto
hacia la construccin y la entrega.
Quin lo hace?
Los ingenieros de software y otros
participantes del proyecto trabajan juntos
en un equipo gil: un equipo con
organizacin propia y que controla su
propio destino.
Cul es el producto obtenido?
Es un incremento de software en
funcionamiento, el cual se entrega al
cliente en una fecha prometida.
Por qu es importante?
Representa una opcin razonable a la
ingeniera convencional para ciertas clases
de software y ciertos tipos de proyectos de
software.
Cmo puedo estar seguro de que
lo he hecho correctamente?
Si el equipo est de acuerdo en que el
proceso funciona y producen incrementos
de software entregables que satisfacen al
cliente.
Ing. Jos Lpez Izquierdo
Qu es la Agilidad?

La agilidad se ha convertido en la palabra mgica de hoy para describir

un proceso del software moderno. Todos son giles. Un equipo gil es
diestro y capaz de responder de manera apropiada a los cambios. El
cambio es de lo que trata el software en gran medida. Hay cambios en el
software que se construye, en los miembros del equipo, debidos a las
nuevas tecnologas, de todas clases y que tienen un efecto en el producto
que se elabora o en el proyecto que lo crea. Deben introducirse apoyos
para el cambio en todo lo que se haga en el software; en ocasiones se
hace porque es el alma y corazn de ste. Un equipo gil reconoce que el
software es desarrollado por individuos que trabajan en equipo, y que su
capacidad, su habilidad para colaborar, es el fundamento para el xito del
proyecto. (Jacobson)

Ing. Jos Lpez Izquierdo

 Qu es la Agilidad?
CARACTERISTICAS

Es ms que una respuesta efectiva al cambio.

Estimula las estructuras y actitudes de los equipos para la

comunicacin sea ms fcil.

Resalta la entrega rpida del software operativo y le resta

importancia a los productos de trabajo intermedio.

Incorpora al cliente una parte del equipo de desarrollo.

Ing. Jos Lpez Izquierdo

La agilidad y el costo del cambio

Ing. Jos Lpez Izquierdo

Manifiesto del Desarrollo gil

Los individuos y sus El software que

interacciones, sobre funciona, ms que la
los procesos y las documentacin
herramientas exhaustiva

La colaboracin con
Responder al
el cliente, y no
cambio, mejor que
tanto la negociacin
apegarse a un plan
del contrato

Ing. Jos Lpez Izquierdo

QU ES UN PROCESO GIL?
Los incrementos de software
Incluye una estrategia deben entregarse en cortos
incremental de periodos para que la
desarrollo. adaptacin mantenga un buen
ritmo con el cambio.

Permite al cliente evaluar el

incremento de software de
Un proceso gil debe ser manera regular, proporcionar
adaptable en forma la retroalimentacin al
incremental a un proyecto equipo, e influir sobre las
y a condiciones tcnicas adaptaciones del proceso
que cambian con rapidez. para adecuar la
retroalimentacin

Ing. Jos Lpez Izquierdo

 Principios de agilidad
1. La prioridad ms alta es
satisfacer al cliente a travs de
la entrega pronta y continua
de software valioso.
5. Hay que desarrollar los
proyectos con individuos
motivados. Debe darse a stos
el ambiente y el apoyo que
necesiten, y confiar en que
harn el trabajo.
9. La atencin continua a la
excelencia tcnica y el buen
diseo mejora la agilidad.
2. Son bienvenidos los
requerimientos cambiantes,
aun en una etapa avanzada del
desarrollo. Los procesos giles
dominan el cambio para
provecho de la ventaja
competitivadel cliente.
6. El mtodo ms eficiente y
eficaz para transmitir
informacin a los integrantes
de un equipo de desarrollo, y
entre stos, es la conversacin
cara a cara.
10. Es esencial la simplicidad:
el arte de maximizar la
cantidad de trabajo no
realizado.
3. Entregar con frecuencia
4. Las personas de negocios y
software que funcione, de dos
semanas a un par de meses, de
preferencia lo ms pronto que
se pueda.
7. La medida principal de
avance es el software que
funciona.
11. Las mejores arquitecturas,
requerimientos y diseos
surgen de los equipos con
organizacin propia.
los desarrolladores deben
trabajar juntos, a diario y
durante todo el proyecto.
8. Los procesos giles
promueven el desarrollo
sostenible. Los patrocinadores,
desarrolladores y usuarios
deben poder mantener un
ritmo constante en forma
indefinida.
12. El equipo reflexiona a
intervalos regulares sobre
cmo ser ms eficaz, para
despus afinar y ajustar su
comportamiento en
consecuencia.
Ing. Jos Lpez Izquierdo
 POLTICAS DEL DESARROLLO GIL

Dentro de cada
Existe un debate
modelo hay un
considerable sobre
conjunto de Hay mucho que
los beneficios y la
Existen varios ideas (tareas de ganar si se
aplicabilidad del
modelos de trabajo). Muchos considera lo mejor
desarrollo gil del
proceso, cada uno conceptos de de ambas
software como
con un enfoque agilidad son tan escuelas, y nada
alternativa a
sutilmente slo adaptaciones que ganar si se
procesos de
diferente. de buenos denigra alguno de
ingeniera del
conceptos de la los dos enfoques
software ms
ingeniera del
convencionales.
software.

Ing. Jos Lpez Izquierdo

 Factores Humanos
La competencia incluye el talento innato, las habilidades especficas relacionadas con el software y el conocimiento
general del proceso que el equipo haya elegido aplicar.
La habilidad y el conocimiento del proceso pueden y deben considerarse para todas las personas que sean miembros
Competencia. giles del equipo.

Aunque los miembros del equipo gil realicen diferentes tareas y aporten habilidades distintas al proyecto, todos deben
centrarse en una meta: entregar al cliente en la fecha prometida un incremento de software que funcione.
Enfoque Para lograrlo, el equipo tambin se centrar en adaptaciones continuas (pequeas y grandes) que hagan que el proceso
comn. se ajuste a las necesidades del equipo.

La ingeniera de software (sin importar el proceso) trata de evaluar, analizar y usar la informacin que se comunica al
equipo de software; crear informacin que ayudar a todos los participantes a entender el trabajo del equipo; y generar
informacin (software de cmputo y bases de datos relevantes) que aporten al cliente valor del negocio. Para efectuar
Colaboracin. estas tareas, los miembros del equipo deben colaborar, entre s y con todos los participantes.

Ing. Jos Lpez Izquierdo

 Factores Humanos
Cualquier equipo bueno de software (incluso los equipos giles) debe tener libertad para controlar su destino. Esto implica que se d autonoma al equipo:
Habilidad para autoridad para tomar decisiones sobre asuntos tanto tcnicos como del proyecto.
tomar
decisiones.

Los gerentes de software deben reconocer que el equipo gil tendr que tratar en forma continua con la ambigedad y que ser sacudido de manera
permanente por el cambio. En ciertos casos, el equipo debe aceptar el hecho de que el problema que resuelven ahora tal vez no sea el que se necesite
Capacidad resolver maana. Sin embargo, las lecciones aprendidas de cualquier actividad relacionada con la solucin de problemas (incluso aquellas que resuelven el
para resolver
problemas problema equivocado) sern benficas para el equipo en una etapa posterior del proyecto.
difusos.

El equipo gil tiene la confianza y respeto que son necesarios.

Confianza y
respeto
mutuos.

En el contexto del desarrollo gil, la organizacin propia implica:

1) El equipo gil se organiza a s mismo para hacer el trabajo,
Organizacin 2) El equipo organiza el proceso que se adapte mejor a su ambiente local,
propia. 3) El equipo organiza la programacin del trabajo a fin de que se logre del mejor modo posible la entrega del incremento

Ing. Jos Lpez Izquierdo

RATIONAL UNIFIED PROCESS

RUP
Creado por:
Rational ahora Puede aplicarse como: Utiliza Artefactos Utiliza UML
propiedad de IBM

Modelo
Modelo gil
Tradicional

Ing. Jos Lpez Izquierdo

La Filosofa del RUP

Demostrar
Colaboracin
valor
entre equipos
iterativamente

Equilibrar Enfocarse en la
prioridades calidad

Adaptar el
proceso RUP Elevar el nivel
de abstraccin

Ing. Jos Lpez Izquierdo

Principales caractersticas

RUP
Pretende
implementar
las mejores
Uso de prcticas en
Modelado Verificacin de
Desarrollo Administracin arquitectura Control de Ingeniera de
visual del la calidad del
iterativo de requisitos basada en cambios Software, de
software software
componentes forma que se
adapte a
cualquier
proyecto

Ing. Jos Lpez Izquierdo

Ciclo de Vida y Fases del RUP

Ing. Jos Lpez Izquierdo

Artefactos

Artefactos Fase de Inicio

Documento
Visin
Diagramas de
caso de uso
Especificacin
de Requisitos
Diagrama de
Requisitos

Ing. Jos Lpez Izquierdo

Artefactos
Diagrama de clases
Vista Lgica
Modelo E-R (Si el sistema as lo requiere)

Diagrama de Secuencia
Artefactos Fase de

Vista de
Diagrama de estados
Elaboracin

Implementacin

Diagrama de Colaboracin

Vista Conceptual Modelo de dominio

Mapa de comportamiento a nivel de

hardware

Vista fsica Diseo y desarrollo de casos de uso

Pruebas de los casos de uso desarrollados

Ing. Jos Lpez Izquierdo
Artefactos

Artefactos Fase de Especificacin de requisitos

Construccin faltantes

Diseo y desarrollo de casos

de uso y/o flujos de acuerdo
con la planeacin iterativa

Pruebas de los casos de uso

desarrollados, y pruebas de
regresin segn sea el caso

Ing. Jos Lpez Izquierdo

Artefactos

Artefactos Fase de Pruebas finales

Transicin de aceptacin
Puesta en
produccin

Estabilizacin

Ing. Jos Lpez Izquierdo

Personal RUP

Ing. Jos Lpez Izquierdo

Metodologa XP

Nace de la mano de Kent Beck en

el verano de 1996, cuando
trabajaba para Chrysler Corporation.
l tena varias ideas de metodologas
para la realizacin de programas que
eran cruciales para el buen desarrollo
de cualquier sistema. Las ideas
primordiales de sus sistemas las
comunico en las revistas C++
Magazine en una entrevista que esta
le hizo el ao 1999.

Ing. Jos Lpez Izquierdo

 Metodologa XP

XP es una metodologa gil para Sugiere algunas tcnicas innovadores y poderosas que
el desarrollo de software y consiste permiten a un equipo gil crear frecuentes lanzamientos
bsicamente en ajustarse de software al entregar caractersticas y funcionalidad que
estrictamente a una serie de describe y despus prioriza el cliente.
reglas que se centran en las
necesidades del cliente para lograr
un producto de buena calidad en
poco tiempo, centrada en potenciar PROGRAMACIN
las relaciones interpersonales como EXTREMA (PE)
clave para el xito del desarrollo de Caractersticas
Planeacin
software Organizada
Diseo
Enfoque como cuatro Codificacin
orientado actividades
Pruebas
a objetos del marco de
trabajo:

Ing. Jos Lpez Izquierdo

Valores XP

Comunicacin
Pruebas Unitarias
Simplicidad
Pruebas de
Aceptacin
Valores

Retroalimentacin
Historias del usuario
o casos de uso

Costo y al efecto

Valenta Disciplina

Respeto

Ing. Jos Lpez Izquierdo

Herramientas de XP

Ing. Jos Lpez Izquierdo

Herramientas de XP

Ing. Jos Lpez Izquierdo

Herramientas de XP

Ing. Jos Lpez Izquierdo

Herramientas de XP

Ing. Jos Lpez Izquierdo

 Roles XP

Programador Cliente

Responsable de implementar las historias de Determina la funcionalidad que se pretende en

usuario por el cliente. cada iteracin y define las prioridades de
implementacin segn el valor de negocio que
El Programador tambin es responsable de aporta cada historia.
disear y ejecutar los test de unidad del
cdigo que ha implementado o modificado. El Cliente tambin es responsable de disear y
ejecutar los test de aceptacin.

Ing. Jos Lpez Izquierdo

Roles XP

TESTER TRACKER
Es el Encargado de ejecutar las pruebas Consiste en seguir la evolucin de las
regularmente, difunde los resultados dentro estimaciones realizadas por los
del equipo y es tambin el responsable de las programadores y compararlas con el tiempo
herramientas de soporte para pruebas. real de desarrollo.

De esta forma, puede brindar informacin

estadstica en lo que refiere a la calidad de
las estimaciones para que puedan ser
mejoradas.

Ing. Jos Lpez Izquierdo

Roles XP

COACH CONSULTOR
Se encarga de iniciar y de guiar a las Es un Miembro externo del equipo con
personas del equipo en poner en un conocimiento especfico en algn
marcha cada una de las prcticas de tema necesario para el proyecto.
la metodologa XP.
Gua al equipo para resolver un
problema especfico.

Ing. Jos Lpez Izquierdo

Roles XP

GESTOR (BIG BOSS):

Es el vnculo entre el cliente y programadores.
Experto en tecnologa y labores de gestin.
Construye el plantel del equipo, obtiene los recursos necesarios y maneja
los problemas que se generan.
Administra a su vez las reuniones (planes de iteracin, agenda de
compromisos, etc.).
Su labor fundamental es de coordinacin.

Ing. Jos Lpez Izquierdo

El Proceso de XP

Ing. Jos Lpez Izquierdo

El Proceso de XP

Planeacin
El proyecto comienza recopilando las historias de usuarios, las
que constituyen a los tradicionales casos de uso. Una vez obtenidas
estas historias de usuarios, los programadores evalan rpidamente el
tiempo de desarrollo de cada una.
Conceptos Bsicos:
Las historias de usuario
El Plan de entregas
Plan de interacciones
Reuniones diarias

Ing. Jos Lpez Izquierdo

El Proceso de XP

Diseo
La metodologa XP hace especial nfasis en los diseos simple y
claros.
Conceptos bsicos:
Simplicidad
Soluciones
Recodificacin
Metforas

Ing. Jos Lpez Izquierdo

El Proceso de XP

Codificacin
Conceptos Bsicos
Disponibilidad del cliente.- Uno de los requerimientos de XP es tener al cliente
disponible durante todo el proyecto (Historia de Usuario).
Uso de estndares.- programacin basada en estndares.
Programacin dirigida por las pruebas.- para estas pruebas se tiene que construir el
test que el sistema debe pasar.
Programacin en pares.- se minimizan errores y se logran mejores diseos compensando
la inversin de horas.
Integracin permanentes.- trabajar con la ltima versin.
Propiedad colectiva del cdigo.- construir nuevas ideas para el proyecto.
Ritmo sostenido.- mantener un ritmo sostenible y razonable.
Ing. Jos Lpez Izquierdo
El Proceso de XP

Pruebas
Conceptos bsicos
Pruebas unitarias.- Se usa para garantizar que una
funcionalidad especfica, trabaje correctamente.
Deteccin y correccin de errores.- Errores encontrados
(Bug).
Pruebas de aceptacin.- El Cliente debe especificar uno o
diversos escenarios para comprobar que una historia de usuario
ha sido correctamente implementada.

Ing. Jos Lpez Izquierdo

 PRACTICAS DE LA METODOLOGIA XP
Principio o practica Descripcin
Planificacin incremental Los requerimientos se registran en tarjetas de historias y las historias a incluir
en una entrega se determinan segn el tiempo disponible y su prioridad
relativa. Los desarrolladores dividen estas Historias en Tareas de desarrollo.
Entregas pequeas El mnimo conjunto til de funcionalidad que proporcione valor de negocio se
desarrolla primero. Las entregas del sistema son frecuentes e
incrementalmente aaden funcionalidad a la primera entrega.
Diseo sencillo Slo se lleva a cabo el diseo necesario para cumplir los requerimientos
actuales.
Desarrollo previamente Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas
probado para nuevas funcionalidades antes de que stas se implementen.
Refactorizacin Se espera que todos los desarrolladores refactoricen el cdigo continuamente
tan pronto como encuentren posibles mejoras en el cdigo. Esto conserva el
cdigo sencillo y mantenible.
Ing. Jos Lpez Izquierdo
 PRACTICAS DE LA METODOLOGIA XP

Principio o practica Descripcin

Programacin por Los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro y
parejas proporcionando la ayuda necesaria para hacer siempre un buen trabajo.
Propiedad colectiva Las parejas de desarrolladores trabajan en todas las reas del sistema, de modo que no
desarrollen islas de conocimientos y todos los desarrolladores posean todo el cdigo.
Cualquiera puede cambiar cualquier cosa.
Integracin continua En cuanto acaba el trabajo en un a tarea, se integra en el sistema entero. Despus de la
integracin, se deben pasar al sistema todas las pruebas de unidad.
Ritmo sostenible No se consideran aceptables grandes cantidades de horas extras, ya que a menudo el
efecto que tienen es que se reduce la calidad del cdigo y la productividad a medio
plazo.
Cliente presente Debe estar disponible al equipo de la XP un representante de los usuarios finales del
sistema (el cliente) a tiempo completo. En un proceso de la programacin extrema, el
cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los
requerimientos del sistema para su implementacin.
Ing. Jos Lpez Izquierdo
 Origen de SCRUM

Este modelo fue identificado y definido por Ikujiro

Nonaka e Hirotaka Takeuchi a principios de los 80, al
analizar cmo desarrollaban los nuevos productos las
principales empresas de manufactura tecnolgica:
Fuji-Xerox, Canon,Honda, Nec, Epson, Brother, 3M y
Hewlett-Packard
En su estudio, Nonaka y Takeuchi compararon la nueva
forma de trabajo en equipo, con el avance en formacin
de scrum de los jugadores de Rugby, a raz de lo cual
qued acuado el trmino scrum para referirse a ella.
Ing. Jos Lpez Izquierdo
 Que es SCRUM?

Scrum es un framework para trabajar en equipo en una serie de interacciones. Las

fases en las que se divide y define un proceso de SCRUM son las siguientes:
El Quin? y el Qu?: identifica los roles de cada uno de los miembros del
equipo y define su responsabilidad en el proyecto.
El Dnde? y el Cundo?: que representan el Sprint
El Por qu? y el Cmo?: representan las herramientas que utilizan los
miembros de Scrum

Ing. Jos Lpez Izquierdo

Roles en Scrum Quin? y Qu?

Ing. Jos Lpez Izquierdo

 ROLES DE SCRUM

Gerente de Proyecto (Product Owner).

Es el responsable de la visin del producto, de asegurar el
retorno de la inversin en el proyecto.
Est constantemente re-priorizando los elementos
del Product Backlog.
Es quin toma decisiones concernientes al modelo de
negocio.
Decide cuando el producto est listo para una salida o
cuando se debe continuar desarrollando en una nueva
iteracin.
Y puede tambin contribuir como miembro del equipo.
Ing. Jos Lpez Izquierdo
 ROLES DE SCRUM

Facilitador (Scrum Mster)

Es el encargado de facilitar el proceso de SCRUM,
contribuye a crear un ambiente de trabajo favorable y
organizado entre los miembros del equipo.
Se encarga de escudar al equipo de intromisiones externas
para mantener el avance del equipo.
Mantiene visible los artefactos de SCRUM (Product Backlog,
tareas asignaciones, tiempos de entrega).
Promueve mejores prcticas en la ingeniera del software.
Y algo muy importante, no tiene autoridad sobre el equipo,
su funcin es ms bien como facilitador/coordinador.
Ing. Jos Lpez Izquierdo
 ROLES DE SCRUM

Miembros del equipo (Development

Team Members):
Todos los dems miembros que se
encargan del desarrollo,
programadores, diseadores,
skateholders (experto de negocio) y
dems. personas

Ing. Jos Lpez Izquierdo

 El Sprint Dnde? Cundo?

El Sprint es la unidad bsica de trabajo para un

equipo Scrum.
Esta es la caracterstica principal marca la
diferencia entre Scrum y otros modelos para el
desarrollo gil.
Es una simple iteracin llevada a cabo por los
miembros del equipo. Un equipo puede
completar varios sprints durante el desarrollo
del proyecto.
Un Sprint inicia con un equipo que se
compromete a realizar el trabajo y finaliza con
la demostracin de un entregable. El tiempo
mnimo para un Sprint es de una semana y el
mximo es de 4 semanas.
Ing. Jos Lpez Izquierdo
 Scrum Events o Eventos Scrum

1. Planeamiento del Sprint/Sprint Planning

Todos los involucrados en el equipo se renen
para planificar el Sprint.
Durante este evento se decide qu
requerimientos o tareas se le asignar a cada
uno de los elementos del equipo.
Cada integrante deber asignar el tiempo que
crea prudente para llevar a cabo sus
requerimientos. De esta manera se define el
tiempo de duracin del Sprint.

Ing. Jos Lpez Izquierdo

 Scrum Events o Eventos Scrum
2. Reunin de Equipo de Scrum/Scrum team meeting
Estas reuniones se deben realizar diariamente con un
mximo de 15 minutos. Siempre en el mismo horario y
lugar.
En ellas, cada miembro del equipo deber responder tres
simples preguntas:
Qu hiciste ayer?
Qu tienes planeado hacer hoy?
Qu obstculos encontraste en el camino?
Estas reuniones sirven para que todos los miembros del
equipo se apoyen entre ellos.
Si alguno de ellos tiene algn inconveniente que tome
ms tiempo del asignado en resolverse; este debe
tratarse ms a fondo en una reunin enfocada en buscar
la mejor solucin para ello.
Ing. Jos Lpez Izquierdo
 Scrum Events o Eventos Scrum

3. Refinamiento del Backlog/Backlog

Refinement
El Product Owner revisa cada uno de los
elementos dentro del Product
Backlog con el fin de esclarecer cualquier
duda que pueda surgir por parte del equipo
de desarrolladores.
Tambin sirve para volver a estimar el
tiempo y esfuerzo dedicado a cada uno de
los requerimientos.

Ing. Jos Lpez Izquierdo

 Scrum Events o Eventos Scrum

4. Revisin del Sprint/Sprint Review

Los miembros del equipo y los clientes se
renen para mostrar el trabajo de
desarrollo de software que se ha
completado. Se hace una demostracin de
todos los requerimientos finalizados dentro
del Sprint.
En este punto no es necesario que todos los
miembros del equipo hablen. Pueden estar
presentes pero la presentacin est a cargo
del Scrum Master y el Product Owner.

Ing. Jos Lpez Izquierdo

 Scrum Events o Eventos Scrum

5. Retrospectiva del Sprint/Retrospective

En este evento, el Product Owner se rene con
todo su equipo de trabajo y su Scrum
Master para hablar sobre lo ocurrido durante el
Sprint. Los puntos principales a tratar en esta
reunin son:
Qu se hizo mal durante el Sprint para poder
mejorar el prximo
Qu se hizo bien para seguir en la misma senda
del xito
Qu inconvenientes se encontraron y no
permitieron poder avanzar como se tena
planificado
Ing. Jos Lpez Izquierdo
 SCRUM MEETINGS

Planificacin de Sprint (Sprint Planning Meeting)

La Reunin de Planificacin de Sprint tiene un mximo de
duracin de 8 horas para un Sprint de un mes. Para Sprints
ms cortos, el evento es usualmente ms corto.
El Scrum Master se asegura de que el evento se lleve a
cabo y que los asistentes entiendan su propsito.
La Reunin de Planificacin de Sprint responde a las
siguientes preguntas:
Qu puede entregarse en el Incremento resultante del
Sprint que comienza?
Cmo se conseguir hacer el trabajo necesario para
entregar el Incremento?

Ing. Jos Lpez Izquierdo

SCRUM MEETINGS
Ejecucin Diaria
Cada da es necesario coordinar el trabajo del equipo.
Los miembros revisan del trabajo de otros, se revisan
las dependencias, los enfoques... es necesario
asegurarse que estn todos en "la misma pgina" con
respecto al trabajo diario.
En este encuentro se debe eliminar impedimentos que
ralenticen el avance del equipo.
El Facilitador es quin asume la organizacin de la
coordinacin diaria y los acuerdos que de ella se
derivan.
Scrum nos aconseja que el Gerente de Proyecto est
presente en este meeting solo cuando sea muy
necesario, porque su presencia puede intimidar la
creatividad y participacin de los dems..

Ing. Jos Lpez Izquierdo

Beneficios de la Planificacin de la iteracin

Productividad mediante comunicacin:

Todos los miembros del equipo tienen una misma visin del objetivo y se ha utilizado
los conocimientos y las experiencias de todos para elaborar la mejor solucin
entregable en el mnimo tiempo y con el mnimo esfuerzo, eliminando tareas
innecesarias, detectando conflictos y dependencias entre tareas.
Potenciacin del compromiso del equipo:
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 sincronizacin del equipo (Scrum daily meeting).
Una estimacin conjunta es ms fiable
Dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de
los integrantes del equipo.
Ing. Jos Lpez Izquierdo
 SCRUM MEETINGS

Revisin del Sprint

Es en este encuentro donde se alista y revisa la
nueva versin del producto a ser entregado.
Se presenta al cliente los requisitos completados.
En dependencia de los resultados mostrados, los
cambios realizados y el valor agregado en esta
nueva versin, el cliente decide si salir al pblico
o re-planificarse el proyecto.
Se hace una valoracin cualitativa del trabajo
terminado en trminos de calidad y rapidez de la
entrega.
Ing. Jos Lpez Izquierdo
 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?

Ing. Jos Lpez Izquierdo

 Ejecucin de la iteracin

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.

Ing. Jos Lpez Izquierdo

SCRUM MEETINGS

Revisin en Retrospectiva
El equipo revisa cul ha sido su manera de trabajar y
cuales son los impedimentos que han estado
ralentizando el trabajo, mejorando de manera
continua su trabajo.
Este encuentro es muy importante para al
aprendizaje, se debe utilizar varios minutos para
compartir desde el pnto de vista tcnico y
organizativo cuales fueron las mejores prcticas y
establecerlas como acuerdo general.
Es una experiencia muy valiosa para cualquier cliente
formar parte activa de un equipo de desarrollo.
Ing. Jos Lpez Izquierdo
SCRUM MEETINGS

Backlog Refinement Meeting

El equipo revisa cada elemento del Product Backlog y
se asegura de que tanto su descripcin como los
criterios de aceptacin del mismo sean precisos y
reflejen las necesidades exactas del momento actual
del proyecto. Adems el Product Owner ajusta la
prioridad de cada elemento si fuera preciso.
Durante la inspeccin de los elementos por parte del
equipo se identifican aquellos que pudieran haberse
quedado obsoletos, bien porque ya no tienen sentido,
o bien porque ya se han llevado a cabo como parte de
otras tareas

Ing. Jos Lpez Izquierdo

Inspeccin y adaptacin
El ltimo da de la iteracin se realiza la reunin de revisin de la
iteracin. Tiene dos partes:
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.
Retrospectiva (4 horas
mximo).
El equipo analiza cmo ha sido su
manera de trabajar y cules son los
problemas que podran impedirle
progresar adecuadamente, mejorando
de manera continua su productividad.
El Facilitador se encargar de ir
eliminando los obstculos
identificados.
Ing. Jos Lpez Izquierdo
Herramientas de SCRUM

Lista de requisitos priorizada

(Product Backlog)
Lista de tareas de la iteracin
(Sprint Backlog)
Grficos de trabajo pendiente
(Burndown Chart)

Ing. Jos Lpez Izquierdo

 Lista de objetivos / requisitos priorizada
(Product Backlog)
La lista de objetivos/requisitos
priorizada representa la visin y
expectativas del cliente respecto 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).
Es importante reflejar las expectativas
del cliente, por lo tanto esta lista
permite involucrarle en la direccin de
los resultados del producto o proyecto.
Ing. Jos Lpez Izquierdo
 Lista de objetivos / requisitos priorizada
(Product Backlog)
Contiene los objetivos/requisitos de alto
nivel del producto o proyecto, que se
suelen expresar en forma de historias de
usuario.
En la lista se indican las posibles
iteraciones y las entregas (releases)
esperadas por el cliente (los puntos en los
cuales desea que se le entreguen los
objetivos/requisitos completados hasta
ese momento), en funcin de la velocidad
de desarrollo de los equipos que trabajara
en el proyecto.
La lista tambin tiene que considerar los
riesgos del proyecto e incluir los requisitos
o tareas necesarios para mitigarlos.
Ing. Jos Lpez Izquierdo
 Lista de tareas de la iteracin
(Sprint Backlog)
Lista de tareas que el equipo elabora en
la reunin de planificacin de la iteracin
(Sprint planning) como plan para
completar los objetivos/requisitos
seleccionados para la iteracin y que se
compromete a demostrar al cliente al
finalizar la iteracin, en forma de
incremento de producto preparado para
ser entregado.
Esta lista permite ver las tareas donde el
equipo est teniendo problemas y no
avanza, con lo que le permite tomar
decisiones al respecto.
Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y la auto
asignacin que han hecho los miembros del equipo.
Ing. Jos Lpez Izquierdo
 Objetivos como historias de usuario
El primer paso en la estimacin y planificacin gil es la creacin del product
backlog, o sea la definicin del proyecto a realizar.
Se puede dividir en objetivos expresados como historias de usuario (user stories),
cada una aportando valor de negocios incremental e individual.

EJM: Como cliente del banco, quiero pedir un

prstamo para poder comprar una casa .
Ing. Jos Lpez Izquierdo
 Estimacin con Planning Poker
El product backlog es, para ser exactos, una
lista priorizada y estimada de historias.
El proceso de estimacin se puede hacer
utilizando una tcnica llamada planning
poker (pker de planificacin).
El objetivo del planning poker es obtener una
medida de tamao relativo de todas las
historias respecto a s mismas.
Planning poker produce estimaciones en una
medida arbitraria de tamao llamada story points o
puntos de historia

Ing. Jos Lpez Izquierdo

 Lista de tareas de la iteracin
(Sprint Backlog)
TABLERO DE TAREAS (SCRUM
TASKBOARD)
La lista de objetivos a completar en la
iteracin (Product Backlog Items) se
puede gestionar mediante un tabln
de tareas (Scrum Taskboard).
Al lado de cada objetivo se ponen las
tareas necesarias para completarlo,
en forma de post-its, y se van
moviendo hacia la derecha para
cambiarlas de estado (pendientes de
iniciar, en progreso, hechas).
Ing. Jos Lpez Izquierdo
Grficos de trabajo pendiente
(Burndown charts)

Un grfico de trabajo pendiente a lo largo del tiempo muestra la

velocidad a la que se est completando los objetivos/requisitos.
Se pueden utilizar los siguientes grficos de esfuerzo pendiente:
Das pendientes para completar los requisitos del producto o
proyecto (product burndown chart), realizado a partir de la lista
de requisitos priorizada (Product Backlog).
Horas pendientes para completar las tareas de la iteracin (sprint
burndown chart), realizado a partir de la lista de tareas de la
iteracin (Iteration Backlog).

Ing. Jos Lpez Izquierdo

 Grficos de trabajo pendiente
(Burndown charts)
Este tipo de grfico permite realizar
diversas simulaciones:
Ver cmo se aplazan las fechas de
entrega si se le aaden requisitos, ver
cmo se avanzan si se le quitan
requisitos o se aade otro equipo,
etc.

Ing. Jos Lpez Izquierdo

Ing. Jos Lpez Izquierdo
Conclusiones SCRUM

Scrum nos ofrece una metodologa gil que alienta la creatividad,

la interaccin, el aprendizaje.
Nos ofrece una manera inteligente de lidiar con el cambio y es un
punto de partida slido en proyectos donde no se tiene una
definicin clara y completa de todos sus requerimientos.
En equipos de alrededor de 7 personas, se crean vnculos y
relaciones muy fuertes y valiosas en todos los sentidos.

Ing. Jos Lpez Izquierdo

Comparacin Metodologas

Ing. Jos Lpez Izquierdo