Metodologías Ágiles: - FDD - AUP - Crystal Clear - DSDM

Álvaro Yuste Torregrosa Carlos Sanchís Server Javier Sánchez Riquelme Carlos Meca López

Featured Driven Development (FDD)

Introducción.

La iniciativa de Desarrollo Dirigida por Rasgos es un tipo de metodología ágil que rige su arquitectura por las funcionalidades del programa a implementar. Como cualquier otra metodología de esta corriente, quiere romper con la noción de “planea el trabajo y trabaja el plan”, y sigue un progreso más adaptativo y dinámico. No enfatiza los requerimientos y la generación de documentación previa, si no que se centra en realizar las fases de diseño y construcción. Sin embargo se preocupa mucho de la calidad del producto, ya que insiste en el monitoreo constante. De su historia podemos remarcar que fue desarrollado por Peter Coad, Eric Lefebvre y Jeff DeLuca, siendo este último en que lo llevó a cabo por primera vez en un caso real de misión crítica. Se le encomendó la tarea de rescatar un proyecto que había durado dos años desde su inicio. Pero éste todavía no poseía ni una sola línea de código, teniendo ya 3500 páginas de documentación. El rescate fue un éxito. Sin embargo no comenzó a utilizarse de manera considerablemente asidua hasta finales de los 90, para implementar grandes aplicaciones bancarias.

Características.

Como algunas otras metodologías ágiles, se basa en un proceso iterativo, pero en este caso es parcial, como ya describiremos en el apartado de “Fases”. Sin embargo, como hemos dicho, la principal propiedad del FDD es la orientación de su arquitectura dirigida los rasgos o funcionalidades del programa a producir. Así nos centraremos en definir este concepto de “feature” para aclarar por extensión cómo trabaja la metodología. En FDD, las “funcionalidades” son lo que en Extreme Programing eran las “historias de usuario”, son el eje de trabajo. Se escriben utilizando el lenguaje del dominio, de manera específica, sin cabida a ambigüedades y usando una estructura similar a: <acción> [un|el] <resultado> [de|a|para|por|…] <objeto> [con|para|de] <parámetros>. El <objeto> identifica la clase en el modelo de dominio, el agente que realiza la operación, la <acción>; que es el método o la función encapsulada en dicha clase y que tiene como valor de salida el <resultado>. Cada una de las funcionalidades equivale a un requisito estipulado previamente por el patrocinador del producto. Tiene siempre un significado empresarial y describe algún valor de negocio. Normalmente también es posible expresarlos como secuencia, cuando existan requisitos para la disponibilidad de unos respecto de otros (el documento que se genera en este caso, como veremos en los artefactos es el Diagrama Secuencial UML). El paradigma de programación que se suele usar en esta clase de metodologías es el FOP (Feature-Oriented Programming), o Programación orientada a rasgos. Este enfoque para sintetizar productos software convierte los programas en una pila de capas, de las cuales, cada una aporta una funcionalidad nueva al conjunto de capas que envuelve. Siempre se trabaja añadiendo nuevo código a un programa ya existente, para que finalmente el resultado sea una composición de transformaciones con la superposición de capas. Las capas son lo que se pasó a denominar “features” o funcionalidades, para dar nombre al paradigma.

Fases.

Una de las principales peculiaridades de este método de desarrollo de sistemas software ágil, con respecto al resto de sus análogos, es que no requiere la presencia del cliente todo lo asiduamente que se suele demandar a lo largo de sus etapas. El peso de estas recae casi íntegramente en los desarrolladores. Las fases iniciales del progreso son secuenciales y únicas en el ciclo de vida. La primera de todas ellas, cuando comienza el desarrollo, es la realización de un modelo global. Aquí, los expertos del dominio, tienen en cuenta el contexto y los requerimientos del sistema para, aportando su visión, modelar el dominio dividiéndolo en las diferentes clases. Estas áreas seccionales se analizan detalladamente por separado construyendo un diagrama de objetos para cada una. A continuación, los desarrolladores elaboran una lista de funcionalidades (con la estructura que hemos explicado en el apartado de características) que en conjunto engloban la funcionalidad total del sistema. Se puede subdividir la lista en conjuntos dependiendo de la semejanza y la dependencia entre funcionalidades. Esta lista posteriormente se revisa por el cliente y por los encargados de validación. Una vez se posee la lista repasada y confirmada, se comienza a desarrollar la planificación por funcionalidad. En esta etapa ya se ordenan en un diagrama, jerárquicamente los conjuntos de rasgos según su prioridad en el desarrollo, y se asignan a su vez a los programadores jefes. Una vez llegado a este punto, como algunas otras metodologías ágiles, se basa en un proceso iterativo. Aunque a diferencia del resto, cada iteración solo engloba las dos fases finales, y no todas ellas. Estas fases son el diseño y la construcción. En ellas, en cada iteración, se selecciona un subconjunto de rasgos a realizar de la lista y se despliega primero diseñando y revisando el diseño. Posteriormente se implementa la funcionalidad y se realizan pruebas unitarias dentro de la construcción (no hay una fase especifica y definida para las pruebas, como ocurre en la mayoría de metodologías). Para finalizar integrando el código e inspeccionándolo. Así una y otra vez, en iteraciones que pueden durar desde unos pocos días hasta un máximo de dos semanas.

