Extreme Pro­gra­m­mi­ng: de­sa­rro­llo ágil llevado al extremo

Hoy en día el de­sa­rro­llo ágil de software ya ha dado algunos frutos. Al margen de Scrum y Kanban, cada vez se valora y aplica más el extreme pro­gra­m­mi­ng. ¿Qué tiene este método de de­sa­rro­llo de extremo?

El extreme pro­gra­m­mi­ng (XP), pro­gra­ma­ción extrema en ca­s­te­llano, se considera, y de ahí el nombre de extremo, como la apli­ca­ción más radical del de­sa­rro­llo ágil de software. Dicho de otra manera: es probable que no haya ningún método, y mucho menos una forma tra­di­cio­nal de pro­gra­ma­ción, más ágil que el XP. En este contexto, el extreme pro­gra­m­mi­ng se di­fe­re­n­cia co­n­cre­ta­me­n­te del de­sa­rro­llo en cascada, por ejemplo, que, según los de­sa­rro­lla­do­res de XP, implica múltiples problemas. A mediados de los años 90, los de­sa­rro­lla­do­res Kent Beck, Ward Cu­n­ni­n­gham y Ron Jeffries de­ci­die­ron darle un giro al método de trabajo tra­di­cio­nal e iniciar un nuevo camino.

Por norma general, el extreme pro­gra­m­mi­ng está orientado a las ne­ce­si­da­des del cliente. Aunque esto parece obvio, el de­sa­rro­llo de software clásico solo puede atender a los deseos de los clientes de manera limitada, lo que se vuelve pa­r­ti­cu­la­r­me­n­te co­m­pli­ca­do si estos re­qui­si­tos van cambiando co­n­ti­nua­me­n­te. Además, XP trata de fomentar la crea­ti­vi­dad de los de­sa­rro­lla­do­res y acepta los errores como una parte natural del trabajo.

Además, XP, al igual que otros métodos ágiles, parte de los procesos ite­ra­ti­vos. XP rompe con la tradición de completar un proyecto durante meses de principio a fin para que al final el resultado no sea el adecuado. En lugar de esto, se hacen co­m­pro­ba­cio­nes, se habla y se publica co­n­s­ta­n­te­me­n­te en ciclos cortos. De esta forma se pueden de­te­r­mi­nar y eliminar los fallos rá­pi­da­me­n­te.

Para poder cumplir las exi­ge­n­cias, se ha de­sa­rro­lla­do un marco bastante definido. Se basa en distintos valores, pri­n­ci­pios y técnicas. Además, se asignan roles definidos para que las tareas se puedan asignar de forma clara.

La pro­gra­ma­ción extrema trata de modificar el enfoque general del trabajo de pro­gra­ma­ción con cinco valores. La idea es que el equipo como conjunto siga una me­n­ta­li­dad de­te­r­mi­na­da para poder colaborar de la mejor manera y entregar un producto de primer nivel.

En el XP no solo importa la co­mu­ni­ca­ción entre los miembros del equipo, sino también la co­mu­ni­ca­ción entre los de­sa­rro­lla­do­res y los clientes. El in­te­r­ca­m­bio continuo está pensado para poder abordar los problemas di­re­c­ta­me­n­te. Solo si todos los im­pli­ca­dos están en contacto de forma pe­r­ma­ne­n­te se pueden evitar y detectar rá­pi­da­me­n­te los malos en­te­n­di­dos. Además, la co­mu­ni­ca­ción hace que todos trabajen con el mismo nivel de in­fo­r­ma­ción y se sientan co­m­pro­me­ti­dos con el proyecto. En este contexto, se prioriza el diálogo cara a cara a la co­mu­ni­ca­ción escrita.

