Procesos Ágiles.

Presentación del tema: "Procesos Ágiles."— Transcripción de la presentación:

1 Procesos Ágiles

2 Contenido Introducción Contexto Manifiesto Ágil Reflexiones FDD Scrum
Open-source AUP

3 Introducción ¿Son los procesos ágiles la salvación del desarrollo de software u otra manera de hacer dinero vendiendo libros? Esa fue la primer pregunta que se nos vino a la mente al empezar a componer esta presentación. Lo segundo que hicimos fue buscar en Internet (la fuente del conocimiento de la humanidad) y lo que encontramos fue lo siguiente: “Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.” Lo impresionante no era lo que intentaban hacer los procesos ágiles sino de cómo se catalogaba a las metodologías tradicionales: “tortuosos y burocráticos caminos”. A partir de ahí nos dimos cuentas que lo mejor era estudiar en que contexto surgieron los procesos ágiles.

4 Contexto Nandhakumar & Avison 1999 Truex et al. 2000 McCauley 2001
Metodologías tradicionales de desarrollo de sistemas de información “son tratadas principalmente como una ficción necesaria para presentar una imagen de control o para proveer un estatus simbólico”. Truex et al. 2000 Es posible que los métodos tradicionales sean “meramente ideales inalcanzables y hipotéticos straw-men que proveen una guía normativa a situaciones de desarrollo utópicas.” McCauley 2001 La filosofía en la cual se basan los métodos orientados a procesos establece que los requerimientos de un proyecto de software quedan congelados antes de que el diseño y desarrollo del software comience. Nandhakumar & Avison 1999 Metodologías tradicionales de desarrollo de sistemas de información “son tratadas principalmente como una ficción necesaria para presentar una imagen de control o para proveer un estatus simbólico”. Este mismo estudio indica que estas metodologías son muy mecánicas para ser usadas en detalle. Truex et al. 2000 Dicen que es posible que los métodos tradicionales sean “meramente ideales inalcanzables y hipotéticos straw-men que proveen una normativa guía a situaciones de desarrollo utópicas” Straw Man: Un argumento inventado para lograr un objetivo concreto. McCauley 2001 La filosofía en la cual se basan los métodos orientados a procesos establece que los requerimientos de un proyecto de software quedan congelados antes de que el diseño y desarrollo del software comience. Con esto no es posible contar con el nivel de flexibilidad, adaptabilidad y agilidad que permita a los desarrolladores realizar cambios tardíos en la especificación.

5 Manifiesto por el Desarrollo Ágil
Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentación exhaustiva Colaboración con el cliente sobre negociación de contratos Responder ante el cambio sobre seguimiento de un plan Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.

6 Principios Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Entregamos software frecuentemente. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. Construimos proyectos con profesionales motivados. Conversación cara a cara. Software que funciona es la principal medida de progreso. Los procesos ágiles promueven el desarrollo sostenible. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad. Simplicidad es esencial. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software frecuentemente, con una periodicidad desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte que necesitan, y confiando en ellos para que realicen el trabajo. El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara. Software que funciona es la principal medida de progreso. Los procesos ágiles promueven el desarrollo sostenible. Esponsores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se autoorganizan. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces mejora y ajusta su comportamiento de acuerdo a sus conclusiones.

7 Reflexiones Highsmith & Cockburn 2001
“lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que reconozcan a las personas como primeros implicados en el éxito de un proyecto, además de un intenso foco en la efectividad y la manejabilidad. Esto genera una nueva combinación de valores y principios que definen una visión ágil del mundo.”

8 Reflexiones (2) Hawrysh & Ruprecht 2000 McCauley 2001
Una sola metodología no puede funcionar para todo el espectro de proyectos, en vez de eso el administrador de cada proyecto debería identificar la naturaleza especifica de cada proyecto y seleccionar la mejor metodología de desarrollo aplicable. McCauley 2001 Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya que no hay un modelo de desarrollo que se ajuste a todos los propósitos imaginables.

9 ¿Cuando un método es ágil?
El desarrollo de software es Incremental liberaciones pequeñas y ciclos rápidos. Cooperativo clientes y desarrolladores trabajando juntos. Simple y Directo el método es fácil de aprender y modificar. Adaptativo es posible realizar cambios de último momento.

10 Feature Driven Development
FDD Es un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a features o funcionalidades, que son pequeñas partes del software con significado para el cliente.

11 Feature Driven Development
A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción. No requiere un modelo específico de proceso y se complementa con otras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso.

12 Roles FDD FDD define tres categorías de roles: Roles claves
- Gerente del proyecto - Arquitecto jefe - Gerente de desarrollo - Programador jefe - Propietarios de clases - Experto de dominio Roles de soporte - Administrador de entrega - “Guru” de lenguaje - “Herramientista” (toolsmith) - Administrador del sistema Roles Adicionales - “Tester” - Escritores de documentos técnicos Gerente del proyecto, es quien tiene la última palabra en materia de visión, cronograma y asignación del personal. Arquitecto jefe, este rol puede dividirse en arquitecto de dominio y arquitecto técnico. Gerente de desarrollo, puede combinarse con arquitecto jefe o gerente de proyecto. Programador jefe, es la persona que participa en el análisis de requerimientos y selecciona rasgos del conjunto a desarrollar en la siguiente iteración. Propietarios de clases, trabajan bajo la guía del programador jefe en diseño, codificación, prueba y documentación, repartidos por rasgos. Experto de dominio, que puede ser un cliente, patrocinador, analista de negocios o una mezcla de todo esto. Administrador de entrega, controla el progreso del proceso revisando los reportes del programador jefe y manteniendo reuniones breves con él, reporta al gerente de proyecto. Guru de lenguaje, conoce a la perfección el lenguaje y la tecnología. “Herramientista” (toolsmith), construye pequeñas herramientas de desarrollo o mantiene bases de datos y sitios web. Administrador del sistema, controla el ambiente de trabajo, servidores, red…etc. “Tester”, verificador del sistema producido. Escritores de documentos técnicos. Un miembro del equipo puede tener otros roles a cargo, y un solo rol puede ser compartido por varias personas.

