modelos ágiles

Este capítulo presenta los modelos que tienen menos énfasis en la configuración de la actividad y más énfasis en los factores de
desarrollo pragmáticos y humanos. El ágil, anteriormente también conocido como procesos ligeros, Ellos se están desarrollando
rápidamente y varios enfoques se pueden encontrar en la literatura. En este capítulo son algunos métodos representativos, comenzando
con FDD ( la sección 4.1 ), O Impulsado funcionalidad de desarrollo, Todavía tiene cierto grado de prescripción y actividades que detallan
que no es común a otros métodos considerados ágil. Otro modelo similar es el DSDM ( sección 4.2 ), O Sistemas método de desarrollo
dinámico. Un método más radical de un tanto en relación a huir de las recetas y la gestión según invertir en el equipo para que pueda
auto-organizarse es la scrum ( sección 4.3 ). El modelo XP ( sección 4.4 ), O

La programación extrema, es también un pequeño método basado en las actividades de venta con receta, pero así como la scrum,
tiene reglas bien definidas acerca de cómo el equipo debe estar organizada como las interacciones y las reuniones deben tener lugar e incluso en
el escritorio debe ser organizado de tal manera que la productividad y el éxito personal y empresarial se maximizan. Crystal Clear ( sección 4.5 )
Es el método más ligero de los métodos de desarrollo de la familia de cristal, que son personalizados con el tamaño y complejidad del proyecto.
Por último, TEA ( sección 4.6 ) o
Desarrollo de Sistemas Adaptativos Es un método ágil que se aplica sistemas adaptativos complejos de ideas.
modelos de desarrollo de software ágil siguen una filosofía diferente de la filosofía de modelos prescriptivos. En lugar de
presentar un "molde" con fases o tareas a realizar, que se centran en los valores humanos y sociales.

Aunque los métodos ágiles son generalmente más ligeros, que es un error verlos como modelos para procesos menos complejos o
simplistas. No sólo es la simplicidad, pero se centran más en los resultados que en el proceso.

Los principios de los modelos ágiles se colocaron en clara Manifiesto ágil ( Ágil 2011) 1 y firmada por 17 investigadores en el
campo, entre ellos Martin Fowler, Alistair Cockburn y Robert Martin. Los estados de manifiesto:

Estamos descubriendo mejores formas de desarrollo de software en la práctica y ayudar a otros a hacer. A través de este trabajo llegamos a
los siguientes valores:

a) Los individuos y las interacciones son procesos y herramientas anteriores.

b) software que trabaja sobre una amplia documentación es.

Disponible en: <agilemanifesto.org/> . Consultado el 21 de enero 2013.

1
45
 modelos ágiles 46

c) Colaboración con el cliente está por encima de la negociación del contrato.

d) Responder a los cambios ha terminado después de un plan.

Es decir, mientras que el primero se valoran, otros serán más valor.

Esto no significa que los modelos ágiles no valoran procesos, herramientas, documentación, contratos y planes. Sólo significa que estos
elementos tendrán más significado y más valor después de los individuos, las interacciones, el software de trabajo, colaboración con el
cliente y la respuesta a los cambios también se consideran importantes.

procesos bien estructurados de nada si la gente no sigue los mismos; software bien documentado también no ayuda si usted no cumple con
los requisitos o no funciona, y así sucesivamente.
El manifiesto ágil se complementa con doce principios mencionados a continuación:

a) Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor.
b) Los cambios en los requisitos son bienvenidos, incluso en las etapas finales del proyecto. Los procesos ágiles utilizan el cambio
como una ventaja competitiva para el cliente.
c) La entrega de software a menudo en intervalos de entre dos semanas a dos meses, prefiriendo
intervalo más corto.
d) (administradores la gente de negocios) y los desarrolladores deben trabajar juntos diariamente en todo el desa-
ción del proyecto.
e) Construir proyectos en torno a individuos motivados. Dales el medio ambiente y el apoyo y la confianza de que lo harán
el trabajo.
f) La forma más eficiente y eficaz para el tratamiento de la comunicación entre los / desde el equipo de desarrollo es la charla
"cara a cara".
g) el software de trabajo es medida principal de progreso.
h) Los procesos ágiles promueven el desarrollo sostenible. Financiadores, los usuarios y los desarrolladores deben
ser capaz de seguir el ritmo de forma indefinida.
i) La atención continua a la excelencia técnica y el buen diseño mejorar la agilidad.
j) Simplicidad - el arte de maximizar la cantidad de un no hecho - es esencial.
k) Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
l) A intervalos regulares, el equipo reflexiona sobre cómo llegar a ser más eficaz, a continuación, ajusta su comportamiento
de acuerdo con este objetivo.

Un número significativo de los modelos actuales se considera ágil. Algunos incluso son muy diferentes, pero casi todos consideran que los
principios mencionados como puntos clave en su funcionamiento. En las siguientes subsecciones se presentarán los modelos ágiles más
conocidos y más representativos: FDD, DSDM, scrum,
XP, Crystal Clear y ASD.

4.1 FDD - Desarrollo de funciones-Driven

El FDD o Desarrollo de funciones-Driven 2 ( Desarrollo impulsado funcionalidad) es un método ágil que enfatiza el uso de la orientación a
objetos. Este modelo fue introducido en 1997 por Peter Coad y Jeff De Luca y como la evolución de un proceso más antiguo (Coad, De
Luca y Lefebvre, 1997).
Dos cambios significativos modelo fueron presentados por Palmer y Mac Felsing (2002) y Anderson (2004).

El FDD tiene sólo dos fases principales:

a) Diseño y planificación: implica pensar un poco (1-2 semanas) antes de empezar

construir.
b) la construcción: ciclos iterativos de desarrollo de productos en 1-2 semanas.

2 Disponible en: < www.featuredrivendevelopment.com/ > . Consultado el 21 de enero 2013.

 modelos ágiles 47

Figura 4.1 Modelo FDD.

El diseño y la planificación etapa tiene tres disciplinas (llamados "procesos" en FDD):

a) DMA - Desarrollar Modelo Integral, en la que recomienda el uso de modelado orientado a objetos.
b) CLF - Lista de características de construcción, que se puede aplicar para identificar la descomposición funcional
las características que el sistema debe proporcionar.
c) PPF - Plan de funcionalidad, en la planificación de los ciclos iterativos se realiza de acuerdo con el
características identificadas.

Desde la construcción incorpora dos sujetos (casos):

a) DPF - Diseño de funciones, correspondiente a lograr diseño objetos del sistema orientado.
b) ACB - Construir por rasgo, correspondiente a construir y probar el software utilizando el lenguaje
y probar técnica orientada a objetos.

El modelo de la estructura general se puede representar como una Figura 4.1 .

4.1.1 DMA - D ESARROLLAR M Odel la brAngente

La primera fase comienza con el desarrollo de un modelo de negocio global, seguido por el desarrollo de modelos más específicos
(dominio). Crear grupos de trabajo formados por los desarrolladores y expertos en el dominio. Los diversos modelos específicos así
desarrollada se evalúan en una taller y una combinación de los mismos está formado para ser utilizado como un modelo de aplicación.

Los modelos de negocio y de dominio están representados por los diagramas de clases y su construcción debe ser dirigido por un
modelista con experiencia en la orientación a objetos. A continuación, este modelo de clases o modelo conceptual se perfeccionarán en la
disciplina DPF (Diseño de funciones).
Para iniciar el desarrollo del modelo integral, es necesario que algunos papeles ya se han definido, en especial el arquitecto principal,
los líderes de los programadores y expertos en el dominio.
Las actividades individuales que conforman esta disciplina son:

a) Formar el equipo de modelado: Es una actividad obligatoria en la responsabilidad del director del proyecto. la
los equipos deben ser ensamblados con los expertos de dominio, los clientes y desarrolladores. No se hará girar entre los miembros
del equipo para que todos puedan ver el proceso de modelado en acción.
b) Estudio llevado a cabo en el dominio: Es una actividad obligatoria por la responsabilidad del equipo de modelado.
Un experto del dominio debe presentar su área de dominio para el personal, especialmente los aspectos conceptuales.
 modelos ágiles 48

c) Estudiar la documentación: Es una actividad opcional en la responsabilidad del equipo de modelado. El equipo
el estudio de la documentación que es posiblemente disponible sobre el dominio del problema, incluyendo los sistemas de legado.

d) Desarrollar el modelo: Es una actividad obligatoria bajo la responsabilidad de modelar equipos específicos
a mantenerse. Grupos de hasta tres personas trabajarán para crear modelos candidatos para sus áreas de dominio. El arquitecto jefe puede
considerar la presentación de los equipos de un modelo básico para facilitar su trabajo. Al final, los equipos presentan sus modelos, que se
consolidan en un único modelo.
e) Refinar el modelo de objetos integral: es una actividad obligatoria en el arquitecto principal responsable
y el equipo de modelado. Las decisiones adoptadas para el desarrollo de modelos específicos de dominio pueden afectar a la forma del
modelo de negocio global, que luego debe ser refinado.
El resultado de estas actividades debe ser revisado por el equipo de modelado (verificación interna) y también por el cliente o por
expertos en el dominio (de verificación externa). Los resultados esperados de este grupo de actividades son:

f) la modelo conceptual, presentado como un diagrama de clases y sus asociaciones.

g) métodos y atributos, posiblemente identificado para las clases.
h) Los diagramas de secuencia o máquina de estados para situaciones que requieren este tipo de descripción.
i) comentarios en el modelo para indicar qué ciertas decisiones diseño Fueron llevados en vez
otra.

Las técnicas para construir tales diagramas de clase, secuencia de máquina de estado y se pueden encontrar en los capítulos 2 y 7
Wazlawick (2011).

4.1.2 ClF - C uilding l LISTA DE F funcionalidades

Este curso identificará las características que cumplen con los requisitos. El equipo se descompondrá las áreas de negocio de dominio, de
acuerdo con la disciplina de DMA. Las áreas de negocio se dividen en actividades comerciales y estos, a su vez, en los pasos de negocio ( Figura
4.2 ). El proceso es algo similar a un análisis de los casos de uso en la que no habría áreas de negocio ( paquetes), casos de uso como
actividades comerciales y pasos casos de uso expandidos como pasos de negocio.

Para iniciar las actividades, es necesario que los expertos de dominio, desarrolladores, líderes y de los principales arquitectos están disponibles.

El curso consta de una sola actividad: crear una lista de características, que es lista obligatoria y función de la responsabilidad
del equipo (formado por los principales desarrolladores de la disciplina anterior).
Así que el equipo mostrará una lista de funcionalidad en tres niveles:

a) áreas de negocio, provenientes de actividades de DMA. Por ejemplo, "ventas".

b) actividades comerciales, que son la descomposición funcional de las áreas de negocio. Por ejemplo, el registro de la solicitud,
requiriendo una propuesta, las ventas de discos pago, etc.
c) Pasos de la actividad empresarial, que son la descripción secuencial de las características necesarias para llevar a cabo
actividades empresariales. Por ejemplo, la identificación del cliente para ordenar, registrar el producto y la cantidad de la orden, aplicar el descuento
estándar para la solicitud, etc.

características no acciones deben llevarse a cabo en la tecnología (como "ventana abierta" o "menú de acceso"), pero las acciones que tienen
significado para el cliente, independientemente de la tecnología. Buenas características deberían poder ser designado como una instancia de la
<objeto acción resultado> tríada . Por ejemplo, "mostrar las ventas totales en el mes" o "registro del acuerdo contraído."

Figura 4.2 Marco conceptual de la lista de características.

 modelos ágiles 49

Se espera que el tiempo para implementar una característica no sea más de dos semanas, y este un límite absoluto, ya que el
tiempo esperado sería de unos pocos días. Características con el esfuerzo estimado por menos de un día no necesitan ser
considerados en la lista de características, pero es probable que sean parte de otro más amplio. Por otro lado, cuando una característica
parece tomar más de dos semanas para desarrollarse (por una persona), que debe ser dividida en pequeñas características.

La evaluación de esta actividad también se puede hacer internamente por la lista de características del equipo o externamente por los
usuarios, clientes y expertos en el dominio.
Las salidas de esta actividad son:

a) Lista de las áreas de negocio.

b) Para cada área, una lista de las actividades comerciales de la zona.
c) Para cada actividad, una lista de los pasos de la actividad o características que permiten llevar a cabo la
actividad.

4.1.3 PTT - P para lAnejAr F unCionAliDADe

Este curso, aún en la primera fase de la FDD, tiene como objetivo generar el plan de desarrollo para la siguiente fase, que está formado por
ciclos iterativos. El plan indicará que se va aplicar la lista de las actividades de negocio definidas en CLF y cuándo. El planificador debe tener
en cuenta los siguientes aspectos para agrupar y priorizar las actividades comerciales:

