SCRUM & XP MASTER CLASS

Transcripción

1 SCRUM & XP MASTER CLASS Miguel Jurado García SCRUM MANAGER CERTIFIED

2 2 SCRUM & XP Gestión de proyectos con Scrum Desarrollo Ágil con XP y TDD 04/11/2013

3 3 ÍNDICE SCRUM Introducción Metodología Ágil vs Predictiva o tradicional Elementos de Scrum: Artefactos Reuniones Roles Medición y gráficos TABLEROS KANBAN Elementos Ejemplos de Tableros

4 4 ÍNDICE SCRUM con XP Pair Programming Test Driven Development Diseño Incremental Integración Continua Estandarización del código Pruebas Refactorización

5 INTRODUCCIÓN Scrum es un marco (framework) para el desarrollo de productos complejos. 5 Las principales características de Scrum son: Ágil Fácil de entender Extremadamente difícil de llegar a implantar y dominar Scrum se basa en una continua inspección y adaptación en ciclos Iterativos e incrementales llamados Sprints que tienen una duración de entre 2 y 4 semanas. Tiene muchísima importancia la cohesión del equipo, ya que tanto el éxito como el fracaso es siempre compartido.

6 6 INTRODUCCIÓN Scrum está basado en estructura de time boxes delimitados. Las principales características de Scrum son: Ágil Fácil de entender Extremadamente difícil de llegar a implantar y dominar Scrum se basa en una continua inspección y adaptación en ciclos Iterativos e incrementales llamados Sprints. No se puede estar siempre sprintando, sino se acaba haciendo footing y no es el objetivo de esta metodología.

7 7 INTRODUCCIÓN El diagrama a alto nivel de scrum sería algo como la siguiente figura: En cuanto a la definición de iterativo e incremental, recordad que scrum siempre trata con productos finales acabados. Ejemplo retrato de la Gioconda: Válido con Scrum No válido con Scrum

8 8 En cuanto a la gestión ágil de proyectos: No es una gestión de anticipación (requisitos, diseño, planificación y seguimiento) sino de adaptación (visión, exploración y adaptación). La gestión ágil tiene como objetivos: valor del producto, reducción del tiempo de desarrollo, agilidad, flexibilidad y fiabilidad. La gestión ágil se basa en los principios del manifiesto ágil y centra el valor: Más en las personas y su interacción que en los procesos y las herramientas Más en los resultados que funcionan que en la documentación exhaustiva Más en la colaboración con el cliente que en la negociación contractual Más en la capacidad de respuesta al cambio que en el seguimiento de un plan El desarrollo ágil comprende cinco fases: Concepto, Especulación, Exploración, Revisión y Cierre.

9 METODOLOGÍA ÁGIL VS PREDICTIVA 9 No se trata de decantarse por una metodología sistemáticamente, sino que hay factores que determinan cual debemos utilizar. Las siguientes figuras muestran algunos de estos factores:

10 CONOCIMIENTO IMPLICITO VS TÁCITO O EXPLICITO 10 IMPLICITO: PRIMA EL PROCESO EXPLICITO: PRIMA LA PERSONA Qué animal es? Qué profesión tienen?

11 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 11

12 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 12

13 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 13

14 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 14

15 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 15 Y al final tanto una parte como la otra afirman que las Fases de un proyecto son: 1. Optimismo general 2. Fase de desorientación 3. Desconcierto general 4. Período de sarcasmo incontrolado 5. Búsqueda implacable de culpables 6. Sálvese quien pueda! 7. Castigo ejemplar a los inocentes 8. Recuperación del optimismo perdido 9. Final inexplicable del proyecto 10. Condecoración y felicitaciones a los no participantes A qué se debe tanta ironía?? Hagamos un replay.

16 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 16

17 EJEMPLO PROYECTO Y PROBLEMAS EN WATERFALL 17 Funcionalidades desarrolladas: 7% se usan siempre 13% se usan a menudo 16% a veces 19% pocas veces 45% NUNCA Fuente: Standish Group Dedicamos mucho esfuerzo a objetivos que aportan poco valor. Dinero y tiempo tirados a la basura. Quién paga esto? Dedicamos mucho esfuerzo a actividades cuyo enfoque es arriesgado Obligamos al cliente a especificar todo lo que se le ocurra, dado que es su última oportunidad antes de firmar el funcional. Y todo parece igual de importante!!!

