SCRUM: Introducció al desenvolupament ágil de programari

Data

SCRUM: Introducció al desenvolupament

ágil de programari Capacitació Tecnològica per a Professionals i Empreses

Cibernàrium

Pàg 1

Professor: Àlex Ballarinhttp://es.linkedin.com/in/alexballarin

Barcelona Activa: Qui som? Barcelona Activa, integrada en l’àrea d’Economia, Empresa i Ocupació, és l’organització executora de les polítiques de promoció econòmica de l’Ajuntament de Barcelona. Des de fa 25 anys impulsa el creixement econòmic de Barcelona i el seu àmbit d’influència donant suport a les empreses, la iniciativa emprenedora i l'ocupació, alhora que promociona la ciutat internacionalment i els seus sectors estratègics; en clau de proximitat al territori.

Barcelona Activa va ser guanyadora del Gran Premi del Jurat 2011, atorgat per la DG d’Empresa i Indústria de la Comissió Europea en el marc dels European Enterprise Awards, per la iniciativa empresarial més creativa i inspiradora d’Europa.

Pàg 2

Formació

Àrees d’activitat de Barcelona Activa

Emprenedoria

Barcelona Activa s’estructura en tres grans blocs de serveis a les Empreses, a l’Emprenedoria i a la Ocupació. La Formació és un instrument transversal present en els tres blocs, així com també tot el relacionat amb l’economia social.

Empresa Capacitació Professional i Ocupació

Economia Social

Pàg 3

4 SCRUM: intruducció al desenvolupament ágil de programari

1 Metodologías ágiles vs tradicionales

2 Fundamentos de Scrum

3 Roles de Scrum

4 Eventos de Scrum

5 Artefactos de Scrum

6 Agilidad disciplinada: DAD

Gestión de proyectos SCRUM – Clase 1

5 5 SCRUM: intruducció al desenvolupament ágil de programari



3 Roles de Scrum

4 Eventos de Scrum




Ciclos de vida

Cascada (waterfall) » Simple y fácil de entender » Aproximación “disciplinada” » Big Design Up Front (BDUF) » Revisión sistemática en hitos » Cambios más caros cuanto más tarde se descubren » Énfasis en control y documentación » Efecto “90%” » Riesgo de no satisfacer al cliente

× Suele desviarse en tiempo × Las funcionalidades se validan tarde


1. Metodologías ágiles vs tradicionales 2 3 4 5 6

Ciclos de vida

Systems Development Life Cycle (elaboración de Cascada)



Ciclos de vida

V-Model » Permite validar cada actividad de requisitos y diseño con sus pruebas

correspondientes » Permite trabajar en paralelo a diferentes roles del equipo » El “feedback” del cliente llega antes » Avance más seguro, las pruebas detectan menos “sorpresas”


Diagrama realizado por Gemma Grau


Ciclos de vida

Iterativo o Espiral » Evita el “BDUP” (gran diseño inicial) » Permite obtener antes el feedback del cliente » Se evita el riesgo de fallo

× Se prueban antes las funciones más dudosas × Se prueba antes las tecnologías más complejas

» Entrega antes las partes del producto al cliente × Menos riesgo (aprendizaje, descubrir cambios...) × El cliente disfruta antes del beneficio del producto (especialmente en proyectos

largos)



Agile Manifesto

12 Principios » Customer satisfaction by rapid delivery of useful software » Welcome changing requirements, even late in development » Working software is delivered frequently (weeks rather than months) » Working software is the principal measure of progress » Sustainable development, able to maintain a constant pace » Close, daily co-operation between business people and developers » Face-to-face conversation is the best form of communication (co-location) » Projects are built around motivated individuals, who should be trusted » Continuous attention to technical excellence and good design » Simplicity » Self-organizing teams » Regular adaptation to changing circumstances



Algunas metodologías


50 60 70 80 90 2000 10

Spiral, Boehm 1986

RUP, Rational 1996

Scrum, Schwaber 1995

Agile Manifesto, 2001

Waterfall, Benington 1956 V-Model,

Hugues Aircraft 1982 DAD, Ambler 2011

Extreme Programming, 1999


Disciplined Agile Delivery (2011)

Completa el ciclo de vida de la solución (no sólo la “construcción”)