a) La complejidad de las características: en función del riesgo, las actividades con mayor funcionalidad com-
complejidad se debe tratar en primer lugar.
b) Las dependencias entre características en términos de clases: Las funciones que dependen deben preferencias
rencialmente abordarse en conjunto, ya que esto evita la fragmentación de las clases trabajadoras de los diferentes equipos.

c) la carga de trabajo del personal: Se debe utilizar un método de estimación (Capítulo 7), que se conoce
el esfuerzo para la realización de cada actividad o funcionalidad, y el trabajo debe ser atribuido al equipo debido a su
capacidad y la estimación.

A diferencia de otros métodos ágiles, las FDD propone que la propiedad de clase se atribuye a los desarrolladores principales, es decir, cada
uno responsable de un subconjunto de las clases. Así que para hacer el reparto de la carga de trabajo, en general, también definirá la
propiedad de clase.
La entrada a las actividades de esta disciplina es lista de características construida en CLF. Hay cuatro actividades de
la disciplina FPP:

a) Formar el equipo de planificación: Es una actividad obligatoria de la responsabilidad del director del proyecto.
Este equipo debe estar formado por el director de desarrollo y los programadores principales.
b) Determinar la secuencia de desarrollo: es una actividad obligatoria la responsabilidad del equipo
la planificación. El equipo debe determinar el plazo para la finalización del desarrollo de cada una de las actividades comerciales. Este
período se determinará en función de meses y años, o plazos mensuales. La secuencia del desarrollo debe construirse teniendo en
cuenta los siguientes factores:
j Priorizar las actividades con características más complejas o de alto riesgo.
j Asignar actividades juntos o características dependientes el uno del otro si es posible.

j Considere marcos externos, en su caso, para crear liberación s.

j Considere la distribución del trabajo entre los propietarios de las clases.

c) Asignar actividades comerciales a los programadores principales: Es una responsabilidad actividad obligatoria
el equipo de planificación y determinará qué líderes programadores propias actividades que comerciales. Esta asignación de
propiedad debe hacerse teniendo en cuenta los siguientes criterios:
j La dependencia entre las características y las clases que los líderes de los programadores ya son propietarios.
j La secuencia de desarrollo.
j La complejidad de las funciones que se aplicará en función de la carga de trabajo asignada a

programadores jefe.
 modelos ágiles 50

d) Asignar clases a los desarrolladores: es una actividad obligatoria la responsabilidad del equipo
la planificación, que debe asignar la propiedad de las clases para los desarrolladores. Esta asignación se basa en:

j la distribución de la carga de trabajo entre los desarrolladores.

j complejidad de las clases (priorizar más compleja o de alto riesgo).
j utilizar clases de intensidad (clases de prioridad muy utilizadas).
j secuencia de desarrollo.

La verificación de las actividades se realiza internamente. El equipo de planificación en sí es una autoevaluación para determinar si
las actividades se llevaron a cabo correctamente.
El dispositivo resultado o salida de las actividades es la plan de desarrollo, que consiste en:

a) Términos (mes y año) para la realización del desarrollo en relación con cada una de las actividades empresariales.
b) La asignación de los desarrolladores que conducen a cada una de las actividades comerciales.
c) Términos (mes y año) para la realización del desarrollo en relación con cada una de las áreas de negocio (esto es
derivado de la última fecha de finalización de las actividades de negocio incluidas en la fecha).
d) Lista de los desarrolladores y las clases de las que son propietarios.

4.1.4 DPF - D para etAlhAr F unCionAliDADe

La disciplina DPF (Diseño de funciones) se lleva a cabo por primera vez en la fase iterativa del FDD. Básicamente consiste en la producción de diseño
implementación de la funcionalidad, que se lleva a cabo habitualmente en secuencia o de comunicación diagramas (Wazlawick, 2011).

La actividad detallada se realiza para cada característica identificada dentro de las actividades de negocio. La atribución de la obra a los
desarrolladores es hecha por el programador líder que pueden considerar, por lo tanto, la conexión entre las características o propiedad
(propiedad) de las clases involucradas.
Como entrada, las actividades de esta disciplina requieren la planificación de la etapa anterior se ha completado.

Las actividades DPF son los siguientes:

a) Formar el equipo de trabajo: Es una responsabilidad obligatoria programador líder de la actividad.

El jefe de programación crea un paquete de características para ser trabajado y, dependiendo de las clases involucradas con estas
características, el equipo define características con los propietarios de estas clases. El líder programador también debe actualizar el
control de avance del proyecto, lo que indica que este paquete de características se está trabajando.

b) dominio dirigido estudio: Es responsabilidad de un dominio experto de la actividad opcional. Si el

funcionalidad es muy complejo, el experto de dominio debe presentar un estudio dirigido en la funcionalidad en el campo en el
que se inserta. Por ejemplo, una característica como "calcular el impuesto" puede ser bastante complicado y merece una
presentación detallada por un experto en el campo antes de los desarrolladores empezar a diseñar él.

c) Estudiar los documentos ç Referencia hará lo siguiente: es una actividad opcional responsabilidad del equipo
características. Dependiendo de la complejidad de la función, es posible que necesite el equipo para estudiar los documentos
disponibles, tales como informes, pantallas dibujos, estándares de interfaz con sistemas externos, etc.

d) Desarrollar diagramas de secuencia: Es un equipo funcional de la actividad opcional responsable de

nalidades. Los diagramas para describir la funcionalidad requerida puede ser desarrollada. Así como otros artefactos, deben ser
sometidos a un sistema de control de versiones (Sección 10.2). decisiones diseño
Ellos deben ser registrados (por ejemplo, el uso de la norma apátrida o statefull etc.).
e) Refinar el modelo de objeto: Es una responsabilidad obligatoria programador líder de la actividad.
Con el uso intensivo de sistema de control de versiones, el principal desarrollador crea un escritorio de una copia del modelo de las
clases necesarias, proporcionando la copia de las características del equipo. Esto, a su vez, habrá acceso compartido a copiar,
pero el resto del personal no lo hizo, hasta que se guarda como una nueva versión de las clases en el sistema de control de
versiones. A continuación, el
 modelos ágiles 51

características del equipo deben agregar métodos, atributos, asociaciones y nuevas clases, según sea necesario.

f) Escribir las interfaces (firma) de las clases y métodos: Es una actividad obligatoria bajo la responsabilidad
cuenta con el equipo. Usando el lenguaje de programación objetivo de la aplicación, los propietarios de las clases escriben las interfaces de
clases, incluyendo los atributos y sus tipos, así como la declaración de métodos, incluyendo los tipos de parámetros y la rentabilidad, las
excepciones y mensajes.

Verificación del producto de estas actividades se realiza mediante la inspección de la evaluación interna de diseño. Esta evaluación debe ser realizada
por el equipo de características, pero otros miembros del proyecto pueden participar. Después de la aceptación del producto final, se genera una lista de
actividades para cada desarrollador (recordando que, hasta ahora, sólo se han definido las firmas de método y que aún no se han implementado de
manera efectiva), y la nueva versión de la clase está registrado ( commit) el sistema de control de versiones.

La salida de las actividades es una paquete de diseño inspeccionado y aprobado. Este paquete consta de:

a) Una cubierta con comentarios que describen con suficiente claridad paquete.
b) Los requisitos abordan en forma de actividades y / o funciones.
c) Los diagramas de secuencia.
d) proyectos alternativos (si los hay).
e) El modelo de clase actualizada.
f) Las interfaces de clase generados.
g) La lista de tareas para los desarrolladores, genera debido a estas actividades.

4.1.5 ACB - C para uilding F unCionAliDADe

Este curso también se realiza dentro de la fase iterativa de la FDD, que tiene como objetivo producir código para las características identificadas. A
partir del diseño generados por la disciplina anterior y de acuerdo con el calendario establecido por el líder en el desarrollo, los desarrolladores
deben construir y probar el código requerido para cada clase asignada. Después de la inspección del código por el programador líder, que se
guarda en el control de versiones y ahora se considera una construir.

La entrada a estas actividades es paquete de diseño generada en la disciplina anterior. Las actividades
involucradas son:

a) Implementación de clases y métodos: Es una actividad obligatoria bajo la responsabilidad del equipo de fun-
las autoridades. La actividad se lleva a cabo por los propietarios de clase en colaboración con los demás.
b) Inspeccionar el código: Es una actividad obligatoria por la responsabilidad del equipo de la característica. una
inspección de código se puede hacer por el personal o los analistas externos (Sección 11.4.2), pero siempre es coordinado por el programador
y el líder se puede hacer antes o después de las pruebas unitarias.
c) Unidad de Pruebas: Es una actividad obligatoria por la responsabilidad del equipo de la característica (Sección 13.2.1).
dueños de clases definir y ejecutar pruebas unitarias de sus clases en busca de cualquier defecto o requisitos inadecuados. El
desarrollador líder puede determinar las pruebas de integración entre las diferentes clases cuando se considere necesario.

d) Actualizar a la versión actual (acumulación): Es una actividad obligatoria bajo la responsabilidad principal desarrollador. para
como los desarrolladores de informes éxito en la prueba de la unidad, el desarrollador líder puede promover la versión actual de
cada clase individual a construir ( Capítulo 10), pero no antes de pasar por la prueba de integración.

Verificación del producto de trabajo se hace internamente por el líder del equipo y funciones para desarrolladores.

Los resultados o salidas de estas actividades son:

a) Las clases que han pasado con éxito en pruebas de unidad e integración y por lo tanto fueron promovidos a la versión
actual ( construir).
b) Proporcionar un conjunto de características con valor para el cliente.
 modelos ágiles 52

4.1.6 F POr portaherramientas FDD

Existen herramientas específicas disponibles para su uso con el método FDD, incluyendo:

a) CaseSpec 3 : herramienta propia, pero con prueba gratuita, la gestión de requisitos a lo largo
el ciclo de vida.
b) DevSuite TexExcel 4 : conjunto de herramientas específicas que se aplicarán FDD.
c) FDD Proyecto Herramientas 5 : proyecto de creación de herramientas de código abierto para FDD.

4,2 DSDM - Método de Desarrollo de Sistemas Dinámicos

Método de Desarrollo de Sistemas Dinámicos ( DSDM) 6 También es un modelo ágil basado en el desarrollo iterativo e incremental, con la
participación activa del usuario. El método es una evolución de Desarrollo rápido de aplicaciones
(RAD) (Martin, 1990), que, a su vez, es un sucesor Rapid Prototyping ( Sección 3.9).
El DSDM tiene tres fases:

a) Pre-proyecto: en esta etapa, se identifica el proyecto y negoció, su presupuesto está definido y es un contrato
firmado.
b) Ciclo de vida: el ciclo de vida comienza con una fase de análisis de viabilidad y de negocios. después entra
los ciclos de desarrollo iterativo.
c) Posterior al proyecto: equivalente al periodo generalmente considerada como la operación y mantenimiento. En esta fase, el
la evolución del software es visto como una continuación del proceso de desarrollo, e incluso puede volver a etapas anteriores si es
necesario.

La fase del ciclo de vida, a su vez, se divide en las siguientes etapas:

a) Estudio de viabilidad.
b) análisis de negocio (a veces aparece junto con la anterior).
c) La iteración modelo funcional.
d) Iteración de diseño y construcción.
e) Despliegue.

DSDM se basa en la Principio de Pareto, 7 Principio o 80/20. Por lo tanto, el DSDM pretende iniciar el estudio y la aplicación del 20% de los
requisitos que serán más decisivo para el sistema en su conjunto. Esta práctica es consistente con la práctica de la inicialmente frente a las
necesidades más complejas o mayor riesgo, presentes en otros modelos como UP.

Otro aspecto de la DSDM es objetividad, que establece que la gestión de riesgos debe centrarse en las características para ser entregados a
expensas de otros factores, tales como documentos o el propio proceso.
La filosofía DSDM se puede resumir en los siguientes principios:

a) participación usuario en el proyecto todo el tiempo.

b) autonomía desarrolladores a tomar decisiones sin tener que consultar a los comités superiores.
c) entregas frecuentes suficientemente buenos lanzamientos son la mejor manera de conseguir una buena mano
producto al final. Posponer las entregas aumenta el riesgo de que el producto final no es lo que quiere el cliente.
d) eficiencia entregas en la solución de los problemas de negocio. A medida que las primeras entregas se centrarán
los requisitos más importantes, que serán más eficaces para el negocio.
e) realimentación usuarios como una manera de leer de nuevo el proceso de desarrollo iterativo e incremental.
f) reversibilidad de todas las acciones llevadas a cabo durante el proceso de desarrollo.

3 Disponible en: < www.casespec.net/ > . Consultado el 21 de enero 2013.

4 Disponible en: < www.techexcel.com/solutions/alm/fdd.html > . Consultado el 21 de enero 2013.

5 Disponible en: <fddtools.sourceforge.net/> . Consultado el 21 de enero 2013.

6 Disponible en: < www.dsdm.org/ > . Consultado el 21 de enero 2013.