El XP siempre busca la solución más sencilla. La sencillez implica varias ventajas: si solo te co­n­ce­n­tras en los factores ne­ce­sa­rios, no te distraes con cue­s­tio­nes se­cu­n­da­rias. Este enfoque también implica de­sa­rro­llar solo las funciones ne­ce­sa­rias en cada momento y no adelantar trabajo para posibles re­qui­si­tos futuros. Así, el equipo de­sa­rro­lla más rápido. Además, un producto simple es mucho más fácil de manejar, ya sea a la hora de seguir de­sa­rro­llá­n­do­lo o de realizar el ma­n­te­ni­mie­n­to. Un código de pro­gra­ma­ción simple también facilita la co­m­pre­n­sión, otra ventaja a favor del valor de la co­mu­ni­ca­ción. Si todo el equipo es capaz de entender el texto fuente, es más fácil in­te­r­ca­m­biar im­pre­sio­nes.

Este valor también va es­tre­cha­me­n­te ligado a la im­po­r­ta­n­cia de la co­mu­ni­ca­ción directa. Es im­po­r­ta­n­te que el cliente tenga numerosas opo­r­tu­ni­da­des para expresar sus críticas. En el extreme pro­gra­m­mi­ng también se usan los mensajes del sistema (logs) como feedback. Para poder llevar a cabo un concepto de feedback como lo plantea el XP, es muy im­po­r­ta­n­te pensar en pasos pequeños. El equipo trabaja en ciclos cortos, comprueba el código cada poco e incluso le presenta el avance al cliente en in­te­r­va­los cortos. Así, las mo­di­fi­ca­cio­nes y co­rre­c­cio­nes de errores se pueden llevar a cabo rá­pi­da­me­n­te.

El extreme pro­gra­m­mi­ng entiende la valentía como la di­s­po­si­ción a decir la verdad, incluso cuando es poco agradable. Si hay errores en el producto, hay que se­ña­lar­los, aunque sean re­s­po­n­sa­bi­li­dad de uno mismo. En un equipo que trabaja según los valores XP tampoco hace falta di­s­cu­l­par­se. Ningún miembro del equipo debe perder el tiempo en intentar minimizar su re­s­po­n­sa­bi­li­dad en un error, ya que esto no es pro­du­c­ti­vo. Al margen de lo dicho, en este contexto también se entiende la valentía como la di­s­po­si­ción a modificar es­tru­c­tu­ras de or­ga­ni­za­ción, a cue­s­tio­nar los propios métodos de trabajo, a aceptar las críticas y a escribir nuevos códigos desde cero si hace falta.

Para que el equipo pueda trabajar de manera armónica y pueda ofrecer un re­n­di­mie­n­to excelente, se requiere respeto mutuo. El respeto también implica que un de­sa­rro­lla­dor no realice mo­di­fi­ca­cio­nes que tengan un impacto negativo en el trabajo de un compañero. Incluso fuera del equipo, la im­po­r­ta­n­cia de los valores es pri­mo­r­dial hasta llegar al cliente. Solo si nos tomamos en serio las demandas de la otra parte, podremos ate­n­de­r­las de manera correcta. Fi­na­l­me­n­te, la dirección de la empresa también debe tratar al equipo de de­sa­rro­lla­do­res con el debido respeto y aportar las co­m­pe­te­n­cias y los recursos ne­ce­sa­rios a los empleados.

En el extreme pro­gra­m­mi­ng, los pri­n­ci­pios se ubican entre los valores y las prácticas, es decir, son el puente entre lo abstracto y lo concreto. Los pri­n­ci­pios se pueden derivar en mayor o menor medida de los valores citados an­te­rio­r­me­n­te.

El feedback debe so­li­ci­tar­se y aplicarse lo antes posible. En este contexto, la idea es que el feedback del propio sistema (al comprobar el código) se aplique en cuestión de segundos, en lugar de recopilar primero todas las im­pre­sio­nes. El feedback de los clientes, en cambio, debe so­li­ci­tar­se y aplicarse en in­te­r­va­los de días o semanas.

