Desarrollar buen software depende no solo de la capacidad del programador, va mucho ms all.

Todas esas cosas que parecen fastidiosas como crear documentacin, manejar y mitigar riesgos, y otras ms necesarias como manejo de requerimientos y errores son importantes para el desarrollo de un software de alta calidad. Actualmente me encuentro desarrollando una aplicacin web para educacin a distancia como proyecto de grado. En la Universidad hemos practicado el desarrollo de software usando la metodologa RUP, la cual en mi experiencia no hemos usado adecuadamente, por ello decidimos experimentar otras opciones. Luego de revisar algunas, nos decidimos por una metodologa de desarrollo gil: Extreme Programming (XP) ya que se adaptaba bastante bien al proyecto.

Cundo usar XP?

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

Los requerimientos no estn claros o cambian mucho: el cliente no tiene una idea clara de lo que el sistema debera hacer. Nuestro proyecto requera la reescritura de una plataforma existente, pero modificando la concepcin original de trabajo orientndola 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 aplicacin a pesar de no ser innovadora en cuanto a sus herramientas, s era una novedad para los desarrolladores el uso de estndares del rea de educacin. 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 pequeo: 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 tambin los gerentes y clientes, todos trabajando en conjunto. El equipo de soporte ofrecido constaba de gente con conocimientos en las reas de diseo, computacin y pedagoga. El cdigo debe poder ser probado: debe ser posible automatizar las pruebas unitarias y funcionales. Partamosde la idea de usar CakePHP como framework de desarrollo. Este nos ofreca 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 podran proveernos de la informacin necesaria para tomar decisiones de diseo importantes no pudieron asistir a las reuniones. Esto gener como resultado desmotivacin en los desarrolladores y estancamiento en la toma de decisiones. Dos aspectos importantes de esta, y cualquier otra, metodologa de desarrollo de software. Otro problema que caus estragos en nuestra planificacin fue relacionado al manejo de riesgos Riesgos altos Los primeros 3 meses fueron necesarios para implementar el primer mdulo de la aplicacin. Este mdulo es el encargado del presentacin de lecciones al estudiante. El estndar (SCORM) en el que se basaba ese mdulo es tan denso y complejo que fcilmente hubiese dado para un trabajo de grado completo. Luego nos enteraramos que, gracias a la falta de comunicacin descrita antes, que los profesores que van a usar el sistema no tienen contenidos en el formato adecuado. La versin de SCORM que usan (1.2) no coincide con la que hemos desarrollado. (En una empresa hubiesen rodado cabezas, ac queran que la dedicaramos otros 3 meses a implementar dicha versin _ ) Los dems puntos los hemos cumplido a cabalidad, el cdigo est en su mayora documentado y probado. Esto ltimo, las pruebas funcionales automatizadas, se han convertido en nuestra maya de seguridad invaluable.

Aspectos Interesantes de XP
La documentacin
XP no hace previsiones para la documentacin, sin embargo es lgico 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 documentacin es necesaria por una par de razones: al finalizar el proyecto sern otras personas quienes se encarguen del mantenimiento; y por otro lado, al ser un proyecto de grado es necesaria mucho ms la documentacin para convencer a los jurados

La propiedad compartida del cdigo

Extreme programming aboga porque ninguna parte del cdigo sea propiedad exclusiva de alguno de los desarrolladores, esto con la intensin de disminuir la necesidad de documentacin 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 da 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 cdigo y no en la chchara.

Conclusin
XP se adapta muy bien a un proyecto que requiere un cdigo de calidad, probado y confiable. No hace nfasis en la documentacin (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 planificacin semanal y la planificacin 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 metodologa. Es triste pasar 5 aos 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