7 El principio fue formulado originalmente por el economista italiano Alfredo Pareto (siglo XIX), quien señaló que, en muchas situaciones, el 80% de las consecuencias se debe al 20% de las causas. requisitos de

ingeniería, se puede observar que, en general, el 80% del sistema proviene del 20% de los requerimientos.
 modelos ágiles 53

g) previsibilidad de manera que el alcance y los objetivos de iteraciones se conocen antes del comienzo.
h) La ausencia de pruebas en el alcance, como el método considera la prueba como una actividad fuera
ciclo de vida.
i) comunicación buena calidad entre todas las partes interesadas es fundamental para el éxito de cualquier proyecto.

El DSDM no se recomienda para proyectos donde la seguridad es crítica, debido a la necesidad de extensas pruebas de este tipo de
conflictos en el sistema con los objetivos de costes y tiempos de DSDM.
El DSDM se basa en mayor medida en la documentación que la melé o XP, que hasta que se pone más como el Proceso Unificado
que con los métodos ágiles. Una de las características que diferencian a DSDM el proceso unificado, sin embargo, es el hecho de que
él no aboga por el uso de cualquier técnica específica. En realidad, es una marco proceso, en el que los participantes pueden
desarrollar sus actividades usando sus técnicas preferidas.

La versión actual del método, conocido como DSDM Atern, Puede ser visto por el libre sitio web DSDM Consortium 8 . Según el Consorcio
DSDM, que fue diseñado para ser compatible con el método de gestión de proyectos PRINCE2 (Sección 9.3), CMMI (Sección 12.3) y la norma
ISO 9001 (Sección 12.1).

4.2.1 en nálisis v iAbiliDADe

en el paso análisis de viabilidad, Se comprobará si es factible el uso de DSDM para el desarrollo del sistema y si hay otros impedimentos
posibles. En esta etapa también se evalúa si el proyecto propuesto realmente va a cumplir los objetivos de negocio de la compañía. Además, se
levantan las primeras riesgos del proyecto. La mayoría de estas actividades se lleva a cabo por los grupos de trabajo. En esta etapa también se
comprueba si hay expertos en el dominio disponibles, por lo general en la empresa cliente, para participar en los grupos de trabajo.

En este paso se generan los siguientes artefactos:

a) Informe de viabilidad.
b) la viabilidad del prototipo.
c) plan de desarrollo (Sección 6.4).
d) control de riesgos (capítulo 8).

4.2.2 en nálisis n egóCio

Si el proyecto es aprobado en el análisis de viabilidad, a continuación, se trasladará a la etapa de análisis de negocios. en análisis de negocio Se estudian
las características de las empresas y las posibles tecnologías que se utilizarán. El análisis de negocios es similar al análisis de requisitos tradicionales,
pero hace hincapié en el trabajo en equipo. Los grupos de trabajo deben implicar una variedad de expertos, incluyendo los analistas, diseñadores, usuarios
y expertos en el campo.
Otra característica típica de esta fase es DSDM utilizando la técnica timeboxing, que consiste en establecer previamente la fecha límite y el
presupuesto que se utilizará. Entonces, la variable de la izquierda es el número de requisitos que pueden ser tratadas. Por lo tanto, requisitos
menos importantes pueden quedar fuera si el tiempo o el presupuesto definido anteriormente son insuficientes. El principio de Pareto establece
que esto no será un problema, ya que el 20% de los requisitos dará lugar al 80% del sistema. Por lo tanto, si los requerimientos menores se
quedan fuera, su influencia definitiva sobre el sistema será muy pequeño.

Para el principio de Pareto se aplica al análisis de los requisitos, sin embargo, es necesario que los requisitos son priorizados, es decir, se
debe determinar que son los más importantes y menos importantes. DSDM aboga por el uso de la técnica de Moscú (Clegg y Barker, 2004),
que es un acrónimo de:

a) debe: requisitos que deben estar necesariamente de acuerdo con las reglas de negocio.
b) debe: requisitos que deben ser considerados tanto como sea posible, pero no tienen un impacto decisivo
el éxito del proyecto.
c) podría: requisitos que se pueden incluir, siempre que no afecten negativamente a los objetivos y el calendario
presupuesto del proyecto.
d) haría: requisitos que se pueden incluir, si el tiempo lo permite.

8 Disponible en: < www.dsdm.org/dsdm-atern > . Consultado el 21 de enero 2013.

 modelos ágiles 54

En este paso también se produce arquitectura del sistema inicial, indicando sus componentes principales tales como clases, paquetes,
componentes, nodos de procesamiento, servidores, medios de comunicación, etc.
Por último, en esta etapa, la lista de riesgos del proyecto se actualiza de acuerdo con los resultados actuales.

4.2.3 i hacer terAção M Odel F unCionAl

Los requisitos identificados en la etapa anterior se pueden convertir en un primer prototipo funcional al paso de iteración del modelo
funcional. Este paso consiste en cuatro actividades:

a) Identificar el prototipo funcional, es decir, las características que serán implementadas deben ser identificados
en el ciclo actual. La base para la determinación de estas características es el resultado de la etapa de análisis de negocio, es decir, el modelo
funcional.
b) orden del día determinar cuándo y cómo cada una de las funciones se implementarán.
c) Creación de un prototipo funcional, que consiste en la aplicación preliminar de características definidas
de acuerdo con la programación.
d) Revisión del prototipo funcional, que está hecho ya sea de la revisión de la documentación como la evaluación
usuario final (similar a las pruebas de aceptación, como en la Sección 13.2.4). Esta actividad debe producir
revisión de documentos prototipo funcional.

la actividad identificación de prototipo funcional también incorpora cuatro sub-actividades:

a) El análisis de requerimientos: los requisitos prototipo actual se revisan y actualizan de acuerdo con la lista de
prioridades establecidas en la fase de análisis de negocios o de la iteración anterior.
b) Enumerar los requisitos funcionales de la iteración actual: seleccione la lista de prioridades de los requisitos para ser
abordado en la iteración actual.
c) Enumerar los requisitos no funcionales de la iteración actual: seleccione requisitos no funcionales que se abordarán
en la iteración actual.
d) Crear un modelo funcional: implica la creación de modelos funcionales preferiblemente utilizando el sistema de
notación gráfica.

la actividad orden del día También se divide en sub-actividades:

a) Determinar el tiempo: de acuerdo con la técnica de timeboxing, el tiempo disponible para las actividades de la iteración debe
Se está predeterminado.
b) el desarrollo conjunto: el plan de creación de prototipos debe incluir todas las actividades necesarias para el desa-
rrollo del prototipo en el tiempo disponible.
c) La confirmación de la orden del día: todos los participantes deben estar de acuerdo con el plan de creación de prototipos.

la actividad creación de prototipos funcionales También tiene tres sub-actividades:

a) investigar: se debe examinar cuidadosamente los requisitos y el modelo funcional, para establecer una
plan de implementación para el prototipo de la iteración actual.
b) refinar: aplicar y perfeccionar el prototipo de iteración actual.
c) consolidar: consolidar o integrar el prototipo de la iteración actual con el prototipo de las iteraciones anteriores.

Por último, la actividad de Revisión del prototipo Se divide en dos sub-actividades:

a) prototipo de prueba: el artefacto registro de la prueba Se debe actualizarse y ser considerada en todas las etapas de
DSDM. En esta subactividad, que será útil para que usted sepa que son las pruebas importantes por los cuales debe pasar a ser aceptado el
prototipo.
b) Revisión Final: dependiendo de la prueba y realimentación se crearán usuarios Documento de revisión proto
mecanografía, los cuales serán utilizados para revisar la lista de requisitos y prioridades, así como la lista de riesgos.

El modelo funcional y el prototipo funcional son los principales artefactos producidos en esta etapa. El prototipo de trabajo se utiliza sobre todo
para el usuario para evaluar si los requisitos implementados son realmente los que él necesita. A partir de la evaluación del prototipo funcional,
la lista de requisitos se revisa, así como su asignación de prioridades y la lista de riesgos.
 modelos ágiles 55

4.2.4 i en terAção D esign y C onstrucción

la iteración de diseño y construcción es un paso que se dirigirá a la integración de las características ya acordados en un sistema que cumple con
los grupos de interés. Además, esta fase implicará una verificación más detallada de los requisitos no funcionales, que podrían haber sido
relegados a un segundo plano en el prototipo funcional. Esta fase también incluye cuatro actividades:

a) Identificar el modelo de diseño: deben ser identificados aquí los requisitos funcionales y no funcionales que
Deben estar en el sistema final. la pruebas de ensayo obtenido de la etapa anterior del prototipo se utilizará para crear la estrategia
de implementación.
b) orden del día: el programa define cuándo y cómo se aplicarán los requisitos.
c) diseño de creación de prototipos: Aquí se crea un prototipo de sistema que puede ser utilizado por los usuarios
Final y también para probar el efecto.
d) Prototipo de la opinión: el prototipo construido de este modo debe ser probado y revisado, la generación de dos artefactos:
la documentación del usuario y pruebas de ensayo.

la prototipado Es uno de los puntos fundamentales de DSDM. El primer prototipo (funcional) debe ser desarrollado para mostrar las
principales funciones del sistema, de manera que el cliente puede tener rápidamente una visión de lo que será implementado. El segundo
prototipo (de diseño) Debe incluir progresivamente todas las características no funcionales que no están en el primer prototipo, y cualquier
cambio solicitado por el cliente en el proceso de revisión del prototipo.

4.2.5 i MPlAntAção

el paso implantación Su objetivo es ofrecer el sistema a los usuarios finales e incluye las siguientes actividades:

a) Directrices y la aprobación del usuario: usuarios finales aprueban el prototipo final como un sistema final
de su uso y la observación de la documentación aportada.
b) formación: usuarios finales están capacitados para utilizar el sistema. usuarios capacitados Ellos son considerados los
salida artefacto que la actividad.
c) implementación: cuando el sistema se despliega y se entrega a los usuarios finales se obtendrá el artefacto sistema
entregado.
d) Business Review: En esta actividad, se evalúa el impacto del sistema de objetivos de negocio. depende
Dendo resultado, el proyecto va a un ciclo posterior y reinicie el ciclo con el fin de perfeccionar y mejorar los resultados.

4.2.6 P Y el papel de DSDM

El DSDM tiene un conjunto muy peculiar de papeles propia. Al igual que en otros casos, una persona puede tener más de una función, pero
es importante que todo el mundo sabe lo que el titular responsabilidades en él. Las siguientes funciones son:

a) promotor del proyecto: Funciona como un gerente ejecutivo. Debe ser una persona con capacidad administrativa
llevar a plazos y decisiones, como siempre encajan las decisiones finales en caso de conflicto.
b) visionario: Tiene una misión para averiguar si los requisitos iniciales son apropiados para comenzar el proyecto. la
Visionario también funciona como una especie de ingeniero de procesos, ya que tiene la responsabilidad de mantener las actividades de
acuerdo con el DSDM.
c) Broker: hace la interfaz con el equipo de desarrollo de clientes, usuarios y expertos
dominio. Su responsabilidad es encontrar y traer la información adecuada y necesaria para el equipo.
d) Editorial: es cualquier usuario que es un importante punto de vista, debe llevar la información
a menudo por el personal, preferiblemente todos los días.
e) Gerente de proyecto: Es responsable del mantenimiento de las actividades dentro de los plazos, con el presupuesto del sistema y la calidad
requerido.
 modelos ágiles 56

f) Coordinador técnico: Es responsable del diseño de la arquitectura del sistema y sus aspectos técnicos.
g) Líder de equipo: Es un desarrollador con una función especial para motivar y mantener la armonía de su grupo.
h) desarrollador: requisitos y trabaja para transformar los modelos en código ejecutable.
i) probador: Es responsable de las pruebas del sistema.
j) Secretario: Usted es responsable de tomar notas para los requisitos de registro identificados, así como las decisiones
diseño tomada a lo largo del proceso de desarrollo.
k) facilitador: Proporciona el entorno de trabajo y evalúa el progreso de los distintos equipos.

Otros papeles típicos en el proceso de desarrollo se pueden utilizar cuando sea necesario, tal como diseñador interfaz, el gestor de
base de datos, experto en seguridad, etc.
Por otra parte, al igual que en otros modelos, una persona puede asumir diferentes roles, sin perjuicio, si el personal es pequeño.

4.3 melé

melé Es un modelo ágil para la gestión de proyectos de software. en melé uno de los conceptos más importantes es la
sprint, que consiste en un ciclo de desarrollo que generalmente oscila entre dos semanas y un mes.
El diseño inicial de la melé Se llevó a cabo en la industria automotriz (Takeuchi y Nonaka, 1986), y el modelo se puede adaptar a varias otras
áreas diferentes de producción de software.
En el área de desarrollo de software, melé su popularidad se debe inicialmente a la obra de Schwaber. Una buena referencia para aquellos
que deseen adoptar el método es el libro Schwaber y Beedle (2001), que muestra el método de manera completa y sistemática.

4.3.1 P erFis