Problemas habituales de los proyectos “en cascada”

Falta de conocimiento del alcance y del contexto al hacer la oferta comercial » Competencia fuerte » El cliente confía en el proveedor » El cliente no se implica » Alcance, calendario y presupuesto posiblemente incorrectos » Dada una estimación de esfuerzo, ¿con que probabilidad se cumplirá?

El objetivo suele ser cumplir el plan de proyecto y especificación original, ¡no aquello que necesita el cliente! » Los cambios en las fases finales son más costosos

¡ La deuda técnica se acaba pagando al final !






3 Roles de Scrum

4 Eventos de Scrum




Tener compromiso y estar comprometido


1 2. Fundamentos de Scrum 3 4 5 6

Proceso empírico vs definido

Proceso definido » Todas las actividades y tareas deben entenderse previamente » Dadas unas entradas caracterizadas, las mismas salidas se obtienen en cada

ejecución



Proceso empírico vs definido

Proceso empírico » El resultado de los procesos no está definido a priori. » El control del proceso no se realiza comparando las ejecuciones contra la

definición del proceso. » El control del proceso se realiza mediante la inspección y adaptación del

proceso en base a los resultados obtenidos. Además, se fomenta la transparencia para deducir las mejoras de manera compartida.



Scrum en 1 minuto: productos, roles y eventos



Roles de Scrum

Product Owner » Representa los intereses del cliente » Define los requisitos y marca las prioridades » Valida la implementación de los requisitos al final del sprint

Scrum Master » Se asegura que Scrum se adopta correctamente » No es jefe de proyecto ni se encarga de artefactos como el Burndown

Development Team

Scrum Team » La conjunción del Product Owner, Scrum Master y el Dev Team



Reuniones de Scrum

Sprint Planning » Refinar la estimación de las historias asignadas al Sprint » Comunicar el alcance de Sprint al product owner

Scrum Diario » En el mismo sitio y lugar, 15 minutos como máximo y de pie » ¿Qué hiciste ayer?, ¿Qué harás hoy?, ¿Qué problemas has tenido?

Revisión de Sprint

Retrospectiva de Sprint



Las horas de un Sprint


1 2 3 4 5 6 7 8 9 10 Sprint

Planning (4h)

Sprint Review (2h)

Retrospective Sprint (2h)

Ejemplo del reparto de horas de un Sprint Equipo 5 personas (40h/semana)

Sprint de 2 semanas (10 días labor.)

Capacidad sprint: 5 * 40 * 2 = 400h

Reserva para desarrollo: 80%

Reserva para incidencias, etc.: 20%

Desarrollo neto: 400h * 80% – 5*4h – 5*2h – 5*2h = 280h

Daily Scrum (15 min)


Características de Scrum

Ciclo de vida iterativo » Las iteraciones (Sprint) tiene duración fija (2, 4, 6 semanas). » Durante el sprint, no se cambia su alcance comprometido. » Tras cada iteración, se entrega una parte “funcionando” del producto. » Las funcionalidades se ordenan por prioridad en un Project Backlog y se

agrupan en Sprints según su tamaño. » Los recursos, tiempo y calidad no varían, el alcance sí.

× Se entrega el alcance, de manera priorizada en sprints, hasta que se acaba el presupuesto.

» El cliente fija expresamente sus prioridades y está informado en todo momento del avance del proyecto.



Los 5 valores de Scrum

Foco » El equipo se concentra en las historias del sprint (y en nada más)

Corage » El S.M. y el P.O. muestran corage al defender el Sprint backlog

Principio de transparencia » El Sprint Backlog muestra en todo momento el trabajo planificado y hecho

Commitment » El equipo se compromete con su estimación del Sprint Backlog

Respect » Se respeta la autonomía y el trabajo de todos los roles






3 Roles de Scrum

4 Eventos de Scrum




Product Owner (PO)

Responsabilidad » Maximizar el valor del producto y del trabajo del equipo de desarrollo

Funciones » Definir claramente los items del Product Backlog » Priorizar el Product Backlog y asegurar que el equipo lo utiliza en sus sprints » Los requisitos del producto siempre deben pasar por esta persona


1 2 3. Roles de Scrum 4 5 6

Development Team (DT)

