Qu son metodologas giles.

Marcos de referencia que permiten hacer entregas parciales al cliente

e introducir cambios con rapidez en cualquier fase de un proyecto.

Se fundamentan en:
Mejorar la satisfaccin del cliente porque se hacen entregas parciales
del producto o servicio.
El equipo de desarrollo permanece motivado y est auto organizado.
Ahorra costos puesto que se detectan los problemas muy rpido y
as mismo se da la solucin.
Se trabaja con mayor eficiencia debido a que se hacen entregas
parciales en corto tiempo.
Mejoran la calidad del producto puesto que un producto final es
susceptible de mejorar.
 Algunas metodologias giles
Kanban: Es un sistema gil altamente efectivo que se basa en crear
flujos de trabajos cortos y hacer su seguimiento mediante tarjetas
de colores, para saber lo que est por hacer, lo que se est
haciendo y lo que ya se termin. Se basa en:

Visualizar permanentemente el flujo de trabajo.

Limitar la cantidad de trabajo en Proceso.
Realizar un seguimiento al tiempo empleado.
Leer fcilmente el estado de su trabajo mediante tarjetas de
colores.
Eliminar los cuellos de botella.
 Algunas metodologias giles

DSDM: Dinamic Systems Development Methods. Mtodo de

desarrollo de sistemas dinmico. Desarrollado en Inglaterra hacia
1995, se basa en los siguientes principios:
Participacin activa del usuario .
Autonoma.
Entrega frecuente de incrementos.
Las entregas se priorizan de acuerdo a las necesidades del
negocio.
Desarrollo iterativo.
Los cambios de pueden reversar.
 Algunas metodologias giles

CRISTAL: Fue presentada al pblico en 1990, es una familia de

metodologas giles de desarrollo de software. Se centra en las
personas y dice que son ligeras y fciles de adaptar. Los mtodos
Cristal tienen cuatro roles:
Patrocinador.
Diseador principal.
Desarrolladores.
Usuario experto.

FDD: Feature Driven Development, se basa en la realizacin de

un proyecto separado en pequeas funciones que son valoradas
por el cliente y que pueden ser entregadas en menos de dos
semanas, tiene dos principios fundamentales: el desarrollo de
software es una actividad humana y el desarrollo de software es
una funcionalidad valorada por el cliente.
 Algunas metodologias giles
XP:: Xtreme Programer. Es el mtodo gil ms exitoso para desarrollo
de software. Se basa en:
Comunicacin.
Simplicidad.
Retroalimentacin.
Coraje.

Algunos de sus principios son:

El cliente.
Programacin en parejas.
Refactorizacin.
Diseo simple.
Pequeas entregas.
Propiedad colectiva del cdigo.
1986: El primer registro del trmino SCRUM en el desarrollo
de producto en el articulo The New New Product
Development Game. publicado en el Harvard Business
Review. Los autores, Takeuchi, Hirotaka and Nonaka,
Ikujiro aplicaron estas metodologas en empresas como Fuji-
Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and
Hewlett-Packard. De aqu toman el nombre Jeff Sutherland y
Ken Schwaber en 1995. El termino Scrum refiere al Rugby
para destacar la importancia del trabajo en Equipos para el
xito en el desarrollo.
 QU ES SCRUM
Es una metodologa gil, que sirve como marco de referencia y que
contiene una serie de buenas prcticas, para el manejo de proyectos.
Hace mucho nfasis en el trabajo colaborativo en equipo para otorgar
el mayor valor al cliente. Maneja procesos iterativos que entregan
producto parcial al cliente y mejoran la calidad y la eficiencia del
proyecto.
 QUIZ DE CONCEPTOS INICIALES

1. Cul de las siguientes NO es una pregunta que responde el equipo Scrum durante las reuniones diarias de
pie?
Seleccione una:
a. Qu terminar hoy?
b. Qu termin ayer?
c. Estoy enfrentando impedimentos u obstculos?
d. Cmo resolver los impedimentos que estoy enfrentando?