13 FDD Proceso 1

14 Proceso 2 FDD FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el sistema. La parte iterativa soporta desarrollo ágil con rápidas adaptaciones a cambios en requerimientos y necesidades del negocio. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida.

15 Proceso Fases 1 FDD Desarrollo de un modelo general:
Cuando comienza el desarrollo, los expertos de dominio están al tanto de la visón, el contexto y los requerimientos del sistema a construir. A esta altura se espera que existan requerimientos tales como casos de uso o especificaciones funcionales. Construcción de la lista de rasgos: Los ensayos, modelos de objeto y documentación de requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos son pequeños ítems útiles a los ojos del cliente. La lista de rasgos es revisada por los usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que requieran de más de diez días se descomponen en otros más pequeños.

16 Proceso Fases 2 FDD Planeamiento por rasgos:
Incluye la creación de un plan de alto nivel, en el que los conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se asigna a los programadores jefes. Diseño por rasgos y Construcción por rasgos: Se selecciona un pequeño conjunto de rasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equipos dispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgos seleccionados. Una iteración puede tomar de unos pocos días un máximo de dos semanas. El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.

17 Experiencias en su uso Algunos “agilistas” sienten que FDD es demasiado jerárquico para ser un método ágil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos. Otros críticos sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia. FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes y recomiendan adoptarlo en forma gradual. Los promotores del método aducen que las empresas ya tienen implementadas sus herramientas de prueba, pero Subsiste el problema de su adecuación. Un rasgo llamativo de FDD es que no exige la presencia del cliente.

18 Orígenes SCRUM "The New Product Development Game" (Harvard Business Review 86116: , 1986) "The Knowledge Creating Company" Ikujiro Nonaka y Hirotaka Takeuchi (Universidad de Oxford, 1995). OOPSLA’95 (Object-Oriented Programming Systems, Languages, and Applications 1995). Jeff Sutherland Ken Schwaber. PLOP Scrum pattern (Pattern Languages of Programs 1998). Mike Beedle, Linda Rising, et al. SCRUM es un termino de Rugby, es la agrupación de los miembros del equipo. De esta manera el equipo trata de recorrer la distancia hacia la meta como una unidad, pasándose la pelota entre ellos. Primera mención "The New New Product Development Game" (Harvard Business Review 86116: , 1986) Elaborado en "The Knowledge Creating Company" Ikujiro Nonaka y Hirotaka Takeuchi (Universidad de Oxford, 1995). Formulado y presentado al Object Management Group en Jeff Sutherland en conjunto con Ken Schwaber realizaron el OOPSLA’95 (Object-Oriented Programming Systems, Languages, and Applications) en el cual se describe a Scrum como un proceso formal. Mike Beedle en conjunto con Linda Rising y otros, publicaron el PLOP Scrum pattern (Pattern Languages of Programs 1998). Jeff Sutherland, Ken Schwaber, and Mike Beedle son tres de los autores del manifiesto ágil.

19 Características SCRUM Equipos auto-organizados
El producto progresa en una serie de “sprints” que duran un mes Los requerimientos se encuentran en el “product backlog” reunidos en una lista No contiene practicas de ingeniería pre-descriptas Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos Usado para proyectos complejos con requerimientos cambiantes Basado en un control de proceso empírico Equipos auto-organizados El producto progresa en una serie de “sprints” que duran un mes Los requerimientos se encuentran en el “product backlog” reunidos en una lista No contiene practicas de ingeniería pre-descriptas Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos Usado para proyectos complejos con requerimientos cambiantes Basado en un control de proceso empírico Es usado para trabajos complejos en los cuales es imposible predecir todo lo que ocurrirá. Scrum simplemente ofrece un framework y un conjunto de practicas que mantienen todo visible. Esto permite a los “practicantes” de scrum saber que esta pasando y hacer ajustes en el momento para mantener al proyecto yendo hacia delante hacia las metas fijadas. La gente que usa Scrum usa el sentido común cada vez que ven que el trabajo se esta desviando del camino hacia la meta.

20 Control de proceso empírico
“Es típico adoptar un enfoque de modelado definido (teórico) cuando los mecanismos subyacentes por el cual el proceso opera son razonablemente bien entendidos. Cuando el proceso es demasiado complicado para el enfoque definido, el enfoque empírico es la elección apropiada.” “Process Dynamics, Modeling and Control” B. A. Ogunnaike y W.H. Ray, Bases Visibilidad Inspección Adaptación Establecer un proceso que repetidamente producirá un resultado con calidad aceptable es llamado Control de Proceso Definido. Cuando un control de proceso definido no se puede alcanzar por la complejidad de las actividades intermedias, se debe usar un control de proceso empírico. “Es típico adoptar un enfoque de modelado definido (teórico) cuando los mecanismos subyacentes por el cual el proceso opera son razonablemente bien entendidos. Cuando el proceso es demasiado complicado para el enfoque definido, el enfoque empírico es la elección apropiada.” B. A. Ogunnaike y W.H. Ray, “Process Dynamics, Modeling and Control” Hay tres cosas que sustentan toda implementación de un control de proceso empírico: Visibilidad Significa que aquellos aspectos del proceso que afecten el resultado deben ser visibles para los que controlan el proceso. Esta visibilidad debe ser clara y real para todos los involucrados. Inspección Todos los aspectos del proceso deben ser inspeccionados los suficientemente frecuente para detectar variaciones inaceptables en el proceso. La frecuencia de estas inspecciones debe tener en consideración que los procesos cambian solo por el hecho de ser inspeccionados. Adaptación Si el inspector encuentra una variación en el proceso que llevara a un producto inaceptable, debe ajustar el proceso. Este ajuste debe hacerse lo mas rápido posible para minimizar la desviación. Un ejemplo de las inspecciones es el Code Review.