Hay tres perfiles importantes de Modelo scrum:

a) la scrum master, que no es un administrador en el sentido de los modelos prescriptivos. No es un líder, ya que los equipos están
auto-organizado, sino un facilitador (que conoce el modelo) y un solucionador de conflictos.
b) la propietario del producto, es decir, la persona responsable del proyecto en sí. Tiene, entre otras cosas, para indicar
¿cuáles son los requisitos más importantes que deben abordarse en cada sprint. la dueño del producto Es responsable de ROI (retorno de la
inversión) y también para conocer y evaluar las necesidades de los clientes.
c) la equipo de scrum, que es el equipo de desarrollo. Este equipo no está necesariamente se divide en papeles
como analista, diseñador y programador pero todos interactúan para desarrollar el producto en conjunto. Generalmente se recomiendan
6-10 equipos de la persona.

Para proyectos muy grandes, se puede aplicar el concepto de Scrum de Scrums, 9 donde múltiples equipos de Scrum
Están trabajando en paralelo y cada uno contribuye a una persona para la formación de Scrum de Scrums, a continuación, cuando se sincronizan los diversos
equipos.

4.3.2 P roducto B acklog

Las características que deben aplicarse en cada proyecto (requisitos o historias de usuario) se mantienen en una lista de llamadas Pila de
Producto.
Uno de los principios del Manifiesto Ágil se utiliza aquí: adaptación en lugar de planificar. Entonces Pila de producto
Usted no necesita ser completa al principio del proyecto. Sólo se puede comenzar con las características más obvias, aplicando el principio de
Pareto, entonces, como el proyecto avanza, el tratamiento de las nuevas características que se están descubriendo. Sin embargo, esto no
significa hacer una encuesta inicial excesivamente superficial. Usted debe tratar de llegar al cliente la mayor cantidad posible de información
acerca de sus necesidades. Es posible que los que se producen normalmente en esta interacción tienen más importancia que otros que son
nuevos descubrimientos ( Figura 4.3 ).

9 Disponible en: < www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting > . Consultado el 21 de enero 2013.

 modelos ágiles 57

Figura 4.3 Ejemplo Pila de producto 10.

Según Kniberg (2007) 11 , varios otros campos podrían añadirse, pero en su experiencia, los seis campos representados en Figura
4.3 siempre llegar a ser importante:

a) Id: identificador numérico (en sentido contrario), importante para el equipo no pierde historia de usuario pista
si al final se cambia el nombre o descripción.
b) nombre: nombre corto que es mnemotécnicamente la historia de usuario.
c) Imp.: importancia de la historia de usuario. Los números más altos indican una mayor importancia. No hay límite. la
relación entre los números no debe interpretarse como una proporción de importancia. Si una historia es importante y 10
Otros asuntos 50, esto sólo significa que la segunda es más importante, pero no lo hace cinco veces más importante.

d) PH: esfuerzo estimado necesario para convertir la historia en el software. El valor se da en puntos
historias (PH). Vea más detalles en la Sección 7.6.
e) Cómo demostrar: Descripción de lo que tendría que ser posible considerar que la historia de manera efectiva
implementado. Este campo puede ser considerado el código de alto nivel para el módulo de prueba de la historia.
f) notas: cualquier otra información que se considere importante para la implementación de la historia de usuario.

4.3.3 s impresión

la sprint es la duración de unas pocas semanas de ciclo de desarrollo en el que la estructura Scrum.
Al comienzo de cada sprint Se hizo una reunión de planificación de Sprint, en el que el equipo da prioridad a los elementos de Pila de producto
a implementarse y transfiere estos elementos Pila de producto para el sprint backlog, es decir, la lista de características que se aplicará en el ciclo
por delante.
El equipo está comprometido con el desarrollo de la funcionalidad, y dueño del producto se compromete a no traer nuevas características
durante el mismo sprint. Si se descubren nuevas características, que serán abordados en sprints
más tarde.
Se puede decir que los dos retrasos Ellos tienen diferentes naturalezas:

a) la Pila de producto Presenta requisitos de alto nivel, en vez adaptadas a las necesidades de los clientes directos.
b) ya sprint backlog proporciona una visión general de estos forma más precisa de los requisitos a la forma en que el equipo
desarrollará ellos.

durante el sprint, es hasta dueño del producto mantener el sprint backlog fecha, indicando las tareas ya realizadas y las que aún no se ha
completado, preferiblemente se muestra en un gráfico actualizado diariamente y de la vista. Un ejemplo de plan de actividades progreso se
muestra en la Figura 4.4 . Hay herramientas como Virtual Junta Scrum 12 , que le permiten editar estas imágenes electrónicamente. El bastidor
oscilante se inicializa con las historias de usuario (primera columna), tomados de la Pila de Producto.

Posteriormente, el equipo se reúne para determinar qué actividades de desarrollo necesarias para poner en práctica cada una de las historias
de usuario. Esta lista de actividades es la sprint backlog, y se utiliza para inicializar la segunda columna "a-do" de la tabla de progreso. A medida
que se están realizando las actividades, completado y verificado, los registros correspondientes se están moviendo a la columna de la derecha.

10 Adaptado de: Kniberg (2007, p. 10).

11 Disponible en: < www.metaprog.com/csm/ScrumAndXpFromTheTrenches.pdf > . Consultado el 21 de enero 2013.
12 Disponible en: < www.downloadplex.com/Windows/Business/Project-Management/virtual-scrum-board_220058.html > . Consultado el 21 de enero 2013.
 modelos ágiles 58

Figura 4.4 Una típica imagen progreso de la tarea de un sprint.

Todos los días se puede encontrar que se requieren tareas que estaban previstos originalmente para implementar las historias de usuario sprint.
Estas nuevas tareas se van a colocar en la columna de tareas a realizar. Sin embargo, las nuevas historias de usuario no se pueden añadir
durante el sprint.
Cada día también podemos evaluar el progreso de las actividades, contando la cantidad de actividades a realizar y la cantidad de
actividades realizadas, que producirá el diagrama burdown sprint.
El diagrama burndown Sprint consiste básicamente en dos líneas: la primera indica la cantidad de trabajo que hacer y el segundo
indica la cantidad de trabajo realizado en el tiempo. El gráfico se actualiza todos los días, desde el principio hasta el final de sprint, y se
espera en una situación ideal, que es similar a la Figura 4.5 . Pero cuando las historias de usuario no se entienden bien y / o las tareas
no estaban bien planeado, o cuando el equipo se fijó tareas adicionales, además de la prevista inicialmente, el burndown Sprint

Se termina con un aspecto similar a la tabla Figura 4.6 . Kane Mar (2006) 13 analiza las líneas de tareas que hacer, la identificación de
siete tipos de comportamiento como sus equipos Sprint burndown:

j Fakey-fakey: Se caracteriza por una línea recta, regular que indica que probablemente
el equipo no está siendo muy honesto, porque el mundo real es muy complejo y proyectos difíciles se
comportan de manera regular.

j Late-alumno: Se indica una acumulación de tareas hasta cerca del final de sprint. Es típico de
equipos principiantes que todavía están tratando de aprender el funcionamiento de la Scrum.

13 Disponible en: <kanemar.com/2006/11/07/seven-common-sprint-burndown-graph-signatures/> . Consultado el 21 de enero 2013.

 modelos ágiles 59

j Medio-alumno: Indica que el equipo puede estar madurando y comenzar a principios

actividades de descubrimiento, y especialmente los ensayos necesarios.

j Temprano en el alumno: Indica un equipo que la demanda, a principios de la sprint, descubrir todo
necesidades y luego desarrollar gradualmente hasta el final del ciclo.

j meseta: indica un equipo que intenta equilibrar la estimulación temprana y tardía, la

en última instancia conduce el ritmo de desarrollo a una meseta. Inicialmente, hacen un buen progreso, pero
no pueden mantener el ritmo hasta el final de sprint.

j Nunca jamás: Indica un equipo que termina por tener sorpresas desagradables al final de
una sprint.

j aumento Alcance: Indica un equipo que da cuenta de un aumento repentino de la carga

trabajo por hacer. Por lo general, la solución en estos casos es tratar de renegociar el alcance de la
sprint con propietario del producto, pero no descarta también una terminación de sprint
para se realiza un rediseño Pila de Producto.

Al final de cada sprint, el equipo debe llevar a cabo una Reunión de revisión de Sprint ( o demo de Sprint) para ver lo que se hizo
y luego salir para un nuevo sprint. la reunión de revisión del sprint es la demostración y evaluación del producto sprint.
Otra reunión que pueda hacerse al final de una sprint es el retrospectiva del sprint, cuyo objetivo es evaluar el personal y los procesos
(obstáculos, problemas, dificultades, nuevas ideas, etc.).

4.3.4 D Aily s Crum

El modelo sugiere que el equipo lleve a cabo una reunión diaria llamada Scrum diario, en el que el objetivo es hacer que cada miembro del equipo
hablan de lo que hizo el día anterior, ¿qué vas a hacer al día siguiente y, si es así, lo que le impide continuar.

Figura 4.5 A burndown Sprint ideal.

 modelos ágiles 60

Figura 4.6 A burndown Sprint donde las tareas adicionales se incluyen después del inicio de sprint.

Estas reuniones deben ser rápidos. Por lo tanto, se sugiere que hacerse con la gente de pie delante de un panel de marcado. Además, se
recomienda que el logotipo se hará después de la comida, porque en ese momento del día, los participantes serán más inmerso en cuestiones
laborales (lejos de los problemas personales), además de ser una buena manera de disipar la fatiga que afecta a los desarrolladores de temprano en
la tarde.
Este es el formato de la reunión de pie, similar a lo que los jugadores hacer algo de deporte en el medio, que es el nombre del método ( scrum,
en ingles).

4.3.5 F operación g eral Do s Crum

El modelo de funcionamiento general melé Se puede entender a partir del resumen presentado en Figura 4.7 . Básicamente, el lado izquierdo de la
figura muestra pila de producto, con historias de usuario, los cuales deben ser priorizados y se estima que su complejidad. Las historias más
importantes son por lo tanto seleccionar durante reunión de planificación de Sprint, hasta que el número de puntos de la historia del equipo se aproxima
a la capacidad de producción durante el sprint. Cada punto de la historia implica un día de trabajo por persona. Por lo tanto, una sprint 2 semanas (10
días laborables) con 3 personas serían capaces de dar cabida a 30 puntos de la historia.

Asimismo, durante el reunión de planificación de Sprint, historias de usuarios seleccionados deben ser detallados en las actividades de desarrollo, es
decir, las tareas sprint backlog Ellos deben ser identificados.
la sprint aperturas, y cada 24 horas, esto debe ocurrir una reunión scrum diaria, círculo más pequeño como se muestra en la figura.

Al final de sprint no debe haber reunión de revisión del sprint, para evaluar el producto del trabajo, y, finalmente, la
retrospectiva del sprint, para evaluar los procesos de trabajo. Por lo tanto, si se aprueba, el producto (parcial o final) puede ser entregado al cliente.
Ese no es el sprint Por último, el ciclo se reinicia.

XP 4.4 - eXtreme Programming

La programación extrema, o XP ( Extreme Programming) Es un modelo ágil inicialmente adecuado para pequeñas y medianas equipos y en base a un conjunto
de valores, principios y reglas. El XP apareció en los Estados Unidos a finales de 1990.
 modelos ágiles 61

Figura 4.7 Modelo Scrum.

Entre los principales valores de XP incluyen: la sencillez, el respeto, la comunicación, realimentación y el valor:

a) simplicidad: según Informe caos ( Standish Group 1995), 14 más de la mitad de las características
sistemas introducido en siempre Se utiliza. XP sugiere cómo valorar la sencillez, es decir, el equipo debe centrarse en las
características requeridas de manera efectiva, y no a quienes podría ser necesario, pero cuya necesidad real no tienen todavía la
evidencia.
b) respecto: respeto entre los miembros del equipo y entre el equipo y el cliente, es un valor de la BA
Suero, que da soporte a todos los demás. Si no hay respeto, la falta de comunicación y de diseño sumideros.
c) la comunicación: desarrollo de software, la comunicación es esencial para que el cliente pueda decir
lo que realmente necesita. defensores XP de comunicación de buena calidad, prefiriendo en lugar de enfrentarse a las reuniones de
videoconferencia, videoconferencia en lugar de llamadas telefónicas, llamadas de teléfono en lugar de
e-mails, etcétera. Es decir, la forma más personal y expresivo de la comunicación, mejor.
d) retroalimentación: diseño de software es reconocida como una empresa de alto riesgo. Consciente de ello, el
Los desarrolladores deben tratar de obtener realimentación tan pronto como sea posible para que cualquier fallo de comunicación se corrigen tan pronto
como sea posible, antes de que el daño se propague y el costo de corrección es alta.
e) valor: se puede decir que la única cosa constante en el diseño de software es la necesidad de cambio.
Para XP Developer, debe confiar en los mecanismos de gestión del cambio para tener el valor para abrazar los cambios
inevitables en lugar de simplemente ignorarlos porque están fuera de contrato formal o ser muy difícil de acomodar.