2. La empresa GALILEO Times ha iniciado un proyecto para monitorear a sus vendedores en la ciudad. Cul
NO es una de las caractersticas de este proyecto si se administra segn la metodologa de Scrum?
Seleccione una:
a. El equipo que trabaja en este proyecto se reunir diariamente durante 15 minutos para hacer una lista
de los impedimentos en la conclusin de tareas.
b. El propietario del producto priorizar las tareas que entregarn el mximo valor de negocio.
c. El cliente no siempre define los requerimientos (muy concretos) en etapas tempranas.
d. Se har una planificacin detallada por adelantado para asegurar que los riesgos se identifiquen con
anticipacin.
3. El Core de integrantes del equipo Scrum est compuesto por:
1. El dueo del producto
2. Las partes interesadas
3. El equipo de desarrollo
4. El scrum Master
a. 1, 2, 4
b. 2, 3, 4
c. 1, 3, 4
d. Todos los anteriores
4. Cul debe ser la duracin de una reunin de planificacin de tareas para un Sprint de cuatro
semanas?
Seleccione una:
a. 6 horas
b. 2 horas
c. 4 horas
d. 8 horas
5. Cul de las siguientes opciones NO es un objetivo de la reunin de retrospectiva del sprint?
Seleccione una:
a. Identificar las cosas que el equipo debe empezar a hacer .
b. Identificar las cosas que el equipo debe seguir haciendo y que puedan seguir como las mejores
prcticas.
c. Identificar las cosas que el equipo debe dejar de hacer para procesar problemas y
embotellamientos.
d. Identificar a los miembros del equipo que fueron de gran importancia en el xito del sprint.
 Semanas

Semanas 12-15

Semanas 9-12

Semanas 5-8

Semanas 1 4
SE REPITE DE ACUERDO AL NUMERO DE SPRINTS
 INICIO DEL PROYECTO

CASO DE
NEGOCIO

REUNION DE LA
VISION DEL
PROYECTO

PRODUCT OWNER DECLARACION DE

PROJECT
LA VISION DEL
CHARTER
PROYECTO

SCRUM MASTER Y REUNIONES CON

EQUIPO DE LOS USUARIOS
DESARROLLO

PRODUCT
BACKLOG
 INICIO DEL PROYECTO

PRODUCT
BACKLOG
PRIORIZADO

PRODUCT OWNER
SCRUM MASTER
EQUIPO DE
DESARROLLO

CRONOGRAMA DURACION DE LOS

DE SPRINT
PLANIFICACION
DE
LANZAMIENTO
 DECLARACION DE LA VISION DEL PROYECTO

Es aquello que nos brinda la direccin correcta y gua a

todos los involucrados en el proyecto a travs de un
entendimiento compartido de lo que queremos lograr y
nos encamina hacia una meta comn.

Describe la necesidades del cliente y los atributos que

debe cumplir el producto para satisfacer estas
necesidades.
 REUNION DE PLANIFICACION DEL SPRINT MX 8 HORAS

DIA 1
DIA 2
DIA 3
DIA 4
DIA 5
DIA 6
DIA 7
DIA 8
DIA 9
DIA 10
DIA 11
DIA 12
DIA 13
DIA 14
DIA 15
SPRINT (1 A 4 SEMANAS)

DIA 16
REUNION DIARIA (MXIMO 15 MINUTOS)

DIA ..
REUNION DE REVISION MAXIMO 4 HORAS

REUNION DE RETROSPECTIVA MAXIMO 3 HORAS

 TRANSPARENCIA

Todos los interesados, el equipo, el dueo del producto, el cliente;

todos saben cmo est la situacin en cualquier momento dado.
Que las reglas sean claras, por ejemplo los criterios que usaremos
para dar por Terminado un trabajo. Tiene que haber sido
testeado? Tiene que haber sido revisado por un colega? etc. Todo
muy claro, si es posible, impreso y a vista de todos en la oficina.
 INSPECCIN

Los artefactos de Scrum debe revisarse permanentemente para ver el progreso