Fases de FDD

Roles.

Una de las principales críticas que propinan a este tipo de metodología es la excesiva jerarquización dentro de sus roles. Algunos consideran que para conservar su carácter ágil éste debería de ser más liviana o sencilla. Aún así, las responsabilidades que recaen sobre los desarrolladores se pueden clasificar en tres grandes grupos según su peso en el supuesto organigrama empresarial de desarrollo.

El primer grupo lo forman los roles clave que como su nombre indica son indispensables para el progreso del sistema. En este grupo se encuentra el administrador de proyecto, que es quien siempre tiene la última palabra en visión, cronograma y selección del personal. De la parte más técnica está encargado el arquitecto jefe, que controla el diseño global y la implementación de las diferentes funcionalidades desde el nivel más alto. Quien se preocupa de que todas se desarrollen correctamente es el manager de desarrollo, encargándose de los conflictos en el equipo y de resolver problemas referentes a los recursos.

A un nivel más bajo, pero en el mismo grupo, se encuentra el programador jefe, quien analiza los requerimientos y tras acabar el diseño, selecciona los rasgos que se desarrollarán en cada iteración. Éste está al mando de los propietarios de clase, a quienes les asigna rasgos propios para que se responsabilicen de su implementación, y participen en la decisión de incluirlos o no en la siguiente iteración. Y por último, para completar los roles clave se tiene el experto de dominio, que puede personificarse en el cliente, el patrocinador o un analista de negocio. Su tarea es controlar los requerimientos y su correcta cobertura en el desarrollo.

Para complementar a estos cargos, también son necesarios los llamados roles de soporte. Aquí se encuentra el administrador de entrega, que es quien se reúne con el programador jefe para revisar sus reportes y transmitírselos al manager de desarrollo. Controla en general el avance y se lo comunica al cliente semanalmente. Por otro lado se tiene al gurú del lenguaje, que es quien conoce a la perfección la tecnología de codificación que se está utilizando, y está a disposición de los desarrolladores para aclarar cualquier cuestión referente a ella.

En este grupo también existe el rol de manager de dominio, es quien organiza y lidera al grupo de expertos de dominio, y resuelva sus diferencias a la hora de concretar los requerimientos del sistema. Además, otro rol de soporte es el ingeniero de construcción, que se encarga de preparar, mantener e impulsar el proceso de construcción a la vez que controla las versiones resultado de cada iteración y publica la documentación relevante. También se cuenta con el rol del herramentista para la creación de herramientas de soporte específicas y la gestión tanto de bases de datos como de las webs. Por último el administrador del sistema es quien controla el ambiente de trabajo y empaqueta el producto para cada entrega.

Para finalizar, el último grupo es el de roles adicionales. En él se encuentran los verificadores (personas que pueden llegar a ser independientes del equipo del proyecto, que testean el sistema para comprobar que cumple los requisitos del cliente), los encargados del despliegue (son quienes adaptan la documentación previa a la requerida por el nuevo sistema a desarrollar y contribuyen a su lanzamiento) y los escritores de documentos técnicos (que preparan la documentación relevante para los usuarios).

Artefactos.
A lo largo del proceso, el primero y principal documento que se genera es en el que se definen todas las funcionalidades de la aplicación, el Modelo de Dominio. Éste se elabora utilizando la técnica llamada Unifieid Modeling Languaje (UML), como diagrama de clases, aunque posteriormente fue mejorado por Peter Coad dando lugar al Domain Neutral Component (DNC) y arquetipos de clase. A continuación observamos un ejemplo que modela el dominio de un hotel y las conferencias que se realizan en él, en formato DNC.

DNC

Como hemos dicho, cada modelo funcionalidades se puede traducir al instante en el artefacto llamado Diagrama Secuencial UML. En el caso del ejemplo anterior, la conversión sería la siguiente:

Conclusión

Concluimos definiendo al FDD como una metodología de desarrollo ágil destinada a proyectos cortos y de reducido personal, pero muy escalable por otra parte. A diferencia de otras, no define explícitamente una fase para la obtención de requisitos ni para la realización de pruebas. Sin embargo, al dividir el proyecto en unidades pequeñas (rasgos), esta metodología es la más adecuada para realizar un seguimiento y una monitorización del progreso. Respecto a la carga de trabajo que recae sobre los desarrolladores, FDD podemos decir que es un proceso intermedio, basándonos en genera más documentación que algunas metodologías ágiles, pero no tanta como otras, y es en la fase de diseño, con sesiones de trabajo conjuntas donde se decide la estructura de la arquitectura. En cuanto a la relación con el cliente, esta es fluida y sin excesivos formalismos, basada en controles propios y una comunicación constante. Como puntos flacos de este tipo de desarrollo software observamos la necesidad de poseer expertos en el equipo de trabajo que marquen desde el principio el camino a seguir, con el modelo global. Además, como ya hemos comentado, existe demasiada jerarquización entre los roles. Estos hechos pueden restarle fluidez al desarrollo. Pero sus principales puntos fuertes son que disminuye en gran medida el riesgo de los proyectos, con la constante monitorización de su calidad (sencilla gracias a la división en rasgos) y las periódicas entregas tangibles (gracias a la estructura iterativa de sus fases), y que además es muy adaptativo y permite cambios de último momento.

