1. Scrum:
Principios Ágiles

2. Por recorrer…
www.lemondata.com.ar

3. Un recorrido por la historia…
Eliminar los desperdicios:
•Todo aquello que no produce valor agregado
en el proceso.
Respetar a las personas:
•Dejar que las personas piensen y decidan por su cuenta, ellos conocen como
mejorar el proceso en el que trabajan.
Postergar los compromisos:
•Retardar las decisiones hasta que se disponga de mayor información ó no se
pueda esperar más.
Crear Conocimiento:
•Mantener una cultura de mejora continua.
Entregas rápidas:
•Permitir que el cliente pueda aprovechar con anticipación los beneficios del
proyecto.
Desarrollar con calidad interna:
•De manera que el producto pueda ir creciendo con una velocidad sostenida.
Optimizar la totalidad del proceso:
•Mejorar el proceso de creación del producto, desde la idea hasta su entrega.
www.lemondata.com.ar

4. Un recorrido por la historia…
Los inicios de Scrum:
1986: se publicó en el Hardvard Bussiness Review el artículo
“The New New Product Development Game” (por Hirotaka Takeuchi y
Ikujiro Nonaka).
1993: Jeff Sutherland, formó el primer equipo Scrum para el
desarrollo de Software.
1995: Jeff Sutherland y Ken Schwaber presentaron
formalmente el marco de trabajo Scrum, en OOPSLA 95.
2001: Ken Schwaber y Mike Beedle, presentaron el primer libro:
“Agile Software development with Scrum”
www.lemondata.com.ar

5. Un recorrido por la historia…
Manifiesto para el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
http://agilemanifesto.org/
www.lemondata.com.ar

6. Características
Propósito:
• No es un proceso o una técnica para
desarrollar o crear productos, sino que es un marco trabajo en el que se
pueden emplear diversos procesos y técnicas.
• Se basa en la teoría del control empírico de procesos, empleando un
enfoque iterativo e incremental para optimizar la previsibilidad y controlar los
riesgos.
Atributos y valores:
La Transparencia
La Inspección
La Adaptación
www.lemondata.com.ar
Compromiso
Enfoque
Respeto
Coraje

7. Características
TIME- BOX:
•Ayuda a crear regularidad en las
actividades:
 Sprint Planning
 Scrum Daily meeting
 Sprint Review
Sprint Retrospective.
 Sprint
SPRINT:
• Son iteraciones de 2 a 4 semanas, los cuales se inician inmediatamente
después del anterior.
• Son de duración fija: terminan en una fecha específica, aunque no se haya
terminado el trabajo, y nunca se alargan.
• La duración debe ser constante Sprint a Sprint, para producir predictibilidad y
un paso sostenido.
www.lemondata.com.ar

8. Ciclo de trabajo de Scrum
www.lemondata.com.ar

9. ROLES: Product Owner
• Cliente o representante del mismo
(con enfoque al Cliente).
• Crea la visión de producto y es responsable de mantener
actualizada y priorizada la lista de requerimientos (Product
Backlog).
• Sprint a Sprint reprioriza y refina el Product Backlog, de acuerdo
al valor de negocio.
• Acepta o rechaza los resultados del trabajo de un Sprint.
• Decide fechas del release.
• Puede cancelar un Sprint.
Consejos:
• Para que el PO tenga éxito, todos en la organización deben respetar sus decisiones.
• El PO es una persona, no un comité.
www.lemondata.com.ar
• El PO nunca debe ser el Scrum Master.

10. ROLES: Scrum Master
• Responsable de asegurar el
cumplimiento de las reglas y prácticas
de Scrum.
• Facilitador, no Project Manager, es decir, no asignan tareas.
• Elimina los impedimentos del Equipo.
• Se asegura que el Equipo funcione correctamente, reafirmando los
principios de Scrum (auto-organizados y funcionales).
• Protege al Equipo, de nuevos requerimientos durante el Sprint.
Consejos:
• Puede ser un miembro del Equipo. Sin embargo, esto conduce frecuentemente a
conflictos cuando el SM tiene que elegir entre eliminar obstáculos o realizar las tareas.
• El SM nunca debe ser el PO.
• NO CONFUNDIR: Scrum Master = Project Manager
www.lemondata.com.ar

