Desarrollo Ágil de Software. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Desarrollo Ágil de Software

Curso IIC 2143 – Ingeniería de Software

Rodrigo Sandoval 2010

Contenidos

• Definiciones de Desarrollo Ágil

• Dos ejemplos de Enfoques Ágiles:

– eXtreme Programming

Extracto “In Search of Methodology”

Alistair Cockburn, 1994

La historia que escuchamos fue casi la misma (con una excepción), independiente del tamaño, experiencia, país, década, o Estructurado vs. Objeto. Lo que encontramos fue lo siguiente:

• A los equipos de desarrollo les desagrada gastar tiempo en actividades de diseño que no lleven directamente al producto final.

• No les gusta tener que actualizar en forma manual documentos de diseño para mantenerlos al día con el producto (típicamente,

simplemente no volvían a actualizarlos).

• Se les dan recursos y tiempo limitados para aprender nuevas técnicas, y no mucho tiempo extra para integrar dichas técnicas a sus hábitos

diarios de trabajo.

• Los desarrolladores generalmente pueden evadir aquellos aspectos de la metodología que no les agradan.

¿Por qué?

• Metodología actual, documentada en papel, no

facilita el desarrollo.

• Existen áreas sensibles que pueden ser mejoradas:

 Evaluación Preliminar v/s Concepción  Construcción y Elaboración v/s

Flujo Normal de Desarrollo

• Fomentar uso de herramientas adecuadas.

• Fomentar empowerment del equipo.

• Manifesto for Agile Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value.

– Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation

– Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more

Definición de Desarrollo Ágil

The Agile Manifesto Principles I

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's

competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter

timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The Agile Manifesto Principles II

• The most efficient and effective method of conveying

information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress. • Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Adaptando UP al Desarrollo Ágil

• Comunicación

► La comunicación tiene lugar entre las personas miembros del equipo, los documentos son secundarios.

• Simplicidad

► La descripción de un proceso siempre debe verse demasiado pequeña. ► Revisiones periódicas para remover complejidades acumuladas.

► Cualquier cosa que no pueda ser completamente justificada se elimina. • Feedback e Iteraciones Breves

► Pasos pequeños, verificando exactitud de lo realizado (~ Daily Build  visibilidad) • Humanizar

► Un proceso sólo puede tener efectos de segundo orden, los efectos de primer orden se deben a las personas.

► Al construir un proceso debemos depender de la gente en todas las instancias donde el riesgo sea aceptable.

• Esfuerzo y Calendario

► La administración de proyectos no puede especificar ambos a la vez. Deben consultarse los actores relevantes.

¿De qué depende la calidad?

• Para lograr la calidad,

conviene enfocarse en

las personas

involucradas en el

proyecto.

• Los procesos y las

tecnologías ayudan a

las personas.

Principios de Desarrollo Liviano

• Iniciar pronto

• Aprender constantemente

• Postergar las decisiones

• Entregar rápidamente

• Eliminar pérdidas

• Empoderar al equipo

• Diseñar con integridad

• Evitar suboptimizaciones

www.agileshift.cl Fuente: Mary Poppendieck. Lean Development & the Predictability Paradox © 2003 Poppendieck LCC

Métodos de Desarrollo Ágil

• eXtreme Programming o XP

– Prácticas de negocio, desarrollo y codificación.

• Scrum

– Base en la gestión del proyecto y la interacción entre sus participantes.

• Feature Driven Development o FDD

– Descubrir e implementar las funcionalidades relevantes (features).

• Crystal Clear

– Fuerte en comunicaciones, liviano en entregables, iteraciones cortas.

EXTREME PROGRAMMING

Procesos de Desarrollo Ágil

EXTREME PROGRAMMING

1996, 1999 Beck, K.

“Extreme programming explained, embrace the change”.

Un conjunto de valores, principios y prácticas para desarrollar software, reduciendo el costo del cambio.

Valores: comunicación, simplicidad, feedback, y valor. Roles: Cliente (Customer) y Desarrollador (Developer)

