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