del proyecto y detectar variaciones. La inspeccin se hace en 3 aspectos
principales: el proceso, las personas y el producto.

Proceso: se debe revisar detalles como: las herramientas usadas, programacin

por pares, integracin, la efectividad de las reuniones diarias, el tiempo de las
reuniones. Estas revisiones se realizan en la reunin de retrospectiva.

Personas: se revisa el funcionamiento del equipo, la comunicacin, si hay

sobrecarga de trabajo, las tensiones, problemas con algn miembro del equipo.
Estas revisiones se realizan en la reunin de retrospectiva.

Producto: La forma como se est construyendo el producto, el producto est

cumpliendo con la definicin de entregado, estamos realmente entregando un
producto que de valor al negocio. Estas revisiones se realizan en la reunin de
revisin.
 PUNTOS DE HISTORIA

Los Puntos de Historia son el tamao relativo de una historia

comparada con otras historias estimadas por el mismo equipo.
Debe asignarse puntos de historia a cada historia de usuario
antes de iniciar el sprint en la reunin de planificacin. Los
puntos de historia determinan la velocidad del equipo en
completar un sprint.
 HISTORIAS DE USUARIO
Se enfocan en definir lo que el usuario necesita hacer, sin describir el cmo, por lo que
representa el inicio y no el final de las conversaciones.
Las historias de usuario son descripciones cortas y simples de una funcionalidad,
escritas desde la perspectiva de la persona que necesita una nueva capacidad de un
sistema, por lo general el usuario, rea de negocio o cliente.
Enunciado de la historia de usuario: El enunciado est compuesto por el Rol, Accin o
funcionalidad y Resultado. El enunciado no describe detalles de cmo se va a
ejecutar la accin que necesita el usuario.

Para una mejor clasificacin y organizacin puede aadirse un cdigo a cada historia,
para ayudar su identificacin dentro del proyecto.

Identificador (ID) de la historia: Cdigo que identifica la historia en el Proyecto que se

est desarrollando. El formato debe ser elegido por el equipo.

Rol: Es el rol que est desempeando el usuario cuando utiliza la funcionalidad que se
est describiendo. Debe ser lo ms especfico posible, describiendo el rol o actor que se
est desempeando. El enunciado puede escribirse como se sigue: Yo como un [Rol],
Desempeando el rol de [Rol], Como un [Rol], entre otros.
 Por ejemplo:
Yo como usuario de contabilidad.
Desempeando el rol de usuario de contabilidad.
Como un usuario de contabilidad.
Accin / Funcionalidad: Representa la funcin que el rol quiere o necesita hacer en el sistema que se est
desarrollando. Puede diferenciarse entre acciones obligatorias u opcionales, utilizando la palabra puede o
necesita para describir la accin. Por ejemplo:
Necesito realizar bsquedas de productos por categoras.
Puedo seleccionar una categora para ver el nmero de productos que tiene asociado.
Resultados: Lo que el rol necesita lograr al ejecutar la accin. Este es el resultado de ejecutar la accin desde
el punto de vista del rol. Este punto puede ser opcional, pues la historia puede documentarse slo con la
definicin del rol y la accin.
Una vez se definen estos componentes, la frase de historia queda establecida de la siguiente forma:

Yo como un [Rol], necesito [Descripcin de la funcionalidad], con la finalidad de [Descripcin de la

consecuencia].

Yo como CLIENTE DEL BANCO

Deseo INGRESAR MI INFORMACIN LABORAL ACTUAL
Para QUE EL BANCO DETERMINE SI ME PUEDE PRESTAR O NO
 Historia de usuario - Listado de morosos

YO COMO gerente de sucursal

DESEO el listado de morosos
PARA saber a quin comenzar a cobrar

