Unidad 3 Introducción al Desarrollo Ágil

Unidad 3

3.1 ¿Qué es la Agilidad?

Las metodologías de desarrollo ágiles y el Software Libre son enfoques muy conocidos para el desarrollo de software. Aunque son muy diferentes, presentan muchas concordancias como, por ejemplo, los principios y valores básicos. En particular, hay muchas analogías entre el desarrollo de Software Libre y la programación extrema (enfoque al código e inclusión de cambios, por citar algunas). Este artículo presenta estos principios y valores básicos e identifica las concordancias entre ambas metodologías.

3.2 Que es el proceso ágil

Las metodologías ágiles (AMS, Agile Methods) se han desarrollado con mucho éxito en los últimos años al igual que el Software Libre (SL). Aunque estos enfoques de desarrollo de software parecen muy diferentes, presentan muchas concordancias, como demostró Koch.

Tanto las AMs como el SL empujan hacia una organización menos formal y jerárquica en el desarrollo de software y más centrada en la persona, con un énfasis mayor en:

- centrarse en el objetivo principal del desarrollo — producir un sistema de gestión con la cantidad correcta de funcionalidades. Esto significa que el sistema final tiene que incluir sólo el mínimo número de características necesarias para satisfacer por completo al cliente real.

- eliminar actividades que se relacionaron con algunos documentos 'formales' de especificaciones que no tienen una relación directa clara con el resultado final del producto. Este enfoque está claramente vinculado a la "gestión ligera" ( Lean Management).

Las AMs reconocen explícitamente sus vínculos con la gestión ligera, mientras que el SL los mantiene implícitos. Más aún, el desarrollo de software mediante las AMs o el SL parecen similares bajo varios puntos de vista, como éstos:

1. Los orígenes de ambos enfoques son bastante antiguos, pero ahora se han revitalizado con renovado interés, como reconoce explícitamente Beck para las AMs (en particular la programación extrema — XP, eXtreme Programming) y prueba Fuggetta para el SL [10].

2. Ambos son rompedores, en el sentido de que alteran valores establecidos en la producción de software.

3. Ambos han tenido éxito, mientras que enfoques más tradicionales han fallado (el proyecto C3 para AMs y el navegador de Mozilla/Firefox para el SL).

3.3 Modelo Ágil

Los principios básicos compartidos por todas las AMs están enumerados en el llamado Agile Manifesto. La tabla 1 identifica los principios de las AMs en el SL.

En conjunto, es evidente que el SL adopta muchos de los valores fomentados por los partidarios de las AMs. Tales evidencias reclaman un análisis subsecuente para determinar el grado y la profundidad de dicha adopción. Por otra parte, las AMs y el SL son clases de métodos de desarrollo de software que incluyen un amplio número de métodos específicos.

Por tanto, es importante considerar los casos específicos para determinar cómo se dan realmente en la práctica las interacciones entre las AMs y el SL, más allá de consideraciones que, por sí solas, resultan bastante inútiles al final.

3.4 Principales metodologías

Los principios fundamentales son:

1. Retroalimentación rápida: volviendo al valor de la retroalimentación, ésta debería ocurrir tan pronto como fuera posible, tener el impacto más alto en el proyecto y limitar lo más posible las interrupciones potenciales.

2. Asumir la sencillez: según lo mencionado, la sencillez es un valor muy importante. Por lo tanto, la sencillez debería ser asumida en todas las fases del desarrollo.

3. Cambios incrementales: el cambio (en su mayor parte procedente de la retroalimentación) no debería hacerse todo de una vez. Por consiguiente debería ser un proyecto permanente e incremental, dirigido a crear un sistema evolutivo.

4. Adopción del cambio: el cambio debería ser manejado con valor y no ser evitado. El sistema en su totalidad, y el código, debería ser organizado para facilitar el cambio más amplio posible.

5. Calidad del trabajo: la calidad debería ser la principal preocupación. La carencia de calidad genera revisiones y derroches que deberían ser evitados en la mayor medida posible. Otros principios de XP son:

Enseñe a aprender: la identificación de requisitos es un proceso de aprendizaje global. Por lo tanto, el aprendizaje es de suma importancia en el sistema.

b. Inversión inicial pequeña: el trabajo previo debería ser lo más escaso posible, puesto que subsiguientes cambios pueden destruirlo.

Jugar a ganar: todos los desarrollos deberían ser guiados por la clara convicción de que lo que hacemos es realmente factible. Experimentos concretos: las ideas deberían no ser validadas a través de discusiones largas y teóricas sino vía experimentaciones concretas en el código base.