18 FACTORES A TENER EN CUENTA PARA CAMBIAR A ÁGIL 18 DESARROLLA EN PARTES PEQUEÑAS y completas de PRODUCTO FINAL, limita la complejidad que manejas. Para potenciar el aprendizaje en tiempos cortos, DEMUESTRA cada parte al cliente, REFLEXIONA sobre qué has obtenido y cómo lo has obtenido. Proporciona FLEXIBILIDAD a tu cliente.

19 CAMBIO A AGILE 19

20 COMPARATIVA AMBAS METODOLOGÍAS 20

21 ORGANIZACIÓN Y CLASIFICACIÓN DE METODOLOGÍAS 21 Para clasificar hay MODELOS (dicen QUÉ hay que hacer) y PRÁCTICAS (dicen CÓMO se debe hacer). Unos trabajan con conocimiento explícito (PROCESOS) y otros con conocimiento tácito (RUTINAS) En ambos casos los hay: Enfocados en una de las áreas claves de la organización (proyecto, proyecto o gerencia). De ámbito global que cubren las tres áreas claves de la organización.

22 ORGANIZACIÓN Y CLASIFICACIÓN DE METODOLOGÍAS 22

23 ORGANIZACIÓN Y CLASIFICACIÓN DE METODOLOGÍAS 23

24 24 ELEMENTOS DE SCRUM Artefactos Reuniones Roles Medición y gráficos

25 ELEMENTOS DE SCRUM :ARTEFACTOS 25 Pila del producto: (product backlog) lista de requisitos de usuario que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo. Se compone de User Stories. Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto. Es una porción de la pila del producto. Incremento: Resultado de cada sprint. Es una parte del producto completamente terminada y operativa. No se deben considerar como incrementos: prototipos, módulos o subrutinas pendientes de pruebas o de integración, desarrollos parciales.

26 ELEMENTOS DE SCRUM: REUNIONES Planificación del sprint (Sprint Plan): Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben conseguir en la iteración. 26 Seguimiento del sprint (Scrum Daily): Breve revisión diaria, en la que cada miembro describe tres cuestiones: 1.- El trabajo que realizó el día anterior. 2.- El que tiene previsto realizar. 3.- Cosas que puede necesitar o impedimentos que deben suprimirse para realizar el trabajo. Cada persona actualiza en la pila del sprint el tiempo pendiente de sus tareas, y con esta información se actualiza también el gráfico con el que el equipo monitoriza el avance del sprint (burn-down) Revisión del sprint (Sprint Review): Análisis y revisión del incremento generado. (Demo del avance) Retrospectiva del sprint (Sprint Retrospective): Análisis y autocrítica de los errores cometidos (no bugs sino de concepto o actuación) o acciones realizadas.

27 TIME BOX DE REUNIONES 27 Lo que marca la duración de las reuniones es la duración del Sprint, excepto la daily que siempre tiene un tope de 15 minutos. Planificación del sprint (Sprint Plan): Tiene dos partes. El SP1 de 1 a 4 horas (1h. Por semana de sprint) para planificar y decidir las user stories del product backlog que van a pasar al sprint backlog. El SP2 de 1 a 4 horas (1h. Por semana de sprint) se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo para cada una, y asignarlas a las personas del equipo. Seguimiento del sprint (Scrum Daily): Breve revisión diaria de tiempo máximo 15 minutos, se recomienda hacerla de pie junto el tablero de tareas. cada miembro describe tres cuestiones: 1.- El trabajo que realizó el día anterior. 2.- El que tiene previsto realizar. 3.- Cosas que puede necesitar o impedimentos que deben suprimirse para realizar el trabajo. Cada persona actualiza en la pila del sprint el tiempo pendiente de sus tareas, y con esta información se actualiza también el gráfico con el que el equipo monitoriza el avance del sprint (burn-down) Revisión del sprint (Sprint Review): Análisis y revisión del incremento generado. (Demo del avance). Duración máxima 4 horas. Retrospectiva del sprint (Sprint Retrospective): Análisis y autocrítica de los errores cometidos (no bugs sino de concepto o actuación) o acciones realizadas. Duración máxima 3 horas.

