Introduccin a tcnicas

giles y Scrum

Curso taller
 Visin

El asistente al curso aprender

los principios y dinmica Scrum
y la filosofa Agile, as como, en
que situaciones aplicarla.
Valores y Principios
de Agile
Agile Manifesto
Individuos e interaccionessobreprocesos y
herramientas
Software funcionandosobredocumentacin

extensiva
Colaboracin con el clientesobrenegociacin

contractual
Respuesta ante el cambiosobreseguir un

plan
Esto es, aunque valoramos los elementos de la
derecha, valoramos ms los de la izquierda.
12 Principios Agiles
1. Nuestra mxima prioridad es satisfacer al cliente a
travsde unatemprana y continua entrega de
software de gran utilidad.

2. Son bienvenidos los cambios de requerimientos,

incluso tarde en el desarrollo. Los procesos giles
aprovechan el cambio para obtener ventajas
competitivas para el cliente.

3. Entregar software funcional con una cierta

frecuencia, en un par de semanas a un par de meses,
con preferencia a la escala de tiempo ms corto.
12 Principios Agiles
4. La gente del negocio y desarrolladores deben
trabajar juntos todos los das en todo el proyecto.

5. Construir proyectos en torno a individuos

motivados. Brindarles el medio ambiente y el
apoyo que necesitan, y confiar en ellos para
hacer el trabajo.

6. El mtodo ms eficiente y eficaz de transmisin

de informacin de un equipo de desarrollo es la
conversacin cara a cara.
12 Principios Agiles
7. Software funcional es la principal medida de
progreso.

8. Procesos giles promueven el desarrollo

sostenible. Los patrocinadores,
desarrolladores y los usuarios deben ser
capaces de mantener un ritmo constante
indefinidamente.

9. La atencin continua a la excelencia tcnica y

el buen diseo mejora la agilidad.
12 Principios Agiles
10. La simplicidad el arte de maximizar la
cantidad de trabajo innecesario 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 eficaces, luego ajusta
su comportamiento en consecuencia.
La Declaracin de Interdependencia

Somos una comunidad de lderes de proyectos altamente exitosos en la

entrega de resultados. Para alcanzar estos resultados:
Aumentamos retorno de la inversin,haciendo del flujo continuo

de valor nuestro enfoque.

Entregamos resultados fiablesmediante la participacin de los

clientes en las interacciones frecuentes y la propiedad compartida.

Esperamos la incertidumbrey la gestionamos a travs de

iteraciones, anticipacin y adaptacin.

Liberamos la creatividad y la innovacinal reconocer que las

personas son la fuentems grande de aportede valor, y creandoun

entorno en el que pueden hacerla diferencia.
Impulsamos el rendimientomediante rendicin de cuentas del

grupo para resultados y la responsabilidad compartida para la eficacia

del equipo.
Mejoramos la eficacia y laconfiabilidada travs de estrategias,

procesos y prcticas especficas a la situacin.

Factores de xito en Agile

Libertad para el cambio

Equipo energizado
Comunicacin con el cliente
Colaboracin
Atencin a la calidad
Incrementalismo
Automatizacin
Beneficios de Scrum

Clientes satisfechos
Mejora de la retorno de la inversin
Reduccin de costos
Resultados rpidos
Confianza para tener xito en un

mundo complejo
Ms alegra
Visin General de
Scrum
Origenes Scrum

Ikujiro Nonaka y Hirotaka Takeuchi (Harvard Business

Review en 1986) The New New Product Development Game,
Jeff Sutherland(VP de Engineering en Easel, Inc) En 1993

Sutherland y su equipo desarrollaron dicho proceso combinando

conceptos del artculo deTakeuchi y Nonaka con conceptos de
desarrollo orientado a objetos, control de procesos empricos,
desarrollo iterativo e incremental, procesos de software e
investigacin de productividad y sistemas complejos adaptativos.
Ken Schwaber estaba buscando la manera de mejorar la

productividad de los equipos de desarrollo de su empresa

(Advanced Development Methods, Inc.), a travs de la mejora de
sus procesos.
En 1995, Ken Schwaber public el primer artculo sobre Scrum en

OOPSLA 1995 (Schwaber 1995)

Scrum and the Perfect Storm.
Scrum Framework

Scrum es un frameworkagile para gestin

de trabajos complejos tales como el
Desarrollo de software
Scrum Framework

Roles x3 Artefactos x3
Actividades x5
Product backlog
Product Sprint
Sprint backlog
owner Sprint planning
Potentially
Product backlog
ScrumMast shippable product
grooming
increment
er Daily scrum

