Crónicas del Buen Programador: Errores comunes en la Programación Extrema
No dejen de mejorar la eficacia y eficiencia de la aplicación de la programación extrema como metodología en sus proyectos informáticos, evitando caer en los errores más comunes.
La programación extrema, a la que me referiré ahora en adelante como XP, persigue conseguir un desarrollo acelerado, flexible y cambiante, con entregas frecuentes y evaluaciones constantes por el cliente, con el fin de obtener un software de mayor calidad en su exhaustiva evaluación y re-evaluación de las entregas y prototipos.
En un plano general digamos que la XP, vista como una metodología formal, nunca busca mitigar los riesgos de un proyecto de software con un análisis y diseño perfeccionista al inicio del mismo. XP se estrella de frente contra los riesgos una vez que éstos se han convertido en un hecho, los absorbe al momento y los supera en una iteración con la re-planificación de entregas, la revisión (corrección) de las historias de usuario y la refactorización.
En esta carrera con obstáculos es muy fácil meter la pata de vez en cuando. A pesar que parezca algo muy sencillo adaptarse a la XP como metodología de desarrollo (ya que a simple vista nos parece que de alguna u otra forma la hemos estado aplicando empíricamente), en la cruda realidad de un proyecto donde se interactúa con un equipo numeroso de personas deja de parecer cosa de “coser y cantar”.
Antes de llegar a mi explicación de los errores comunes en la XP, me gustaría recordarles que básicamente la XP es un cúmulo de “buenas prácticas” para guiar el desarrollo caótico de los proyectos de software. Estas prácticas, recordemos (sin entrar en explicaciones más profundas), son las siguientes:
- El juego de la planificación (the planning game)
- Entregas pequeñas (small releases)
- Metáfora (metaphor)
- Diseño simple (simple design)
- Pruebas (testing)
- Refactorización (refactoring)
- Programación en parejas (pair programming)
- Propiedad colectiva (collective ownership)
- Integración continua (continous integration)
- 40 horas semanales (40-hour week)
- Cliente en casa (on-site costumer)
- Estándares de codificación (coding standards)
Existen autores que defienden la idea de que sólo se aplica la XP cuando se llevan a cabo en su totalidad las 12 prácticas antes mencionadas, otros dicen que para aplicar XP no necesariamente se deben adoptar estas 12 prácticas completas… “XP o no XP, ese es el dilema”. Realmente no me propongo aclarar ese dilema, pero en cambio me propongo hablarles un poco de los errores frecuentes para cada una de las prácticas. ¿Para qué? Bueno, si ya sé lo que no debo hacer, es más fácil (en la mayoría de los casos) hacer lo que debo hacer.
El juego de la planificación
La mayoría de las personas malinterpretan esta práctica, comparándola con una etapa de planificación exhaustiva y minuciosa, característica de otras metodologías. Definitivamente ese es un error. El juego de la planificación se da comienzo con una planificación general, a groso modo, de lo que se piensa realizar para llevar a cabo el proyecto.
Posteriormente una vez que los clientes hayan redactado las historias de usuario, se procede a planificar las pequeñas entregas para periodos cortos de tiempo.
Otro error frecuente es dejar que el equipo de desarrollo interfiera con la redacción de las historias de usuario. El cliente no debe ser contaminado en primera instancia con la visión de los programadores. Inicialmente las historias de usuario deben estar redactadas completa y únicamente por el cliente, para que más adelante estas historias de usuario sean discutidas por todo el equipo (incluyendo al cliente) y se defina todo aquello factible o dentro del alcance del proyecto.
Entregas pequeñas
En proyectos grandes hasta los módulos considerados más pequeños suelen ocupar un tiempo considerable de desarrollo. El error en la división del proyecto por módulos y que las entregas se conviertan en las entregas de los módulos es sumamente frecuente. Para evitar esto se debe fraccionar a la mínima expresión o tarea cada modulo a desarrollar y posteriormente agrupar esas tareas de manera tal que su tiempo de desarrollo no supere las 3 semanas (siendo el tiempo ideal 1 semana). Vale la pena aclarar que no necesariamente las diferentes tareas que conformen un modulo coinciden con una historia de usuario (o con un caso de uso en particular). A veces una historia de usuario podrá ser desarrollada en 1 semana y otras habrá que dividirla en tareas porque su desarrollo será de 1 mes.
Metáfora
La práctica de la metáfora siempre es difícil de entender. Pero como siempre he dicho: La mejor forma de explicar una metáfora es con una metáfora.
¿Por qué constantemente Pinky pregunta a Cerebro qué van a hacer el día de hoy (*1)? ¿Será que Cerebro no ha sabido usar la metáfora ideal para hacer que el objetivo de su plan sea comprendido por su equipo de trabajo: Pinky?
Y no le queda más que repetirla:
“Lo mismo de todos los días Pinky: ¡Tratar de conquistar al mundo!”
En el caso de Cerebro su metáfora se encuentra sumergida en su realidad. En otras palabras, lo que él le está diciendo a Pinky es literalmente lo que quiere hacer. Pero un momento… “Tratar de conquistar al mundo” no parece ser algo fácil de comprender cierto? Y mucho menos algo fácil de hacer. A pesar que ese es el objetivo fundamental, sigue siendo mucho más provechoso dar un sentido metafórico al proyecto de manera que cada individuo se sienta identificado con el ideal, la misión o el objetivo que se persigue.
Talvez si Cerebro un día le respondiera a Pinky: “… ¡Tratar de ser el queso del mundo!” ,Pinky en su mente de ratón (estúpida además) podría captar el mensaje (aunque sea en lo más profundo de su ser ;) ), y con un poco de suerte ya Cerebro no tendría que seguir respondiendo su pregunta una y otra vez.
Como podemos ver, el error común de esta práctica yace en la mala creación o selección de la metáfora per se.
Diseño simple
Generalmente la gente tiende a confundir lo simple con lo mediocre. Eso no tiene porque ser así. De hecho la más grande de las mediocridades es solucionar de la manera más compleja el problema más sencillo. ¿Para qué gastar pólvora en zamuro?
El diseño en XP debe ser KISS (Keep It Small and Simple – Mantenlo Fácil y Simple).
Las soluciones complejas a pesar de que sean geniales pueden tomarse un tiempo de diseño exagerado en comparación con una solución más simple que retorne los mismo resultados. He allí la importacia de la simplicidad en el diseño y desarrollo del software en XP, los tiempo de entrega no deben prolongarse, después de la entrega siempre habrá tiempo para perfeccionar aquello que ya funciona. Esta última frase que he marcado en negrillas no suele ser bien vista por los gerentes de proyectos, pero resulta que es amada por aquellos a quienes resulta transparente: los clientes.
XP en etapas tempranas del proyecto otorga mayor importancia a la eficacia sobre la eficiencia. Posteriormente habrá tiempo de balancear la ecuación y optimizar la utilización de los recursos, para que en conjunto la eficacia y la eficiencia proporcionen los parámetros necesarios para afirmar que hemos realizado una labor con optima calidad (eficacia + eficiencia = efectividad).
Exigir la temprana perfección del diseño va completamente en contra de XP. Un proyecto llevado a cabo con XP es el resultado de una evolución, es una gallina nacida de un huevo, no es un conejo sacado de un sombrero.
Pruebas
Las pruebas se supone que deben ser Unitarias, nunca “Colectivas”. Cada prueba debe tener un fin determinado. Me explico:
En una etapa muy pronta del desarrollo probar las validaciones de las entradas a un sistema puede que no tenga mucho sentido, pero probar el resultado correcto de una función puede que nos resulte más beneficioso.
Las pruebas deben ir a la par de las entregas del proyecto, nunca más adelante ni detrás de las mismas.
Refactorización
La refactorización debe ser tema de cuidado. En ciertas ocasiones la refactorización se puede convertir en un ciclo de nunca acabar.
Cada prueba no superada debería dar pie a una refactorización, y de esa forma es que debe funcionar. La refactorización sólo debe llevarse a cabo una vez que se ha probado contundentemente que es necesaria la corrección del código en cuestión.
En cualquier otro caso se estaría hablando de una refactorización por motivos de estética o para mejorar la usabilidad del producto, cosa que es válida, pero no podemos olvidar que en primer plano lo importante para XP es “Make It Work”. Así que en mi opinión la refactorización debe saber ubicarse entre las etapas donde se encuentra el desarrollo del equipo o parte del mismo. De nada sirve que corrijamos algo para que sea rápido y estético si todavía no funciona…
Nota mental para todos: En XP la frecuencia de las entregas es más importante que la calidad de las mismas. Suena ilógico al comienzo, pero piénsenlo y se darán cuenta que para XP la retroalimentación del cliente lo es todo, sin ella se convierte en una metodología inútil.
Programación en parejas
La programación en parejas no suele ser bien vista por las empresas, porque les da por pensar que están dejando ocioso a uno de cada par de programadores. Tampoco es bien vista por los programadores porque todos prefieren tener su propio PC para sentirse más a gusto. Pero no todo es malo, 4 ojos ven mejor que 2 sin duda. Se dice que el código producto de 2 personas trabajando al mismo tiempo en la misma máquina contiene menos errores que el de 1 sola persona haciendo lo mismo, y la verdad es que me parece que hay mucho de cierto en eso, tomando en cuenta también que cuando una persona esta al lado tuyo mirando lo que haces en el trabajo simplemente no pierdes tiempo haciendo otras cosas que podrían esperar tan sólo por consideración o por vergüenza.
Ahora la cuestión es: ¿cómo hacer que los jefes y los empleados estén contentos con la implementación de esta práctica? El error común es dejarla a un lado, desaprovechando los beneficios de la programación en parejas por cualquiera o ambos motivos.
En mi opinión lo mejor en este caso es tomar una decisión salomónica. Se le deja trabajar con máquina propia a cada empleado, pero ciertas tareas consideradas críticas por el equipo se deberán desarrollar en parejas. Digamos que de esa manera se puede obtener en cierta medida lo mejor de los 2 mundos.
Propiedad colectiva
El error común por parte de los clientes es el de la omisión de información. Ocultar conocimientos del área de negocios en que se ubica el proyecto es el peor de los errores. No es buena práctica ir dosificando en gotas la información, la idea es aclarar dudas justo al momento en que se presentan en el equipo de desarrollo.
Sin embargo este es un error común en los clientes y líderes de proyectos, ya que se toman la tarea de filtrar la información a su consideración. En la mayoría de las ocasiones esto se debe a la falta de confianza en el equipo y por ende, el miedo a perder “Derechos de Autor” sobre el producto.
El otro error común, pero por parte de los programadores, se refleja en una sola frase: “Es muy fácil mejorar una idea, lo difícil es tenerla.”
Ciertos desarrolladores tienen la mala costumbre de convertirse en unos zamuros de ideas. Sale alguien con una solución genial pero un poco improvisada, la desarrolla y la comparte, y el resto simplemente se sienta a esperar que este se la entregue para continuar, pero más tarde lo que hacen es añadir, quitar y reorganizar lo que ya esta hecho y funcionando con la intención de mejorarlo, comprometiendo a veces los tiempos de entrega. Sin olvidar que luego estos amigos quieren dar a conocer su nueva versión, con intenciones de atribuirse grandes méritos.
El problema no se trata de la competencia típica, sino que esta competencia deje de ser cooperativa en pro del proyecto para convertirse en una competencia personal en pro del individuo. Señores, en XP el mérito es colectivo y puede esperar, los tiempos de entrega no.
Integración continua
Algo debe quedar claro: la integración no es una prueba.
Puede que se lleven a cabo con anticipación ciertas pruebas de integración, corroborando así los estándares de codificación y el acoplamiento, etc. Pero lo cierto es que la integración continua no debe frenar o comprometer el tiempo de desarrollo de las entregas.
No se puede permitir que el resultado de la integración continua sea una refactorización constante.
La integración continua debe estar consciente de las prioridades de XP: si funciona, hazlo bien, y si ya lo hace bien, entonces hazlo rápido (Make It Work, Make It Right, Make It Fast).
40 horas semanales
Creo que todos sabemos cual es el error común de esta práctica. Al inicio del proyecto se comienza trabajando 30 horas semanales y al final cuando se aproxima el “Dead Line” se termina trabajando 100 horas semanales… ¡Muy mal!
En XP nunca se debe trabajar de más, pero tampoco de menos. En XP se debe trabajar lo justo, manteniendo el equilibrio de las 40 horas semanales. Y aunque sea mal visto por los gerentes de proyecto, si un empleado trabaja horas extras un día esas horas deberían ser no trabajadas al día siguiente, sirviendo como estímulo a la persona. Igualmente el empleado debe comprometerse a cumplir con horas extras al día siguiente aquellas horas que no sean trabajadas un día, por motivos considerados no justificados formalmente por la empresa.
Cliente en casa
Esta práctica digamos que puede que sea la mentirilla blanca en la mayoría de los proyectos utilizando XP.
Generalmente el ritmo de trabajo del cliente no le deja tiempo suficiente como para que podamos decir: “lo tenemos en casa”. Digamos por lo tanto que la disponibilidad del cliente no suele ser inmediata.
En este caso el error común y más grave de todos es que las reuniones acordadas a disponibilidad del cliente sean demasiado escasas y muy distanciadas una de otra. Para luchar contra ello hay que comprometer al cliente con el proyecto, hacerlo sentir completamente dentro del equipo, y otorgarle ciertas tareas en la matriz de responsabilidades del proyecto (con sus tiempos de entrega) no esta demás.
Estándares de codificación
Los estándares de codificación son la bendición de las prácticas para desarrollar software. La bendición… y a veces la maldición.
Cuando los estándares de codificación son muy rigurosos tienden a frenar la velocidad del desarrollo e inevitablemente cuartan en cierta medida la creatividad de los programadores para brindar soluciones novedosas que puedan no adaptarse completamente a los requisitos de los estándares adoptados.
El error que no se debe cometer es precisamente adoptar estándares de codificación complejos. Se necesita que éstos sean prácticos y que todo el equipo de programadores se encuentre de acuerdo y se sienta a gusto con los mismos. Esto nos permite vislumbrar que se deben tomar en cuenta en la agenda aquellas reuniones a inicios del proyecto donde los estándares sean discutidos por todo el equipo.
—
En conclusión, en cualquiera de los casos que se aplique XP, con todas sus prácticas o con la mayoría de ellas, lo que importa es que todas las que se adopten sean desempeñadas con un margen de error mínimo para asegurar un porcentaje de efectividad jugoso que conlleve al eventual éxito del proyecto de software.
Y nunca olviden,
quien este libre de “errores” que tire la primera piedra…
(*1)Pinky y Cerebro son dibujos animados que tuvieron sus inicios como un show Animaniacs de la Warner Brothers. Pinky es un tonto ratón de laboratorio y Cerebro es un genio brillante. Cada día Cerebro piensa planes disparatados para controlar el mundo con la ayuda de Pinky.
[ad#Google Adsense-468x15ContentLinkunit]
