1.

• Una Introduccin a Scrum

• Adaptacin:Alberto Torreblanca V . - CSM Traduccin:Ernesto Grafeuille( Noviembre 2008)

2.

Estamos perdiendo la carrera de relevos

Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game,Harvard Business Review , January 1986.

En enfoque de carrera de relevos en el desarrollo de productos ... puede entrar en conflicto con los objetivos de mxima velocidad y flexibilidad. En su lugar, un enfoque holstico o estilo rugby - donde un equipo intenta ir a la distancia como una unidad, pasando la pelota hacia adelante y hacia atrs -pueden servir mejor a los actuales requisitos competitivos".

3.

Scrum es un proceso gil que nos permite centrarnos en ofrecer el ms alto valor de negocio en el menor tiempo.

4. Nos permite rpidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). 5. El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de ms alta prioridad. 6. Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint.

Scrum en 100 palabras

7.

Orgenes de Scrum

Jeff Sutherland

• Scrums iniciales en Easel Corp en 1993

8. IDX 500 personas haciendo Scrum

Ken Schwaber

• ADM

9. Se presenta Scrum en OOPSLA 96 con Sutherland

10. Autor de tres libros sobre Scrum

Mike Beedle

• Patrones Scrum en PLOPD4

Ken Schwaber and Mike Cohn

• Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance

11.

Scrum ha sido utilizado por:

Microsoft

12. Yahoo 13. Google 14. Electronic Arts 15. High Moon Studios 16. Lockheed Martin 17. Philips 18. Siemens 19. Nokia 20. Capital One 21. BBC 22. Intuit

Intuit

23. Nielsen Media 24. First American Real Estate 25. BMC Software 26. Ipswitch 27. John Deere 28. Lexis Nexis 29. Sabre 30. Salesforce.com 31. Time Warner 32. Turner Broadcasting 33. Oce 34.

Scrum ha sido utilizado para:

Software comercial

35. Desarrollos internos 36. Desarrollos bajo Contrato 37. Proyectos Fixed-price 38. Aplicaciones Financieras 39. Aplicaciones certificadas ISO 9001 40. Sistemas Embebidos 41. Sistemas con requisitos 7x24 y 99.999% de disponibilidad 42. Joint Strike Fighter

Desarrollo de video juegos

43. Sistemas crticos de soporte vital, aprobados por laFDA 44. Software de control satelital 45. Sitios Web 46. Software para Handheld 47. Telfonos porttiles 48. Aplicaciones de Network switching 49. Aplicaciones de ISV 50. Algunas de las ms grandes aplicaciones en uso 51.

Caractersticas

Equipos auto-organizados

52. El producto avanza en una serie de Sprints" de dos semanas a un mes de duracin 53. Los requisitos son capturados como elementos de una lista de Product Backlog" 54. No hay prcticas de ingeniera prescritas 55. Utiliza normas generativaspara crear un entorno gil para la entrega de proyectos 56. Uno de los procesos giles 57.

El Manifesto gil una declaracin de valores

Fuente: www.agilemanifesto.org

Procesos y herramientas

Individuos e interacciones

sobre

Seguimientode un plan

Responderante el cambio

sobre

Documentacin exhaustiva

Software que funciona

sobre

Negociacin de contratos

Colaboracincon el cliente

sobre

58.

Nivel de ruido de un proyecto

Simple

Complejo

Anarqua

Complicado

Tecnologa

Requisitos

Lejos deAcuerdo

Cerca de Acuerdo

Cerca de Certeza

Lejos de Certeza

Fuente:Strategic Management and Organizational Dynamicsby Ralph Stacey inAgile Software Development with Scrumby Ken Schwaber and Mike Beedle.

59.

Scrum

Product Backlog

Cancel

Gift wrap

Return

Sprint 2-4 semanas

Objetivo del Sprint

Sprint Backlog

Incremento del productopotencialmente entregable

24 horas

60.

Poniendo todo junto

Imagen disponible en www.mountaingoatsoftware.com/scrum

61.

Sprints

En Scrum los proyectos avanzan en una serie de Sprints

• Anlogo a las iteraciones en XP

La duracin tpica es 24 semanas o alo sumo un mes calendario

62. La duracin constante conduce a un mejor ritmo 63. El product es diseado, codificado y testeado durante el Sprint 64.

Desarrollo secuencial vs. superpuesto

Source: The New New Product Development Game by Takeuchi and Nonaka.Harvard Business Review,January 1986.