21 Estructura SCRUM Corazón de SCRUM Esqueleto de SCRUM
Proceso iterativo e incremental Corazón de SCRUM Iteraciones Scrum basa todas sus practicas en un esqueleto de proceso iterativo e incremental. El circulo de abajo representa una iteración de las actividades de desarrollo que ocurren uno luego de otra. El resultado de cada iteración es un incremento del producto. El otro circulo representa la inspección diaria que ocurre durante la iteración, en la cual los miembros del equipo se reúnen, inspeccionando las actividades realizadas por otro miembro del equipo y hacer los ajustes apropiados. El ciclo se repite hasta que el proyecto se termina. El esqueleto opera de la siguiente manera: En el comienzo de una iteración, el equipo revisa que se debe hacer. Luego selecciona lo que cree que se puede agrupar en un incremento de una potencial envío de funcionalidad para el fin de la iteración. El equipo es luego dejado solo para que realice su mejor esfuerzo por el resto de la iteración. Al final de la iteración, el equipo presenta el incremento de funcionalidad que construyo para que los stakeholders puedan inspeccionar que funcionalidad y adaptaciones de tiempo se pueden hacer al proyecto. El corazón de scrum se basa en la iteración. El equipo mira los requerimientos, considera la tecnología disponible, y evalúa su complejidad, dificultades y sorpresas. El equipo analiza que se necesita hacer y selecciona la mejor forma de hacerlo. Este proceso creativo es el corazón de scrum.

22 Ciclo de vida SCRUM Todo el trabajo es realizado en Sprints (30 días)
Durante el Sprint se realizan reuniones que constituyen la inspección empírica y las practicas de adaptación de Scrum. Sprint Reunión de planeamiento del Sprint (< 8hs) Primeras 4hs Requerimientos a realizarse en el sprint Segundas 4hs Plan de trabajo del sprint Todo el trabajo es realizado en Sprints (carreras). Cada sprint es una iteración de 30 días de calendario consecutivos. Cada sprint es iniciado con una reunión de planeamiento del sprint, donde el PO y el equipo se juntan y colaboran sobre que se hará para el próximo sprint. Seleccionando del punto con mas prioridad del product backlog, el PO le comunica al equipo que es deseable, y el equipo le comunica al PO cuanto de los que es deseable cree que se podrá transformar en una funcionalidad durante el próximo sprint. Las reuniones de planeamiento de Sprint no pueden durar mas de 8 horas, la meta es ponerse a trabajar, no pensar en el trabajo. La reunión de planeamiento del sprint tiene dos partes: En las primeras 4 horas el Product Owner presenta los puntos del Product Backlog con mayor prioridad. El equipo le pregunta sobre el contenido, propósito significado, e intenciones del product backlog. Cuando el equipo sabe lo suficiente, pero antes de que terminen las primeras 4 horas, el equipo selecciona cuanto mas pueda del product backlog de lo que crea que pueda transformarse en un incremento completo de un probable despacho de funcionalidad del producto para el final del sprint. El equipo se compromete con el PO a que va a hacer lo mejor posible. Durante las segundas 4 horas, el equipo planea el sprint. Ya que el equipo es responsable de administrar su propio trabajo, necesita un plan tentativo para comenzar el sprint. Las tareas que componen este plan son colocadas en el Sprint Backlog; las tareas en el sprint backlog emergen con la evolución del sprint. En el comienzo de la segunda parte de la reunión, el sprint ha comenzado y el reloj esta corriendo hacia el fin del periodo del sprint. Juntas, las reuniones de planeamiento del sprint, Daily Sprint, Sprint review, y sprint retrospective constituyen la inspección empírica y las practicas de adaptación de scrum.

23 Ciclo de vida SCRUM Daily sprint (< 15min)
¿ Qué has hecho en este proyecto desde el ultimo Daily sprint? ¿ Qué planeas hacer en el proyecto entre hoy y la próxima reunión Daily Scrum? ¿ Qué impedimentos se te han presentado para lograr lo prometido en el Sprint y proyecto? Sprint Review (< 4hs) Presentación de lo desarrollado durante el sprint Sprint Retrospective (< 3hs) Revisión y análisis del proceso de desarrollo Todos los días el equipo se reúne por unos 15 minutos, esta reunión se llama Daily Sprint (sprint diario). En el Daily sprint, cada miembro del equipo responde tres preguntas: Que has hecho en este proyecto desde el ultimo Daily sprint? Que planeas hacer en el proyecto entreoí y la próxima reunión Daily Scrum? Que impedimentos se te han presentado para lograr lo prometido en el Sprint y proyecto? El propósito de esta reunión es sincronizar diariamente el trabajo de todos los miembros del equipo, y planificar cualquier reunión que el equipo necesite para progresar. Al final del sprint, se realiza una reunión de revisión del sprint, Sprint Review. Esta reunión dura 4 horas, en las cuales el equipo presenta, al PO y a cualquier otro stakeholder que quiera asistir, que fue desarrollado durante el sprint. La intención de esta reunión informal en la cual la funcionalidad es presentada, es intentar juntar a las personas y ayudarlos colectivamente a determinar cual es el siguiente paso que debe realizar el equipo. Luego del sprint review y antes de la próxima reunión de planeamiento del sprint, el Scrum Master lleva a cabo una reunión de retrospectiva (Sprint retrospective) con el equipo. Esta reunión dura 3 horas, en las cuales el Scrum Master alienta al equipo a revisar, dentro el framework y practicas del proceso de scrum, el proceso de desarrollo para hacerlo mas efectivo y disfrutable para el próximo Sprint.

24 Ciclo de vida