Comunicación abierta, honesta: la comunicación debería ser siempre simple y fácil. El cliente no debería ocultar sus prioridades ni los desarrolladores y directivos deberían ocultar el estado actual del trabajo.

3.4.1 Cristal

Primero hay que comprender que un cristal tiene la capacidad de recibir, almacenar y liberar una orden, o sea, una intención (ya sabemos que el mayor poder del Mago reside en su voluntad, en su intención).

También comentar que cuando se habla de cristales significa que hablamos de cuarzo y derivados (cuarzo ahumado, amatista, citrino… y minerales sobre todo cristalinos). Pero el mejor sin duda es el cuarzo hialino o cristal de roca. Preferiblemente debería ser una cristalización natural, con su extremo en punta, ya que su estructura molecular original actúa como amplificador de todo tipo de energía o, en este caso, intenciones que se desean canalizar a través de él.

Una vez purificado el mineral para eliminar todo tipo de energía residual que pueda tener, hay que seguir unos pasos:

DESPEJARLO:

Se tiene que despejar de toda clase de pensamiento: Se sostiene en la mano izquierda con la punta del cristal hacia arriba y con la mano derecha a poca distancia cubriéndolo pero sin tocarlo debes concentrarte. Imagina un haz de luz blanca que fluye a través de la mano hacia la base del cuarzo, que sube por su cuerpo y sale por la punta superior. Siente como esa luz pasa hacia los lados y se introduce en el interior de nuevo.

Así queda borrada cualquier otra programación previa.

PROGRAMARLO:

Hay que pensar en lo que deseamos que transmita ese cristal, en el bien deseado, preferiblemente visualizando a esa persona (o a uno mismo) bien, con el beneficio que le deseas. Hay que tener cuidado de que no se crucen imágenes negativas. De esta manera esas imágenes quedan instaladas en el cristal y luego se verán amplificadas por la vibración natural del cuarzo, por los triángulos espirales de su punta.

3.4.2 SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Roles Principales

Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

3.4.3 DSDM

El método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM) es un método que provee un framework para el desarrollo ágil de software, apoyado por su continua implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema que reuna las necesidades de la empresa en tiempo y presupuesto. 

Es uno de un número de métodos de desarrollo ágil de software y forma parte del alianza ágil.

DSDM fue desarrollado en el Reino Unido en los años 90 por un consorcio de proveedores y de expertos en la materia del desarrollo de sistemas de información (IS), el consorcio de DSDM, combinando sus experiencias de mejores prácticas. El consorcio de DSDM es una organización no lucrativa y proveedor independiente, que posee y administra el framework. La primera versión fue terminada en enero de 1995 y publicada en febrero de 1995. La versión actualmente en uso (abril de 2006) es la versión 4.2: El framework para el Negocio Centralizado Desarrollado lanzado en mayo de 2003.

Como extensión del Desarrollo rápido de aplicaciones (RAD), DSDM se centra en los proyectos de sistemas de información que son caracterizados por presupuestos y agendas apretadas. DSDM trata los problemas que ocurren con frecuencia en el desarrollo de los sistemas de información en lo que respecta a pasar sobre tiempo y presupuesto y otras razones comunes para la falta en el proyecto tal como falta de implicación del usuario y de la comisión superior de la gerencia.

DSDM consiste en 3 fases: fase del pre-proyecto, fase del ciclo de vida del proyecto, y fase del post-proyecto. La fase del ciclo de vida del proyecto se subdivide en 5 etapas:

·        

      estudio de viabilidad,

·         estudio de la empresa,

·         iteración del modelo funcional,

·         diseño e iteración de la estructura, e

·         implementación.

DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes acorde a las necesidades de la empresa. Para alcanzar estas metas, DSDM promueve el uso del RAD con el consecuente peligro que demasiadas esquinas estén cortadas. DSDM aplica algunos principios, roles, y técnicas.

En algunas circunstancias, hay posibilidades para integrar contenido de otros métodos, tal como el Proceso Unificado de Rational (RUP), Programación Extrema (XP), y Proyectos en ambientes controlados (PRINCE2), para complementar el DSDM en la realización de un proyecto. Otro método ágil que tiene semejanzas proceso y concepto con DSDM es Scrum.

3.4.4 FDD

Desarrollo Basado en Funcionalidades