Developme Sprint execution

Sprint review
nt team Sprint

retrospective
Scrum Framework
Equipo Scrum
El Equipo Scrum
Equipos Pequeos < 7
Auto Organizado y autoadministrado
Encargado dehacer la estimacin de historias de

usuario o tems del backlog

Interdisciplinario(architect, programmer, tester,

database administrator, UI designer)

Facultado para convertir tems del backlog en tareas

en las cuales se van a trabajar.

Seguimiento del progreso del proyecto
Responsable de mostrar los resultados del Sprint

para el product owner y los stakeholders al final de

cada sprint.
Drucker Excersise
Integracin de Equipo
What Am I Good At
How do I perform?
What do I value?
What contribution can be expected from me on this
project
Habilidades Tcnicas

TCNICAS UTILES QUE EL

PROGRAMADOR AGILE DEBE
TENER
TDD y Programacin por
Intencin
Qu es la programacin por intencin?
Es una tcnica central utilizada en

ProgramacineXtema(XP), donde se trata

de comunicar de manera clara que es lo
que se tena en mente cuando escribamos
el cdigo, dicho de otra manera, la
intencin con la cual se escribi el cdigo.
Prueba Primero (TDD) y Suposiciones

Cuando hacemos TestDrivenDevelopment,

y programamos la prueba antes de tener el
cdigo real, hacemos la suposicin del
mtodo ideal que necesitamos, imaginamos
los parmetros deber tener y que valor
deber regresar, consideramos
quenombretendra ms sentido para
dicho mtodo y pensamos en qu es lo que
debe hacer, antes de pensar en el cmo
Refactor

Dentro del ciclo deTDDuna etapa fundamental que nos

ayuda a hacer ms claro y legible nuestro cdigo es la
etapa delrefactor, en la cual contamos con las
siguientes opciones para lograr dicho fin:
Renombrar mtodos o variables para que tengan ms
sentido en el contexto de la clase
Extraer y generar mtodos a partir de un cdigo en un
mtodo extenso.
Extraer y generar clasesa partir de cdigo en un
mtodo extenso, en caso de considerarse que el
comportamiento del cdigo est fuera del contexto de
la clase donde est definido.
Product backlog
 El uso de Scrum, siempre hacemos el trabajo ms
valioso primero.
El product owner, con el aporte del resto del equipo
Scrum y los Stakeholders, es responsable de
determinar y gestionar la secuencia de este trabajo
y comunicarla en forma de una lista de prioridades
(u ordenada),
Aprovechamos la conversacin como una
herramienta clave
La comunicacin verbal tiene la ventaja de ser de
alto ancho de banda y proporcionar una respuesta
rpida,
Product Backlog Items (PBI)
Los tems del product
backlog(PBI) son caractersticas
necesarias para cumplir con la
misin del product owner.
A lo largo del proyecto el product
backlog puede contener nuevas
caractersticas, cambios en las
caractersticas, defectos que debe
arreglarse, mejoras tcnicas, etc.
Se ponen en la secuencia correcta
(usando factores tales como el
valor, el costo, el conocimiento, y
el riesgo) dando prioridad a los
tems de alto valor en el backlog
El product backlog es un artefacto
en constante evolucin.
En Scrum, los detalles de
un requisito se negocian
a travs de
conversaciones que
suceden de forma
continua durante el
desarrollo y detalles se
desglosan justo a tiempo
y slo lo suficiente para
que los equipos
comiencen a construir la
funcionalidad para
cumplir ese requisito.
Grooming

En general, la
actividad de crear y
refinacin tems del
product backlog, la
estimacin, y la
priorizacin de estos,
se conoce como
grooming
Tamao
Antes de que
finalicemos de
priorizar, ordenar, u
organizar el product
backlog, tenemos que
conocer el tamao de
cada elemento del
product backlog

Tamao equivale a los

costos, y es necesario
saber el costo para
determinar su
prioridad.
Medida Relativa
Una medida de tamao relativo expresa el
tamao total de un elemento en una forma
tal que el valor absoluto no se considera,
pero el tamao relativo de un elemento en
comparacin con otros artculos se
considera
Ej. caracterstica C es de tamao 2 y
caracterstica E es de tamao 8. Lo que podemos
concluir es que la funcin E es aproximadamente
cuatro veces ms grande que la caracterstica C.
User Stories (Historias de usuario)

Scrum no especifica ningn formato estndar para PBI

User Stories son un formato conveniente para expresar

el valor de negocio deseado para muchos tipos de PBI,