25 Roles SCRUM Product owner (dueño del producto) Team (equipo)
ScrumMaster Hay solo 3 roles en scrum: Product owner (dueño del producto) Es responsable por representar a todos los interesados en el proyecto y el sistema resultante. El PO logra el financiamiento inicial y progresivo para el proyecto, creando todos los requerimientos iniciales del proyecto, los objetivos de ganancias de la inversión (ROI: return on investment) , y los planes de liberación. La lista de requerimientos es llamada Product Backlog. El PO es responsable de usar el Product backlog para asegurar que la funcionalidad mas importante es producidas primero; esto se logra priorizando frecuentemente el product backlog para realizar un cola de los requerimientos mas importantes para realizar en la próxima iteración. Team (equipo) Es responsable de desarrollar las funcionalidades. Los equipos son administrados por si mismos, organizados por si mismos, y sus miembros habilidades cruzadas, y son responsables descifrar como poner al product backlog en un incremento de funcionalidades dentro de una iteración y administrar su propio trabajo para lograrlo. Los miembros del equipo son colectivamente responsables por el éxito de cada iteración y del proyecto como un todo. ScrumMaster Es responsable por el proceso de scrum, de enseñar scrum a todos los involucrados en el proyecto, de implementar scrum para que quepa en la cultura organizacional y todavía de los beneficios esperados, y por asegurar que todos siguen las regla y practicas de scrum. La gente que tiene estos roles son los que están comprometidos con el proyecto. Otros pueden estar interesados en el proyecto, pero no están “en la mira”. Scrum hace clara esta distinción entre los dos grupos y asegura que los que son responsables por el proyecto tienen la autoridad de hacer lo que sea necesarios para su éxito y los que no pueden interferir innecesariamente. Los roles anteriores son llamados “chanchos”, son los que están comprometidos con el proyecto; el resto son llamados “pollos”, solo están involucrados en el proyecto; estos nombres vienen de un viejo chiste: “Un pollo y un chancho están caminando por un camino. El pollo le dice al chancho, “quieres abrir un restaurante conmigo?” El chancho analiza la pregunta y le responde, “si, me gustaría. Cómo quieres llamar al restaurante?” El pollo contesta, “Jamón y Huevos!” El chancho para, espera, y responde “Pensándolo bien, No creo que quiera abrir un restaurante contigo. Yo estaría comprometido, pero tu solo estarías involucrado.” Los pollos pueden incluir stakeholders, usuarios, arquitectos del sistema y cualquiera que tenga interés en el proyecto y ese interés pueda entrometerse en la liberación regular del producto.

26 Artefactos SCRUM Product backlog Sprint backlog Incremento de una
funcionalidad del producto potencialmente despachable Product backlog  Los requerimientos para el sistema o producto sea desarrollado por le proyecto/s están listados en el product backlog. El Product Owner es responsable por su contenido, priorización, y disponibilidad del Product Backlog. EL product backlog nunca esta completo, y el uso del product backlog en el plan de proyecto es meramente un estimativo inicial de los requerimientos. El Product Backlog evoluciona con el producto, y el ambiente en el cual será utilizado. El product backlog es dinámico; la administración lo cambia constantemente para identificar que necesita el producto para ser apropiado, competitivo y útil. Mientras el producto exista, el Product backlog también existirá. Ejemplo de product backlog. Las filas son los ítems del product backlog, separadas por sub-encabezados de sprint y release. Las primeras cuatro columnas son el nombre del ítem, el estimativo inicial, el factor de complejidad, y tiempo de ajuste. EL factor de complejidad incrementa el estimativo debido a las características del proyecto que reducen la productividad del equipo. EL resto de las columnas representan los Sprint durante los cuales el product backlog es desarrollado. Sprint backlog  El sprint backlog define el trabajo, o tareas, que un equipo define para convertir el product backlog seleccionado en un potencial despacho de funcionalidad del producto. El equipo recaba un lista inicial de estas tareas en la segunda parte de la reunión de planeamiento del sprint. Las tareas deben dividirse para que cada una lleve como mucho de 4 a 16 horas para finalizarla. Solo el equipo puede cambiar el Sprint backlog. El sprint backlog es altamente visible, es una imagen real y actual del trabajo que el equipo planea realizar durante el sprint. Ejemplo del Sprint backlog. Las filas representan las tareas del Sprint backlog; las columnas representan los 30 días de sprint. Una vez que una tarea es definida, el numero estimado de horas restantes para completar la tarea son ubicadas en la intersección del a tarea y el día de sprint por la persona que trabaja en la tarea. Incremento de una funcionalidad del producto potencialmente despachables (Increment of potentially shippable product funcionality) Scrum requiere que los equipos construyan un incremento de la funcionalidad del producto en cada sprint. Este incremento debe ser potencialmente despachable, porque el product owner puede elegir implementar esa funcionalidad inmediatamente. Esto requiere que el incremento consista en código profundamente testeado, bien estructurado y bien escrito que ha sido construido en un ejecutable y que la operación del usuario de la funcionalidad sea documentada, ya sea en archivos de ayuda o en documentación de usuario. Esta es la definición de un incremento finalizado. Si un incremento de un producto, es creado durante un sprint, tiene un uso mas exigente, la organización desarrolladora usualmente define los requerimientos del producto adicionales como estándares o convenciones.

27 Experiencia en su uso SCRUM
Microsoft ha combinado los modelos de trabajo ágiles Scrum y Extreme programming para finalizar el lanzamiento de las nuevas versiones: SQL Server 2005, Visual Studio 2005 tool suite y Biztalk server 2006 integration server Microsoft ha combinado los modelos de trabajo ágiles Scrum y Extreme programming para finalizar el lanzamiento de las nuevas versiones: SQL Server 2005, Visual Studio 2005 tool suite y Biztalk server 2006 integration server.

28 Open-source El término refiere en principio a una forma de licencia que debe tener fundamentalmente las siguientes características: Libre redistribución. Código fuente abierto. La redistribución de modificaciones debe estar permitida. El software debe poder ser regalado o vendido libremente. El código fuente debe estar incluido u obtenerse libremente.