Criterios de aceptacin
- El listado contendr los campos
- Nombres
- Apellidos
- Cdula
- dias de mora
- monto del prstamo
- Monto adeudado
- Porcentaje de deuda frente al monto
- tipo de prstamo
- El listado debe estar ordenado x das de mora descendente
- Debe generarse un informe por cada sucursal
- Quienes tengan mora
- mayor a180 das en color rojo
- 60-179 color amarillo
- color negro
- Exportable a Excel
- Paginado por cada 20 registros
- Accede solo el Gerente de sucursal
- En la parte superior de reporte debe aparecer la fecha de corte (fecha en que se genera)
 SGB CUERPO DE ASESORAMIENTO DE SCRUM

Cuerpo de asesoramiento de Scrum es una funcin opcional,

que generalmente consiste en un conjunto de documentos y/o
un grupo de expertos que normalmente estn involucrados en
la definicin de objetivos relacionados con la calidad, las
regulaciones gubernamentales, la seguridad y otros parmetros
claves de la organizacin. El SGB gua el trabajo llevado a cabo
por el Propietario del producto, Scrum Master y Equipo Scrum.
 EQUIPO AUTOORGANIZADO
Comparte informacin y los miembros confan entre ellos. Realiza de manera
conjunta las siguientes actividades:
Seleccionar los requisitos que se compromete a completar en un sprint, de forma
que estn preparados para ser entregados al cliente.
Estimar la complejidad de cada historia de usuario en la lista priorizada del
productos.
En la reunin de planificacin del sprint decide cmo va a realizar su trabajo:
Seleccionar las historias de usuario que pueden completar en cada sprint,
realizando al product owner las preguntas necesarias.
Identificar todas las tareas necesarias para completar cada historia de usuario.
Estimar el esfuerzo necesario para realizar cada tarea o historia.
Cada miembro del equipo se autoasigna las tareas.
Durante la sprint, trabajar de manera conjunta para conseguir los objetivos del
sprint. Cada especialista lidera el trabajo en su rea y el resto colaboran si es
necesario para poder completar una historia o tarea.
Al finalizar el sprint:
Demostrar al dueo del producto las historias de usuario completadas en cada
sprint.
Hacer una retrospectiva la final de cada sprint para mejorar de forma continua su
manera de trabajar.
 COLABORACIN

Concientizacin: Conocer y estar conscientes del trabajo de los dems

integrantes del grupo.
Articulacin: Dividir el trabajo en unidades entre los miembros del equipo.
Apropiacin: El equipo debe adaptar la tecnologa a su situacin especfica.
Colocacin: Equipos que trabajan en la misma localizacin fsica, maximizando la
comunicacin entre ellos.
 PRIORIZACION DEL PRODUCT BACKLOG
El product backlog se prioriza por valor, segn el valor que cada tem aporta al
negocio, siendo responsabilidad del product owner asignar (o averiguar) dicho
valor y con base en ello realizar la priorizacin.

Priorizar el product backlog genera bastantes dudas. Hay quien quiere poner
muchas cosas a prioridad nmero 1 (que bsicamente es como no priorizar
nada), hay quien se pierde con tanta cosa en el product backlog que no sabe
cmo priorizar, etc., hay de todo.

Y es por ello por lo que en los ltimos aos, en el mundo gil, han ido
apareciendo diferentes tcnicas de priorizacin de requisitos, tems, historias
de usuario, etc., dicho sea de paso, muchas de ellas son adaptaciones de
clsicos a la era gil.
Las siguientes son 3 tcnicas de priorizacin en product backlog:

Filtro de prioridad
En su filtro de priorizacin, las columnas se etiquetan de izquierda a derecha como prioridad 3,
prioridad 2 y prioridad 1.
Prioridad 1: Un tem en el que estamos trabajando actualmente o existe la intencin de trabajar
en l en forma inmediata.
Prioridad 2: Un elemento que debera estar listo en la mayor brevedad posible.
Prioridad 3: Un tem en el que debemos trabajar en breve.

