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

Transcripción

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

2 Contenidos Definiciones de Desarrollo Ágil Dos ejemplos de Enfoques Ágiles: extreme Programming Scrum

3 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.

4 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. Fomentar mentalidad de equipo.

5 Definición de Desarrollo Ágil 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 agilemanifesto.org

6 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.

7 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.

8 Adaptando UP al Desarrollo Ágil Minimizar los Artefactos Intermedios 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.

9 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. Procesos Personas Calidad Tecnologías

10 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 Fuente: Mary Poppendieck. Lean Development & the Predictability Paradox 2003 Poppendieck LCC

11 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.

12 Procesos de Desarrollo Ágil EXTREME PROGRAMMING Algunas referencias de material de Rosa Alarcón 2009

13 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, refactoring frecuente, estándares de codificación.

14 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.

15 5 VALORES 1. Comunicación Diseño simple, uso de metáforas, colaboración usuarioprogramador, 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

16 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. 5. Integración continua. 6. Mejora de diseño (refactoring). 7. Releases pequeños. Entendimiento común. 8. Diseño simple. 9. Metáfora de sistema. 10.Propiedad colectiva del código. 11.Estándares de codificación o convenciones. Salud del programador. 12.Ritmo sostenible (semana de 40 hrs.).

17 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.

18 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: - Test: -

19 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.

20 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.

21 Historia de XP (Título descriptivo de la historia) (Nº ID) (Descripción breve y concisa de la historia en dos o tres párrafos describiendo propósito, entrada, salida y efectos principales) CLIENTE DESARROLLADOR (Estimación Esfuerzo)

22 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. Deben ser independientes unas de otras.

23 Historia y Tareas Desarrollo - Ejemplo Ingresar Datos del Documento H 09 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. 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 5 días

24 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.) TAREAS (TASKS) CRC CARDS HISTORIA 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.

25 Levantamiento de Req. en XP Iteration Plan Story Estimated Iteration Release ,5 2 (4) Ordenar según prioridad , , (5) Planificar (1) Describir historias (2) Definir/descomponer c/historia en tareas técnicas (3) Estimar esfuerzo

26 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). Otros: Consultor (consultor técnico, coach).

27 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, testdriven 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.

28 Procesos de Desarrollo SCRUM Algunas referencias de material de Rosa Alarcón 2009

29 Scrum Workflow

30 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. Demo al cliente al final del Sprint

31 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 hablan.

32 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: - Test: -

33 Product Backlog (1) 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. A este nivel puede ser prioridad: alta/media/baja 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...

34 Product Backlog (2) 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). 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

35 Product Backlog (3) 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 siguiente. Descripción Prioridad Esfuerzo Iter 1 Iter 2 Llenar formulario de datos de cotización Modificar datos de cotización Consulta/Búsqueda de cotizaciones por cliente y por fecha

36 Sprint Backlog 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. Incluye asignación de tareas con nombre. Descripción Origen Responsable Estado Iter 1 Iter 2 Iter 3 Crear BD Pedro Pedro Terminada Crear Tablas Modelo 1 Pedro Jorge Terminada Instalar servidor Web y configurar seguridad José José En progreso Implementar Stored Proc para Cotizaciones Pedro Jorge No iniciada

37 MÉTRICAS SPRINT BACKLOG

38 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.

39 COMPARACIÓN CON OTROS PROCESOS

40 Procesos de Desarrollo Proceso Fortalezas Prioridades Situaciones Serial (Cascada) Iterativo (Espiral) Incremental (RUP) Iterativo- Incremental (Ágil) Ad-hoc (Code & Fix) Administra riesgo de costo. Solidez diseño y arquitectura. Administra riesgo técnico. Administra riesgo de calendario Absorbe cambios en reqs. Administra riesgo técnico y de calendario Requiere un equipo bien afiatado. 1) Funcionalidades 2) Poco defecto 3) Tiempo x release 1) Funcionalidades 2) Poco defecto 3) Tiempo x release 1) Tiempo x release 2) Poco defecto 3) Funcionalidades 1) Tiempo x release 2) Funcionalidades 3) Poco defecto 1) Tiempo x release 2) Funcionalidades 3) Poco defecto Software embebido en hardware o para controlar un dispositivo crítico. Requisitos estables, alta calidad. Productos o ideas nuevas que requieren refinarse antes del desarrollo. La mayoría de los proyectos, como nuevas versiones de productos, necesidad de flexibilidad y compromisos de tiempo. Productos nuevos. Requisitos inestables. Necesidad de experimentación y tiempo limitado. Experimentos. Nada crítico.