s05 - paradigma de construcción de soluciones basado en desarrollo de código

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

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


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


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

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

• [email protected]

¿Preguntas?

s05 - paradigma de construcción de soluciones basado en desarrollo de código

Education

Transcript of s05 - paradigma de construcción de soluciones basado en desarrollo de código