Gente que hace Scrum sin saber que existe Scrum (Scrum Gathering Bs As 2012)
HABLEMOS DE AGILIDAD, SCRUM - RAZONES, FALLAS Y TIPS
120
1 HABLEMOS DE AGILIDAD RAZONES, FALLAS Y TIPS JORGE HERNÁN ABAD LONDOÑO @jorge_abad Blog http://www.lecciones- aprendidas.info/ Agile Coach, Project Leader, Scrum Master and Always a Learner
-
Upload
jorge-hernan-abad-londono -
Category
Software
-
view
929 -
download
6
Transcript of HABLEMOS DE AGILIDAD, SCRUM - RAZONES, FALLAS Y TIPS
1
HABLEMOS DE AGILIDADRAZONES, FALLAS Y TIPS
JORGE HERNÁN ABAD LONDOÑO@jorge_abad
Blog http://www.lecciones-aprendidas.info/
Agile Coach, Project Leader, Scrum Master and Always a Learner
2
Miembro de Ágiles Colombia
3
Miembro PMI Capítulo Antioquia
pmiantioquia.org @pmiantioquia facebook.com/PMIAntioquia meetup.com/es-ES/Proximo-Capitulo-PMI-Antioquia/
4
Agenda
¿Por qué adoptar metodologías ágiles? ¿Por qué los equipos ágiles son más
rápidos y efectivos que los tradicionales? Fallas Comunes en la Adopción Ágil Tips Preguntas
5
Agenda
¿Por qué adoptar metodologías ágiles? ¿Por qué los equipos ágiles son más
rápidos y efectivos que los tradicionales? Fallas Comunes en la Adopción Ágil Tips Preguntas
6
¿Quiénes…?
7
Contestemos sinceramente
8
UNAS PREGUNTAS
¿Quiénes han o les han fallado en una estimación el cuádruple…El triple….El doble….?
9
UNAS PREGUNTAS
¿Quiénes han trabajado seguido 6 meses o más…
(sábados, domingos y festivos)?
10
UNAS PREGUNTAS
¿Quiénes han trabajado más de 36 horas seguidas…?¿24 horas…?
11
UNAS PREGUNTAS
¿quiénes han tenido
ultimatum familiar?
12
Unas preguntas
¿Se les dañó un paseo o
viaje planeado
debido a un proyecto?
13
UNAS PREGUNTAS
¿a quiénes se les ha dañado una entrega lista?
14
UNAS PREGUNTAS
les han dicho o han dicho:
¿es lo especificado pero no es lo que necesito?
15
UNAS PREGUNTAS
les han dicho o han dicho:
¿es lo especificado pero ya cambió el negocio?
16
UNAS PREGUNTAS
les han dicho o han dicho: ¿Cómo van a pagar ese tiempo?
17
UNAS PREGUNTAS
Han dicho o han pedido
¿Una estimación EXACTA?
18
UNAS PREGUNTAS
Has dicho o has escuchado: ¿a eso vamos a tener que darle manejo?
19
UNAS PREGUNTAS
¿los controles de cambio costaron más que el proyecto original?
20
UNAS PREGUNTAS
¿consideran que el 100% del software construido es
usado….?
21
UNAS PREGUNTAS
¿el 90% del software?¿el 80%?¿el 70%?¿el 60%?¿el 50%?
22
Chaos Manifesto 2013http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf
De las funcionalidades en el sw:• 20% usado frecuentemente• 30% usado algunas veces• 50% poco o nunca usadas
Pareto también se cumple en software
23
UNAS PREGUNTAS
Va el 92% de avance Dos semanas después Va el 92.4% de avance Tres semanas después Va el 92.7% de avance Etc Etc Etc
Han dicho o les han dicho
24
UNAS PREGUNTAS
¿se han demorado cerrando el 10% del proyecto otro 90%?
(o sea, más o menos el 180% del tiempo para todo el proyecto)
25
UNAS PREGUNTAS
¿Las salidas a producción son hiper-preparadas, le llenan de temor y terror y requieren de sus mejores “hombres”?
26
UNAS PREGUNTAS
¿Quiénes han estado en un
proyecto que se ha cumplido alcance,
tiempo, costo, calidad y felicidad?
27
¿Dónde estamos?
28
Creemos que hacer software es…
29
30
31
Navegar en los ríos de la predictibilidad
32
Ensamblar componentes y dar clic derecho: configurar y
desplegar
33
Para acabar más rápido pongo más UMPALUMPAS
34
Hacemos software empleando el enfoque
WATERFALLFAIL
35
36
Pero hacer software es…
37
38
39
«Estudio de la Universidad de Missouri: la vida media del valor de los requisitos ha ido disminuyendo Exponencialmente. En 1980 esta fue de alrededor de 10 a 12 años, en el 2000 había caído a 2 a 3 años, y actualmente está funcionando a alrededor del 6 meses».
"Software Development: How the Traditional Contract Model Increases the Risk of Failure" de Susan Atkinson y Gabrielle Benefield
Radioactividad de los Requisitos
40
41
Hacer software es…
Saber trabajar REALMENTE en equipo Que los riesgos saltan y se materializen por
doquier Convivir con la incertidumbre, y saber como
reaccionar a ella. Saber que no vamos a tenerlo TODO definido, Aprender de las fallas y corregir el camino
(Inspección y Adaptación)
42
43
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
44
¿hemos tratado de resolver el problema del software con la herramienta equivocada?
45
www.agilemanifesto.org
46
Principios del Manifiesto Ágil Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
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.
47
Principios del Manifiesto Ágil 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.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
48
Principios del Manifiesto Ágil Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
49
50
“Nuestro trabajo no es hacer (toneladas de) software,
nuestro trabajo es hacer la MENOR cantidad de SOFTWARE
que maximice el VALOR del negocio de nuestros clientes”
Ángel Medinilla
@angel_m
51
Valor y riesgos en enfoque tradicional y ágil
52
Agenda
¿Por qué adoptar metodologías ágiles? ¿Por qué los equipos ágiles son más
rápidos que los tradicionales? Fallas Comunes en la Adopción Ágil Tips Preguntas
53
Repasemos un poco de Scrum
54
Scrum
CancelGift wrap
Return
Sprint2-4 semanas
Objetivo del Sprint
Sprint Backlog
Incremento del producto potencialmente entregable
ProductBacklog
24 horas
55
Reuniones de Scrum
56
• Sprint Execution
• Review• Retrospectiva
• Sprint Planning
• (kaizen =mejora)
Actuar Planear
HacerVerificar
SCRUM es un ciclo de mejora
continua
57
Hagamos recorderis Recuerdan el Infome del caos donde la
principales causas de fracaso son:– Falta de involucramiento del usuario*– Requisitos incompletos y cambiantes*– Expectativas irreales *– Falta de planificación *
Y las de éxito– Involucramiento del usuario*– Requisitos claros*– Hitos acotados*– Expectativas realista*– Buena planificación*– Proceso ágil**
* The CHAOS Report (1994), Standish Group - http://www.standishgroup.com/sample_research/chaos_1994_1.php
**The CHAOS Report (2013), Standish Group - http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf
58
¿En dónde radica la agilidad si los equipos ágiles
hacen lo mismo o más que los tradicionales?
59
Los roles adecuados para construir el producto– Product Owner– Scrum Master– Team Members
No sobra, ni falta nadieNo hay silos
60
Un Product Owner interesado en LIBERAR
A PRODUCCIÓN EL PRODUCTO LO ANTES POSIBLE Y LO QUE MÁS VALOR GENERE
Que resuelve dudas durante el sprint, que tiene toda la autoridad sobre el producto • El involucramiento del usuario tan buscado
• Se elimina la burocracia• Hay respuesta rápida a inquietudes del equipo
61
El Scrum Master cuida al proceso está preocupado
por mejorar cada vez el desempeño del equipo
Remueve impedimentos Un líder al servicio del
equipo
62
Un equipo: Que tiene un objetivo
claro Que jala trabajo en un
ciclo corto (pull) en vez de que se le asigne (push).
Un equipo autoorganizado y multidisciplinario
63
Enfoque en el valor y no en el alcance
Se posterga lo incierto, se construye lo que genera valor
64
Un Sprint Backlog congelado durante el sprint
65
Un Planning que compromete a los directos responsables.
El compromiso es asumido no asignado
66
El Scrum Diario o Daily que sincroniza al equipo
Evita el trabajo de islas y repúblicas independientes
Ayuda a evidenciar problemas y resolverlos más rápido
67
Un Review que permite validar el producto y compromete más al equipo
Inspección y adaptación sobre el producto
68
La retrospectiva que busca la mejora continua
Inspección y adaptación sobre el equipo y proceso
69
Ciclos cortos de desarrollo (Sprints) que – mitigan riesgos y que estos se propaguen por
largos periodos– Evidenciar el avance
70
Requerimientos (Historias de usuario, Casos de uso, etc) en Ready para el sprint backlog
No se trabaja en algo que no está claro
71
La Definition of Done / DoD/ Definición de Terminado / Realizado que es el criterio de calidad y de entrega claro para todo el equipo
72
TRANSPARENCIA
Transparencia (Visual Management) que permite a todos saber el estado del proyecto y del producto
No hay posibilidad de darle “manejo”
73
Existe una construcción orgánica y completa del
producto, orientadas incialmente al MVP
(Mínimo Producto Viable)
74
75
http://idrawgirls.com/tutorials/2011/12/12/painting-chinese-woman-portrait/
76
Porciones completas de producto (software)
Se entregan al final del ciclo porciones producto que se pueden poner en producción
OJO: NO se entregan capas que NO le entregan valor al cliente
77
Razones para la adopción ágil
La razón radica en que las prácticas de Scrum mitigan bastantes problemas del desarrollo tradicional y aligeran el desarrollo– eliminando reprocesos– mitigando riesgos más rápido – suprimiendo el desperdicio– acabando burocracia – Maximizando la comunicación– Enfocados en entregar software de valor lo antes
posible
78
Estos elementos estan enmarcados por Lean Software Development
Eliminar los desperdicios Ampliar el aprendizaje Decidir lo más tarde posible Reaccionar tan rápido como sea
posible Potenciar el equipo Crear la integridad Véase todo el conjunto
79
State of agile development survey. 9th -2015Version One
Logros de este enfoque
80
Pero no debemos perder el foco
Entender el
problemaLEAN AGILE
ENFÓQUESE EN SOLUCIONES, NO
EN SOFTWARE
CONSTRUYA EL PRODUCTO CORRECTO
CONSTRUYA DE LA FORMA CORRECTA
81
Agenda
¿Por qué adoptar metodologías ágiles? ¿Por qué los equipos ágiles son más
rápidos y efectivos que los tradicionales? Fallas Comunes en la Adopción Ágil Tips Preguntas
82
Fallas Comunes en la Adopción Ágil
83
¿Cual creen ustedes que es el punto de falla más critico de Scrum?
84
Puntos de falla en el Product Owner
Sin visión Sin un roadmap del producto o plan de releases Sin poder sobre el backlog No disponible para aclarar dudas Un Product backlog no priorizado por valor de
negocio
85
Puntos de falla en el Scrum Master
Sin dedicación al equipo Creer que su trabajo es mínimo Que no remueve impedimentos Que no «huele» impedimentos Sin capacidad comunicativa Que no escucha
86
Puntos de falla en el Planning
El backlog no esta en ready El equipo hace malas estimaciones Existe sobre-estimación Falta transparencia
87
Puntos de falla en el Equipo
Pobre conocimiento técnico Part –time Multi-tasking individual Prueban tarde No es multidisciplinario y no puede lograr el
DONE No mejora técnicamente en prácticas de
ingeniería Mal uso de la libertad
88
Puntos de falla en el Daily
Equipo superior a 9 personas Las personas no hablan Las personas no entienden para que sirve Dura más de 15 minutos
89
Puntos de falla en el Review
No muestra codigo trabajando y testeado (El incremento no esta en DONE)
No genere feedback sobre el producto No se inviten interesados
90
Puntos de falla en la Retrospectiva
No hay mejora sprint tras sprint No genera impacto y compromiso en el equipo Se desecha del framework No se inspecciona y mejora el proceso y/o el
equipo
91
Puntos de falla en General
No hay mejora No se eliminan los desperdicios No hay enfoque en el valor No se remueven impedimentos Se hace microgestión El equipo no es retado y se queda en zona de
confort
92
UN SPRINT DE ANÁLISIS UN SPRINT DE DESARROLLO UN SPRINT DE PRUEBAS
Scrum un grupo de cascadas
93
Si se evitan las malas prácticas
94
Ken Schwaber: “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”
95
Creer que Scrum y las metodologías ágiles son una bala de plata
Mitos, Monstruos y Leyendas Urbanas
Ágil también falla
96
En metodologías ágiles no se documenta
Se documenta lo que agrega valor
Mitos, Monstruos y Leyendas Urbanas
97
En metodologías agiles no se realiza planeación
User Story Map
Mitos, Monstruos y Leyendas Urbanas
98
Ágil no necesita diseño previo
Hay un diseño que se realiza y se vá refinandoSprint tras Sprint
Mitos, Monstruos y Leyendas Urbanas
99
Ágil siempre usa “Historias de Usuario“
El Product Backlog no tiene prescrito que sean historias de usuario solo ítemes priorizados los cuales pueden ser requerimientos, en prosa, casos de uso, etc. Pero es de aclarar que las metodologiías ágiles funcionan mejor con historas de usuario.
Mitos, Monstruos y Leyendas Urbanas
100
Ágil no se usan herramientas
Mitos, Monstruos y Leyendas Urbanas
Las hay pero no son el foco, primero las personas y sus interacciones , luego las herramientas.
101
Mitos, Monstruos
Ser ágil es solo proceso y no es necesario lo técnico
Principio 9 del ManifiestoLa atención continua a la excelencia técnica y al buen diseño mejora la agilidad
102
Mitos, Monstruos
Ágil es solo para superdotados
Principio 5 del ManifiestoLos 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.
103
No hay • Ni compromisos• Ni planes• Ni métricas
Es desarrollo hippie
104
Scrum Master igual a Gerente de Proyecto
Podemos hacer Scrum sin un Dueño de Producto
Scrum no funciona con CMMI u otros modelos de procesos
Ágil significa más rápido
Mitos, Monstruos y Leyendas Urbanas – Otros
105
Tips para la adopción ágil
106
Tips
Busque acompañamiento y otros que lo hayan logrado El Scrum Master es esencial No tenga equipos UNI-DISCIPLINARIOS Garantice el DONE Fortalezca el equipo técnicamente y tenga prácticas
como TDD, Integración continua, ATDD, refactoring, automatización de pruebas, etc
Empiece con pocas métricas– Para medir la realidad de los proyectos– No a las personas
107
Tips
Reclute al Cliente Proporcione un Product Owner que tenga voz y voto
sobre el producto y esté disponible para el equipo Evalúe los contratos, permita la colaboración y el riesgo
compartido Haga una semilla y vaya creciendo poco a poco (Scrum
orgánico) Use scrum para implantar scrum
– ciclos cortos, con planeación, revisión y retrospectiva
108
Tips centrales de scrum
No combinar roles No alargar, ni acortar los sprints No suprimir reuniones Retrospectivas, retrospectivas, restrospectivas,
restrospectivas
109
UNAS FRASES Y UNOS NÚMEROS PARA TERMINAR
110
“Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.” Tom DeMarco 2009 - “Software Engineering: An Idea Whose Time Has Come and Gone?”
111
112
Olvídese de la frase,
Mi Organización es un caso especial,«la verdad, todas lo son»
Agile se puede implantar, ya no es una moda se esta convirtiendo en la forma de trabajo de la industria
113
114
PREGUNTAS
115
¡GRACIAS!Jorge H. Abad L.
[email protected]@jorge_abad
Blog http://www.lecciones-aprendidas.info/
116
117 Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador
Anexos
118
Estas presentación contiene algunas diapositivas de
LeanSight – Agustín Villena Proyectalis - Ángel Medinilla Henrik Kniberg Lucho Salazar – Agil es algo que eres
Nota: Traté de dar crédito a todos, pero consideras que faltaste por que no te referencié o debo modificar algo de tu propiedad por favor no dudes en hacérmelo saber, contactándome al email: [email protected]
119
Aviso de Copyright Usted es libre de:
– Compartir- copiar, distribuir y trasmitir el trabajo
– Modificar- adaptar el trabajo
Bajo las siguientes condiciones– Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor
o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).
Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.
Para más información ver http://creativecommons.org/licenses/by/3.0/
120
Información de contacto
Jorge Hernán Abad Londoño– [email protected] – @jorge_abad
Puede eliminar esta (o cualquier diapositiva), pero debe dar crédito de la fuente en algún lugar de su presentación. Utilizar el logotipo y el nombre de la empresa (como en la parte inferior izquierda, por ejemplo) o incluir una diapositiva en algún lugar diciendo que parte (o todo) de su presentación son de esta fuente. Gracias.
