eXtreme Programming ‘XP’

Metodologías ágiles para desarrollo de sistemas informáticos


Ilham Chmiti
Sergio Merino Martínez
Lisardo Fernández Cordeiro

ETSE   –  2º GII  –  IS
Universidad de Valencia



English version
            
         La hiperactividad siempre ha estado reñida con el trabajo concienzudo, sosegado, de tiempos ajustados a la pauta de lo metódico, garante de éxitos y triunfos simpar con acabados relucientes. O al menos eso nos han vendido.
            Se ha especulado, hasta en las más vehementes barras de bar, la aparente sinrazón de las grandes inversiones en estudios vinculados con la búsqueda de modelos y métodos que establezcan procedimientos, pautas y filosofías con los que optimizar el triunfo, pues no vale cualquiera.
        Pero si Platón observaba con placentera quietud el mundo desde una cueva, con el convencimiento absoluto de llegar a establecer una pauta rigurosa sobre lo esencialmente adecuado a la razón y la verdad, fue Sócrates el que, con desparpajo alborotador, se puso los guantes reglamentarios de faena a la par que creaba conceptos tan fiables como sencillos con los que enervar a los contemporáneos.
            Y en esto anda parte del pastel creativo actual. Sin dar ni quitar razones, es prudente adecuar metodologías atrincheradas en los diseños y vistas conceptuales previas a la inclusión en el barro de la generación de código, para que los hiperactivos y nerviosos picacodes, comiencen sus labores con rigor pero sin dilaciones.
         Adaptar los proyectos a los modelos no siempre es el orden correcto y eso es importante. Son las metodologías las que han de modificarse en función de las dimensiones, objetivos y funcionalidades del proyecto.
            Actualmente, se entiende que el analfabetismo de la especialización extrema, con departamentos absolutamente estancos, no crea más que problemas hacia delante, de futuro, de mantenimiento caro, actualización compleja y, por ende, durabilidad del producto escasa.
            La agilidad, la simplicidad y la cooperación se alzan como alternativas prudentes y capaces para garantizar que el ciclo de vida de un sistema sea abordable económicamente por su estabilidad.

introducción ágil
      Los tiempos que corren, o vuelan según quien los mire, se hacen acompañar de todo aquello que se acoja a unos pocos principios básicos. Este selecto club de escasa paciencia, solo admite apariencias wonderful, mantenimientos baratos si no escasos y desarrollos veloces que pongan en circulación aplicaciones robustas con capacidades camaleónicas.
      No se trata tanto de características como de exigencias reales para no perder el tren de vía única que se nos planta delante. De este modo, el micromundo en el que nos tostamos la piel, enriquecido por la dependencia cada vez mayor de aplicaciones de gestión, control, automatización y ocio, no se conforma con cualquier cosa proveniente del autista del código de turno, ajeno a la contemplación y el análisis de las verdaderas necesidades de los futuros usuarios.
      Por otro lado, los grandes retos oficializados con enormes dosis de ortodoxia jerarquizada en niveles estancos, hacen gala de una ostentación poco adecuada a la demanda de flexibilidad y cambio continuo, por muy rigurosas que suenen las gigantescas montañas de documentación que generan, acompañadas de tickets de representación asombrosamente abultados.
      Es por tanto, la fusión de mundos tan encontrados como los anteriores, el camino adecuado para salvar el pellejo con la dignidad suficiente en momentos de procelosos entredichos y cambios de paradigmas vitales.
      El diseño es esencial ante el reto de emprender aplicaciones software. Se trata de establecer los caminos iniciales y esenciales sobre los que basar un trabajo de codificación sin que resulte inútil. Mantenerlo en lo básico y acompañarlo de mejoras continuas, enriqueciendo las funcionalidades con mimo y método, acercar el diseño a su implementación para correr de la mano, obteniendo los beneficios de la fiabilidad, la flexibilidad, la robustez y la velocidad de desarrollo que tanto reclaman los clientes.
      En los siguientes apartados intentaremos explicar, sucintamente para que el lector no precise de intermedios publicitarios, qué es eXtreme Programming, una de las metodologías de diseño software más ágiles y que mejores resultados aporta al mercado de los especialistas en desarrollo de eso que tanta dependencia genera, la tecnología.

principios básicos
       El principio más básico que debe cumplir toda metodología ágil es la creación de software de una manera lo más estructurada posible y sin salirnos del presupuesto planteado en un principio. Para poder cumplir esto de una manera fácil y segura, se crean una serie de reglas para la creación del código. [1]
       Estas reglas, tal y como se pueden observar en los esquemas 1, 2, 3 y 4, serían las siguientes, las cuales explicaremos a posteriori más detalladamente:
– Planificación 
– Sistema Metafórico (Metaphor)
– Programación en parejas 
– 40 horas por semana 
– Versiones Pequeñas 
– Diseños simples
– Testeos Continuos
– Refactoring
– Propiedad colectiva del código
– Integración continua
– El cliente en su sitio
– Estándares de codificación

       Veámoslo detenidamente:
Planificación
       Para realizar un buen trabajo hay que planificarse bien.
       Por ello debemos empezar tan solo cuando dispongamos de los diagramas necesarios para poder implementarlos, haciendo caso a lo que hay sin añadir ni modificar información. Esto nos ayudara a que nuestros resultados sean acorde con lo que pide el cliente, y no hayamos tenido que hace esfuerzo en vano y trabajo inútil.
Sistema Metafórico (Metaphor)
       Se basa en crear un sistema de nombrado de variables, funciones, etc. Ganando con ello mucha velocidad a la hora de pensar nombres y o de pensar que significa algún nombre ya puesto por otra persona, siendo así entonces se gana mucha limpieza en nuestro código.
Programación en parejas
       La implementación del código se realizara por parejas, de este modo los errores serán mucho menos, ya que otro programador con los mismos conocimientos sobre el sistema está corrigiendo el código en tiempo de escritura. Esto en muy bueno por otra razón muy importante, el descaso de los programadores al no estar sometidos a la presión de fallo vulgares a nivel semántico o sintáctico.
40 horas por semana
       Basándonos en el punto anterior, en concreto, en el descanso del programador. Justamente lo que se quiere es eso, hacer mucho trabajo de una tacada no garantiza la eficiencia del programador, ya que se pueden cometer muchos errores debidos a la fatiga del trabajo constante. Estas 40 horas se podrán dividir de varias manera, y casa cual tendrá su preferencias.
Versiones Pequeñas
       Lo ideal sería que el cliente pudiera explicar de una manera clara y concisa que es lo que necesita, pero esto como bien se sabe habitualmente no pasa, ya que el cliente no posee los conocimientos necesarios para saber de que manera explicarlo para que todo esté claro para la posteriori programación de su proyecto, por ellos se crean estas versiones pequeñas, ¿Qué son? fácil, son simplemente versiones del programa jefe, las cuales iremos enseñando al cliente para que nos de su confirmación y así saber si es lo que él desea, ya que aunque no tenga conocimiento para explicar de una manera entendible a nivel de implementación, si que posee un gran conocimiento sobre su área de trabajo, en la cual nos estamos basando para poder crear este software.
Diseños simples
       El mayor truco para la nitidez del código es crear código muy simple pero efectivo. Esto significa que el algoritmo empleado no sea redundante y aproveche bien los recurso, claramente siendo eficaz, es decir, que el programa haga lo que se espera que haga sin dar ningún error a nivel de datos finales sobretodo.
Testeos Continuos
       No es nada más que eso. Realizar test de una manera progresiva conforme vamos implementando código, una manera eficaz de aplicar esto es con el uso de las ya nombradas versiones pequeñas, haciendo las pruebas necesarias sobre ellas antes de incluirlas en el programa jefe o final.
Refactoring
       Igual que siempre nuestro objetivo es crear código lo más simple posible. Lo principalmente evitable sería el código redundante o repetido, ya que ensucia nuestro código de una manera inimaginable.
Propiedad colectiva del código
       Es una manera de crear código más eficazmente, ya que todo el código creando por el equipo es de también de cada miembro de ese grupo, pudiendo hacer las modificaciones y mejoras que se crean necesarios sin tener que pedir permiso de ninguna clase.
Integración continua
       Siguiendo con nuestro objetivo de un código claro, si sabemos que debemos introducir cambios que favorecen dicha característica, debemos integrarla cuanto antes y no esperar a que se nos acumulen los cambios.
El cliente en su sitio
       Una de las principales características del XP es la comunicación, por lo tanto la comunicación con el cliente haciendo que forme parte del proyecto es una manera que soluciona o al menos se facilita la compresión de las funcionalidad que en ciertos casos suele ser la etapa más difícil , más cara y más lenta del desarrollo del proyecto.
Estándares de codificación
       Todas las anteriores reglas, no son nada si no nos basamos también en los bien conocidos estándares, que facilitan de manera desorbitada la comprensión del código. Eso sin contar la ganancia de eficacia al decidir de antemano el mejor estándar para satisfacer los requerimientos propuestos por el cliente.