El principio de la sencillez se co­rre­s­po­n­de con la base del valor con el mismo nombre, pero incluye in­s­tru­c­cio­nes concretas de apli­ca­ción. En este sentido se usan dos métodos:

• You ain’t gonna need it (YAGNI): mientras una función no se solicite ex­pre­sa­me­n­te, no se debe im­ple­me­n­tar para no realizar trabajo en vano.
• Don’t repeat yourself (DRY): debe evitarse repetir tareas y diseñar el código de manera que los cambios no tengan que aplicarse en varios puntos, sino una sola vez, en la medida de lo posible.

En el extreme pro­gra­m­mi­ng, las mo­di­fi­ca­cio­nes siempre se realizan en pasos pequeños. En lugar de im­ple­me­n­tar grandes ac­tua­li­za­cio­nes para co­n­tra­rre­s­tar varias fuentes de errores a la vez, solo se trata un problema cada vez. Así, el equipo reacciona más rápido y es más fácil entender la causa de las mo­di­fi­ca­cio­nes. No obstante, el principio no solo hace re­fe­re­n­cia al código del programa. Los cambios en el diseño o en la es­tru­c­tu­ra del equipo también se deben llevar a cabo en pasos pequeños e in­cre­me­n­ta­les.

Como la pro­gra­ma­ción extrema gira alrededor del cliente, sus pe­ti­cio­nes gozan de la máxima im­po­r­ta­n­cia. Por ello, todo el equipo debe ace­p­tar­las como algo positivo y no oponerse a su rea­li­za­ción. La consigna es incluso animar a los clientes a que ma­ni­fie­s­ten sus pe­ti­cio­nes de cambios en lugar de intentar co­n­ve­n­ce­r­los de que no hacen falta.

Suena banal, pero es im­pre­s­ci­n­di­ble para el fu­n­cio­na­mie­n­to del extreme pro­gra­m­mi­ng: el equipo debe realizar un trabajo de alta calidad. El listón lo pone el cliente. No obstante, para poder realizar un trabajo de calidad, hace falta contar con la dirección. Si los factores son los adecuados y el equipo puede estar contento con el trabajo realizado, dicho equipo va a gozar de un excelente estado de ánimo.

Las prácticas del XP son in­s­tru­c­cio­nes de actuación y métodos de trabajo muy concretos. Mientras que los valores y pri­n­ci­pios pre­se­n­ta­dos también se usan en otros métodos de trabajo ágiles, las técnicas concretas del extreme pro­gra­m­mi­ng son elementos cla­ra­me­n­te di­s­ti­n­ti­vos. Estas técnicas también cambiaron li­ge­ra­me­n­te y varían en función de la fuente empleada. Por norma general, las técnicas se dividen en cuatro ámbitos distintos.

En la pro­gra­ma­ción extrema, los pro­gra­ma­do­res trabajan con ciclos ex­tre­ma­da­me­n­te cortos. De esta forma se puede comprobar el código escrito una y otra vez. El de­no­mi­na­do test-driven de­ve­lo­p­me­nt (de­sa­rro­llo guiado por pruebas) está tan basado en la co­m­pro­ba­ción que los de­sa­rro­lla­do­res escriben primero un entorno de prueba antes de comenzar a crear el código fuente en sí. En el momento en el que un código no supere esta prueba, no se puede seguir de­sa­rro­lla­n­do. En este punto, el feedback nace del propio sistema.

El de­no­mi­na­do planning game (partido de pla­ni­fi­ca­ción) es una reunión que tiene lugar al inicio de cada fase de de­sa­rro­llo. El equipo y el cliente se reúnen para valorar el trabajo realizado hasta el momento, aportar opiniones y debatir futuras funciones. A co­n­ti­nua­ción, se asignan las tareas.