En lugar de hacer todo de una cosa a la vez ...

... los equipos Scrum hacen un poco de todo todo el tiempo

Requisitos

Diseo

Cdigo

Test

65.

No hay cambios en un sprint

Planee la duracin del sprint en torno a cunto tiempo usted puede comprometerse a mantener los cambios fuera del sprint

Cambios

66.

Scrum Framework

Product owner

67. ScrumMaster 68. Team

Roles

Sprint planning

69. Sprint review 70. Sprint retrospective 71. Daily scrum meeting

Reuniones

Product backlog

72. Sprint backlog 73. Burndown charts

Artefactos

74.

Scrum framework

Product backlog

75. Sprint backlog 76. Burndown charts

Artefactos

Sprint planning

77. Sprint review 78. Sprint retrospective 79. Daily scrum meeting

Reuniones

Product owner

80. ScrumMaster 81. Team

Roles

82.

Product Owner

Define las funcionalidades del producto

83. Decide sobre las fechas y contenidos de los releases 84. Es responsable por la rentabilidad del producto (ROI) 85. Prioriza funcionalidades de acuerdo al valor del mercado/negocio 86. Ajusta funcionalidades y prioridades en cada iteracin si es necesario 87. Acepta o rechaza los resultados del trabajo del equipo 88.

El ScrumMaster

Representa a la gestin del proyecto

89. Responsable de promover los valores y prcticas de Scrum 90. Remueve impedimentos 91. Se asegura de que el equipo es completamente funcional y productivo 92. Permite la estrecha cooperacin en todos los roles y funciones 93. Escudo del equipo de interferencias externas 94.

El Team

Tpicamente de 5 a 9 personas

95. Multi-funcional:

• Programadores, testers, analistas, diseadores, etc.

Los miembros deben ser full-time

• Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)

Los equipos son auto-organizativos

• Idealmente, no existen ttulos pero a veces se utilizan de acuerdo a la organizacin

Solo puede haber cambio de miembros entre los sprints

96.

Scrum Framework

Product owner

97. ScrumMaster 98. Team

Roles

Product backlog

99. Sprint backlog 100. Burndown charts

Artefactos

Sprint planning

101. Sprint review 102. Sprint retrospective 103. Daily scrum meeting

Reuniones

104.

Sprint Planning meeting

Planificacin

Decidir como alcanzar el objetivo del Sprint (diseo)

105. Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features) 106. Estimar Sprint Backlog en horas

Condiciones delNegocio

Capacidad del Equipo

Product Backlog

Tecnologa

Producto Actual

Priorizacin

Analizar y evaluar el Product Backlog

107. Seleccionar el objetivo del Sprint

Objetivo del Sprint

Sprint Backlog

108.

Planificacin del Sprint

El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar

109. Se crea el Sprint Backlog

• Se identifican tareas y cada una es estimada (1-16 horas)

110. Realizado colaborativamente, no solo por el ScrumMaster

El diseo de Alto Nivel es considerado

COMO planificador de vacaciones, YO QUIERO ver fotos de los hoteles.

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)

111.

Daily Scrum

Parmetros

• Diaria

112. Dura 15 minutos

113. Parados

No para la solucin de problemas

• Todo el mundo est invitado

114. Slo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar

115. Ayuda a evitar otras reuniones innecesarias 116.

Todos responden 3 preguntas

Noes dar un status report al Scrum Master

117. Se trata de compromisos delante de pares

Qu hiciste ayer?

1

Qu vas a hacer hoy?

2

Hay obstculos en tu camino?

3

118.

Sprint review

El equipo presenta lo realizado durante el sprint

119. Normalmente adopta la forma de una demo de las nuevas caractersticas o la arquitectura subyacente 120. Informal

• Regla de 2 hs preparacin

121. No usar diapositivas

Todo el equipo participa

122. Se invita a todo el mundo 123.

Sprint retrospective

Peridicamente, se echa un vistazo a lo que funciona y lo que no

124. Normalmente 15 a 30 minutos 125. Se realiza luego de cada sprint 126. Todo el equipo participa

• ScrumMaster

127. Product owner

128. Equipo 129. Posiblemente clientes y otros 130.

Start / Stop / Continue

Todo el equipo se rene y discute lo que les gustara:

Comenzar a hacer

Dejar de hacer

Continuar haciendo

Esto es slo una de las muchas maneras de hacer una retrospectiva.

