Tema II Métodos Ágiles

Transcripción

1 Tema II Métodos Ágiles Dr. Javier Garzás Universidad Rey Juan Carlos ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS ÁGILES 6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES 2 1

2 Se puede desarrollar software igual que industrialmente se construyen coches o casas? 1955 La ingeniería software era igual que la hardware. Aquellos tiempos, todos eran ingenieros hardware o matemáticos B. Boehm 2

3

4 2005 Diseño previo e inamovible 4

5 antes de la Construcción Predictibilidad 5

6 Ciclo de vida en Cascada 6

7 7

8 = % avance 8

9 Diseño Construcción Tradicional Software V1 V2 V3 9

10 Predicción vs Evolución 10

11 EL CICLO DE VIDA ITERATIVO INCREMENTAL (I) Se va liberando parte del producto periódicamente y cada entrega es un incremento respecto a la anterior. Cada fase se realiza varias veces. Lo cual difiere del desarrollo en cascada, donde las fases del ciclo de vida se realizan (en teoría) una única vez, y el inicio de una fase no comienza hasta que termina la fase que le precede 21 ITERATIVO = INCREMENTAL

12 EL CICLO DE VIDA ITERATIVO INCREMENTAL (II) Se comenzó a aplicar en 1950, en la construcción del avión cohete X-15 En 1960 es aplicado por la NASA en el proyecto Mercury 23 12

13 1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y contínua de software con valor. Principios Ágiles 2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles. 4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. 5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte que necesitan, y confiando en ellos para que realicen el trabajo. Principios Ágiles 6. El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara. 7. Software que funciona es la principal medida de progreso. 8. Los procesos ágiles promueven el desarrollo sostenible. Esponsores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad. 13

14 Principios Ágiles 10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se autoorganizan. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces mejora y ajusta su comportamiento de acuerdo a sus conclusiones. Traducción realizada por Agile Spain del original en Inglés. Éste pueden encontrarse en 14

15 HAY 3 TIPOS DE METODOLOGÍAS Tradicionales Ágiles Híbridas 29 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Tradicionales Ágiles Híbridas 30 15

16 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Cambiabilidad: Las metodologías ágiles están preparadas para adaptarse a cambios, mientras que las tradicionales presentan cierta resistencia a los mismos 31 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Metodologías tradicionales: conceptos característicos de la fabricación industrial o la arquitectura 32 16

17 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Producción en cadena -> Trabajo repetible, generalmente más manual que intelectual y operario sustituible División del trabajo y métodos Tayloristas ( Principles of Scientific Management (1912)) Actividades diferenciadas: el diseño y la construcción. Construcción: poca actividad intelectual y más manual. Los costes de la construcción (y sus cambios) son muy superiores a los del diseño. Por ello el diseño pretende controlar el 100% la construcción Diseño basado en matemáticas - física 33 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES PERO EN SOFTWARE ES LO MISMO? CUÁNDO SABEMOS QUÉ SOFTWARE QUERÍAMOS CONSTRUIR? CUESTA LO MISMO CAMBIAR UNA COLUMNA QUE UNA LÍNEA DE CÓDIGO? EXISTE UNA BASE MATEMÁTICA CIENTÍFICA? 34 17

18 CHOQUES ENTRE OLAS : ADAPTATIVO VS. PREDICTIVO METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Algunas diferencias entre ágil y tradicional 36 18

19 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Contrato: En las metodologías tradicionales normalmente existe un contrato cerrado, mientras que en las ágiles no existe este tipo de contrato o, si existe, es bastante flexible 37 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Interacción con el cliente: En las metodologías tradicionales, el cliente interactúa con el equipo de desarrollo mediante reuniones. Sin embargo, en las metodologías ágiles el cliente forma parte del equipo de desarrollo 38 19

20 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Tamaño de los grupos: Las metodologías ágiles están definidas para grupos pequeños (menos de 10 integrantes) que trabajan en el mismo sitio. Sin embargo, las metodologías tradicionales se definen para grupos grandes y posiblemente distribuidos 39 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Arquitectura del software: Para las metodologías tradicionales la arquitectura del software es esencial y se expresa mediante modelos. Las ágiles, por su parte, ponen un menor énfasis en la arquitectura del software 40 20