Agile Unified Process
El AUP o Proceso Unificado Agil de Scott Ambler es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Agil, Gestión de Cambios Agil, y Refactorización de Base de Datos para mejorar la productividad. (RUP).

Disciplinas:
A diferencia del RUP, el AUP tiene tan solo 7 disciplinas: 1. Modelo. Entender el problema planteado por el proyecto e identificar una solución para abordar el problema. 2. Implementación. Transformar el modelo(s) en código ejecutable y realizar pruebas de nivel básico en concreto prueba de unidad. 3. Pruebas. Realizar una evaluación objetiva para asegurarse la calidad. Esto incluye encontrar defectos, asegurarse de que el sistema funciona como debería y verificar que cumple los requisitos. 4. Desarrollo. Planificar la entrega del sistema y ejecutar el plan para hacer que el sistema este disponible para el usuario final. 5. Administrar la Configuración. Administrar el acceso a los artefactos del proyecto. Esto incluye Esto incluye el seguimiento de versiones de artefactos a través del tiempo, asi como el control y la gestión de los cambios a los mismos. 6. Administración del Proyecto. Dirigir las actividades que toman parte en el proyecto. Esto incluye la administración de riesgos, dirigir personas (asignarles tareas, llevar el seguimiento de su progreso, etc), y coordinarse con personas y sistemas fuera del ámbito del proyecto para asegurarse que se entrega a tiempo y dentro del presuspuesto 7. Medio Ambiente. Apoyar el resto del esfuerzo, garantizando que el proceso es adecuado, las guias (normas y directrices), y las herramientas (hardware, software, etc) están disponibles para el equipo según sea necesario.

Entrega de versiones incrementales con el tiempo:
En lugar del enfoque “Big Bang” de entregar el software todo en una entrega en vez de entregar porciones (por ejemplo, la versión 1, versión 2, y así sucesivamente), los equipos AUP suelen ofrecer versiones de desarrollo al final de cada iteración en las fases de pre-producción. Una versión de desarrollo de

una aplicación es algo que podría ser potencialmente lanzado si pasara los controles de calidad de pre-producción, pruebas y procesos de desarrollo. En la imagen se observa que la primera versión de producción suele tomar mas tiempo de desarrollo que las demás; en la primera versión de un sistema el equipo tiene que establecer las bases, lo que lleva mucho tiempo, pero permitirá que las versiones siguiente sean lanzadas mas rápido. La entrega de la primera producción puede tomar doce meses, la segunda entrega, nueve meses, y luego, las siguientes versiones, se entregan cada seis meses.

Un enfoque inicial en los problemas de implementación no sólo te permite evitar los problemas, además también te permite aprovechar la experiencia obtenida durante el desarrollo. Por ejemplo, cuando se va a implementar el software en tu área de preparación debes tomar notas de lo que funciona y de lo que no, esas notas pueden servir como eje de las secuencias de comandos de instalación.

Principios:
1. Tus empleados saben que están haciendo. Los empleados no van a leerse los detalles de la documentación del proceso, pero necesitarán alguna orientación de alto nivel y / o formación de vez en cuando. El producto del AUP propone enlaces para muchos de los detalles, si estas interesados en ellos, pero no te fuerza a usarlos. 2. Simplicidad. Todo es descrito con precisión usando un puñado de paginas, pero sin pasarse. 3. Agilidad. El AUP se ajusta a los valores y principios del desarrollo ágil de software y de la Alianza Ágil. 4. Centrarse en actividades de alto valor. La atención se centra en las actividades que realmente cuentan, y no en cada cosa que pudiera pasar a lo largo del desarrollo del proyecto. 5. Independecia de las Herramientas. Con la AUP se pueden utilizar cualquier conjunto de herramientas que quiera el desarrolador. La recomendación es que utilice las herramientas que se adapten mejor para el trabajo, que a menudo son herramientas simples. 6. Adaptar el AUP para que cumpla tus necesidades. Bibliografía http://www.ambysoft.com/unifiedprocess/agileUP.html http://en.wikipedia.org/wiki/Agile_Unified_Process

Introducción
DSDM (Dynamic System Development Method) es considerada la primera metodología ágil y es la única de ellas que ha sido declarada en un Consorcio formado por 17 personas en Gran Bretaña en el año 1994. El origen de esta metodología surgió como resultado de la búsqueda de una metodología pública que se ajustase a cualquier herramienta de desarrollo de software y que pudieras ser usado en proyectos RAD (Rapid Agile Development). Creado con la experiencia de los fundadores en las prácticas que se llevaban a cabo en la industria del software el primer modelo DSDM fue liberado en el año 1995. Su involucración en la industria fue positivo por lo tanto el presidente del Consenso decidió que sería útil crear un libro sobre la aplicación real del método a los proyectos de software. Esta metodología se basa en 9 principios que se apoyan en la ideología RAD: 1. Es obligatoria la involucración del usuario en el proyecto. 2. Los equipos de trabajo que desarrollen el proyecto deben de poder tomar decisiones. 3. Se deben de producir entregas frecuentemente para comprobar el estado del proyecto. 4. Las entregas deben cumplir los propósitos de modelo que se indicaron. 5. La solución del negocio requiere un ciclo de desarrollo iterativo e incremental. 6. Cualquier cambio en el desarrollo es posible, ya que este método permite la reversibilidad. 7. Los requerimientos del proyecto están especificados a un alto nivel. 8. El testeo se integra en el mismo ciclo de vida. 9. La colaboración y cooperación entre los miembros interesados en el proyecto es esencial.