Responsabilidad » Producir los incrementos del producto entregables al final de los sprints

Características » Se auto-organizan para realizar los ítems del Sprint Backlog » El Scrum Master ayuda a seguir los eventos, artefactos y roles de Scrum, pero

no dice al equipo como deben realizar su trabajo » Tamaño por encima de 3 (poca “potencia”) y por debajo de 9 (demasiada

“complejidad”)



Scrum Master (SM)

Responsabilidad » Ayudar a entender y seguir Scrum al equipo y a los demás actores

Funciones » Ayudar al Product Owner a entender como crear y mantener el Product

Backlog » Ayudar al PO y al resto de la organización a entender la planificación en

releases y sprints » Mentorizar y facilitar el trabajo auto-organizado del equipo » Facilitar que se produzcan las reuniones y artefactos de Scrum » Ayudar al equipo a mejorar su valor entregado y productividad






3 Roles de Scrum

4 Eventos de Scrum




Sprint

Objetivo » Contener todas las actividades de desarrollo en un ciclo corto (2 a 4

semanas) que den lugar a un producto entregable (interno/externo)

Características » No se admiten cambios (desde fuera) al objetivo del Sprint (Sprint backlog) » No se cambian los miembros del equipo » El alcance (definición de los ítems del backlog) se puede refinar entre el DT y

el PO » Un Sprint puede ser cancelado por el PO


1 2 3 4. Eventos de Scrum 5 6

Reunión de planificación de Sprint

Objetivo » Planificar el trabajo a realizar durante el Sprint

Duración: 2h * semana de Sprint (p.e. 2 semanas = 4 horas)

Parte 1: ¿Qué se hará en el Sprint? » Participa el Product Owner y el Development Team » Se estima la parte del Product Backlog que puede realizarse con el tiempo

(Sprint) y recursos (tamaño del equipo) disponibles

Parte 2: ¿Cómo se hará? » Participa sólo el Development Team » El alcance del Sprint se analiza y descompone en tareas más pequeñas (4..8

horas) y se consensúa la estrategia para realizarlas



Scrum diario

Objetivo » El equipo da seguimiento a su trabajo, se coordina y planifica el trabajo a

realizar durante la jornada

Duración: 15 minutos (¡y de pie! Y mismo lugar/hora)

El equipo se coordina explicando cada miembro: » ¿Qué hiciste ayer? » ¿Qué harás hoy? » ¿Qué obstáculos has tenido o tendrás?

¡Sólo responder las preguntas! !No permitir un debate!



Revisión de Sprint

Objetivo » Revisar y validar el resultado del Sprint » Mejorar la colaboración entre equipo y los actores externos

Duración: 4 horas

Actividades » El DT muestra el resultado conseguido al PO » El DT explica qué fue bien, qué fue mal y como se reaccionó » El PO actualiza el Product Backlog según el avance conseguido » Todos colaboran para planificar los próximos pasos



Retrospectiva de Sprint

Objetivo » Aprender de lo que ha ido mal para mejorar en el próximo sprint

Duración: 1h * semana de sprint aprox. (3h sprint 4 sem.)

Participa: sólo el Development Team

Contenidos » Identificar como fue el Sprint respecto gente, relaciones, procesos y

herramientas » Identificar las cosas que fueron bien y como mejorar las que no » Planificar (que, quien, como) las mejoras para el Sprint



Aplicabilidad de Scrum

Tipos de proyecto donde Scrum es muy adecuado » Desarrollo interno de producto » Existe confianza entre cliente y proveedor » No se requieren grandes inversiones materiales iniciales » Equipo cohesivo (objectivos y disponibilidad comunes)

Tipos de proyecto donde mejor no usar Scrum » Relación “contractual” entre cliente y proveedor » Plazo, alcance y recursos fijados de antemano » Se requiere una gran inversión inicial relacionada con el alcance definido

para el proyecto » Equipo de diferentes empresas con objetivos propios


1 2. Fundamentos de Scrum 3 4 5




3 Roles de Scrum

4 Eventos de Scrum




“Planificación” del proyecto (1)

Product Backlog


Sprint #1 (15/Feb) [320h]

Historia 1 (45h) Historia 2 (80h) Historia 3 (90h) Historia 4 (70h)