21 METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES Documentación: La documentación en los procesos ágiles es más relajada, mientras que en los procesos tradicionales es más exhaustiva. 41 EJERCICIO: CUÁL ES MÁS ADECUADO? 1. Gran cambiabilidad de los requisitos 2. Necesidad de una arquitectura robusta 3. Documentación muy detallada 4. Un contrato cerrado 5. Se necesita interacción con el cliente 6. Tamaño equipo pequeño 7. Se necesita predicción 8. Se necesita Reacción - Adaptación ÁGIL / TRADICIONAL 42 21

22 ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS ÁGILES 6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES 43 METODOLOGÍAS HÍBRIDAS Tradicionales Ágiles Híbridas 44 22

23 METODOLOGÍAS HÍBRIDAS La realidad en las empresas refleja posturas moderadas en la implantación de metodologías ágiles, hibridas y orientadas por la necesidad, al negocio y mejor práctica para cada organización y proyecto 45 METODOLOGÍAS HÍBRIDAS Consisten en adaptaciones de las Metodologías Ágiles, muchas veces incorporándole prácticas formales, como, por ejemplo, el robustecer y hacer menos iterativa la fase de diseño de la arquitectura software 46 23

24 CUATRO MÉTODOS DE DESARROLLO El intercambio de la cultura organizacional y la estabilidad del proyecto sugieren dos métodos nuevos de desarrollo además de los métodos formales y ágiles 47 ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS ÁGILES 6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES 48 24

25 SCRUM Metodología ágil que proporciona un marco para la gestión de proyectos. Está especialmente indicada para proyectos con un cambio rápido en los requisitos 49 SCRUM Basada en entregas parciales priorizadas por el beneficio que aporta al receptor del proyecto 50 25

26 SCRUM Permite obtener resultados tempranos y que permite adaptarse a los cambios en los requisitos 51 CARACTERÍSTICAS PRINCIPALES Desarrollo software mediante iteraciones Reuniones a lo largo del proyecto 52 26

27 EL PROCESO DE SCRUM 53 SPRINT A cada iteración se le denomina sprint. El sprint es un periodo de corta duración (2-4 semanas) en el que se crea un producto potencialmente entregable 54 27

28 PRIMER PASO: PRODUCT BACKLOG Las características que van a implementarse en el sprint provienen de la Pila del Producto (Product Backlog), que contiene una serie de requisitos priorizados para su aplicación 55 PRIMER PASO: PRODUCT BACKLOG HISTORIAS DE USUARIO El product backlog debe ser una lista priorizada y estimada de historias de usuario Como xxx, quiero hacer yyy con el objetivo de zzz 56 28

29 PRIMER PASO: PRODUCT BACKLOG PRIORIZACIÓN: ESTIMACIÓN Y VALOR Planning Poker Secuencia de Fibonacci 57 PRIMER PASO: PRODUCT BACKLOG PRIORIZACIÓN: RESPONSABILIDAD DEL PRODUCT OWNER (CLIENTE)

30 SPRINT BACKLOG Una vez seleccionadas las características que van a desarrollarse en el Sprint, se conforma la Pila del Sprint (Sprint Backlog), que se mantendrá inamovible durante toda la iteración 59 SPRINT BACKLOG Velocidad: cantidad de story points o historias de usuario que terminan por iteración. Burndown charts 60 30

31 HISTORIAS 61 LAS REUNIONES Son una parte importante dentro de Scrum. Se definen diversos tipos de reuniones: Daily Scrum Sprint Planning Meeting Sprint Review Meeting Sprint Retrospective 62 31

32 REUNIÓN DIARIA (DAILY SCRUM) Reunión de no más de 15 minutos en la que se presenta que hizo ayer cada miembro del equipo, que va a hacer hoy y que problemas se ha encontrado 63 REUNIÓN DE PLANIFICACIÓN DEL SPRINT (SPRINT PLANNING MEETING) Se realiza al principio de cada Sprint, definiendo en ella que se va a realizar en ese Sprint. Esta reunión da lugar al Sprint Backlog. Su duración no debe ser mayor de 8 horas 64 32