especialmente caractersticas.
Las Historias de los usuarios se elaboran de manera tal

que sean comprensibles para las personas de negocios y

tcnicos.
Son estructuralmente simple y proporcionan un gran

marcador de posicin para una conversacin.

Pueden ser escritos en varios niveles de granularidad y

son fciles de refinar progresivamente.

Las 3 Cs: Card, Conversation, Confirmation (Jeffries

2001).
Card
Originalmente se escriban
las User stories en tarjetas
de: 3 x 5 pulgadas
Unformato de plantilla
comn para la
escritura de historias
de usuario(Cohn2004):
Especificar una clase de
usuarios (el rol de
usuario)
Lo que esa clase de
usuario quiere lograr (la
meta)
Por qu los usuarios
quieren lograr el
objetivo? (el beneficio)
Conversacin
Los detalles de un requisito se
exponen y comunican en una
conversacin entre el equipo de
desarrollo, product owner, y las partes
interesadas(stakeholders).
Puede haber una conversacin inicial,
cuando la historia de usuario se
escribe, otra conversacin cuando es
refinado, an otra cuando se estima,
otra durante la planificacin del sprint
(cuando el equipo se sumerge en los
detalles a nivel de tareas), y por
ltimo, las conversaciones en curso,
mientras que el historia de usuario
est siendo diseados, construidas y
probadas durante el sprint.
Aunque las conversaciones son en
gran parte verbal, con frecuencia se
complementan con documentos.
Confirmacin
Una historia de usuario tambin
contiene informacin de
confirmacin en forma de
condiciones de satisfaccin.
Estos son los criterios de aceptacin

que aclaran el comportamiento

deseado.
Son utilizados por el equipo de

desarrollo para comprender mejor lo

que se va a construir y probar y por
el product owner para confirmar que
la historia de usuario se ha
implementado hasta su satisfaccin.
Estas condiciones se pueden escribir

al reverso de la tarjeta
Estas condiciones de satisfaccin se

pueden expresar como pruebas de

aceptacin de alto nivel.
INVEST del Product Backlog

Independent, Negotiable, Valuable,

Estimatable, Small Testable
(Bill Wake 2003)
Cuando se combina la informacin derivada

de aplicar cada uno de estos criterios, se

obtiene una imagen clara de lo que algn
cambio adicional podramos hacer a la
historia.
Independent / Independiente

Las historias de usuario

deben ser independientes o
al menos slo dbilmente
acoplados entre s
Historias que muestran un
alto grado de
interdependencia complican
la estimacin, priorizando, y
planificacin.
Al aplicar el criterio de
independencia, el objetivo
no es eliminar todas las
dependencias, sino escribir
las historias de una manera
que minimice las
dependencias
Negotiable / Negociable
Las buenas historias captan claramente la esencia de la
funcionalidad del negocio que se desea y por qu se desea.
Sin embargo, dejan espacio para que el Product Owner, los
stakeholders, y el equipo negocien los detalles.
Las historias deben ser acerca del qu? y por qu?, no del
cmo?
Historias negociables son agradables porque nos dan el
margen de maniobra que a veces necesitamos para trabajar
dentro de nuestros presupuestos.
Escribir historias negociables deja claro que el dilogo es
necesario.
Un ejemplo comn de donde se viola la negociabilidad es
cuando el product owner le indica al equipo cmo
implementar una historia
Valuable /Valioso
Historias necesitan ser valiosas para un cliente, usuario, o
ambos.
Est bien tener historias tcnicos, siempre y cuando el product

owner debe de entender por qu aporta valor esa historia

En la prctica, sin embargo, la mayora de las historias tcnicas

no deben ser incluidas en el product backlog

En cambio, este tipo de historias deben ser tareas asociadas a

satisfacer historias valiosas de negocio.

La clave de los criterios de valor es que todas las historias del

backlog deben ser valiosa (valen la pena invertir en ellas) desde

el punto de vista del product owner (vista de usuario y clientes)
No todas las historias son independientes, y no todas las

historias son totalmente negociable, pero todos deben ser

valiosas
Estimatable /Estimable
Las historias deben ser estimables por el equipo que las va a
disear, construir y probar.
Las estimaciones proporcionan una indicacin del tamao y,

por tanto, el esfuerzo y el costo (PRIORIDAD)

El equipo Scrum, por otra parte, puede determinar a partir del

tamao de la historia si se requiere refinamiento o

desagregacin adicional.
Si el equipo no es capaz de dimensionar una historia, la

historia es o demasiado grande o ambiguas para ser