Prácticas: Planificar el juego, programación en pares, release pequeños y frecuentes, propiedad colectiva del código,

metáforas del sistema, integración continua, diseño simple, ritmo de producción sostenido, testing, todos juntos,

6 BUENAS PRÁCTICAS

1. Si las revisiones de código son buenas, revisar TODO el código (programación por pares).

2. Si el testing es bueno, TODOS harán pruebas de unidad TODO el tiempo, incluso los clientes (prueba de aceptación).

3. Si la simplicidad es buena, siempre haremos lo MÁS SIMPLE posible que funcione.

4. Si la arquitectura es importante, TODOS definirán y refinarán la arquitectura TODO el tiempo.

5. Si las pruebas de integración son importantes, integraremos y probaremos varias veces al día.

6. Si las iteraciones cortas son buenas, haremos iteraciones MUY cortas.

5 VALORES

1. Comunicación

Diseño simple, uso de metáforas, colaboración usuario-programador, comunicación y feedback verbal.

2. Simplicidad

Código simple, “refactoring” hacia mejores soluciones.

El diseño del código se hace pensando en el hoy, no en el futuro.

3. Feedback

Del sistema, del cliente, del equipo.

4. Coraje

Siempre codificar para “ahora”. Saber cuando “desechar” código.

5. Respeto

Nunca hacer cambios que dañen la compilación, introduzcan errores en los Tests o retrasen el trabajo de los pares

12 prácticas …

• Feedback fino.

1. Desarrollo guiado por Testing (Test Driven Development).

2. Planificación.

3. Todos juntos (incluir al cliente). 4. Programación en pares.

• Proceso continuo.

• Entendimiento común.

código.

11.Estándares de codificación o convenciones.

• Salud del programador.

12.Ritmo sostenible (semana de 40 hrs.).

PROGRAMACIÓN POR PARES

2 programadores.

El que escribe es el conductor, el que guía es el

navegador (diseño, testing).

Mientras uno hace pruebas de unidad el otro

piensa en la clase que satisface esa prueba.

Cambio de roles cada media hora.

Pares dinámicos (un par en la mañana y

posiblemente otro en la tarde).

2001, Laurie Williams (Utah Univ.): paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs.

ARTEFACTOS

Requisitos: Story cards (tarjetas de papel que contienen

feature/funcionalidad a programar. Grano: 2-10 días).

Diseño: CRC cards (tarjetas de papel que contienen

responsabilidades de las clases e ideas de colaboradores), Sketches (borradores).

Gestión: Lista de tareas (papel o pizarra, Grano: 1-2 días),

Gráficos (en la pared), Story cards (Cómo el usuario (con nombre idealmente) usaría el software).

Manejo de configuraciones: Implementación:

-Escribiendo Historias

• La “historia” es la unidad de funcionalidad en

XP (feature)  Requisitos

• Se demuestra el progreso de un proyecto al

entregar código integrado y testeado que

implementa una historia.

• Se escriben en tarjetas para poder visualizarlas

a la vez y ordenarlas según prioridad del cliente.

Escribiendo Historias

• Una historia debe:

– ser entendible por clientes y

desarrolladores,

– testeable

– valiosa para el cliente

– y lo suficientemente pequeña para construir

6 de ellas en una iteración.

Historia de XP

(Descripción breve y concisa de la historia en dos o tres párrafos describiendo propósito, entrada, salida y efectos principales)

(Nº ID)

(Estimación Esfuerzo)

CLIENTE

Escribiendo Historias

• Principios de “buenas historias”

– Deben ser entendibles por el cliente.

– Deben entregar valor al cliente.

– Debe formarse de una o a lo más dos frases que

describan algo importante para el cliente. (ej: “El

sistema debe verificar la ortografía de todas las

palabras ingresadas en el comentario”)

– Mientras más corta, mejor.

Historia y Tareas Desarrollo - Ejemplo

Ingresar Datos del Documento

