Capacitación herramientas ágiles y Scrum (16 horas)

1. Curso de Scrum
by @joseleerazuri

3. Scrum es
Fácil de aprender y extremadamente
difícil de aplicar

4. Ejercicio:
Colocar en un postit cuales son tus expectativas, o
qué temas quisieras aprender en el curso.

5. Agenda
Día 1:
- Introducción
- Manifiesto Ágil
- Inception Ágil
- Elevator Pitch
- Product Vision
Board
- Story Mapping
- Scrum
- Roles
Día 2:
- Scrum:
- Ceremonias
- Artefactos
- Pilares

6. Ejercicio:
En un postit escribe cuáles serán las Reglas de
Juego, del Curso de Scrum.

7. ¿Scrum es un framework de Moda?
Introducción:

8. Scrum es una realidad

9. Empresas mas grandes que usan Scrum
y hay mas, ….Nokia, Intel, mySpace, Yahoo…..

10. Falso Mito:
Scrum sólo
funciona para
proyectos,
equipos o
empresas
pequeñas.

11. Ejercicio:
Crea un listado de causas, de porqué fracasan los
proyectos de software en tu organización.

12. MANIFIESTO ÁGIL

13. Ustedes no son los únicos
En el 2014: sólo el 34 % de los
proyectos de Desarrollo de
Software fueron exitosos, el 40%
terminaron fuera de tiempo y
costo y el 26% fallaron.
Standish Group en su reporte “Chaos Report”

14. Las diez causas principales de los fracasos en
Proyectos de Software
Por orden de importancia, son:
• Escasa participación de los usuarios.
• Requerimientos y especificaciones incompletas.
• Cambios frecuentes en los requerimientos y especificaciones.
• Falta de soporte ejecutivo.
• Incompetencia tecnológica.
• Falta de recursos.
• Expectativas no realistas.
• Objetivos poco claros y procesos de negocio inestables o pocos maduros.
• Cronogramas irreales.
• Nuevas tecnologías.
Standish Group
2011

15. Los Software no son Tuercas
“Los Software no son Tuercas, no es un Sistema Simple de fabricación, es UN
SISTEMA COMPLEJO (quizás imposible) caracterizar perfectamente a
priori un sistema software”
Requerimientos
Estables:
- Material.
- Diámetro.
- Resistencia.
“Los contratos actuales, están bien diseñados para adquirir tuercas, pero no
contratar Servicios de Software”

16. Sistemas Complejos
• Ley de Ziv: Las especificaciones nunca se entenderán completamente.
• Ley de Humphrey: El usuario no sabrá lo que quiere hasta que el
sistema esté en producción.
• Lema de Wegner: un sistema interactivo nunca puede ser totalmente
especificado ni totalmente testado.
• Lema de Langdon: el software evoluciona más rápidamente conforme
nos acercamos a la región del caos.
• “Andar sobre las aguas y desarrollar software contra especificaciones
escritas es fácil si ambas están congeladas” – Ley de Berard

17. Waterfall

21. 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.
• perfeccionar su comportamiento en consecuencia.

22. 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.
• 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.

24. Maratón Sprint
Vs

26. Desarrollo Iterativo e Incremental

27. Metodologías Ágiles

28. Scrumfall

29. Ejercicio:
Con tu equipo, discute sobre qué proyecto van a
trabajar en este curso.

30. Inception
Inception Agile es una técnica en la que mediante un
proceso colaborativo se obtiene la contextualización de un
proyecto y gracias a esto todos obtienen una visión
compartida de lo que se va a construir, según la
delimitación del alcance y sus prioridades.

31. Ejercicio: Elevator Pitch
en máximo 1 minuto
explica tu idea.

32. Ejercicio: ¿Quienes Somos?
Reune a todo tu equipo, y
que coloquen en postit,
Nombres completos, Rol en
el proyecto, Expectativas.

33. Ejercicio: Product Vision
Board

34. Ejercicio: Story Mapping

35. Teorema de Pareto

36. Ejercicio: MVP