La idea de un on-site customer (cliente in situ) también genera feedback continuo. En el mejor de los casos, se busca que al menos un re­pre­se­n­ta­n­te del cliente prá­c­ti­ca­me­n­te forme parte del equipo para poder resolver dudas, aportar ideas o tra­n­s­mi­tir prio­ri­da­des más rá­pi­da­me­n­te.

Fi­na­l­me­n­te, el pair pro­gra­m­mi­ng (pro­gra­ma­ción en pareja) garantiza el principio de cuatro ojos: siempre hay dos personas tra­ba­ja­n­do si­mu­l­tá­nea­me­n­te en el código. Mientras un de­sa­rro­lla­dor escribe el código, otro lo comprueba, transmite consejos de mejora y señala errores. Este método es muy caro porque implica el uso de dos tra­ba­ja­do­res para un solo trabajo, pero el código re­su­l­ta­n­te es no­ta­ble­me­n­te mejor y exige menos trabajo de repaso.

Los equipos de XP están co­n­ti­nua­me­n­te reha­cie­n­do su código. La idea es que el re­fa­c­to­ri­ng mejore el texto fuente y elimine re­pe­ti­cio­nes y co­m­po­ne­n­tes in­ne­ce­sa­rios. Un código op­ti­mi­za­do de esta forma es más fácil de entender, incluso para lectores externos, y es menos su­s­ce­p­ti­ble de contener errores.

A través de la co­n­ti­nuous in­te­gra­tion (in­te­gra­ción continua), los equipos de extreme pro­gra­m­mi­ng y otros métodos de trabajo ágiles ga­ra­n­ti­zan una in­te­gra­ción continua del nuevo código en el proyecto completo. Un de­sa­rro­lla­dor escribe su trabajo varias veces al día en el proyecto. De esta forma se co­m­prue­ban co­n­ti­nua­me­n­te todas las apo­r­ta­cio­nes y los im­pli­ca­dos siempre trabajan con toda la in­fo­r­ma­ción.

En el XP los programas y las ac­tua­li­za­cio­nes que funcionan se publican lo antes posible. Estos small releases (entregas cortas) aumentan la fre­cue­n­cia de los feedbacks. Así, los errores se pueden detectar más fá­ci­l­me­n­te y ya se corrigen en la siguiente ac­tua­li­za­ción. El cliente tiene la opo­r­tu­ni­dad continua de probar di­re­c­ta­me­n­te los últimos avances del de­sa­rro­llo e im­ple­me­n­tar críticas y su­ge­re­n­cias.

Si el diseño es simple (simple design) todo el mundo puede entender el código. Por lo tanto, todo lo que complique el texto fuente de manera in­ne­ce­sa­ria debe eli­mi­nar­se. Cualquier de­sa­rro­lla­dor que trabaje según el extreme pro­gra­m­mi­ng querrá evitar cualquier du­pli­ca­ción. Además, debe quedar claro cuál es el objetivo del pro­gra­ma­dor a partir del propio texto fuente.

Para que todo el equipo pueda trabajar en estrecha co­la­bo­ra­ción, se definen coding-standards (es­tá­n­da­res de co­di­fi­ca­ción). Estas in­di­ca­cio­nes hacen re­fe­re­n­cia al enfoque y el formato. Es im­po­r­ta­n­te que los de­sa­rro­lla­do­res puedan trabajar en los códigos de sus co­m­pa­ñe­ros y que sepan qué cambios ha realizado cada uno.

La po­si­bi­li­dad de trabajar en el código de forma conjunta fortalece la propiedad conjunta del código (co­lle­c­ti­ve code ownership): en lugar de hacer hincapié en qué parte de re­s­po­n­sa­bi­li­dad (y también de errores) tiene cada uno, se contempla el código como un producto conjunto. De esta forma, todo el equipo es re­s­po­n­sa­ble de todo, tanto errores como éxitos. Además, esta técnica invita a seguir de­sa­rro­lla­n­do códigos de co­m­pa­ñe­ros y a integrar nuevas ideas.

