La metodología de programación extrema fue introducida por el americano Kent Beck (autor también de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development)
y coautor de JUnit) en el año 1999, aunque empezó a trabajar en la
misma años antes, concretamente desde el año 1996 cuando fue contratado
por Chrysler Corporation, para intentar sacar adelante una aplicación
para nóminas que hasta entonces tenía importantes problemas en el
desarrollo. Cuando empezó a trabajar en el proyecto, detectó una serie
de aspectos en el proceso de desarrollo que debían cambiar, aplicando
para ello una serie de estrategias, muchas de ellas basadas en buenas
prácticas ya contempladas y utilizadas.
La programación extrema se sitúa en una posición diferente a los
ciclos de vida tradicionales. Ya no se trata de requisitos que se
cierran en etapas tempranas del desarrollo y que constituyen el contrato
de lo que posteriormente se va a desarrollar (y que los usuarios no ven
hasta mucho después) sino de requisitos que están vivos y que son
modificables a lo largo del ciclo de vida.
La programación extrema se centra en cinco principios:
- Simplicidad: Conforme en el proceso de construcción un sistema va
creciendo paulatinamente (aplicable también a mantenimientos sobre
sistemas ya construidos), la complejidad del código va creciendo de
manera proporcional (o incluso exponencial en función del tamaño del
proyecto y del número de personas que participen en el proceso).
Mediante la refactorización, se intenta mantener el código en unas
condiciones donde la complejidad esté controlada y facilite la
escalabilidad del sistema. Esto requiere disciplina y creer que esta
metodología produce resultados ya que resulta complicado tomar la
decisión de tocar código que ya funciona (esto va en contra de una de
las máximas de la programación que consiste en que no toques algo que
funciona, aunque también es cierto que la misma viene derivada de las
malas experiencias provocadas por la crisis del software).
La integración continua
resulta esencial en esta metodología, ya que ofrece la oportunidad de
probar con una cierta regularidad la integración de los componentes, de
manera que este tipo de problemas se puede detectar lo antes posible.
El control de la calidad del código se complementa con otras estrategias como por ejemplo el intento de que el mismo sea lo más autocomentado
posible (sin prescindir de comentarios cuando sean necesarios). ¿Por
qué la metodología prioriza la autodocumentación? Como el proyecto es
algo que está vivo, el código se modifica con cierta frecuencia (sobre
todo en el proceso de construcción), ¿por qué preocuparse en comentar un
código que tal vez tenga que modificar muy pronto ya sea por una
modificación funcional, por una corrección o por una refactorización? A
esto hay que añadirle el peligro de que empiecen a quedarse atrás
comentarios que no se han eliminado y que no se correspondan con la
realidad del código. Si el código está autodocumentado evoluciona de la
misma manera que lo hace el proyecto.
Para esta metodología lo más importante del proceso de desarrollo de
software es el código, la base para esto tiene un razonamiento simple,
sin código no hay aplicación. Se considera que una aplicación que
funciona según las necesidades del cliente tiene mucho más peso que el
hecho de que esté documentada al detalle.
Para sostener esta afirmación en sistemas de un cierto tamaño es
fundamental un código de mucha calidad. De no ser así, el cambio de un
equipo de desarrollo por otro puede provocar un riesgo importante para
conseguir una continuidad en el mantenimiento del proyecto ya que se
estará caminando por un terreno lleno de trampas y con poca luminosidad.
- Comunicación: Fluida y continua. Para ello se programa por parejas
(pair-programming, un ordenador, dos personas) y los usuarios designados
por el cliente forman parte del equipo de desarrollo (se eliminan
fronteras). Pero la comunicación va más allá de eso, un código comentado
(autodocumentado) y con pruebas unitarias definidas expresa información
para la comprensión del mismo, es como una caja del tiempo o un mensaje
en una botella y que será muy útil cuando se tengan que realizar
modificaciones.
Algunos de los críticos de esta metodología comentan que la tendencia
de los programadores a considerar el código desarrollado como propio
dificulta el proceso de comunicación ya que cada cual considera que sus
opiniones y decisiones son y han sido las mejores, que su código es
difícilmente superable (o por lo menos que era complicado hacerlo mejor
en el tiempo que se ha dispuesto para desarrollarlo) y además no se
suelen aceptar de buen grado las correcciones (sobre todo si están
relacionadas con la calidad).
Para resolver ese inconveniente la programación extrema considera que
el código es colectivo, no hay parcelas, de manera que cualquier
integrante del equipo de proyecto puede realizar contribuciones a
cualquier parte del mismo.
Las pruebas unitarias
resultan esenciales, ya que permiten automatizar la revisión del
funcionamiento de cada módulo y así tener la posibilidad de realizar
este tipo de tareas con frecuencia. Hay que tener en cuenta también que
el código está en continua evolución por lo que las pruebas de regresión
cobran importancia. El objetivo es detectar posibles errores lo antes
posible. La detección tardía de errores es más costosa y su corrección
además tiende a ensuciar el código (cuando el tiempo aprieta lo
importante es apagar el fuego).
Aunque no es obligatorio, se recomienda incluso que las pruebas
unitarias de cada componente estén construidas antes de desarrollarlo.
Otro aspecto característico de la metodología son las reuniones
diarias, que se realizan de pie y en círculo (stand-up meetings) y que
tienen una duración aproximada de quince minutos. En las mismas se habla
sobre el estado actual del proyecto y sobre contingencias,
problemáticas o dudas que se produzcan en el mismo.
Para favorecer la comunicación se aconseja que todo el equipo de
trabajo se encuentre en la misma ubicación física y en entornos
despejados.
- Retroalimentación: La participación y proximidad de los usuarios
permite resolver dudas casi de forma instantánea, pueden ver
funcionalidades concretas construidas parcialmente y opinar sobre ellas.
Se comparten opiniones sobre cuál puede ser la mejor solución (es
importante lo funcional pero hay que equilibrar lo que se quiere con la
complejidad de realizarlo, como dijo Voltaire, lo perfecto es enemigo de
lo bueno)
El desarrollo iterativo incremental
permite que en cada evolución el usuario pueda expresar su opinión
sobre los resultados obtenidos y si es necesario corregir algo,
planificarlo para la siguiente o próximas iteraciones.
- Coraje: Optar por esta metodología no es sencillo por muchos
factores, por muchos interrogantes. ¿Es sencillo admitir que se programe
por parejas?, es decir, ¿puede todo el mundo entender que en cada
momento uno toque el teclado y el otro mire?, ¿se puede comprender que
esta estrategia no tiene por qué afectar a la productividad?.
La programación en parejas tiene una serie de ventajas:
Las decisiones en la codificación no son algo unilateral de la
persona que programa el componente (los arquitectos o analistas
orgánicos no pueden llegar a todo el detalle de la programación, ya que
ellos determinan el armazón de la aplicación que librerías utilizar, su
división en capas, etc…, es decir, establecen el marco general).
El código es revisado en tiempo real, disminuyendo la probabilidad de error e incrementando la calidad del código.
Pero no es solo lo anterior, ¿puede ser admisible que se retoque
software que ya funciona con el objeto de mejorar su calidad
(simplicidad)?, ¿se puede vivir en un proyecto donde los requisitos
están siempre en el aire?, ¿es sostenible un proyecto orientado a
entregas continuas cada poco tiempo donde el cumplimiento de los plazos
resulta de gran importancia?.
Sobre esto último algunos de los críticos con la metodología
consideran que el equipo de trabajo está vendido a las entregas y que al
haber muchas y frecuentes, los errores en la planificación provocarán
numerosos picos de trabajo con el consiguiente overtime para los
distintos integrantes del equipo de proyecto.
Sin embargo los defensores sostienen que el mismo Kent Beck considera
que es necesario evitar el cansancio de los componentes del equipo de
proyecto, debiéndose respetar su jornada laboral, situándose esta en
cuarenta horas semanales. De hecho considera que no se debe haber
overtime dos semanas consecutivas. Aplica por tanto el principio de
responsabilidad en el sentido de que hay que tener disciplina con las
entregas pero que eso no puede estar por encima de un continuo
sobreesfuerzo de los integrantes del equipo de trabajo. ¿Por qué
defiende esto? Pues porque los programadores cansados escriben código de
peor calidad y además son menos productivos.
- Respeto: Algo complicado de encontrar en los proyectos de
desarrollo de software y en un mundo tan ombliguista como es este. Se
basa en el hecho de que todos los participantes en el equipo de proyecto
suman y que es importante que se tenga en cuenta que para que todo vaya
bien, todos tienen que dar lo mejor de sí y para que esto se pueda
producir hay que crear un ambiente que lo propicie. Las críticas deben
ser constructivas, siempre para mejorar, siempre para ir hacia adelante.
Es importante que se tenga en cuenta que para que el barco vaya hacia
adelante todos tienen que remar y que si se hunde se hunden todos.
Por otro lado cada participante debe asumir su responsabilidad, cada
cual tiene su rol y debe entender que tras él hay una serie de tareas
que se tienen que realizar, gustén más o gusten menos.
http://jummp.wordpress.com/2011/04/20/desarrollo-de-software-programacion-extrema-extreme-programming-xp/
No hay comentarios.:
Publicar un comentario