11. ROLES: Team
• Típicamente 7±2 integrantes.
• Responsables del desarrollo del
producto.
• Auto-organizados, sin lideres.
• Deciden que pueden hacer en un Sprint, como lo harán y proveen la
estimación de cada User Story.
• Son multidisciplinarios.
• Los miembros deberían ser fulltime para evitar demoras por multitasking.
• Van tomando las tareas que deseen y las van cumpliendo.
Consejos:
• Ubicarse en el mismo espacio de trabajo, para una mayor sinergia.
• Buscar actividades/técnicas para fomentar el espíritu de colaboración y/o la
www.lemondata.com.ar del equipo.
autonomía

12. ARTEFACTOS: Product Backlog
• Es una lista requerimientos priorizada
por el valor de negocio.
• Compuesta por los items que se pretenden para elaborar el producto:
- User Story (2 – 4 semanas)
- Feature (3– 6 meses)
- EPIC (1– 2 años)
• Esta siempre visible a todos los
interesados.
• El PO, es el responsable de
mantener su contenido y
priorización.
• El Product Backlog es dinámico, y
evoluciona a medida que lo hace el
producto y su entorno.
www.lemondata.com.ar

13. ARTEFACTOS: Product Backlog
PBI – Product Backlog Item:
•Especifica el qué, no el cómo, de
una funcionalidad centrada en el usuario.
• Poseen criterio de aceptación (definición de hecho).
• Escrita en términos del negocio.
• Se suelen dividir en varias tareas.
• El esfuerzo es estimado por el Equipo.
• El valor de negocio es
estimado por PO.
www.lemondata.com.ar

14. ARTEFACTOS: Sprint ó Committed Backlog
• Contiene los PBI que negociaron
el Equipo y el PO, durante el Sprint Planning.
• Los PBI del Product Backlog, se desglosan en tareas para el Sprint
Backlog (de duraciones no menores a 4 horas ni mayores a 16 horas.)
• Los PBI que se convertirán en un
incremento de Producto.
• Los PBI a realizar, deben ser los
posibles a desarrollar en un Sprint.
• Siempre visible para el Equipo.
• Es actualizado Inmediatamente
después del Daily Scrum.
www.lemondata.com.ar

15. ARTEFACTOS: Burndown Chart
• Gráfico que muestra por día, cuanto trabajo
resta para finalizar las tareas del Sprint.
• Muestra el progreso hacia el objetivo, en términos del esfuerzo pendiente y
story points, más que el esfuerzo realizado.
• Se actualiza día a día, luego de que cada miembro del Equipo estima cuanto
tiempo resta para finalizar cada tarea en el Sprint Backlog.
• Facilita la auto-organización
del Equipo.
• No es un reporte para la
administración o gerencia
del proyecto.
www.lemondata.com.ar

16. CEREMONIAS: Sprint Planning
CARACTERISTICAS
DESCRIPCION
Frecuencia
Al comienzo de cada Sprint.
Duración
4 hs, para un Sprint de 2 Semanas.
8 hs, para un Sprint de un mes.
Objetivo
Se obtiene el Sprint Backlog ó Sprint COMMITTED Backlog.
Composición
Primera parte:
 Se discute el Qué se hará durante el Sprint (hasta
completar la velocidad del Equipo).
 Se definen el Objetivo del Sprint, y definiciones de
hecho.
Segunda parte:
 El Equipo determina el Cómo se va a convertir una
funcionalidad en Producto potencialmente
entregable.
PARTICIPANTES
www.lemondata.com.ar
- PO
- EQUIPO
- SM
Primera parte :
- PO
- EQUIPO
- SM
Segunda parte :
-EQUIPO

17. CEREMONIAS: Daily Standup
CARACTERISTICAS
DESCRIPCION
Frecuencia
Una vez al día (a la misma hora y en el mismo lugar).
Duración
15 minutos.
Objetivo
Comunicación y Sincronización:
 Observar el estado de avance de las tareas tomadas
del Sprint Backlog, y los obstáculos existentes.
PARTICIPANTES
Composición
www.lemondata.com.ar
Se contesta tres preguntas:
1. ¿Qué hice desde la última reunión?
2. ¿Qué haré hasta la próxima reunión?
3. ¿Encontré obstáculos/impedimentos?
 No se puede llegar tarde.
Los Interesados no pueden interrumpir.
 Se actualiza tareas del Sprint Backlog y gráficos de
Burndown.
- EQUIPO
- SM
- Interesados

18. CEREMONIAS: Sprint Review
CARACTERISTICAS
DESCRIPCION
Frecuencia
Una vez, al final el Sprint.
Duración
1 a 4 hs.
Objetivo
Mostrar el incremento de producto que el Equipo se
comprometió a trabajar durante el último Sprint.
Composición
 El Equipo muestra el trabajo realizado.