Pirmide de Priorizacin
Utiliza las mismas ideas que el filtro de prioridad dividiendo en tres partes las prioridades, pero
esta vez en una pirmide.
Prioridad uno, parte superior de la pirmide, con la ms alta prioridad, al ser la parte de la
pirmide con menos rea slo debera entrar un tem.
Prioridad dos, en el centro de la pirmide. Esto es para las tareas se iniciarn tan pronto como
se disponga de recursos
Prioridad tres, en la parte inferior de la pirmide, donde, al ser ms amplia, puede haber ms
tems.
Por debajo de la base de la pirmide estaran el resto de tems.

Filtros MoSCoW y Kano

Se utiliza para clasificar y priorizar requisitos en funcin de lo que satisfarn al usuario. Y se
basa en dividirlos en cuatro tipos:
Requisitos obligatorios (bsicos).
Necesidades (esperado, lineal).
No esperados (inesperado, excitante).
Indiferentes. El cliente no est interesado en ellos.
 PRINCIPIOS DE LA TEORIA X
Al ser humano medio no le gusta trabajar y evitar a toda costa hacerlo.
En trminos sencillos, los trabajadores son como los caballos: si no se les espuelea
no trabajan. La gente necesita que la fuercen, controlen, dirijan y amenacen con
castigos para que se esfuercen por conseguir los objetivos de la empresa.
El individuo tpico evitar cualquier responsabilidad, tiene poca ambicin y quiere
seguridad por encima de todo, por ello es necesario que lo dirijan.

PRINCIPIOS DE LA TEORA Y
El desgaste fsico y mental en el trabajo es tan normal como en el juego o el reposo,
al individuo promedio no le disgusta el trabajo en s.
No es necesaria la coaccin, la fuerza o las amenazas para que los individuos se
esfuercen por conseguir los objetivos de la empresa.
Los trabajadores se comprometen con los objetivos empresariales en la medida que
se les recompense por sus logros, la mejor recompensa es la satisfaccin del ego y
puede ser originada por el esfuerzo hecho para conseguir los objetivos de la
organizacin.
En condiciones normales el ser humano medio aprender no solo a aceptar
responsabilidades sino a buscarlas.
La mayora de las personas poseen un alto grado de imaginacin, creatividad e
ingenio que permitir dar solucin a los problemas de la organizacin.
 ASPECTOS DE SCRUM

Los aspectos de Scrum se deben abordar y gestionar a lo largo de todo el

proyecto. Los aspectos son 5:

1. Organizacin: Nos habla de entender los roles y responsabilidades de

las personas que intervienen en un proyecto de Scrum.

2. Justificacin del negocio: Es importante para una organizacin llevar a

cabo una evaluacin apropiada del negocio antes de comenzar un
proyecto.

3. Calidad: Scrum define la calidad como la capacidad que tiene el

producto para cumplir con los criterios de entrega y alcanzar el valor del
negocio que espera el cliente.

4. Cambio: Es importante que todo el equipo entienda que los proyectos

en Scrum estn diseados para aceptar los cambios.

5. Riesgo: La gestin del riesgo en Scrum se hace forma iterativa y durante

todo la vida del proyecto.
 CONCEPTOS DE CALIDAD
. En cada iteracin de Scrum se ejecuta el ciclo de mejora continua de Deming en los siguientes
mbitos:
Las expectativas del cliente, a las cuales se va acercando iteracin a iteracin
mediante las siguientes actividades:
La planificacin al inicio de la iteracin, en que el equipo se rene con el cliente, quien ha
expresado sus expectativas mediante la lista priorizada de objetivos del proyecto (product
backlog). El equipo tomatantos objetivos como se vea capaz de cumplir en la iteracin, los refina
con preguntas al cliente y hace una primera descomposicin en las tareas necesarias para
completar cada uno de ellos, creando la definicin de completado y la lista de tareas de la
iteracin (sprint backlog).
La iteracin se desarrolla orientada a objetivos, minimizando el nmero de objetivos en curso
para tener alguno completado cuando acabe la iteracin y no muchos iniciados o a punto de
finalizar.
La demostracin de los resultados completados que el equipo realiza al cliente al final de la
iteracin. El feedback recibido del cliente permite ir acercndose a sus expectativas mediante
ajustes a realizar en siguientes iteraciones, bien porque el equipo no consigui entender
correctamente sus necesidades, bien porque es el cliente quien ahora entiende mejor el
producto, bien porque la velocidad de desarrollo no es la esperada o bien por cambios externos
al proyecto que obligan a cambiar objetivos.
 Riesgo Cmo lo controla Scrum