mantener… that´s the question
      Uno de los grandes objetivos de la humanidad, además de vivir del cuento, es elaborar software con mantenimiento sencillo y, por ende, de muy bajo coste. Pues si carece de errores ahorramos el mantenimiento depurativo, de modo que se reserva la mejora continua como único coste de mantenimiento.
      Y la verdad es que suena fabuloso.
      Pero para ello se deben establecer protocolos muy ajustados de depuración del software que garanticen la ausencia de errores de código.
      Tal y como se ha visto en el apartado anterior, eXtreme Programming basa gran parte de sus esfuerzo en la orientación del desarrollo a la simplicidad de código y el enganche absoluto a los test continuos de cada bloque o sección en la que se ha dividido el proyecto.
      Es importante que el lector mantenga la atención sobre el papel que juega el diseño en este proceso, pues la exigencia puntual del código generado en cada iteración del desarrollo, debe satisfacer las pautas marcadas por el estado del diseño en cada punto del desarrollo, facilitando su adaptabilidad.
      Mantener el código, desde el punto de vista actual, donde los costes de personal deben ajustarse al máximo posible en un sector tradicionalmente aquejado de mantenimientos de software desamparados por analistas y diseñadores, no puede representar un esfuerzo varias veces superior al propio desarrollo [2].
      La depuración a cargo del cliente de los innumerables problemas –bugs- de las aplicaciones desarrolladas con métodos tradicionales, no hace más que añadir desconfianza sobre la capacidad del equipo de desarrollo o de los diseñadores… o de los dos. Desconfianza que no resuelve nada en un mundo que valida estos comportamientos de forma natural.
      Precisamente por ello, se hace necesario un cambio de modelo de pensamiento por parte del cliente en la exigencia de software. Como el mantenimiento no se puede evitar,  destinemos el coste del mismo a mejorar prestaciones, enriquecer funcionalidades con las demandas de los usuarios, adaptar diseño a las pasajeras y caprichosas modas, y todo lo que represente innovar sobre la plataforma básica desarrollada. Solo de este modo se logrará conservar el coste del mantenimiento en umbrales acotados y proporcionales a las etapas de diseño y desarrollo principal.

refactoring, la ecología en el software
      Si al lector curioso se le planta delante de los ojos de mirar, un concepto tan ambiguo como el diseño incremental [8], se cambiará rápidamente a los ojos de ver, por aquello de no perderse detalle de cómo demonios se aplica al desarrollo de software.
      En el apartado anterior se ha intentado poner de manifiesto los beneficios del desarrollo depurado. Pero no se logra con la mera aplicación sistemática del código a baterías de test, pues es sabido que el coste de modificación por error ante un test o cambios de diseño por parte del cliente, es proporcional al estado de desarrollo en que se encuentra el sistema.
      Precisamente por ello, el código debe llevar un aspecto y una hechura lo más liviana y simple como se sea capaz de lograr a lo largo de todo su proceso evolutivo. Asentaremos, de este modo, un concepto importante dentro de la eXtreme Programming, como es el refactoring -o revisión continua del código-.
      Ceñirse a lo esencial, centrarse en lo importante parece alejarse de la cruel realidad donde lo banal y accesorio empujan fuerte, no se sabe si para tapar lo importante o para no permitir centrarse. En todo caso, mantener un código que haga única y exclusivamente lo que se le pide en cada momento, sin florituras ni extras superguays sin sentido que acaban enguarrando el código, proporciona entornos idóneos de crecimiento, interacción y flexibilidad global, facilitando sobremanera cualquier ajuste, modificación o apaño posterior.
      En este punto, intuirá el lector avispado, que estamos abaratando el mantenimiento del sistema con la sencilla idea de generar código simple. Pero lograr este propósito implica una disciplina de diseño e implementación un tanto arriesgada para el profano.
      El término refactoring conlleva estar dispuesto a generar código simple basado en diseños simple, sometido a baterías de test continuas y compartido con tantas intervenciones ajenas como sea necesario para llegar a la base mínima precisa que conforma cada bloque.
      Pero aún va más allá. Refactoring no acaba cuando la unidad independiente ha concluido con todas sus pruebas superadas. Vuelve a pasar por el mismo proceso conforme va interaccionando con el resto de las unidades de diseño indefinidamente mientras el sistema no se entregue. Preparando, de este modo, un conjunto con alta capacidad de reversibilidad en caso de modificaciones de diseño o funcionalidades no acertadas.
      Como bien dice Jim Highsmith en el libro blanco de  eXtreme Programming [2], refactoring no cambia el comportamiento observable del software, sino que mejora la estructura interna. De hecho, a la hora de añadir nuevas funcionalidades, el primer paso, a menudo, es refactorizar, preparando, de este modo, un entorno lo más simple posible para que las nuevas funcionalidades se puedan integrar fácilmente y con el menor número de errores.