37. La visión financiera
Tradicional: Se invierte $ durante todo el
tiempo, recién al final del producto, se
empieza a recuperar lo invertido.
Ágil:promueve el MVP (mínimo producto
viable).
by @pablitux
Filosofía Lean (Reaccionar tan rápido como sea posible)

38. Scrum

39. Scrum: Un marco de trabajo por el cual las personas
pueden abordar problemas complejos adaptativos, a
la vez que entregar productos del máximo valor
posible productiva y creativamente.

42. Pilares y Valores
Pilares: Transparencia, Inspección y
Adaptación
Valores: Compromiso, coraje, foco,
apertura y respeto

43. Roles Scrum

48. Maratón Sprint
Vs

49. Sprint 0
Pequeño Sprint para estabilizar el inicio del proyecto,
preparar ambientes, terminar las contrataciones, los
accesos, capacitaciones, etc.

50. DoD, DoR
Definition of Done (DoD): Cuáles son los criterios de aceptación para que
una Historia de Usuario o Requerimiento finalice. (Ej: Pruebas Unitarios,
Documentación, TDD, etc).
Definition of Ready (DoR): Cuáles son los criterios de aceptación para que
una Historia de Usuario o Requerimiento puede ser planificada en Sprint (Ej:
Que cuente con un diseño, Caso de Prueba, Criterios de Aceptación).

51. Backlog (PB) y PBI(Item)
Conjunto de requerimientos funcionales o Historias de
Usuarios

52. Historias de Usuario
Yo como ……..
Necesito …….
Para …...

53. Otros.
Epic: Business case (puede ser todo un
proyecto).
Features: Grandes Características (podría ser
un módulo).
No funcionales: Req. Técnicos.
Spike: Documentación, Capacitación.

54. by @malaimo
Priorización del Backlog

55. Nuestra forma de estimación
•Planning poker para estimación
del Desarrollo.
Ajuste con Ratios (Waterfall)
•10 % Planificación.
•15 % Análisis.
•60 % Desarrollo (incluye las Pruebas Unitarias).
•10% Pruebas de Sistema y Funcionales.
•5% Implantación, Capacitación.

56. Ejercicio:
Crea el backlog del proyecto, estimar y priorizar.

57. Ejercicio: Sprint Planning
Seleccionemos la funcionalidad que posiblemente
podamos hacer en el Sprint 1 y luego dividamos el
trabajo en tareas.

58. Reuniones diarias: (15 min de pie)
- ¿Qué hice ayer que ayudó al equipo de desarrollo a cumplir la meta de
Sprint?
- ¿Qué haré hoy para ayudar al equipo de desarrollo a cumplir con la meta
de Sprint?
- ¿Veo algún impedimento que impida que yo o el Equipo de Desarrollo
alcancemos el objetivo de Sprint?

59. Juegos Ágiles - Samurai
1.- Todos reunidos en círculo (Si es posible incluir al Product Owner, Scrum Master y todo el team Dev)
2.- Iniciar con un saludo Japonés en palabras en “Japonés” (lo que se te ocurra), y todo regresan el saludo.
3.- El que inicia saludando ataca a cualquiera del grupo levantando su katana y diciendo “Jun”
4.- El que es atacado, se defiende levantando su katana y diciendo “Ja”
5.- Los dos compañeros que estén a su lado izquierdo y derecho del que fue atacado, lo atacan con su katana
en el estómago, diciendo “bling”
6.- El que fue atacado, inicia en el punto 3, atacando a cualquiera del grupo y así repetir, hasta que alguien del
equipo, en el punto 5, se equivoca o es muy lento en decir “bling”.
7.- Aquel que se equivoque en el punto 5, pide disculpa mirando a los ojos a todos los participantes y luego se
sienta en el centro del círculo, esperando a que termine el juego.
8.- Se continúa, iniciando con el punto 2, hasta que ya sea muy difícil de jugarlo (3 participantes)

60. Tablero Kanban
3 Restricciones

61. Tablero Scrum

62. Scrumban

63. Burndown Chart

64. Métricas en Scrum y Scrumban

65. Herramientas Online

66. Sprint Review
El equipo muestra el incremento del producto (potencialmente usable) al
Product Owner (otros interesados)

67. RETROSPECTIVAS