28 28 ELEMENTOS DE SCRUM: ROLES Roles Comprometidos: Propietario del producto: es la persona responsable de lograr el mayor valor de producto para los clientes, usuarios y resto de implicados. Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto. Scrum Master: Responsable del funcionamiento de la metodología Scrum en la organización. Roles Implicados: Otros interesados (Dirección general Dirección comercial Marketing Usuarios, etc)

29 RESPONSABILIDADES DE LOS ROLES 29

30 RESPONSABILIDADES DE LOS ROLES :PRODUCT OWNER 30 El propietario del producto o product owner es la persona que toma las decisiones del cliente. Para simplificar la comunicación y toma de decisiones es necesario que las responsabilidades de gestión del producto las asuma una única persona. Si se trata de organizaciones cliente grandes o con varios departamentos, éstas pueden tener la forma de comunicación interna que consideren oportuna, pero en el equipo de desarrollo sólo se integra una persona representando al cliente, y ésta debe tener el conocimiento suficiente del producto y las atribuciones necesarias para tomar las decisiones que le corresponden. Para ejercer este rol es necesario: Conocer perfectamente el entorno de negocio del cliente, las necesidades y el objetivo que se persigue con el sistema que se está construyendo. Tener atribuciones suficientes para tomar las decisiones necesarias durante el proyecto. Conocer Scrum para realizar con solvencia las tareas que le corresponden: Desarrollo y administración de la pila del producto Presentación y participación en la reunión de planificación de cada sprint. Recibir y analizar de forma continua retro-información del negocio (evolución del mercado, competencia, alternativas ) y del proyecto (sugerencias del equipo, alternativas técnicas, pruebas y evaluación de cada incremento ). Es recomendable conocer y haber trabajado previamente con el mismo equipo. Es quien decide en última instancia cómo será el resultado final, y el orden en el que se van construyendo los sucesivos incrementos: qué se pone y qué se quita de la pila del producto, y cuál es la prioridad de las funcionalidades. Es responsable de la financiación del proyecto, y las decisiones sobre fechas y funcionalidades de las diferentes versiones del producto, y el retorno de la inversión del proyecto. En los desarrollos internos para la propia empresa, suele asumir este rol el product manager o el responsable de marketing. En desarrollos para clientes externos: el responsable del proceso de adquisición del cliente.

31 RESPONSABILIDADES DE LOS ROLES: EQUIPO DE DESARROLLO Se recomienda un tamaño de equipo entre 4 y 8 personas. Scrum.org cita 7 ± 2. Más allá de 8 resulta más difícil mantener la agilidad en la comunicación directa, y se manifiestan con más intensidad las rigideces habituales de la dinámica de grupos (que comienzan a aparecer a partir de 6 personas). No se trata de un grupo de trabajo formado por un arquitecto, diseñador o analista, programadores, pruebas Es un equipo multidisciplinario, en el que todos trabajan de forma conjunta para realizar cada sprint.(lo más cross-functional posible) Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre grupo de trabajo y equipo. Un grupo de trabajo es un conjunto de personas que realizan un trabajo, con una asignación específica de tareas, responsabilidades y siguien-do un proceso o pautas de ejecución. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde por su trabajo. El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente. Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y auto-organizada. No hay un gestor que delimita, asigna y coordina las tareas. Son los propios componentes del equipo los que lo realizan. En el equipo: Todos conocen y comprenden la visión del propietario del producto. Aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto. Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro. Todos los miembros participan en las decisiones. Se respetan las opiniones y aportaciones de todos Todos conocen el modelo de trabajo con Scrum. Hay un responsable o líder del equipo que asume las responsabilidades de garantía de funcionamiento del campo de Scrum en el proyecto. En las fases de implementación de Scrum, con equipos sin demasiada experiencia en desarrollo ágil con Scrum, y en organizaciones con demasiada rotación de personas de los equipos entre proyectos, es recomendable la figura de un gestor de Scrum o Scrum Manager para asumir estas responsabilidades. 31