29 Proceso OSS Estas fases se realizan en forma iterativa.
Típicamente un proyecto open-source contiene las siguientes fases: Descubrimiento del problema. Búsqueda de desarrolladores voluntarios. Identificación de la solución. Implementación y testeo. Revisión de cambios en el código. Aprobación del código y de la documentación. Liberación del producto. Estas fases se realizan en forma iterativa.

30 Características del Proceso
Los siguientes factores caracterizan al proceso de desarrollo open-source. Muchos desarrolladores voluntarios. El trabajo no se asigna. Cada cual elige libremente su tarea en función de su interés personal. No hay plan de proyecto, ni plazos, ni lista de entregables. Una buena división de las tareas es esencial para el éxito del proyecto. Internet como herramienta de comunicación es esencial para el desarrollo open-source. El sistema aumenta en pequeños incrementos. Los programas son testeados frecuentemente. 4) Las tareas deben resultar interesantes para que se puedan encuentrar desarrolladores voluntarios.

31 Roles y Responsabilidades
Una típica estructura de desarrollo open-source está compuesta por varios tipos de voluntarios. Líderes de Proyecto, son quienes tienen la responsabilidad general del proyecto y usualmente han escrito el código inicial. Desarrolladores voluntarios, crean y envían código para el proyecto. Personas que identifican bugs y envían reportes de problemas al usar el software. Personas que participan de newsgroups y foros de discusión.

32 Open-Source vs. Procesos Ágiles
Diferencias Open-source opera generalmente en forma geográficamente distribuida. En tanto que, los métodos ágiles tradicionales recomiendan grupos de desarrollo pequeños y geográficamente cercanos. En open-source el cliente suele ser también desarrollador. En open-source cada participante elige su tarea. -- 2) Esto no ocurre en procesos ágiles. 3)Esto tampoco suele ocurrir en procesos ágiles.

33 Open-Source vs. Procesos Ágiles
Similitudes Desarrollo incremental, entregas tempranas y frecuentes. El programa es frecuentemente testeado. Cooperación entre cliente y desarrollador. Open-source, no incluye ninguna norma de documentación formal predefinida. En un proceso de desarrollo open-source, los requerimientos son elaborados continuamente. 1)Los proyectos se expanden por medio de pequeños incrementos. 2) --- 3) En el caso de open-source, cliente y desarrollador a menudo coinciden, esto hace, en el caso de open-source, que el proyecto cobre interés. 4) Los métodos ágiles también enfatizan el desarrollo y el debuggeo paralelo en su proceso. 5) Una de las características de los procesos ágiles es justamente la capacidad de permitir cambios a último momento de forma controlada.

34 Conclusiones OSS Se ha argumentado que open-source difiere de los procesos ágiles en aspectos filosóficos, económicos y de estructura de equipos. Sin embargo, el proceso de desarrollo open-source resulta bastante cercano al de los procesos ágiles. Organizaciones dispersas geográfica y culturalmente podrían beneficiarse de las ventajas del paradigma open-source.

35 AUP Qué es? Cuándo y cómo surge? Ciclo de vida. Fases e hitos.

36 AUP Qué es? Es una versión simplificada del RUP
Aplica técnicas ágiles: TDD: test driven development (TFD+refactoring) AMDD: agile model driven development Agile requirements change management Database refactoring

37 AUP Cuándo surge? 1988: Objectory 1.0 1998: RUP 5.0 Feb/2004: EUP
Sep/2005: AUP 13/5/2006: v1.1 AUP

38 AUP Cómo surge? Scott W. Ambler 1999: Cómo extender RUP?
2001: Cómo agilizar RUP? 2002: Publica “Agile Modeling book” AM vs XP AM vs RUP 2004: EUP 2005: AUP

39 AUP Ciclo de Vida

40 AUP Ciclo de vida Inicio Elaboración Construcción Transición

41 AUP Ciclo de vida: Inicio
Objetivos: Identificar el alcance inicial del proyecto, proveer una arquitectura potencial para el sistema, y obtener un financiamiento inicial del proyecto y la aceptación de los stakeholders.

42 Ciclo de vida: Elaboración
AUP Ciclo de vida: Elaboración Objetivos: Probar la arquitectura del sistema; hacer un prototipo de arquitectura que elimine los riesgos técnicos para probar que el proyecto es factible.

43 Ciclo de vida: Construcción
AUP Ciclo de vida: Construcción Objetivos: De forma regular e incremental, construir software que funcione y satisfaga las necesidades de mayor prioridad de los stakeholders del proyecto.

44 Ciclo de vida: Transición
AUP Ciclo de vida: Transición Objetivos: Validar e instalar el sistema en el ambiente de producción.

45 AUP Fases e hitos Inicio Elab. Cons. Tran.
Objetivos del ciclo de vida (LCO) Arquitectura del ciclo de vida (LCA) Capacidad operacional inicial (IOC) Lanzamiento del producto (PR)

46 Objetivos del ciclo de vida (LCO)
AUP Fases e hitos Objetivos del ciclo de vida (LCO) Acuerdo del alcance Def. inicial de reqs. Acuerdo del plan Aceptación de riesgos Aceptación del proceso Factibilidad Plan del proyecto Conformidad de la lista Inicio Definir alcance del proyecto Estimar costos y plazos Definir riesgos Determinar factibilidad del proyecto Preparar el ambiente

47 Arquitectura del ciclo de vida (LCA)
AUP Fases e hitos Elaboración Identificar arquitectura Validar la arquitectura Desarrollar el ambiente el proyecto Equipo del personal del proyecto Arquitectura del ciclo de vida (LCA) Estabilidad de la visión Estabilidad de la arquitectura Aceptación de riesgos Factibilidad Plan de proyecto Conformidad con la empresa

48 Capacidad operacional inicial (IOC)
AUP Fases e hitos Construcción Modelado, construcción y testeo del sistema Creado de documentación de apoyo Capacidad operacional inicial (IOC) Estabilidad del sistema Stakeholders preparados Aceptación de riesgos Plan de proyecto Conformidad con la empresa