Para que el texto fuente sea aún más co­m­pre­n­si­ble, en la pro­gra­ma­ción extrema se usa la técnica system metaphor. Esta práctica consiste en describir el proyecto de la manera más sencilla posible, incluso usando metáforas. Esta idea también se aplica a la no­me­n­cla­tu­ra de objetos, clases o funciones dentro del código, de modo que se han de utilizar siempre nombres au­to­de­s­cri­p­ti­vos en la medida de lo posible. Así, los tra­ba­ja­do­res nuevos que se suman al proyecto en­te­n­de­rán todo mucho más rápido. Así, el código no solo será co­m­pre­n­si­ble para los pro­gra­ma­do­res.

El bienestar del equipo es im­po­r­ta­n­te para el éxito del proyecto. Solo un empleado de­s­ca­n­sa­do y motivado puede ofrecer un re­n­di­mie­n­to y re­su­l­ta­dos de calidad. Para ga­ra­n­ti­zar este bienestar, el extreme pro­gra­m­mi­ng impone una semana de 40 horas. Las horas extra deben evitarse a toda costa y solo se permiten si la semana siguiente no se suman más horas.

Aquí los roles sirven para di­s­tri­buir todas las co­m­pe­te­n­cias entre los im­pli­ca­dos, tanto de­sa­rro­lla­do­res como clientes.

La pro­gra­ma­ción extrema gira en torno al cliente, hasta el punto que el cliente se considera como parte del equipo y siempre hay al menos un re­pre­se­n­ta­n­te presente (on-site customer). El cliente marca las exi­ge­n­cias del producto, pero solo marca de forma limitada cómo cumplir las exi­ge­n­cias. Solo es su re­s­po­n­sa­bi­li­dad marcar la prioridad por los ámbitos parciales. Esta re­s­po­n­sa­bi­li­dad también implica expresar sus propios deseos de manera co­m­pre­n­si­ble.

El rol del cliente lo puede de­sem­pe­ñar una sola persona o un equipo de distintos re­pre­se­n­ta­n­tes del cliente. En la práctica suelen en­ca­r­gar­se di­re­c­to­res de producto o empleados de la sección de marketing (en función del objetivo del proyecto) de estas tareas.

El equipo de de­sa­rro­lla­do­res no se divide en su­b­ca­te­go­rías, es decir, todo aquel que participa ac­ti­va­me­n­te en la creación del producto en sí, se considera un de­sa­rro­lla­dor. Por ello, aquí no solo se incluyen pro­gra­ma­do­res, sino también otras personas im­pli­ca­das en la creación, en función de los re­qui­si­tos del proyecto. Aparte del trabajo de de­sa­rro­llo pro­pia­me­n­te dicho, los pro­gra­ma­do­res también tienen la tarea de reac­cio­nar a los deseos del cliente: calcular el gasto, es­ta­ble­cer un marco temporal, pla­ni­fi­car la im­ple­me­n­ta­ción.

Entre los derechos de los de­sa­rro­lla­do­res está la po­si­bi­li­dad de buscar recursos ne­ce­sa­rios, es decir, solicitar a la dirección medios adi­cio­na­les. Además, el XP impone a los de­sa­rro­lla­do­res la semana de 40 horas. Es im­po­r­ta­n­te para el proyecto que los de­sa­rro­lla­do­res no estén ex­plo­ta­dos. Por ello, el equipo de de­sa­rro­lla­do­res establece su propio horario.

El director es el elemento de co­mu­ni­ca­ción entre los de­sa­rro­lla­do­res y los clientes. Los re­pre­se­n­ta­n­tes de este grupo son los que organizan las reuniones entre ambas partes y presiden el planning game, por ejemplo. En este contexto, el director debe prestar atención a que se cumplan las normas acordadas pre­via­me­n­te y las co­n­ve­n­cio­nes generales de un debate co­n­s­tru­c­ti­vo. El director también debe actuar como mediador si es necesario.

