Este documento presenta información sobre desarrollo ágil de software utilizando Scrum. Explica los roles de Scrum, las actividades como Sprint Planning y Daily Meetings, y los artefactos como Product Backlog y Sprint Backlog. También describe los valores fundamentales de Scrum como transparencia, inspección y adaptación.
2. Agenda
Antecedentes y motivación
Agilidad y el Agile Manifesto
Framework Scrum
Manejo de requisitos: User Stories y Backlog
Cómo comenzar
Referencias
Pablo Lischinsky - Evolución Ágil C.A. 2014
3. Redefiniendo el éxito de un proyecto
Técnico
Organizacional
Personal
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
4. Redefiniendo el éxito de un proyecto
¿A quiénes impacta?
Cliente
Usuarios, Interesados
Equipo de desarrollo
Organización
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
6. Takeuchi y
Nonaka, HBR,
1986
Desarrollo de
software
iterativo e
incremental
Built-in instability
Self-organizing teams
Overlapping development phases
Multilearning
Subtle control
Organizational transfer of learning
SCRUM
Priorización/
Pareto
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
Timeboxing
7. Priorización y el principio de Pareto
O principio del 80/20
20% causas
80% efectos
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
8. Funcionalidades utilizadas en un software
El 64% Nunca o
rara vez se utiliza
Rarely
19%
Never
45%
Sometimes
16%
El 20% siempre o
frecuentemente se
utiliza
Often
13%
Always
7%
Sources: Standish group study reported at XP2002 by Jim Johnson, Chairman
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
9. Orígenes de la agilidad
¿Cómo llegamos aquí?
Buscando resolver la crisis del software nacieron varios métodos:
Scrum, eXtreme Programming o XP, DSDM, Crystal Clear,
Adaptive SD, etc.
1995 "Scrum Development Process," in OOPSLA Business Object
Design and Implementation Workshop, J. Sutherland, K.
Schwaber.
2001: Agile Manifesto, 17 firmantes de la industria del software.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
10. En lugar de trabajar así
h=p://www.w4-‐bpm.es/principios-‐manifiesto-‐agil.htm
Preferimos así
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
11. En lugar de trabajar así
¿DoD?
h=p://www.w4-‐bpm.es/principios-‐manifiesto-‐agil.htm
Preferimos así
¿DoD?
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
13. Agile Manifesto
www.agilemanifesto.org
Feb 11-13, 2001
Snowbird ski resort, Utah
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
14. Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo mejores formas 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.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
15. 12 Principios del Manifiesto Ágil
1. Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y un
mes, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que
darles el entorno y el apoyo que necesitan, y confiarles la ejecución del
trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
16. 12 Principios del Manifiesto Ágil
7. El software funcionando es la medida principal de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la
agilidad.
10. La simplicidad (el arte de maximizar la cantidad de trabajo no realizado), es
esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para
a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
17. Valores Ágiles
Para trabajar en Agilidad se necesita una base firme de valores que
sirvan como fundamento para el proceso y los principios del equipo:
Foco
Coraje/Valor
Apertura
Compromiso
Respeto
Otros valores importantes:
Comunicación, Feedback/Retroalimentación, Confianza, Honestidad,
Colaboración, Empoderamiento.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
19. Scrum no es …
http://2.bp.blogspot.com/-SkxCC5L8z40/UXgS3jK_peI/AAAAAAAARII/rflNW7UU4qg/s1600/libro+cocina+craft+de+recetas
+laminas+decorativas+hermanas+bolena+1.JPG
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
20. Scrum
Es un marco de trabajo ágil para desarrollar
productos y servicios en dominios complejos, con
requisitos cambiantes o poco definidos, y donde la
innovación, la flexibilidad y la productividad son
fundamentales.
No es una metodología ni una receta.
Hace visible las disfunciones y el desperdicio en las
organizaciones.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
21. Scrum
Scrum es perverso: simple de entender pero difícil de
aplicar y dominar.
Se basa en el control empírico de procesos y sus tres
pilares: transparencia, inspección y adaptación.
Es centrado en las personas y se fundamenta en
valores, principios y prácticas.
Las prácticas incorporan roles, actividades,
artefactos y sus reglas.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
22. :
o Scrum, roles
Equip
r
Product Owne
•
crum Master
• S
r
• Team membe
:
euniones
des o R
Activida
• Sprint anning
print Pl g
• S
n
ly meeti
• Dai
Review
• Sprint ctive
etrospe
• R
m
quipo Scru
E
efactos: klog
Art
c
duct Ba
• Pro
Backlog
• Sprint t
ncremen
• I
Transparencia, inspección y adaptación, efecto emergente:
más que la suma de sus partes …
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
23. Equipo Scrum
El equipo de trabajo se llama el equipo Scrum y consta
de 3 roles:
• el Product Owner (PO), responsable de qué es lo que
se va a desarrollar y en qué orden,
• el ScrumMaster (SM) es responsable de guiar al
equipo en crear y seguir su propio camino basado en
el marco Scrum,
• y el equipo de desarrollo (DT) responsable de
determinar cómo entregar lo que el PO demandó
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
24. Equipo Scrum
¿cuál es el objetivo de cada
jugador?
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
25. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
26. Actividades o reuniones de Scrum
Limitadas en tiempo (timebox)
Scrum y la gestión del conocimiento
Moderadas por el ScrumMaster
Inputs y outputs muy claros
¿Construcción de actas? Dependiendo de las necesidades
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
27. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
28. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
29. Sprint
Desarrollo superpuesto, no secuencial
Requisitos
Diseño
En lugar de trabajar en
etapas secuenciales ...
Código
Test
... los equipos Scrum
trabajan
transversalmente.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
30. Sprint
Desarrollo superpuesto, no secuencial
Requisitos
Diseño
¿Cómo hacerlo? Test
Código
¡Apoyándose en las modernas
prácticas de la Programación
eXtrema – XP! (mañana …)
En lugar de trabajar en
etapas secuenciales ...
... los equipos Scrum
trabajan
transversalmente.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
31. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
32. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
33. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
34. Equipo de Desarrollo
7±2 integrantes
Diverso, multidisciplinario
TM
Autosuficiente, responsable de todo el proceso: diseñar,
construir y probar el producto
Auto-organizado, determina conjuntamente la mejor forma
de trabajar
Propiedad y responsabilidad colectiva del producto
Trabajo de a pares, en espacio común
Colaboración, gestión del conocimiento
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
35. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
36. ScrumMaster
Guía y mantiene al equipo en el camino de Scrum:
entendimiento de los valores, principios y prácticas.
Falicitador: elimina los obstáculos (barreras, impedimentos)
Desarrolla y protege al equipo de interferencias externas
SM
Se asegura de que Scrum sea implementado correctamente
Moderador de las ceremonias
Desarrolla siempre sus habilidades de liderazgo
Agente de cambio hacia agilidad en la organización. Equivalente
al entrenador/coach en equipos deportivos
Sin autoridad para ejercer control: líder servil, no PM.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
37. Flujo de trabajo Scrum
SM
TM
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
PO
38. Product Owner
Comprender y compartir la visión del producto
PO
Maximizar el ROI
Priorizar el Product Backlog
Hacer el “grooming” o refinamiento del Product Backlog con el
equipo
Colaborar con el equipo
Hacer con el equipo el Release Planning
Comprender y definir el valor de negocio con los
stakeholders
Hacer de intermediario entre el equipo y el cliente
Disponible para el equipo y SM, participa en reuniones
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
39. Resumiendo
Los proyectos tradicionales son como una bala de cañón.
Supuestos:
3) Nada va a
cambiar a lo largo
del camino.
1) El cliente
sabe lo que
quiere.
2) Los
desarrolladores
saben cómo
construirla.
http://www.funciones.webs.com/FuncionCuadratica_archivos/image004.jpg
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
40. Agile es como un misil.
Supuestos:
1) El cliente
descubre lo
que quiere.
3) Las cosas
cambian a
lo largo del
camino.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
41. Timeboxing
Plan
Sem1
A B
C D
Sem2
Sem3
Sem4
Ufff!!!...muy tarde
Escenario tradicional
-> Entregamos ABCD en 4 semanas
A
✗P
✗Q
T
✗
Sem1
Sem2
Sem3
Sem4
Sem5
Sem6
A
Q
P
B
A
Sem1
Sem2
Sem3
Sem4
Sem5
T
Ufff!!!, nuestra velocidad es menor de lo que pensábamos.
Parece que sólo terminaremos AB en la sem 4.
¿Qué debemos hacer ahora?
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
Sem8
Teniendo el software, veo
que CD no son relevantes,
pero requiero E
Escenario ágil
Entregamos producto en cada sprint (2 semanas).
No estamos seguros que podemos terminar ABCD en 4 semanas
Siempre entregamos los más importante primero. A
Sem7
A B
C D
A B
E
Sem6
42. Beneficios de Scrum
¿Ustedes están satisfechos con los resultados que obtienen
actualmente?
¿Creen que entregan suficiente valor a sus clientes, a tiempo,
de calidad y dentro de los costos?
¿Y sus equipos de trabajo? ¿Best place to work?
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
46. Beneficios de Scrum
Clientes + contentos.
Mejor retorno de inversión mediante la entrega
temprana y frecuente de versiones.
Reducen costos
Resultados + rápidos
Confianza en tener éxito en un mundo complejo y mas
competitivo
Equipos mas contentos y motivados, empoderados
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
47. Manejo de Requisitos en Scrum
Los métodos secuenciales y Scrum tratan los requisitos de forma
muy diferente.
Métodos secuenciales: los requerimientos son no-negociables, son
detallados de antemano, sin ninguna prioridad y pretenden ser
independientes del resto del proceso.
Scrum: los detalles de los requerimientos son negociados a través de
conversaciones continuas con el cliente. Se van desarrollando según su
prioridad, justo a tiempo y sólo lo suficiente para que el equipo
comience a desarrollar las funcionalidades respectivas.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
48. Jerarquía de requisitos por nivel de planificación y
granularidad
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
49. Manejo de Requisitos en Scrum: Historias
de Usuario
Las 3 Cs para escribir Historias de Usuario
Card (ficha)
Conversation
Confirmation
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
50. Historia de usuario (User Story): Ficha
ID
<<Descripción>>
Como
<Rol>
Deseo
<Actividad>
Para
<Lograr un objetivo>
Bussines
Value
points
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
Story
points
51. Historia de usuario (User Story)
Us1
Escribir historias de usuario
Como
miembro del equipo
Deseo
escribir
historias de usuario correctamente
usando la metáfora 3C
Para
que el esclarecimiento de los requisitos
se dé con la mayor transparencia posible.
12
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
8
52. Historia de usuario (User Story)
Us1
Escribir historias de usuario
¿Quién?
Como
miembro del equipo
¿Qué?
Deseo
escribir
historias de usuario correctamente
usando la metáfora 3C
Para
que el esclarecimiento de los requisitos
¿Por
qué?
se dé con la mayor transparencia posible.
12
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
8
53. Historia de usuario (User Story)
Us1
Ver lista de oportunidades
Como
Gerente Comercial
Deseo
ver la Lista de Oportunidades
Para
Planear la estrategia comercial
20
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
8
54. Historia de usuario (User Story) – Reverso Ficha
Criterios de aceptación
Dado
que he ingresado al sistema como Gerente Comercial
Cuando estoy en la sección de Oportunidades
Entonces
debo ver las oportunidades ingresadas por todos
los asesores
Dado
que he ingresado al sistema como Gerente Comercial
Cuando selecciono una Oportunidad
Entonces
debo ver el monto y la Probabilidad de cumplimiento
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
55. Historia de usuario (User Story) – Reverso Ficha
Criterios de aceptación
Dado
que he ingresado al sistema como Gerente Comercial
Cuando estoy en la sección de Oportunidades
¡ATDD!
Entonces
debo ver las oportunidades ingresadas por todos
los asesores
Dado
que he ingresado al sistema como Gerente Comercial
Cuando selecciono una Oportunidad
Entonces
debo ver el monto y la Probabilidad de cumplimiento
¡Testers escribiendo
HU!
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
56. Criterio INVEST en buenas Historias de Usuario
Independientes
Negociables
Valuables
Estimables
Small (pequeñas)
Testeables
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
57. Product Backlog (Gestión de requisitos)
Product
Backlog
Items
(PBIs):
Funcionalidades
(features)
Defectos
Trabajo
técnico
Formación/capacitación
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
58. Product Backlog (Gestión de requisitos)
PB: DEEP (Roman Pichler)
Detallado apropiadamente
Estimado
Emergente (dinámico)
Priorizado
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
59. Product Backlog
+
Prioridad
Detalle
más detalle, alta
granularidad
GesSón
dinámica
y
priorizada
por
ROI
de
los
requisitos
-
Poco detalle,
desconocido, baja
granularidad
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
61. Dinámica de la priorización
Product Backlog
El PO pueden re-priorizar los
PBIs de acuerdo a las
necesidades del cliente o el
ROI
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
62. Refinamiento del Backlog
Dinámica de una épica
Product Backlog
Épica
PBI
PBI
PBIListo
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
63. ¿Cómo comenzar una transformación
hacia la agilidad y Scrum?
Con ADAPT (Mike Cohn):
1. Reconocimiento de que hay un problema (Awareness)
2. Deseo de adoptar Scrum para intentar resolver el
problema
3. Capacidad y competencia para tener éxito (Ability)
4. Promoción de Scrum en la organización compartiendo
experiencias y casos de éxito.
5. Transferencia del conocimiento e implicaciones del uso de
Scrum a toda la organización
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
64. ¿Cómo comenzar?
Consensuando un Backlog de cambios:
¡ aplicando Scrum para implementar Scrum !
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
68. Bibliografía
•
•
•
•
•
•
•
The Scrum Guide, Ken Schwaber and Jeff Sutherland, Scrum.org,
2011
Do Better Scrum, Peter Hundermark, 2009
Scrum y XP desde las trincheras, Henrik Kniberg, 2007
Succeeding with Agile, Mike Cohn, 2010.
User Stories Applied for Agile Software Development, Mike Cohn,
2004.
Extreme Programming Explained: Embrace Change, Second
Edition, By Kent Beck, Cynthia Andres, 2004.
Agile Software Development, Robert C. Martin, 2002.
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014
70. Otros recursos
Grupos o comunidades
•
•
•
•
Foro-agiles: http://groups.yahoo.com/neo/groups/foro-agiles/
Agilven: http://groups.google.com/group/agilven y en casi todos los
países de LatAm
Grupos Agiles y Agilven en Linkedin ¡ y muchos otros !
Koans, Katas, Code Retreats … ¡ Software Craftmanship !
Pablo
Lischinsky
-‐
Evolución
Ágil
C.A.
2014