49 Lanzamiento del producto (PR)
AUP Fases e hitos Transición Test del sistema Test de usuarios Retrabajo del sistema Instalación del sistema Lanzamiento del producto (PR) Aceptación por los stakeholders del negocio Aceptación de operaciones Aceptación de soporte Aceptación de costo y estimaciones

50 Disciplinas Definen actividades que el equipo de desarrolladores debe realizar para construir, validar y entregar un software que satisfaga las necesidades de los stakeholders. Modelado Implementación Testeo Deployment Configuration Management Project Management Environment

51 Modelado Modelado El objetivo de esta disciplina es comprender el negocio de la organización, comprender el dominio del problema abordado por el proyecto, e identificar una solución al mismo que sea viable. La disciplina de modelado de AUP comprende lo que serían en RUP el Modelo de Negocio, los Requerimientos, el Análisis y el Diseño.

52 Recomendaciones No es necesario mucho detalle durante las fases de inicio y elaboración. Model storming se realiza en el momento para obtener los detalles necesarios. El objetivo es crear modelos con la profundidad necesaria para lo que se está haciendo. La mayor parte de los modelos se descarta. Siempre hay que tener en cuenta oportunidades de reuso. La participación activa de los stakeholders es fundamental para el éxito. Se recomienda la arquitectura en capas. No hay que invertir mucho tiempo en detallar el modelado y la documentación en estas etapas, como se muestra en la fig1. Deberian llevar algunos días el Modelado Inicial de Requerimientos y el Modelado Inicial de la Arquitectura. 2) Típicamente se hace en la fase de Construcción y no debería llevar más que algunos minutos. Fig1. 3) Siempre se puede volver atrás y explicitar más detalles si se necesita. 4) Una minoría de modelos se mentienen. 5) Esto no se refiere sólo al código.

53 Agile Model Driven Development

54 Modelado Fase a Fase Inicio
Explorar la utilización del producto escribiendo casos de uso. Identificar los procesos de negocio por medio de la creación de diagramas de flujo de datos. Identificar las principales entidades de negocio y sus relaciones. Identificar las principales reglas de negocio y los principales requerimientos técnicos.   Comenzar el desarrollo de un glosario que contenga los términos importantes técnicos y del negocio. 3) Esto se hace trabajando en un dominio reducido del negocio.

55 Modelado Fase a Fase Elaboración Identificar riesgos técnicos.
Modelado de la arquitectura. Realizar un prototipo de la interfaz de usuario. Los artefactos de requrimientos, en particular los casos de uso y los requerimientos técnicos pueden revelar potenciales riesgos del proyecto. 2) Al construir el prototipo de la arquitectura puede ser necesario hacer model storming para pensar como resolver ciertas partes de la arquitectura. 3) En paralelo con el modelado de la arquitectura debiera realizarse un prototipo de la interfaz que contenga las pantallas principales. No se necesita hacer mucho prototipado en esta fase porque los requerimientos seguramente van a cambiar y entonces el trabajo será descartado. El objetivo debería ser entender las principales pantallas de la interface y identificar el “look and feel” básico del producto.

56 Modelado Fase a Fase Construcción
Participación activa del stakeholder y modelado inclusivo. Mostrar los detalles de los casos de uso. Explorar reglas de negocios y requerimientos técnicos con la misma profundidad. Aplicar model storming para el diseño. Puede resultar útil realizar diagramas de secuencia UML, modelo de deployment, diagramas de clase UML, modelo de seguridad frente a amenazas, modelos de datos físicos. Documentar las decisiones de diseño críticas. La idea es que los stakeholders participen del modelado. Para esto se usan herramientas y técnicas sencillas, cuanto más sencillas mejor. 2)Para esto se sugiere usar diagramas de actividad UML en lugar de descripciones textuales. 3) --- 4)En las iteraciones de Construction se debe realizar sólo el modelado suficiente para resolver un único requerimiento antes de implementarlo. 5)No es necesario utilizarlas todas, depende del proyecto.  6)Se recomienda documentar las decisiones que no sean obvias y aquellas que puedan resultarle interesantes a alguien en el futuro. Estas decisiones documentadas pueden ser consideradas como un comienzo para el documento general del sistema que se finaliza en la etapa de transición.

57 Modelado Fase a Fase Transición
Aplicar model storming para intentar comprender la causa de defectos detectados. Finalizar la documentación general del sistema. 1) -- 2) El mejor momento para terminar la documentación general del sistema es en esta fase donde el alcance del sistema está verdaderamente estabilizado.

58 Implementación Consejos Programación por pares
Objetivo Transformar el modelo realizado en código ejecutable y realizar tests de nivel básico, en particular tests unitarios. Consejos Programación por pares Desarrollo dirigido por tests (TDD) Modelar antes de codificar Seguir guías y estándares de codificación Rescribir el código y los esquemas de base de datos Tener ambientes de desarrollo separados (sandboxes) Objetivo Transformar el modelo realizado en código ejecutable y realizar tests de nivel básico, en particular tests unitarios. Programación por pares, puede incrementar la calidad del trabajo, su aprendizaje y productividad. Desarrollo dirigido por tests (Test driven development TDD), se escriben primero los tests y luego se escribe suficiente código como para satisfacer dichos test. Modelar antes de codificar, un dibujo puede valer mas que mil líneas de código. Modelar antes de la codificar, aunque sea en un pizarrón, puede prevenir el retrabajo. Seguir guías y estándares de codificación. Rescribir el código y los esquemas de base de datos para mantenerlo con alta calidad. Tener ambientes de desarrollo separados (sandboxes).