PARTICIPANTES
El PO verifica la realización del Sprint Backlog según la
“definición de hecho”, y puede aceptar o rechazar.
Todo feedback se debe plasmar en el Product Backlog.
Al final, se acuerda la fecha para la próxima reunión.
www.lemondata.com.ar
- EQUIPO
- SM
- PO
- Interesados

19. CEREMONIAS: Sprint Retrospective
CARACTERISTICAS
DESCRIPCION
Frecuencia
Una vez, al final del Sprint Review.
Duración
3 a 4 hs.
Objetivo
Se analiza como se trabajó durante el Sprint anterior y se
revisa el Proceso.
Composición
 Lo facilita el SM.
 Se centran en:
 ¿Qué se hizo bien?
 ¿Qué funcionó mal?
 ¿En qué se puede mejorar?
Finalmente se identifican y priorizan las soluciones, para
aplicar en el próximo Sprint.
PARTICIPANTES
www.lemondata.com.ar
- EQUIPO
- SM

20. ¿Cómo llevarlo acabo?
www.lemondata.com.ar

21. ¿Cómo llevarlo acabo?
Pequeñas Entregas:
•El equipo entrega software funcionando (ó un incremento del
mismo que agrega valor al negocio), al PO, al final de cada Sprint.
Pruebas de Usuarios:
•Pruebas de Aceptación: cada User Story necesita una o más
Pruebas de Aceptación (Las cuales el Equipo debería automatizarlas).
Estándares de Codificación:
•Buscar que todo código en el sistema, pareciera que fue escrito por
un único individuo.
•Los estándares de codificación ayudan a la propiedad colectiva.
www.lemondata.com.ar

22. ¿Cómo llevarlo acabo?
Propiedad Colectiva:
•No existe dueños de determinadas partes de código.
•Cualquiera puede modificar cualquier parte, en cualquier
momento.
•Difundir el conocimiento entre el Equipo.
“Esto se Respalda: por Pruebas Unitarias y /o Programación de a
Pares”
Integración Continua:
•El sistema está integrado todo el tiempo.
El sistema se compila varias veces por día.
Repositorio único de código fuente.
Automatizar el Build.
Compilación Auto – Verificable (pruebas automatizadas)
Commits diarios (es una manera de comunicar al resto y
anticiparse de futuros conflictos)
www.lemondata.com.ar

23. ¿Cómo llevarlo acabo?
Diseño Simple:
•Debe ser lo más sencillo posible.
•Suficientes para cubrir los requerimientos actuales.
•No hacer cosas “por las dudas”.
“El diseño Ágil es evolutivo, no una actividad para realizar
anticipadamente”
Programación de a Pares:
•Todo código productivo es revisado por alguien más, en tiempo real.
Se produce un código de mayor calidad, cuando estamos codo
a codo, que si programamos de forma aislada.
- No es fácil programar de a Pares, lleva unas semanas ver los
resultados.
www.lemondata.com.ar

24. ¿Cómo llevarlo acabo?
Diseño dirigido por Pruebas:
•Desarrollo en ciclos cortos (aplicamos TDD):
Primero se codifica una Prueba de lo que se desea construir.
Luego se debe verificar su fallo (si No falla, no es bueno)
Luego se codifica y verifica la ejecución exitosa de la Prueba.
Refactorizar hasta que se termine el fragmento que quiero
construir (manteniendo las pruebas exitosas).
“Las Pruebas están vinculadas a la IC.”
Refactorización:
•Es la Mejora continua del Diseño.
•Los procesos de Refactorización se enfocan en:
Remover duplicaciones.
Incrementar la cohesión.
Disminuir el acoplamiento.
www.lemondata.com.ar

25. Cerrando…
La agilidad requiere una forma diferente de pensar y de ver las cosas, se
trata sobre todo de valores y principios.
No miremos a Scrum como un conjunto más de prácticas y reglas a seguir,
sino como una guía de valores y principios, que podrá hacer que en EQUIPO,
con ganas de aprender, mejorar, colaborar y estando comprometidos,
desarrollemos Software con un gran Valor agregado y de Calidad.
www.lemondata.com.ar

26. ¿Preguntas?
www.lemondata.com.ar

27. MUCHAS
GRACIAS!!!
REFERENCIAS:
•http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
• http://www.agilemanifesto.org/
•http://softwareagil.blogspot.com.ar/
•http://es.wikipedia.org/wiki/Lean_software_development
www.lemondata.com.ar