El usuario, antes de digitalizar el documento e ingresarlo a la plataforma documental deberá digitar los datos o índices del documento, que serán exigidos y validados por el formulario de ingreso.

Los índices a solicitar al usuario dependerán de una plantilla centralizada que la aplicación deberá consultar siempre antes de mostrarle el formulario al usuario.

H 09

5 días

Consideración 1: El acceso a la plantilla centralizada se puede implementar como una historia separada.

Consideración 2: A su vez, la validación puede ser una historia separada

De escribir a estimar

• Una historia, que debería ser lo más atómica posible,

depende de una o más tareas de desarrollo (por ej:

implementar tablas, implementar capa lógica, hacer

interfaz, etc.)

Implementar Tablas para los datos Implementar clase Documento

que tiene la lógica de manejo de los datos del documento

Implementar formulario interfaz para el ingreso de datos.

HISTORIA

“Levantamiento de Req. en XP”

(3) Estimar esfuerzo

(4) Ordenar según prioridad

ROLES

Cliente: Escribe historias y pruebas de aceptación. Elige

historias para su construcción/release en cada iteración.

Desarrollo: Programador (codifica, diseña, hace refactoring,

identifica nuevas tareas y estima el tiempo de desarrollo),

Tester (ayuda al cliente a escribir y desarrollar los tests).

Administrador: Coach (concientiza sobre el proceso,

customiza el proceso, interviene, enseña). Tracker

(colecciona métricas, informa del progreso, da feedback

sobre malas estimaciones).

PRÁCTICAS

Requisitos: Planificar el juego, cliente colocado, test de aceptación. Diseño: Metáforas del sistema, refactoring frecuente, diseño

simple.

Implementación: Refactoring frecuente, estándares de

codificación, programación en pares, propiedad colectiva del código.

Test y verificación: pruebas de aceptación, pruebas de cliente, test-driven development, cliente colocado.

Gestión: Planificación del juego, entregas cortas, ritmo sostenible, reuniones de pie.

Manejo de configuraciones: Integración continua, sala común, planificación del juego.

SCRUM

Procesos de Desarrollo

SCRUM

1986, H.Takeuchi & I.Nonaka, The New Product Development Game [Harvard Business Review].

1996, J. Sutherland & K. Schwaber, Scrum Development Process [OOPSLA 96]. 2001, Manifiesto Ágil.

Teams auto-dirigidos y auto-organizados.

Scrum Master: 50% desarrollo, 50% administración.

Proceso:

Reuniones para determinar lo que se hará en la siguiente fase (Sprint). No se puede cambiar las tareas del Sprint. Reuniones diarias de pie.

Sprints de 30 días calendario.

ROLES

Cliente (Product Owner)

Crea y prioriza el Product Backlog, elige metas del siguiente Sprint, revisa sistema.

Desarrollo (Scrum Team)

Team members trabajan en el Sprint (iteración).

Administrador (Scrum Master, 50% desarrollo)

Asegura seguir prácticas Scrum, refuerza visión del proyecto y metas; media entre el Administrador del proyecto y el equipo; escucha

progresos, remueve impedimentos. Dirige el Scrum diario, conduce el Sprint Review.

Otros: Chickens, los demás observan pero no intervienen o

ARTEFACTOS

Requisitos: Product Backlog (tareas: features, casos de uso,

mejoras, bugs, instalación, … Entradas en archivo Excel).

Gestión:

Product & Release Backlog (lista priorizada de requisitos con tiempos estimados). Sprint Backlog (tareas siguiente iteración. Grano: 4-16hrs)

Gráfico del Backlog (estimar trabajo remanente vs. días disponibles)

Diseño: -.

Manejo de configuraciones: Implementación:

-Product Backlog (1)

Descripción Prioridad

Llenar formulario de datos de cotización 5 Modificar datos de cotización 2 Consulta/Búsqueda de cotizaciones por cliente y por fecha 3

. . .

• El Cliente (PO) prepara y entrega esta lista de

requerimientos PRIORIZADOS (en orden).