Fases
El DSDM tiene un ciclo de desarrollo dividido en 5 fases: Estudio de factibilidad: en esta fase se comprueba que la metodología se ajuste al proyecto que se va a llevar a cabo. Estudio de negocio: Se establece la temprana comunicación con el cliente para llegar a las bases del sistema que deberá de desarrollarse y como deberán de operarse. Se encuentran las necesidades de más alto nivel del software y se sientan las bases del desarrollo a su alrededor, junto a los costes de tiempo y capital Iteración del modelo funcional: como su nombre indica es la primera iteración que se lleva a cabo en ella se deben de crear prototipos que puedan ser usados y vaya supliendo necesidades del sistema a desarrollar en cada iteración. Esta iteración se divide en 4 subfases principales: Acordar Plan, Crear Prototipo, Revisar Prototipo e Identificar Prototipo funcional. Iteración de Diseño y Construcción: Crea el diseño de la aplicación y se construirá atendiendo a este empleando el prototipo generado en la fase anterior. También está dividido en 4 subfases principales: Acordar plan, Crear prototipos de diseño, Revisar los prototipos de diseño e Identificar estos prototipos. Implementación e implantación: En esta fase se produce el beta-testing además de enseñar a los usuarios a usarla, se crean los manuales de uso de la aplicación, se encuentran errores en el uso si es que existen, se restablecen los criterios del negocio y si hay errores se vuelve a comenzar el ciclo de vida, en caso contrario se implantará el software entregándoselo al cliente (empresa o usuarios).

El creador del modelo de desarrollo XP ha aceptado que la imagen corporativa de DSDM es mejor que la de su modelo y se ha creado una especie de fusión entre ambos llamada EnterpriseXP.

Roles de trabajo
La gente que trabaja junta de manera efectiva son el fundamento de un proyecto exitoso. El DSDM reconoce esta necesidad y asigna papeles y responsabilidades claros a cada persona en el proyecto, ya sean clientes o proveedores. Estas dos comunidades deben trabajar hombro con hombro en los proyectos DSDM rompiendo toda barrera que impida la comunicación. Los principales roles a desempeñar son:

Patrocinador de negocio:
Es el nivel más alto en la parte del proyecto. Se encarga de resolver las dudas de negocio a cualquier persona y decidir las decisiones financieras. Tiene la gran responsabilidad de que el proyecto se desarrolle a la velocidad adecuada y eficazmente. Sus responsabilidades son:      Se encarga del caso de negocio del proyecto. Asegura la viabilidad del proyecto con respecto al plan establecido. Regula los fondos y otros recursos disponibles conforme a las necesidades. Controla que las tomas de decisiones de proceso solucionan las dudas de manera efectiva y rápida. Responde rápidamente ante problemas de tamaño considerable y encuentra soluciones eficaces.

Visionario de Negocio
Uno de los niveles más altos del proyecto. Está involucrado de manera más activa que el Patrocinador, es el responsable de interpretar las necesidades del Patrocinador y comunicar estas necesidades al equipo intentando fielmente el plan de proyecto. Además, aprovisionará al equipo de desarrollo con una dirección estratégica y asegurándose de que la solución escogida a la hora de solucionar un problema conseguirá los beneficios estimados.

Sus responsabilidades son:          Posee la mayor implicación en el proceso de desarrollo de los papeles organizativos. Define la visión de proyecto. Comunica y promueve la visión de negocio a todas las partes interesadas. Monitoriza el progreso del proyecto en la línea de la visión de progreso. Contribuye a los requerimientos, diseño y reseñas clave. Provee cambios a los requisitos de alto nivel. Asegura la colaboración entre los clientes y el área de trabajo. Comprueba que existan los recursos necesario. Promociona la traducción de la visión de negocio al ámbito del trabajo. Actúa como árbitro definitivo entre desacuerdos de los miembros del equipo.

Analista de Negocio
Está íntegramente integrado con el equipo de desarrollo de soluciones y es el centro de las relaciones entre los encargados de gestionar el negocio y los técnicos, proveyendo una dirección acertada y decisiva provista por el equipo de desarrollo de soluciones en una base diaria. Es el encargado de comprobar que todas las necesidades se analizan correctamente y se reflejan en el plan de desarrollo. Otras de sus responsabilidades son:   Asegura la implicación día a día de las decisiones de negocio en el proyecto de manera fiel. Controla el desarrollo, distribución y base de la documentación y productos que tienen relación con los requerimientos de negocio y su interpretación.

Desarrollador de soluciones
Interpreta los requerimientos de negocio y los traduce a una posible solución que logra solucionar las necesidades funcionales y no funcionales. Debería de estar a tiempo completo desarrollándose en un único proyecto. Sus responsabilidades son:  Trabaja con los encargados del negocio y el equipo de pruebas de soluciones con el fin de desarrollar iterativamente:

-

Una solución desplegable. Modelos requeridos para el apropiado control del desarrollo de soluciones. Modelos y documentación requerida para el fin de sostener la solución en tiempo real de uso.

  