68. Maratón Sprint
Vs

69. ¿Para qué sirven las Retrospectivas?
Depende del Rol
Ej:
- Equipo de Desarrollo (Para mejorar cada sprint).
- Scrum Master (Para tener tareas que hacer durantes los sprint).
- Product Owner (Porque se atrasa el equipo).

70. ¿Quienes deben de estar en la
Retrospectiva?
Depende del foco
Ej:
- Motivación (sólo equipo de desarrollo).
- Procesos administrativos (sólo
stakeholders, P.O., líderes de equipo).
- Velocidad de un Sprint (Todos).

71. ¿Cuál puede ser el foco de la Retrospectiva?
Depende de las dolencias que
más daño están haciendo al
proyecto (Producto / Proceso).
Ej:
- Equipo (Motivación, Colaboración).
- Producto (Baja calidad).
- Proceso (Velocidad de Sprint)
- Herramientas (HubStaff, Jira, Slack).

72. ¿Cuánto tiempo debe de durar la
Retrospectiva?
Depende del tamaño del equipo o
semanas del sprint
Ej:
- Sprint de 2 semanas con equipos de 8 personas, 2 horas y media de
retrospectivas.

73. ¿Cuando realizar la Retrospectiva?
Depende del hito
Muy importante hacerla al cierre de cada Sprint, pero se pueden hacer, al
cierre del release, al cierre del descubrimiento (inception), al cierre del
planning, incluso al cierre de una retrospectiva (retrospectiva de la
retrospectiva)

74. Técnicas o Ejercicios de
Retrospectivas
Fases de una retrospectiva
Lluvia de
ideas
Recolección
de datos
Priorizar las
oportunidades
de mejoras
Decidir qué
acciones se
harán
Asignar un
responsable

75. ¿Cómo iniciar la retrospectiva?
Depende de si es o no la primera
retrospectiva
- Si es que es la primera retrospectiva, comunicar la importancia de hacer
la retrospectiva, las fases que se seguirán y a dónde se quiere llegar.
- Si no es la primera retrospectiva, se debe de iniciar leyendo los acuerdos y
planes de acción con sus estados del backlog de retrospectiva

76. ¿Debo de usar un backlog de retrospectiva?
Depende de cómo lo gestionas
mejor
Se puede usar un backlog independiente, para registrar los acuerdos y planes
de acción (con responsables) o incluirlo en el backlog del proyecto.

77. Ejemplo del backlog de retrospectiva

78. ¿Qué ejercicio hacer en la retrospectiva?
Depende de la situación del
equipo
- Los equipos son diferentes y también las cosas que tienen que ver con los
equipos pueden ser diferentes en cada iteracción.
- Existe un riesgo de que los equipos se aburran cuando siempre se está
haciendo la retrospectiva de manera similar.

79. Cronología de los ejercicios
Sprint
1 2 3 4 5 6 7 8
Haciendo
Preguntas
Haciendo
Preguntas
Estrella de
Mar
Bote
Índice de
Felicidad
Índice de
Felicidad
Una Palabra
Nombre del
Equipo
Cinco Veces
Por qué

80. Haciendo Preguntas
Con un equipo que es nuevo en las
retrospectivas pueden utilizarse estas 4
preguntas claves:
¿Qué hicimos bien?
¿Qué hemos aprendido?
¿Qué debemos hacer diferente la próxima vez?
¿Qué nos desconcierta todavía?

81. Estrella de Mar

82. Índice de Felicidad

83. Bote

84. Una Palabra
Cuando un equipo está luchando con la forma
en que colabora o si los conflictos y fricciones
personales están obstaculizando el espíritu del
equipo.
Baja Motivación

85. Nombre de un Equipo de Fútbol
Permite inducir al equipo en que piensen en
algo que es más cómodo para ellos y luego
inducirlos a exponer porque se sienten así.

86. Nombre de un Equipo de Fútbol

87. Nombre de un Equipo de Fútbol

88. Cinco veces por qué
Utiliza el análisis de causa raíz para identificar
la causa más profunda de un problema.
El cual ayuda a definir acciones efectivas para
detener los problema que están ocurriendo.