33 REUNIÓN DE REVISIÓN DEL SPRINT (SPRINT REVIEW MEETING) Se realiza al final del Sprint. Durante la misma se indica qué ha podido completarse y qué no, presentando el trabajo realizado a los implicados. No debe durar más de 4 horas 65 RETROSPECTIVA DEL SPRINT (SPRINT RETROSPECTIVE) Se realiza al final del Sprint, sirve para que los implicados den sus impresiones sobre el Sprint que acaba de terminar. Se utiliza para la mejora del proceso. Esta reunión debería durar 4 horas 66 33

34 RESUMEN Scrum: Metodología ágil que proporciona un marco para la gestión de proyectos, indicada especialmente para proyectos con un cambio rápido en los requisitos. Sprint: Período de corta duración (2-4 semanas) en el que se crea un producto potencialmente entregable. Product backlog: Lista priorizada que contiene una serie de los requisitos del producto priorizados para su realización. Sprint backlog: Lista con las características que van a desarrollarse en el Sprint. 67 RESUMEN Daily Scrum: Reunión de no más de 15 minutos en la que se presenta que hizo ayer cada miembro del equipo, que va a hacer hoy y los problemas que se ha encontrado. Sprint planning meeting: Reunión de no más de 8 horas realizada al principio de cada Sprint, en la que se define que se va a realizar en el mismo. Sprint review meeting: Reunión de no más de 4 horas realizada al final del Sprint, en la que se presenta el trabajo realizado a los implicados. Sprint retrospective: Reunión de no más de 4 horas que se realiza al final del Sprint, realizada para recoger las impresiones de los implicados respecto al Sprint realizado

35 ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS ÁGILES 6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES 69 Automated builds Continuous integration Unit testing Refactoring Iterative development Pair programming Daily meetings On-site customer 70 35

36 ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS ÁGILES 6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES 71 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 72 36

37 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 73 extreme Programming (XP) Centrada en potenciar las relaciones interpersonales. Se basa en la realimentación continua entre el cliente y el equipo de desarrollo, la comunicación fluida entre todos los participantes, la simplicidad en las soluciones implementadas y el coraje para enfrentarse a los cambios 74 37

38 CARACTERÍSTICAS DE extreme Programming (XP) El juego de la planificación: hay una comunicación frecuente entre el cliente y los programadores. Los técnicos estiman el esfuerzo requerido para la implementación, mientras que los clientes deciden sobre el tiempo de cada iteración. Entregas pequeñas: una entrega no debería tardar más de tres meses, tiempo en el que debe desarrollarse una versión del sistema que sea operativa aunque no cuente con toda la funcionalidad del sistema. Metáfora: es una historia que describe el funcionamiento del sistema. El sistema es definido por una metáfora o un conjunto de ellas compartidas por el cliente y el equipo de desarrollo. 75 CARACTERÍSTICAS DE extreme Programming (XP) Diseño simple: se debe diseñar la solución más simple que pueda funcionar. Pruebas: la producción del código está dirigida por pruebas unitarias. Refactorización: la reestructuración del código es necesaria para la mejora de la calidad del mismo. Se mejora la estructura interna del código sin alterar su comportamiento externo. Programación por pares: la producción se hace en parejas, lo que conlleva evitar errores, mejorar el diseño, etc. Propiedad colectiva del código: cualquier programador puede cambiar cualquier parte del código en cualquier momento

39 CARACTERÍSTICAS DE extreme Programming (XP) Integración continua: cada parte del código es integrada en el sistema una vez que está lista. 40 horas por semana: de debe trabajar un máximo de 40 horas semanales, y no realizar horas extra durante dos semanas seguidas. Si esto ocurre, algo está realizándose mal. Cliente in-situ: el cliente debe estar presente y disponible todo el tiempo para el equipo, conduciendo el trabajo hacia lo que aportará mayor valor de negocio. Estándares de programación: la comunicación entre programadores se realiza a través del código, por lo que es importante que se sigan unas reglas para mantener el código legible. 77 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 78 39

40 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM) Primera metodología ágil (1994) y la mas próxima a los métodos tradicionales. Metodología iterativa e incremental en el que equipo de desarrollo y usuario trabajan juntos. Propone cinco fases: estudio de viabilidad, estudio del negocio, modelado funcional, diseño y construcción y por último implementación. Las tres últimas fases son iterativas, y existe realimentación entre cada fase. 79 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 80 40