A partir de estos valores, una serie de principios básicos se definen:

a) realimentación rápido.
b) Asumir la simplicidad.
c) cambios incrementales.
d) Aceptar el cambio.
e) trabajo de calidad.

14 Disponible en: < www.projectsmart.co.uk/docs/chaos-report.pdf > . Consultado el 21 de enero 2013.

 modelos ágiles 62

Así XP aboga por cambios incrementales y realimentación rápido, y pensar en cambiar algo positivo, que debe entenderse como
parte del proceso. Además, el XP valora el aspecto de la calidad, se cree que las pequeñas ganancias a corto plazo por sacrificar la
calidad no se ven compensados ​por las pérdidas en el medio y largo plazo.

A estos principios todavía puede añadir priorización de las características más importantes, de manera que si el trabajo no puede ser
todo lo completó al menos las partes más importantes han sido.

4.4.1 P RÁCTICA XP

Para aplicar XP, debe seguir una serie de prácticas que se refieren a relaciones con los clientes, gestión del diseño,
programación y pruebas:

a) la planificación del juego (juego de la planificación): semanal, el equipo debe cumplir con el cliente para priorizar
las funciones a desarrollar. Es responsabilidad del cliente para identificar las principales necesidades y la estimación equipo de
desarrollo que puede ser implementado en que comience el ciclo semanal. Al final de la semana, estas características son entregados al
cliente. Este tipo de modelo de relación con el cliente es adaptativo, en contraposición a los contratos estrictos establecidos por lo
general.
b) Metaphor (metáfora): hay que conocer el idioma del cliente y sus significados. El equipo debe aprender
para comunicarse con el cliente en el idioma que comprenda.
c) equipo cohesionado (equipo completo): el cliente es parte del equipo de desarrollo y el equipo debe estar estructurado
de manera que las barreras de comunicación son eliminados.
d) Reuniones de pie (reunión stand-up): como en el caso de scrum, reuniones de pie tienden a ser más objetivo y
efectiva.
e) Diseño simple (diseño simple): implica cumplir con la funcionalidad requerida por el cliente sin innecesariamente sofisticado
riamente. Uno debe hacer lo que el cliente necesita, no lo que sería necesario que el desarrollador. A veces, diseño sencilla se
puede confundir con diseño fácil. No siempre el diseño simple es más fácil de implementar, y diseño fácil no puede satisfacer las
necesidades o bien generar problemas de arquitectura.
f) versiones pequeñas (pequeñas comunicados): la liberación de pequeñas versiones del sistema puede ayudar a la prueba del cliente
funcionalidad continuamente. XP se toma este principio al extremo, lo que sugiere versiones incluso más pequeño que los otros procesos
adicionales, tales como UP y Scrum.
g) ritmo sostenible (ritmo sustentable): un trabajo de calidad con un número razonable de horas por día (no
más de 8). Las horas extraordinarias sólo se recomienda cuando en realidad traerá una mayor productividad, pero no puede ser de rutina.

h) propiedad colectiva (propiedad colectiva): el código no posee y no tiene que pedir permiso a nadie
para modificarlo.
i) Programación en pares (programación en parejas): la programación se realiza siempre por dos personas en cada computarizada
Tador general, un programador más experimentado y un aprendiz. El aprendiz debe utilizar la máquina, mientras que el más
experimentado para ayudarle a desarrollar sus capacidades. De este modo, el código generado será siempre han sido verificadas por al
menos dos personas, lo que reduce drásticamente la posibilidad de errores. También se ha sugerido que la programación en parejas es
hecha por los desarrolladores del mismo nivel de conocimiento, que debe activar pilotaje ordenador (Bravo, 2010).

j) Estándares de Codificación (estándar de codificación): el equipo debe establecer y seguir las normas de codificación de manera que
el código parece haber sido todos desarrollados por la misma persona, aunque sea hecho por decenas de ellos.
k) pruebas de aceptación (pruebas de clientes): se planifican y las pruebas realizadas por el equipo en conjunto con el
cliente para verificar que se han cumplido los requisitos.
l) basado en pruebas de desarrollo (desarrollo basado en pruebas): antes de programar una unidad, se deben
definir y ejecutar las pruebas por las que debe pasar.
m) Refactoring (refactoring): No debe escapar de la refactorización cuando es necesario. Se mantiene el
la complejidad del código en un nivel manejable, y es una inversión que trae beneficios en el mediano y largo plazo.

n) La integración continua (integración continua): nunca hay que esperar hasta el final del ciclo para integrar una
nueva funcionalidad. Una vez que sea posible, debe integrarse en el sistema para evitar sorpresas.
 modelos ágiles 63

Las prácticas de XP son, sin embargo, no hay consenso entre los desarrolladores. Keefer (2003) 15 Dice, entre otras cosas, que las prácticas no
siempre son aplicables, que el estilo de trabajo no es escalable para equipos más grandes y la programación en parejas termina siendo una actividad
muy vigorosa, que sólo es posible si su duración se mantiene durante los períodos de tiempo relativamente corto.

Además, Tolfo y Wazlawick (2008) muestran que la cultura de la organización, especialmente en sus aspectos más profundos, que son los
valores por defecto y practicado por las personas, independientemente de lo que está escrito en las tablas de la misión y visión de la empresa, es
crucial con el fin de proporcionar un ambiente fértil u hostil a la aplicación de los métodos ágiles, especialmente XP.

4.4.2 r reglas a partir de P lAnejAMento

Wells (2009) 16 Va más allá de las prácticas de la XP, señalando una breve y más bien establecidas reglas objetivas para XP. Divide las reglas en
cinco grupos principales: planificación, gestión, diseño, codificación y pruebas. En este apartado y los siguientes, estas reglas, que son un desglose de
las prácticas de XP, se presentarán.
la planificación Se compone de las actividades que tienen lugar antes del inicio de un proyecto o de un ciclo. Durante la planificación, el equipo
analiza el problema, sus riesgos y alternativas, priorizar las actividades y planes como el desarrollo y las entregas van a suceder. Las reglas de planificación
Son los siguientes:

a) Escribir historias de usuario: Ellos tienen el mismo propósito de casos de uso, pero no son lo mismo. ellos son
utilizado en lugar del documento de requisitos. A diferencia de los casos de uso, que se definen por los analistas, los casos de uso
deben ser escritas por los usuarios teniendo en cuenta que son los elementos que necesitan el sistema para hacer por ellos.
Pueden ser utilizados para definir las pruebas de aceptación (Sección 13.2.4). El equipo debe evaluar si la historia puede ser
implementado en una, dos o tres semanas. veces más que éstos significan que la historia debe dividirse en dos o más pisos.
Menos de una semana significa que la historia está en un muy alto nivel de detalle y necesita ser combinado con otros. Cómo las
historias son escritas por el cliente, se espera que no están contaminados con aspectos técnicos.

b) La planificación de la entrega crea el programa de entrega: se realiza una reunión de planificación de entrega
para perfilar el proyecto en su conjunto. Es importante que los técnicos toman las decisiones técnicas y los gerentes a tomar decisiones de
negocio. Se debe estimar el tiempo que cada historia de usuario en términos de semanas de programación ideales 17 y priorizar las historias
más importantes desde el punto de vista del cliente. Esta priorización se puede hacer con historias impresas en tarjetas, que debe ser
transportado en la mesa o una tabla para indicar las prioridades. Las historias se agrupan en las iteraciones, que sólo se han programado
justo antes de ser iniciado.

c) Comer pequeñas entregas frecuentes: algunos equipos ofrecen el software al día, que puede ser una
exageración. En el peor de los casos, las entregas deben ocurrir cada una o dos semanas. La decisión de colocar la entrega en funcionamiento o
el cliente no lo es.
d) El proyecto se divide en iteraciones: prefieren iteraciones de una a dos semanas. No planificar actividades
con suficiente antelación; Asegúrese de planificar con ellos justo antes de que comiencen. planificación just-intime Es una manera de
estar siempre en sintonía con los cambios en los requisitos y la arquitectura. No trate de poner en práctica lo que vendrá después.
Tomar en serio los plazos. Siga la productividad. Si se da cuenta de que no va a ganar el programa, convocar una nueva reunión de las
entregas de planificación y la transmisión de algunas entregas a otros ciclos. Centrarse en la realización de tareas en lugar de dejar
varias cosas sin terminar.

e) La planificación de la iteración comienza cada iteración: planificación que comienza cada iteración, selecciona
los casos de uso más importantes a ser desarrollados y las partes del sistema que fallaron en las pruebas de aceptación, que se
divide en tareas de programación. Las tareas se escriben en las tarjetas, así como historias de usuario. Si bien las historias de
usuario están en el idioma del cliente, los trabajos de programación están en el lenguaje de los desarrolladores. Cada
desarrollador selecciona una tarea calcula el tiempo que tardará en completarse. Las tareas deben ser estimados en una, dos o
tres días ideales

15 Disponible en: < www.avocallc.com/downloads/ExtremeProgramming.pdf > . Consultado el 21 de enero 2013.

16 Disponible en: < www.extremeprogramming.org/rules.html > . Consultado el 21 de enero 2013.
17 Una semana de programación ideal es aquel en el que una persona trabaja todas las horas de la semana en un proyecto, sólo dedicándose él.
 modelos ágiles 64

programación 18 . Las tareas de un día más corto se debe combinar, y más de tres días tareas debe ser dividida.

4.4.3 r reglas a partir de g GESTIÓN

la administración Proyecto se produce durante la ejecución. La gestión de búsqueda básicamente asegurar que las actividades se
llevan a cabo a tiempo, dentro del presupuesto y con la calidad deseada. Las reglas de gestión XP citarse:

a) Darle al equipo un espacio de trabajo abierto y dedicado: Es importante eliminar las barreras físicas entre los miembros
equipo para mejorar la comunicación. Se sugiere colocar el ordenador en una sala central para la programación y tablas de par en el lado
de la habitación para que las personas que tienen que trabajar solos no desconecta el medio ambiente. Incluir un área para reuniones de
pie con una pizarra y una mesa de reuniones.
b) Establecer un viaje sostenible: trabajo más allá de la jornada normal es agotador y desmoralizante. Si el
retraso del proyecto, lo mejor es volver a programar las tareas de una liberar reunión de planificación. Descubre la velocidad ideal para su equipo
y se adhieren a ella. No trate de hacer un trabajo en equipo en otra velocidad. Hacer planes realistas.

c) Comience el día con un pie de encuentro: en una reunión típica, no siempre contribuyen, pero al
menos escuchar. Mantener un mínimo de personas tan poco tiempo en reuniones. Reuniones de pie no son una pérdida de tiempo, sino una
forma rápida para mantener el equipo sincronizado, ya que cada uno dirá lo que hizo ayer, ¿qué vas a hacer hoy y lo que le impide continuar.

d) La velocidad de diseño se mide: se cuenta o estimado cuántas historias de usuario puntos y / o tareas
la programación se desarrollan en cada iteración. En cada reunión de planificación de la iteración, los clientes pueden seleccionar un
conjunto de historias de usuario cuyo número total de puntos es aproximadamente igual a la velocidad estimada del proyecto. Lo
mismo vale para los programadores con respecto a las tareas de programación. Esto permite que el equipo se recupere de las
iteraciones difíciles. Aumenta la velocidad y se espera que disminuya.

e) Mover a la gente: personas en los proyectos de movilidad es importante para evitar la pérdida de conocimiento y
cuellos de botella de programación. Sé la responsabilidad de un solo empleado es peligroso. Debe evitar la creación de islas de
conocimiento, ya que son susceptibles a la pérdida. Si necesita experiencia, contratar a un consultor por un período determinado.

f) Reparar XP cuando inapropiada: no dude en cambiar lo que no funciona en XP. Esto no significa
se puede hacer nada. Las reglas deben ser seguidas hasta que se dan cuenta de que tienen que ser cambiado. Todos los
desarrolladores deben saber qué se espera de ellos y lo que pueden esperar de los demás. La existencia de reglas es la mejor manera
de asegurar esto.

4.4.4 r reglas a partir de D esign

Las reglas de diseño Son los siguientes:

a) Adoptar simplicidad: una diseño Sencillo siempre es correr más rápido que una diseño compleja.
Sin embargo, la simplicidad es subjetiva y difícil de medir. Así es el equipo que debe decidir lo que es simple. Una de las mejores maneras
de conseguir la simplicidad en una diseño es tomar en serio la patrón de diseño "Alta cohesión" (Wazlawick, 2011), porque va a conducir a
los elementos del sistema (clases, módulos, métodos, componentes, etc.) más fácil de entender, modificar y ampliar. Recomiendo son
algunas de las cualidades subjetivas para determinar la sencillez de una diseño:

j la capacidad de prueba: uno puede escribir pruebas unitarias para verificar que el código es correcto. El sistema debe
Se puede dividir en unidades comprobables, tales como los casos de uso, el flujo, las operaciones del sistema, los métodos de delegados y métodos
básicos.
j Browseabilidade: se pueden encontrar los elementos cuando los necesite. Los buenos nombres y uso de buenas
disciplinas como el polimorfismo, la herencia y la delegación evitarlo.

18 El programa ideal de día es un día de trabajo normal que una persona se dedica exclusivamente al proyecto.
 modelos ágiles 65

j Comprensibilidad y explicabilidad: comprensibilidad es una cualidad subjetiva, porque un sistema de

Puede ser bastante comprensible para aquellos que están trabajando en ello, pero difícil para el forastero. Por lo tanto, esta propiedad se
puede definir en términos de lo fácil que es para explicar el sistema para aquellos que no han participado en su desarrollo.

b) Elija una metáfora del sistema: un buen sistema de la metáfora ayuda a explicar su funcionamiento a alguien
que está fuera del proyecto. Debe evitarse que la comprensión del sistema reside en pilas de documentos. nombres significativos y nombrar los
elementos del programa de normalización deben ser cuidadosamente seleccionados y seguidos de manera que los fragmentos de código son
efectivamente reutilizable.
c) Utilizar tarjetas CRC durante las reuniones del proyecto: es una técnica para encontrar y responsabilidades
colaboraciones entre objetos. El equipo se reúne alrededor de una mesa y cada miembro recibe una o más tarjetas que representan ejemplos
de diferentes clases. Una actividad (la operación o consulta) es simulado y, como suele suceder, los titulares de la tarjeta, tenga en cuenta las
responsabilidades de objetos (en el lado izquierdo de la tarjeta) y las colaboraciones del objeto (en el lado derecho de la tarjeta). La
documentación de los procesos se puede hacer con los diagramas de secuencia o de comunicación UML.

d) Crear soluciones afilados ( picos) para reducir el riesgo: riesgos importantes del proyecto deben ser exploradas
forma final y exclusivo, es decir, uno debe buscarse solución aguda o espiga para el problema identificado. una espiga Es
entonces un desarrollo o una prueba diseñada específicamente para analizar y quizá resolver un riesgo. Si se mantiene el
riesgo, se debería poner un par de programadores para una o dos semanas de trabajo exclusivamente a examinarlo y mitigarlo.
más picos No va a ser utilizada en el proyecto y se puede clasificar como una forma de creación de prototipos usar y tirar.

e) No se añade ninguna funcionalidad antes de la hora: debe evitar la tentación de añadir una característica
innecesarios simplemente porque sería más fácil hacer esto en el momento y dejar que el mejor sistema. solamente necesario Debe ser hecho en el
sistema. Desarrollar lo que no es necesario es el tiempo de juego exterior. Mantenga código abierto a posibles cambios en el futuro tiene que ver con
la simplicidad diseño, además de añadir funcionalidad o flexibilidad innecesaria deja siempre diseño más complejo y tiene el efecto de una bola de
nieve. deben tenerse en cuenta las necesidades futuras cuando sea estrictamente requerido por el cliente. flexibilidad diseño Es bueno, pero se
necesita tiempo de desarrollo. Debe decidir qué requisitos merecen efectivamente para tener una implementación flexible.

f) Utilice refactorización cuando y donde sea posible: refactorizar sin piedad. XP no recomienda seguir utilizando
diseño viejo y mal simplemente porque funciona. En caso de ser redundancias eliminado, eliminar características innecesarias y
rejuvenecer diseños anticuada.

4.4.5 r reglas a partir de C ODIFICACIÓN

Las normas relativas a codificación los programas son los siguientes:

a) El cliente siempre está disponible: XP requiere que el cliente está disponible, preferiblemente en persona,
durante todo el proceso de desarrollo. Sin embargo, debido a la larga duración de un proyecto, la empresa cliente puede tener
la tentación de asociar con un poco empleado con experiencia o pasante. Sin embargo, no sirve. Para ser un experto, usted
debe escribir las historias de usuario y dar prioridad a ellos y negociar su inclusión en las iteraciones. Puede parecer una alta
inversión de tiempo personal, pero esto es compensado por la falta de necesidad de un estudio de los requisitos detallados en
el inicio, así como el hecho de que no se le dará un sistema inadecuado.

b) El código debe ser escrito de acuerdo con las normas aceptadas: normas de codificación de mantener el código de com-
comprensible y capaz de refactorización por todo el equipo. Además, un código estandarizado y familiar fomenta su propiedad colectiva.

c) Escriba la primera prueba de la unidad: en general, escribir la prueba antes del código para ayudar a escribir código
mejor. El tiempo para escribir la prueba y el código se convierte en lo mismo que lo que costaría acaba de escribir el código, pero esto le
da un código de mejor calidad y es una manera de asegurar que no pierde precisión incluso después de los cambios posteriores.

d) Todo el código es producido por pares: aunque parece contrassensual, dos personas trabajando en un com-
putadora puede producir tanto el código como dos personas que trabajan por separado, pero con más calidad. A pesar de que se
recomienda tener un programador experimentado, la relación no debería ser profesor-alumno, pero iguales.
 modelos ágiles 66

e) Sólo hace un par código de integración a la vez: la integración en paralelo puede traer problemas comparables
bilidad inesperado debido a que el sistema de dos partes que nunca han sido probados juntos llegar a ser integrado sin ser probado.
Tiene que estar claramente definidos versiones del producto. Así que para los equipos que trabajan en paralelo no tienen problemas al
integrar su código para el producto, deben esperar su turno. se deben establecer turnos de integración que se cumplen.

f) La integración debe ser común: los desarrolladores deben integrar el código en el repositorio por períodos cortos
de tiempo. la integración de retardo puede exacerbar el problema de todo el mundo está trabajando en versiones actualizadas del sistema.

g) Establecer un equipo único para la integración: este equipo funciona como un registro exclusivo
( token) para la integración. Su existencia en el lugar de trabajo permite a todo el personal para ver quién es la integración de una
función como la función es la siguiente. El resultado de la integración debe pasar las pruebas de unidad a fin de obtener la estabilidad
en cada versión, así como los cambios de ubicación y posibles errores. Si fallan las pruebas de unidad, esta unidad debe ser limpiado.
Si la actividad de integración tomar más de diez minutos, significa que el equipo necesita un poco de espacio adicional antes de
integrarse. En este caso, la integración debe ser abortado, devolver el sistema a la última versión estable, y el aclaramiento de la
unidad debe seguir siendo hecha por la pareja.

h) La propiedad del código debe ser colectiva: No deben ser creados por los propietarios de los códigos cuellos de botella de la existencia.
Todo el mundo debe permitir que modificar, piezas de recambio o Refactor del sistema. Para que esto funcione, los desarrolladores siempre
deben desarrollar pruebas de unidad con el código, es nuevo, se modificaron. Por lo tanto, siempre hay una garantía de que el software cumple
con las condiciones de funcionamiento. No tener un propietario de las partes del sistema también reduce el impacto de la pérdida de los
miembros del equipo.

4.4.6 r reglas a partir de t este

Por último, las normas relativas a las pruebas de software son los siguientes:

a) Todo el código debe tener pruebas unitarias ( Sección 13.2.1): Este es uno de los pilares de XP. Inicialmente, el desa-
volvedor XP debe crear u obtener una marco de pruebas unitarias. 19 A continuación, debe probar todas las clases del sistema, haciendo caso omiso
de los métodos básicos triviales como captadores y setters, sobre todo si se generan automáticamente. Las pruebas unitarias favorecen la propiedad
colectiva del código, ya que le protegen de ser dañado accidentalmente.

b) Todo el código debe pasar las pruebas de unidad antes de ser entregado: requerir que ayuda a asegurar que su
funcionalidad se implementa correctamente. Las pruebas unitarias también favorecen la refactorización, porque protegen la fuente de los cambios
de funcionalidad no deseados. La introducción de la nueva funcionalidad debería conducir a la adición de otras pruebas específicas para la unidad
de prueba.
c) Cuando se encuentra un error funcional, se crean las pruebas: un error característica identificada
requiere pruebas de aceptación están diseñados para proteger el sistema. De este modo, los clientes expliquen con claridad a los
desarrolladores lo que esperan que sea modificado.
d) Las pruebas de aceptación se ejecutan con frecuencia y los resultados se publican: pruebas de aceptación son
creado a partir de las historias de usuario. Durante una iteración, las historias de usuario seleccionados serán traducidos a las pruebas de
aceptación. Estas pruebas son el tipo funcional ( Sección 13.5) y representan uno o más deseadas características. Las pruebas de aceptación
deben ser automatizados para que puedan ser ejecutados con frecuencia.

4.5 Crystal Clear

Crystal Clear es un método ágil creado por Alistair Cockburn en 1997. Pertenece a la familia de métodos Crystal,
más amplio, iniciado en 1992 (Cockburn, 2004). Otros métodos son conocidos como Amarillo, naranja y Rojo. Claro Es el primer método
familia. Se recomienda que cada método para aumentar la tripulación (hasta 8, 20, 40 y

19 Un bueno sitio web descargar marcos para las pruebas unitarias que implican varios idiomas es < www.xprogramming.com/software >. Además, en < www. junit.org/ > puede encontrar el JUnit, que

se está convirtiendo en un estándar para el desarrollo basado en pruebas en Java. Hits: 21 de enero 2013.
 modelos ágiles 67

Figura 4.8 Estructura de Vida Ciclo Crystal Clear.

100 desarrolladores, respectivamente) y mayor riesgo (malestar, pequeñas pérdidas financieras, grandes pérdidas financieras y la muerte,
respectivamente). A medida que crece el tamaño del equipo y el riesgo del proyecto, los métodos son cada vez más formal. por lo tanto, Crystal
Clear Es el más ágil de todos.
Crystal Clear Por lo tanto, es un enfoque ágil adecuada a los equipos pequeños (de hasta 8 personas) que trabajan juntos (en la misma
habitación o habitaciones contiguas). En general, el equipo se compone de una diseñador líder y dos a siete desarrolladores. El método propone,
entre otras cosas, el uso de radiadores de información, tales como pinturas y murales en la vista, fácil acceso a los expertos de dominio,
eliminando las distracciones, calendario de desarrollo basados ​en la técnica de timeboxing y el método de ajuste cuando sea necesario.

El ciclo de vida Crystal Clear Está organizado en tres niveles ( Figura 4.8 ):

a) la iteración, compuesta de estimación, el desarrollo y la celebración, que suele durar unas pocas semanas.
b) la entrega, formado por varias iteraciones, en el espacio máximo de dos meses entregará características
útil para el cliente.
c) la proyecto, formado por el conjunto de todas las entregas.

De acuerdo con Cockburn (2004) 20 , la familia cristal Se centra en las personas ( humano accionado) tan ligero y ( estirar para encajar):

a) Centrado en las personas: Esto significa que el enfoque para el éxito de un proyecto es mejorar el trabajo de
personas involucradas. Mientras que otros métodos se pueden centrar en el proceso de la arquitectura o de la herramienta, cristal Se centra
en las personas.
b) ultraligero: significa que, independientemente del tamaño del proyecto, la familia cristal se esforzará para reducir
la burocracia, el papeleo y gastos generales, que existen en suficiente medida a las necesidades del proyecto.
c) En la medida: significa que el diseño Se empieza con algo más pequeño de lo que cree que es correcta, entonces es
aumento de sólo lo suficiente para satisfacer las necesidades. Se parte del principio de que es más fácil y más barato para aumentar un sistema
para cortar las cosas que se han hecho, pero no son necesarios.

Las siete columnas del método se enumeran a continuación. Las tres primeras condiciones sine qua non método; los otros cuatro se
recomiendan llevar al equipo a la zona de confort en relación con su capacidad para desarrollarse correctamente el software:

a) entregas frecuentes: Se espera que las entregas a clientes a tener lugar al menos cada dos meses, con versiones
intermedio.
b) mejora de reflexión: los miembros del equipo deben a menudo discuten si el proyecto está en marcha y
comunicar los descubrimientos que podrían afectar el proyecto.
c) la comunicación osmótica: el equipo debe trabajar en una habitación individual para que cada uno pueda escuchar la conversación de los demás
y participar en él cuando lo estimen conveniente. Se considera una buena práctica para interferir con el trabajo de otros. El método propone que
los programadores trabajan en forma individual, pero muy cerca uno del otro. Esto puede ser considerado como un compromiso entre la
programación y la programación par individual, ya que cada uno tiene su tarea, pero todos pueden ayudarse mutuamente con frecuencia.

d) Seguridad personal: los desarrolladores deben asegurarse de que pueden hablar sin temor a reproches.
Cuando la gente no habla, sus debilidades vieron las debilidades del equipo.
e) centrarse: se espera que los miembros del equipo tienen dos o tres temas de alta prioridad sobre la cual
trabajar en silencio, sin recibir nuevas asignaciones.