clasificada, o el equipo no tiene los conocimientos suficientes
para estimar un tamao.
Si es demasiado grande, el equipo tendr que trabajar con el product
owner para dividirla en historias ms manejables
Si el equipo no tiene el conocimiento, ser necesario algn tipo de
actividad exploratoria para adquirir la informacin
Small (Sized Appropriately) / Pequea (Tamao
Apropiado)

Las historias deben ser del tamao

adecuado para cuando tenemos la intencin
de trabajar en ellas.
Historias trabajadas en sprints deben ser

pequeas.
Debe tener en cuenta cuando la historia se

trabajar cuando se aplica este criterio.

Testable / Comprobable
Una historia slo debe considerarse finalizada (hecha) ,
entre otras cosas, si se puso a prueba con xito.
Si uno no puede probar una historia debido a la falta de
informacin, la historia no debe ser considerada como
buena candidata para ser parte del backlog
Las historias deben ser comprobable en una manera
binaria ya sea que se apruebe o no.
Debido a que estas pruebas con frecuencia
proporcionan importantes detalles de la historia,
pueden ser necesarias antes de que el equipo incluso
pueda estimar la historia.
No siempre puede ser necesario o posible probar una
historia (Ej. Historias epicas)
Project Inception
La recopilacin de historias

Involucrar a los usuarios como parte del equipo que

est determinando qu construir y est
constantemente revisando lo que se est
construyendo
Talleres de redaccin de historias de usuarios.

El
objetivo del taller es generar una lluvia de ideas en
conjunto alrededor de los valores de negocio que
desee y crear marcadores de posicin de la historia de
usuario para lo que se supone que el producto o
servicio debe hacer.
No se genera un conjunto completo de historias de usuario
desde un inicio.
El taller tiene un enfoque especfico. Ej. Analizar los roles de
usuario o definicin de personas
Eltaller incluye frecuentemente al Product Owner,
ScrumMaster y el equipo de desarrollo, en
colaboracin con los stakeholders internos y externos.
Top- Down o Down- Top
Mapeo de Historias
Story mapping es una tcnica popularizada por Jeff Patton (Patton
2009) Toma una perpectiva centrada en el usuario para generar el
conjunto de historias.
La idea bsica consiste en descomponer las actividades de usuarios

de alto nivel en un flujo de trabajo que se puede descomponer an

ms en un conjunto de tareas detalladas
Patton utiliza trminos como actividad, tarea, y subtarea para

describir la jerarqua dentro de un mapa de historias.

Epic -> Theme -> Sprintable story = Activity -> Task -> Subtask
Epic: Representan las actividades ms grandes que aportan valor
medible al usuario.
Mapeo historia combina los conceptos de diseo centrado en el

usuario con descomposicin de historias

Muestran un flujo de actividades, desde la perspectiva del usuario y

proporcionan un contexto para entender las historias individuales y su

relacin con las unidades ms grandes de valor para el cliente.
Descripcin :Story Mapping

Seleccionar una historia pica

Siguiente pensamos en la secuencia o flujo de

trabajo comn de las tareas del usuario que

conforman la pica(representado por temas-
colecciones de historias relacionadas)
Exponemos los temas a lo largo de una lnea de

tiempo.
Cada tema se descompone entonces en un

conjunto de historias implementables que

estn acomodadas verticalmente en orden de
prioridad
Inception Deck
Es una coleccin de diez preguntas difciles y ejercicios
creado originalmente por Robin Gibbons
Lo usamos para cubrir el rea de iniciacin del proyecto en
mtodos giles
Si podemos conseguir a la gente adecuada en la habitacin
y preguntarles las preguntas correctas, esto va a hacer
maravillas para establecer colectivamente las expectativas
acerca de nuestro proyecto.
Al poner el equipo a travs de una serie de ejercicios y
capturar la salida en un conjunto de diapositivas
(generalmente PowerPoint), podemos conseguir
colectivamente una idea bastante clara de lo que este
proyecto es, lo que no es, y lo que va a tomar para entregar.
Las personas adecuadas:

Cualquier persona directamente

involucrada en el proyecto
clientes, stakeholder, los miembros del
equipo, desarrolladores, testers,
analistas
Descripcin del Inception
Deck:
Por qu estamos aqu.
Crear un discurso de
ascensor.
Disear la caja del producto.
Cree una lista de NOs.
Conocer a los vecinos
Mostrar la solucin.
Preguntar lo que nos quita
el sueo.
Asignarle un tamao
Ser claro sobre lo que va a
obtener
Mostrar lo que va a
necesitar