59 Implementación - Fases
Inicial Prototipo Técnico Elaboración Probar la arquitectura Construcción Testear primero Realizar builds continuamente Desarrollar la lógica del dominio Desarrollar la interfaz grafica Desarrollar el esquema de datos Desarrollar interfaces para sistemas externos Escribir scripts para conversión de datos Transición Corregir defectos Inicio Prototipo Técnico You might need to "spike" a small aspect of a requirement in order to understand it sufficiently, enabling you to estimate the effort required.  These prototypes are typically small, "throw away" pieces of code. User interface prototyping.  For most stakeholders the user interface (UI) -- the screens, reports, and manuals -- is the system.  When the UI is potentially complex, or when your stakeholders want to see what they're going to get before they buy it, you will want to consider prototyping at least the main screens/pages.  The UI prototype, usually a throw away at this point, would be used to convince your stakeholders that you understand their needs (which you would explore as part of your modeling efforts). Elaboración Probar la arquitectura   The critical activity within the Elaboration phase is to identify a potential architecture and then prove that your architecture works via the development of an end-to-end architectural prototype for your system, thereby mitigating much of the technical risk on your project.  Technical prototypes such as this are production quality code that forms the foundation, or skeleton, of your system. Construcción Testear primero Take a TDD-based approach to all aspects of implementation. Realizar builds continuamente   Daily builds are a good start, but ideally you want to build your system whenever the source code changes.  Automate this using a product like Cruise Control which monitors your version control system for changes to your code and rebuilds as needed. Desarrollar la lógica del dominio   Implement your business logic in your domain/business classes. Desarrollar la interfaz grafica   The user interface is the system to most of your users.  Strive to make your software as usable as possible by following common usability and user interface design strategies. Desarrollar el esquema de datos   Your data schema should be evolved in step with your domain and user interface code.  You will need to refactor your database just like you refactor your other types of code. Desarrollar interfaces para sistemas externos   You will often need to access existing functionality within legacy systems.  This may be done via a variety of means, including a web services interface, a C-API, stored procedures, and so on.  Legacy analysis is often an important part of your modeling efforts. Escribir scripts para conversión de datos   You will often need to access legacy data sources.  These data sources often suffer from design and/or quality problems and as a result you will need to write data conversion scripts to put the data feed(s) into a useable format.  Transición Corregir defectos Your focus shifts to fixing the defects found as a result of testing.

60 Implementación - TDD Objetivo Escribir código claro y limpio Enfoque
Se debe testear con un propósito, y saber porque se esta testeando y hasta que nivel testearlo TDD Escribir el test Escribir el código para satisfacer el test Rescribir el código With traditional testing a successful test finds one or more defects.  It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem.  More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.  As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system.  To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. 

61 Test Objetivo Realizar una evaluación objetiva para asegurar la calidad. Esto incluye buscar defectos, validar que el sistema funcione como debería, y verificar que se cumplen los requerimientos. Consejos Realizar test durante el ciclo de vida (FLOOT) Desarrollo dirigido por tests (TDD) Automatizar el test suite Realizar practicas que promuevan la revisión continua Si vale la pena crearlo, vale la pena validarlo Realizar test de aceptación para los requerimientos y los artefactos de testeo Objetivo Realizar una evaluación objetiva para asegurar la calidad. Esto incluye buscar defectos, validar que el sistema funcione como debería, y verificar que se cumplen los requerimientos. Sugerencias Realizar test durante el ciclo de vida (FLOOT Full Lifecycle Object Oriented Testing) Desarrollo dirigido por tests (Test driven development TDD) Técnica de implementación que promueve el desarrollo de software de alta calidad Automatizar el test suite Para poder realizar soporte durante la evolución del desarrollo Realizar practicas que promuevan la revisión continua Como programación por pares, modelar en equipo, etc. Da como resultado menos necesidad de revisión tradicional. Si vale la pena crearlo, vale la pena validarlo Realizar test de aceptación para los requerimientos y los artefactos de testeo

62 Test - FLOOT En este diagrama se pueden ver los distintos artefactos y practicas a realizarse durante el proyecto. Si realizamos tests en todos las etapas del proceso de producción, obtendremos un producto final con mayor calidad

63 Test - Fases Inicio Plan de testeo inicial
Realizar una revisión de los artefactos iniciales de la administración del proyecto Realizar una revisión de los modelos iniciales Elaboración Validar la arquitectura Desarrollar el modelo de testeo Construcción Testear el software Transición Validar el sistema Validar la documentación Finalizar el modelo de testeo Inception Initial test planning.  Should be very high-level at first.  The main goal is to identify how much testing you'll need to do, who will be responsible for it, the level of stakeholder participation required, and the types of tools and environments required (an Environment discipline issue). Review initial project management artifacts.  Towards the end of this phase the initial project plan, vision, and so on should be available.  These artifacts are often reviewed, typically as part of the milestone review, by key project stakeholders. Review initial models.  A high-level, initial requirements model, and perhaps even an initial architecture model, should be produced by your modeling efforts.  You may choose to review this work with stakeholders, particularly if you want to communicate the scope and potential architecture of your system to a wider range of people than were actively involved in the development of the models. Elaboration Validate the architecture.  You should take a test-driven development (TDD) approach to building your technical prototype which proves the architecture of your system.  An important aspect of the milestone review is the validation of the architecture, which might be something as simple as presenting an overview of the architecture and the results of your prototyping efforts to your stakeholders.  Or, it might be something as complex as a formal review of all your work during this phase.  Evolve your test model.  Your team will develop a regression test suite, comprised of unit tests from your test driven development (TDD) efforts in implementation, your acceptance tests from your modeling efforts, and your system tests (e.g. for function, integration, load, ... testing).  You may also need to maintain traceability between your requirements, tests, and source code to show how you have validated the implemented requirements.  At this point your defect reports would simply be the output of your test suite. Construction Test the software.  In addition to unit testing by developers you need to do installation testing of your deployment scripts, system testing efforts such as load/stress testing and function testing, and user acceptance testing.  Because your software evolves throughout your projects so will your test suite.  The more often you promote your code into a pre-production test environment, and then test it appropriately, the better your Transition phase testing activities will be. Evolve your test model.  See above. Transition Validate the system.  Your focus will be on "testing in the large" activities such as system testing, integration testing, acceptance testing, and pilot/beta testing.  Your goal is to fully test the system within your pre-production testing environment(s). Validate the documentation.  Your system documentation (system overview, user, support, and operations documentation), and your training materials will need to be validated.  This can be done in reviews or better yet as part of your pilot/beta testing. Finalize your test model.  You will continue to run your regression test suite, and update it as needed, until your system is ready to be deployed into production.  Your defect reporting will likely become more formal, the found defects will likely be recorded, along with appropriate details, so that developers can implement fixes.

