Fundamentos y principios

SCRUM

Manifiesto gil

qu es scrum?
Es un marco de trabajo gil por el cual las
personas pueden acometer problemas complejos
adaptativos, a la vez que entregar productos del
mximo valor posible productiva y
creativamente.
Scrum es:
Ligero
Fcil de entender
Extremadamente difcil de llegar a dominar

Qu es scrum?
Scrum se basa en la teora de control de
procesos emprica o empirismo.
Scrum emplea un enfoque iterativo e
incremental para optimizar la predictibilidad y el
control del riesgo.

Qu es scrum?

evolucin

(15 min.)
1 Da

(2-4 hrs.)

(Hasta 8 hrs.)
(1-3 hrs.)

Cmo funciona

Tradicional vs. gil

componentes

Roles en scrum

Cerdos

Gallinas

Quin?
Product Owner

Scrum Master
Equipo de Desarrollo

Quin?
Usuarios

Stakeholders
Expertos

Comprometido en:
El proyecto y el proceso Scrum.

Construir software de manera

regular y frecuente.

Tiene el tocino en el sartn.

Cualquiera que est involucrado e

interesado en el proyecto.
No son parte del proceso Scrum.
Sus ideas, deseos y necesidades son
tomadas en cuenta, pero no en un
sentido en que puedan afectar o
distorsionar el projecto Scrum.

Roles en scrum

Mapenado los roles

El equipo de
desarrollo
Deberes

El equipo debe ser auto-organizado. Los propios miembros del equipo establecern la forma de
hacer su trabajo.
Tiene que ser multifuncional.
Todos los miembros deben trabajar con sus habilidades para cumplir el sprint goal.
Los equipos de desarrollo deben ser pequeos, de 3 -7 personas.
Junto con el Scrum Master, se encargan de establecer los tems del Sprint Backlog, de planificar el
sprint.
Estimar las historias de usuario y tareas.
Hacer la demo.
Implementar pruebas de aceptacin y pruebas unitarias.
Trabajo de calidad y mejora continua de la calidad (refactorizacin, por ejemplo)
Participar en los Daily meeting, Sprint Planning Meeting, Sprint Review y Sprint Retrospective.
Estar motivados.
Saber buenas prcticas de programacin: pair programming, TDD, integracin continua,
refactorizacin, malos olores, patrones de diseo, etc.
Identificar posibles obstculos y comunicrselos al Scrum Master.
Actualizar el trabajo en progreso (burndown chart) (es responsabilidad tanto del equipo de
desarrollo como del Scrum Master)

El equipo de
desarrollo
Derechos

La organizacin tiene que animar al equipo a auto-organizarse, sin

entrometerse en su forma de trabajar.
A que slo bajo contadas y controladas circunstancias, las tareas
del sprint sean modificadas una vez que este ha comenzado.

Equipo gil autoorganizado

Scrum developer

Actitud mosquetero
Todo el equipo es responsable
de la construccin del producto
Habilidades T

Scrum: artefactos

Product backlog
Lista priorizada y secuencial de
caractersticas o historias de
usuario.
Basada en la visin de producto
del PO.
Responsabilidad del PO.
Siempre el trabajo ms valioso
va primero, y va ms detallado.

Sprint backlog

Lista prevista de desarrollo o

ejecucin para un (1) Sprint.

Items primeros en el PB, con

estimacin acorde al Sprint.

Desagregado de los items del

PB en tareas especficas y
asignadas en el DT.

Items susceptibles de ser

afrontados con KANBAN.

Producto
potencialmente
entregable

Una parte o seccin de

producto construida o hecha.
Parte o seccin dispuesta a ser
liberada.
La liberacin es una decisin
de negocio, no es imperativo.

Scrum: actividades

Scrum: actividades

sprint

Sprint planning

Reunin de revisin de PB para llegar a acuerdos (PO, SM, DT).

Seleccin de comn acuerdo de X cantidad de items del PB al
SB.
Estimacin de items (generalmente horas)
Item > Tareas > Llenar la capacidad

Daily scrum
Revisin de inspeccin y adaptacin.
- SM, DT, PO (pasivo)
Daily stand-up
Generalmente:
- Qu logr desde el ltimo Daily?
- Cul es mi plan para el siguiente
Daily?
- Qu obstculos enfrento?
Gallinas y cerdos

Sprint execution

Sprint review

Sprint retrospective

Backlog gromming

Tres maneras de
fracasar en un
proyecto
gil
1 El contrato, el
cliente y el modelo de negocio.
Deca el manifiesto gil que aquello de que la agilidad
requera de Colaboracin con el cliente sobre negociacin
contractual. Pero claro, si tu cliente es de los que te entrega
al principio del proyecto un documento enorme lleno de
requisitos, clausulas y posibles penalizaciones y no vuelves a
verlo hasta el ltimo da de proyecto olvdate de la agilidad,
en serio, no va a funcionar.
La agilidad pretende obtener software que cumpla lo que los
usuarios necesitan no que cumpla lo que pone en un
documento de requisitos.

2 La calidad software.
Antes de ser gil, hazte las siguientes preguntas
Tenemos un robusto control de versiones? programamos con
calidad? hacemos cdigo espagueti? copy paste?
complejidad ciclomtica disparada? pruebas unitarias?
diseo mantenible? refactorizas? etc., etc., etc. Supongo que
saber por dnde voy, no es cuestin de seguir con la lista.
Los anteriores son tan necesarios en un proyecto gil, como en
cualquier proyecto software, pero en uno gil, por lo cortas
que son las iteraciones tiene el doble de impactosi no las
tienes a la perfeccin dudo que la agilidad te dure ms de 5
iteraciones.
Como deca Fowler, If youre afraid to change something it is
clearly poorly designed.

3 La documentacin

Volviendo al manifiesto gil Software funcionando sobre

negociacin extensiva. Lo que no es lo mismo que
Software funcionando Y NO documentacin comprensiva.
Que en agilidad la documentacin es menor, cierto. Que
ocupa otro rol, cierto. Que se crea de otra manera, tambin.
Pero no que no hay documentacin.
Recuerda aquello de cmo lograr que tus clientes nunca
puedan sustituirte y tenerlos atados para la
eternidad.