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.

jorge.abad@gmail.com@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: jorge.abad@gmail.com

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– jorge.abad@gmail.com – @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.