Universidad Tcnica Federico Santa Mara Departamento de Informtica Ingeniera de Software Avanzada

Metaphor, base de la comunicacin en programacin extrema

Integrantes: Csar Pasache Ahumada - 9804523-6 Fernando Prez Guzmn 9973052-8 Entrega: 22 de junio de 2004 Profesor: Marcello Visconti

1.- Introduccin En la actualidad, la tendencia en equipos de desarrollo, se aleja cada vez ms de la estructuracin y el formalismo, acercndose a todo aquello que permita potenciar la creatividad y la improvisacin. Este tipo de tcnicas ha cado en la categora de los llamados Mtodos giles, uno de cuyos exponentes, la Programacin Extrema, es tratado en este trabajo. Ms especficamente, nos abocamos a la nocin de comunicacin en los equipos de desarrollo. Es aqu donde se encasilla la tcnica llamada Metforas (Metaphor). Para comenzar, se presenta una visin clsica de lo que este concepto representa (lo que se puede sintetizar en poner a una cosa, el nombre de otra). Se establece que ha sucedido este ltimo tiempo en los equipos de desarrollo de software y los Mtodos giles, para posteriormente, hacer una explicacin ms detallada del concepto de Metforas y su utilidad. Se expone un ejemplo, que se ha convertido en un icono de dicha tcnica de comunicacin: El Juego de Ajedrez. Esta explicacin, se hallar que en cierta forma es recursiva, pues explica la Programacin Extrema, usando una de sus propias herramientas. Finalmente, se concluir en base a lo que se present y basado en las ideas propias de los autores.

2.- La paradoja de la metfora (Potencialidades y falencias del concepto de metfora, en su visin clsica) La visin clsica de metfora, involucra un cambio de contexto semntico. Cualquier realidad, es claramente descriptible mediante un lenguaje comprensible por los entes involucrados en la transmisin de una idea. La condicin para obtener este resultado reside en que los smbolos del lenguaje, sean reconocibles y signifiquen lo mismo tanto para el orador como para su interlocutor y asimismo, que ambos ubiquen las construcciones lingsticas (frases, oraciones, palabras) en el mismo contexto. Cuando Yo diga perro, espero que mi interlocutor se imagine el gracioso animalito; y cuando diga esta nublado, espero que la otra persona, se imagine un cielo medianamente nublado, esto es, ni una tormenta, ni un da de sol. Alejndose un poco de la forma comn de comunicarse, o quiz acercndose ms que nunca, la nocin de metfora expande la nocin de comprensibilidad alterando el normal contexto de las mencionadas construcciones lingsticas. De esta forma, diametralmente opuesta a la expresada anteriormente, cuando diga Si .. me gusto mucho, puedo estar significando que realmente nos pareci un asco. Este caso es en particular decidor, pues complementa el lenguaje verbal, con el lenguaje corporal y fontico: Solo se interpretar correctamente, si se invoca la frase precedente de la manera correcta, esto es, con irona. De esta forma, contrariamente a lo que puede parecer a primera vista, la semntica involucrada crece de forma notable. No necesito expandirme horas en eptetos de cuan grotesco me pareci lo consultado, me basta con decir, Si .. claro ... me gusto mucho, y nuestro interlocutor sabr inmediatamente que nos desagrado tanto que ni siquiera queremos referirnos a ello. Con este burdo ejemplo, contextualizamos la gran potencialidad de la metfora, que es expandir la semntica. Pero, como todo en esta vida, un derecho es correlativo a una obligacin. Y as, una potencialidad, generalmente, acarrea una falencia o taln de Aquiles. Cuando digo Si .. claro ... me gusto mucho, corro el gran riesgo que mi interlocutor crea que realmente fue de mi agrado. As nuestra gran semntica no solamente queda reducida, sino que anulada, por una mala comprensin. Y es de esta manera que se comprende la condicin (la falencia mencionada) para que la metfora cumpla su cometido: El contexto involucrado dentro de la metfora, tambin debe ser comprendido por el interlocutor. De esta forma, aunque ambos interlocutores entiendan los smbolos atmicos (las palabras que constituyen la frase de ejemplo), se necesitar que, tambin, ambos entiendan que estas estn en otro contexto. Si se da esto, las posibilidades reales de comunicacin crecen notablemente en un equipo, pues se aprovecharn las dos grandes posibilidades de la metfora: Hacer manifiesta una relacin entre la semntica de las acciones involucradas (mi dentista es un carnicero) Potenciar el significado de cierto smbolo del lenguaje (una palabra, una frase, etc.), analogndolo a otro smbolo en otro dominio (frgil como un avecilla recin nacida)