131.

Scrum framework

Product owner

132. ScrumMaster 133. Team

Roles

Sprint planning

134. Sprint review 135. Sprint retrospective 136. Daily scrum meeting

Reuniones

Product backlog

137. Sprint backlog 138. Burndown charts

Artefactos

139.

Product Backlog

Los requisitos

140. Una lista de todos los trabajos deseados en el proyecto 141. Idealmente cada tema tiene valor para el usuarios o el cliente 142. Priorizada por el Product Owner 143. Repriorizada al comienzo de cada Sprint

Este es el product backlog

144.

Ejemplo de Product Backlog

Backlog item

Estimacin

Permitir que un invitado a hacer una reserva.

3

Como invitado, quiero cancelar una reserva.

5

Como invitado, quiero cambiar las fechas de una reserva.

3

Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitacin disponible

8

Mejorar el manejo de excepciones

8

...

30

...

50

145.

El objetivo del Sprint

Una breve declaracin de cual ser el foco del trabajo durante el sprint

Aplicacin con B.Datos

Servicios Financieros

Ciencias Biolgicas

Funciones de apoyo tcnico necesarios para estudios de gentica de poblaciones.

Soportar ms indicadores tcnicos que la empresa ABC en tiempo real y streaming de datos.

Hacer que la aplicacin se ejecute en SQL Server, adems de Oracle.

146.

Gestin del Sprint Backlog

Los individuos eligen las tareas

147. El trabajo nunca es asignado 148. La estimacin del trabajo restante es actualizada diariamente 149. Cualquier miembro del equipo puede aadir, borrar o cambiar el Sprint Backlog 150. El trabajo para el Sprint emerge 151. Si el trabajo no est claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego. 152. Actualizar el trabajo restante a medida de que ms se conoce 153.

Ejemplo de Sprint Backlog

Tareas

Codificar UI

Codificar negocio

Testear negocio

Escribir ayuda online

Escribir la clase foo

L

M

M

J

V

8

16

8

12

8

4

12

16

8

4

11

8

4

8

8

Agregar error logging

8

10

16

8

8

154.

Un Sprint Burndown Chart

Hours

155.

Hours

40

30

20

10

0

Mon

Tue

Wed

Thu

Fri

Tareas

Codificar UI

Codificar Negocio

Testear Negocio

Escribir ayuda online

L

8

16

8

12

M

M

J

V

50

4

12

16

7

11

8

10

16

8

156.

Escalabilidad

Normalmente los equipos son de 7 2 personas

• La escalabilidad proviene de equipos de equipos

Factores a tener cuenta

• Tipo de aplicacin

157. Tamao del equipo

158. Dispersin del equipo 159. Duracin del proyecto

Scrum se ha utilizado en mltiples proyectos de ms de 500 personas

160.

Expansin a travs de Scrum de scrums

161.

Scrum de scrums de scrums

162.

Donde seguir?

www.mountaingoatsoftware.com/scrum

163. www.scrumalliance.org 164. www.controlchaos.com 165. [email_address] 166.

Una lista de lecturas sobre Scrum

Agile and Iterative Development: A Managers Guideby Craig Larman

167. Agile Estimating and Planningby Mike Cohn 168. Agile Project Management with Scrumby Ken Schwaber 169. Agile Retrospectivesby Esther Derby and Diana Larsen 170. Agile Software Development Ecosystemsby Jim Highsmith 171. Agile Software Development with Scrumby Ken Schwaber andMike Beedle 172. Scrum and The Enterpriseby Ken Schwaber 173. User Stories Applied for Agile Software Developmentby Mike Cohn 174. Artculos semanales en www.scrumalliance.org 175.

Aviso de Copyright

Usted es libre de:

• Compartir- copiar, distribuir y trasmitir el trabajo

176. Modificar- adaptar el trabajo

Bajo las siguientes condiciones

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

177. Para ms informacin ver http://creativecommons.org/licenses/by/3.0/ 178.

Informacin de Contacto

Presentado por: Mike Cohn [email_address] www.mountaingoatsoftware.com (720) 890-6110 (office)

Puede eliminar este (o cualquier diapositiva), pero debe dar crdito de la fuente en algn lugar de su presentacin. Utilizar el logotipo y el nombre de la empresa (como en la parte inferior izquierda, por ejemplo) o incluir una diapositiva en algn lugar diciendo que parte (o todo) de su presentacin son de esta fuente. Gracias.