Escucha e interpreta los detalles de cambios en requerimientos, soluciones, definiciones… Hacen sus propias pruebas y les dan más prioridad que a las pruebas de otros equipos. Participa en cualquier trabajo de estimación de calidad para asegurar que los productos desarrollados se ajustan al plan.

Probador de soluciones
El probador de soluciones está totalmente integrado con el equipo de desarrollo de soluciones y ejerce pruebas en relación a la estrategia de pruebas técnicas plasmadas en el proyecto. Sus responsabilidades son:   Trabaja con los encargados del negocio para definir los escenarios y casos de prueba para la solución propuesta. En compromiso con la Estrategia Técnica de Pruebas: Visiona todos los tipos de soluciones como uno. Crea productos de pruebas. Reporta los resultados de las actividades de prueba al coordinador técnico de propósitos de calidad y seguridad. Mantiene al líder del equipo informado de los resultados de las pruebas. Ayuda al Embajador y al Consejero de Negocio a asegurar que pueden planear y llevar a cabo sus pruebas lo suficientemente bien como para asegurar algunos puntos para asegurar que ciertas áreas están cubiertas.

Consejero de Negocio:
Actúa como compañero del Embajador de Negocio, el consejero es quien provee de ayudas específicas y especialistas al desarrollo de soluciones o a la prueba de estas. Normalmente será un usuario con buenos conocimientos o un beneficiario de la solución, aunque quizás simplemente ofrece un apoyo a las bases legales del proyecto.

Sus responsabilidades son:  Provee ayudas y aportes especialistas campos relevantes como el entrenamiento de usuarios, decisiones día a día en proyectos, organizando y controlando la aceptación de los resultados de las pruebas en el negocio.

Facilitador de Taller
Es el responsable de controlar el proceso de taller y el catalizador en la preparación y comunicación. También es el responsable del proceso en el taller, aunque no del contenido de este. Sus responsabilidades son: Para cada taller:       Acepta el campo del que se ocupará el taller con el propietario de este. Planea el uso del taller. Familiariza a los sujetos con el área de trabajo. Comprueba las capacidades de los trabajadores en el campo. Asegura que comprender los objetivos del trabajo. Anima a lo largo del proceso de trabajo.

Coach
El papel de Coach es una ayuda para el equipo con limitada experiencia que usa DSDM para obtener todo el provecho del equipo posible. Debería de ser una persona con certificación acreditada para estar capacitado para llevar a cabo el trabajo y tener los conocimientos necesarios. Sus responsabilidades son:    Provee detallado conocimiento y experiencia sobre la metodología y el tema a tratar. Confecciona el proceso de trabajo para adaptarlo a las necesidades individuales del proyecto y el ambiente en el que se está operando. Ayuda al equipo a usar técnicas de la metodología y prácticas, y ayuda a aquellos fuera del equipo a apreciar la filosofía DSDM y su valor. Ayuda al equipo de trabajo a adentrarse en la colaboración y la cooperación demandada por la metodología DSDM y Ágil. Mejora las aptitudes del equipo en DSDM.

 

Roles de especialistas:
Se encargan de aportar todo lo posible al campo de conocimiento del proyecto en el cual son expertos e intentar trabajar con total eficacia siguiendo las indicaciones de las capas superiores y adaptándose al plan de desarrollo. La decisión de que todo acabe bien es suya al ser la mano de obra principal el proyecto. Si su forma de trabajo no es la correcta sufren en mayor medida la capacidad de ser sustituidos.

Esquema de Roles de Atern (último DSDM)

Conclusión:
Como hemos podido comprobar en este trabajo el DSDM es una metodología que tiene en mente la limitación de recursos y que la velocidad es importante. Además, se preocupa en gran medida por la colaboración entre la empresa de desarrollo y el cliente. Se interesa mucho por la coordinación y el control sobre la comunicación colocándola en el centro de la metodología. En el DSDM se mezclan las bases para el desarrollo ágil y una organización estricta del equipo y la planificación. Debería ser utilizado en proyectos que puedan tener especificaciones cambiantes o que necesiten desarrollarse en poco tiempo. Y lo más importante es que fue creado en un consenso de expertos lo que hace que sea una metodología ideal y de utilidad bien demostrada, además puede ser utilizada junto con otras metodologías. La metodología sufrió una importante atención debido a los beneficios del feedback que se obtenía de los usuarios que trabajaban codo con codo en el proyecto.

