Agile Software development

ESCUELA DE INGENIERÍA INFORMÁTICAUniversidad de Oviedo

DIRECCION Y GESTIÓNDE PROYECTOS WEB

00. Metodologías Ágiles

Máster y Doctorado en Ingeniería Web

Curso 2010-2011

Ponente

Julio A. Argüello FernándezResponsable de Arquitectura y Desarrollo

Grupo B2B 2000

3

Índice

1. Introducción2. Manifiesto Ágil3. SCRUM

1. Introducción2. Sprints3. Roles4. Backlogs5. Reuniones6. Técnicas7. Caso Práctico

4. Contactos y Página Web5. Bibliografía

MANIFIESTO ÁGILEnfoque Metodológico

Postgrados en Ingeniería

Introducción

Burocracia↓↓ Valor↑↑ Iteraciones [1s – 4s] (planificación +

análisis + codificación + revisión + documentación)

Manifiesto Ágil

1. Valorar a los individuos y su interacción, …

2. Valorar el software que funciona,…

3. Valorar la colaboración con el cliente, …

4. Valorar la respuesta al cambio, …

…sobre los procesos y las herramientas.…sobre la documentación exhaustiva.sobre la negociación contractual.…sobre el seguimiento de un plan.

1. Personas vs. Procesos (I)

1.Personas vs. Procesos (II)

2. Funcionamiento vs. Documentación (I)

3.Colabora vs. Negocia (I)

3.Colabora vs. Negocia (II)

4.Cambio vs. Plan

Características

Proceso iterativo e incremental Mitigación del riesgo (mediante iteraciones

fijas) Mejora continua Calidad desde el primer día Priorización de requerimientos (según

valor) Equipos dedicados y auto-gestionados Colaboración continua con el cliente Incorporar el cambio Prácticas de desarrollo modernas

Ejemplos

XP (eXtreme Programming) TDD (Test Driven Development) Crystal Clear SCRUM AUP (Agile Unified Process) EssUP (Agile Unified Process) FDD (Feature Driven Development) BDD (Behavior Driven Development)

¿¿??

¿¿??

SCRUMMetodología Ágil Objetivo

Postgrados en Ingeniería

Introducción (I)

“Programming is so inherently difficult and complex”

--Edsger W. Dijkstra

Introducción (II)

Introducción (III)

Origen

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales.1 Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las fases se traslapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, como en el rugby, donde el equipo entero «actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro». Los casos de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas fotográficas, computadoras e impresoras.

En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions (A problemas malvados, soluciones virtuosas),2 se refirieron a esta aproximación como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por Takeuchi y Nonaka.

A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a poner en práctica el scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum.3 En 1995 Sutherland y Schwaber, durante el OOPSLA '95 desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología. Durante los años siguientes, Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo que ahora se le conoce como scrum. En 2001, Schwaber y Mike Beedle describieron la metodología en el libro Agile Software Development with Scrum.

Roles (I)

El Pollo mira al cerdo y le dice "Hey, por qué no abrímos juntos un restaurante?". El cerdo mira al pollo y dice: "Buena idea, ¿cómo podría llamarse?". El pollo entonces piensa al respecto y finalmente dice: "¿Por qué no lo llamamos 'Jamón y Huevos'?". "Mmmmm, no me parece justo. ", dice el cerdo, "Yo estaría totalmente comprometido, mientras que vos sólo estarías algo involucrado"

Roles (II)

Los cerdos Miembros del Equipo Scrum Máster Dueño de Producto

Los pollos Stakeholders (clientes, vendedores, etc.) Usuarios (quienes utilizarán el software) Gerentes (los administradores de la org.) Otras personas

Objetivo•Involucrar a usuarios, negocio y stakeholders

Objetivo•Involucrar a usuarios, negocio y stakeholders

Roles: Dueño del Producto

La voz del cliente Responsabilidades

Retorno de inversión (ROI) Fijar características, fechas y

contenidos Ofrecer visión única de los “pollos” Priorizar las características Aceptar o rechazar el resultado del

