Desarrollo de software: probando Extreme Programming


El desarrollo de software es muy divertido, pero desarrollar buen software no es fácil. Esta frase la leí hace un tiempo no se en donde.

Desarrollar buen software depende no solo de la capacidad del programador, va mucho más allá. Todas esas cosas que parecen fastidiosas como crear documentación, manejar y mitigar riesgos, y otras más necesarias como manejo de requerimientos y errores son importantes para el desarrollo de un software de alta calidad.

Actualmente me encuentro desarrollando una aplicación web para educación a distancia como proyecto de grado. En la Universidad hemos practicado el desarrollo de software usando la metodología RUP, la cual en mi experiencia no hemos usado adecuadamente, por ello decidimos experimentar otras opciones.
Luego de revisar algunas, nos decidimos por una metodología de desarrollo ágil: Extreme Programming (XP) ya que se adaptaba bastante bien al proyecto.

¿Cuándo usar XP?

Alguna de las situaciones en las que XP es adecuada son:

Los requerimientos no están claros o cambian mucho: el cliente no tiene una idea clara de lo que el sistema debería hacer.

Nuestro proyecto requería la reescritura de una plataforma existente, pero modificando la concepción original de trabajo orientándola hacia las redes sociales y la web 2.0
Los riesgos son altos: si el cliente tiene una fecha tope o si el proyecto representa una novedad para el equipo de desarrollo.

La aplicación a pesar de no ser innovadora en cuanto a sus herramientas, sí era una novedad para los desarrolladores el uso de estándares del área de educación. Así mismo, el nuevo enfoque que se le daba representaba una novedad para todo el equipo. (Realmente es y será novedad para toda la comunidad).
se trabaja con un equipo de desarrollo pequeño: se recomienda equipos de entre 2 y 12 programadores.
Somos 3.

Se dispone de un equipo multidisciplinario: el equipo debe no solo ser de desarrolladores, sino también los gerentes y clientes, todos trabajando en conjunto.

El equipo de soporte ofrecido constaba de gente con conocimientos en las áreas de diseño, computación y pedagogía.

El código debe poder ser probado: debe ser posible automatizar las pruebas unitarias y funcionales.
Partíamosde la idea de usar CakePHP como framework de desarrollo. Este nos ofrecía una suite de pruebas automatizadas.

¿Qué ha salido bien y qué no?

Para hacer la historia corta, enumeraré algunos de los principales problemas que se han presentado.
El trabajo multidisciplinario y en conjunto.

Resultó que nuestro tutor es una persona muy ocupada y en varias ocasiones no asistió a las reuniones pautadas (llegó un punto en el que dimos por descontado su asistencia y dejamos de ir nosotros). Así mismo, durante 6 meses las distintas personas que podrían proveernos de la información necesaria para tomar decisiones de diseño importantes no pudieron asistir a las reuniones.

Esto generó como resultado desmotivación en los desarrolladores y estancamiento en la toma de decisiones. Dos aspectos importantes de esta, y cualquier otra, metodología de desarrollo de software.
Otro problema que causó estragos en nuestra planificación fue relacionado al manejo de riesgos

Riesgos altos

Los primeros 3 meses fueron necesarios para implementar el primer módulo de la aplicación. Este módulo es el encargado del presentación de lecciones al estudiante. El estándar (SCORM) en el que se basaba ese módulo es tan denso y complejo que fácilmente hubiese dado para un trabajo de grado completo.

Luego nos enteraríamos que, gracias a la falta de comunicación descrita antes, que los profesores que van a usar el sistema no tienen contenidos en el formato adecuado. La versión de SCORM que usan (1.2) no coincide con la que hemos desarrollado. (En una empresa hubiesen rodado cabezas, acá querían que la dedicaramos otros 3 meses a implementar dicha versión… ¬_¬ )

Los demás puntos los hemos cumplido a cabalidad, el código está en su mayoría documentado y probado. Esto último, las pruebas funcionales automatizadas, se han convertido en nuestra maya de seguridad invaluable.

Aspectos Interesantes de XP

La documentación

XP no hace previsiones para la documentación, sin embargo es lógico que sea necesaria para que cualquier persona fuera del proyecto se ponga en contexto. Al final todo dependerá del proyecto y del equipo.
Para este proyecto la documentación es necesaria por una par de razones: al finalizar el proyecto serán otras personas quienes se encarguen del mantenimiento; y por otro lado, al ser un proyecto de grado es necesaria mucho más la documentación para convencer a los jurados

La propiedad compartida del código

Extreme programming aboga porque ninguna parte del código sea propiedad exclusiva de alguno de los desarrolladores, esto con la intensión de disminuir la necesidad de documentación hacia adentro del equipo de programadores. Adicionalmente esto permite evitar cuellos de botella que entorpecen el avance.

Para lograrlo, XP exige dos cosas: mover a los desarrolladores de sus asignaciones a otras y desarrollar en parejas de modo que la toma de decisiones y el conocimiento sobre ellas no sea un secreto.

Adicionalmente, cada día las reuniones permiten notificar estas decisiones al resto del grupo.

En este apartado, puedo decir que en gran parte se ha logrado. El desarrollo en parejas puede ser perjudicial si no se mantiene la disciplina necesaria para concentrarse en el código y no en la cháchara.

Conclusión

XP se adapta muy bien a un proyecto que requiere un código de calidad, probado y confiable. No hace énfasis en la documentación (al contrario de RUP) lo cual nos ha ayudado a concentrarnos en lo importante para el cliente: la funcionalidad.

Disponer del cliente/asesor realmente dedicado y concentrado es importante para acelerar el desarrollo y evitar pasos en falso.

La planificación semanal y la planificación de las entregas es importante para mantener metas claras.
Otra cosa…

No como será en otros paises, pero he odio que las empresas promedio en Venezuela les importa un bledo la metodología. Es triste pasar 5 años aprendiendo cosas que a las empresas no les interesa.
Pero menos mal que la tarea de la universidad no es ofrecer lo que la sociedad demanda, sino lo que la sociedad necesita — E.W. Dijkstra

Entradas que pueden interesarte