20 Disponible en: <alistair.cockburn.us/Crystal + metodologías> . Consultado el 21 de enero 2013.

 modelos ágiles 68

f) El fácil acceso a los expertos: expertos en el dominio, los usuarios y el cliente deben estar disponibles para trabajar
con el equipo de desarrollo.
g) tecnológicamente rico entorno: el entorno de desarrollo debe permitir pruebas automatizadas, geren-
ciamento configuración e integración frecuente.

Se considera a aplicar Crystal Clear Tiene más que ver con conseguir las propiedades mencionadas anteriormente que los procedimientos siguientes.

4.5.1 y ntregAs F requentes

Las ventajas de entregas frecuentes como una forma de reducir el riesgo en un proyecto de software son indiscutibles, y los ciclos de la vida moderna se
adhieran a este principio.
La mayoría de las veces cuando se trata de entregas frecuentes, imagínese sistemas hechos a la medida para un cliente conocido y está
interesado en dar realimentación al proceso de desarrollo, pero no siempre el software está hecho para este tipo de cliente. Muchos sistemas
desarrollados hoy se distribuyen a través de Internet; a continuación, la comunidad de usuarios no puede ser totalmente conocido. En tales casos,
la táctica para hacer las entregas (versiones disponibles) muy a menudo (por ejemplo, semanalmente) puede ser irritante para algunos usuarios.
Por otra parte, reducir la frecuencia de las entregas puede hacer que el equipo de desarrollo de perder un importante retroalimentación. La solución
en este caso es definir un conjunto de usuarios de amistad que no les importa recibir versiones con mayor frecuencia que los usuarios normales.

Si no se encuentran los usuarios de amistad, la sugerencia es que el ciclo de desarrollo está terminado, como si se haría la entrega, es decir,
una entrega perturbador debe realizarse con toda la formalidad, como si se tratara de una entrega de bienes, pero no debe se puso a disposición de
los usuarios.
una iteración, posiblemente produciendo una entrega, no debe confundirse con una la integración. La integración puede producirse por hora,
siempre que cualquier programador ha creado una nueva versión de un componente que se puede integrar en el sistema. Ya iteración asume el
final de un ciclo de actividades predefinidas y controladas, incluyendo varias adiciones largo del ciclo. para Crystal Clear, es importante que el final
de un ciclo está marcado con una celebración, así, el equipo va a ganar ritmo emocional con la sensación de paso completo. Después de todo,
está formada por personas, no máquinas.

Crystal Clear Se supone que una iteración puede durar desde una hora hasta tres meses. Sin embargo, lo más común es que las iteraciones tendrán una
duración de dos semanas a dos meses, como en el proceso unificado. Lo importante es que se utilizará la técnica de timeboxing y que la fecha límite de
iteraciones no se cambia debido a un retraso dará lugar a otros y el ritmo emocional del equipo puede descargar.

Una mejor estrategia es mantener la fecha límite, dejando el equipo a entregar lo que es posible en ese período de tiempo y luego, si es necesario,
volver a programar las siguientes iteraciones.
Algunos equipos pueden intentar utilizar la técnica de los requisitos fijos ( requisitos de bloqueo) es decir, asume que durante una iteración
requisitos o prioridades no cambiarán. Esto permitirá que el equipo sepa que puede completar sus tareas sin rumbo cambios en el proceso.
Por lo general, sin embargo, en entornos no hostiles y de buen comportamiento, no es necesario establecer esto como una regla, que termina
sucediendo de forma natural.
Es importante tener en cuenta que las entregas frecuentes se refieren a entregar software de servicio al cliente, no simplemente iteraciones
completas. Algunos equipos pueden hacer que cada iteración corresponde a una entrega; otro software entregar cada 2, 3 o 4 iteraciones; Todavía
otros definen el calendario para las iteraciones fechas específicas que producen las entregas. En todos los casos, no había suficiente personal para
hacer iteraciones rápidas; es necesario entregar software con frecuencia. Sin el uso de 24 iteraciones más de un año, pero no la entrega, porque
mientras tanto el cliente no ha dado realimentación en lo que se ha desarrollado.

4.5.2 M MEJORAR r eFleXivA

Una de las cosas que pueden hacer que un proyecto que está fallando para cambiar las cosas es la mejora de reflexión. Esta práctica indica
que el equipo debe reunirse, discutir lo que es y lo que no funciona, evaluar maneras de mejorar lo que no funciona y, lo que es más
importante, poner en práctica los cambios. No es necesario pasar mucho tiempo con esta actividad. Unas horas al mes suelen ser
suficientes.
 modelos ágiles 69

Curiosamente, muchos proyectos se enfrentan a grandes dificultades en las primeras iteraciones. Sin embargo, podría conducir a un desastre
desde el principio debe ser considerado como un punto de partida para la reflexión y la mejora de las prácticas (reflexionar y mejorar). Por otro lado,
si estos problemas no se abordan en serio desde el principio, puede poner en peligro el proyecto de forma rápida y desmoralizar al equipo para que
se convierta en imposible reanudar el ritmo, lo que sin duda dará lugar a la cancelación del proyecto.

Los cambios que hay que hacer a veces con personas, a veces, la tecnología y otros, las prácticas de proyectos en equipo. la
sugerencia Crystal Clear Es que, cada semana, cada mes o una vez o dos veces por ciclo de desarrollo, el equipo se reúne en una taller
la reflexión o la retrospectiva de iteración para discutir las cosas que están funcionando y las que no están funcionando. una lista de
cosas hay que hacer es ser mantenidos y los que deben cambiar. Estas listas deben colocarse a la vista para que se graben y se
cambian de manera efectiva en las siguientes iteraciones.

4.5.3 C COMUNICACIÓN la sMótiCA

la comunicación osmótica Es aquella en la que la información debe fluir por el medio ambiente, es decir, las personas deben ser capaces de escuchar
la conversación de los demás e intervenir, si lo desean, o continuar su trabajo. Esto se obtiene por lo general cuando se ponen todos los
desarrolladores en la misma habitación. Por otra parte, es importante que las pantallas de ordenador son accesibles, ya que en algunos casos es
interesante que un pequeño grupo puede reunirse frente a un ordenador para ver los problemas y dar sugerencias. Por lo tanto, deben ser evitados diseños
habitación para evitar este tipo de visualización.

De acuerdo con Cockburn (2004), cuando la comunicación se lleva a cabo osmótica, preguntas y respuestas fluyen de forma natural por el
medio ambiente y, sorprendentemente, con poca perturbación al equipo. Se plantea la cuestión: "Se tarda más de 30 segundos para conseguir su
pregunta a los ojos y los oídos de alguien que pueda contestar?". Si la respuesta es sí, el proyecto pueden tener dificultades.

la comunicación osmótica es de bajo costo pero altamente eficiente en términos de retroalimentación, porque los errores se corrigen antes de que se
conviertan en problemas más graves y la información se difunde rápidamente.
Aunque la comunicación osmótica es valioso también para proyectos y equipos grandes, se hace cada vez más difícil de conseguir que en estas
condiciones. Usted puede tratar de dejar los equipos en las habitaciones cercanas, pero aún así, la comunicación osmótica sólo va a ocurrir entre
personas de la misma habitación. Otra posibilidad en el caso de los equipos grandes o distribuidos, sería el uso de herramientas de comunicación como
la videoconferencia y chat en línea, de manera que las preguntas que se hacen de una persona a otra, pero vistos por todo el equipo.

Un problema que puede surgir con la comunicación osmótica es demasiado ruido en la habitación o un gran flujo de información dirigida a
los desarrolladores con más experiencia. Pero los equipos conscientes terminan autorregulando y autodisciplinando para evitar este tipo de
problemas. Aislar el desarrollador líder en otra habitación termina por no ser una buena solución, porque si él es el más experimentado, es
natural que llegar a ser de gran demanda, y esto es exactamente el papel: ayudar a otros programadores a crecer. Tener el desarrollador líder
en la misma habitación donde el equipo de trabajo es una estrategia llamada Experto en el Earshot ( experto al alcance del oído). Sin embargo,
siempre hay situaciones extremas. Si el programador líder es así que le preguntó por el equipo que ya no puede avanzar en su propio trabajo, a
reservar para multiplicado por sí mismo que no estarán disponibles para el equipo. Esta técnica se denomina "cono de silencio". El tiempo debe
ser ajustada de acuerdo a la necesidad y respetado por todos.

4.5.4 s eguridad P TAFF

La seguridad personal se relaciona con el hecho de que las personas pueden hablar de cosas que le están molestando sin temor a represalias o
reprimendas. De acuerdo con Cockburn (2004), esto implica, entre otras cosas, decirle al director que la programación no es realista que el diseño
un colega necesita mejorar o incluso que él tiene que ducharse con más frecuencia. La seguridad personal es muy importante, ya que con ella el
equipo puede averiguar lo que sus puntos débiles y corregirlos. Sin ella, la gente no quiere hablar y debilidades continuarán socavando el equipo.

La seguridad personal es un paso en la dirección de confianza, es decir para dar otro poder sobre sí mismo. Algunas personas dependen unos de otros
hasta que se demuestre lo contrario hacer la revisión de que la confianza; otras personas eviten la confianza hasta que tengan la seguridad de que el otro no
perjudicaría a ellos.
 modelos ágiles 70

Hay varias maneras que una persona puede dañar a otros en el lugar de trabajo o incluso obstaculizar el trabajo. Hay personas que se
encuentran, las personas que son incompetentes, las personas que sabotean el trabajo de otros de forma activa y al no proporcionarles
información u orientación importante cuando es necesario. Teniendo en cuenta estas formas de lesión, se puede pedir demasiado a las personas
de un equipo que simplemente confían entre sí. Por lo tanto, es más fácil comenzar con la comunicación abierta, donde cada uno dirá lo que le
molesta y el equipo va a ajustar las acciones y comportamientos de eso.

De acuerdo con Cockburn (2004), el establecimiento de la confianza consiste en exponer a la gente a situaciones en las que otros pudieran lesionar a
ellos y demostrar que no es así. Por ejemplo, un jefe puede exponer a un error en diseño un desarrollador y, en lugar de castigarlo, proporcionarle apoyo
para corregir el error, lo que demuestra que esto es parte del proceso de auto-desarrollo.

Es importante mostrar que la gente no se verán perjudicados, incluso si muestran la ignorancia sobre cualquier tema en relación con su área
de especialización, y señaló que las lagunas de conocimiento son siempre oportunidades para aprender más.

Además, es importante educar a la gente para interpretar la forma de comunicar a otros como no agresiva, incluso durante una discusión.
Una discusión puede ser motivo para una pelea, pero en un ambiente saludable debe ser una manera de enfrentarse a diferentes puntos de
vista. Incluso si no hay consenso, el respeto a la opinión del otro debe prevalecer incluso si es en contra de sus propias convicciones. Las
personas deben escucharse unos a otros con buena voluntad, y las distintas opiniones deben interpretarse siempre como posibilidades u
oportunidades para aprender algo.

Todo esto es importante que la gente se da cuenta de que, con la ayuda de otros, puede resolver problemas complejos mejor
que si trataban solo.
La confianza se ve reforzada por el principio de entregas frecuentes, debido a que, en el momento de la entrega, se puede ver que realmente
hizo su trabajo y quién no. Con seguridad personal, todo el mundo para hablar de sus problemas y limitaciones en talleres mejora de reflexión, de
modo que los fallos se minimizan o eliminan en el futuro.

4.5.5 F hueco

foco Implica primero saber lo que va a trabajar y luego se basan en tiempo, espacio y tranquilidad para hacer el trabajo. Saben cuáles son las
prioridades es algo por lo general determinada por la dirección. El tiempo y la tranquilidad de venir de un entorno de trabajo donde las
personas no son arrancados de sus actividades para llevar a cabo otra, a menudo sin relación con lo que se hace en un principio.

Sólo a establecer prioridades para los desarrolladores no es suficiente. Se debería permitirles identificar de forma eficaz estas actividades. Un
desarrollador interrumpió su tren de pensamiento para presentar informes o demostraciones último minuto, asistir a reuniones o corregir defectos
descubiertos recientemente pasarán varios minutos para recuperar el hilo de sus pensamientos después de la interrupción. Si estas interrupciones se
producen varias veces al día, no es raro que el desarrollador pasar la inactividad en el medio, a la espera de la siguiente interrupción - si se detiene cada
vez que está retomando el ritmo de trabajo, pronto se dará cuenta de la futilidad de tratar de enfocar .

Tenga en cuenta, sin embargo, que este principio no contradice la comunicación osmótica. En el caso de la comunicación osmótica, cada
uno decide si se debe detener lo que está haciendo para responder a una pregunta o ayudar a alguien. Esto suele tardar unos segundos o
como máximo unos pocos minutos. Sin embargo, una tarea de última hora, trajo a la coacción desarrollador que intenta centrarse en su
trabajo, es diferente: es una interrupción que se guarden de trabajo durante varios minutos o incluso horas.

