Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spanish Redistributable Intro To Scrum

1,776 views

Published on

Adaptación en español de la popular presentación Intro To Scrum

Published in: Education
  • Be the first to comment

  • Be the first to like this

Spanish Redistributable Intro To Scrum

  1. 1. <ul>Una Introducción a Scrum </ul><ul>Adaptación: Alberto Torreblanca V . - CSM Traducción: Ernesto Grafeuille( Noviembre 2008) </ul>
  2. 2. <ul>Estamos perdiendo la carrera de relevos </ul><ul>Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review , January 1986. </ul><ul>“ En enfoque de ‘carrera de relevos’ en el desarrollo de productos ... puede entrar en conflicto con los objetivos de máxima velocidad y flexibilidad. En su lugar, un enfoque holístico o estilo ‘rugby’ - donde un equipo intenta ir a la distancia como una unidad, pasando la pelota hacia adelante y hacia atrás -pueden servir mejor a los actuales requisitos competitivos&quot;. </ul>
  3. 3. <ul><li>Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo.
  4. 4. Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes).
  5. 5. El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.
  6. 6. Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint. </li></ul><ul>Scrum en 100 palabras </ul>
  7. 7. <ul>Orígenes de Scrum </ul><ul><li>Jeff Sutherland </li></ul><ul><ul><li>Scrums iniciales en Easel Corp en 1993
  8. 8. IDX 500 personas haciendo Scrum </li></ul></ul><ul><li>Ken Schwaber </li></ul><ul><ul><li>ADM
  9. 9. Se presenta Scrum en OOPSLA 96 con Sutherland
  10. 10. Autor de tres libros sobre Scrum </li></ul></ul><ul><li>Mike Beedle </li></ul><ul><ul><li>Patrones Scrum en PLOPD4 </li></ul></ul><ul><li>Ken Schwaber and Mike Cohn </li></ul><ul><ul><li>Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance </li></ul></ul>
  11. 11. <ul>Scrum ha sido utilizado por: </ul><ul><li>Microsoft
  12. 12. Yahoo
  13. 13. Google
  14. 14. Electronic Arts
  15. 15. High Moon Studios
  16. 16. Lockheed Martin
  17. 17. Philips
  18. 18. Siemens
  19. 19. Nokia
  20. 20. Capital One
  21. 21. BBC
  22. 22. Intuit </li></ul><ul><li>Intuit
  23. 23. Nielsen Media
  24. 24. First American Real Estate
  25. 25. BMC Software
  26. 26. Ipswitch
  27. 27. John Deere
  28. 28. Lexis Nexis
  29. 29. Sabre
  30. 30. Salesforce.com
  31. 31. Time Warner
  32. 32. Turner Broadcasting
  33. 33. Oce </li></ul>
  34. 34. <ul>Scrum ha sido utilizado para: </ul><ul><li>Software comercial
  35. 35. Desarrollos internos
  36. 36. Desarrollos bajo Contrato
  37. 37. Proyectos Fixed-price
  38. 38. Aplicaciones Financieras
  39. 39. Aplicaciones certificadas ISO 9001
  40. 40. Sistemas Embebidos
  41. 41. Sistemas con requisitos 7x24 y 99.999% de disponibilidad
  42. 42. Joint Strike Fighter </li></ul><ul><li>Desarrollo de video juegos
  43. 43. Sistemas críticos de soporte vital, aprobados por laFDA
  44. 44. Software de control satelital
  45. 45. Sitios Web
  46. 46. Software para Handheld
  47. 47. Teléfonos portátiles
  48. 48. Aplicaciones de Network switching
  49. 49. Aplicaciones de ISV
  50. 50. Algunas de las más grandes aplicaciones en uso </li></ul>
  51. 51. <ul>Características </ul><ul><li>Equipos auto-organizados
  52. 52. El producto avanza en una serie de “Sprints&quot; de dos semanas a un mes de duración
  53. 53. Los requisitos son capturados como elementos de una lista de “Product Backlog&quot;
  54. 54. No hay prácticas de ingeniería prescritas
  55. 55. Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos
  56. 56. Uno de los “procesos ágiles” </li></ul>
  57. 57. <ul>El Manifesto Ágil – una declaración de valores </ul><ul>Fuente: www.agilemanifesto.org </ul><ul>Procesos y herramientas </ul><ul>Individuos e interacciones </ul><ul>sobre </ul><ul>Seguimiento de un plan </ul><ul>Responder ante el cambio </ul><ul>sobre </ul><ul>Documentación exhaustiva </ul><ul>Software que funciona </ul><ul>sobre </ul><ul>Negociación de contratos </ul><ul>Colaboración con el cliente </ul><ul>sobre </ul>
  58. 58. <ul>Nivel de ruido de un proyecto </ul><ul>Simple </ul><ul>Complejo </ul><ul>Anarquía </ul><ul>Complicado </ul><ul>Tecnología </ul><ul>Requisitos </ul><ul>Lejos de Acuerdo </ul><ul>Cerca de Acuerdo </ul><ul>Cerca de Certeza </ul><ul>Lejos de Certeza </ul><ul>Fuente: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. </ul>
  59. 59. <ul>Scrum </ul><ul>Product Backlog </ul><ul>Cancel </ul><ul>Gift wrap </ul><ul>Return </ul><ul>Sprint 2-4 semanas </ul><ul>Objetivo del Sprint </ul><ul>Sprint Backlog </ul><ul>Incremento del producto potencialmente entregable </ul><ul>24 horas </ul>
  60. 60. <ul>Poniendo todo junto </ul><ul>Imagen disponible en www.mountaingoatsoftware.com/scrum </ul>
  61. 61. <ul>Sprints </ul><ul><li>En Scrum los proyectos avanzan en una serie de “Sprints” </li></ul><ul><ul><li>Análogo a las iteraciones en XP </li></ul></ul><ul><li>La duración típica es 2–4 semanas o alo sumo un mes calendario
  62. 62. La duración constante conduce a un mejor ritmo
  63. 63. El product es diseñado, codificado y testeado durante el Sprint </li></ul>
  64. 64. <ul>Desarrollo secuencial vs. superpuesto </ul><ul>Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. </ul><ul>En lugar de hacer todo de una cosa a la vez ... </ul><ul>... los equipos Scrum hacen un poco de todo todo el tiempo </ul><ul>Requisitos </ul><ul>Diseño </ul><ul>Código </ul><ul>Test </ul>
  65. 65. <ul>No hay cambios en un sprint </ul><ul><li>Planee la duración del sprint en torno a cuánto tiempo usted puede comprometerse a mantener los cambios fuera del sprint </li></ul><ul>Cambios </ul>
  66. 66. <ul>Scrum Framework </ul><ul><li>Product owner
  67. 67. ScrumMaster
  68. 68. Team </li></ul><ul>Roles </ul><ul><li>Sprint planning
  69. 69. Sprint review
  70. 70. Sprint retrospective
  71. 71. Daily scrum meeting </li></ul><ul>Reuniones </ul><ul><li>Product backlog
  72. 72. Sprint backlog
  73. 73. Burndown charts </li></ul><ul>Artefactos </ul>
  74. 74. <ul>Scrum framework </ul><ul><li>Product backlog
  75. 75. Sprint backlog
  76. 76. Burndown charts </li></ul><ul>Artefactos </ul><ul><li>Sprint planning
  77. 77. Sprint review
  78. 78. Sprint retrospective
  79. 79. Daily scrum meeting </li></ul><ul>Reuniones </ul><ul><li>Product owner
  80. 80. ScrumMaster
  81. 81. Team </li></ul><ul>Roles </ul>
  82. 82. <ul>Product Owner </ul><ul><li>Define las funcionalidades del producto
  83. 83. Decide sobre las fechas y contenidos de los releases
  84. 84. Es responsable por la rentabilidad del producto (ROI)
  85. 85. Prioriza funcionalidades de acuerdo al valor del mercado/negocio
  86. 86. Ajusta funcionalidades y prioridades en cada iteración si es necesario 
  87. 87. Acepta o rechaza los resultados del trabajo del equipo </li></ul>
  88. 88. <ul>El ScrumMaster </ul><ul><li>Representa a la gestión del proyecto
  89. 89. Responsable de promover los valores y prácticas de Scrum
  90. 90. Remueve impedimentos
  91. 91. Se asegura de que el equipo es completamente funcional y productivo
  92. 92. Permite la estrecha cooperación en todos los roles y funciones
  93. 93. Escudo del equipo de interferencias externas </li></ul>
  94. 94. <ul>El Team </ul><ul><li>Típicamente de 5 a 9 personas
  95. 95. Multi-funcional: </li></ul><ul><ul><li>Programadores, testers, analistas, diseñadores, etc. </li></ul></ul><ul><li>Los miembros deben ser full-time </li></ul><ul><ul><li>Puede haber excepciones (Ej.: Infraestructura, SCM, etc.) </li></ul></ul><ul><li>Los equipos son auto-organizativos </li></ul><ul><ul><li>Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organización </li></ul></ul><ul><li>Solo puede haber cambio de miembros entre los sprints </li></ul>
  96. 96. <ul>Scrum Framework </ul><ul><li>Product owner
  97. 97. ScrumMaster
  98. 98. Team </li></ul><ul>Roles </ul><ul><li>Product backlog
  99. 99. Sprint backlog
  100. 100. Burndown charts </li></ul><ul>Artefactos </ul><ul><li>Sprint planning
  101. 101. Sprint review
  102. 102. Sprint retrospective
  103. 103. Daily scrum meeting </li></ul><ul>Reuniones </ul>
  104. 104. <ul>Sprint Planning meeting </ul><ul>Planificación </ul><ul><li>Decidir como alcanzar el objetivo del Sprint (diseño)
  105. 105. Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features)
  106. 106. Estimar Sprint Backlog en horas </li></ul><ul>Condiciones del Negocio </ul><ul>Capacidad del Equipo </ul><ul>Product Backlog </ul><ul>Tecnología </ul><ul>Producto Actual </ul><ul>Priorización </ul><ul><li>Analizar y evaluar el Product Backlog
  107. 107. Seleccionar el objetivo del Sprint </li></ul><ul>Objetivo del Sprint </ul><ul>Sprint Backlog </ul>
  108. 108. <ul>Planificación del Sprint </ul><ul><li>El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar
  109. 109. Se crea el Sprint Backlog </li></ul><ul><ul><li>Se identifican tareas y cada una es estimada (1-16 horas)
  110. 110. Realizado colaborativamente, no solo por el ScrumMaster </li></ul></ul><ul><li>El diseño de Alto Nivel es considerado </li></ul><ul>COMO planificador de vacaciones, YO QUIERO ver fotos de los hoteles. </ul><ul>Codificar la capa intermedia (8 hs) Codificar la interfaz de usuario (4) Escribir los test fixtures (4) Codificar la clase foo (6) Actualizar test de performance (4) </ul>
  111. 111. <ul>Daily Scrum </ul><ul><li>Parámetros </li></ul><ul><ul><li>Diaria
  112. 112. Dura 15 minutos
  113. 113. Parados </li></ul></ul><ul><li>No para la solución de problemas </li></ul><ul><ul><li>Todo el mundo está invitado
  114. 114. Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar
  115. 115. Ayuda a evitar otras reuniones innecesarias </li></ul></ul>
  116. 116. <ul>Todos responden 3 preguntas </ul><ul><li>No es dar un status report al Scrum Master
  117. 117. Se trata de compromisos delante de pares </li></ul><ul>¿Qué hiciste ayer? </ul><ul>1 </ul><ul>¿Qué vas a hacer hoy? </ul><ul>2 </ul><ul>¿Hay obstáculos en tu camino? </ul><ul>3 </ul>
  118. 118. <ul>Sprint review </ul><ul><li>El equipo presenta lo realizado durante el sprint
  119. 119. Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente
  120. 120. Informal </li></ul><ul><ul><li>Regla de 2 hs preparación
  121. 121. No usar diapositivas </li></ul></ul><ul><li>Todo el equipo participa
  122. 122. Se invita a todo el mundo </li></ul>
  123. 123. <ul>Sprint retrospective </ul><ul><li>Periódicamente, se echa un vistazo a lo que funciona y lo que no
  124. 124. Normalmente 15 a 30 minutos
  125. 125. Se realiza luego de cada sprint
  126. 126. Todo el equipo participa </li></ul><ul><ul><li>ScrumMaster
  127. 127. Product owner
  128. 128. Equipo
  129. 129. Posiblemente clientes y otros </li></ul></ul>
  130. 130. <ul>Start / Stop / Continue </ul><ul><li>Todo el equipo se reúne y discute lo que les gustaría: </li></ul><ul>Comenzar a hacer </ul><ul>Dejar de hacer </ul><ul>Continuar haciendo </ul><ul>Esto es sólo una de las muchas maneras de hacer una retrospectiva. </ul>
  131. 131. <ul>Scrum framework </ul><ul><li>Product owner
  132. 132. ScrumMaster
  133. 133. Team </li></ul><ul>Roles </ul><ul><li>Sprint planning
  134. 134. Sprint review
  135. 135. Sprint retrospective
  136. 136. Daily scrum meeting </li></ul><ul>Reuniones </ul><ul><li>Product backlog
  137. 137. Sprint backlog
  138. 138. Burndown charts </li></ul><ul>Artefactos </ul>
  139. 139. <ul>Product Backlog </ul><ul><li>Los requisitos
  140. 140. Una lista de todos los trabajos deseados en el proyecto
  141. 141. Idealmente cada tema tiene valor para el usuarios o el cliente
  142. 142. Priorizada por el Product Owner
  143. 143. Repriorizada al comienzo de cada Sprint </li></ul><ul>Este es el product backlog </ul>
  144. 144. <ul>Ejemplo de Product Backlog </ul><ul>Backlog item </ul><ul>Estimación </ul><ul>Permitir que un invitado a hacer una reserva. </ul><ul>3 </ul><ul>Como invitado, quiero cancelar una reserva. </ul><ul>5 </ul><ul>Como invitado, quiero cambiar las fechas de una reserva. </ul><ul>3 </ul><ul>Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación disponible </ul><ul>8 </ul><ul>Mejorar el manejo de excepciones </ul><ul>8 </ul><ul>... </ul><ul>30 </ul><ul>... </ul><ul>50 </ul>
  145. 145. <ul>El objetivo del Sprint </ul><ul><li>Una breve declaración de cual será el foco del trabajo durante el sprint </li></ul><ul>Aplicación con B.Datos </ul><ul>Servicios Financieros </ul><ul>Ciencias Biológicas </ul><ul>Funciones de apoyo técnico necesarios para estudios de genética de poblaciones. </ul><ul>Soportar más indicadores técnicos que la empresa ABC en tiempo real y streaming de datos. </ul><ul>Hacer que la aplicación se ejecute en SQL Server, además de Oracle. </ul>
  146. 146. <ul>Gestión del Sprint Backlog </ul><ul><li>Los individuos eligen las tareas
  147. 147. El trabajo nunca es asignado
  148. 148. La estimación del trabajo restante es actualizada diariamente
  149. 149. Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog
  150. 150. El trabajo para el Sprint emerge
  151. 151. Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego.
  152. 152. Actualizar el trabajo restante a medida de que más se conoce </li></ul>
  153. 153. <ul>Ejemplo de Sprint Backlog </ul><ul>Tareas </ul><ul>Codificar UI </ul><ul>Codificar negocio </ul><ul>Testear negocio </ul><ul>Escribir ayuda online </ul><ul>Escribir la clase foo </ul><ul>L </ul><ul>M </ul><ul>M </ul><ul>J </ul><ul>V </ul><ul>8 </ul><ul>16 </ul><ul>8 </ul><ul>12 </ul><ul>8 </ul><ul>4 </ul><ul>12 </ul><ul>16 </ul><ul>8 </ul><ul>4 </ul><ul>11 </ul><ul>8 </ul><ul>4 </ul><ul>8 </ul><ul>8 </ul><ul>Agregar error logging </ul><ul>8 </ul><ul>10 </ul><ul>16 </ul><ul>8 </ul><ul>8 </ul>
  154. 154. <ul>Un Sprint Burndown Chart </ul><ul>Hours </ul>
  155. 155. <ul>Hours </ul><ul>40 </ul><ul>30 </ul><ul>20 </ul><ul>10 </ul><ul>0 </ul><ul>Mon </ul><ul>Tue </ul><ul>Wed </ul><ul>Thu </ul><ul>Fri </ul><ul>Tareas </ul><ul>Codificar UI </ul><ul>Codificar Negocio </ul><ul>Testear Negocio </ul><ul>Escribir ayuda online </ul><ul>L </ul><ul>8 </ul><ul>16 </ul><ul>8 </ul><ul>12 </ul><ul>M </ul><ul>M </ul><ul>J </ul><ul>V </ul><ul>50 </ul><ul>4 </ul><ul>12 </ul><ul>16 </ul><ul>7 </ul><ul>11 </ul><ul>8 </ul><ul>10 </ul><ul>16 </ul><ul>8 </ul>
  156. 156. <ul>Escalabilidad </ul><ul><li>Normalmente los equipos son de 7 ± 2 personas </li></ul><ul><ul><li>La escalabilidad proviene de equipos de equipos </li></ul></ul><ul><li>Factores a tener cuenta </li></ul><ul><ul><li>Tipo de aplicación
  157. 157. Tamaño del equipo
  158. 158. Dispersión del equipo
  159. 159. Duración del proyecto </li></ul></ul><ul><li>Scrum se ha utilizado en múltiples proyectos de más de 500 personas </li></ul>
  160. 160. <ul>Expansión a través de Scrum de scrums </ul>
  161. 161. <ul>Scrum de scrums de scrums </ul>
  162. 162. <ul>Donde seguir? </ul><ul><li>www.mountaingoatsoftware.com/scrum
  163. 163. www.scrumalliance.org
  164. 164. www.controlchaos.com
  165. 165. [email_address] </li></ul>
  166. 166. <ul>Una lista de lecturas sobre Scrum </ul><ul><li>Agile and Iterative Development: A Manager’s Guide by Craig Larman
  167. 167. Agile Estimating and Planning by Mike Cohn
  168. 168. Agile Project Management with Scrum by Ken Schwaber
  169. 169. Agile Retrospectives by Esther Derby and Diana Larsen
  170. 170. Agile Software Development Ecosystems by Jim Highsmith
  171. 171. Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
  172. 172. Scrum and The Enterprise by Ken Schwaber
  173. 173. User Stories Applied for Agile Software Development by Mike Cohn
  174. 174. Artículos semanales en www.scrumalliance.org </li></ul>
  175. 175. <ul>Aviso de Copyright </ul><ul><li>Usted es libre de: </li></ul><ul><ul><li>Compartir- copiar, distribuir y trasmitir el trabajo
  176. 176. Modificar- adaptar el trabajo </li></ul></ul><ul><li>Bajo las siguientes condiciones </li></ul><ul><ul><li>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). </li></ul></ul><ul><li>Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.
  177. 177. Para más información ver http://creativecommons.org/licenses/by/3.0/ </li></ul>
  178. 178. <ul>Información de Contacto </ul><ul>Presentado por: Mike Cohn [email_address] www.mountaingoatsoftware.com (720) 890-6110 (office) </ul><ul>Puede eliminar este (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. </ul>

×