Sprint #2 (1/Mar) [320h]


Sprint #3 (15/Mar) [320h]

Historia 9 · · ·

285h

300h

1 2 3 4 5. Artefactos de Scrum 6


Product Backlog » Contiene todo el trabajo pendiente (relevante para el Product Owner)

× Normalmente funcional (en forma de “historias de usuario”) × Tareas técnicas de “I+D” (p.e. Architectural Spike) × Cualquier otro tipo de item relevante para el P.O. (bug, cambio…)

» La priorización la da el “product owner”, y en la estimación participa todo el equipo. El orden se calcula con: {valor, riesgo, necesidad}.

» No toda la información de los ítems está en el Backlog (p.e. wiki de referencia)

» Los elementos se van detallando tal y como se aproximan: ¿porqué elaborar un elemento lejano que puede cambiar o desestimarse?

» La priorización puede realizarse durante el sprint o en la revisión de sprint, pero su elaboración es continua (backlog grooming)




Product Backlog – Temas y Epics


S#1 (15/Feb) [320h]


S#2 (1/Mar) [320h]


S#1 (15/Feb) [320h]

S#2 (1/Mar) [320h]

S#3 (15/Feb) [320h]

S#4 (1/Abr) [320h]

S#5 (15/Abr) [320h]

S#6 (1/May) [320h]

S#7 (15/May) [320h]

S#8 (1/Jun) [320h]

Feat 31, Feat 32, Feat 35, Feat 37 Epic 4, Epic 5, Epic 7

Trabajo programado

Trabajo planificado / comprometido

Trabajo NO comprometido

S#5 (15/Abr) [320h] Feat 22 (120h) Feat 25 (180h)

S#6 (1/May) [320h] Feat 17 (140h) Feat 24 (150h)

S#7 (15/May) [320h] Feat 17 (140h) Feat 24 (150h)

S#7 (1/Jun) [320h] Epic 3 (300h)

Back

log

gro

omin

g



Release Plan / Roadmap » Compartir con la organización una visión simplificada de los próximos sprints

del proyecto y de su contenido » No es un artefacto puro de Scrum, pero es muy frecuente



Planificación del Sprint

Sprint Backlog » Al comenzar un Sprint (Sprint Planning), se analizan las historias de usuario

asignadas y se descomponen en tareas. » El “dueño” es el equipo de desarrollo. » Capacidad del Sprint

× Tamaño del equipo * Duración * Dedicación × P.e. 3 personas * 2 semanas * 80% = 192 horas × Se recomienda asignar máximo el 80% del tiempo útil para absorver desviaciones

» Al refinar las historias, puede descubrirse que las funcionalidades asignadas sean más grandes de la capacidad.

» Se puede añadir o eliminar contenido según se vea que el avance es superior o inferior al planificado.



Seguimiento del Sprint (1)

Kanban Board » No es un artefacto oficial de Scrum pero sí de uso frecuente.



The Definition of Done (DoD)

El equipo hace una “DoD – Definition Of Done” » Esta definición la usará cada miembro del equipo para dar por acabada cada

historia de usuario » Ejemplo:

× Código completado × Test unitarios creados y superados × Test integrado creado y superado × Documentado (lo necesario) × La interfaz seguirá los estándares descritos en: intranet/UI.html × Las historias con persistencia serán recuperables en caso de caída del sistema × Las historias no tendrán ningún defecto que no sea “Prioridad 4 - menor” × · · ·

No existe el rol de “pruebas” » Cada miembro del equipo es responsable de dar como terminada una

funcionalidad » El Product Owner da la validación final



http://www.google.com/

Seguimiento del Sprint (2)

Recta de “burn down” » ¿Avanzamos al ritmo planificado? (iteración o release) » Siempre se refiere a analizar el avance futuro (en el examen)



Seguimiento del Proyecto (1)

Velocity Chart » Observar cual es la “velocidad” estimada


1 2 3 4 5. Artefactos de Scrum




3 Roles de Scrum

4 Eventos de Scrum




52 SCRUM: intruducció al desenvolupament ágil de programari 52

SCRUM: Introducció al desenvolupament ágil de programari

Documents

Transcript of SCRUM: Introducció al desenvolupament ágil de programari