Sin duda, puede haber interrupciones de alta prioridad, pero hay algunas tareas que no pueden esperar unas horas o incluso unos pocos días
a realizar. En otras palabras, lo importante es saber cuál es la verdadera urgencia de la tarea y lo puso en su lugar apropiado en la lista de
prioridades. Y a menos que sea algo realmente importante, la tarea actual no debe ser interrumpido. La nueva tarea debe estar en la pila de
prioridades a la espera de la finalización de la tarea actual y luego ser iniciado.

Las personas que trabajan en varios proyectos al mismo tiempo, casi no hacen ningún progreso en cualquiera de ellos. De acuerdo con
Cockburn (2004), puede pasar hasta una hora y media para recuperar la línea de pensamiento al pasar de un proyecto a otro.

administradores de proyectos experimentados coinciden en que una persona puede ser eficaz en una o dos proyectos al mismo tiempo, pero cuando
se toma en un tercer proyecto, que comienza a no ser eficaz en los tres.
 modelos ágiles 71

Cuando un desarrollador está lleno de múltiples proyectos y actividades simultáneas, la solución de gestión es establecer una lista de
prioridades y lo que es la actividad (o actividades) que se complete tan pronto como sea posible. Si bien se centra en que la actividad, otros
esperan su turno.
Cuando la compañía hace que la rotación de empleados entre los proyectos (que es sano), una de las maneras de mantener el enfoque en las
actividades es asegurar que cada estancia un tiempo mínimo (por ejemplo, dos días) en un proyecto antes de ser trasladado a otro . Esto le da al
empleado la tranquilidad de que sus esfuerzos iniciales para entrar en el ritmo del proyecto no serán interrumpidos abruptamente antes de que tenga
oportunidad de producir algo de valor.

4.5.6 cesso F el acilo y sPeCiAlistAs

No hay duda de que el fácil acceso a los especialistas ayuda en gran medida el desarrollo de un proyecto de software, ya que, aunque los
desarrolladores tienen experiencia en sistemas, no son que que están desarrollando. Por desgracia, esta característica no es la más fácil de
conseguir en un proyecto.
Los usuarios y los clientes serán necesarios antes, durante y después del desarrollo. antes para presentar los requisitos y objetivos de
negocio, durante a responder a las preguntas que invariablemente surgen a lo largo del desarrollo, entonces para validar lo que se ha
desarrollado.
Cockburn (2004) establece que al menos una hora por semana sería esencial para un especialista en el dominio, usuario o cliente
que estaba disponible para responder las preguntas del equipo de desarrollo. Más de lo que sería sin duda beneficioso; menos podría
llevar el proyecto a tener problemas serios.
Otro problema relacionado con esto es el tiempo que lleva a dudas los desarrolladores de resolver. Si duda necesita para ser
contestadas, los desarrolladores pueden incrustar el código de su mejor estimación y luego olvidarse de él. De este modo, el sistema sólo
mostrará que usted tiene una situación de incumplimiento, así más tarde, cuando se libera para uso del cliente.

Para evitar preguntas importantes tardan demasiado tiempo en responder es fundamental que si el experto no puede estar físicamente
presente en el entorno de desarrollo de todas las horas de la semana, no es una forma de comunicación inmediata con él como el teléfono.

Cockburn (2004) también indica tres estrategias principales para facilitar el acceso a los expertos:

a) Reuniones una o dos veces a la semana con llamadas de los usuarios y de teléfono adicionales: El usuario tendrá muchos
Información importante para el equipo en las primeras semanas. A continuación, la necesidad de que el equipo tendrá que disminuirá
gradualmente. Un ritmo natural constituirá el usuario con los requisitos de información y evaluación de software desarrollado cada ciclo
iterativo. Unas pocas llamadas adicionales durante la semana ayudarán al equipo a no invertir tiempo y esfuerzo en la dirección
equivocada.
b) Uno o más expertos de forma permanente en el equipo de desarrollo: esta es una situación más difícil
ser alcanzado. Las opciones son para poner el equipo a trabajar dentro de la empresa cliente o coalocada con cualquier usuario.

c) Enviar desarrolladores para trabajar como aprendices con el cliente desde hace algún tiempo: por extraño
esta opción puede sonar, es muy válida ya que los desarrolladores tendrán una visión muy clara de negocio del cliente y
entender cómo el sistema se desarrollará puede ayudar a mejorar su forma de trabajar.

Una cosa importante a este respecto es entender que no hay un solo tipo de usuario. Hay clientes que por lo general son las personas
que pagan por el sistema; los gerentes de nivel alto y bajo; expertos de dominio (los que conocen o definir políticas); y los usuarios
finales (los que realmente utilizan el sistema). Es importante que el equipo de desarrollo tiene acceso a cada uno de ellos en el
momento adecuado y entender sus necesidades.

4.5.7 El AMBIENTE t eCnologiCAMente r ico

Un equipo, para estar en el desarrollo de la zona de confort, debe tener una tecnológicamente rico entorno, no sólo los lenguajes de
programación y herramientas para dibujar diagramas, pero los tres pilares del buen entorno de desarrollo de software: de prueba
automatizado sistema de gestión de la configuración y la integración frecuente.
 modelos ágiles 72

Un equipo será productivo, de hecho, cuando se puede hacer versiones de interaccion con frecuentes controlados y probados de forma
automática. Así, el proceso de generar nuevas versiones del sistema puede tardar unos minutos y fiabilidad esta integración será bastante
alto.

4.5.7.1 Las pruebas automatizadas

La prueba automatizada no puede considerarse como propiedad esencial de un proceso de desarrollo, porque los equipos que componen las
pruebas manuales también pueden producir con calidad. Sin embargo, la automatización de pruebas ahorra tiempo y da mucha tranquilidad a
los desarrolladores es un movimiento muy importante hacia la zona de confort.

La prueba automatizada implica que la persona responsable de los ensayos podrá, en cualquier momento, iniciar y salir y hacer algo más
mientras se realiza. No debería haber ninguna necesidad de intervención humana en la prueba. Los resultados pueden incluso ser publicados en
la web o intranet, para que todos los desarrolladores pueden seguir en tiempo real lo que está siendo probado y los resultados de eso.

Además, debe ser posible combinar las secuencias de ensayo individuales para generar un conjunto completo de pruebas para el sistema,
que posiblemente podrían ser activada fines de semana para asegurar que los nuevos defectos no se introducen de forma inadvertida.

Debe, sin embargo, recordar que este tipo de pruebas se realiza únicamente para detectar defectos de diseño. Para validar el sistema como las
necesidades de los usuarios es necesario que una evaluación de riesgos se realiza por un ser humano. El mismo también es necesario evaluar la
usabilidad de una interfaz.
Las pruebas del sistema de automatización de la utilización de una interfaz gráfica de usuario es generalmente una actividad cara y consume mucho
tiempo. Por otra parte, cualquier cambio en la interfaz puede hacer que el conjunto de pruebas tiene que ser hecho de nuevo. Así que, por lo general, estas
pruebas no están entre los más recomendados. Para las pruebas del sistema es automático, es necesario invertir en una arquitectura de tipo equipo MVC
(Modelo / Vista / Controlador) ( Reenskaug, 2003) 21 en el que las pruebas del sistema se pueden realizar funciones de controlador de acceso secuencial sin ir
a través de la interfaz gráfica de usuario ( vista).

4.5.7.2 Sistema de Gestión de la Configuración

El sistema de gestión de configuración también ayuda a que el equipo de trabajo más tranquilidad porque los caminos son eventualmente
seguidos, pero no mostró tan prometedor como parece en un primer momento, se puede deshacer sin mayores consecuencias (Capítulo 10).

4.5.7.3 integraciones con frecuencia

Cuanto más frecuentemente el equipo a hacer la integración de las partes del sistema, más rápido se detectarán los errores. No llevar a cabo
la integración frecuente hace que se acumulen errores y por lo tanto comienzan a multiplicarse, y un conjunto de errores es mucho más difícil
de corregir que cada uno de ellos.
No hay una respuesta definitiva acerca de cuál debe ser la frecuencia de integración, así como no hay una respuesta única a la duración de los ciclos
iterativos. Será hasta el equipo para evaluar la forma más ecológica de hacer las integraciones, pero recordando siempre que posponerlo demasiado tiempo
puede dar lugar a problemas.

4,6 ASD - Desarrollo de software adaptativo

la Desarrollo de software adaptativo ( ASD) 22 Es un método ágil, creado por Jim Highsmith (2000), que se aplica las ideas se originó el área
de sistemas adaptativos complejos ( La teoría del caos 23 ). Él ve el proceso de desarrollo de software como un sistema complejo agentes ( desarrollador
clientes, y otros) ambientes ( organizacional, tecnológica y de procesos) y (salidas emergentes productos en desarrollo).

El modelo se basa en el desarrollo cíclico iterativo basado en tres fases: especular, colaborar y aprender.

21 Disponible en: <heim.ifi.uio.no/ ~ trygver / 2003 / JavaZone-JAOO / HM1A93.html> . Consultado el 21 de enero 2013.

22 Disponible en: < www.adaptivesd.com /> . Consultado el 21 de enero 2013.

23 Disponible en: < www.santafe.edu/ > . Consultado el 21 de enero 2013.

 modelos ágiles 73

4.6.1 y de espejo

"La especulación" es el ciclo de planificación adaptativa. En lugar de la planificación, el modelo supone que lo más probable, en las primeras etapas, es que las
partes interesadas todavía no saben exactamente lo que van a hacer y por lo tanto especular.
En esta etapa, sin embargo, se deben establecer metas y plazos. El plan de desarrollo se basa en componentes. La especulación
consiste en llevar a cabo las siguientes actividades:

a) Determinar la duración del proyecto, el número de ciclos y su duración óptima (Sección 6.4).
b) Describir un gran objetivo para cada ciclo.
c) Definir los componentes de software a desarrollar para cada ciclo.
d) Establecer la tecnología y el apoyo a los ciclos.
e) Desarrollar lista de tareas del proyecto.

4.6.2 C olAborAr

"Colaborar" corresponde a los componentes de ingeniería concurrente. El equipo debe entonces tratar de equilibrar sus esfuerzos para llevar a cabo
las actividades que pueden ser más predecibles y los que son naturalmente más incierto. A partir de esta colaboración, los diversos componentes
se desarrollarán simultáneamente.

4.6.3 El detener

"Aprender" es la revisión de la calidad. ciclos de aprendizaje se basan en pequeñas interacciones de diseño, codificación y pruebas,
donde los desarrolladores, al cometer errores pequeños en base a suposiciones incorrectas, mejorar su conocimiento del problema
de dominarla.
Esta fase requiere repetidas revisiones de calidad y pruebas de aceptación con presencia y dominio de los expertos del cliente. Se
recomiendan tres actividades de aprendizaje:

a) grupos de revisión con la atención al usuario: una taller, donde los desarrolladores tienen el producto y
los usuarios tratan de usarlo, la presentación de sus observaciones.
b) Las inspecciones de software: Inspecciones (Sección 11.4.2) y análisis (Capítulo 13) que tienen como objetivo detectar defectos
el software.
c) Autopsias: ellos el equipo evalúa lo que hizo que el ciclo y, si es necesario, cambie su forma de trabajar.

Estas tres fases no son necesariamente secuencial, pero pueden ocurrir simultáneamente y de forma no lineal.

4.6.4 i niCiAlizAção y y ncontrar

Además de estas tres fases iterativos, el modelo predice una etapa temprana y una etapa final, que se producen sólo una vez cada uno:

a) puesta en marcha del proyecto: preparación para iniciar los ciclos iterativos. Inicialización debe ocurrir con una
taller a los pocos días, dependiendo del tamaño del proyecto, en el que el equipo va a establecer la misión o los objetivos del proyecto. En
esta fase también se elevarán los requisitos iniciales, restricciones y riesgos, y realizado estimaciones iniciales de esfuerzo.

b) poner fin a la garantía de calidad y disponibilidad: Incluye la prueba final y la aplicación del producto.

4.6.5 j engrase t Udo

El modelo de ASD se puede resumir por el diagrama Figura 4.9 .

El modelo de ASD es similar a otros modelos ágiles ya vistos en los siguientes aspectos:

a) Se basa en ciclos iterativos de 4-8 semanas.

b) Plazos se tasa (fija timeboxing).
c) Es tolerante al cambio y adaptación.
d) Está orientado principalmente a un mayor riesgo de desarrollar elementos.
 modelos ágiles 74

Figura 4.9 ASD Model.

Quizás el modelo ASD no es tan popular o tan detallada como XP y scrum, pero tiene el mérito de hacer hincapié en la importancia
del desarrollo de adaptación. En modelos prescriptivos, por lo general la adaptación se entiende como una desviación causada por
un error. Pero en la adaptación de ASD es el camino que conduce a los desarrolladores en extrema