FDD con sus siglas en inglés Feature Driven Development es un enfoque á gil para el desarrollo de sistemas. Fue desarrollado por Jeff De Luca y el viejo gurú de la Orientación a Objetos Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. Dicho enfoque no hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción. Sin embargo, fue diseñado para trabajar con otras actividades de desarrollo de software y no requiere la utilización de ningún modelo de proceso específico. Además, hace énfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Al contrario de otras metodologías, FDD  afirma ser conveniente para el desarrollo de sistemas críticos.

Los desarrolladores entran en dos tipos:

·         Dueños de clases

·         Programadores jefe

Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Sólo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe actúa como el coordinador, diseñador líder y mentor, mientras los dueños de clases hacen gran parte de la codificación del rasgo.

FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

·         Desarrollar un Modelo

·         Global Construir una Lista de los Rasgos

·         Planear por Rasgo

·         Diseñar por Rasgo

·         Construir por Rasgo

En las primeras tres fases se ocupa gran parte del tiempo al inicio del proyecto, pero a medida que se avanza en las iteraciones las otras dos van ocupando más tiempo, y las primeras solo son para el refinamiento del siguiente.

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.

El Proceso

Dicho proceso consiste de cinco fases secuenciales durante las cuales el diseño y la construcción del sistema se llevan a cabo.

La parte iterativa del proceso de FDD (Diseño y Construcción) soporta un desarrollo ágil, con adaptaciones rápidas para cambios de último momento en los requerimientos.

1- Develop an Overall Modell (desarrollar modelo general)

Cuando esta fase comienza, los expertos del dominio ya tienen una idea del contexto y los requerimientos del sistema. Es probable que el documento de especificación de requerimientos ya exista. Sin embargo, FDD no hace énfasis en la recolección y administración de los requerimientos. Los expertos del dominio presentan un informe llamado walkthrough en el cual los miembros del equipo y el Chief Arquitect son informados a través de una descripción de alto nivel del sistema.

El dominio global es dividido en diferentes áreas y se realiza un walkthrough detallado para cada una de dichas áreas por parte de los expertos del dominio. Luego de cada walkthrough, un grupo de desarrolladores realizan un modelo de objetos para el área del dominio. Además, el equipo de desarrollo discute y decide cual es el modelo de objetos más apropiado para cada área del dominio. Simultáneamente, el modelo global del sistema es construido.

2- Build a Features List (construir lista de rasgos)

Los walkthroughs, el modelo de objetos y los requerimientos existentes ofrecen una buena base para construir una features list que resuma la funcionalidad del sistema a ser desarrollado. En dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente. Las funcionalidades son presentadas por cada área del dominio y éstas forman un Mejor List Sets. Dicha lista es divida en subconjuntos en base a la funcionalidad. Estas representan diferentes actividades con un área específica del dominio. La features list es revisada por los usuarios y sponsors del sistema para su validación y aprobación.

3- Plan by Feature (planear por rasgos)

En esta etapa se incluye la creación de un plan de alto nivel, en el cual la features list es ordenada en base a la prioridad y a la dependencia entre cada feature. Además, las clases identificadas en la primera etapa son asignadas a cada programador.

3.4.5 ASD

Adaptable Software Development (ASD) es un proceso de desarrollo de software que surgió de un rápido desarrollo de aplicaciones de trabajo por Jim Highsmith y Sam Bayer. Incorpora el principio de que la adaptación continua del proceso a la obra que nos ocupa es el estado normal de las cosas.

Adaptativa de desarrollo de software reemplaza la tradicional cascada ciclo con una serie repetida de especular, colaborar y aprender ciclos. Este ciclo dinámico ofrece para el aprendizaje continuo y la adaptación a la situación emergente del proyecto. Las características de un ciclo de vida de los TEA son que es misión se centró, función basada, iterativo, timeboxed , riesgo impulsada, y cambiar tolerante.

La palabra especular se refiere a la paradoja de la planificación - es más probable que asumir que todas las partes interesadas son comparativamente equivocado para algunos aspectos de la misión del proyecto, al tratar de definirlo colaboración se refiere a los esfuerzos para equilibrar el trabajo basado en las piezas predecibles. el medio ambiente (planificación y orientación de ellos) y la adaptación a la mezcla circundante incierta de los cambios causados ​​por diversos factores - la tecnología, requisitos, los interesados, los proveedores de software, etc Los ciclos de aprendizaje, desafiando a todas las partes interesadas, se basan en las iteraciones cortas con el diseño, construir y pruebas. Durante estas iteraciones el conocimiento se recoge haciendo pequeños errores basados ​​en suposiciones falsas y corregir esos errores, lo que conduce a una mayor experiencia y, finalmente, la maestría en el dominio del problema