SCRUM: Introducció al desenvolupament ágil de programari

Transcripción

1 Cibernàrium SCRUM: Introducció al desenvolupament ágil de programari Capacitació Tecnològica per a Professionals i Empreses Professor: Àlex Ballarin Data Pàg 1

2 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

3 Àrees d activitat de Barcelona Activa 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 Emprenedoria Capacitació Professional i Ocupació Formació Economia Social Pàg 3

4 Gestión de proyectos SCRUM Clase 1 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 4

5 Gestión de proyectos SCRUM Clase 1 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 5 5

6 1. Metodologías ágiles vs tradicionales Cascada (waterfall) Ciclos de vida» 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 6

7 1. Metodologías ágiles vs tradicionales Ciclos de vida Systems Development Life Cycle (elaboración de Cascada) 7

8 1. Metodologías ágiles vs tradicionales 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 8

9 1. Metodologías ágiles vs tradicionales Iterativo o Espiral Ciclos de vida» 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) 9

10 1. Metodologías ágiles vs tradicionales 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 10

11 1. Metodologías ágiles vs tradicionales Algunas metodologías Waterfall, Benington 1956 Extreme Programming, 1999 V-Model, Hugues Aircraft 1982 RUP, Rational 1996 DAD, Ambler Scrum, Schwaber 1995 Agile Manifesto, 2001 Spiral, Boehm

12 1. Metodologías ágiles vs tradicionales Disciplined Agile Delivery (2011) Completa el ciclo de vida de la solución (no sólo la construcción ) 13

13 1. Metodologías ágiles vs tradicionales 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! 14

15 1 2. Fundamentos de Scrum Tener compromiso y estar comprometido 16

16 1 2. Fundamentos de Scrum Proceso definido Proceso empírico vs definido» Todas las actividades y tareas deben entenderse previamente» Dadas unas entradas caracterizadas, las mismas salidas se obtienen en cada ejecución 17

17 1 2. Fundamentos de Scrum Proceso empírico Proceso empírico vs definido» 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. 18

18 1 2. Fundamentos de Scrum Scrum en 1 minuto: productos, roles y eventos 19

19 1 2. Fundamentos de Scrum 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 20

20 1 2. Fundamentos de Scrum Sprint Planning Reuniones de Scrum» 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 21

21 1 2. Fundamentos de Scrum Las horas de un Sprint Sprint Planning (4h) Daily Scrum (15 min) Sprint Review (2h) Retrospective Sprint (2h) Ejemplo del reparto de horas de un Sprint Equipo 5 personas (40h/semana) Reserva para desarrollo: 80% Sprint de 2 semanas (10 días labor.) Capacidad sprint: 5 * 40 * 2 = 400h Reserva para incidencias, etc.: 20% Desarrollo neto: 400h * 80% 5*4h 5*2h 5*2h = 280h 22

22 1 2. Fundamentos de Scrum Ciclo de vida iterativo Características de Scrum» 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. 23

23 1 2. Fundamentos de Scrum Foco Los 5 valores de Scrum» 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 25

25 Roles 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 27

26 Roles de Scrum Responsabilidad Development Team (DT)» 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 ) 28

27 Roles de Scrum Responsabilidad Scrum Master (SM)» 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 29

29 Eventos de Scrum 5 6 Objetivo Sprint» 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 31

30 Eventos de Scrum 5 6 Objetivo Reunión de planificación de Sprint» 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 32

31 Eventos de Scrum 5 6 Objetivo Scrum diario» 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! 33

32 Eventos de Scrum 5 6 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 34

33 Eventos de Scrum 5 6 Objetivo Retrospectiva de Sprint» 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 35

34 1 2. Fundamentos de Scrum 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 36

36 Artefactos de Scrum 6 Product Backlog Planificación del proyecto (1) Sprint #1 (15/Feb) [320h] Historia 1 (45h) Historia 2 (80h) Historia 3 (90h) Historia 4 (70h) 285h Sprint #2 (1/Mar) [320h] Historia 5 (80h) Historia 6 (90h) Historia 7 (60h) Historia 8 (70h) 300h Sprint #3 (15/Mar) [320h] Historia 9 38

37 Artefactos de Scrum 6 Product Backlog Planificación del proyecto (2)» 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) 39

38 Artefactos de Scrum 6 Product Backlog Temas y Epics Planificación del proyecto (3) S#1 (15/Feb) [320h] Historia 1 (45h) Historia 2 (80h) Historia 3 (90h) Historia 4 (70h) S#5 (15/Abr) [320h] Feat 22 (120h) Feat 25 (180h) S#2 (1/Mar) [320h] Historia 5 (80h) Historia 6 (90h) Historia 7 (60h) Historia 8 (70h) S#6 (1/May) [320h] Feat 17 (140h) Feat 24 (150h) Backlog grooming 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] Trabajo programado Trabajo planificado / comprometido S#7 (15/May) [320h] Feat 17 (140h) Feat 24 (150h) S#7 (1/Jun) [320h] Epic 3 (300h) Feat 31, Feat 32, Feat 35, Feat 37 Epic 4, Epic 5, Epic 7 Trabajo NO comprometido 40

39 Artefactos de Scrum 6 Release Plan / Roadmap Planificación del proyecto (4)» 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 41

40 Artefactos de Scrum 6 Sprint Backlog Planificación del Sprint» 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. 42

41 Artefactos de Scrum 6 Kanban Board Seguimiento del Sprint (1)» No es un artefacto oficial de Scrum pero sí de uso frecuente. 43

42 Artefactos de Scrum 6 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 44

43 Artefactos de Scrum 6 Recta de burn down Seguimiento del Sprint (2)» Avanzamos al ritmo planificado? (iteración o release)» Siempre se refiere a analizar el avance futuro (en el examen) 45

44 Artefactos de Scrum Seguimiento del Proyecto (1) Velocity Chart» Observar cual es la velocidad estimada 47

46 52 52