As, se entiende el porque esto es una paradoja: Puedo explicar mucho mejor algo, si lo expreso en palabras de otro dominio. Mi interlocutor sabr que tan malo es mi dentista, si digo que el es un carnicero, puesto que ambos saben que tan sanguinario puede ser el trabajo de dicha persona.

Y as, nace la ltima condicin necesaria para la correcta aplicacin de una metfora: Que ambos interlocutores tengan la imagen mental (la nocin) de que es un carnicero. Cumplindose esto, mi dentista perder un cliente potencial. Y es as, luego de toda la explicacin precedente que nos es lcito afirmar que tan extraa forma de comunicacin, que a la larga es bastante eficaz, que permite trasladar una idea de un dominio a otro, resulta beneficiosa para trabajo en equipo. Y en especial, de equipos que desarrollan software en la modalidad de programacin extrema: Cuando mi cliente trabaja en el mbito de la contabilidad, es preferible emplear metforas, para asegurar una suficiente y rpida comprensin de la idea que deseo transmitir. Y as, ni l, ni yo, nos desgastaremos en largas y tediosas conversaciones llenas de tecnicismos y formalidades.

3.- Porqu los proyectos de Software fallan? Actualmente dentro de un proyecto de desarrollo de software, existen algunas graves fallas que al buscar su causa, radican normalmente en una deficiente comunicacin entre el equipo de desarrollo con el resto del mundo. Cada falla del proyecto tienen inevitablemente un gasto de dinero, tiempo y recursos, los cuales son limitados. Sabiendo esto, los proyectos siguen operando de manera catica y con ello siguen teniendo fallas, porqu?. El problema principal dentro de estos errores, es la falta de comunicacin con el cliente, ya que si no se tiene una comunicacin constante con el cliente, se puede llegar a perder el foco del proyecto, y llegar a una solucin que no es la deseada. El otro problema fuerte que existe, es que algunas personas del equipo desarrollador pierde la visin final del producto, la visin que tiene la empresa y sus compaeros, lo que reduce el performance del equipo. Entre algunos datos que se pueden obtener con respecto a lo importante que puede ser la comunicacin, El proyecto de climatizacin de Marte , exhibi una inadecuada comunicacin entre los elementos del proyecto durante las fases de desarrollo y operacin. Esta falla fue identificada como la causa del fracaso de la misin Reporte p21 de gestin de proyectos en la NASA Dentro de un proyecto, existen varias instancias de comunicacin, entre las cuales se encuentran las planeadas (o calendarizadas) y las realizadas a base de eventos (Comunicacin No-planeada). Por otro lado, esta se puede dar mediante diferentes mecanismos, ya sea una comunicacin Sincrnica (La fuente y el receptor se encuentran disponibles al mismo momento) y de forma asincrnica (en donde existe un tiempo de respuesta entre cada parte).

Ilustracin 1 - Formas de comunicacin Alguna de las actividades en que se calendariza la comunicacin son las revisiones del proyecto, que entra ellas existe una comunicacin con el cliente, el cual enfoca todo su esfuerzo en hacer valer los requerimientos. Entre las instancias de comunicacin basadas en eventos, se pueden ver las a peticin de un integrante del equipo de desarrollo para clarificar conceptos dentro de algn proceso del Software. Alguno de los tipicos sistemas de comunicacin sincrnicas, son aquellas conversaciones de pasillo (informales), en las cuales se conversa de igual a igual situaciones especificas del software. Por otro lado, algunos ejemplos de comunicacin asincrnica son el E-mail, los Newsgroup, etc. Obviamente, todos estos mtodos de comunicacin no pueden ser factibles