• Si no tiene conocimiento o experiencia para este nivel de

detalle, el analista prepara el detalle, pero la prioridad la

pone el cliente.

Product Backlog (2)

Descripción Prioridad Esfuerzo

Llenar formulario de datos de cotización 5 2

Modificar datos de cotización 2 2

Consulta/Búsqueda de cotizaciones por cliente y por fecha

3 1

. . .

• El Cliente (PO) presenta la lista al Team de desarrollo y se describen los detalles adecuados para que el Team entienda claramente lo que hay que hacer y pueda estimar el esfuerzo. • A este nivel puede ser factible describir complejidad en lugar

de esfuerzo específico (funcionalidad de complejidad alta/media/baja).

• Luego se estima en forma genérica el esfuerzo para una funcionalidad alta (3 días), media (1 día), baja (1/2 día).

Product Backlog (3)

Descripción Prioridad Esfuerzo Iter 1 Iter 2

Llenar formulario de datos de cotización 15 2 2 2

Modificar datos de cotización 2 2 2 0

Consulta/Búsqueda de cotizaciones por cliente y por fecha

3 1 1 0

. . .

• Habiendo definido prioridades (PO) y esfuerzos (Team), se

establece un Plan de Iteración (Sprint Plan), que define un

plazo acotado (30 días) y cuánto del Product Backlog se

alcanza a implementar en ese plazo.

• El plan define: “cuánto me queda para terminar …”.

• Las funcionalidades que no entren se dejan para el

Sprint Backlog

Descripción Origen

Respon-sable

Estado Iter 1 Iter 2 Iter 3

Crear BD Pedro Pedro Terminada _{1 0 0}

Crear Tablas Modelo 1 Pedro Jorge Terminada _{2 0 0}

Instalar servidor Web y configurar seguridad José José En progreso _{1 0 0}

Implementar Stored Proc para Cotizaciones Pedro Jorge No iniciada _{4 4 0}

. . .

• Lista de tareas técnicas para cumplir con el Proudct

Backlog. Es el plan de trabajo detallado del Team,

habiendo definido el plan general de req. a

implementar.

MÉTRICAS

PRÁCTICAS

Requisitos: Planificar el pre-juego, planificar el Sprint,

revisión del Sprint.

Diseño: Fase de diseño de alto nivel. Implementación: -.

Test y verificación: Revisión del Sprint.

Manejo de configuraciones: Sala común, build diario. Gestión:

No añadir tareas a la iteración. Scrum Master es un Firewall.

Scrum diario. Bloqueos removidos en 1 día. Decisiones en 1 hora. Equipo auto-organizado, auto-dirigido.

Planificar el pre-juego, planificar el Sprint. Chickens & Pigs.

COMPARACIÓN CON OTROS

PROCESOS

Procesos de Desarrollo

Proceso Fortalezas Prioridades Situaciones

Serial

(Cascada)

Administra riesgo de costo. Solidez diseño y arquitectura.

1) Funcionalidades 2) Poco defecto 3) Tiempo x release

Software embebido en hardware o para controlar un dispositivo crítico. Requisitos estables, alta calidad.

Iterativo

(Espiral)

Administra riesgo técnico. 1) Funcionalidades

2) Poco defecto 3) Tiempo x release

Productos o ideas nuevas que requieren refinarse antes del desarrollo.

Incremental

(RUP)

Administra riesgo de calendario Absorbe cambios en reqs.

1) Tiempo x release 2) Poco defecto 3) Funcionalidades

La mayoría de los proyectos, como nuevas versiones de productos, necesidad de flexibilidad y compromisos de tiempo. Iterativo-Incremental (Ágil)

Administra riesgo técnico y de calendario

Requiere un equipo bien afiatado.

1) Tiempo x release 2) Funcionalidades 3) Poco defecto

Productos nuevos. Requisitos inestables. Necesidad de experimentación y tiempo limitado.

Ad-hoc

(Code & Fix)

1) Tiempo x release 2) Funcionalidades 3) Poco defecto