You are on page 1of 27

Universidad Tecnológica Nacional Facultad Regional

2010

Crystal Clear Methodology

Melisa Guzmán – Legajo: 26.107 Víctor Alberto Soria – Legajo:

Contenido
Metodologías Ágiles........................................................................................3 ¿Qué significa ser ágil?................................................................................3 Los cuatro principios del manifiesto ágil.....................................................4 Metodología Crystal........................................................................................5 ¿Qué es Crystal Clear?...................................................................................6 Propiedades................................................................................................6 Estrategias.................................................................................................. 8 Técnicas......................................................................................................9 Proceso......................................................................................................10 Roles......................................................................................................... 10 Caso de Estudio............................................................................................13 Introducción..............................................................................................14 Cronología del Proyecto............................................................................14 Roles......................................................................................................... 14 Exploración...............................................................................................15 Reunión de Planeación..............................................................................17 Incremento 1: Esqueleto Caminante.........................................................18 Incremento 2: Tratamiento de Documentos..............................................20 Incremento 3: Multihilo.............................................................................20 Incremento 4: Búsqueda...........................................................................22 Conclusiones................................................................................................22 Evaluación de Crystal Clear.......................................................................23 Bibliografía y Sitios Web Recomendados......................................................24

Metodologías Ágiles
Las metodologías ágiles surgen como una alternativa, una reacción a las metodologías tradicionales y principalmente a su burocracia. Muchas ideas que se plantean en las metodologías ágiles no son nuevas, gran parte de ellas ya fueron reflejadas por Brooks en su mítico libro, The Mythical Man Month y en gran parte responden al sentido común. Algunos autores consideran que se ha cumplido un círculo que empezó con una reacción provocada por múltiples factores y señalada temporalmente por el manifiesto de Dijkstra, en el cual se hacía un llamamiento a la disciplina y que se cierra con el ya famoso Manifest for Agile Software Development, una petición por la relajación de los procesos en pro de las personas. La aparición de las metodologías ágiles no puede ser asociada a una única causa, sino a todo un conjunto, bien es cierto que la mayoría de autores nos indicarán que son una reacción a las metodologías tradicionales, pero ¿cuáles fueron las causas de esta reacción?, los factores que comúnmente más se mencionan que hicieron realidad esta nueva manera de desarrollar software son: • “Plumbing”. La traducción al castellano sería pesadez, lentitud de reacción, exceso de documentación, en definitiva, falta de agilidad de los modelos de desarrollo existente. Las metodologías existentes no cumplieron las expectativas planteadas inicialmente. Explosión de la red y las aplicaciones Web. Movimiento open source.

• • •

Definitivamente, las metodologías tradicionales exigen un sobreesfuerzo por parte del equipo de desarrollo en fases poco productivas, como es la documentación y debido a su estructuración (típicamente siguiendo el modelo en cascada o más actualmente UP) son poco flexibles a los cambios, de requisitos, de nuevas funcionalidades, etc. Si a todo esto le añadimos que las metodologías tradicionales no han sido capaces de eliminar todos los fallos, que persiguen al desarrollo de proyectos software prácticamente desde sus inicios, obtenemos un clima un poco escéptico respecto a las metodologías. A todo lo planteado, además debemos añadir un cambio bastante importante, en cuanto a la demanda del mercado del software, cada vez más orientada a la Web, con uno requisitos muy volátiles, que requieren tiempos de desarrollo cada vez más cortos y con una comunidad “in crescendo”, la comunidad del software libre.

¿Qué significa ser ágil?
Jim Highsmith dice que ser Agile significa ser capaz de “Deliver quickly, Change quickly, Change often”. Mientras que las técnicas ágiles pueden

variar en su ejecución y en su énfasis, todas ellas comparten características, incluyendo el desarrollo iterativo y que están centradas en la interacción, comunicación, y en la reducción de la creación de artefactos intermedios. Desarrollar mediante iteraciones permite al equipo de desarrollo adaptarse a los cambios de los requisitos. Trabajar con un alto grado de comunicación permite que el equipo pueda tomar decisiones y aplicarlas inmediatamente. La reducción de artefactos intermedios que no dan valor añadido al producto final, nos permite asignar más recursos al producto en sí y podrá ser acabado antes. Cockburn y Highsmith nos explican que lo que es realmente nuevo de los métodos ágiles, no son las prácticas que ellos utilizan, sino el reconocimiento de las personas como principales valedoras para que un proyecto triunfe, en conjunto con una gran orientación a la efectividad y la manejabilidad. La mayoría de seguidores de las metodologías ágiles están de acuerdo en que ser ágil, es algo más que seguir las guías que se supone que hacen un proyecto ágil. La verdadera agilidad es más que un conjunto de prácticas, es un estado de ánimo.

Los cuatro principios del manifiesto ágil
En marzo de 2001, Kent Beck convocó a 17 críticos de los modelos de mejora basados en procesos, justo un par de años antes Kent había publicado el libro "Extreme Programming Explained" en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la reunión se acuñó el término “Métodos Ágiles” para definir los métodos que estaban surgiendo como alternativa a las metodologías formales, consideradas excesivamente “pesadas” y rígidas por su carácter normativo y su fuerte dependencia de planificaciones detalladas, previas al desarrollo. De esta reunión surgiría un resumen en forma de cuatro principios, que actualmente conocemos como “Manifiesto Ágil”, que básicamente son los principios sobre los que se basan los métodos reconocidos como ágiles.

Manifiesto ágil (http://www.agilemanifesto.org)
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar: • • • • A los individuos y su interacción, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentación exhaustiva. La colaboración con el cliente, por encima de la negociación contractual. La respuesta al cambio, por encima del seguimiento de un plan.

Firmado por: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Metodología Crystal
La familia de metodologías Crystal es un conjunto de diferentes metodologías que podemos seleccionar en función de la adecuación al proyecto en el que nos encontremos. Crystal también incluye un conjunto de principios para adaptar las diferentes metodologías según las circunstancias del proyecto. Cada una de las metodologías de la familia Crystal tiene asignado un color, cuanto más oscura sea su tonalidad, más compleja es la metodología.

Crystal sugiere que escoger un color de la metodología para un proyecto en función de su criticidad y tamaño. Los proyectos más grandes suelen necesitar una mayor coordinación y metodologías más complejas que los proyectos más pequeños. Cuanto más crítico sea el sistema que queremos desarrollar, más rigurosidad necesitamos disponer en el desarrollo del proyecto. En la figura anterior aparecen unos caracteres (C, D, E y L) e indican las pérdidas potenciales por fallos del sistema, y lo hacen de la siguiente manera: • • • C, indica pérdida de confort debido a un fallo del sistema D, indica pérdida de dinero discrecional, es decir del que podemos disponer, generalmente nuestro. E, indica pérdida de dinero esencial, es decir dinero que probablemente no es nuestro y no podemos disponer de él libremente.

L, de Life en ingles, vida. Indica la pérdida de vidas por el fallo del sistema.

Las dimensiones de criticidad y tamaño, son representadas por un símbolo de la categoría del producto, que aparece en la figura. Por ejemplo, D6 indica un proyecto con un máximo de 6 personas, de máxima criticidad de dinero discrecional. Crystal Clear no es una metodología en si misma sino una familia de metodologías con un “código genético” común. La idea es poder armar distintas metodologías para distintos tipos de proyectos. Cada proyecto y organización usará este código genético para generar su propia metodología. Las metodologías que integran la familia Crystal tienen en común un conjunto de características. Primero, los proyectos siempre usan ciclos de desarrollo incrementales, de una longitud máxima de cuatro meses, siendo preferibles periodos de un mes a tres meses. Segundo, se hace énfasis en la comunicación y la cooperación de la gente. Tercero, las metodologías Crystal permiten el uso de prácticas y herramientas de otras metodologías ágiles como XP o Scrum.

¿Qué es Crystal Clear?
Crystal Clear está diseñada para pequeños proyectos, proyectos de categoría D6, pudiendo contar con un equipo de desarrolladores formado por 6 personas como máximo. Algunas modificaciones nos permitirían utilizar Crystal Clear con proyectos de tipo E8 o D10. Dada las limitaciones de comunicación de la estructura, el equipo debería encontrarse ubicado en una oficina común.

Grupos de hasta 8 personas

Reuniones en un mismo espacio

Proyectos pequeños

Proyectos no críticos

Propiedades
Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal o mensual. Al hacer esto aseguramos que nuestro proyecto no se despegara mucho de lo que el cliente necesita realmente, pues cada entrega formal, resultara en correcciones a los malentendidos que surgen continuamente en el análisis del sistema. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada semana o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir. Eso se llama hacer un "Taller de reflexión", obteniendo una lista de prácticas o hábitos de desarrollo que nos gustaría mantener, una lista de lo que nos gustaría intentar, y probablemente, una lista de lo que queremos evitar, todo esto escrito y publicado de alguna manera, a la vista de todos. Esto nos genera una mejora continua en nuestro proyecto y nos da el tiempo para corregir el camino, acelerar el desarrollo y mejorar nuestros hábitos y conocimiento de desarrollo. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseñador senior y discutir respecto del tema que se trate. La colocación física del equipo de desarrollo es de lo más importante, y la comunicación osmótica se refiere a llevar la comunicación al máximo nivel: Nos debe tomar menos de 30 segundos llevar nuestras dudas a los ojos u oídos de quien puede resolvérnoslas, debemos sentarnos en el mismo cuarto o en cubículos contiguos. Captar algo relevante de la conversación entre otros miembros del equipo al menos cada pocos días. El hecho de tener que levantarnos de nuestro escritorio, cruzar el pasillo y abrir una puerta, con toda seguridad nos distrae de nuestro tren de pensamiento. Irrumpir en la oficina de otro miembro del equipo y hacerle preguntas, a si sean de lo más simple, terminara por retrasar bajar nuestra productividad de manera crítica. Comparado con hacer una pregunta a una persona que está constantemente conectada en nuestro mismo tren de ideas, nos da la diferencia entre comunicación cerrada y la mejor, comunicación osmótica. Seguridad personal. Hablar con los compañeros cuando algo molesta dentro del grupo. Fomentar la confianza y el respeto entre el entre el equipo, de manera que todos tengan claro que lo importante es lograr los objetivos del proyecto de manera conjunta. Así, las equivocaciones e incapacidades de unos, pueden ser cubiertas por los demás, los miembros no temen exponerse, y el equipo respeta estas exposiciones. Tres exposiciones en particular son importantes

• • •

Revelar nuestra ignorancia Revelar nuestros errores Revelar nuestra incapacidad en una tarea asignada

Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Cada quien debe saber cuáles son los dos elementos de más alta prioridad sobre los cuales trabaja en todo momento. Además, deberíamos tener garantizado todos por lo menos dos días seguidos y dos horas ininterrumpidas por día para trabajar en un proyecto. Fácil acceso a usuarios expertos. Tener alguna comunicación con expertos desarrolladores. Nos debería de tomar menos de tres días en promedio, desde que surge una duda respecto al uso del sistema, hasta que un usuario experto la resuelve. Inclusive lo deseable, es poder obtener las respuestas en unas cuantas horas cuando mucho. Si surge una duda sobre en el desarrollo de la funcionalidad, y podemos levantar el teléfono para comunicarnos con el usuario experto en el dominio, hacerle algunas preguntas y seguir con el desarrollo, entonces estamos del otro lado. Esto no es siempre posible, pero por lo menos será importante poder agendar una cita para visitar o ser visitado por nuestro usuario experto. Ambiente técnico con pruebas automatizadas, gestión de la configuración e integración frecuente. Poder dejar corriendo las pruebas de nuestro desarrollo hasta el final sin estar físicamente presente nos ahorra el tiempo que no tenemos, sin mencionar las ventajas de depuración inmediata y de probar el código indiscriminadamente. Todos los desarrolladores deberían ingresar el código en el que trabajan en un sistema de administración de la configuración, de manera que este se encargue de llevar el control de versiones, documentos, etc. y escribir una nota útil sobre el código cuando lo ingresan. El sistema se debería integrar por lo menos dos veces a la semana, juntando el código de todos, compilándolo, y haciéndolo pasar por todas las pruebas automáticas posibles, y obteniendo de esta manera código ejecutable constantemente. El sistema funciona más o menos así: Se diseñan los test antes del desarrollo. El sistema se integra frecuentemente en el sistema de manejo de configuración y se pasa por todos los test, mostrando los resultados de inmediato.

Estrategias
Exploración de 360°. Verificar o tomar una muestra del valor de negocios del proyecto, los requerimientos, el modelo de dominio, la tecnología, el plan del proyecto y el proceso.

Éxito temprano. Es mejor buscar pequeños triunfos iniciales que aspirar a una gran victoria tardía. Esqueleto caminante. Es una transacción que debe ser simple pero completa. Rearquitectura incremental. Se ha demostrado que no es conveniente interrumpir el desarrollo para corregir la arquitectura. Más bien la arquitectura debe evolucionar en etapas, manteniendo el sistema en ejecución mientras ella se modifica. Radiadores de información. Es una lámina pegada en algún lugar que el equipo pueda observar mientras trabaja o camina. Tiene que ser comprensible para el observador casual, entendida de un vistazo y renovada periódicamente para que valga la pena visitarla.

Explorar 360º

Radiador es de informaci ón

Éxitos tempran os Estrateg ias

Re arquitectur a increment al

Esquelet o camina nte

Técnicas
Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener visiones más ricas. Talleres de reflexión. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el período siguiente. Planeamiento Blitz. Se escriben las funciones del programa en tarjetas y los programadores estiman tiempos para cada una de forma independiente entre las mismas. Estimación Delphi con estimaciones de pericia. Los expertos se reúnen y definen el tamaño del proyecto, fecha de entrega, etc. Encuentros diarios de pie. Cinco a diez minutos como máximo. No se trata de discutir problemas, sino de identificarlos.

Miniatura de procesos. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un día. La idea es que la gente pueda “degustar” la nueva metodología. Gráficos de quemado. Son gráficas en las cuales se observan retrasos en las tareas, este gráfico sirve para tener un control del proyecto y ver en que funciones deben tener mayor prioridad. Programación lado a lado. Establece proximidad, pero cada quien se enfoca a su trabajo asignado, prestando un ojo a lo que hace su compañero, quien tiene su propia máquina. Esta es una ampliación de la Comunicación Osmótica al contexto de la programación.

Proceso
La familia de metodologías Crystal no especifica ningún ciclo de vida concreto, ni ningún modelo de procesos, en vez de eso lo que hace es determinar una guía de las políticas estándar, productos de trabajo, asuntos locales, herramientas, estándares y roles. A continuación veremos las prácticas más comunes de las metodologías Crystal: Planificación por etapas. Básicamente consiste en la planificación del siguiente incremento del sistema. La planificación debe finalizar con una versión ejecutable cada tres o cuatro meses como máximo. El equipo selecciona los requisitos que serán implementados en el incremento y planifican lo que creen que serán capaces de hacer. Revisiones y resúmenes. Cada incremento consta de diferentes iteraciones y cada iteración incluye las siguientes actividades: construcción, demostración y resumen de los objetivos del incremento. Monitorización. Los progresos del proyecto son monitorizados a partir de las diferentes entregas del equipo durante el proceso de desarrollo. El progreso se mide con los hitos clave y la estabilidad de las fases (muy inestable, fluctúa y lo suficiente estable para revisar). Paralelismo y flujo. Cuando el monitor de estabilidad nos indica un estado lo suficientemente estable para su revisión, entonces es el momento para pasar a la siguiente tarea. Con tal de poder llevar esto a cabo, los equipos de seguimiento y arquitectura deben revisar sus planes de trabajo, su estabilidad y sincronización.

Roles
• Sponsor: persona que se encarga de poner y hasta defender su inversión en el proyecto. Es quien tiene en mente la visión a largo plazo. Esta persona es quién creará la visibilidad externa para el proyecto y proveerá al equipo de decisiones cruciales a nivel de negocio. Si el costo del desarrollo sobrepasa la inversión disponible, debe tomar la decisión de seguir o no con el proyecto; si continúa, deberá replantear las funciones restantes para recuperar la inversión. Parte de la metodología involucra dar buena información al sponsor para que tome sus decisiones. Usuario Experto: Esta es la persona que se supone está familiarizada con los procedimientos operativos del sistema en uso (si es que existe uno), conociendo cuáles son los modos de operación más y menos frecuentemente utilizados, qué atajos son necesarios, y qué información necesita verse en conjunto en una misma pantalla. Es una base de conocimiento diferente de la que se espera que posea el Experto en Negocio. De la persona que asume el rol de Usuario Experto, se espera que conozca las reglas de negocio necesarias para el sistema, qué políticas son estables frente a las que son propensas al cambio. No se espera que el Experto en Negocios tenga una íntima familiaridad con las actividades minuto a minuto de la población de usuarios, a diferencia del Usuario Experto. Líder de Diseño: Esta persona es el líder técnico, se supone que tiene experiencia en el desarrollo de software, que es capaz de realizar la mayor cantidad de diseño del proyecto y de encaminar al equipo cuando sea necesario. En términos de niveles de competencia, se espera que el líder diseñador sea un diseñador de nivel 3. Partiendo

de que en un proyecto Crystal Clear hay sólo de tres a ocho personas, al menos una de ellas debe ser competente y experimentada, esto significa de nivel 3. Usualmente, hay un par de aprendices o juniors entre los miembros del proyecto. Como medida de seguridad, se designa el rol de líder diseñador, separado de los otros roles. Se espera que el líder diseñador desempeñe tareas tanto de diseño como de programación, al igual que un programador diseñador. Usualmente, no siempre, el líder diseñador es la persona más experimentada del equipo y que también debe asumir las asignaciones de programación más difíciles. Esto es común, y de hecho representa un riesgo para el proyecto. El líder diseñador tiende a estar sobrecargado, teniendo roles como coordinador, arquitecto, mentor y programador más experimentado. Cualquier cosa que pueda hacerse para liberarlo de tareas, mejorará el perfil de riesgo del proyecto. La opción obvia es elegir a alguien que interprete el rol de coordinador, total o parcialmente. • Diseñador Programador: Es una persona que reúne las características de un diseñador, como de un programador. El diseño sin programación, representa fallas durante la retroalimentación (en proyectos de todos los tamaños). Es raro que esto se dé en un proyecto del tipo Crystal Clear. La programación natural involucra diseñar. Experto en Negocios: Es el experto que indica cómo va el negocio, qué estrategias o políticas deben arreglarse, qué tiende a variar pronto, seguido o nunca. Esta persona responderá variadas preguntas a los desarrolladores acerca del corazón del sistema. Provee información diferente de la que entrega el Usuario Experto, de hecho, en algunos casos puede suceder que el usuario experto, es también el experto en negocios. En muchas situaciones se ha visto que el sponsor, el líder de diseño o el usuario experto actúen como expertos en negocios. Algunas veces, una persona externa es traída para desempeñar esta tarea. Coordinador: El coordinador es, probablemente, una ocupación parcial de alguno de los miembros del equipo; los proyectos con cuatro a ocho personas tienen una persona dedicada a manejar el proyecto. Puede darse que una persona maneje varios proyectos y juegue el papel de coordinador en cada uno de ellos. Alternativamente, el sponsor o el líder de diseño asumen este rol, o incluso otras personas se turnan para éste. Tester: encargado de las pruebas Escritor: encargado de redactar la documentación (manuales de usuario, de entrenamiento y ayuda)

• •

Caso de Estudio
En el presente caso de estudio, se explicará de manera clara y fácil de entender cómo se implementa la metodología en un determinado proyecto. Esperando conocer sobre el desarrollo ágil como parte de una actividad de innovación del proceso corporativo, se decidió probar Crystal Clear en el desarrollo de un proyecto denominado “Indexación Automática de Orígenes de Datos (crawl o auto-indexing)”. El sistema tiene como propósito permitir la auto-indexación de la información almacenada en diversos documentos (el sistema queda limitado a la indexación de archivos de Microsoft Word 97 – 2003, con extensión DOC; archivos de texto, con extensión TXT; archivos de Microsoft PowerPoint 97 – 2003, con extensión PPT; archivos de Microsoft Excel 97 – 2003, con extensión XLS y archivos PDF). El proceso de indexación de toda la información se iniciará automáticamente, mediante un Scheduler, luego, la misma podrá ser accedida desde una aplicación de búsqueda. El proceso de indexación comprende una serie de pasos internos, que implican la implementación de un Tokenizer para extraer el texto y poder procesarlo. El siguiente paso consiste en la eliminación de las Stop Words y luego, la generalización de las palabras mediante Stemming. Esto proporcionará al usuario búsquedas más intuitivas y con resultados en pocos segundos. En términos generales, la meta de este sistema es la automatización del proceso de indexación de archivos. Concretamente, esto incluye: • • • • Iniciación automática del proceso de indexación Agilización de la búsqueda de los archivos necesarios de manera rápida e intuitiva Disminución de tiempo y carga de trabajo de los empleados Respuesta rápida a los clientes

El principal beneficio que se obtiene con la implementación de este sistema es la notable reducción del tiempo de búsqueda de archivos debido a la automatización del proceso y la implementación de herramientas de software diseñadas para tal fin. La prioridad principal del equipo del proyecto era completar el prototipo antes de que concluya el año 2009. Lo ideal sería tener un producto de calidad para mostrar inmediatamente a las empresas interesadas en él. De hecho, se terminó con una demostración de alta calidad que puede ser transformado en producto en un tiempo razonablemente corto, y fácilmente integrable con otros productos ya desarrollados. Crystal Clear es una metodología ágil, y como tal tiene como objetivo reducir el riesgo de una mala construcción, y ofrecer un valor tan pronto como sea posible. Crystal Clear fue seleccionado porque hace hincapié en:

Eficiencia. Crystal Clear tiene como objetivo minimizar los residuos, centrándose al mismo tiempo en las características importantes del equipo. Habitabilidad. Crystal Clear está diseñado para ser cómodo de usar, de modo que los equipos no sientan la necesidad de evitar que los sigan. Seguridad. La metodología tiene como objetivo aumentar la probabilidad de éxito de la entrega.

Se decidió desarrollar este proyecto con Crystal Clear, porque era pequeño y no crítico (que es el tipo de proyecto para la que fue diseñada la metodología), y porque el equipo era reducido (estaba compuesto por cinco miembros). El cliente en este caso, es la empresa misma, ya que este proyecto es una prueba piloto para el uso de esta metodología.

Introducción
Básicamente, más allá de brindar la posibilidad de indexación automática de las imágenes de los documentos escaneados mediante nuestro mediante OCR, el sistema desea ofrecer la funcionalidad de auto indexación de la información residente en diversos medios (discos de red, bases de datos, etc.). De esta manera un "robot de indexación" iniciará, mediante un proceso programado, la indexación de toda la información existente en los medios especificados. Luego la misma será accesible desde una aplicación de consulta. No se partió de ningún prototipo ni diseño previo. El sistema era una herramienta completamente nueva para el equipo de desarrollo.

Cronología del Proyecto
La fecha de inicio del proyecto fue el 15/06/2009 y se planificó, en un principio, una duración de 3 a 4 meses como máximo. Los miembros del equipo de desarrollo para el proyecto estaba compuesto por las siguientes personas: • • • • • Norma, líder de proyecto Omar, programador experto en Java Carlos, programador junior en Java Víctor, programador junior en Java Melisa, analista funcional

Roles
Para dar comienzo al inicio del proyecto se establecieron los requisitos iniciales del mismo, el enfoque de desarrollo, una primera estructura de división del trabajo, y una estimación para el trabajo. La estimación fue de

120 días de esfuerzo. La asignación inicial de las funciones se muestra a continuación:

Nombre Norma Omar Carlos Víctor Melisa

Roles Sponsor, Experta en Negocios Líder de Diseño, Coordinador Usuario Experto Diseñador-Programador, Tester Coordinadora, Escritora, Tester

A pesar de que se tenían los requisitos básicos del sistema, estaba claro que había cuestiones que teníamos que resolver antes de poder iniciar el desarrollo iterativo. Así que se tomó la idea de una "fase de exploración" de XP. Esta fue la primera fase del proyecto.

Exploración
La fase de exploración fue de dos semanas, en el que Omar y Carlos capturaron los requisitos más detallados, investigaron las principales cuestiones técnicas, y firmaron la estimación para el proyecto. Omar y Carlos trabajaron juntos para completar los detalles, Carlos (como usuario) fue la principal fuente de los requisitos. Capturaron a los requisitos de uso en una pizarra, y mediante el dibujo de las pantallas se fueron realizando los primeros diseños.

Las impresiones fueron numeradas y mantenidas juntas en una carpeta. A partir de los requisitos identificados, Melisa comenzó un documento de requisitos.

Después de algunas investigaciones, se decidió que la aplicación fuera desarrollada bajo el lenguaje de programación Java (J2EE), y complementada con la implementación de una API para recuperación de información, denominada Lucene. Apache Lucene es una librería de software libre, una herramienta de desarrollo, no es una aplicación de búsqueda.

Nueva Planificación
Seleccione el tipo de planificación Diaria Detalle de Planificación Nombre Directorio Raíz Semanal Tipo de Archivo Día [Lun, Mar, … ] Mensual Intervalo [MM] Seleccione una opcion Hora [HH:MM] Frecuencia[MM] Guardar Examinar

Planificaciones Nº Nombre Directorio Raíz Tipo de Archivo Tipo de Planificación Hora Intervalo

Modificar

Eliminar

Salir

Reunión de Planeación
Se realizo una reunión de planificación usando la técnica de planificación proyectos sugerido en CC. Los miembros del equipo se sientan alrededor una mesa y se distribuyen tarjetas de tarea. Cada tarjeta de tarea tenía título, una breve descripción, el nombre de la persona, y una estimación días-hombre. de de un en

Distribuimos las tarjetas de tareas sobre la mesa y se acordó un orden para cada una, de manera que se maximice las posibilidades de alcanzar los objetivos del proyecto. A continuación se dio a cada tarjeta una etiqueta (en la parte inferior de la tarjeta) para que podamos reconstruir el orden. Después de la reunión, las tareas se han copiado en Microsoft Project, a fin de tener claramente la planificación para el proyecto. Indexación Automática de Origenes de Datos Fase de Exploración Determinación de los Requisitos Esbozo de los primeros diseños Armado de carpeta para anotaciones Generación de la primera ERS Reunión de Planeación Elaboración del diagrama de Gantt Confección de tarjetas de tareas 100 días 10 días 2 días 3 días 2 días 3 días 3 días 1 día 1 día 15/06/2 009 15/06/20 09 15/06/20 09 17/06/20 09 22/06/20 09 24/06/20 09 29/06/20 09 29/06/20 09 30/06/20 09 30/10/2 009 26/06/20 09 16/06/20 09 19/06/20 09 23/06/20 09 26/06/20 09 01/07/20 09 29/06/20 09 30/06/20 09

Estimación de la duración del proyecto Primer Incremento: Esqueleto Caminante Reunión de Visión y Reflexión Determinación de las herramientas a utilizar Generación del primer Release Segundo Incremento: Tratamiento de Docum. Reunión de Visión y Reflexión Generación del segundo Release Tercer Incremento: Multihilo Reunión de Visión y Reflexión Redacción de los manuales Generación del tercer Release Cuarto Incremento: Búsqueda Reunión de Visión y Reflexión Elaboración de la versión final de los manuales Generación del último Release

1 día 18 días 1 día 2 días 15 días 16 días 1 día 15 días 19 días 1 día 3 días 15 días 34 días 1 día 3 días 30 días

01/07/20 09 02/07/20 09 02/07/20 09 03/07/20 09 07/07/20 09 28/07/20 09 28/07/20 09 29/07/20 09 19/08/20 09 19/08/20 09 20/08/20 09 25/08/20 09 15/09/20 09 15/09/20 09 16/09/20 09 21/09/20 09

01/07/20 09 27/07/20 09 02/07/20 09 06/07/20 09 27/07/20 09 18/08/20 09 28/07/20 09 18/08/20 09 14/09/20 09 19/08/20 09 24/08/20 09 14/09/20 09 30/10/20 09 15/09/20 09 18/09/20 09 30/10/20 09

Con la suma de los totales de las tarjetas de trabajo, llegamos a una estimación mejorada para el resto del proyecto: 100 días.

Incremento 1: Esqueleto Caminante
El propósito del primer incremento fue crear una aplicación que fuera el esqueleto del sistema, incorporando las principales características arquitectónicas y algunas funciones básicas. Lo primero que se hizo fue seleccionar y configurar nuestras herramientas. Las herramientas fueron elegidas por los miembros del equipo, sobre todo Omar, sobre la base de su experiencia en otros proyectos. Las herramientas fueron las siguientes: • • Herramienta de diseño. Enterprise Architect 7.0 fue seleccionado para el diseño de los diagramas UML. Herramientas de programación (se eligió como lenguaje de programación a Java) o IDE Eclipse

o o

Hibernate Framework como herramienta ORM Apache Lucene como herramienta para la recuperación de información Log4j como herramienta para el seguimiento de trazas Apache POI para el procesamiento de archivos de Office

o o • •

Herramienta de pruebas de unidad. Hemos seleccionado JUnit. Herramienta de control de versiones. Se utilizó Subversion

Una vez que las herramientas se han seleccionado y configurado, Omar comenzó a crear la arquitectura del software y a debatir los problemas de diseño con Norma utilizando una pizarra. Durante incremento de 1, Víctor comenzó a escribir el código de Java para el proyecto, contando siempre con la ayuda de Omar. El equipo continuó para refinar los requisitos, con Carlos y Omar trabajando juntos para producir borradores de pantalla actualizada. Al final del incremento 1, el equipo había tenido éxito en crear el esqueleto caminante. Se logró terminar y entregar al usuario un Scheduler que consiste en un administrador de planificaciones que permitirá determinar el día, la hora y la frecuencia para iniciar el proceso de auto-indexación de documentos. De esta manera, el usuario podrá ingresar, consultar, modificar o eliminar una planificación para auto indexar archivos. Además, se generará un módulo de indexación básico que consiste en la capturar los nombres de archivos DOC y TXT para realizar búsquedas básicas por nombre.

Hacia el final del incremento, Norma le dio al equipo su declaración de misión. Este es uno de los productos de los trabajos exigidos por Crystal

Clear. Este producto del trabajo sólo se pide al sponsor. También se celebró un taller de reflexión y visión. La reunión se realizó de manera ordenada, y se contó con la presencia de la totalidad del equipo de desarrollo. Durante la misma, se trataron algunas cuestiones sobre el primer incremento realizado, identificando los objetivos alcanzados hasta el momento, y se planteó la visión para el siguiente incremento. Todos los puntos tratados en la reunión se registraron en una pizarra, que se encontrará ubicada dentro de la sala de trabajo, de manera que los miembros del equipo puedan consultar contantemente y tener siempre presente los objetivos a cumplir. Al final del incremento 1, el equipo realizó un taller de reflexión. El objetivo principal de ésta reunión era identificar los aspectos del proceso de trabajo, de manera que se pudiera determinar qué se necesitaba cambiar y qué puntos se mantendrían. Los puntos principales identificados fueron: • Conocimiento sobre la metodología Crystal Clear. El equipo no había sido entrenado en el uso de la metodología, ya que nunca tuvo la oportunidad de aplicarlo. El material de formación que se empleó fue el libro de CC llamado “Crystal Clear A Human-Powered Methodology for Small Teams”, por lo que se propuso y se acordó que cada miembro del equipo debe realizar una lectura del mismo. Toma de decisiones. Omar, como el líder de diseño y miembro con más experiencia en desarrollo de sistemas en Java, quedó a cargo de la toma de las principales decisiones técnicas. Aspectos a conservar. El equipo encontró mucho acerca de la metodología que se quería conservar. En particular, los miembros del equipo estaban trabajando bien juntos. Varios de los miembros del equipo antes habían trabajado juntos en otros proyectos, por lo que les resultaba más fácil trabajar juntos en este proyecto.

Incremento 2: Tratamiento de Documentos
El objetivo del segundo incremento era que el sistema pudiera efectuar el tratamiento del texto una vez que se indexaron los archivos. Esto comprende, la tokenización, eliminación de los signos de puntuación, conversión a minúsculas, eliminación de stop words (palabras irrelevantes) y stemming (generalización), tanto del título como del contenido de cada uno de los archivos. Este tratamiento, permitirá realizar búsquedas más intuitivas y sencillas, brindando resultados más precisos y significativos al usuario. Las funcionalidades que se obtengan del presente incremento no serán captadas por el usuario final, ya que las mismas se realizan mediante

procesos internos del sistema. Por lo tanto el usuario final no verá los resultados hasta el incremento 4, cuando se encuentre concluida la búsqueda. Sin embargo, estas funcionalidades si podrán ser verificadas por los miembros desarrolladores del equipo y serán evaluados los resultados. El incremento 2 comenzó con una reunión de planificación en la que la programación del proyecto fue reconstruido sobre la base de la situación actual y se planificaron las cuestiones a ser tratadas en el incremento 3. Al final del incremento, se contaba con un sistema capaz de indexar y procesar el texto de cada uno de los archivos indexados, lo cual sería empleado en el siguiente incremento. Al igual que en el incremento 1, se realizó una reunión de visión y un taller de reflexión. Los aspectos tratados fueron registrados en la pizarra, la cual siempre debe estar actualizada y a la vista de todos los miembros del equipo.

Incremento 3: Multihilo
En este incremento se buscó agregar la funcionalidad multihilo a la aplicación. Debido a que durante las pruebas efectuadas, el sistema debía realizar tareas de manera concurrente (despliegue de la interfaz, búsquedas, trabajo de planificación, etc.), se decidió luego de la reunión de reflexión, modificar el sistema para dicho fin. De esta manera, el sistema no queda “congelado” cuando realice tareas en paralelo, ya que cada hilo trataría cada tarea de manera independiente. Los problemas se daban concretamente durante las tareas de indexación, momento en el cual hay un pico de uso de CPU y memoria.

Aunque el usuario no tendría noción de los resultados de la indexación hasta el próximo incremento, se mantendrá el módulo generado en el primer incremento para realizar las búsquedas por nombre de archivo. Durante este incremento se comenzó con un esbozo de los manuales de usuario y de instalación y configuración a cargo de Melisa.

Además de este tema, en la reunión de reflexión se marcaron algunas observaciones en la pizarra y se determinaron las falencias y fortalezas detectadas.

Incremento 4: Búsqueda
Durante el incremento final, se agregó la funcionalidad de búsqueda para el contenido de los archivos indexados. Se trató de hacerla intuitiva, similar a la que implementa Google en su buscador Web, agregando soporte para comodines (“?”, “*”) y conectores lógicos (AND, OR). De esta manera se logra una búsqueda fácil y familiar para el usuario. El módulo de búsqueda también corre de manera concurrente en un hilo independiente del resto. Se finalizó la redacción de los manuales de usuario y de instalación y configuración. Y se realizaron las integraciones finales del código.

Se corrieron las pruebas unitarias definitivas y las pruebas generales. Llevamos a cabo un taller de reflexión final. Este se convirtió en una discusión general acerca de cómo fue la metodología. Las opiniones de los miembros del equipo fueron en general muy positivas.

Conclusiones
Esta sección presenta nuestra evaluación de Crystal Clear. Se evalúa la metodología en contra de las afirmaciones que se hacen para ella. Asimismo, presentamos una serie de cuestiones en las que es necesario tener cuidado en el uso de la metodología.

Evaluación de Crystal Clear
Las afirmaciones hechas por Crystal Clear es que es eficiente, habitable y seguro. Sobre la base de nuestro proyecto piloto, se apoyan estas afirmaciones: Eficiencia: La metodología ayudó a mantener el desarrollo centrado, y a la reducción de residuos. De residuos, en este contexto, significa cualquier cosa que no contribuye al producto final. Se consiguió una alta productividad, a tal punto de poder reducir el tiempo estimado en un principio para el sistema, y concluir satisfactoriamente con el cronograma planificado, en tiempo y en forma.

Habitabilidad: Todos los miembros del equipo estarían felices de usar esta metodología de nuevo. Varios Se recibieron comentarios positivos por parte del equipo, incluyendo: • • • Carlos (usuario experto). "En general, la participación fue una experiencia agradable, y uno que me encantaría repetir." Omar (Líder de Diseñado). "Por lo general se sentía muy centrado y con energía.... Me sentí en general, en el control". Norma (Sponsor). "Las comunicaciones son excelentes... El equipo ha trabajado bien juntos... El software fue entregado en una condición de trabajo satisfactoria".

Seguridad: Una metodología segura es la que aumenta la probabilidad de éxito del proyecto. El proyecto piloto tuvo éxito, ya que creó un producto que logro la satisfacción tanto del sponsor como del usuario experto. Más allá de eso, varios aspectos del proyecto pueden demostrar la seguridad: los planes siempre se plantearon de acuerdo a las necesidades de cada momento, los temas difíciles se han resuelto de manera oportuna, y el equipo siempre se centró en las características más importantes.

Bibliografía y Sitios Web Recomendados
• • Alistair Cockburn (2004). Crystal Clear A Human-Powered Methodology for Small Teams. http://alistair.cockburn.us/ Agile Manifesto http://www.agilemanifesto.org