32 RESPONSABILIDADES DE LOS ROLES: SCRUM MASTER 32 Es el responsable del funcionamiento de Scrum en el proyecto, cubriendo los aspectos siguientes que la organización necesite según el cono-cimiento, experiencia con el modelo o aquellos que no cubra con otras personas con la formación e idoneidad adecuada. Asesoría y formación al Propietario del pro-ducto. Asesoría y formación al equipo. Revisión y validación de la pila del producto. Moderación de las reuniones. Resolución de impedimentos que en el sprint pueden entorpecer la ejecución de las tareas. Gestión de la dinámica de grupo en el equipo Respeto de la organización y los implicados, con las pautas de tiempos y formas de Scrum Configuración, diseño y mejora continua de las prácticas de Scrum en la organización. Lo más habitual es que la garantía de funcionamiento de Scrum en el proyecto se asigne: Al rol de un Team Leader, en equipos experimentados en trabajo ágil, en organizaciones que tienen ya una cierta experiencia con agilildad. A un puesto específico para contar con esta garantía (Gestor de Scrum o Scrum Master), en equipos y organizaciones en fases tempranas de implementación de Scrum, sin experiencia previa en desarrollo ágil.

33 DISTRIBUCIÓN DEL PERSONAL SEGÚN ROL 33 Hazlo como puedas pero sienta al equipo JUNTO

34 34

35 35 ELEMENTOS DE SCRUM: GRÁFICOS Gráfico de producto (burn-up). Es una herramienta de planificación y seguimiento del propietario del producto, que muestra de un vistazo, en un gráfico muy simple el plan general de desarrollo del producto, y la traza de su evolución. Se confecciona con: La estimación del esfuerzo prevista en la pila del producto. La velocidad del equipo. Es un diagrama cartesiano que representa en el eje de ordenadas el trabajo estimado para desarrollar el producto, y en el de abcisas las fechas, medidas según las duraciones previstas para los sprints.

36 36 ELEMENTOS DE SCRUM: GRÁFICOS Gráfico de avance: monitorización del sprint (burn-down). Es el gráfico que actualiza el equipo en las reuniones de seguimiento del sprint, para comprobar el ritmo de avance, y detectar desde el primer momento si es el previsto, o se puede ver comprometida la entrega prevista al final de sprint. La estrategia ágil para el seguimiento de los proyectos se basa en: Medir el esfuerzo que falta, no el realizado. Seguimiento muy cercano (diario de ser posible). Y en este gráfico toman forma los dos principios: En el eje Y se registra el trabajo que aún falta por realizar. Se actualiza a diario.

37 MÉTRICAS 37 A modo de resumen, este es el conjunto de métricas que recomiendo se utilicen en al comienzo de una implementación: Encuestas de satisfacción de equipo y clientes Gráfico de velocidad Gráficos de burndown Número de tests automatizados Deuda técnica Trabajo en proceso Tiempo promedio de finalización de historias Bugs por sprint Una vez que ya has sido capaz de poner algún tipo de medida concreta al valor de negocios, agrega las siguientes: Coste por sprint o punto de historia Verdadero valor entregado Retorno de Inversión (ROI)

38 TABLEROS KANBAN 38 Kanban es una técnica de control visual. Es un sistema de señalización para desencadenar acciones. El término japonés Kanban se puede traducir por tablero, o tarjeta de señalización

39 39 TABLEROS KANBAN Favorece la comunicación directa Detección temprana de problemas Contribuye a una cultura de colaboración y resolución Monitorización y regulación del flujo, y la carga de trabajo Genera un flujo de trabajo que lleva los problemas a la superficie Produce un ritmo sostenido y evita la ley de Parkinson El trabajo se expande hasta llenar el tiempo disponible para que se termine (Ley de Parkinson)

40 TABLERO KANBAN PROPUESTO 40

41 EJEMPLOS TARJETAS USER STORIES 41

42 42

43 EXTREME PROGRAMMING 43 PLANNING GAME: Release planning Exploration - user stories, prioridades del cliente. Commitment - alcance de la release. Steering - ajustes del plan; agregar/quitar requerimientos. Iteration planning Exploration - user stories / task cards. Commitment - asignación de tareas a miembros del equipo, estimación. Steering - iteración de trabajo y contraste con user stories.

