• Save
Manual01
Upcoming SlideShare
Loading in...5
×
 

Manual01

on

  • 4,851 views

 

Statistics

Views

Total Views
4,851
Views on SlideShare
4,065
Embed Views
786

Actions

Likes
6
Downloads
0
Comments
0

10 Embeds 786

http://aegxxi-desarrollo.blogspot.com 528
http://aegxxi-desarrollo.blogspot.com.es 107
http://aegxxi-desarrollo.blogspot.com.ar 74
http://aegxxi-desarrollo.blogspot.mx 57
http://www.slideshare.net 10
http://aegxxi-desarrollo.blogspot.de 4
http://aegxxi-desarrollo.blogspot.com.br 3
https://www.mturk.com 1
http://static.slidesharecdn.com 1
http://aegxxi-desarrollo.blogspot.it 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Manual01 Manual01 Presentation Transcript

  • Métodos ágiles-Scrum y XP Object-Oriented Technology Training Dr. Ricardo R. Quintero Meza
  • 1 Métodos Ágiles-Scrum y XP El Desarrollo Iterativo y Evolutivo: Scrum y XP Tema 1: Iterativo y Evolutivo (Dr. Ricardo Quintero) 1 Repositorio en línea de Material Adicional  http://tinyurl.com/cursoagil 2 Dr. Ricardo Quintero 1
  • 2 Métodos Ágiles-Scrum y XP Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 3 Desarrollo y construcción “predecible” Al construir un teléfono celular es posible definir, sin ambigüedades, sus especificaciones y pasos de construcción. Después de alguna experiencia en la construcción de teléfonos es posible hacer estimaciones confiables de costo y tiempo de futuros teléfonos a construir. 4 Dr. Ricardo Quintero 2
  • 3 Métodos Ágiles-Scrum y XP Desarrollo y construcción “no predecible” Suponga una persona que desea construir una casa “a la medida”. Se quieren utilizar materiales y métodos ecológicos, pero no se está seguro al 100% de lo que se desea. Cambia o clarifica sus decisiones conforme pasa el tiempo al ver la casa y sus costos. 5 Desarrollar Software es “Desarrollar nuevos productos” + Predictibilidad de proyectos - Desarrollo de nuevos Manufactura en masa o productos o proyectos con Manufactura predecible: alto nivel de inventiva: Niveles bajos de cambio o Alto grado de novedad, novedad con altos niveles de creatividad y cambio sin creación idéntica o casi experiencia previa de idéntica casos idénticos a partir de los cuales estimar o derivar planes confiables 6 Dr. Ricardo Quintero 3
  • 4 Métodos Ágiles-Scrum y XP Proyectos predecibles y no predecibles P. Predecibles P. No predecibles Al principio es posible definir sus Raramente es posible crear una especificaciones y después especificación detallada y no construir cambiante Al inicio, se puede estimar de forma Al principio no es posible. Conforme confiable el esfuerzo y el costo van surgiendo datos empíricos, incrementalmente va siendo posible planear y estimar Es posible identificar, definir, Al principio, no es posible. Se calendarizar y establecer requieren pasos adaptativos detalladamente el orden de todas conducidos por ciclos construir- las actividades retroalimentar La adaptación al cambio no La adaptación creativa para los predecible no es la norma y la cambios no previstos es la norma. razón de cambio es relativamente La razón de cambio es alta. baja 7 ¿En que categoría cae el software? Desarrollar software no es un problema de manufactura en masa o predecible. El desarrollo de software cae en la categoría de desarrollo de un producto nuevo. 8 Dr. Ricardo Quintero 4
  • 5 Métodos Ágiles-Scrum y XP Si esto no convence … Muchos proyectos utilizan tecnologías nuevas (y no sencillas) que incrementan el grado de novedad y no predictibilidad. Estas tecnologías llevan a un inexperto a situaciones semejantes a las de la construcción de un nuevo producto, aún cuando tenga experiencia previa 9 Por lo tanto …  Debido a que el paradigma de manufactura predecible es el incorrecto para desarrollar software entonces … Las prácticas y valores que tienen sus raíces en el mismo no resultan útiles. 10 Dr. Ricardo Quintero 5
  • 6 Métodos Ágiles-Scrum y XP Considere el “enfoque de cascada”  Especificación predictiva de las especificaciones.  Estimaciones y planes especulativos aplicables a la manufactura predecible, incorrectamente se han aplicado a los proyectos de software, un dominio que requiere trabajo inventivo, de alta razón de cambio y novedad. 11 Ejercicio: ¿Por qué estimaciones predictivas fallan?  Usando el artículo de Parnas y Clemens (1986) realice el ejercicio ¿Porqué las estimaciones predictivas fallan? 12 Dr. Ricardo Quintero 6
  • 7 Métodos Ágiles-Scrum y XP ¿Por qué las estimaciones predictivas fallan?  Parnas y Clemens (1986) nos dan razones:  Los clientes o usuarios suelen no estar seguros (de forma precisa) lo que quieren.  Les resulta difícil establecer todo lo que quieren y desean.  Muchos de los detalles de lo que realmente quieren solamente se revela al momento del desarrollo. 13 ¿Por qué estas estimaciones predictivas de estimación fallan?  (cont..)Parnas y Clemens (1986) nos dan razones:  Para las personas los detalles son abrumadoramente complejos.  Conforme van viendo el producto desarrollado, van cambiando su mente (lo que desean).  Factores externos (como el producto de un competidor o servicio) dirigen los cambios o extensiones en las solicitudes. 14 Dr. Ricardo Quintero 7
  • 8 Métodos Ágiles-Scrum y XP La motivación de los métodos ágiles  La motivación principal para los métodos ágiles e iterativos subyace en la apreciación de que: La actividad de construir software es compleja, con alto nivel de cambio y con naturaleza no predecible 15 Pero también son motivados por el deseo de competir y ganar  Los métodos ágiles e iterativos impulsan flexibilidad y maniobrabilidad: ventajas competitivas. 16 Dr. Ricardo Quintero 8
  • 9 Métodos Ágiles-Scrum y XP Pero también son motivados por el deseo de competir y ganar  Goldman y Preiss en su libro Agile competitors and Virtual Organizations: Strategies for Enriching the Customer nos enseñan: “Agilidad es acerca de éxito y triunfo: éxito en salir triunfante en las arenas competitivas; triunfo en predicciones y clientes, en el centro de las tormentas competitivas que muchas empresas actuales enfrentan” 17 Recursos Web  www.agilealliance.com  www.cetus-links.org  www.bradapp.net  alistair.cockburn.us  www.martinfowler.com 18 Dr. Ricardo Quintero 9
  • 10 Métodos Ágiles-Scrum y XP Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 19 Desarrollo iterativo  Los métodos ágiles son un subconjunto de los métodos iterativos y evolutivos.  Es un enfoque para construir software (o cualquier cosa) en el cual el ciclo de vida se compone por varias iteraciones en secuencia.  Cada iteración es un mini-proyecto auto-contenido compuesto por actividades como análisis de requisitos, diseño, programación y pruebas. 20 Dr. Ricardo Quintero 10
  • 11 Métodos Ágiles-Scrum y XP Desarrollo iterativo  El objetivo final de una iteración es obtener un release de iteración: un sistema parcial estable, integrado y probado.  Es decir: Todo el software a través de todos los equipos de desarrollo se integra en un release en cada iteración.  Los release pueden ser internos (para el equipo de desarrollo) o externos (para el cliente). 21 Desarrollo iterativo e incremental (IID) La retroalimentación (feedback) de la iteración N dirige el refinamiento y adaptación de los requisitos y el diseño en la iteración N+1 feedback feedback Se construye para Se construye para Se construye para algunos requisitos algunos requisitos algunos requisitos El Sistema crece Una iteración de 3 incrementalmente RELEASE AL semanas CLIENTE 22 Dr. Ricardo Quintero 11
  • 12 Métodos Ágiles-Scrum y XP Longitud de las iteraciones  Muchos proyectos tienen al menos tres iteraciones antes de un release público final.  En los métodos modernos: La longitud recomendada de una iteración oscila entre 1 y 6 semanas. 23 Disciplinas a través de las iteraciones 24 Dr. Ricardo Quintero 12
  • 13 Métodos Ágiles-Scrum y XP Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 25 Planeación iterativa dirigida por el cliente y por el riesgo  ¿Qué hacer en cada iteración?  Los métodos IID promueven una combinación de prioridades dirigida por el cliente y por los riesgos. 26 Dr. Ricardo Quintero 13
  • 14 Métodos Ágiles-Scrum y XP Planeación iterativa dirigida por el cliente y por el riesgo  Desarrollo iterativo dirigido por los riesgos:  Seleccione los elementos más riesgosos y difíciles para las primeras iteraciones.  Ej.- Un cliente podría decir: “Deseo que las páginas Web sean en color verde y que el sistema maneje 5,000 transacciones simultáneas” El color verde puede esperar por tanto se buscaría resolver primero el volumen de transacciones 27 Planeación iterativa dirigida por el cliente y por el riesgo  Desarrollo iterativo dirigido por el cliente:  La elección de características para cada iteración debe venir del cliente –cualquiera que sea lo que él considera de mayor valor.  De esta forma el cliente conduce el proyecto, iteración por iteración, solicitando las características que en ese momento considera de mayor valor para el negocio. 28 Dr. Ricardo Quintero 14
  • 15 Métodos Ágiles-Scrum y XP Planeación iterativa dirigida por el cliente y por el riesgo  Desarrollo iterativo dirigido por el cliente (cont…):  De esta forma el cliente adaptativamente planea la selección para la siguiente iteración, brevemente antes de iniciarla, basado en la experiencia adquirida en la iteración previa, más que de forma especulativa al inicio del proyecto.  Conforme nueva información va surgiendo el cliente va percibiendo control y capacidad de decisión. 29 Planeación iterativa dirigida por el cliente y por el riesgo  Aplique ambas técnicas…  Porque:  Los clientes no siempre son capaces de percibir lo que técnicamente es más difícil o riesgoso.  Los desarrolladores no siempre aprecian lo que es de más alto valor para el negocio. 30 Dr. Ricardo Quintero 15
  • 16 Métodos Ágiles-Scrum y XP Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 31 Ejercicio-El principio de Timeboxing  Lea el artículo Time boxing for top team performance.  Resuelva el ejercicio El principio de Timeboxing. 32 Dr. Ricardo Quintero 16
  • 17 Métodos Ágiles-Scrum y XP El principio de TimeBoxing  Timeboxing:  Es la práctica de mantener fija la fecha final de la iteración y no permitir cambios.  Este principio debería aplicar también para la fecha final de todo el proyecto.  Si eventualmente sucediera que las solicitudes hechas (alcance) para una iteración no pueden satisfacerse dentro del timebox, entonces en lugar de cambiar la fecha final, el alcance se reduce (colocando las prioridades de más bajo riesgo al final de la lista de “deseos”). 33 El principio de TimeBoxing  Esto con el fin de que se obtenga un sistema parcial (pero creciente) en un estado estable y probado. Es importante que el Timeboxing no se utilice para presionar a los desarrolladores para que trabajen largas horas para cumplir con la inminente fecha de terminación. Si el paso normal de trabajo es insuficiente, haga menos. 34 Dr. Ricardo Quintero 17
  • 18 Métodos Ágiles-Scrum y XP Longitud del TimeBox  No todos los Time-box necesitan ser iguales:  La primer iteración puede ser 4 semanas.  La segunda iteración 3 semanas, etc.  Como ya mencionamos la longitud recomendada es: 1 a 6 semanas. 35 Longitud del TimeBox  Se ha demostrado que Pasos cortos poseen:  Menor complejidad.  Menor riesgo.  Mejor retroalimentación.  Más alta productividad.  Mayor razón de éxito.  Todos los métodos modernos (incluyendo Scrum o XP o UP) requieren o recomiendan aplicar Timeboxing a las iteraciones. 36 Dr. Ricardo Quintero 18
  • 19 Métodos Ágiles-Scrum y XP TimeBoxing Construye para feedback Construye para En Timeboxing, algunos requisitos algunos requisitos la variable tiempo en cada iteración se mantiene fija 1 iteración de 3 semanas 1 iteración de 2 semanas “timeboxed”. La fecha final no “timeboxed”. La fecha final no se cambia. se cambia. Alcance (tareas) Tiempo Tiempo, alcance, recursos y calidad son las 4 variables comunes con las que se puede jugar en un Proyecto proyecto. Timeboxing remueve el tiempo de estas opciones durante una iteración Calidad Recurso ¡Recuerde el “Iron (gente) Triangle”! 37 Beneficios del Time-Boxing  Enfoque: El enfoque psicológico que promueve una fecha de terminación fija de 3 semanas es muy diferente al que promueve una de 3 meses. Time boxing es un antidoto a la Ley de Parkinson: “El trabajo se expande para ocupar todo el tiempo disponible”  Las personas recuerdan más fechas postergadas que características postergadas: es un capricho de la naturaleza humana. 38 Dr. Ricardo Quintero 19
  • 20 Métodos Ágiles-Scrum y XP Beneficios del Time-Boxing  Obliga a atacar niveles pequeños de complejidad: la investigación ha demostrado que pasos de complejidad baja se realizan más productivamente.  Obliga a tomar decisiones difíciles y de compensación tempranamente : se obliga a ser realista en lo que se hará y en lo que no se hará. Obliga al manejo de prioridades. 39 Durante la iteración, ningún cambio de los Stakeholder externos  Los métodos ágiles e iterativos enfrentan el cambio, pero no el caos.  Esto se logra con la siguiente regla: Una vez que se han determinado las solicitudes para una iteración y estas se están llevando a cabo, ningún stakeholder externo puede cambiar el trabajo. 40 Dr. Ricardo Quintero 20
  • 21 Métodos Ágiles-Scrum y XP Durante la iteración, ningún cambio de los Stakeholder externos  No se vale que el administrador del producto (por decir alguien) diga: “¿Pueden hacer esto también?” Deberá esperar a la siguiente iteración. Sin embargo, el equipo puede reducir el ámbito de la iteración si a la fecha final del timebox no se puede lograr. 41 Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 42 Dr. Ricardo Quintero 21
  • 22 Métodos Ágiles-Scrum y XP Desarrollo evolutivo y adaptativo  Desarrollo iterativo evolutivo:  Los requisitos, planes, estimaciones y soluciones evolucionan o se refinan en el transcurso de las iteraciones.  En lugar de ser completamente definidos o “congelados” en un esfuerzo mayúsculo de especificación antes de que el desarrollo iterativo empiece. Los métodos evolutivos son consistentes con el patrón de descubrimiento y cambio no predecible en el desarrollo de un nuevo producto. 43 Desarrollo evolutivo y adaptativo  Desarrollo adaptativo:  Es un término relacionado con evolutivo.  Implica que los elementos se adaptan en respuesta al “feedback” del trabajo anterior –”feedback” de usuarios, testers, desarrolladores, etc.  La intención es la misma que en el desarrollo evolutivo, pero el nombre sugiere un mecanismo más fuerte de repuesta-feedback en la evolución. 44 Dr. Ricardo Quintero 22
  • 23 Métodos Ágiles-Scrum y XP Análisis evolutivo de requisitos  En el desarrollo evolutivo y adaptativo no se trata de que los requisitos están “sin límite” o “cambiantes continuamente”.  Al contrario, mucho del descubrimiento y refinamiento ocurre durante las primeras iteraciones.  La rápida atención en estas iteraciones tiene como propósito entender los requisitos arquitectónicamente más significativos o de más alto valor al negocio. 45 Análisis de requisitos evolutivo 1 2 3 4 5 ... 20 requirements workshops Imagine this will ultimately be a 20- iteration project. requirements requirements software software In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements 90% 90% workshops (for example). Perhaps after four iterations and 50% workshops, 90% of the requirements are 30% defined and refined. 20% 20% 5% 8% 10% Nevertheless, only 2% 10% of the software is Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 built. a 3-week iteration week 1 week 2 week 3 M T W Th F M T W Th F M T W Th F kickoff meeting team agile start de-scope final check-in demo and next clarifying iteration modeling & coding & iteration and code- 2-day iteration goals with the team. design, testing goals if freeze for the requirements planning 1 hour UML too much iteration workshop meeting; whiteboard work baseline 2 hours sketching. 5 hours Most OOA/D and Use-case modeling applying UML during during the workshop this period 46 Dr. Ricardo Quintero 23
  • 24 Métodos Ágiles-Scrum y XP Planeación evolutiva y adaptativa  Igual que con los requisitos, la planeación adaptativa y evolutiva no se trata de que los estimados y fechas se desconozcan por siempre.  Esto es, debido a que los primeros requisitos son muy cambiantes (y a otros factores), existe una fase inicial de alto nivel de incertidumbre, la cual declinará conforme el tiempo avance y la información se acumule.  Esto ha sido llamado el Cono de Incertidumbre. Steve McConnell's Software Project Survival Guide (Microsoft Press, 1998, ISBN: 1-57231-621-7) 47 El Cono de Incertidumbre Mayor información: COCOMO 2.0 48 Dr. Ricardo Quintero 24
  • 25 Métodos Ágiles-Scrum y XP Respuesta iterativa a la incertidumbre  La respuesta iterativa a la incertidumbre es postergar los estimados semi-confiables de costo, esfuerzo o tiempo hasta que unas pocas de las iteraciones han pasado. Razonablemente un 10% o 20% del proyecto. 49 Respuesta iterativa a la incertidumbre  Esto es consistente con otras prácticas administrativas en otros dominios de desarrollo de nuevos productos, donde es común una fase exploratoria inicial.  Aún más, se motiva a la planeación adaptativa más que a la planeación predictiva.  Es decir, una planificación detallada no se crea hasta que se ha avanzado más allá de un breve tiempo, de tal manera que el nivel de detalle y compromiso se consensa con la calidad de la información. 50 Dr. Ricardo Quintero 25
  • 26 Métodos Ágiles-Scrum y XP Contratos de precio fijo  Con respecto a hacer una oferta de precio fijo y estimaciones evolutivas, algunos métodos IID recomiendan realizar el proyecto con un contrato de dos fases, cada uno de múltiples iteraciones “timeboxed”. 51 Contrato de dos fases 52 Dr. Ricardo Quintero 26
  • 27 Métodos Ágiles-Scrum y XP Contrato de dos fases  Primera fase:  Un contrato relativamente pequeño de tiempo fijo y precio fijo, con el objetivo de cumplirse en unas cuantas iteraciones, haciendo desarrollo temprano (pero parcial) de software y análisis evolutivo de requisitos.  El resultado de la fase –incluyendo el software base- se comparte con los clientes para el contrato de precio fijo de la segunda fase.  El refinamiento evolutivo de las especificaciones y código en la fase uno ofrece datos de mayor calidad para los estimadores de la fase dos y al mismo tiempo ofrece avances del software. 53 Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 54 Dr. Ricardo Quintero 27
  • 28 Métodos Ágiles-Scrum y XP Entrega incremental  Es la práctica de entregar repetidamente un sistema a producción (o al mercado) en una serie de capacidades extendidas. Es una práctica promovida por los métodos ágiles e IID.  Las entregas incrementales son en un rango de 3 a 12 meses. 55 Entrega incremental Esta práctica no debe confundirse con el desarrollo iterativo. Un ciclo de entrega de 6 meses podría componerse por 10 iteraciones. El resultado de cada iteración no se libera al mercado, pero los resultados de una entrega sí 56 Dr. Ricardo Quintero 28
  • 29 Métodos Ágiles-Scrum y XP Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 57 Entrega evolutiva  Es un refinamiento de la entrega incremental.  Con la diferencia de que aquí existe un interés muy marcado por obtener “feedback” respecto al producto instalado y usar este “feedback” para guiar la siguiente entrega.  El objetivo es conocer necesidades difíciles de predecir.  Recomendación: hacer una mezcla de ambas prácticas. 58 Dr. Ricardo Quintero 29
  • 30 Métodos Ágiles-Scrum y XP Entrega Incremental vs. Evolutiva  En la Entrega Incremental hay un plan definido para las entregas futuras (el “feedback” no conduce el plan de entregas).  En la Entrega Evolutiva no hay plan (o al menos no uno fijo) de entregas futuras; cada una es creada dinámicamente en base a la información que va surgiendo. 59 Temas  Motivación  Desarrollo Iterativo  Planeación iterativa dirigida por los riesgos y por el cliente  El principio de “Time boxing”  Desarrollo evolutivo y adaptativo  Entrega incremental  Entrega evolutiva  Los errores más comunes 60 Dr. Ricardo Quintero 30
  • 31 Métodos Ágiles-Scrum y XP El error más común  Líderes de proceso iterativos y ágiles continuamente ven escenarios así: Líder: Seguro, nosotros no aplicaremos la cascada- ya sabemos que no funciona. Adoptaremos el método <X> y estamos ante nuestro primer proyecto. Ya hemos estado trabajando durante dos meses y hemos terminado prácticamente el análisis de los casos de uso y la planificación y programación de lo que iremos haciendo en cada iteración. Después de revisar y aprobar los requisitos finales y la programación de iteraciones, empezaremos a programar … Ups ! 61 El error más común  Esta es una profunda falta de entendimiento del método y una sobreimposición de los métodos de cascada en los métodos iterativos.  Suele ser uno de los errores más comunes. Evítalo. 62 Dr. Ricardo Quintero 31
  • 32 Métodos Ágiles-Scrum y XP Métodos iterativos  Los métodos iterativos precedieron a los ágiles.  Los métodos iterativos pueden o no ser considerados ágiles. 63 Métodos iterativos  Ejemplos:  Evo (el primero, inició en los 1960s)  UP (desarrollado a mediados de los 1990s)  Microsoft Solutions Framework. (una descripción de las mejores prácticas usadas por Microsoft)  OPEN de Henderson-Sellers, FireSmith y Graham  Modelo de espiral WinWin o Modelo de espiral MBASE de Barry Bohem. 64 Dr. Ricardo Quintero 32
  • 33 Métodos Ágiles-Scrum y XP Lecturas recomendadas  Rapid Devlopment-  The Mythical Man- Steve McConell. Month-Frederick Examina variaciones del Brooks. La edición de desarrollo iterativo. plata de este clásico discute las ventajas de IID, además de muchas otros temas muy interesantes 65 Dr. Ricardo Quintero 33
  • 34 Métodos Ágiles-Scrum y XP El Desarrollo Iterativo y Evolutivo: Scrum y XP Tema 2: Ágil (Dr. Ricardo Quintero) 1 Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad:el roce humano.  El equipo como un Sistema Complejo Adaptativo. 2 Dr. Ricardo Quintero 1
  • 35 Métodos Ágiles-Scrum y XP Desarrollo ágil  Los Métodos ágiles aplican:  Desarrollo evolutivo e iterativo “timeboxed”.  Planeación adaptativa.  Promueven entregas evolutivas.  Incluyen otros valores y prácticas que motivan la agilidad-respuestas rápidas y flexibles al cambio. 3 Desarrollo ágil  Su lema es: Enfrentar el cambio.  Su punto estratégico es: Maniobrabilidad 4 Dr. Ricardo Quintero 2
  • 36 Métodos Ágiles-Scrum y XP Desarrollo ágil  No es posible definir exactamente a los Métodos ágiles, porque sus prácticas específicas varían.  Pero las siguientes prácticas son compartidas por diversos métodos:  Iteraciones pequeñas “timeboxed”.  Refinamiento adaptativo y evolutivo de planes y objetivos 5 Desarrollo ágil  Además los Métodos ágiles promueven prácticas y principios que reflejan una “sensación de agilidad” como: simplicidad, ligereza, comunicación, equipos autodirigidos, programación sobre documentación y más. 6 Dr. Ricardo Quintero 3
  • 37 Métodos Ágiles-Scrum y XP Ejemplo de prácticas ágiles en Scrum  Ejemplos de prácticas ágiles en Scrum (que estudiaremos más al detalle posteriormente) son:  Un lugar común para el proyecto.  Equipos auto-dirigidos que se coordinan a través de reuniones diarias con preguntas concretas que cada miembro responde. 7 Ejemplo de prácticas ágiles en XP  Ejemplos de prácticas ágiles en XP (que estudiaremos más adelante) son:  Usar notas concisas en papel (story cards) para sumarizar requisitos.  Programar en parejas.  Trabajar en un lugar común con participación de tiempo completo de “proveedores de requisitos” para que los requisitos escritos puedan complementarse con explicaciones verbales. 8 Dr. Ricardo Quintero 4
  • 38 Métodos Ágiles-Scrum y XP Iterativo VS ágil  Como concepto de proceso de software, “ágil” es más nuevo que el enfoque “iterativo”.  Muchos métodos IID (Evo o UP) no fueron diseñados como ágiles en su definición original, pero se pueden aplicar en un espíritu ágil.  Aunque podríamos imaginar métodos IID no-ágiles, la mayoría (por no decir todos) están adoptando los valores y prácticas ágiles –es raro que alguien promueva la no-agilidad. 9 Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad:el roce humano.  El equipo como un Sistema Complejo Adaptativo. 10 Dr. Ricardo Quintero 5
  • 39 Métodos Ágiles-Scrum y XP Clasificación de los métodos por ceremonia y ciclos Estrictamente El peso del método en cascada(secuencial) términos de documentación, pasos El número y longitud formales, revisiones, etc. de las iteraciones Ciclos Pocos documentos Muchos documentos Pocos pasos Ceremonia Muchos Pasos formales Scrum UP XP Evo Muchas iteraciones pequeñas (5 días) 11 Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad:el roce humano.  El equipo como un Sistema Complejo Adaptativo. 12 Dr. Ricardo Quintero 6
  • 40 Métodos Ágiles-Scrum y XP El Manifiesto Ágil  Manifiesto (según diccionario RAE): Escrito en que se hace pública declaración de doctrinas o propósitos de interés general.  El 2001 un grupo interesado en los métodos ágiles e iterativos acuñaron el término.  Se reunieron para formar la Alianza Ágil (www.agilealliance.com) con un Manifiesto y un conjunto de estatutos de principios.  Éstos guían la gestión de proyectos ágiles. 13 Valores del Manifiesto Ágil  “Individuos e interacciones sobre procesos y herramientas.  Software trabajando sobre documentación de comprensión.  Colaboración del cliente sobre negociación de contrato.  Respuesta al cambio sobre seguir un plan. Es decir, si bien existe valor en los segundos elementos, valoramos los primeros más 14 Dr. Ricardo Quintero 7
  • 41 Métodos Ágiles-Scrum y XP Ejercicio – El Manifiesto ágil  Lea el Manifiesto Ágil y todo el grupo realice el siguiente ejercicio:  Dividimos el grupo en 4 equipos.  Cada equipo selecciona alguna de las doctrinas (valores) del movimiento ágil y hará una “araña” con los puntos más importantes que lo justifican. Se pega la “araña” en las paredes.  Cada equipo expondrá al resto su doctrina correspondiente. Cada equipo comentará su punto de vista sobre la doctrina. Discusión y comentarios.  Se toman fotos digitales a cada araña y se distribuyen entre los participantes. 15 Principios ágiles (leeremos las justificaciones en el Manifiesto) 1. Nuestra más alta prioridad es satisfacer al cliente a través de entregas continuas y tempranas de software valuable. 2. Bienvenidos los cambios de requisitos aún en etapas posteriores al desarrollo. Los procesos ágiles aprovechan el cambio a favor de la ventaja competitiva del cliente. 3. Entrega software trabajando frecuentemente, desde un grupo de semanas hasta un grupo de meses, con preferencia a escalas breves de tiempo 16 Dr. Ricardo Quintero 8
  • 42 Métodos Ágiles-Scrum y XP Principios ágiles 4. La gente del negocio y los desarrolladores deben trabajar en conjunto diariamente a lo largo del proyecto. 5. Construye el proyecto con gente motivada. Dales el ambiente y soporte necesario y confía en que harán bien el trabajo. 6. El método más eficiente y efectivo para conllevar información hacia y dentro el equipo de desarrollo es la conversación cara-a-cara. 17 Principios ágiles 7. Software trabajando es la medida principal de progreso. 8. Los procesos ágiles promueven el desarrollo sustentable. 9. Los patrocinadores, desarrolladores y usuarios deben mantener una paz constante indefinidamente. 10. Atención constante a la excelencia técnica y el buen diseño aumenta la agilidad. 18 Dr. Ricardo Quintero 9
  • 43 Métodos Ágiles-Scrum y XP Principios ágiles 11. Simplicidad-el arte de maximizar el monto de trabajo no hecho-es esencial. 12. Las mejores arquitecturas, requisitos y diseños emergen a partir de equipos auto-organizados. 13. A intervalos regulares, el equipo reflexiona sobre como ser más efectivo, acorde a lo cual ajusta su comportamiento. 19 Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad:el roce humano.  El equipo como un Sistema Complejo Adaptativo. 20 Dr. Ricardo Quintero 10
  • 44 Métodos Ágiles-Scrum y XP Gestión de proyectos ágiles  Aunque más adelante veremos prácticas concretas de gestión de proyectos ágiles (en Scrum y XP). Hay generalizaciones comunes a todos los métodos.  Veremos dos descripciones bien conocidas. 21 Gestión de proyectos ágiles:Jim Highsmith 1. Entrega algo útil al usuario; verifica que es lo que le resulta de valor. 2. Cultiva stakeholders comprometidos. 3. Emplea un estilo de liderazgo colaborativo. 4. Construye equipos competentes y colaborativos. 5. Posibilita la toma de decisiones en equipo. Gestion de Proyectos ágiles -Highsmith.pdf 22 Dr. Ricardo Quintero 11
  • 45 Métodos Ágiles-Scrum y XP Gestión de proyectos ágiles:Jim Highsmith 6. Utiliza iteraciones cortas “timeboxed” para ofrecer entregas rápidas. 7. Motiva la adaptabilidad. 8. Busca la excelencia técnica. 9. Enfócate en actividades de entrega, no en actividades de cumplimiento de procesos. 23 Gestión de proyectos ágiles:Augustine and Woodcock 1. Visión guiada: establece una visión guiada para el proyecto. Refuérzala continuamente a través de palabras y acciones. 2. Trabajo en equipo & colaboración: facilita la colaboración y el trabajo en equipo a través de relaciones y espíritu comunitario. 3. Reglas simples: establece y soporta un conjunto de prácticas guía, tales como Scrum y XP. 24 Dr. Ricardo Quintero 12
  • 46 Métodos Ágiles-Scrum y XP Gestión de proyectos ágiles:Augustine and Woodcock 4. Apertura en la información: Ofrece acceso abierto y visible a la gestión del proyecto y otra información. 5. Roce ligero: Aplica sólo el control suficiente para fomentar comportamiento emergente en equipo auto-dirigido. 6. Vigilancia ágil: Refuerza la visión, sigue o adapta las reglas, escucha a la gente. 25 Gestión de proyectos ágiles:papel del administrador  Tanto en Scrum como en XP se regresa tanto el control como la planeación al equipo, no al administrador.  El administrador no crea la estructura de partición del trabajo, la estimación de tiempos; todo esto se hace en equipo.  Generalmente el administrador no dice a la gente lo que hará.  El administrador no define y asigna detalladamente la mayoría de los roles y responsabilidades. 26 Dr. Ricardo Quintero 13
  • 47 Métodos Ágiles-Scrum y XP Gestión de proyectos ágiles:papel del administrador  Al contrario:  El rol del administrador del proyecto es realizar coaching, ofrecer recursos, mantener la visión, remover impedimentos, promover los principios ágiles, etc. 27 Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad:el roce humano.  El equipo como un Sistema Complejo Adaptativo. 28 Dr. Ricardo Quintero 14
  • 48 Métodos Ágiles-Scrum y XP Programación como si la gente importara “La gente es más importante que cualquier proceso. Buena gente con un buen proceso superará siempre a buena gente sin ningún proceso” Grady Booch (1996) 29 Programación como si la gente importara  El primer valor del Manifiesto ágil es que los Individuos y las interacciones están sobre los procesos y las herramientas.  Nos recuerda que: la programación es una actividad humana.  Atento al impacto del “trabajo extra” en la habilidad para programar bien o mantener una vida familiar o social saludable, XP tiene la regla de paz sustentable-evitar el “trabajo extra” 30 Dr. Ricardo Quintero 15
  • 49 Métodos Ágiles-Scrum y XP Programación como si la gente importara  Los hábitos correctos de trabajo y conocimiento juegan un papel significativo en la productividad-el valor de la educación constante y del mentoring para desarrolladores.  XP motiva fuertemente la transferencia de habilidades a través de la programación en parejas. 31 Programación como si la gente importara  El énfasis en la comunicación es también importante, especialmente las conversaciones cara-a-cara.  Las reuniones diarias de Scrum y un lugar común para el proyecto y en XP la programación en parejas y todo el equipo junto son ejemplos. 32 Dr. Ricardo Quintero 16
  • 50 Métodos Ágiles-Scrum y XP Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad:el roce humano.  El equipo como un Sistema Complejo Adaptativo. 33 Prácticas y herramientas de proyectos simples  Muchos métodos ágiles promueven el principio de hacer lo más simple que posiblemente funcione – un aforismo* XP. *Sentencia breve y doctrinal que se propone como regla en alguna ciencia o arte (Diccionario RAE) 34 Dr. Ricardo Quintero 17
  • 51 Métodos Ágiles-Scrum y XP Prácticas y herramientas de proyectos simples  Muchos métodos ágiles promueven un enfoque “low-tech, high- touch”.  Low-tech es relativo, si una herramienta Web es lo más simple, úsala. 35 Prácticas y herramientas de proyectos simples Es un malentendido igualar los métodos ágiles con falta de habilidad o auto-disciplina. Un proyecto aplicando todas las prácticas XP tiene plena estructura y disciplina. Pero –y esto es quizá el punto clave en los métodos ágiles- las prácticas “disciplinadas” son muy orientadas-a- entregables o de orientación-a-calidad-en-el- código. Los desarrolladores rápidamente ven los beneficios. 36 Dr. Ricardo Quintero 18
  • 52 Métodos Ágiles-Scrum y XP Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad: el roce humano.  El equipo como un Sistema Complejo Adaptativo. 37 Procesos Empíricos vs. Definidos y Prescriptivos  Proceso definido (o prescriptivo): tiene un conjunto ordenado y predefinido de actividades a seguir durante el desarrollo. Útil en dominios predictivos de manufactura.  Proceso empírico: usado para dominios inestables y de alto-cambio. En lugar de sustentarse en muchas actividades; se basa en mediciones frecuentes y respuestas dinámicas a eventos variables.  Los métodos ágiles promueven los Procesos empíricos en lugar de Procesos definidos.  Ej.- Scrum no nos indica las actividades a realizar por iteración (salvo una reunión al inicio del día).  Ej.- UP está en un punto medio, lista actividades comunes, pero el equipo las puede ignorar o hacer en cualquier orden. 38 Dr. Ricardo Quintero 19
  • 53 Métodos Ágiles-Scrum y XP Procesos empíricos VS. Definidos y Prescriptivos  Los métodos ágiles entienden que el grado de “peso de un método” y la predefinición de actividades ordenadas están en función del tipo de proyecto.  Un método o proyecto ágil cae en un “continuum” de empirismo, dirigido por las necesidades. 39 Basado en Principios VS Basado en Reglas  En lugar de considerar un conjunto predefinido de reglas (roles, organización de equipo, responsabilidades, etc.) el equipo y el administrador son guiados por los principios más que por las prácticas. 40 Dr. Ricardo Quintero 20
  • 54 Métodos Ágiles-Scrum y XP Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad: el roce humano.  El equipo como un Sistema Complejo Adaptativo. 41 Disciplina de sustentabilidad: el toque humano  No hay pocas historias de intentos en adoptar métodos que requieren disciplina y esfuerzo, sólo para terminar en poco tiempo con poco apego a los mismos.  Los factores sociales y psicológicos necesarios para la adopción sustentable se están perdiendo. 42 Dr. Ricardo Quintero 21
  • 55 Métodos Ágiles-Scrum y XP Disciplina de sustentabilidad: el toque humano  Los creadores de algunos métodos ágiles (XP, Crystal) reconocen que factores humanos como el disfrute, la simplicidad, el estímulo a corto plazo, etc; son ingredientes para crear un suelo fértil para la auto-disciplina sostenible en las prácticas. 43 Disciplina de sustentabilidad: el toque humano  Por ejemplo, el desarrollo dirigido por pruebas revela sus ventajas rápidamente a aquellos que lo usan.  Los desarrolladores disfrutan la “pequeña victoria” de pasar una prueba y la clarificación en el diseño que viene a partir de escribir las pruebas antes de que el código sea probado (práctica común en XP). 44 Dr. Ricardo Quintero 22
  • 56 Métodos Ágiles-Scrum y XP Agenda  Desarrollo ágil  Clasificación de los métodos  Los principios y el manifiesto ágil  Gestión de proyectos ágiles  Abrazando la comunicación y la retroalimentación  Prácticas y herramientas de proyectos simples  Procesos empíricos VS Procesos definidos y prescriptivos  Disciplina de sustentabilidad: el roce humano.  El equipo como un Sistema Complejo Adaptativo. 45 El equipo como un Sistema Complejo Adaptativo  Algunos métodos ágiles (ej. Scrum) hablan de un equipo de desarrollo saludable como un Sistema Complejo Adaptativo (SCA).  Lo comparan con una “parvada de pájaros”. Cada pájaro tiene reglas de comportamiento local relativamente simples, pero a nivel macro exhiben un comportamiento emergente.  Esto es distinto a una coordinación dirigida por un líder. 46 Dr. Ricardo Quintero 23
  • 57 Métodos Ágiles-Scrum y XP El equipo como un Sistema Complejo Adaptativo  Los métodos ágiles promueven el valor de que para proyectos creativos-inventivos una cultura inspirada en SCA es más valiosa que el control y planeación de los administradores.  Ej.- En Scrum los equipos son auto- organizados; la organización a nivel de equipo y adaptación se realiza en la Scrum meeting. 47 ¿Mucha promoción ágil?  Visto como un todo los principios y prácticas ágiles (por ejemplo de XP o Scrum) tienen un “sabor fresco” nuevo.  Se engloban en:  Abrazar los cambios de requisitos.  La comunicación.  La auto-organización de equipos.  La planeación adaptativa. Etc.  Y poseen algunas prácticas novedosas como el desarrollo dirigido por pruebas y la integración continua. 48 Dr. Ricardo Quintero 24
  • 58 Métodos Ágiles-Scrum y XP Métodos ágiles específicos  De acuerdo a una encuesta de Shine, XP y Scrum son los métodos ágiles más ampliamente utilizados.  Scrum: su énfasis distintivo entre los métodos es su fuerte promoción a los equipos auto-organizados, a la medición diaria de los equipos y el evitar seguir pasos predefinidos. 49 Métodos ágiles específicos  XP: es el método ágil más conocido; enfatiza la colaboración, rápida y temprana creación del software; y buenas prácticas experimentadas de desarrollo. Se fundamenta en 4 valores:  Comunicación.  Simplicidad.  Retroalimentación  Coraje o valor. 50 Dr. Ricardo Quintero 25
  • 59 Métodos Ágiles-Scrum y XP Métodos ágiles específicos  Familia Crystal: fue desarrollada por Alistair Cockburn.  Al mismo tiempo que reconoce la necesidad del ciclo de vida iterativo, en este grupo de métodos Cockburn favorece los aspectos del “peopleware” sobre los procesos: comunicación, educación, etc.  Su definición del desarrollo de software: “un juego cooperativo de invención y comunicación”. 51 Métodos ágiles específicos  Familia Crystal: diferentes versiones de Crystal (Clear, Yellow,…) contienen incrementalmente “peso del método” como una función del tamaño del staff, criticalidad y prioridad del proyecto.  Se selecciona el tamaño y la criticalidad y se mapea a una versión particular Crystal con un “peso del método” recomendado.  Utilizaremos este modelo para clasificar Scrum y XP. 52 Dr. Ricardo Quintero 26
  • 60 Métodos Ágiles-Scrum y XP Familia Crystal 53 Modelado Ágil  Es un conjunto de principios y prácticas para el análisis de requisitos y modelado que complementa a muchos métodos IID.  El Modelado Ágil promueve la creación colaborativa “low-tech, high-touch” con modelos que ayuden más al entendimiento y la comunicación.  Sus prácticas promueven velocidad, simplicidad y creatividad 54 Dr. Ricardo Quintero 27
  • 61 Métodos Ágiles-Scrum y XP Prácticas del Modelado Ágil Refinamiento iterativo Simplicidad Crea varios Itera a otros Usa la Despliega los modelos en paralo artefactos herramienta más modelos de forma simple simple Ej. un diagrama de Ej. 5% de un clases y uno de diagrama de clases, Ej. pizarrón blanco Ej. en la pared; no secuencia después 5% de un & cámara; video en una página Web relacionados diagrama de secuencia Documentación Trabajo en equipo Descarta modelos Actualiza solo si Modela con otros Despliega los temporales vale la pena modelos Ej. diagramación en públicamente Ej. toma una foto; Ej. desarrollar el parejas borra el pizarrón código es más Ej. Datos de gestión importante que del proyecto en las mantener el paredes diagrama 55 Otros métodos y prácticas  Adaptative Software Development (DSA): Jim Highsmith.  Dynamic Solutions Delivery Model (DSDM).  Feature-driven Development (FDD); Jeff De Luca y Peter Coad.  Lean Development: Mary and Tom Poppedieck  Pragmatic programming: Andy Hunt and Dave Thomas. www.pragmaticprogram mer.com 56 Dr. Ricardo Quintero 28
  • 62 Métodos Ágiles-Scrum y XP El Desarrollo Iterativo y Evolutivo: Scrum y XP Tema 3: Scrum (Dr. Ricardo Quintero) 1 Temas  Clasificación de Scrum  Workproducts, roles y prácticas  Errores comunes, adopción y mezcla de procesos, fortalezas y debilidades 2 Dr. Ricardo Quintero 1
  • 63 Métodos Ágiles-Scrum y XP Scrum y Rugby  Scrum es un término con el que se identifica una jugada de Rugby en la cual un par de equipos se disputan la posesión del balón una vez que se ha reanudado un juego por alguna interrupción … 3 Scrum: prácticas clave  Equipos auto-dirigidos y auto- organizados.  Una vez seleccionado, no se agrega trabajo adicional a una iteración.  Reunión diaria “de pie” con preguntas especiales.  Iteraciones de 30 días (generalmente).  Demo a los stakeholders al final de cada iteración.  En cada iteración, planeación adaptativa dirigida por los clientes. 4 Dr. Ricardo Quintero 2
  • 64 Métodos Ágiles-Scrum y XP Scrum en la escala de ciclos y ceremonia Estrictamente Preciso en la longitud de las cascada(secuencial) Flexible en el grado de iteraciones (30 días), no ceremonialidad pero en el número de se recomienda “as iteraciones. little ceremony as possible”. Ciclos Pocos documentos Muchos documentos Pocos pasos Ceremonia Muchos Pasos formales Scrum UP XP Evo Muchas iteraciones pequeñas (5 días) 5 Scrum en la escala de Cockburn 6 Dr. Ricardo Quintero 3
  • 65 Métodos Ágiles-Scrum y XP Tamaño de equipos  1 equipo de Scrum debe ser de 7 o menos participantes.  Múltiples equipos pueden formar un proyecto.  Pueden tenerse “Scrum de Scrums” donde varios equipos pequeños trabajan juntos y tienen una reunión diaria con representantes de cada equipo.  Scrum es complementario a otras prácticas de tal forma que puede aplicarse a otros dominios de software (desde misión crítica hasta más casuales).  Promueve valores y prácticas de gestión de proyectos (más que de requisitos, implementación, análisis, diseño, etc.). Por eso puede combinarse con otros métodos. 7 Mayor énfasis en procesos empíricos que en predefinidos  Ken Schwaber, uno de los fundadores de Scrum cuenta la siguiente historia:  “Deseaba entender porque los procesos de mis clientes (cascada y definidos- detalladamente) no trabajaban para mi compañía de software, así que en 1995 traje varias metodologías a los expertos de teoría de procesos en el DuPont Experimental Station. Estos expertos, dirigidos por Babatunde Ogannaike, son los expertos teoristas más respetados en procesos de control industrial… 8 Dr. Ricardo Quintero 4
  • 66 Métodos Ágiles-Scrum y XP Mayor énfasis en procesos empíricos que en predefinidos  “..Inspeccionaron los procesos de desarrollo de sistemas que les llevé. Raramente había visto un grupo que se riera tanto. Estuvieron sorprendidos y asustados de que mi industria (de software) estuviera tratando de hacer su trabajo usando un modelo de control de procesos completamente inapropiado. Decían que el desarrollo de sistemas tenía mucha complejidad e impredecibilidad por lo que tenía que ser manejado por un modelo de control de procesos que referían como “empírico”. Decían que eso no era totalmente nuevo y que todos los procesos complejos que no estuvieran completamente entendidos (o que tenían entradas cambiantes) requería el modelo empírico (y no un modelo definido de procesos) …” 9 Mayor énfasis en procesos empíricos que en predefinidos  “…[Ogannaike] me dijo que mi negocio era un negocio intelectualmente intenso que requería de mucho intelecto y creatividad para ser un buen candidato para un enfoque predefinido…Estaba particularmente sorprendido de que las tareas estuvieran enlazadas con dependencias (tipo PERT), como un proceso industrial bien definido..” 10 Dr. Ricardo Quintero 5
  • 67 Métodos Ágiles-Scrum y XP Mayor énfasis en procesos empíricos que en predefinidos  Las palabras de Ogannaike recuerdan los procesos industriales de Deming y Shewhart que poseen énfasis en ciclos Plan-Do-Study-Act para ambientes complejos y cambiantes. (El ciclo de Shewart o la rueda de Deming). 11 Ciclo de vida de Scrum: 4 fases para una entrega (release) Planeación Montaje Desarrollo Entrega (Pre-juego) (Pre-juego) (Juego) (pos-juego) Propósito: Propósito: Propósito: Propósito: Establecer la visión, Identificar la mayoría Implementar un -Instalación expectactivas y de los requisitos y sistema listo para operacional. aseguramiento priorizarlos para la entregarse en una financiero primer iteración. serie de iteraciones (Sprints) de 30 días Actividades: Actividades: Actividades: Actividades: -Definir la visión, -Planeación. -Junta de planeación -Documentación. presupuesto, Product -Diseño exploratorio para el Sprint -Entrenamiento. Backlog inicial y y prototipos. definiendo el Sprint -Mercadeo & Ventas. estimación de sus Backlog y items. estimaciones. … -Diseño exploratorio -Juntas diarias y prototipos. Scrum. -Diseño de la -Revisión del Sprint Arquitectura de alto nivel 12 Dr. Ricardo Quintero 6
  • 68 Métodos Ágiles-Scrum y XP Ciclo de vida de Scrum 13 Ciclo de vida de Scrum 14 Dr. Ricardo Quintero 7
  • 69 Métodos Ágiles-Scrum y XP Temas  Clasificación de Scrum  Workproducts, roles y prácticas  Errores comunes, adopción y mezcla de procesos, fortalezas y debilidades 15 Workproducts (entregables no-software) de las diversas disciplinas Requisitos Diseño •Incluye todos los items del producto. •El Release backlog es un subconjunto del Product Backlog (PB). •Incluye: características, UC, extensiones, defectos, tecnologías, etc. Implementación Pruebas & Verificación Gestión del proyecto Configuración & Ambiente de Gestión de Cambios •Estimación del trabajo restante VS los días restantes. •Tareas para la iteración. Granularidad de 4 a 16 hrs. 16 Dr. Ricardo Quintero 8
  • 70 Métodos Ágiles-Scrum y XP Workproducts (o entregables)  Además de los que se mencionan, Scrum permite cualquier Workproduct que de valor al proyecto. Los principales son:  El Product Backlog.  El Sprint Backlog.  El gráfico del Sprint Backlog 17 Workproducts-Product Backlog (Requisitos)  Product Backlog: Incluye una lista de todos los “items” concebibles del sistema, priorizados por el Product Owner (el cliente).  Es una lista maestra de toda la funcionalidad deseada en el producto.  Incluye estimaciones de esfuerzo (en unidades de tiempo-hombre) de cada “item”. En principio definidas burdamente pero refinadas después una vez que los miembros del equipo se comprometen 18 Dr. Ricardo Quintero 9
  • 71 Métodos Ágiles-Scrum y XP Workproducts-Ejemplo de Product Backlog 19 Workproducts-Product Backlog 20 Dr. Ricardo Quintero 10
  • 72 Métodos Ágiles-Scrum y XP Aspectos prácticos-Product Backlog  Plantilla básica propuesta. (Se recomienda como un archivo compartido en la red, para que los interesados lo pueda compartir y modificar)  Ejemplo 1 en Excel.  Ejemplo 2 en Excel.  El SprintOmeter. 21 Workproducts-Sprint Backlog (Project Management)  Sprint Backlog: Es la lista de Tareas que el Scrum Team se compromete para el Sprint actual. Los “items” del Sprint Backlog se obtienen a partir del Product Backlog (de acuerdo a las prioridades definidas por el Product Owner).  Es crítico que el equipo seleccione los items y el tamaño del Sprint Backlog, porque ellos son los que estarán comprometidos con el trabajo definido en el mismo.  Se puede definir el estimado diario de horas restantes para cada tarea.  Se actualiza diariamente por cada miembro o por algún responsable común.  Se puede definir en Excel. 22 Dr. Ricardo Quintero 11
  • 73 Métodos Ágiles-Scrum y XP Workproducts-Sprint Backlog 23 Workproducts-Sprint Backlog 24 Dr. Ricardo Quintero 12
  • 74 Métodos Ágiles-Scrum y XP Aspectos prácticos-Sprint Backlog  Plantilla básica propuesta. (Puede ser un archivo compartido en la red)  Ejemplo 1 en Excel.  Ejemplo 2 en Excel.  Ejemplo 3 en Excel.  El SprintOmeter. 25 Aspectos prácticos-Sprint Backlog “de hombre pobre” 1. Localiza un área grande en pared sin utilizar. 2. Toma una gran hoja de papel (2x2 m. o 3x2 m) y cólocala en la pared. 26 Dr. Ricardo Quintero 13
  • 75 Métodos Ágiles-Scrum y XP Aspectos prácticos-Sprint Backlog “de hombre pobre” 3. Ahora dibuja las líneas y coloca las HU y Tareas: 27 Aspectos prácticos-Sprint Backlog “de hombre pobre” 28 Dr. Ricardo Quintero 14
  • 76 Métodos Ágiles-Scrum y XP Aspectos prácticos-Sprint Backlog “de hombre pobre” 4. Después de la primer junta Scrum: 29 Aspectos prácticos-Sprint Backlog “de hombre pobre” 4. Después de algunos días: 30 Dr. Ricardo Quintero 15
  • 77 Métodos Ágiles-Scrum y XP Aspectos prácticos-Sprint Backlog “de hombre pobre” 4. El diagrama de BurnDown: 31 Aspectos prácticos-Sprint Backlog “de hombre pobre” 5. Monitoreando el proyecto (Scrum Master) 32 Dr. Ricardo Quintero 16
  • 78 Métodos Ágiles-Scrum y XP Workproducts-gráfico Sprint Backlog  Gráfico Sprint Backlog: es un resumen visual de la estimación de tiempo restante de las tareas del Sprint Backlog.  Es considerado el dato más crítico del proyecto.  Recomendación: Colocar en la pared y actualizar diariamente una versión de este Workproduct para la junta diaria de Scrum. 33 Workproducts-gráfico Sprint Backlog 34 Dr. Ricardo Quintero 17
  • 79 Métodos Ágiles-Scrum y XP Workproducts-gráfico Sprint Backlog Notése que el equipo hace un ajuste en las tareas del Sprint actual cuando restaban 619 horas y se han percatado que es mucho trabajo y el Sprint corre el riesgo de no cumplirse (remueven tareas) 35 Roles Customer Development •Trabaja en el Sprint Backlog •Una persona responsable de (iteración). crear y priorizar el PB. •Cada miembro es, solamente, •A partir del PB selecciona los un “miembro del equipo” objetivos del siguiente Sprint. (team member). •Junto con los stakeholders, revisa el sistema al finalizar el Sprint. Management Other •50% desarrollador, no sólo administrador. •Conoce y refuerza la visión y objetivos del proyecto e iteración. •Todos los demás pueden •Asegura que los valores y prácticas se observar, pero no interferir o sigan. hablar durante una iteración •Media entre la administración y el Scrum team. •Monitorea el avance y elimina obstáculos. •Conduce la reunión diaria de Scrum. •Conduce la revisión del Sprint (demo). 36 Dr. Ricardo Quintero 18
  • 80 Métodos Ágiles-Scrum y XP Prácticas-una puede soportar múltiples disciplinas Requisitos Diseño Implementación Pruebas & Verificación Gestión del proyecto Configuración & Ambiente de Gestión de Cambios (valores) 37 Core practices-Requisitos  Pre-juego Planeación y montaje:  Todos los stakeholder pueden contribuir para crear una lista de características, UC, extensiones, defectos, etc y registrar en el Product Backlog.  Se designa un Product Owner y las solicitudes se hacen a través del mismo.  En esta sesión se genera el trabajo para, al menos, la primer iteración.  Se identifica el Release Backlog, un subconjunto del Product Backlog que definirá al siguiente producto operacional. 38 Dr. Ricardo Quintero 19
  • 81 Métodos Ágiles-Scrum y XP Core practices-Requisitos  Planeación de Sprint:  Antes del inicio de cada Sprint se manejan dos juntas: 1) Los stakeholders refinan y re-priorizan el Product Backlog y el Release Backlog para seleccionar los objetivos de la siguiente iteración, dirigidos por valor del negocio o riesgo. 2) El Scrum Team y el Product Owner se reúnen para definir como lograr las tareas y crear el Sprint Backlog (en unas 4 a 16 hrs). Si el esfuerzo estimado excede los recursos, ocurre otro ciclo de planeación. 39 Core practices-Requisitos  Planeación de Sprint:  Conforme la iteración procede, el Sprint Backlog se actualiza, es común que sea diario durante la parte inicial de la iteración, conforme nuevas tareas se descubren.  Al paso del tiempo (y con experiencia), el equipo mejora en la elaboración del Sprint Backlog. 40 Dr. Ricardo Quintero 20
  • 82 Métodos Ágiles-Scrum y XP Planeación del Sprint-Aspectos prácticos  Es, quizá, el evento más importante de Scrum. Una mala planeación puede llevar al fracaso todo el Sprint.  Resultados de la planeación: 1. El objetivo del Sprint. 2. Una lista de los miembros del equipo y sus niveles de compromiso. 3. El Sprint backlog. 4. Una fecha definida para el Sprint demo. 5. Una hora y lugar definidos para la junta diaria de Scrum. 41 Planeación del Sprint-Aspectos prácticos  El Product Owner la debe atender. De no hacerlo, el método se verá seriamente comprometido en su éxito.  El tiempo del reunión debe respetar el principio de time-boxing (al principio puede ser difícil e incluso no lograrse una reunión satisfactoria, pero aún así persiste, la próxima reunión se verán presionados a dar resultados en el tiempo estipulado). 42 Dr. Ricardo Quintero 21
  • 83 Métodos Ágiles-Scrum y XP Planeación del Sprint-Aspectos prácticos  Agenda ejemplo (8:00 a 12:00 hrs)  8:00 a 8:30 – El Product Owner define el objetivo y sumariza el Product Backlog. Se define lugar del Demo, hora y fecha.  8:30 a 10:00 – Estimaciones de tiempo de las HU, posibles divisiones de las mismas. El Product Owner puede repriorizar las HU. Se clarifican las HU. Se llenan todos los “Demos” de cada HU en el PB.  10:00 a 11:00 – El equipo selecciona las HU a incluir en el Sprint. Se calcula la velocidad del equipo.  11:00 a 12:00 – Se determina la hora y lugar de la junta diaria de Scrum. Se dividen las HU en Tareas. 43 Core practices-Requisitos  Revisión de Sprint:  Al finalizar cada iteración, hay una reunión de revisión (max. 4 hrs) convocada por el Scrum master. Participan el equipo, el Product Owner y otros stakeholders.  Se muestra un demo del producto para informar a los stakeholders de la función del producto, diseño, fortalezas, debilidades, esfuerzo del equipo y futuros puntos de problema. 44 Dr. Ricardo Quintero 22
  • 84 Métodos Ágiles-Scrum y XP Core practices-Requisitos  Revisión de Sprint:  Se motiva al “feedback” y a la lluvia de ideas sobre las direcciones futuras, pero no se establecen compromisos. En la siguiente reunión de Sprint planning, los stakeholders y el equipo harán los compromisos.  Prohibido presentaciones en Power Point. El énfasis en la presentación es en mostrar el producto. 45 Revisión de Sprint-Aspectos prácticos  Asegúrate de presentar claramente el objetivo del Sprint. Si en la reunión hay gente que no sabe nada del producto, da alguna explicación.  Enfócate en presentar el producto, no presentaciones en PowerPoint.  Procura que tu demo sea sobre escenarios fáciles y ágiles de presentar (más que cuestiones estéticas).  Manten la demo a nivel de funcionalidad (el ¿Qué?)y no tecnicismos (el ¿Cómo?).  Si es posible, trata que el auditorio pruebe el producto.  No muestres arreglos o características pequeñas. Enfócate en lo importante. 46 Dr. Ricardo Quintero 23
  • 85 Métodos Ágiles-Scrum y XP Core practices-Project Management  No agregar a una iteración:  Durante una iteración, la administración no agrega trabajo al equipo o individuos. Se busca un “enfoque ininterrumpido”.  En el raro caso de que algo tenga que agregarse algo deberá removerse.  Pero, antes de cada nueva iteración el Product Owner y la administración tienen el derecho y la responsabilidad de re-priorizar el Product Backlog e indicar que hacer en la siguiente iteración, de tal forma que la requisición de trabajo no exceda los recursos. 47 Core practices-Project Management  Cerdos y gallinas:  Durante la Scrum meeting, sólo el Scrum Team puede hablar (the Pigs). Los demás pueden atender a la reunión, pero se mantienen en silencio (the chickens), aún el jefe.  Sólo se les permite “feedback” para puntos de explicación relevante del negocio para el trabajo del equipo.  “Huevos con jamón-¿Quién está involucrado y quien comprometido? ¿El cerdo o la gallina?” 48 Dr. Ricardo Quintero 24
  • 86 Métodos Ágiles-Scrum y XP Core practices-Project Management  Scrum Master firewall:  El Scrum Master debe asegurarse de que el equipo no sea interrumpido por solicitudes de trabajo de terceros y de ocurrir, removerlas y manejarlas con “inteligencia”.  El Scrum Master debe asegurarse de que el método de Scrum se aplique, removiendo obstáculos, proveyendo recursos y tomando decisiones.  Debe tomar la iniciativa cuando ve que las reuniones no están completando su trabajo o si el equipo no está participando (hablando, por ej.) 49 Core practices-Project Management  Scrum diario:  Cada día de trabajo en el mismo lugar y hora, se tiene una reunión con los miembros del equipo (en círculo), en el que se realizan las preguntas especiales Scrum para cada miembro: 1) ¿Qué hiciste desde el último Scrum? 2) ¿Qué harás desde ahora y hasta el siguiente Scrum? 3) ¿Qué obstáculos tienes para alcanzar los objetivos? 4) ¿Alguna tarea a agregar al Sprint Backlog? 5) ¿Haz aprendido o decidido algo nuevo, de relevancia para alguno de los miembros del equipo? 50 Dr. Ricardo Quintero 25
  • 87 Métodos Ágiles-Scrum y XP Core practices-Project Management  Scrum diario:  La reunión es mejor manejarla en círculo para motivar a la brevedad.  En promedio 15 a 20 minutos para 7 a 10 personas. Reuniones más largas pueden tenerse al inicio de la iteración.  Miembros que no son del equipo (chickens) están fuera del círculo.  Se maneja junto a un pizarrón en el cual las tareas y obstáculos se van escribiendo.  El Scrum Master borra los obstáculos sólo cuando han sido removidos 51 Core practices-Project Management  Scrum diario:  Puede existir alguna forma de comunicación externa para miembros no presentes.  El Scrum Master asegura que las reglas se sigan y prepara el lugar para una reunión eficiente.  Debe empezar a la hora.  Ninguna otra discusión se permite que las 5 preguntas. El Scrum Master tiene la autoridad de reenfocar la discusión.  Si otros aspectos necesitan discusión, se pueden tener reuniones secundarias inmediatamente después del Scrum meeting con subconjuntos del Scrum team. 52 Dr. Ricardo Quintero 26
  • 88 Métodos Ágiles-Scrum y XP Scrum diario-Aspectos prácticos  En el Sprint Backlog “de hombre pobre” cada miembro del equipo puede actualizar el tiempo restante de cada tarea, es muy importante que todos actualicen sus tareas. Si esta tarea se deja sólo al Scrum Master, será mucho trabajo: 53 Scrum diario-Aspectos prácticos  ¿Qué hacer con los impuntuales? Puede pagar una “multa” y usar luego el dinero para algún evento social   ¿Qué hacer con los que “no saben que hacer el día actual”? Se les escucha (sin discutir) y luego se lleva a todo el equipo al Sprint Backlog para que adecuen o agreguen nuevas tareas. Con el SB actualizado se les pide a los “susodichos” que seleccionen lo que harán el día de hoy. En ocasiones, si esto no funciona, el Scrum Master tendrá que realizar coaching más personal (incluso decidir si vale la pena seguir con ese miembro o no en el equipo). 54 Dr. Ricardo Quintero 27
  • 89 Métodos Ágiles-Scrum y XP Core practices-Project Management  Decisiones en 1 hora:  Los bloqueos reportados en el Scrum Meeting y que requieren decisión del Scrum Master deben decidirse, idealmente, inmediatamente o dentro de 1 hora.  Se promueve el valor de “Es mejor tomar malas decisiones a no decidir. Las malas decisiones se pueden revertir” 55 Core practices-Project Management  Remoción de bloqueos en 1 día:  Los bloqueos reportados en el Scrum Meeting deben removerse idealmente antes de la siguiente reunión. 56 Dr. Ricardo Quintero 28
  • 90 Métodos Ágiles-Scrum y XP Core practices-Project Management  Equipos de 7:  Scrum se puede escalar a proyectos grandes, pero recomienda tener un máximo de 7 miembros.  Proyectos más grandes se manejan como multi-equipo. 57 Core practices-Project Management  Scrum of Scrums:  Se pueden manejar para multi-equipos reuniones de Scrum de Scrums. 58 Dr. Ricardo Quintero 29
  • 91 Métodos Ágiles-Scrum y XP Core practices-Project Management  Sprint:  El trabajo generalmente se organiza en iteraciones de 30 días de calendario; cada una llamada un Sprint. 59 Core practices-Project Management  Equipos auto-dirigidos y auto- organizados:  Se empodera al equipo con autorización y recursos de tal forma que caminen a su ritmo y resuelvan sus problemas.  El Scrum Master y la administración proveen recursos y remueven obstáculos.  Es el reto más fuerte para la adopción de Scrum. 60 Dr. Ricardo Quintero 30
  • 92 Métodos Ágiles-Scrum y XP Core practices-Configuración & Ambiente de Gestión de Cambios  Cuarto común del proyecto:  Idealmente el equipo trabajo junto en un espacio común para el proyecto, en lugar de oficinas separadas o cubículos.  Para otras actividades se pueden considerar los espacios separados y privados.  Se han reportado casos de éxito con equipos geográficamente dispersos que participan mediante comunicación virtual. 61 Core practices-Configuración & Ambiente de Gestión de Cambios  Construcción diaria:  Al menos una integración diaria y una prueba de regresión a todo lo largo del código verificado.  Más adelante veremos la práctica de Integración Continua de XP que es aún mejor. 62 Dr. Ricardo Quintero 31
  • 93 Métodos Ágiles-Scrum y XP Valores que promueve Scrum  Compromiso:  Dado que el Scrum Team se compromete a metas definidas por iteración y se le da la autonomía y autoridad para decidir como alcanzarla.  Dado que la Administración y el Scrum Manager se comprometen a no introducir nuevo trabajo, eliminar obstáculos y proveer recursos.  El Product Owner se compromete a definir y priorizar el Product Backlog, guiar los objetivos por iteración y revisar y ofrecer “feedback” iteración a iteración. 63 Valores que promueve Scrum  Enfoque:  Dado que el Scrum Team se enfoca en los objetivos establecidos de la iteración, sin distracciones.  El Scrum Master y la administración se enfocan en proveer recursos, remover obstáculos y evitar interrupciones al equipo con solicitudes adicionales. 64 Dr. Ricardo Quintero 32
  • 94 Métodos Ágiles-Scrum y XP Valores que promueve Scrum  Apertura:  El Product Backlog está disponible para visualizar el trabajo y las prioridades.  Las Daily Scrums hacen visible el estado general de los individuos y sus compromisos.  La velocidad del trabajo y su tendencia es visible con el Backlog graph. 65 Valores que promueve Scrum  Respeto:  Más responsabilidad de equipo que “chivos expiatorios”.  Los miembros del equipo se respetan por sus debilidades y fortalezas y no por sus fallas en las iteraciones.  El equipo completo (más que el administrador), mediante auto-organización y dirección, adopta la actitud de resolver problemas “individuales” mediante la exploración grupal de soluciones dándole los recursos y la autoridad para reaccionar a los retos (tal como traer un experto consultor para compensar sus carencias de expertise). 66 Dr. Ricardo Quintero 33
  • 95 Métodos Ágiles-Scrum y XP Valores que promueve Scrum  Coraje:  La administración tiene el coraje de planear y guiar adaptativamente y confiar en el equipo evitando decirles que tienen que hacer.  El equipo tiene el coraje de tomar la responsabilidad de la auto-dirección y la auto-gestión. 67 Temas  Clasificación de Scrum  Workproducts, roles y prácticas  Errores comunes, adopción y mezcla de procesos, fortalezas y debilidades 68 Dr. Ricardo Quintero 34
  • 96 Métodos Ágiles-Scrum y XP Errores comunes y malos entendidos  No ser equipo auto-dirigido; los administradores o el Scrum Manager dirige u organiza el equipo.  No actualizar diariamente el Sprint Backlog.  Agregar nuevo trabajo individual o a la iteración.  El Product Owner no se involucra o no decide.  No hay Sprint Review.  Muchos masters.  La documentación es mala: no se habló de documentación, pero el principio ya se ha comentado –aquella que agregue valor al proceso-. 69 Errores comunes y malos entendidos  El diseño o la documentación es mala: lo mismo que la documentación.  Scrum meetings muy largas o no enfocadas.  La iteración no termina en un producto parcial integrado y probado.  Cada iteración termina en un release de producto.  Planeación predictiva. Planeación tipo PERT. 70 Dr. Ricardo Quintero 35
  • 97 Métodos Ágiles-Scrum y XP Mezcla de procesos: Scrum+UP  Las prácticas de Scrum son iguales o especializaciones de las prácticas de UP o son adiciones consistentes.  Aunque Scrum no promueve orden en las actividades, se puede aprovechar el orden de UP para los Sprints.  Cuando estudiemos XP veremos su mezcla con Scrum 71 Estrategias de adopción  En contraste a la recomendación precautoria de UP (un proyecto piloto), los creadores de Scrum motivan a las organizaciones para adoptarlo en su proyecto más difícil y crítico.  Esta recomendación atrevida la sustentan en la visión que tienen los creadores de que es una medicina fuerte con una alta razón de éxito. 72 Dr. Ricardo Quintero 36
  • 98 Métodos Ágiles-Scrum y XP Estrategias de adopción  Después de que inicia el primer proyecto, pero no antes de la segunda iteración (es decir, cuando todas las prácticas se han probado) administración ajena al proyecto y clientes potenciales se les puede invitar para observar los Scrum meetings, Sprint Planning y Sprint Reviews.  Los proyectos de segunda generación de Scrum pueden iniciar antes de complementar los primeros, aunque se debe dar tiempo de madurar al primero (algunas 3 iteraciones). Los miembros del equipo del segundo equipo se pueden beneficiar al atender alguna de las reuniones del primer equipo. 73 Lecturas recomendadas  La biblia de Scrum es: Agile Software Development with Scrum 74 Dr. Ricardo Quintero 37
  • 99 Métodos Ágiles-Scrum y XP Ejercicio  Realizaremos un ejercicio de Scrum.  Se formaran 3 equipos (no más de 7 integrantes).  Este es el Product Backlog.  Este es el ejercicio. 75 Dr. Ricardo Quintero 38
  • 100 EJERCICIO - ¿Porqué estas estimaciones predictivas fallan? LECTURA: A rational design process: How and Why to fake it 1) Lea la parte I.- THE SEARCH FOR THE PHILOSOPHER’S STONE: WHY DO WE WANT A RATIONAL DESIGN PROCESS? Conteste las siguientes preguntas: a. ¿Qué se entiende por una persona racional? ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ b. ¿Porqué el proceso de desarrollo de software es considerado irracional? ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ c. ¿Cuál es el propósito de los métodos de desarrollo de software? ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ 2) Lea la parte II.- WHY WILL A SOFTWARE DESIGN “PROCESS” ALWAYS BE AN IDEALISATION? Identifique las 7 razones por las cuales el desarrollo de software es considerado irracional. Escríbalas en una sola línea: a. _____________________________________________________________ b. _____________________________________________________________ c. _____________________________________________________________ d. _____________________________________________________________ e. _____________________________________________________________ f. _____________________________________________________________ g. _____________________________________________________________ 3) TAREA: En casa lea el resto del artículo. Escriba sus comentarios sobre el “disfraz” que es necesario colocar a nuestro proceso de desarrollo de software.
  • 101 A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT David L. Parnas Computer Science Department University of Victoria Victoria BC V8W 2Y2 Canada and Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USA and Paul C. Clements Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USA I. THE SEARCH FOR THE PHILOSOPHER'S STONE: WHY DO WE WANT A RATIONAL DESIGN PROCESS? A perfectly rational person is one who always has a good reason for what he does. Each step taken can be shown to be the best way to get to a well defined goal. Most of us like to think of ourselves as rational professionals. However, to many observers, the usual process of designing software appears quite irra- tional. Programmers start without a clear statement of desired behavior and implementation constraints. They make a long sequence of design decisions with no clear statement of why they do things the way they do. Their rationale is rarely explained. Many of us are not satisfied with such a design process. That is why there is research in software design, programming methods, structured programming and related topics. Ideally, we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in a published proof. All of the methodologies that can be con- sidered "top down" are the result of our desire to have a rational, systematic way of designing software. This paper brings a message with both bad news and good news. The bad news is that, in our opinion, we will never find the philosopher's stone. We will never find a process that allows us to design software in a perfectly rational way. The good news is that we can fake it. We can present our system to others as if we had been rational designers and it pays to pretend do so during development and maintenance. 1
  • 102 II. WHY WILL A SOFTWARE DESIGN "PROCESS" ALWAYS BE AN IDEALISATION? We will never see a software project that proceeds in the "rational" way. Some of the reasons are listed below: (1) In most cases the people who commission the building of a software system do not know exactly what they want and are unable to tell us all that they know. (2) Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack. Because we try to minimize lost work, the resulting design may be one that would not result from a rational design process. (3) Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. However, until we have separated the concerns, we are bound to make errors. (4) Even if we could master all of the detail needed, all but the most trivial projects are subject to change for external reasons. Some of those changes may invalidate previous design decisions. The resulting design is not one that would have been produced by a rational design process. (5) Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made. (6) We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to try out or use a favourite idea. Such ideas may not be derived from our requirements by a rational process. (7) Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our software with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort. For all of these reasons, the picture of the software designer deriving his design in a rational, error-free, way from a statement of requirements is quite unrealistic. No system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen. 2
  • 103 EJERCICIO - Timeboxing LECTURA: Timeboxing for top team performance 1) Lea la INTRODUCCIÓN. Conteste las siguientes preguntas: a. Según el autor ¿Cuál es la definición de un proyecto exitoso? ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ b. Complete: Timebox: Define y establece un ________________________________ y después se ajusta el __________________________________ para que lo que se desea entregar se entregue en ______________________________ adecuado. Esto asume que __________________________________________ es lo más importante y frecuentemente lo es. Hay otros aspectos a considerar también: ________________________________, ___________________________, ___________________________________ y _______________________. Más adelante los revisaremos. 2) Lea la parte THE “IRON TRIANGLE”. En un proyecto, los recursos suelen ser fijos. Lo que se puede manejar es lo siguiente (defina): a. Schedule:_____________________________________________________ b. Scope:_______________________________________________________ c. Quality:______________________________________________________ 3) Se les llama el “Triángulo de hierro” por su relación inmutable. El autor menciona dos ejemplos de esta relación. De acuerdo a su experiencia, proporcione un ejemplo más: EJEMPLO:_____________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ 4) Lea: THE LAST FEATURES y conteste: ¿Cuál es la mejor estrategia de TimeBoxing?___________________________________________________________ ______________________________________________________________________ _____________________________________________________________________. 5) Revise la Figura 2 The 90/90 Rule. ¿De que forma timeboxing contribuye a que el 10% de un sistema no nos tome el 90% del tiempo disponible?__________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ 6) Lea: THE RIGHT FEATURES. Conteste ¿Como seleccionar las características que primero se deben entregar en un sistema?____________________________________________________________
  • 104 ___________________________________________________________________ ___________________________________________________________________ __________________________________________________________________. 7) Lea: INCREMENTAL RELEASES. Mencione los pasos que sigue la estrategia de Jim McCarthy de Microsoft para entregas incrementales: (gotta have=consigue tener; should have= debería tener; nice to have=sería bueno tener) a. _________________________________________________________ b. _________________________________________________________ c. _________________________________________________________ d. _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ e. _____________________________________________________________ f. _____________________________________________________________ 8) Lea: STOP APOLOGIZING ¿Cuál fue la enseñanza que Bill Gunther le enseñó al autor cuando era un joven ingeniero de Sistemas de IBM?______________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ¿Cuál es tu opinión al respecto?_______________________________________________________________ ______________________________________________________________________ ______________________________________________________________________
  • Timeboxing for Top Team Performance Página 1 de 5 105 Timeboxing For Top Team Performance by Rick Zahniser What’s your definition of a successful software project? How about this: A successful software project delivers a quality product on time, within budget. Time is always a factor in software development, and developers are always complaining about it. “They didn’t give us enough time.” “They didn’t let us estimate; they just told us when it was due.” “We had to skip most of the system testing in order to deliver on time.” Timeboxing grabs that problem by the horns and wrestles it to the ground. (Forgive me -- I’m from Colorado!) We set an end time -- that is, a timebox -- and then adjust our scope so that we deliver what we can within the time allotted. This presumes that the schedule is the most important aspect of the project, and frequently it is. Now there are other aspects, including resources, development skill, scope and quality. Let’s look at these aspects realistically, with an eye to managing them so that we look good! The “Iron Triangle” On a given project, resources are usually fixed; and unless you believe in the Mongolian Horde Approach (hire a hundred people and hope some of them are good) the best team is a small one. Once you’ve put that team together, you’ve established their capability, at least in the short run. Now you have three aspects to manage, as shown in Figure 1. Schedule: The time when the software product is due. Scope: The functions and features delivered in the software product. Quality: The absence of defects in the product. I call these three “The Iron Triangle” because they have an immutable relationship. For example: 1. If we increase the scope, the schedule must grow, or the quality must decline. 2. If we shorten the schedule, we must decrease the scope or deliver with more defects. The best timeboxing strategy holds quality constant and reduces scope to meet a schedule. Reducing scope flies in the face of what I call “The World’s Greatest Program” syndrome -- the tendency on the part of developers to put every great feature into the first release, even if it causes us to be late. (Roland Racko calls this creeping or galloping elegance.) The customer always wants those features; they just don’t understand how much it will cost them. I’d like to acquaint you with the facts, so you can feel good about leaving some features out when you’re approaching the end of your timebox. The last features Those latest and greatest features cost more than you expect, and here’s why. Remember the 90:90 rule: The first 90% of a system takes 90% of the time: The last 10% takes the other 90% of the time! That sounds like a joke, but Figure 2 shows why it’s true. As we approach 100% complete, our progress slows down drastically. This is because we’re making tough decisions in the face of uncertainty. Moreover, they’re not very good decisions. We will probably have to make many of them over again, when we have more information. This last 10% also accounts for much of the arguing and fighting that goes on in a project. Timeboxing forces us to forgo these last features, but it also lets us avoid most of the conflict that goes with them. Pareto’s Law -- the old “80:20 rule” -- gives us another justification for procrastinating on those last features. In the systems world, it predicts that: 20% of the system will give us 80% of the payback. Now, in reality, this 20% only applies to a particular set of users. If we have a diverse set of users, we will have to http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005
  • Timeboxing for Top Team Performance Página 2 de 5 106 give each group a different 20%, but it’s reasonable to expect that we can please the vast majority of our users with 80-90% of the features. Sooner or later, we’re going to deliver those last features, but not right now! The right features Making Pareto’s Law work for you may sound like magic, but there actually is a systematic way of finding out what features you should deliver first. Ask your customers to rank the features they want. You can do this most easily in a group meeting of customers and developers. Write each feature on a Post-it®, put these on a whiteboard, and have the group rank them (1 is high, 10 is low.). Then ask your developers to estimate how difficult each feature will be to implement (1 is easy, 10 is hard) and multiply these two to give you a priority weight for each feature. On the whiteboard, build a matrix like the one I’ve shown in Figure 3. It will show you, the team and the customers which features you should implement first and which you might postpone. (Quality practitioners will recognize this process as a part of QFD or “Quality Function Deployment.”) Incremental Releases This whole process of managing features is the best way to stage incremental releases of a software product. Jim McCarthy, Program Manager for Microsoft C++ products, asserts that you can build customer confidence through a series of timely releases, which delivers a steady stream of new features. To do this, he says you have to get into a stable state, and be ready to ship at any time. Here’s a strategy for delivering that first release: 1. Define your features. 2. Prioritize them. 3. Define three subsets: • Gotta have • Should have • Nice to have 3. Build the ‘gotta have’ subset as a prototype. Define a timebox, start prototyping, and deliver what you have when you run out of time. (Since it’s a prototype, you won’t have trouble explaining why it looks incomplete.) 4. Use this early experience with the prototype to define timeboxes for your first incremental release. 5. Stay within your timeboxes, delivering the features you have ready, on time. Maintaining Quality If you’re in a stable state, you have a much better chance of controlling quality. A couple of basic metrics will demonstrate stability and dramatically improve your ability to deliver a quality product as you reach the end of a timebox. You need Defects Discovered, and Defects Corrected for each time period (days or weeks.) Figure 4 is a graph of these two measures; you can also derive (and graph) other important measures such as Defects Remaining and Mean Time to Repair. Who does this defect tracking and graphing? According to McCarthy, Microsoft has a ratio of one Quality Assurance (QA) person for every two developers on the team. This graph is a great way for QA to highlight the coordination between these two factions on your team. You can timebox anything So far, we’ve been talking about timeboxing for product delivery. As I began studying the literature on timeboxing (see sidebar) I realized that I had been doing a form of timeboxing for over a decade. Training companies frequently have a set format for their courses; for example, all of their courses may be four days long. To build a course, you start with an overall four-day timebox, and break that down into smaller timeboxes to fit within breaks and lunches. That realization led me to try timeboxing in our methodology experiments at CASELab. We put every activity into a one-to two-hour timebox and gave the participants an opportunity to expand the box “a little” but not more than 20%. We found that you can timebox any development activity, from requirements definition, to system design, to http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005
  • Timeboxing for Top Team Performance Página 3 de 5 107 paper prototyping your screens. You define a time interval, and work within it. When you run out of time, you stop, and move on. Of course, you have to be reasonable; you can’t do ten days of coding in a two-day timebox; but you actually might able to build a prototype in three days. You won’t know until you try. Stop apologizing! Early in my career, as a young IBM Systems Engineer, I was working on a SPOOLing package with Bill Gunther, an old software hand from Northrop Corporation. I suggested that, for some good reasons, we might be able to slip the package we were working on a couple of weeks from its scheduled delivery date. “NO!!” he said, vehemently. “People won’t remember why we were late; they will only remember that we were late.” That’s still true; it’s all too easy to get a reputation for always being late. If schedule is important in your software shop, you CAN be on time, if you’ll simply manage the iron triangle properly. And timeboxing is a good way to do that. ## Go to top Go to sidebar FIGURES Schedule Scope Qualit y Figure 1. The Iron Triangle http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005
  • Timeboxing for Top Team Performance Página 4 de 5 108 Figure 2. The 90/90 Rule Feature Customer Delivery Priority Rank Cost Capture existing file 3 4 12 Create new records 1 1 1 Allocate new space interactively 5 9 45 Validate keys interactively 2 2 4 Validate all fields interactively 6 6 36 Recreate file from backup 3 4 12 Update file from journal 8 7 56 Modify existing records 1 3 3 Find record by primary key 1 2 2 Find record by secondary key 2 6 12 ... etc... ... ... ... Figure 3. Feature Priority Matrix http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005
  • Timeboxing for Top Team Performance Página 5 de 5 109 Figure 4. Defects found vs. Defects fixed. Sidebar Want to Learn More About Timeboxing? The term ‘timebox’ was first used by Scott Shultz of DuPont, as a key component of Rapid Iterative Production Prototyping (RIPP), a predecessor of RAD, which Shultz developed in the early 80’s. James Kerr and Richard Hunter interview him in Inside RAD: How to build fully functional computer systems in 90 days or less. (McGraw- Hill, 1994, pp. 14-16.) In Rapid Application Development, James Martin calls timeboxing “a variant of RAD” and devotes an entire chapter to it.(Prentice-Hall, 1991, Chapter 11.) Without using the word “timeboxing”, Tom Gilb provides a cogent discussion of “Deadline pressure: how to beat it” in Principles of Software Engineering Management (Addison-Wesley, 1988, Chapter 17.) For more on QFD, see The Customer-Driven Company: Managerial Perspectives on QFD by William Eureka and Nancy Ryan (American Supplier Institute, 1988.) For an interesting discussion of creeping or galloping elegance, and incremental delivery, see Roland Racko’s “Object Lessons: Joseph and the CD-ROM of Many Colors” (Software Development, September 1994.) Jim McCarthy is a frequent speaker at Software Development and other national conferences. His talk “21 Rules of Thumb for Delivering Quality Software on Time” is a classic, available on tape from Conference Copy, Inc. 717-775-0580. (Session 04, Conf. #698D) Finally, Pascal Zachary’s Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft (Free Press, 1994) is must reading for any one who needs to understand the realities of the Iron Triangle. (It’s also a GREAT read!) About the Author. [Updated:] When this was written, Rick Zahniser was the founder & chairman of CASELab, a startup which specialized in coaching software teams to world-class performance. In 1999, he decided to watch the Turn of the Century from Belize, Central America. You can meet him and chat with him on his website http://belizenorth.com. Copyright, CASElab, 1995. All rights reserved. Go to top http://www.belizenorth.com/articles/TIMEBOX.htm 22/06/2005
  • 110 ________________________ ________________________ 1 Agile Processes The weather-cock on the church spire, though made of iron, would soon be broken by the storm-wind if it did not understand the noble art of turning to every wind. -- Heinrich Heine Many of us have lived through the nightmare of a project with no process to guide it. The lack of a process leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules, growing budgets, and poor quality. Developers are disheartened by working ever longer hours to produce ever poorer software. Once we have experienced such a fiasco, we become afraid of repeating the experi- ence. A common response to fear is to create a process that we believe eliminates what we are afraid of. We are afraid that • The project will produce the wrong product. • The project will produce a product of inferior quality. • The project will be late. • We’ll have to work 80 hour weeks. • We’ll have to break commitments. • We won’t be having fun. Our fears motivate us to create a process that constrains our activities and demands certain outputs and artifacts. We draw these constraints and outputs from past experience, choosing things that appeared to work well in previous projects. Our hope is that they will work again, and take away our fears. 7
  • 111 Chapter : 8 But projects are not so simple that a few constraints and artifacts can reliably prevent error. As errors continue to be made, we diagnose those errors and put in place even more constraints and outputs in order to prevent those errors in the future. After many projects we may find ourselves overloaded with a huge cumbersome process that greatly impedes our ability to get projects done. A big cumbersome process can create the very problems that it is designed to prevent. It can slow the team to the extent that schedules slip and budgets bloat. It can reduce responsiveness of the team to the point that they are always creating the wrong product. Unfortunately this leads many teams to believe that they don’t have enough process. So, in a kind of runaway process inflation, they make their process ever larger. Runaway process inflation is a good description of the state of affairs of the software industry circa 2000 A.D. Though there were still many teams operating without a process. The adoption of very large heavyweight processes was rapidly growing; especially in large corporations. The Agile Alliance In early 2001, motivated by the observation that software teams in many corporations were stuck in a quagmire of ever increasing process, a group of industry experts met to outline the values and principles that would allow software teams to develop quickly and respond to change. They called themselves the Agile Alliance . Over two days they worked to create a statement of values. The result was the manifesto of the Agile Alliance. Over the next three months they continued to work together to create the principles of agility. The Manifesto: a statement of agile values Manifesto for Agile Software 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 ~ That is, while there is value in the items on the right, we value the items on the left more.
  • 112 9 Chapter : : Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Individuals and interactions over processes and tools. People are the most important ingredient of success. A good process will not save the project from failure if the team doesn’t have strong players; but a bad process can make even the strongest of players ineffective. Even a group of strong players can fail badly if they don’t work as a team. A strong player is not necessarily an ace programmer. A strong player may be an average programmer, but someone who works well with others. Working well with others, communicating and interacting, is more important that raw programming talent. A team of average programmers who communicate well are more likely to succeed than a group of superstars who fail to interact as a team. The right tools can be very important to success. Compilers, IDEs, source code con- trol systems, etc., are all vital to the proper functioning of a team of developers. However, tools can be overemphasized. An overabundance of big unwieldy tools is just as bad as a lack of tools. My advice is to start small. Don’t assume you’ve outgrown a tool until you tried it and found you can’t use it. Instead of buying the top of the line, mega-expensive, source code control system, find a free one and use it until you can demonstrate that you’ve out- grown it. Before you buy team licenses for the best of all CASE tools, use white boards and graph paper until you can unambiguously show that you need more. Before you com- mit to the top-shelf behemoth database system, try flat files. Don’t assume that bigger and better tools will automatically help you do better. Often they hinder more than they help. Remember, building the team is more important that building the environment. Many teams and managers make the mistake of building the environment first and expecting the team to gel automatically. Instead, work to create the team, and then let the team configure the environment on the basis of need. Working software over comprehensive documentation. Software without docu- mentation is a disaster. Code is not the ideal medium for communicating the rationale and structure of a system. Rather, the team needs to produce human readable documents that describe the system, and the rationale for their design decisions. However, too much documentation is worse than too little. Huge software documents take a great deal of time to produce, and even more time to keep in sync with the code. If they are not kept in sync, then they turn into huge lies, and become a significant source of misdirection. I have no problem with a short rationale and structure document that the team pro- duces and keeps in sync from month to month. But I want that document to be short and
  • 113 Chapter : 10 salient. It should discuss the overall design rationale, and only the highest level structures in the system. If all we have is a short rationale and structure document, how do we train new team members about the system? We work closely with them. We transfer our knowledge to them by sitting next to them and helping them. We make them part of the team through close training and interaction. The two documents that are the best at transferring information to new team mem- bers, are the code and the team. The code does not lie about what it does. It may be hard to extract rationale and intent from the code; but the code is the only unambiguous source of information. The team holds the ever-changing roadmap of the system in their heads. There is no way to put that roadmap down on paper and transfer it to others that is faster and more efficient than interaction with the team. Many teams have gotten hung up in pursuit of documentation instead of software. This is often a fatal flaw. There is a simple rule that prevents it: Produce no document unless its need is immediate and significant. Customer collaboration over contract negotiation. Software cannot be ordered like a commodity. You cannot write a description of the software you want and then have someone develop it on a fixed schedule for a fixed price. Time and time again, attempts to treat software projects in this manner have failed. Sometimes the failures are spectacular. It is tempting for the managers of a company to tell their development staff what their needs are, and then expect that staff to go away for awhile and return with a system that satisfies their needs. But this mode of operation leads to poor quality and failure. Successful projects involve customer feedback on a regular and frequent basis. Rather than depending upon a contract, or a statement of work, the customer of the software works closely with the development team, providing frequent feedback on their efforts. A contract that specifies the requirements, schedule, and cost of a project is funda- mentally flawed. In most cases the terms it specifies become meaningless long before the project is complete. The best contracts are those that govern the way the development team and the customer will work together. As an example of a successful contract, in 1994 I negotiated a contract for a large, multi-year, half-million-line, project. We, the development team, were paid a relatively low monthly rate. Large payouts were made to us when we delivered certain large blocks of functionality. Those blocks were not specified in detail by the contract. Rather the con- tract stated that the payout would be made for a block when the block passed the cus- tomer’s acceptance test. The details of those acceptance tests were not specified in the contract. During the course of this project we worked very closely with the customer. We released the software to him almost every Friday. By Monday of Tuesday of the following week he would have a list of changes for us to put into the software. We would prioritize those changes together, and then schedule them into subsequent weeks. The customer
  • 114 11 Chapter : : worked so closely with us that acceptance tests were never an issue. He knew when a block of functionality satisfied his needs because he watched it evolve from week to week. The requirements for this project were in a constant state of flux. Major changes were not uncommon. There were whole blocks of functionality that were removed, and others that were inserted. And yet the contract, and the project, survived and succeeded. The key to this success was the intense collaboration with the customer; and a contract that gov- erned that collaboration rather than trying to specify the details of scope and schedule for a fixed cost. Responding to change over following a plan. It is the ability to respond to change that often determines the success or failure of a software project. When we build plans, we need to make sure that our plans are flexible and ready to adapt to changes in the business and technology. The course of a software project cannot be predicted far into the future. There are too many variables to account for. We simply aren’t very good at estimating the cost of a large project. The business environment that the software must serve is likely to change during the course of development. It is difficult to write reliable requirements. Customers are likely to alter the requirements once they see the system start to function. It is tempting for novice managers to create a nice PERT or Ghant chart of the whole project, and tape it to the wall. They may feel that this chart gives them control over the project. They can track the individual tasks and cross them off the chart as they are com- pleted. They can compare the actual dates with the planned dates on the chart and react to any discrepancies. But what really happens is that the structure of the chart degrades. As the team gains knowledge about the system, and as the customer gains knowledge about their needs, cer- tain tasks on the chart will become unnecessary. Other tasks will be discovered and will need to be added. In short, the plan will undergo changes in shape, not just changes in dates. A better planning strategy is to make detailed plans for the next few weeks, very rough plans for the next few months, and extremely crude plans beyond that. We should know the tasks we will be working on for the next few weeks. We should roughly know the requirements we will be working on for the next few months. And we should have a only a vague idea what the system will do after a year. This decreasing resolution of the plan means that we are only investing in a detailed plan for those tasks that are immediate. Once the detailed plan is made, it is hard to change since the team will have a lot of momentum and commitment. But since that plan only governs a few weeks worth of time the rest of the plan remains flexible. The lower resolu- tion parts of the plan can be changed with relative ease.
  • 115 Chapter : 12 Principles The above values inspired the following twelve principles. These principles are the char- acteristics that differentiate an agile process. • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The MIT Sloan Management Review published an analysis of software development practices that help companies build high quality products 1. The article found a num- ber of practices that had a significant impact upon the quality of the final system. One was a strong correlation between quality, and the early delivery of a partially func- tioning system. The article reported that the less functional the initial delivery, the higher the quality in the final delivery. Another finding of this article was a strong correlation between final quality and fre- quent deliveries of increasing functionality. The more frequent the deliveries, the higher the final quality. An agile process is one that delivers early and often. We strive to deliver a rudimen- tary system within the first few weeks of the start of the project. And we strive there- after to continue to deliver systems of increasing functionality every few weeks. Customers may choose to put these systems into production if they think they are functional enough. Or they may choose simply to review the existing functionality and report on changes they want made. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. This is a statement of attitude. The participants in an agile process are not afraid of change. They view changes to the requirements as good things, because they mean that the team has learned more about what it will take to satisfy the market. An agile team works very hard to keep the structure of their software flexible, so that when requirements change, the impact to the system is minimal. Later in this book we will learn the principles of object oriented design that help us to maintain this kind of flexibility. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. We deliver working software. And we delivery it early and often. We are not content with delivering bundles of documents, or plans. We don’t count those as true deliver- ies. Our eye is on the goal of delivering software that satisfies the customer’s needs. 1. Product-Development Practices That Work: How Internet Companies Build Software , MIT Sloan Management Review, Winter 2001, Reprint number 4226
  • 116 13 Chapter : : • Business people and developers must work together daily throughout the project. In order for a project to be agile, there must be significant and frequent interaction between the customers, developers, and stakeholders. An agile project is not like a fire-and-forget weapon. An agile project must be continuously guided. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. An agile project is one in which people are considered the most important factor of success. All other factors, process, environment, management, etc., are considered to be second order effects, and are subject to change if they are having an adverse effect upon the people. For example, if the office environment is an obstacle to the team, the office environ- ment changes. If certain process steps are an obstacle to the team, the process steps change. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In an agile project, people talk to each other. The primary mode of communication is conversation. Documents may be created, but there is no attempt to capture all project information in writing. An agile project team does not demand written specs, written plans, or written designs. They may create them if they perceive an immediate and significant need, but they are not the default. The default is conversation. • Working software is the primary measure of progress. Agile projects measure their progress by measuring the amount of software that is working. They don’t measure their progress in terms of the phase that they are in, or by the volume of documentation that has been produced, or by the amount of infra- structure code they have created. They are 30% done when 30% of the necessary functionality is working. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. An agile project is not run like a 50 yard dash; it is run like a marathon. The team does not take off at full speed and try to maintain that speed for the duration. Rather they run at a fast, but sustainable, pace. Running too fast leads to burnout, shortcuts, and debacle. Agile teams pace them- selves. They don’t allow themselves to get too tired. They don’t borrow tomorrow’s energy to get a bit more done today. They work at a rate that allows them to maintain the highest quality standards for the duration of the project.
  • 117 Chapter : 14 • Continuous attention to technical excellence and good design enhances agility. High quality is the key to high speed. The way to go fast is to keep the software as clean and robust as possible. Thus, all agile team-members are committed to produc- ing only the highest quality code they can. They do not make messes and then tell themselves they’ll clean it up when they have more time. If they make a mess, they clean it up before they finish for the day. • Simplicity--the art of maximizing the amount of work not done--is essential. Agile teams do not try to build the grand system in the sky. Rather they always take the simplest path that is consistent with their goals. They don’t anticipate tomorrow’s problems and try to defend against them today. Rather they do the simplest and high- est quality work today, confident that it will be easy to change if and when tomorrows problems arise. • The best architectures, requirements, and designs emerge from self-organizing teams. An agile team is a self organizing team. Responsibilities are not handed to individual team members from the outside. Rather, responsibilities are communicated to the team as a whole, and the team determines the best way to fulfill them. Agile team members work together on all aspects of the project. Each is allowed input into the whole. No single team member is responsible for the architecture, or the requirements, or the tests, etc. The team shares those responsibilities and each team member has influence over them. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. An agile team continually adjusts its organization, rules, conventions, relationships, etc. An agile team knows that its environment is continuously changing, and knows that they must change with that environment to remain agile. Conclusion The professional goal of every software engineer, and every development team, is to deliver the highest possible value to our employers and customers. And yet, our projects fail, or fail to deliver value, at a dismaying rate. Though well intentioned, the upward spi- ral of process inflation is culpable for at least some of this failure. The principles and val- ues of agile software development were formed as a way to help teams break the cycle of process inflation, and to focus on simple techniques for reaching their goals.
  • 02/11/2009 118 Product Backlog para un Sprint de 59 minutos • Este backlog posee un número de “items” a considerar para completar un Sprint (iteración). • El equipo puede decidir, junto con el Product Owner (el instructor), cual es el tema u objetivo del Sprint. • El Product Owner decidirá el orden de prioridad de los items. • El equipo deberá enfocarse en no más de 5 “items” para el demo del Sprint. • Se hará algo creativo (comercial, folleto, stand, poster). Backlog para turismo espacial-Marte visita la Tierra • Crear la portada, marca y/o logo • Definir los tópicos mayores para el turismo marciano. • Describir el tour “El Arte en Europa”. • Describir un tour basado en el folklore. • Esquematizar una expedición a las “7 maravillas del mundo antiguo”. • Definir los mensajes de “warning” (gravedad, oxígeno, etc.) • Sugerir opciones de vestuario. • Explicar las opciones de viaje hacia/desde Marte. • Describir un tour “Deportes humanos”. • Esquematizar la política de devoluciones. • Sugerir servicios relacionados. • Definir los medios de publicación. • Definir una campaña de 12 meses. • Establecer la forma de obtener más información. • Definir los precios de los tours. 1