Ampliacin descontrolada de En Scrum se parte de una lista ordenada por retorno de la inversin de las caractersticas del
caractersticas proyecto. Esta lista es gestionada por el Product Owner y puede ser establecida al principio del
proyecto. Aunque siempre esta abierta a la inclusin de nuevas caractersticas, esto siempre
implica, de manera explicita un aumento en el nmero de Sprint, en la magnitud del proyecto. Esto
ataja los problemas habitualmente relacionados con la ampliacin descontrolada de caractersticas,
pues en Scrum nunca la ampliacin de caractersticas es descontrolada sino el fruto de un proceso
explicito de priorizacin y evaluacin.
Captura de requisitos mal Ninguna metodologa protege de una captura de requisitos mal realizada. Pero una metologa si
realizada puede proteger del losriesgos ms habituales en lo relativo a la captura de requisitos: no realizarla
en absoluto, realizarla de una mnera demasiado exhaustiva, no asumir que cambiaran y no
detallarlos suficientemente antes de la implementacin. En Scrum estos riegos se atajan
respectivamente con la construccin del product backlog, evitando detallar los requisitos en una
fase temprana de proyecto y detallandoles adecuamente, durante el Sprint Planning Meeting,
cuando se va a realizar su implementacin.
Calidad insuficiente La imposicin que Scrum realiza de demostrar de la funcionalidad implementada durante el Sprint
Review actua como fusible de seguridad ante la calidad insuficiente.
Plazos optimistas impuestos En Scrum el equipo es el ltimo responsable de aceptar los plazos y de comprometerse con la
cantidad de caractersticas a implementar durante el Sprint. Nadie puede imponer plazos que no
sean realistas pues el equipo tiene la postestad para no aceptarlos,
Diseo inadecuado De nuevo el Sprint Review y la demostracin que realizamos durante el mismo actua aqu como
una valvula de escape que nos alerta rpidamente de las carencias en lo relativo al diseo
inadecuado.

Personal inadecuado
Fallos de los proveedores
Friccin con los clientes Scrum como metodologa gil que es sigue el manifiesto gil y por tanto el pricipio de poner la
Ninguna metodologa actua de maner explicita en este aspecto. Scrum minimiza las posiblidades
de que en el equipo haya personal inadecuado al incidir mucho en que los miembros del equipo
sean multidisciplinares y que se produzca una continual comunicacin y transmisin de
conocimientos entre ellos mediante el Daily Scrum.
Scrum no aborda este apecto de ninguna manera hasta donde yo se. La nica metodologa que lo
hace de manera explicita es CMMI.
colaboracin con el cliente sobre la negociacin de contratos. Para ello Scrum pone en todo
proyecto un representante de los intereses de cliente, el Product Owner y adems permite y
persigue la colaboracin y la comunicacin con todos los involucrados en el proyecto durante los
Sprint Reviews.
 INICIO DEL PROYECTO

CASO DE
NEGOCIO

REUNION DE LA
VISION DEL
PROYECTO

PRODUCT OWNER DECLARACION DE

PROJECT
LA VISION DEL
CHARTER
PROYECTO

SCRUM MASTER Y REUNIONES CON

EQUIPO DE LOS USUARIOS
DESARROLLO

CRITERIOS DE
PRODUCT TERMINADO
BACKLOG
 INICIO DEL PROYECTO

PRODUCT
BACKLOG
PRIORIZADO

PRODUCT OWNER
SCRUM MASTER
EQUIPO DE
DESARROLLO

CRONOGRAMA DURACION DE LOS

DE SPRINT
PLANIFICACION
DE
LANZAMIENTO