Definiendo las prácticas de DAC

El Manifiesto Ágil

La aplicación de los valores y principios del manifiesto ágil (Beck et al., 2001) así como prácticas ágiles para la gestión de proyectos mejoran considerablemente los resultados de calidad del proyecto medidos en: indicadores de ejecución del proyecto, número de no conformidades encontradas en evaluaciones de calidad del proceso y productos de trabajo, satisfacción del cliente.

Basada en los principios y valores del manifiesto ágil (Beck et al., 2001) DAC defiende lo siguiente:

• Es prioridad para el proyecto satisfacer los acuerdos tomados con el cliente a través de la entrega temprana y continua de software de valor que cumpla con los atributos de calidad definidos. 
• El cambio es bienvenido pero controlado, dejando siempre constancia de las solicitudes realizadas y las decisiones a tomar al respecto. Los cambios no pueden comprometer el éxito y la calidad del proyecto. 
• Los involucrados relevantes, tanto externos como internos, deben estar en constante comunicación y realizar reuniones de chequeo del avance del proyecto de forma frecuente. 
• Es vital para la gestión de la comunicación en el proyecto explotar las bondades de las nuevas tecnologías y la red. No obstante se declara como la forma más efectiva de comunicación la conversación cara a cara. 
• Construir el proyecto con individuos capacitados en todo momento garantiza la mitad del éxito. 
• La atención continua a la excelencia técnica enaltece la agilidad y determina la calidad. 
• La reunión diaria es una técnica eficaz para mejorar la comunicación y la resolución de problemas; mientras que la reunión de chequeo y análisis de resultados, en intervalos regulares, se aprovecha para que el equipo reflexione sobre la forma de ser más efectivo y ajustar su conducta en consecuencia. 
• La planeación colaborativa, iterativa y detallada no quita agilidad, brinda control. 
• Evitar a toda costa tener documentación repetida.

Metodologías Ágiles

Las metodologías ágiles de desarrollo de software como XP, Scrum, proceso guiado por funcionalidades (FD, Feature Driven Development) y otras, prevalecen cada vez más en la industria del Software. DAC toma elementos de estas metodologías.

De XP (Beck y Andres, 2004; Jeffries, Anderson, y Hendrickson, 2001) se retoma la idea de realizar un plan de entregas, en este caso versiones del producto, realizando durante el mantenimiento de la primera versión nuevas iteraciones para desarrollar las siguientes versiones del software. Se propone además retomar la idea de las siguientes prácticas XP adaptadas al concepto de DAC: 

• El uso de la metáfora mediante diagramas de paquetes lógicos a partir del estudio del negocio o los requisitos de alto nivel. 
• Diseño simple, abarcando únicamente el modelado del sistema mediante diagramas de paquetes o componentes solo hasta el nivel de funcionalidad. Se incluye como parte del diseño el mapa de navegación y el modelo de datos. No se realizan en DAC diagramas de clases o tarjetas clase-responsabilidad-colaboración (CRC). No son necesarios si en la implementación se aplican correctamente los patrones arquitectónicos y de diseño definidos. 
• La producción del código está dirigida por pruebas de unidad desde el nivel de funcionalidad hasta el nivel de módulos para evitar no conformidades futuras en revisiones de calidad del producto. 
• La refactorización del código antes de las pruebas finales contribuyen a la calidad del software disminuyendo la ocurrencia de no conformidades. 
• Integración continua de cada componente del software una vez sea liberado por el grupo de aseguramiento y control de la calidad. 
• Estándares de programación para fomentar la reutilización del código y la comunicación entre programadores. 

DAC también asume todos los valores de Scrum (Palacio; Schwaber & Beedle, 2002). Esta metodología tiene buenas prácticas que se pueden aplicar en DAC:

• Revisión de las iteraciones con el equipo de proyecto. Las iteraciones en DAC pueden ser tan largas como se determine en la planificación con el cliente. En DAC hay dos tipos de iteraciones: iteraciones por versiones del producto e iteraciones por versiones de componentes. 
• Desarrollo incremental obteniendo en cada iteración al menos un componente del software pudiendo ser este una entrega pactada o parte de ella. 
• Desarrollo evolutivo, aunque en las fases iniciales de cada versión del producto se define una arquitectura y diseño de alto nivel, esta se va actualizando y mejorando durante las iteraciones. 
• Colaboración entre los miembros del equipo de desarrollo. DAC pone especial énfasis a compartir y socializar el conocimiento partiendo del hecho de que un equipo de proyecto es una comunidad de desarrollo. También se propone el uso de repositorios de activos de productos y componentes. 
• DAC define varios tipos de reuniones: reunión de inicio de una iteración, reunión diaria, reunión de análisis de resultados (máximo cada 30 días), reunión de chequeo de acuerdos con involucrados, reunión de cierre de iteración. 