Metodología Crystal:
Introducción: La familia de metodologías Crystal nace a principios de los 90 por uno desarrollador de software llamado Alistair Cockburn en base a sus distintos proyectos y experiencia. Es un tipo de metodología ágil cuyo nombre viene de su comparación de los grupos con los minerales según su color o dureza. Se caracteriza por su gran énfasis en la comunicación y su tolerancia, que la hace ideal en casos en los que XP es inaplicable o para proyectos pequeños. Crystal se define con mucho énfasis en la comunicación y de forma muy ligera en relación a los productos periódicos entregables. Aneja interacciones cortas con feedback frecuente por parte del cliente, minimizando los productos intermedios. También cuenta con usuarios reales que participan en la definición del producto como tal. Esta familia dispone de unos códigos de color para marcar la complejidad de cada una de las metodologías que la componen: de más oscuro y pesado a más claro y ligero; y de mayor criticidad y rigor a menor. Situadas en una gráfica, estas metodologías siguen los parámetros de Comodidad, Dinero Discrecional y Esencial y Vidas. Según este código de colores, el Clear es para equipos de 8 o menos personas, el Amarillo para equipos de entre 10 y 20 personas, el Naranja para equipos de entre 20 y 50 personas, el Rojo de 50 a 100 y el Azul de 100 a 200. Valores o Propiedades: Como casi todos los métodos, Crystal Clear consiste en valores, técnicas y procesos. Los siete valores o propiedades de esta metodología son: – Entrega frecuente a los clientes, lo cual no consiste tan solo en compilar, sino en evaluarlo. La frecuencia de esto dependerá de la complicación del proyecto. Al hacer esto aseguramos que el proyecto cumple las condiciones que espera el cliente, evitando malentendidos en el análisis del sistema. – Comunicación osmótica, es decir, todos los integrantes del grupo deberán estar desarrollando en la misma sala, con periódicas reuniones separadas para que los concurrentes se concentren mejor.

– Mejora reflexiva, es decir, periodos de reflexión para que los desarrolladores puedan pensar, tomar notas, reflexionar, relajarse, discutir... Se obtienen así una serie de hábitos o prácticas de desarrollo que nos gustaría mantener, una lista de lo que nos gustaría intentar y de lo que queremos evitar, generando así una mejora continua en nuestro proyecto. – Comunicación Osmótica, es decir, todos juntos en el mismo cuarto. La posición física de los desarrolladores es muy importante en Crystal, ya que nos permite no tomarnos demasiado tiempo en solucionar las dudas y contrastarlas con otros miembros del equipo. – Seguridad personal y buena comunicación entre los integrantes cuando algo molesta o no está bien, en lugar de encubrirlo, para así poder mejorarlo y desarrollar un software libre de errores. – Foco, saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicación sobre dirección y prioridades con el Patrocinador Ejecutivo; lo segundo de un ambiente en el que la gente no se vea compelida a hacer otras cosas incompatibles. – Fácil acceso a usuarios expertos, ya que es muy importante el contacto directo con expertos en el desarrollo de un proyecto, y un encuentro semanal y llamadas telefónicas adicionales o el entrenamiento de los desarrolladores como usuarios pueden resultar muy beneficiosos. – Ambiente técnico con pruebas automatizadas, management de configuración e integración frecuente. Deberán integrarseun mínimo de dos veces por semana. Técnicas: Además comparte algunas técnicas con el resto de metodologías ágiles, que a pesar de no ser obligatorias como en otras como el XP, si es conveniente utilizarlas. Estas son: – Exploración de 360º, tomando muestras del valor de negocio del proyecto, sus requerimientos, su modelo de dominio, tecnología, plan de proyecto y proceso entre otros. – Victoria temprana, ya que es mejor tener pequeños entregables periódicos cada poco tiempo que entregar el producto terminado al cabo de mucho.

– Esqueleto ambulante, una transacción debe ser simple pero estar completa, no dejarla a medio programar, ya que al volver a mejorarla al cabo de un tiempo puede habérsenos olvidado el código y ser incapaces de mejorarla sin mermar sus funcionalidades. – Rearquitectura incremental, es decir, la arquitectura del proyecto debe mejorar en etapas, manteniendo el sistema en ejecución mientras se modifica. – Radiadores de información, unos paneles con la evolución del proyecto y sus requisitos para que los integrantes del grupo puedan tenerlo disponible en cualquier momento para ser observado y recordado o modificado. Crystal sigue una serie de técnicas para completar el proyecto. Estas son: – Entrevistas de proyectos a más de un responsable para tener varias visiones del software que se va a desarrollar. – Talleres de reflexión para que el equipo discuta sobre el trabajo, pros y contras, mejoras, planes para las siguientes interacciones, etc. – Planeamiento relámpago o Poker, tal y como se utiliza en XP, con tarjetas con valores según la dificultad de las tareas a realizar. – Estimaciones de pericia mediante el proceso Delphi.

– Encuentros diarios breves para la identificación de problemas o fallos. – Programación por parejas, que establece proximidad.

Procesos: Esta metodología no especifica ningún ciclo ciclo de vida o modelo de procesos, pero determina una guía estándar de las prácticas más utilizadas. Estas son: Planificación por etapas del siguiente incremento del sistema. Debe finalizar con una versión ejecutable cada tres o cuatro meses. El equipo selecciona los requisitos que serán implementados en cada incremento y planifican lo que harán. Revisiones y resúmenes de cada iteración de cada incremento

-

según sus actividades: construcción, demostración y resúmenes de los objetivos del incremento. Monitorización de los progresos a partir de las entregas del equipò durante el desarrollo. Se mide con los hitos clave y la estabilidad de las fases. Paralelismo y flujo. Cuando el monitor de estabilidad nos indica un estado estable para su revisión se pasa a la siguiente tarea. Los equipos de seguimiento y arquitectura deben revisar sus planes de trabajo, su estabilidad y su sincronización para llevar esto a cabo.

-