44 44 SCRUM Y XP: PAIR PROGRAMMING Dos miembros del equipo trabajando en una misma máquina: Uno se ocupa de los detalles del código en sí, tiene el control de la máquina. El otro mantiene la mirada en el contexto, revisa el código, sugiere cambios, etc. Los roles deben ir cambiando sucesivamente en una misma iteración. Además, los pares deben trabajar en distintos problemas dentro de la misma iteración, incluso armando y desarmando pares De esta forma pasamos a un Ownership de código colectivo.

45 SCRUM Y XP: TEST DRIVEN DEVELOPMENT 45 La esencia de TDD es sencilla pero ponerla en práctica correctamente es cuestión de entrenamiento, como tantas otras cosas. El algoritmo TDD sólo consta de tres pasos: Escribir la especificación del requisito (el ejemplo, el test). Implementar el código según dicho ejemplo. Refactorizar para eliminar duplicidad y hacer mejoras. Con esto lo que logramos es: Enunciar claramente un comportamiento lo más simple y pequeño posible del story que se está implementando. Escribir un test que lo valide. Lanzar todos los tests que tenemos al momento: el nuevo falla. Escribir el código más simple que haga pasar el test. Correr los tests nuevamente: todos pasan. Refactorizo + retesteo. Repetir

46 TEST DRIVEN DEVELOPEMENT 46 En resumen: Desarrollo guiado por pruebas significa que escribes un test automático y, a continuación, escribes el código suficiente para pasar dicho test y después refactorizas el código, principalmente para mejorar la legibilidad y eliminar duplicaciones. Aclarar y repetir. Observaciones: TDD es duro. Los programadores tardan un tiempo en pillarlo. De hecho, en muchos casos no importa cuanto lo expliques, lo demuestres y los animes: en muchos casos la única forma de que un programador lo pille es emparejarlo con otro programador que sea bueno en TDD. Una vez que un programador lo pilla, sin embargo, normalmente será infectado severamente y nunca más querrá trabajar de otra forma. TDD tiene un efecto profundamente positivo en del diseño del sistema. Se tarda un tiempo en conseguir que TDD funcionar en un nuevo producto, especialmente con pruebas de integración tipo caja negra, pero el retorno de la inversión paga con creces esa inversión. Herramientas típicas: junit / httpunit / jwebunit, TestNG, Selenium, Team Foundation, Cobertura para las métricas, etc.

47 SCRUM Y XP: DISEÑO INCREMENTAL 47 Diseño Incremental es el mismo concepto que hemos expuesto con scrum, significa mantener el diseño simple desde el principio y mejorarlo continuamente, en lugar de conseguir que todo funcione desde el principio y entonces congelarlo. La mejora continua del diseño es sobre todo un efecto secundario automático de hacer TDD.

48 SCRUM Y XP: INTEGRACIÓN CONTINUA 48 Son herramientas que facilitan a los miembros de un equipo de desarrollo de software integrar su trabajo individual, frecuentemente, de manera que puedan realizarse pruebas y verificaciones del sistema completo (habitualmente de manera automatizada) permitiendo detectar errores de integración en etapas tempranas, reduciendo de este modo los problemas y logrando desarrollar un software bien cohesionado desde el principio. Buenas prácticas: Actualizar de manera frecuente el repositorio Mantener un proceso de construcción rápido. Esto se suele obtener en dos fases: Fase de construcción y tests unitarios automáticos cada vez que cambia el repositorio Fase de ejecución de tareas secundarias (ejecución de pruebas de integración y aceptación automátizadas, generación de documentación, despliegues en entornos de pruebas, revisiones de código, informes de cobertura de tests unitarios,.) Notificar convenientemente los resultados: recibir notificaciones con información sobre los resultados de los procesos de construcción (especialmente cuando hay errores) tanto los desarrolladores como otros interesados (gestores, usuarios, clientes, ) Ejemplos de herramientas para este propósito: Ant, Maven, Hudson/Jenkins, Bamboo, SVN, TFS, GIT