comunicar simplifica la realimentación con coraje
       El extreme Programming se basa en cinco valores fundamentales que son la comunicación, la simplicidad, la retroalimentación o feedback, el coraje y el respeto que fue añadido en la segunda edición de  eXtreme Programming Explained de K. Beck.
       Como todo el mundo sabe, la comunicación ha sido siempre un medio fundamental no solo en la vida de los humanos, pero también de los animales. Una manera para evitar problemas, aunque persisten los de interpretación, por esta razón, la comunicación entre programadores tiene que estar la más simple posible. Esto implica que no basta tener un código eficaz sino sencillo, fácil y rápido a entender.
       La comunicación programador/cliente representa un paso muy importante para llevar a cabo el objetivo visto que el cliente forma parte del equipo de desarrollo y ayuda al programador a la hora de solucionar dudas y especificar requisitos.
       La simplicidad consiste basicamente en alcanzar el objetivo siguiendo el camino más corto y más sencillo, y así se puede desarrollar o modificar la aplicación facilmente cada vez que se necesita.
       En la vida de un proyecto, los cambios son inevitables, y suele ser modificado en cualquier momento, para hacerlo correctamente, se piensa antes de todo a la retroalimentacion. El feedback nos permite implementar la solución correcta teniendo en cuenta una serie de pasos que ayudan a la facilidad y el funcionamiento, por eso si cada vez es más simple el sistema, mas fácil es obtener una buena retroalimentación.
       El miedo es el sentimiento humano más peligroso, porque afecta a las consecuencias de nuestras acciones, al pensamiento y la lógica, y visto que hay muchas modificaciones que necesitan poco o mucho coraje, la única forma de poder solucionar problemas de todo tipo es, necesariamente, tener coraje. La comunicación, la simplicidad y la retroalimentación también se benefician del coraje al obtener información concreta para actuar.
       El respeto tiene también mucha importancia,  si personas del mismo equipo no se respetan, este último estará perdido y no sabrá como especificar los objetivos o/y como alcanzarlos, todos los valores anteriores se basan con el respeto.

conclusión
      Siempre, las palabras de los sabios han servido de inspiración y guía en los albores de cualquier actividad. Así, nada mejor para concluir que las del filósofo y economista alemán Karl Marx

Los filósofos se han limitado a interpretar el mundo de distintos modos; de lo que se trata es de transformarlo.”

y en eso anda esta curiosa metodología ágil, poniendo en práctica, sin dilación, toda idea considerada buena, esquivando la parálisis que supone la excesiva ortodoxia de los modelos bizantinos amparados en el folcklore de diván evolutivo.

bibliografía y/o webferencias

1..eXtreme Programming. José Carlos Cortizo Pérez, Diego Expósito Gil y Miguel Ruiz Leyva
2..Agile Project Management – Advisory Service – White Paper. Jim Highsmith
3..http://www.extremeprogramming.org
4..http://www.extremeprogramming.org/rules.html
5..http://www.agile-process.org/proverbs.html
6..http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html
7..http://c2.com/cgi/wiki?ExtremeProgramming
8..http://www.programacionextrema.org/articulos/designdead.es.html
9..http://xprogramming.com/book/whatisxp
10..http://en.wikipedia.org/wiki/Extreme_programming
11..http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema


esquemas y figuras
1.. Ciclo de evolución del modelo ágil XP

2.. Esquema de los cauces evolutivos de un proyecto


3.. Esquema de los cauces evolutivos en la iteración


 4.. Esquema de los cauces evolutivos en el desarrollo


5.. Otro esquema del modelo de desarrollo de software ágil eXtreme Programming

6.. “Dilbert” on Extreme and Agile Programming por JOEY DEVILLA



 


4 comentarios sobre “eXtreme Programming ‘XP’

  1. Por aquí todos estupendamente y echándoos de menos.
    La verdad es que se trata de un blog donde vuelco los trabajos que realizo en la carrera, con el deseo de que no se pierda tanto trabajo en lo profundo de un disco duro.
    Agradezco tu esfuerzo y cariño.
    un abrazo a toda la familia.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *