desarrollo ágil de aplicaciones

Curso Ambientes de Desarrollo

Énfasis II en Ingeniería de Sistemas Telemáticos

programa de Ingeniería Electrónica y Telecomunicaciones

Paradigma de construcción de soluciones basa en la

construcción de código

Desarrollo Ágil de Aplicaciones

¿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…

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

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

del desarrollo ágil.

] Comunicación

] Coraje

] Simplicidad

] Realimentación

] Respeto

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

Director

• 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 principales en XP

Probador - Tester

• Ayuda al cliente con las

pruebas funcionales

• Se asegura de que las pruebas

funcionales se superan

Preparador - Coach

• Responsable del proceso

• Tiende a estar en un

segundo plano a medida

que el equipo madura

Controlador - Tracker

• Métricas

• Observa sin molestar

• Conserva datos históricos

Roles secundarios en XP

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 siempre disponible

Implementación

Pruebas de Unidad

Integración

Implantación

Pruebas de Aceptación

Retroalimentación a escala fina:

• El principio de pruebas

• Proceso de planificación

• Cliente en el sitio

• Programación por parejas

Principios básicos

Proceso continuo en lugar de por lotes:

• Integración continua

• Refactorización

• Entregas pequeñas

Principios básicos

Entendimiento compartido:

• Diseño simple

• Metáfora

• Propiedad colectiva del código

• Estándares de codificación

Principios básicos

Bienestar del programador:

• La semana de 40 horas

• Dedicación exclusiva

Principios básicos

Mejores prácticas

Proceso de Desarrollo

Lectura para la casa

• 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


Reuniones


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


Roles

SCRUM Framework


Artefactos


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 SCRUM Master

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


Roles

SCRUM framework


Reuniones


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

Tareas

Codificar UI

Codificar negocio

Testear negocio

Escribir ayuda online

Escribir la clase foo

L

8

16

8

12

8

M

4

12

16

8

M J

4

11

8

4

V

8

8

Agregar error logging

8

10

16

8

8

Gráfica de progreso

Ho

urs

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

• [email protected]

¿Preguntas?

¿Observaciones?

Elaborando un mapa

conceptual…

http://cmap.ihmc.us

desarrollo ágil de aplicaciones

Education