4.- Mtodos giles Ser gil denota la capacidad de ser gil, de estar preparado para el cambio, ser activo, tener destreza sobre el movimiento; El desarrollo de software, est intentando ofrecer nuevas soluciones al mercado, tratando de hacer ms fciles y ms rpidos todos los procesos involucrados en el desarrollo de software. Estos nuevos mtodos estn especialmente diseados para enfrentarse al rpido crecimiento que posee la industria de software en Internet como tambin en el emergente mercado de las aplicaciones mviles. Entre las prcticas giles, los puntos que se respetan son: La individualizacin e interaccin sobre los procesos y herramientas. Trabajar el Software en base a una buena documentacin. La colaboracin del cliente sobre todo el proceso de desarrollo. Respuesta a los cambios de plan.

Las tcnicas giles enfatizan en que las relaciones humanas dentro de un proyecto, son esenciales, y no deben dejarse de lado. Uno de los principales objetivos de estos mtodos, es ir probando continuamente el software, realizando entregas de forma muy peridica. Los desarrolladores deben mantener el cdigo simple, directo y tcnicamente avanzado (implementando buenos algoritmos). La colaboracin que debe existir entre el equipo y el cliente, es un punto muy importante para no perder el rumbo del proyecto. El equipo de desarrollo, ya sean los desarrolladores como los representantes del cliente, deben permanecer siempre bien informados acerca del proyecto, teniendo siempre en cuenta la posibilidad de realizar cambios drsticos al producto. Estos nuevos mtodos han ido tomando gran importancia dentro de las empresas de desarrollo de software, y entre ellos existen: La Programacin Extrema (XP) Scrum Desarrollo dirigido por las especificaciones (Feature Driven Development - FDD) Mtodo de desarrollo dinamico de sistemas (Dynamic System Development Methods DSDM) Desarrollo de software adaptativo (Adaptive Development Software - ASD) Desarrollo de software de cdigo abierto (Open source software development OSS) Modelacin gil Programacin Pragmtica 4.1 .- Programacin Extrema Programacin extrema es un miembro de una metodologa de desarrollo de software denominada mtodos giles, los que buscan un mtodo ptimo y ms realista de hacer frente a los retos del desarrollo de software, contra mtodos de desarrollos tradicionales. Es una aproximacin disciplinada al desarrollo de software, pero no rgida; es flexible. Este mtodo se ha desarrollado desde hace ocho aos, y actualmente se ha podido apreciar el efecto del uso de estos mtodos en diferentes tipos de industrias en la red (Internet). La programacin extrema consta de 5 fases: la exploracin, el planeamiento, las iteraciones de entregas, produccin, mantenimiento y por ltimo la fase de muerte.

La fase de exploracin, es cuando el cliente entrega sus requerimientos, describe las caracteristicas que quiere en el producto. En esta misma etapa, el equipo se familiariza con las herramientas a usar, la plataforma y la arquitectura que van utilizar para el producto. En la fase de planeamiento, se seleccionan las prioridades y el orden a seguir para completar los requerimientos. La fase de iteraciones, es en donde los desarrolladores deben ir entregando peridicamente pequeos release. Existen varias semanas de desarrollo para entregar el primer release, y este debe presentar la arquitectura de todo el sistema. La fase de produccin, requiere de tiempo extra para realizar las pruebas correspondientes. En esta etapa es en donde se prueba el performance del producto. La fase de mantenimiento, es en donde el equipo de desarrollo provee al cliente de tareas de soporte. Y la fase de muerte, es cuando el cliente ya no tiene ms peticiones sobre el producto. Es en esta fase en donde la documentacin se completa, y no se producen ms cambios ni al diseo ni al cdigo del producto. La programacin extrema consta de doce prcticas esenciales, las cuales son: El proceso de planeacin. (Planning Game) El proceso de planeacin permite al cliente definir las metas deseadas para el proyecto, y usa estimaciones de costos estimadas por los programadores, con ello se puede seleccionar que es lo que se necesita hacer y cuando. El efecto del proceso de planeacin es hacer fcil el xito del proyecto. Pequeas entregas. (Small Releases) El equipo de programacin realiza entregas de simples sistemas, los cuales son actualizados muy frecuentemente, en ciclos cortos de produccin. Metforas. (Metaphor) Se definen nombres y descripciones comunes para el sistema, de manera tal que se tenga una gua de desarrollo y de comunicacin.

