Diapositivas de lsesión 05: paradigma de construcción de soluciones basado en desarrollo de código. XP y SCRUM.

1. 15/09/2009 Universidad del Cauca Departamento de Telemática DESARROLLO ÁGIL DE APLICACIONES Ambientes de Desarrollo

2. 15/09/2009 ¿qué es el desarrollo ágil de aplicaciones? Es una iniciativa que agrupa una serie de metodologías (eXtreme Programming, SCRUM, Crystal, etc. ...) Basadas en la adaptabilidad ante el cambio como medio para aumentar las posibilidades de éxito de un proyecto. En general los procesos ágiles se centran en las personas; en su comunicación directa y sus habilidades en vez de procesos muy formales.

3. Procesosy herramientas Individuose interacciones Seguimientode un plan Responder ante el cambio Documentaciónexhaustiva Software quefunciona Negociaciónde contratos Colaboracióncon el cliente sobre sobre sobre sobre El Manifiesto Ágil Firmado en 2001 por Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Robert Martin, Ron Jeffries, otros…

4. 15/09/2009 XP: eXtreme Programming “La Programación Extrema (desarrolla por Kent Beck - DaimerChrysler) es una metodología de desarrollo de aplicaciones que se basa en la simplicidad, la comunicación y la realimentación o reutilización del código desarrollado”.

5. 15/09/2009 Lo que dice Beck... “Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.”

8. Tiempo

9. Calidad

12. Coraje

13. Simplicidad

15. Responsable de construir el sistema

16. Sin distinción entre analistas, diseñadores o codificadores

19. Determina qué construir y cuándo

23. Observa sin molestar

25. Proceso de Desarrollo

27. Trozos de funcionalidad que aportan valor

28. Se les asignan tareas de programación con un número de horas de desarrollo

29. Las establece el cliente

32. Se priorizan aquellas historias de usuario que el cliente selecciona porque son más importantes para el negocio

33. Entregas:

34. Lo más pequeñas posibles

35. Se dividen en iteraciones de 2 o 3 semanas

36. Están compuestas por historias de usuario

38. La programación de tareas se realiza por parejas

39. La pareja diseña, prueba, implementa e integra el código de la tarea

40. Código dirigido por las pruebas

42. Implementación

43. Pruebas de Unidad

44. Integración

45. Implantación

47. Integración continua

48. 40 horas semanales

49. Cliente en el sitio

50. Estándares de codificación

51. Metáforas

52. Planificación

53. Entregas pequeñas

54. Diseño simple

55. Hacer pruebas

56. Refactorización

58. Ken Schwaber y Jeff Sutherland fueron los precursores de este método demostrando ampliamente su uso en proyectos de gran envergadura con un alto número de personal

60. Los requisitos son capturados como elementos de una lista de “ProductBacklog”

61. No hay prácticas de ingeniería prescritas

62. Indicado para proyectos con un rápido cambio de requerimientos.

63. Gran protagonismo de reuniones a lo largo del proyecto.

65. Desarrollo secuencial vs. superpuesto Requisitos Diseño Código Test En lugar de hacer todo de una cosa a la vez ... ...los equipos Scrum hacen un poco de todo todo el tiempo

67. SCRUM Master

68. Equipo SCRUM

69. Planeación Sprint

70. Reuniones diarias

71. Revisión Sprint

72. Retrospectiva Sprint

73. Backlog del Producto

74. Backlog del Sprint

75. Grafica de progreso Scrum Framework

77. Scrum Master

78. Equipo Scrum

79. Planeación Sprint

80. Reuniones diarias

81. Revisión Sprint

83. Backlog del Sprint

85. El SCRUMMaster Representa a la gestión del proyecto Responsable de promover los valores y prácticas de Scrum Remueve impedimentos Se asegura de que el equipo sea completamente funcional y productivo Permite la estrecha cooperación en todos los roles y funciones Garantiza el cumplimiento de roles y responsabilidad

86. El Equipo S SCRUM Los equipos son auto-organizativos Responsable de transformar Sprint Backlog en un incremento de la funcionalidad del software. Típicamente de 5 a 9 personas Multi-funcional y de tiempo completo: Programadores, testers, analistas, diseñadores, etc. El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad. Solo puede haber cambio de integrantes entre los sprints

88. Scrum Master

89. Equipo Scrum

90. Backlog del Producto

91. Backlog del Sprint

92. Grafica de progreso

93. Planeación Sprint

94. Reuniones diarias

95. Revisión Sprint

96. Retrospectiva SprintSCRUMFramework

98. Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog

100. Seleccionar el objetivo del SprintReunion de planeación Sprint Capacidad del Equipo Product Backlog Condiciones del Negocio Producto Actual Tecnología

101. Reunionesdiarias Parámetros Diaria Dura 15 minutos Parados No para la solución de problemas Todo el mundo está invitado Sólo los miembros del equipo, ScrumMaster y Propietario del Producto, pueden hablar Ayuda a evitar otras reuniones innecesarias

102. Todos responden 3 preguntas 1 2 3 ¿Quéhicisteayer? ¿Qué vas a hacer hoy? ¿Hay obstáculos en tucamino? No es dar un reporte de estado al SCRUMMaster Se trata de compromisos delante de pares

104. No usar diapositivasTodo el equipo participa Se invita a todo el mundo

105. Reunión de retrospectiva Sprint Periódicamente, se echa un vistazo a lo que funciona y lo que no, normalmente dura de 15 a 30 minutos Se realiza luego de cada sprint Todo el integrantes del proyecto participa Además de Posiblemente clientes y otros Todos discutes lo que les gustaría: Comenzar a hacer Dejar de hacer Continuar haciendo Esto es sólo una de las muchas maneras de hacer una retrospectiva.

107. Scrum Master

108. Equipo Scrum

109. Planeación Sprint

110. Reuniones diarias

111. Revisión Sprint

112. Retrospectiva Sprint

113. Backlog del Producto

114. Backlog del Sprint

115. Grafica de progreso SCRUMframework

117. Ejemplo Backlog del Producto

118. Sprint Backlog Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de la funcionalidad. Se recomienda que las tareas tengan una duración de 4 a 16 horas de trabajo. Las de mayor duración deben dividirse en sub-tareas de ese rango de tiempo. Los individuos eligen las tareas. La estimación del trabajo restante es actualizada diariamente Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog

119. 8 4 8 16 12 4 10 8 16 11 8 16 12 8 8 8 8 8 4 Agregar error logging 8 Ejemplo de Sprint Backlog Tareas L M M J V Codificar UI Codificar negocio Testear negocio Escribir ayuda online Escribir la clase foo

120. 4 8 12 7 10 16 11 16 8 Gráfica de progreso Tareas L Ma Mi J V Codificar UI 8 Codificar Negocio 16 Testear Negocio 8 Escribir ayuda online 12 50 40 30 Hours 20 10 0 L Ma Mi J V

121. Resumen SCRUM

122. SCRUMy XP SCRUM se enfoca a practicas de organización y gestión XP se centra en practicas de programación Tratan de áreas diferentes pero se complementan.

123. METODOLOGÍA NO ÁGIL METODOLOGÍA ÁGIL Más Artefactos Pocos Artefactos Más Roles Pocos Roles Existe un contrato prefijado No existe un contrato tradicional o al menos es bastante flexible El cliente interactúa con el equipo de desarrollo mediante reuniones Cliente es parte del equipo de desarrollo (además in-situ) Grupos grandes Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio La arquitectura es esencial Menos énfasis en la arquitectura ágil contra no ágil

124. Referencias www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com

125. ¿Preguntas?