Incepción ágil at infosoft

2,283
-1

Published on

Mike acaba de completar un entrenamiento de Scrum y siente que ha entendido las bases de Scrum así que está convencido que será beneficioso aplicarlo en su próximo proyecto.

Semanas más tarde, le dan luz verde al proyecto y Mike, entusiasmado, convoca a la primer Sprint Planning. Dado que ha pasado un poco de tiempo desde que revisó por última vez los conceptos de Scrum, Mike revisas sus apuntes, y recuerda que tiene que tener un Product Backlog granulado, una visión compartida, un roadmap, etc.

Mike entra en pánico, puesto que no tiene estas cosas listas, y siente que le ha faltado hacer cosas antes del sprint 1.

La presente charla será una explicación para Mike, de qué cosas podría hacer (un workflow y unas prácticas) antes del primer sprint para iniciarlo de la mejor forma.

Published in: Business
5 Comments
22 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,283
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
5
Likes
22
Embeds 0
No embeds

No notes for slide

Incepción ágil at infosoft

  1. 1. Incepción Ágil Todo lo que ocurre antes del primer sprint HELP!
  2. 2. Hiroshi Hiromoto CSP | CSM | PMI-ACP | CSPO | CSD Agile Consultant & Trainer
  3. 3. La historia de Mike
  4. 4. La historia de Mike
  5. 5. Soy Mike! Trabajo como Project Manager
  6. 6. Reconocida empresa de desarrollo
  7. 7. Método Ágiles Scrum XP Kanban Iterativo Valor Incremental
  8. 8. ?
  9. 9. Mike anda al curso!
  10. 10. Mike
  11. 11. Manifiesto ágil Principios Valores
  12. 12. Visión Backlog Daily Meeting Sprint Review Sprint Retro Sprint Planning
  13. 13. Esto es genial!
  14. 14. Quiero hacer un proyecto con Scrum! Director de desarrollo
  15. 15. 2 semanas después
  16. 16. Tu propuesta para usar Scrum ha sido aprobada!
  17. 17. =D
  18. 18. Muchachos el Lunes tenemos Sprint Planning
  19. 19. Sprint Planning Tips - Timeboxea la reunión. - Ten el backlog refinado. - Ten el backlog priorizado. - Repasa la visión al iniciar la sesión. - Comunica al equipo en que parte del producto se desea hacer enfoque. - Repasa el Definition of Done. - Recuerda que debe estar presente todo el equipo. - Recuerda que el equipo estima. - ... Tengo que recordar los tips!
  20. 20. !
  21. 21. Visión? Roadmap? Backlog refinado?
  22. 22. Visión? Roadmap? Backlog refinado? Definición de Terminado? Equipo alineado? Riesgos? Prioridad?
  23. 23. HELP!
  24. 24. Aquí falta algo! (que Scrum no te dice)
  25. 25. HELP! Yo te puedo ayudar! Agile Consultant
  26. 26. Si bien Scrum no lo explicita Hay trabajo previo al 1er sprint
  27. 27. A cont. Tips y Técnicas
  28. 28. Genial!
  29. 29. Todo lo que ocurre (o podría ocurrir) antes del primer sprint
  30. 30. Comencemos
  31. 31. Disclaimer: Cada una de las técnicas que se mencionarán podrían tener su propia charla, en esta ocasión el foco será en dar un visión general de lo que se puede hacer antes del primer sprint
  32. 32. Todo inicia con un “WHY”
  33. 33. Lo primero que tenemos que asegurar es que todos los miembros del equipo entendamos la principal razón del proyecto!
  34. 34. Entonces antes de iniciar el proyecto, convoco a todo el equipo y se explica la razón principal del proyecto.
  35. 35. TIP: Recuerda que no sólo es importante que el equipo sepa esa razón sino que la entienda (el transfondo).
  36. 36. OK! Luego? Una visión! No solo debe existir! Visible y compartida
  37. 37. El Product Vision Board es una herramienta visual que permite construir la visión de un producto. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor
  38. 38. El codename es el nombre que usará el equipo para referirse al proyecto. Entre todos busquen un nombre creativo que los relacione al proyecto. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor
  39. 39. La frase representativa debe ser corta y precisa, debe expresar el alma del producto y ser nuestro nexo hacia lo que aspira a ser. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor
  40. 40. Identifica los grupos de usuarios que utilizarán el producto. ¿Para quién estamos trabajando en el proyecto? Codename Frase representativa Grupo de usuarios Necesidades Producto Valor
  41. 41. ¿Cuáles son las necesidades de tu grupo de usuarios? Aquí se encuentran las razones de ser de tu proyecto. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor
  42. 42. ¿Qué características de tu producto satisfacen las necesidades de tus usuarios? No necesitas hacerlo a gran detalle. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor
  43. 43. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor ¿Qué valor le genera al negocio la satisfacción de la necesidad del grupo de usuario a través del producto? Movimiento obligatorio!
  44. 44. Codename Frase representativa Grupo de usuarios Necesidades Producto Valor Entonces con el Product Vision Board todo el equipo sabrá desde el inicio para quién, por qué y qué valor brindamos al realizar el proyecto.
  45. 45. TIP: Utiliza siempre (que sea posible) una pizarra física y promueve la participación de todo el equipo mediante la interacción con ella.
  46. 46. Nota: A veces utilizo una variación en la columna de valor y coloco el valor para el usuario final. Cuando hago esto coloco también dentro de mi grupo de usuarios a mi cliente/sponsor.
  47. 47. Tengo mi visión, ahora? Conoce a tus vecinos Ah? Vecinos?
  48. 48. Sí! Lanza la siguiente pregunta: ¿Quiénes son los involucrados en este proyecto (fuera del equipo)?
  49. 49. Plasma el mapa de tu equipo y sus vecinos físicamente y muéstralo al resto, de seguro alguno identifica a uno nuevo!
  50. 50. Entonces no es suficiente que yo crea que sé quienes son los involucrados sino que lo debo tener visible y corroborarlo.
  51. 51. Interesante hay más? Ahora veamos riesgos
  52. 52. Toca preguntarnos: ¿Qué nos mantiene despiertos en las noches?
  53. 53. <inserta tu riesgo favorito> Genera una lista con las cosas que te preocupan del proyecto, aquellas que no te dejan ir a dormir tranquilo
  54. 54. Es bueno saber que cuando trabajamos con Scrum también pensamos en riesgos! <inserta tu riesgo favorito> Un ataque de zombies!
  55. 55. <inserta tu riesgo favorito> TIP: No te quedes solo con la lista, priorízala y toma las medidas que creas necesarias! Por cierto, tampoco abuses con la longitud de la lista!! Un ataque de zombies!
  56. 56. OK, entiendo Ahora solo falta decir... que cosas NO van a salir!
  57. 57. Pon visible y comunica las cosas (funcionalidades) que NO se van a hacer. Muchas veces las asumimos, pero al decirlas genera un conocimiento compartido. Además le da foco al equipo sobre lo que debe construir.
  58. 58. Además así puedo evitar malos entendidos con los involucrados y setear expectativas!
  59. 59. ¿Qué opinas hasta ahora? Bien! Qué sigue? Toca ¡cómo llegar al backlog! Y para eso usaremos algunas técnicas
  60. 60. Definamos personas
  61. 61. Personas es una técnica que nos permite crear un esteriotipo de nuestros usuarios y nos ayuda a ver el producto desde el punto de vista del usuario. Si hemos hecho antes el PVB las personas deberían estar en uno de los grupos de usuario definidos.
  62. 62. Una forma práctica de generar personas es usando este template Nombre y Foto Características Necesidades
  63. 63. Comienza poniéndole un nombre y una foto Nombre y Foto Características Necesidades
  64. 64. Ahora sigue con las características de la persona. Puedes incluir su ubicación, su trabajo, su estilo de vida, etc. Nombre y Foto Características Necesidades
  65. 65. Finalmente determina las necesidades que tiene esa persona que la harían utilizar (comprar) el producto Nombre y Foto Características Necesidades
  66. 66. Nombre y Foto Características Necesidades Ya veo. Y esto lo utilizo para cada uno de los esteriotipos de usuarios que tengo.
  67. 67. Nota: Existen muchas formas de definir personas, busca la que más te acomode! Nombre y Foto Características Necesidades
  68. 68. Y esto ¿cómo me acerca al backlog?
  69. 69. Con la siguiente técnica lo verás!
  70. 70. Es una de mis favoritas!!
  71. 71. El Visual Story Mapping es una herramienta visual que mapear las funcionalidades de un producto contextualizado a un escenario. Su elaboración permite generar de manera más sencilla el Product Backlog
  72. 72. Y como toda herramienta colaborativa lo más importante son las discusiones y conversaciones que se generan en su elaboración
  73. 73. En líneas generales el mapa se construye de la siguiente forma.
  74. 74. En primer lugar definimos el proceso/actividades de alto nivel, que tienen que ver directamente con el proceso de negocio que va a estar relacionado con el producto A A A A
  75. 75. Luego tomamos a nuestras personas definidas previamente y las colocamos en el lado derecho del mapa A A A A P P P P
  76. 76. TIP: Prioriza tus personas, y deja a la más prioritaria en el tope de la lista A A A A P P P P
  77. 77. A continuación tomamos una persona y contamos las tareas que realiza, mapeándola con el proceso definido. A esto le llamo definir una travesía de la persona. A A A A P P P P
  78. 78. Ahora utiliza la misma persona y genera una travesía alternativa. A A A A P P P P
  79. 79. Así sucesivamente para todas las personas A A A A P P P P
  80. 80. TIP: Involucra a todos los miembros del equipo en el armado, recuerda que lo importante son las discusiones que genera. También procura contar una historia al generar las travesías.
  81. 81. Entonces son esas tareas de la persona las que serán transformadas en una o varias funcionalidades que poblarán mi backlog!
  82. 82. Wow! Ya vi la luz!
  83. 83. Ya puedo hacer mi backlog
  84. 84. Antes de eso, quiero hablarte de un concepto más
  85. 85. Se llama Producto Mínimo Viable (MVP) y es usado mucho por emprendedores, pero también te será muy útil A A A A P P P P
  86. 86. El MVP busca que indentifiques las funcionalidades mínimas para que puedas salir a producción y se puede muy fácil utilizando el VSM A A A A P P P P
  87. 87. Solo delimita con una línea el (las) travesías mínimas indispensables para que el producto dé valor y tenga sentido! Y ya tienes tu MVP A A A A P P P P
  88. 88. Entonces mi MVP termina siendo mis funcionalidades más prioritarias y las que van arriba en el Backlog A A A A P P P P
  89. 89. TIP: Busca en realidad lo mínimo! Recuerda, busquemos minimizar el output y maximizar el outcome A A A A P P P P
  90. 90. Creo que ya estoy listo para mi 1er sprint! Sí! Solo te dejo un tip más
  91. 91. El Product Backlog Board es una herramienta visual que le permite al equipo tener centralizado todos los elementos de información necesarios para trabajar los items del backlog Área de personas Área de historias Área de restricciones Área de modelado
  92. 92. En el área de personas colocamos nuestras personas elaboradas anteriormente. Hay que recordar que ellas representan a nuestros grupos de usuarios definidos en la visión Área de personas Área de historias Área de restricciones Área de modelado
  93. 93. En el área de historias coloca tus historias listas para trabajar y las que están en cola. Es básicamente tu Backlog. Área de personas Área de historias Área de restricciones Área de modelado
  94. 94. En el área de restricciones coloca tus requerimientos no funcionales y el diseño de la interfaz Área de personas Área de historias Área de restricciones Área de modelado
  95. 95. Área de personas Área de historias Área de restricciones Área de modelado Finalmente, en el área de modelado coloca cualquier diagrama (flujo, modelo, etc) que le sirva de guía al equipo durante el desarrollo Movimiento obligatorio!
  96. 96. Nota: En algunas ocaciones cambio el área de personas e historias y la reemplazo directamente con el VSM. VSM Área de restricciones Área de modelado
  97. 97. Área de personas Área de historias Área de restricciones Área de modelado Con esto no solo tengo el Backlog visible sino también los requerimientos no funcionales, las interfaces de usuario y los flujos y procesos del modelado
  98. 98. Que te pareció? Ayudó? Si! Ya tengo más claro qué hacer antes del 1er sprint
  99. 99. Muchas Gracias! :) Un gusto ayudar!
  100. 100. Disclaimer: Esto ha sido un conjunto de recomendaciones en función a experiencias que he tenido, no es una guía absoluta!
  101. 101. Referentes en el tema @jrasmusson  @davidhussman @romanpichler  @jeffpatton
  102. 102. Dos buenos libros
  103. 103. Los invitamos a Ágiles2013! El 10, 11, y 12 de Oct. bit.ly/agiles2013
  104. 104. Hiroshi Hiromoto CSP | CSM | PMI-ACP | CSPO | CSD Agile Consultant & Trainer Preguntas? @hhiroshi hiromoto.hiroshi@gmail.com

×