Por otra parte, de la metodología FDD (Palmer & Felsing, 2001) se retoma en DAC la idea del desarrollo de un modelo inicial de alto nivel, que se corresponde con la metáfora de XP. DAC indica que debe establecerse una arquitectura base para poder iniciar el desarrollo a partir de la priorización y agrupamiento de los requisitos del cliente o de alto nivel. Estos requisitos se traducen en objetivos del proyecto, que guiarán el proceso de desarrollo mediante su desglose, refinamiento, análisis, especificación y validación en las distintas fases.


También se incluyen actividades como el estudio de los documentos, el desarrollo de un modelo en áreas y un modelo global. De estos modelos salen las propuestas de componentes en distintos niveles de empaquetamiento y de cada componente las iteraciones necesarias para desarrollarlos.

Prácticas ágiles

En Letelier (2013) se presenta una lista creada por este autor de 42 prácticas ágiles “a modo de carta de restaurante para que cada equipo configure su propio menú”. Además, explica que “Este enfoque conlleva la promoción de una estrategia de implantación que apuesta por combinar prácticas cogidas desde diferentes métodos ágiles”. La mayoría de estas prácticas se aplican en DAC de forma íntegra; sin embargo otras deben aplicarse haciendo algunas adaptaciones. Entre estas:

• Formar equipos pequeños (si el trabajo está organizado se puede dividir un equipo grande en pequeños grupos de desarrollo). 
• El equipo se autoorganiza y toma las decisiones técnicas (a veces un equipo que se autoorganiza tiende a acomodarse y no planificar de la manera más eficiente). 
• Colocalización de miembros del equipo, todo el equipo trabajando en el mismo espacio físico (con el uso de las tecnologías de la información y comunicaciones esto no es necesario, al menos no siempre). 
• Que los integrantes del equipo no tengan solo algunas actividades fijas asignadas (es ideal un equipo así pero en DAC se le da mucha importancia a la especialización de cada miembro en su rol). 
• Documentar, pero solo lo estrictamente necesario, que sea rentable el aprovechamiento de la documentación respecto del esfuerzo asociado a elaborarla (en DAC es utilizar cada uno de los productos de trabajo definidos en la metodología de la manera más eficiente y en el momento que corresponda). 
• Establecer pautas para gestionar convenientemente el retrabajo (mientras sea posible evitar el retrabajo y si ocurre debe analizarse, priorizarse e incorporarse a la planificación). 

Definiendo las prácticas de DAC

Uniendo todo lo anteriormente expuesto junto a un conjunto de buenas prácticas generales en el desarrollo de software a continuación se resumen las prácticas de DAC. 

Calidad en la gestión de los recursos humanos:

• Realizar las reuniones necesarias planificadas. 
• Comunicación mediante las redes e internet y cara a cara siempre que sea posible. 
• Capacitación constante del equipo. 
• Socialización del conocimiento. 
• Colaboración constante. 
• 40 horas semanales. 

Calidad de los productos de trabajo:

• Definir la arquitectura de alto nivel al inicio de cada versión. 
• Planificación conjunta entre cliente y equipo de proyecto. 
• Arquitectura y diseño basados en componentes y patrones. 
• Refactorización de código. 
• Integración continua. 
• Estándar de código. 
• Pruebas en cada iteración y versión (pruebas funcionales, de integración, no funcionales, aceptación alfa y beta). 
• Desarrollo evolutivo-incremental. 
• Evaluar la calidad de cada entregable. 
• Gestionar líneas base. 
• Revisar y gestionar inconsistencias entre los productos de trabajo. 

Calidad en los procesos:

• Documentar, firmar y satisfacer los acuerdos con involucrados y compromisos con el plan. 
• Controlar y firmar las solicitudes de cambio. 
• Planificar y ejecutar el aseguramiento de la calidad del proceso y del producto. 
• Planificar guiado por entregas y requisitos. 
• Adaptar los procesos definidos. Ÿ Seguir los procesos definidos. 
• Analizar los resultados. 
• Documentar los procesos y sus guías. 
• Debe existir un administrador de la calidad y la configuración. 
• Firmar actas de aceptación de los entregables. 
• Monitorear los procesos. 
• Elaborar productos de trabajo simples que cumplan con su propósito de uso.

Nota importante: Estos fragmentos han sido tomados de: http://revistas.proeditio.com/iush/quid/article/download/82/82. En dicho artículo podrán encontrar las referencias bibliográficas.