41 ADAPTIVE SOFTWARE DEVELOPMENT (ASD) Metodología iterativa, orientada a los componentes software más que a las tareas y tolerante a los cambios. Su ciclo de vida consta de tres fases: especulación, en la que se inicia el proyecto y se planifican las características del software; colaboración, en la que se desarrollan las características; y aprendizaje, en la que se revisa su calidad y se entrega al cliente. 81 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 82 41

42 FEATURE-DRIVEN DEVELOPMENT (FDD) Metodología iterativa que consta de 5 pasos. Las iteraciones son cortas, centrándose en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software 83 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 84 42

43 LEAN DEVELOPMENT (LD) Los cambios se consideran riesgos, pero si se manejan adecuadamente se convierten en oportunidades que mejoren la productividad del cliente. Es necesario introducir un mecanismo que permita implementar dichos cambios 85 OTRAS METODOLOGÍAS ÁGILES extreme Programming Dynamic Systems Development Method Adaptive Software Development Feature-Driven Development Lean Development(LD) Kanban 86 43

44 KANBAN Metodología que ayuda a controlar de modo armónico la fabricación de productos en la cantidad y tiempo necesarios en cada uno de los procesos 87 KANBAN Divide el trabajo en bloques, se escribe cada elemento en una tarjeta/post-it y se coloca en una superficie visible (pizarra, pared, etc.) Utiliza columnas con nombre para indicar en que lugar del flujo de trabajo se encuentra cada elemento. Limita el Work in Progress (trabajo en curso). Asigna límites concretos a los elementos que están en progreso en cada estado del flujo de trabajo. Mide el lead time (tiempo de ciclo). Optimiza el proceso para que el tiempo de ciclo sea lo más pequeño y predecible posible

45 KANBAN PENDIENTE DESARROLLO PRUEBA ENTREGA FINALIZADO J G E D A K H F B L I C FLUJO 89 ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS ÁGILES 6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES 90 45

46 Criticality (defects cause loss of...) Different methodologies are possible & needed (project size, system criticality, priorities, fears) Life (L) Essential money (E) Discretionary money (D) Comfort (C) Prioritized for Legal Liability Prioritized for Productivity & Tolerance L6 L20 L40 L100 L200 L500 L1000 E6 E20 E40 E100 E200 E500 E1000 D6 D20 D40 D100 D200 D500 D1000 C6 C20 C40 C100 C200 C500 C ,000 Alistair Cockburn Number of people involved +20% Y QUE OCURRE CON LA DOCUMENTACIÓN? 92 46

47 DOCUMENTAR, DE MANERA ÁGIL, PERO DOCUMENTAR [ ] Frecuentemente escucho a los desarrolladores decir que no les gusta documentar, que no lo encuentran útil, pero No era el objetivo principal de documentar el ayudar a otros? Cómo es posible una visión tan distorsionada de la documentación? Agile Documentation, Anyone? por Bran Selic IEEE Software de noviembre (Diciembre, 2010) 93 DOCUMENTAR, DE MANERA ÁGIL, PERO DOCUMENTAR [ ] El propósito de la documentación es enseñar a quienes no están familiarizados con un sistema cómo este se estructura, funciona y los motivos que llevaron a decidirse por ese diseño. Los principales usuarios de la documentación de diseño son los futuros responsables del mantenimiento del sistema. La única alternativa a no tener documentación de diseño es explorar directamente el sistema, buscar un camino a través de una selva sin mapa ni brújula. Así, mientras que documentar tiene un coste, la inversión, si se hace correctamente, vale la pena [ ] Agile Documentation, Anyone? por Bran Selic IEEE Software de noviembre (Diciembre, 2010) 94 47

48

49 97 En la batalla Cuando preparo una batalla, encuentro que los planes son inútiles, pero la planificación es indispensable Dwight Eisenhower 98 49

50 QUÉ hacer? MODELO DE PROCESOS ISO CMMI- ACQ CMMI- DEV CMMI- SVC CÓMO hacerlo? METODOLOGÍAS Tradicionales Ágiles 50