Diseo Simple. (Simple Design) Un programa en programacin extrema debe ser lo ms simple, tal que cumpla con todos los requerimientos solicitados. Para ello se requiere asegurar un buen diseo. Pruebas. (Testing) El equipo debe enfocarse en la validacin del sistema en todo el tiempo. Los programadores desarrollan el software escribiendo primero las pruebas, con ello se asegura que este cumpla con todos los requerimientos. Refabricacin. (Refactoring) El equipo mejora el diseo del sistema durante todo el desarrollo. Esto es realizado manteniendo el Software limpio, o sea, sin duplicaciones, con alta comunicacin, simple, y casi completo. Programacin de a pares. (Pair Programing) Los programadores de programacin extrema escriben su codigo en pares, dos programadores trabajan juntos durante toda la produccin. Ha sido probado por varios experimentos que este tipo de programacin desarrolla mejor software que los programadores individuales Propiedad colectiva. (Colective Ownership) Todo el cdigo pertenece a todos los programadores. Con este mtodo, cuando se requiere un cambio, cualquier programador puede realizarlo sin mayor espera. Integracin continua. (Continuous Integration) Todas las partes del sistema, son continuamente integradas. Esto mantiene a todos los programadores trabajando por una misma meta, y habilita un muy rpido progreso. Por otro lado, tambin asegura que la integracin final estar correcta. Semanas de 40 horas. (40th hours week) Un programador cansado comete ms errores que uno que esta descansado. Con esta medida, se mantiene a los programadores fuera del excesivo sobretiempo. Cliente en el sitio (On-Site Customer) Mantener al cliente como parte del equipo de trabajo, mantiene al cliente informado acerca del avance del proyecto y por otro lado, mantiene a los desarrolladores sin dudas sobre el sistema. Cdigo estndar. (Coding Standard) Mantener un estndar en la codificacin, ayuda a eficiencia del trabajo en pares y de la propiedad colectiva.

5.- Aplicacin de la nocin de metfora en proyectos XP Lo siguiente, esta basado en un trabajo de Andr Brissette, Pyxis Technologies, titulado Another attempt with the game metaphor Puesto que Metaphor (o metfora), es utilizado en la programacin extrema, es interesante dar un ejemplo que involucre metforas para explicar la programacin extrema misma. Y como afirma Andr, dar una solucin satisfactoria a los siguientes retos: Explicarlo al equipo de desarrollo Convencer a mi jefe y al cliente Monitorear nuestra agilidad durante el proceso

Y para esto, se utilizar una metfora que se ha vuelto clsica en el mbito de los Mtodos giles y en particular, de la Programacin Extrema: El juego de ajedrez. El autor afirma que la industria de software, es un sub-juego dentro de un juego mayor. El gran juego est en el mbito de los negocios, de crear valores agregados y de maximizar la productividad. Esto es, ser cada da ms eficiente. El sub-juego, es la industria de software. Es un sub-juego, pues es un juego en si mismo (esto es, es un negocio en si mismo), pero es una parte que corre bajo (o en paralelo) al negocio, o gran juego. De esta forma, la industria de software, se convierte en un sostn de los negocios, guiando su quehacer por la misma mxima: Tender a la mxima eficiencia. Esto lo define como es sobre hacer software que direccionen un conjunto de necesidades que ayudarn a crear valor. As, nos adentramos en la metfora del juego. Como una forma de simplificar la explicacin, se asla el juego y sus reglas: As, la industria de desarrollo de software se vislumbra como un ente autnomo, que se rige por sus propios principios. (Claramente, esto no es as, pero con propsitos didcticos, mantendremos dicha aseveracin como cierta con el propsito de mantener en perspectiva y nfasis. En palabras del autor proyecto tras proyecto, equipo tras equipo, el juego debe ser el mismo) Otro punto central en la metfora del juego, es que las reglas pueden cambiar solo si todos los participantes estn de acuerdo. As, la idea es que cuando se cambian las reglas, solo se cambia la forma de llegar a la meta: en trminos concretos, los objetivos y metas tienden a ser inmutables, cambiando solo la forma de llegar a ellos. Esta es una caracterstica que manifiesta la flexibilidad de la tcnica de comunicacin. Nuestro juego, esto es, nuestro negocio (o sub-negocio, si as se le quiere ver), viene dado por 4 componentes: Ideas, extradas del pensamiento empresarial y puestas de modo que alcancen el estado de aportar valor al negocio. Estados, iniciales, intermedios y finales por los que pasan las ideas, hasta llegar al punto en que aportan valor al negocio. Movidas, acciones tomadas por los individuos para llevar las ideas desde estados iniciales a los finales.

abrissette@pyxis-tech.com

Reglas, o restricciones establecidas al comienzo del juego y que deben ser mantenidas para verificar coherencias. El resultado de una movida no puede colocar al juego en un estado en el cual una regla resulta ser violada. Como anteriormente habamos referido, el xito de esta tcnica de comunicacin reside en que tanto el locutor, como su interlocutor, tengan una experiencia en comn que compartir Una vez que tenemos esto en mente, podemos pensar en las piezas de un tablero de ajedrez como las mencionadas ideas. As, en un estado inicial, estas se hallan al principio del tablero (en la fase de requerimientos). El objetivo ser entonces, hacer llegar las piezas del tablero a ser un rey, esto es, a llegar al punto en que dichas ideas realmente aportan valor agregado a la empresa. De esta forma, nuestro juego, se traduce en hacer llegar las ideas desde la fase de los requerimientos, hasta la construccin, validacin y posterior uso.

Adems, es claro que aunque el juego tiene ciertas convenciones que ayudan a ganar (conocimiento adquirido tras mucho de tiempo de juego), ser la lgica del negocio en cuestin, quien dictar la ltima palabra en cuanto a decisiones de desarrollo. Esto es, se valora el conocimiento, pero asimismo (y quiz ms) un buen feeling. Una vez que es seguro que todos comparten una idea del juego como la anteriormente presentada (una idea bastante simple, por lo dems), podemos empezar a cosechar un sistema de intercambios de ideas y conceptos entre distintos dominios. Por muy tcnicos que sean, la idea comn compartida, ser comprendida de la misma forma y con bastante rapidez. Por todo lo anteriormente expuesto, es fcil observar que esta simple tcnica, se puede ahorrar mucho tiempo. Pero ms an, se hace bastante ms eficiente la comunicacin en un equipo de desarrollo.

10