64 Deployment Objetivo Planificar la liberación del sistema. Sugerencias:
Desarrollar los scripts de instalación/desinstalación durante la fase de construcción. Tener un área de pre-producción donde poder validar el sistema antes de la liberación. Dentro del objetivo, mediante la ejecución de este plan lograr un sistema en producción correcto y usable para los usuarios finales.

65 Deployment Tener en mente los periodos de pausa en la organización, ya que en estos periodos no se podrá realizar la liberación. Definir puntos de decisión (seguir/no seguir) . Ser capas de desinstalar el sistema si surgen problemas. Realizar testeo de scripts instalación/desinstalación. Tenerlo en mente para la planificación del plan de liberación. Definir puntos clave o de riesgos para tomar la decisión de seguir o no.

66 Deployment

67 Deployment Fases Inicial: - Identificar la liberación potencial.
- Comienzo de la planificación de la liberación. Elaboración: - Actualizar el plan de liberación.

68 Deployment Fases Construcción: - Desarrollo de los scripts.
- Desarrollo de las notas de liberación. - Desarrollo inicial de la documentación. - Actualización del plan. - Liberación pre-producción.

69 Deployment Fases Transición: - Finalización del empaquetado del
sistema. - Finalización de la documentación. - Anuncio de la liberación. - Entrenamiento del personal.

70 Roles y Responsabilidades 1
AUP define los siguientes: DBA, administrador de bases de datos Agile Modeler, responsable de crear y desarrollar modelos. Configuration Manager, responsable de proveer toda la infraestructura necesaria para el equipo de desarrollo. Deployer, responsable de la liberación del sistema. DBA, persona que colabora con el equipo de desarrollo en el diseño y soporte de la aplicación. Agile Modeler, modelos de inmplementación Deployer, responsable de la pre-liberacion (ambiente de testeo).

71 Roles y Responsabilidades 2
Developer, escribe, realiza pruebas unitarias y construye el software. Process Engineer, desarrolla, adapta y mantiene el proceso de software de la organización. Project Manager Reviewer, evalua los artefactos generados por el proyecto. Deployer, responsable de la pre-liberacion (ambiente de testeo). Process Engineer, define documentación del proceso de desarrollo, una guía ejemplos ..etc. Project Manager, gerencia el proyecto, responsable de construir las relaciones con stakeholders, definir planes ..etc.

72 Roles y Responsabilidades 3
Stakeholder Technical Writer, responsable de producir la documentación para los stakeholders, documentación operacional, de soporte y para usuarios. Test Manager, responsable de la planificación del testeo del sistema. Tester, responsable de escribir y ejecutar las pruebas. Stakeholder. Usuarios directos e indirectos, miembros del equipo de desarrollo..etc. Technical Writer, Test Manager, eleborando planes.

73 Roles y Responsabilidades 4
Tool Specialist, responsable de seleccionar, adquirir, configurar las herramientas a utilizar. Un mismo rol puede ser asumido por varias personas. Una persona puede asumir varios roles.

74 Entregables Consejos Mantener los entregables tan simples y concisos como se pueda. Se necesita mucha menos documentación de la que se piensa. Trabajar conjuntamente con la gente que crea los entregables, para producir sólo lo necesario. Documentos ágiles son justo lo suficientemente buenos. Producir documentos es la peor manera de comunicar la información. Utilizar pizarrones, papel y Wikis para modelar y capturar la documentación.

75 Entegables Minimos Sistema Código Fuente Casos de Testeo
Scripts de Instalación Documentación del Sistema Release Notes Modelo de Requerimientos Test de Aceptación, Procesos de Negocio, Dominio, Casos de Uso, Interfaz de Usuario Modelo de Diseño El mejor lugar para documentar el diseño es en los test unitarios y en el código fuente Sistema: el software, hardware y documentación a implantar en producción. Código Fuente Casos de Testeo: test de aceptación, unitarios, de sistema, etc. Script de Instalación Documentación del Sistema Release Notes: Notas de Liberaciones, “buenas cosas a saber de cada versión”. Modelo de Requerimientos: test de aceptación, modelo de procesos de negocios (BPM), modelo de dominio, modelo de casos de uso, modelo de interfaz de usuario. Modelo de Diseño: “El mejor lugar para documentar el diseño es en los test unitarios y en el código fuente”. Incluye modelo fisico de los datos, modelo de interfaz de usuario, etc.

76 Otros… Oportunidades de Automatización Reportes de Defectos
Una lista Reportes de Defectos Un mail o una planilla Excel Modelo de Interfaz de Usuario Un papel o una pizarra Oportunidades de Automatización: una lista de las cosas que se pueden automatizar. Reportes de Defectos: Manejo de los pedidos de cambios al sistema. Modelo de Interfaz de Usuario: prototipos en papel, esquemas en pizarras son suficientes en fases inicial y elaboración.

77

78 Filosofía Los integrantes saben lo que hacen. Simple Ágil
Todo es Conciso Ágil Mantener el foco en las actividades de alto valor. Independiente de la Herramienta Brinda soporte a herramientas CASE Customizable Los integrante saben lo que hacen. Simple y Ágil Mantener el foco en las actividades de alto valor. Independiente de la Herramienta Soporta Herramientas CASE Customizable

79 Y Entonces… Casos de Éxito ?
“AUP no es para todos, ningún proceso lo es. AUP es adecuado si se busca una versión ágil y racionalizada del Unified Process.”

80 ¿ Preguntas ?