Paradigma de construcción d

1. Curso Ambientes de Desarrollo
Énfasis II en Ingeniería de Sistemas
Telemáticos
programa de Ingeniería Electrónica y Telecomunicaciones

2. Paradigma de construcción de
soluciones basa en la
construcción de código
Desarrollo Ágil de Aplicaciones

3. ¿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.

4. El Manifiesto Ágil
Individuos e interacciones sobre Procesos y herramientas
Software que funciona sobre Documentación exhaustiva
Colaboración con el cliente sobre Negociación de contratos
Responder ante el cambio sobre Seguimiento de un plan
Firmado en 2001 por Kent Beck, Alistair Cockburn, Ward Cunningham,
Martin Fowler, Robert Martin, Ron Jeffries, otros…

5. 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”.

6. 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.”

7. Las cuatro variables
• XP hace de sus cuatro variables, elementos
visibles tanto a clientes, programadores y
jefes de proyectos.
• Se busca jugar con sus valores hasta que el
alcance del proyecto tenga
] Costo
un valor que satisfaga a todos.
] Tiempo
] Calidad
] Alcance

8. Los cinco valores
• Los cinco valores de XP son esenciales para
que sus practicas tengan sentido y puedan ser
llevadas a cabo con éxito.
• Deben ser parte integral de la
filosofía de un profesional ] Comunicación
del desarrollo ágil. ] Coraje
] Simplicidad
] Realimentación
] Respeto

9. Roles principales en XP
Programador Director
• Responsable de decisiones • Organiza y guía las
técnicas reuniones
• Responsable de construir el • Asegura condiciones
adecuadas para el proyecto
sistema
• Sin distinción entre analistas,
Cliente
diseñadores o codificadores • Es parte del equipo
• Determina qué construir y
• En XP, los programadores
cuándo
diseñan, programan y realizan
• Establece las pruebas
las pruebas
funcionales

10. Roles secundarios en XP
Preparador - Coach
• Responsable del proceso
Probador - Tester • Tiende a estar en un
• Ayuda al cliente con las segundo plano a medida
pruebas funcionales que el equipo madura
• Se asegura de que las pruebas
funcionales se superan Controlador - Tracker
• Métricas
• Observa sin molestar
• Conserva datos históricos

11. Proceso de Desarrollo

12. Proceso de Desarrollo

13. Captura de Requisitos
Historias de Usuarios:
• Establecen los requisitos del cliente
• Trozos de funcionalidad que aportan valor
• Se les asignan tareas de programación con un
número de horas de desarrollo
• Las establece el cliente
• Son la base para las pruebas funcionales

14. Ejemplo de historia
de usuario

15. Planificación
 Planificación por entregas (releases)
 Se priorizan aquellas historias de usuario que el cliente
selecciona porque son más importantes para el negocio
 Entregas:
• Lo más pequeñas posibles
• Se dividen en iteraciones de 2 o 3 semanas
• Están compuestas por historias de usuario
 A cada programador se le asigna una tarea de la historia
de usuario

16. Diseño
 Diseño simple
 La programación de tareas se realiza por parejas
 La pareja diseña, prueba, implementa e integra el
código de la tarea
 Código dirigido por las pruebas
 Código modular, intentando refactorizar siempre
que se pueda

17. Desarrollo
 Cliente siempre disponible
 Implementación
 Pruebas de Unidad
 Integración
 Implantación
 Pruebas de Aceptación

18. Principios básicos
Retroalimentación a escala fina:
• El principio de pruebas
• Proceso de planificación
• Cliente en el sitio
• Programación por parejas

19. Principios básicos
Proceso continuo en lugar de por lotes:
• Integración continua
• Refactorización
• Entregas pequeñas

20. Principios básicos
Entendimiento compartido:
• Diseño simple
• Metáfora
• Propiedad colectiva del código
• Estándares de codificación

21. Principios básicos
Bienestar del programador:
• La semana de 40 horas
• Dedicación exclusiva

22. Mejores prácticas

23. Proceso de Desarrollo

24. Proceso de Desarrollo

25. Proceso de Desarrollo

26. Proceso de Desarrollo

27. Lectura para la casa

28. SCRUM
• Es una metodología ágil de desarrollo de software.
que permite centrarse en ofrecer el más alto valor de
negocio en el menor tiempo.
• 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
• El negocio fija las prioridades y los equipos se auto-
organizan a fin de determinar la mejor manera
de entregar las funcionalidades de más alta prioridad.

29. Características
• Desarrollo de software por medio de iteraciones
“Sprints" de 2 semanas a un 1 de duración
• Los requisitos son capturados como elementos
de una lista de “Product Backlog”
• No hay prácticas de ingeniería prescritas
• Indicado para proyectos con un rápido cambio
de requerimientos.
• Gran protagonismo de reuniones a lo largo del
proyecto.
• Colaboración estrecha con el cliente.

30. Sprints
• “Sprints”- Periodo de tiempo (2-4 semanas) donde se
llevan a cabo una serie de tareas previamente
establecidas. ( Análogo a las iteraciones en XP)
• No hay cambios en un sprint
• El producto es diseñado, codificado y testeado durante
el Sprint
• Al iniciar cada Sprints, el equipo revisa el trabajo
pendiente y selecciona la parte que terminará como un
incremento de funcionalidad incorporado al software.
• Al final del Sprint el equipo presenta el incremento de
funcionalidad a las partes implicadas en el proyecto.

31. 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

32. Scrum Framework
Roles
•Propietario del producto
•SCRUM Master Reuniones
•Equipo SCRUM
•Planeación Sprint
•Reuniones diarias
•Revisión Sprint
•Retrospectiva Sprint
Artefactos
•Backlog del Producto
•Backlog del Sprint
•Grafica de progreso

33. SCRUM Framework
Roles
•Propietario del producto
•Scrum Master
•Equipo Scrum Reuniones
•Planeación Sprint
•Reuniones diarias
•Revisión Sprint
•Retrospectiva Sprint
Artefactos
•Backlog del Producto
•Backlog del Sprint
•Grafica de progreso

34. Propietario del Producto
• Representa a todos los interesados en el producto final
Sus áreas de responsabilidad son:
– Financiación del proyecto
– Requisitos del sistema
– Retorno de la inversión del proyecto
– Lanzamiento del proyecto
– Decide sobre las fechas y contenidos de los Releases
– Prioriza funcionalidades de acuerdo al valor del mercado/negocio
– Ajusta funcionalidades y prioridades en cada Sprint
– Acepta o rechaza los resultados del trabajo del equipo

35. El SCRUM Master
• 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

36. 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

37. SCRUM Framework
Roles
•Propietario del producto
•Scrum Master
•Equipo Scrum Reuniones
•Planeación Sprint
•Reuniones diarias
•Revisión Sprint
•Retrospectiva Sprint
Artefactos
•Backlog del Producto
•Backlog del Sprint
•Grafica de progreso

38. Capacidad Reunion de planeación Sprint
del Equipo
Priorización
Product • Analizar y evaluar el Product Backlog Objetivo
Backlog • Seleccionar el objetivo del Sprint del Sprint
Condiciones
del Negocio Planificación
• Decidir como alcanzar el objetivo del
Sprint (diseño)
Producto
• Crear el Sprint Backlog (tareas) en Sprint
Actual
base a los temas del Product Backlog Backlog
• Estimar Sprint Backlog en horas (1-16
horas)
Tecnología

39. Reuniones diarias
• 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, Scrum Master y
Propietario del Producto, pueden hablar
– Ayuda a evitar otras reuniones innecesarias

40. Todos responden 3 preguntas
1
¿Qué hiciste ayer?
2
¿Qué vas a hacer hoy?
3
¿Hay obstáculos en tu camino?
• No es dar un reporte de estado al SCRUM Master
• Se trata de compromisos delante de pares

41. Reunión de Revisión Sprint
• El equipo presenta lo realizado durante el sprint
• Normalmente adopta la forma de un demo de las
nuevas características o la arquitectura subyacente
• Informal
• Regla de 2 hs preparación
• No usar diapositivas
• Todo el equipo participa
• Se invita a todo el mundo

42. 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.

43. SCRUM framework
Roles
•Propietario del producto
•Scrum Master
•Equipo Scrum Reuniones
•Planeación Sprint
•Reuniones diarias
•Revisión Sprint
•Retrospectiva Sprint
Artefactos
•Backlog del Producto
•Backlog del Sprint
•Grafica de progreso

44. Backlog del Producto
Listado con los requisitos del sistema
• Es responsabilidad del dueño del producto
• Contenido
• Priorizacion inicial y al comienzo de cada Sprint
• Disponibilidad
• Es un documento dinámico que incorpora constantemente
las necesidades del sistema
• Idealmente cada tema tiene valor para el usuarios o el
cliente
• Se mantiene durante todo el proceso.

45. Ejemplo Backlog del Producto

46. 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

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

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

49. Resumen SCRUM

50. SCRUM y 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.

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

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

53. ¿Preguntas?
¿Observaciones?

54. Elaborando un mapa
conceptual…

55. http://cmap.ihmc.us