15/09/2009Ambientes de Desarrollo
DESARROLLO ÁGIL DE APLICACIONES
Universidad del Cauca
Departamento de Telemática
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.
El Manifiesto Ágil
Procesos y herramientasIndividuos e interacciones sobre
Seguimiento de un planResponder ante el cambio sobre
Documentación exhaustivaSoftware que funciona sobre
Negociación de contratosColaboración con el cliente sobre
Firmado en 2001 por Kent Beck, Alistair Cockburn, Ward Cunningham,
Martin Fowler, Robert Martin, Ron Jeffries, otros…
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”.
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.”
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
un valor que satisfaga a todos.Costo
Tiempo
Calidad
Alcance
Los cuatro valores
• Los 4 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
del desarrollo ágil.Comunicación
Coraje
Simplicidad
Realimentación
Programador
Responsable de decisiones
técnicas
Responsable de construir el
sistema
Sin distinción entre analistas,
diseñadores o codificadores
En XP, los programadores
diseñan, programan y realizan
las pruebas
Manager
Organiza y guía las reuniones
Asegura condiciones adecuadas para el proyecto
Cliente
Es parte del equipo
Determina qué construir y cuándo
Establece las pruebas funcionales
Roles en XP
Encargado de pruebas
Ayuda al cliente con las
pruebas funcionales
Se asegura de que las pruebas
funcionales se superan
Controlador Tracker
Métricas
Observa sin molestar
Conserva datos históricos
Preparador Coach
Responsable del proceso
Tiende a estar en un
segundo plano a medida
que el equipo madura
Roles en XP
Proceso de Desarrollo
Proceso de Desarrollo
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
Ejemplo de historia
de usuario
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
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
Desarrollo
Cliente disponible
Implementación
Pruebas de Unidad
Integración
Implantación
Pruebas de Aceptación
Las prácticas
Planificación
Entregas
pequeñas
Diseño simple
Hacer pruebas
Refactorización
Programación
por pares
Propiedad colectiva
del código
Integración continua
40 horas semanales
Cliente en el sitio
Estándares de
codificación
Metáforas
• 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.
SCRUM
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.
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.
Desarrollo secuencial vs. superpuesto
En lugar de hacer todo de una cosa a la vez ...
...los equipos Scrum hacen un poco de todo todo el tiempo
Requisitos Diseño Código Test
Scrum Framework
•Propietario del producto •SCRUM Master•Equipo SCRUM
Roles
•Planeación Sprint •Reuniones diarias•Revisión Sprint•Retrospectiva Sprint
Reuniones
•Backlog del Producto•Backlog del Sprint•Grafica de progreso
Artefactos
SCRUM Framework
•Planeación Sprint •Reuniones diarias•Revisión Sprint•Retrospectiva Sprint
Reuniones
•Backlog del Producto•Backlog del Sprint•Grafica de progreso
Artefactos
•Propietario del producto •Scrum Master•Equipo Scrum
Roles
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
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
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
•Propietario del producto •Scrum Master•Equipo Scrum
Roles
SCRUM Framework
•Backlog del Producto•Backlog del Sprint•Grafica de progreso
Artefactos
•Planeación Sprint •Reuniones diarias•Revisión Sprint•Retrospectiva Sprint
Reuniones
Reunion de planeación Sprint
Priorización
• Analizar y evaluar el Product Backlog
• Seleccionar el objetivo del Sprint
Planificación
• Decidir como alcanzar el objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog
• Estimar Sprint Backlog en horas (1-16 horas)
Objetivodel Sprint
SprintBacklog
Condicionesdel Negocio
Capacidaddel Equipo
Product Backlog
Tecnología
ProductoActual
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
Todos responden 3 preguntas
• No es dar un reporte de estado al SCRUMMaster
• Se trata de compromisos delante de pares
¿Qué hiciste ayer?1
¿Qué vas a hacer hoy?2
¿Hay obstáculos en tu camino?3
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
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.
•Propietario del producto •Scrum Master•Equipo Scrum
Roles
SCRUM framework
•Planeación Sprint •Reuniones diarias•Revisión Sprint•Retrospectiva Sprint
Reuniones
•Backlog del Producto•Backlog del Sprint•Grafica de progreso
Artefactos
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.
Ejemplo Backlog del Producto
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
Ejemplo de Sprint Backlog
TareasCodificar UI
Codificar negocio
Testear negocio
Escribir ayuda online
Escribir la clase foo
L8
16
8
12
8
M4
12
16
8
M J
4
11
8
4
V
8
8
Agregar error logging
8
10
16
8
8
Gráfica de progreso
Hou
rs
40
30
20
10
0L Ma Mi J V
Tareas
Codificar UI
Codificar Negocio
Testear Negocio
Escribir ayuda online
L
8
16
8
12
Ma Mi J V
4
12
16
7
11
8
10
16 8
50
Resumen SCRUM
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.
Grupos grandesGrupos pequeños (< 10 integrantes) y
trabajando en el mismo sitio
La arquitectura es esencialMenos énfasis en la arquitectura
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Cliente es parte del equipo de desarrollo
(además in-situ)
Existe un contrato prefijadoNo existe un contrato tradicional o al
menos es bastante flexible
Más RolesPocos Roles
Más ArtefactosPocos Artefactos
METODOLOGÍA NO ÁGILMETODOLOGÍA ÁGIL
ágil contra no ágil
Referencias
• www.mountaingoatsoftware.com/scrum
• www.scrumalliance.org
• www.controlchaos.com
¿Preguntas?
Top Related