Roles: En Crystal se establecen unos roles bien definidos para cada integrante del grupo. Estos son: Patrocinador, que consigue recursos y define el proyecto y produce la Declaración de Misión con Prioridades de Compromis o (Tradeoff). Pone y defiende su inversión en el proyecto. Tiene en mente la visión a largo plazo del mismo. Crea la visibilidad externa para el producto y provee al equipo de decisiones cruciales para el negocio. También puede tomar la decisión de si seguir o no con el proyecto si no lo ve una inversión rentable y, de continuar, deberá replantear las funciones restantes para recuperar la inversión. EN Crystalse hace mucho incapié en dar buena información al sponsor para que pueda tomar sus decisiones correctamente. Usuario Experto, que produce la Lista de Objetivos y el Archivo de Casos de Uso y Requerimientos. También sugiere maneras de optimizar su uso con macros, modos de visualización y navegación y cualquier otra sugerencia. Es una base de conocimiento para el Experto de Negocio. Se espera que conozca las reglas del negocio necesarias para el sistema, las políticas que son estables y las propensas al cambio. Experto de Negocios, que componen la Lista de Objetivos del proyecto, Archivos de Casos de Uso y Requerimientos. Debe conocer las reglas y políticas del negocio. Es experto en indicar cómo va el negocio. Responderá a varias preguntas de los desarrolladores acerca del sistema. Provee información diferente de la entrega el Usuario Experto, e incluso puede suceder que el mismo Usuario sea el Experto de Negocios.

-

-

-

Diseñador Principal, que produce la arquitectura del producto, llamada Descripción Arquitectónica. Debe manejar con fluidez, mezclar e inventar procedimientos. Tiene los roles de coordinación, arquitecto, maestro y programador más experto. Es por tanto el líder técnico del equipo. Diseñador-Programador, que produce unos borradores de pantallas y el modelo común, al igual que otra serie de documentos de diseño de software como notas, diagramas de diseño, código fuente, código de migración, pruebas y sistema de empaquetado. Dado que un programa desarrollado en Crystal es diseño y programa, sus desarrolladores harán las veces tanto de programador como de diseñador, por tanto cualquier individuo que no cumpla ambos requisitos no tiene cabida en este tipo de desarrollo de software. Coordinador, que junto con el equipo produce el Mapa del Proyecto y su Plan de Entrega, Lista de Riesgos, el Plan y Estado de Iteración y la Agenda de Visualización. Suele ser una ocupación parcial en alguno de los demás miembros del equipo. Alternativamente, el Patrocinador o Diseñador Principal pueden asumir este rol. Verificador, que produce los reportes de fallos y bugs. Puede ser tanto una sola persona como todo un equipo de programadores. Escritor, que produce el manual para el usuario.

-

-

-

-

Desarrollo de un proyecto: En el desarrollo de un proyecto en Crystal se deben tener en cuenta para empezar las personas que componen un equipo, el aspecto humano del mismo, la comunicación entre los componentes, las distintas políticas a seguir y el espacio físico de trabajo. Especial importancia tiene el tamaño del equipo, ya que si es elevado produce una metodología más pesada. También es importante una comunicación cercana para que sea más barata y efectiva, recomendando el cara a cara. Dado que Crystal no es una metodología concreta sino más bien una familia de ellas, todas comparten una serie de características llamadas código genético. Estas son: 1. Modelo de Juego Cooperativo, dividiendo a los integrantes del equipo en grupos o partidos cuyos objetivos consisten en inventar y comunicar para mejorar su concentración. Cada partido es diferente y

tiene como objetivo la entrega de software y preparación para el siguiente juego. 2. Prioridades, que son - Eficiencia en el desarrollo, para que los proyectos sean rentables económicamente hablando. - Seguridad en lo que se entrega. - Habilidad para hacer que todos los miembros del equipo adopten las convenciones de trabajo establecidas por el equipo.

3.

Propiedades, que son: - Frecuencia de las entregas usables de entre 2 semanas y un mes. - Comunicación, que es uno de los pilares de esta familia de metodologías. Por eso el suo de pizarras u otros espacios destinados a la comunicación y la notificación del estado del proyecto son prácticas frecuentes. - Creciminento reflexivo, utilizando periodos de reflexión y reuniones entre los integrantes del equipo para mejorar la eficiencia de estos. - Seguridad personal con un equipo en el que todos sus miembros se sientan cómodos con el trabajo y el entorno. - Concentración - Fácil acceso a los usuarios clave haciendo que sean parte del desarrollo - Entorno técnico especializado. Mientras que las 3 primeras son obligatorias, Crystal es más flexible con el resto. 4. Principios, el grado de detalle necesario en la documentación y ajuste en la forma de trabajo acorde con la personalidad para encajar con los miembros del equipo. 5. Estrategias, ya comentadas anteriormente: Victorias Tempranas, Exploración de 360º, Esqueleto ambulante, Rearquitectura Incremental y Radiadores de Información. 6. Técnicas, también comentadas con anterioridad, como las Reuniones Periodicas o las de Reflexión.

Conclusión: Como conclusión podemos remarcar que las metodologías Crystal son altamente recomendables para equipos pequeños. Son flexibles y priorizan la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza entre los integrantes del grupo. Los requisitos se obtienen mediante programación por parejas. También presta especial atención al espacio físico donde se sitúa el equipo y a la comunicación. La necesidad de las entregas periódicas, además, estimulan la concentración y resalta la importancia de la comunicación con el cliente junto con las reuniones. Por último, el equipo elige que técnicas aplicar según las características del proyecto.