Este rol a veces también se denomina como tracker (re­gi­s­tra­dor). El motivo es que el director también es el encargado de registrar cifras ca­ra­c­te­rí­s­ti­cas im­po­r­ta­n­tes, (p. ej., el tiempo que emplea cada tra­ba­ja­dor en el proyecto).

Todo el equipo (incluido el cliente) debe estar fa­mi­lia­ri­za­do con el extreme pro­gra­m­mi­ng y saber cómo aplicar este método de trabajo de manera co­n­se­cue­n­te. Un tutor o coach puede ser útil para que todos tengan la misma idea de los procesos. El coach no participa en el de­sa­rro­llo del producto en sí, sino que solo brinda su apoyo como ayudante externo, de forma similar a un scrum master. En co­n­ve­r­sa­cio­nes previas se pueden repasar las normas y prácticas con esta persona. En el mejor de los casos, el coach acompaña al equipo a lo largo de todas las fases del de­sa­rro­llo y ayuda a resolver dudas.

A menudo se emplea un proveedor de servicios externo para esta función. También puede ser que el coach sea de la misma empresa, pero en este caso, de otro de­pa­r­ta­me­n­to. Deben evitarse si­tua­cio­nes en las que una persona desempeña varios roles (por ejemplo, un de­sa­rro­lla­dor que también desempeña el rol de coach).

El extreme pro­gra­m­mi­ng ha es­ta­ble­ci­do puntos de re­fe­re­n­cia im­po­r­ta­n­tes para el tipo de de­sa­rro­llo de software, pero no es adecuado para todos los es­ce­na­rios ni para todos los equipos. El XP parte de la base de que, al comenzar el proyecto, el cliente aún no tiene una idea definida del producto terminado. En estos casos, el software se puede pla­ni­fi­car y de­sa­rro­llar de forma ágil, es decir, paso a paso.

Por un lado, esta forma de trabajo satisface al cliente. La solución adecuada se determina con su pa­r­ti­ci­pa­ción y se le integra en cada paso. Por otro lado, los de­sa­rro­lla­do­res pueden llevar a cabo los proyectos en la manera en que lo co­n­si­de­ren apropiado en lugar de tener que estar cediendo siempre. No obstante, si el cliente ya contacta al equipo de de­sa­rro­lla­do­res con una de­s­cri­p­ción de­fi­ni­ti­va del producto y una lista de funciones deseadas, es muy difícil aplicar el método XP.

El concepto de pro­gra­ma­ción en parejas puede suponer un problema para los equipos más pequeños, ya que carecen de las ca­pa­ci­da­des ne­ce­sa­rias. Las co­n­s­ta­n­tes reuniones con el cliente también implican la de­di­ca­ción de tiempo que no se puede destinar al trabajo de pro­gra­ma­ción en sí. En una situación ideal, esto no es relevante. El resultado será no­ta­ble­me­n­te mejor si el equipo puede tomarse el tiempo y los recursos ne­ce­sa­rios. No obstante, en la práctica, los de­sa­rro­lla­do­res siempre se ven pre­sio­na­dos por un pre­su­pue­s­to limitado y unos plazos muy marcados. Además, es posible que el cliente carezca del interés o las po­si­bi­li­da­des ne­ce­sa­rias para im­pli­car­se tanto en el proyecto como lo exige el XP.

Ahora bien, si las co­n­di­cio­nes permiten un pro­ce­di­mie­n­to según el método del extreme pro­gra­m­mi­ng, cualquier equipo puede obtener un resultado excelente mediante esta técnica. Las continuas pruebas generan sistemas muy estables y el pro­ce­di­mie­n­to iterativo en co­la­bo­ra­ción con el enfoque mi­ni­ma­li­s­ta ga­ra­n­ti­zan que solo se creen funciones que realmente son im­po­r­ta­n­tes para el proyecto.