trabajo

Roles: Scrum Master

El padre, el facilitador de Scrum Responsabilidades

Asegurar las reglas Mejorar vida y productividad de los

miembros Asegurar la cooperación de todos los roles Proteger al equipo de interferencias

externas Invitar a personas a las reuniones Seguir la lista de impedimentos Asesorar al cliente cómo maximizar su ROI

Roles: Miembros del Equipo

Los creadores Grupo de Trabajo vs. Equipo Perfiles (analistas, diseñadores, …)

Responsabilidades Colaborar Seleccionar el objetivo de la iteración Hacer todo lo necesario para tener éxito Se organiza a si mismo y a su trabajo Demos. ante dueño producto y

stakeholders.

Roles…

Sea como fuere…

Sprints (I)

Iteración acotada en el tiempo [2s-4s]

Meta del Sprint …Sprint de Release…

Calidad

[1] ó [4, ) [1] ó [4, ) semanassemanas

[3,4] semanas[3,4] semanas

2 semanas2 semanas

Sprints (II)

Sprints (III)

Alcance

Estimación Importancia

(Alcance) (Calidad)(Calidad)

Sprints (IV)

( )

Sprints (V)

Reglas: El Equipo puede buscar ayuda externa. Nadie del exterior debe proveer al

Equipo con directivas. Nadie fuera del Equipo puede cambiar los

items del Backlog del Sprint. El Scrum Master o el Dueño del Producto

pueden cancelar el Sprint.

Sprints (VI)

Reglas: Ante adelantos/retrasos…

… el Equipo puede consultar al Dueño del Producto qué items agregar/quitar. El Scrum Master podría decidir cancelarlo.

Gestionar desvíos en las planificaciones. Asistencia al Scrum diario y actualizar

el Backlog del Sprint (que puede crecer). El Equipo tiene que adherir a los

estándares.

Backlog del Producto (I)

Artefacto más importante de Scrum Lista priorizada de:

Requerimientos funcionales Mejoras Tecnología Corrección de errores

Típicamente formado por historias de usuario

Nunca se da por completo (a diferencia de un documento de requisitos del sistema)

Backlog del Producto (II)

Formato: hoja cálculo, pizarra, herramienta colaborativa

Incluye: identificador, descripción, prioridad, estimación

Opcional: observaciones, criterios validación

Gestionado por el Dueño del Producto

Backlog del Sprint (I)

Contiene tareas para convertir un Backlog del Producto en funcionalidad.

Las tareas del Backlog del sprint están respaldadas por un Backlog del Producto.

Las tareas se estiman en horas [1-16] Las de más de 16 horas se descomponen

Los miembros del equipo eligen las tareas

Sólo los miembros del Equipo pueden alterar las tareas del backlog del sprint

Actualizar la estimación de trabajo restante

Backlog del Sprint (II)

Formato: hoja cálculo, pizarra, herramienta colaborativa

Incluye: lista tareas, responsables, estado, tiempo restante

No incluye: información innecesaria

Es ágil y soporta el Scrum diario

Backlog del Sprint (III)

La Velocidad

Factor de foco/dedicación Mide cuan fiables son nuestras estimaciones Tiene en cuenta los imprevistos (< 100%) Inicialmente 70% Sprint 2 y sucesivos: ffi = (ff(i-1) + ff(i-2))/2

Velocidad del equipo 4 desarrolladores 15 días ideales Factor de foco = 0,7 15 * 4 *0,7= 42 puntos

Alternativas•Estimación a OjO•Tiempo que hizo ayer

Alternativas•Estimación a OjO•Tiempo que hizo ayer

Reuniones (I)

Reunión de Planificación Exposición Resolución

Scrum Diario Demostración o Revisión del Sprint Retrospectiva del Sprint

Reuniones (II)

Reunión Planificación(I)

Fase 1: Exposición (de historias) Horario

Durante la mañana Asistentes

Equipo + Scrum Master + Dueño del Producto Outputs:

Priorización Estimación

Hasta superar la Velocidad ≤ 20 puntos

Historias del Backlog del Sprint

•Lidera esta reunión•Evita divagaciones

Reunión Planificación(II)

Fase 1: Exposición (de historias) Outputs:

Objetivo del Sprint

Gestión de maestros

Scrum Diario De 9:30 a 9:45 en la Sala de Reuniones

Duración del Sprint

3 semanas

Revisión del Sprint

22 de Junio de 2010 en la Sala de Reuniones

Gráfico Burndown

Avance ideal

Reunión Planificación (III)

Fase 2: Resolución Horario

Durante la tarde Asistentes

Equipo + Scrum Master Outputs

Tareas del Backlog del Sprint Tarea < 4 días ideales

Reunión Planificación (IV)

Agenda

45

Reunión Planificación (V)

Acuerdo

46

Reunión Planificación (VI)

• Outputs: Tablero del Sprint

Reunión Planificación (VII)

Reunión Planificación (VIII)

Reunión Planificación (IX)

50

Scrum Diario (I)

Scrum Diario Horario

Todos los días a las 10:00 h (a lo sumo 15’) Asistentes

Equipo + Scrum Master Objetivos

Repasar (rápidamente) la situación y el tiempo restante para finalizar el sprint. Identificación temprana de impedimentos, confianza y

motivación, mejora comunicaciones y productividad (presión inconsciente!!!)

Sincronizar actividades Outputs

Backlog del Sprint y Gráfico Burndown actualizados Identificación de necesidades e impedimentos

•Lidera esta reunión•Evita divagaciones

Scrum Diario (II)

Reglas Todos los días en el mismo sitio y hora Asisten todos los miembros Puntualidad o multa (para cafés…) Todos hablan en sentido agujas reloj (sin

interrupciones) Se responde al grupo (NO al Scrum

Master): ¿Qué hiciste?¿Qué harás?¿Qué problemas has

tenido? Pollos invitados pero NO participan

Revisión Sprint (I)

Revisión (demostración) del Sprint Horario

La preparación no debe superar las 2h, sino algo falla con el concepto de “Terminado”.

Duración [1h- 2h] Asistentes

Equipo + Scrum Master + Dueño Producto Opcionalmente otros interesados

Objetivos Obvio… …demostrar funcionalidad!!! Visualización temprana!!

¿Qué?

Revisión Sprint (II)

Revisión (demostración) del Sprint Reglas

Demostración en vivo (sin transparencias, papeles…). Se puede utilizar un PC de desarrollo

Primero se describe previsión (objetivo + historias) y luego ejecución (¿OK?¿KO?¿Por qué?)

Se debe demostrar conforme a pruebas de aceptación

Debate y cambios (sólo el Dueño del Producto puede aceptarlos)

Retrospectiva Sprint (I)

Retrospectiva del Sprint Horario Asistentes

Equipo + Scrum Master Objetivos

Mejorar Aspectos técnicos,

Reglas

¿Cómo?

Retrospectiva Sprint (II)

Retrospectiva del Sprint Dinámica

Cada miembro expone su visión y rellena dos primera columnas

Luego el grupo propone acciones correctoras 3 votos en papel x Miembro Scrum Master

recuenta y propone hacer foco en 2-3 de ellas

Bueno A Mejorar Acción correctora

Retrospectiva Sprint (III)

57

Técnicas:Historias de Usuario (I)

El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo

• El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.

Se verifica si el cliente está en condiciones de tomar este plan.Se confirma la operación por parte del sistema

Técnicas:Historias de Usuario (II)

• ¿Cómo sería la identificación del cliente (login)?

- Usuario y contraseña• ¿El pedido de cambio de plan

se resuelve Online o no? - Online

• ¿Se puede modificar un pedido grabado?

- Sí• ¿Se puede cancelar un

pedido?- Sí •Surgen nuevas historias•Surgen nuevas historias

Técnicas:Historias de Usuario (III) Nombre

Breve Conciso

Importancia ≡ Prioridad A es más importante

que B si A > B Estimación

Inicialmente vacía Se valora durante la

reunión de planificación Validación

A efectos de aceptación

Nombre Historia

Importancia

Estimación

Validación

Técnicas:Planning Poker (I)

Técnicas:Planning Poker (II)

Técnicas:Actualización Estimaciones

Gestión Maestros

100

4

Es posible crear, buscar, borrar

y actualizar maestros

Gestión Maestros

100Julio

4

Es posible crear, buscar, borrar

y actualizar maestros

Gestión Maestros

100

4

Es posible crear, buscar, borrar

y actualizar maestros

X 2 Gestión Maestros

100

4

Es posible crear, buscar, borrar

y actualizar maestros

X 2X

Técnicas: Control de impedimentos

Sistema

legado KO!Sistema

legado KO!

I

Sistema

legado KO!

II

Servicio

Web Down!Servicio

Web Down!

IGestionados por Scrum MasterGestionados por Scrum Master

¿A QUÉ ESTAMOS JUGANDO?

No me lo creo, ¡demuéstramelo!

Sprints Tipo

Sprint 0: Preparación Sprint 1: Comienzo Sprint 2: Aumenta Velocidad Sprint 3: Impedimentos Sprint 4: ¡Más Caña!

Sprint 0: Preparación (I)

Definición Backlog de Producto Estimaciones imprecisas (en días) No es problema, en las primeras iteraciones se verá si

el proyecto es o no viable Presentación de los roles Visión de Proyecto

Cualquier integrante conoce el propósito del proyecto Definición de Terminado

Cumple requerimientos, funciona en desarrollo, diseño completo, desarrollo TDD, Tests OK, probado IE6 y Firefox, documentación, 0% CS, 0% PMD…

Definición inicial de entregables

Sprint 0: Preparación (II)

Reunión kick-off Alcance Revisión backlog Enfoques técnicos Acuerdos varios (horas de las reuniones…)

Logística Ubicación (ej.: reserva de salas de

reuniones) Material (equipos, red, pizarra, entorno

desarrollo…)

Sprint 1: Comienzo

Día 1 Velocidad inicial

Factor de foco (inicialmente 70%) Reunión de Planificación del Sprint

Exposición + Resolución Día 2

Los desarrolladores eligen tareas Scrum diario

Día 15 Reunión de Revisión Reunión de Retrospectiva

Sprint 2: + Velocidad

Día 1 Recalcular Factor de Foco Reunión de Planificación del Sprint

Día 10: hemos terminado las tareas!!! Se recupera del Backlog del Producto un

nuevo item… Día 15

Reunión de Revisión Reunión de Retrospectiva

Sprint 3: Impedimentos

Día 1 Aumenta el Factor de Foco Reunión de Planificación de Sprint

Día 3 Surge un impedimento

Registro en la Lista de Impedimentos Día 8

Surge un imprevisto (bajas) Registro en la lista de imprevistos

Día 9 Se comunica al Dueño del Producto que se prevé retraso.

¡Lo intentaremos de todas formas! Día 15

Reunión de Revisión Reunión de Retrospectiva

Sprint 4: ¡Más caña!

Scrum Checklist

Conclusiones

74

Contactos y Página web

http://www.ceb2b2000.com [email protected] [email protected]

Julio A. Argüello FernándezResponsable de Arquitectura y Desarrollo

Grupo B2B 2000

75

Bibliografía

Do It Yourself Agile Damon B. Poole. Septiembre 2009. Scrum y XP desde las Trincheras Henrik Kniberg.

2007. Agile Estimating and Planning,  Prentice Hall, Mike

Cohn, 2005 Blogs

http://www.dosideas.com http://blog.crisp.se/henrikkniberg

Webs http://agilemanifesto.org/ http://www.navegapolis.net/ http://www.agile-spain.com/ http://www.proyectosagiles.org/ http://www.scrumalliance.org/

ESCUELA DE INGENIERÍA INFORMÁTICAUniversidad de Oviedo

DIRECCION Y GESTIÓNDE PROYECTOS WEB

FIN