COMPARATIVA:
- Tamaño de los equipos FDD: Pensado para proyectos cortos y equipos pequeños, pero muy escalable. Crystal: Preferiblemente para equipos de tamaño reducido, pero modificable según el peso del proyecto. DSDM:Pensado para proyectos que deben desarrollarse de manera rápida con un equipo ajustado y dirigido. AUP: Preferiblemente aumentar el tamaño. - Obtención de requisitos FDD: No define explicitamente esta parte del proyecto, sino que propone proceder a partir de un momento en el que ya se han recogido de la manera que se quiera, en las 3 primeras fases. Crystal: El equipo elige la manera en la que obtendrán los requisitos, si bien debe haber comunicación suficiente para debatrilo y que todos los integrantes trabajen a gusto. DSDM: Se definen los requisitos en dos fases iniciales llamadas estudio de factibilidad y estudio de negocio. AUP: Se produce en la primera fase, que está destinada específicamente para ello, y condiciona la siguiente iteración. - Carga de trabajo FDD: A medio camino entre la documentación y el desarrollo, bastante libre para los desarrolladores auque con orden, porque estos están muy jerarquizados. Crystal: Cada componente del equipo tiene su papel, especificando uno concreto para la docuemntación (Escritor), para la arquitectura (Diseñador Principal), la programación (ProgramadorDiseñador), etc. DSDM: El trabajo está muy organizado en niveles muy claros y con funciones definidas, la carga se reparte en la medida de lo posible entre todos los niveles. pequeños, pero con posibilidad de

AUP: Se centra totalmente hacia el desarrollo colocando las cuestiones de documentación o planificación en segundo plano.

- Relación con el cliente FDD: No tiene formalismos en la documentacion, realiza controles propios y una comunicación fluida con el cliente. Éste recibe una muestra al final de ca da iteracion corta. El feedback del cliente ya no marca el progreso, porque éste queda restringido por el modelo de dominio creado en las primeras fases. Crystal: Mucha relación con el cliente en forma de entregas periódicas y reuniones diarias. DSDM: Trabaja codo con codo con el cliente o los usuarios finales obteniendo el beneficio de un feedback que ayudaban a mejorar el proyecto. Se hacen entregas frecuentes al cliente para comprobar el estado del desarrollo. AUP: El cliente recibe pequeñas entregas cada poco tiempo y entregas más complejas, por lo general, cada 12, o cada 9 meses. - Desarrollo FDD: Proceso iterativo. Se centra en la organización global. Y cada iteración acaba con un producto totalmente completo (con manual de instrucciones, nota..) Crystal: Se realizan gran cantidad de iteraciones con productos completos y usables. DSDM: Tres fases principales con subfases que se ejecutan de manera iterativa. Se integran pruebas durante todo el ciclo de vida del proyecto. AUP: También es iterativo y cada iteración acaba con un microproducto efectivo que se entrega al cliente. - Códigos fuente FDD: Es propietario, cada programador trabaja por su cuenta. Aunque definen grupos y sesiones de trabajo, con los propietarios de clases relacionadas.

Crystal: Utiliza la programación por parejas para trabajar más dinámicamente y potenciar la comunicación. DSDM: Cada uno desarrolla su trabajo designado, no se utiliza el Pair Programming normalmente. AUP: Fomenta el trabajo en grupos pequeños cuyos miembros interactúan entre sí para mejorar el resultado final.

- Conocimiento sobre la arquitectura FDD: Se concreta en la fase de diseño con reuniones conjuntas, para conseguir una arquitectura sencilla y sin errores. Crystal: Existe un papel dentro del equipo llamado Diseñador principal que se encarga de la arquitectura, y a la vez todos los programadores son diseñadores en si mismos. DSDM: En las fases cada campo decide como se van a organizar, lo aceptan y se sigue el plan creado. AUP: Se decide al principio de cada iteración, en la fase de diseño.

- Evaluación del estado del proyecto FDD: Es el mas adecuado para la monitorizacion del progreso, porque se divide en unidades muy peueñas (los rasgos). Crystal: Son flexibles y priorizan la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza entre los integrantes del grupo. También presta especial atención al espacio físico donde se sitúa el equipo y a la comunicación DSDM: Durante todo el ciclo de vida se desarrollan pruebas que comprueban como se va desarrollando, hay un equipo destinado a desarrollar y probar esos tests. AUP: Muy rápido, pero contraindicado para grupos grandes o proyectos que por sus características no sean de fácil evaluación.

- Punto fuertes y puntos flacos FDD: División del software pequeña y manejable, pero excesiva jerarquización del personal. Crystal: Muy eficiente si el equipo tiene buen ambiente de comunicación y es escalable, pero restringe la ubicación del grupo a un único espacio físico. DSDM: Al ser propuesto por un consenso de expertos es una de las metodologías más recomendadas, además se puede utilizar junto con otras metodologías como XP o no ágiles como RUP, el feedback y la íntima relación con el cliente le dan seguridad y calidad al proyecto. Su punto flojo puede ser que en proyectos muy cortos puede complicarse la organización ya que es medianamente compleja. AUP: Garantiza un rápido progreso de producción y se centra más en el código como tal que en el diseño previo de éste.

Sign up to vote on this title
UsefulNot useful