49 SCRUM Y XP: ESTANDARIZACIÓN DEL CÓDIGO 49 La mayoría de programadores tiene su propio estilo y por tanto sus propias convenciones, no obstante se puede encontrar puntos comunes y redactar unos estándares para hacer el código más legible para todos. He aquí algunos ejemplos de nuestro estándar de código: Puedes romper estas reglas, pero asegúrate de que hay una buena razón para ello y documéntala. Usa las convenciones de código dotnet por defecto: Usa las convenciones de código de Sun por defecto: Nunca captures excepciones sin registrar la traza de la pila (stack trace) o relanzar. log.debug() Utiliza inyección de dependencias basada en métodos set para escindir unas clases de otras y eliminar dependencias (excepto, por supuesto, cuando una herencia o acomplamiento estricto de clases es deseable) Evita usar abreviaturas. Abreviaturas muy conocidas como DAO son admisibles. Los métodos que devuelven colecciones o vectores no deberían devolver null. Es mejor devolver colecciones o vectores vacíos.

50 SCRUM Y XP: PRUEBAS 50 En el mundo Scrum ideal, un Sprint produce una versión potencialmente instalable de nuestro sistema. En la realidad no siempre es así, con lo que no tiene que generarse obligatoriamente una release por cada sprint.

51 51 TAREAS A REALIZAR EN EL SPRINT PARA PRUEBAS Montar un entorno de pruebas. Clarificar requisitos. Discutir los detalles de instalación con operaciones. Escribir documentos de instalación (notas de versión, RFC s, ). Contactar con recursos externos (diseñadores de interfaz de usuario, por ejemplo) Mejorar los scripts de compilación Identificar las preguntas clave de los desarrolladores y conseguir respuestas.

52 No profundizaremos ya que se explicaron muy en detalle en la master class de QA. 52

53 53 SCRUM Y XP: REFACTORIZACIÓN La refactorización es una técnica que permite reestructurar, de manera disciplinada, el código existente de un componente o de un Sistema de Información. Su uso permite modificar la estructura interna sin modificar el interfaz a partir de un conjunto de pequeñas transformaciones que preservan el comportamiento (pequeñas para minimizar riesgos) Tras refactorizar el Sistema de Información deberá seguir manteniéndose completamente funcional. Por tanto es un proceso de mantenimiento de un Sistema de Información cuyo objetivo no es ni arreglar errores ni añadir nueva funcionalidad, si no mejorar la comprensión del código. El diario de deuda técnica ayuda a refactorizar

54 54 REFACTORIZACIONES BÁSICAS Actualmente muchas herramientas automatizan la refactorización. Entre el conjunto de las refactorizaciones básicas ofrecidas por estos entornos es habitual encontrarse, al menos, las siguientes: Renombrar una clase o un método Mover una clase Cambiar el número, orden y tipo de los argumentos de un método Extraer un método del código de otro Extraer una constante Extraer una clase o mover métodos a otra clase Generar un interface a partir de una clase

55 55 REFACTORIZACIONES AVANZADAS Ciertos casos no tan obvios de refactorización como los que podéis encontrar en Destaco las siguientes: Descomponer un condicional Consolidar una expresión condicional Introducir variables explicativas Eliminar dobles negaciones Introducir extensiones locales Introducir objetos nulos

56 56 REFACTORIZACIONES A LA CARTA Además del uso de aquellas refactorizaciones más extendidas en la industria del desarrollo de Software, los desarrolladores pueden/deben diseñar o adaptarlas en función de las necesidades que tengan en un momento concreto. Ejemplo: Reemplazar condicional por factoría de estrategias. Trata de cambiar un condicional complejo por diferentes clases para cada rama del condicional.

57 Preguntas? 57

58 58

59 59 BIBLIOGRAFÍA UTILIZADA Manual de certificación oficial de Gestión de proyectos de la Scrum Manager A better Scrum 2 Manifiesto for Agile Software Development Distributted Scrum Agile vs Predictive Kanban and Scrum (The best of both worlds) Excelencia del código (Manual de la Scrum Manager) Scrum and XP from the trenches 7th Annual State of Agile Developement Survey Y las encuestas publicadas de Standish Group