6.- Beneficios del uso de Metaphor en programacin extrema. Es una cosa bien sabida que la comunicacin en un equipo de trabajo, es el factor esencial. No se gana nada con tener rutilantes estrellas del campo de la informtica, si no son capaces de comunicarse, tanto para compartir ideas, como para aclarar potenciales dudas. Oli Ivarsson, en su paper titulado Extreme programming and Extreme Game Development, seala que: Casi todo el tiempo ocurre un problema inesperado en el proceso de desarrollo, la causa puede ser rastreada a una falla de comunicacin entre la gente del equipo de desarrollo. Cuando trabaja gente que posee conocimientos de ndole diversa en un equipo, es esencial que todos tengan un conocimiento del estado general del proceso, pues de ello depende las funciones a seguir: Si mis compaeros de equipo manejan una semntica distinta a la ma, es esencial que nos podamos entender en un dominio comn, para mantener en perspectiva el proceso a nivel global. Otro punto relevante es que la comunicacin se basa en la terminologa oral. Esto significa un cambio significativo a nivel histrico: La comunicacin va documentacin frente a la comunicacin va conversacin. Segn Oli Esto mejora la confiabilidad y la flexibilidad. Esto es claro, nada resulta ms convincente de la verdadera intencin de una idea, que una conversacin frontal (entre seres bien intencionados): Cualquier duda, se aclara en el momento, y esto, finalmente, redundar en la productividad. Finalmente, el concepto de metfora y comunicacin cercana, est estrechamente ligado a la programacin de a pares, otra base de la programacin extrema. Sin un adecuado nivel de comunicacin, esta forma de programacin, que se ha detectado como positivamente eficaz, no tendra los resultados observados en la prctica. As, podemos sintetizar los beneficios del uso de metforas, como una base formal para un mejoramiento de la comunicacin en equipos de desarrollo, lo que es realmente en una ltima instancia lo que mejora el desempeo de la gente involucrada.

11

7.- Conclusiones De lo visto y expuesto en este informe, podemos denotar los siguientes puntos como esenciales en cuanto a la necesidad y ventajas, en el uso de la tcnica de Metforas. Una Metfora, es una representacin de una semntica en otro dominio. La razn principal del empleo de metforas, es lograr que interlocutores que se ambientan en distintos dominios, logren hallar, con cierta facilidad, un dominio comn que les permita expresar sus ideas en forma rpida y eficaz. Para que una metfora sea eficaz, se deben dar dos condiciones: Que los interlocutores reconozcan correctamente los smbolos del lenguaje Que los interlocutores compartan una experiencia en comn (que ambos sean capaces de rememorar la misma emocin, al escuchar determinada palabra) El uso de metfora, nos puede ayudar a cumplir fines tan esenciales en un proyecto de desarrollo de software, tales como: Explicarlo al equipo de desarrollo Convencer a mi jefe y al cliente Monitorear nuestra agilidad durante el proceso

Una vez asegurado que todo integrante del equipo mantiene la visin comn de lo que se est (o se debiera estar) haciendo, ser fcil proponer nuevas nociones que permitan mejorar procesos de desarrollo. Esto es posible por que al ser la tcnica de Metforas, flexible y confiable, permite implementar cambios con una rapidez y seguridad, mayor que la que se tendra al proponer cambios en un sistema tradicional Metforas, privilegia la comunicacin oral, antes que el formalismo de la documentacin, dando espacio para la creatividad e improvisacin (y el mejoramiento) Como conclusin final, se expone que el uso de la tcnica basada en Metforas permite mejorar en forma ltima la comunicacin en equipos de desarrollo, quiz interdisciplinarios. De esta manera, se constituye en uno de los puntos esenciales a considerar en cualquier desarrollo que pretenda ser rpido, flexible, pero serio.

12

8.- Bibliografa

[1] [2] [3] [4]

Charles Poole y Jan Willem Huisman, Using Extreme Programming in a Maintenance Enviroment, IEEE software, November/December 2001. Andr Brissete, Another attempt with the game metaphor, Pyxis Technologies. Oli Ivarsson, Extreme Programming And extreme game development, 18 de Diciembre de 2003. Agile software development Pekka Abrahamsson, Outi Salo, Jussi Ronkainen & Juhani Warsta Review and Analysis. Pginas Web http://c2.com/cgi/wiki?SystemMetaphor http://ootips.org/xp.html http://www.agilemanifesto.org/ http://www.javaworld.com/javaworld/jw-09-2001/jw-0921-soapbox.html

[5]

13