Desarrollo de software: probando Extreme Programming
Desarrollar buen software depende no solo de la capacidad del programador, va mucho más allá: documentar, manejar y mitigar riesgos, planificar, etc. Pueden ser actividades tediosas cuando quieres ver resultados. Acá les presento un resumen de mi experiencia de 6 meses con 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
Recibe otros artículos como este automáticamente
Suscríbete vía RSS a aikon.com.ve ||
¿Qué es RSS?
Muy buena tu descripción de XP… con estas semanas sin trabajar en el proyecto, ya se me estaba olvidando lo que era
En cuanto a las empresas en Venezuela, sé de al menos una que si la sigue (No la mencionaré porque no me pagan por hacerles publicidad). Pero esta metodología resulta ser una diseñada por ellos mismos (basada en RUP y metodologías ágiles) que se adapta a sus procesos internos.
Realmente no creo que las empresas no tengan una metodología… Pienso que simplemente no la han formalizado, lo cual no quiere decir que sea una buena o mala metodología. A fin de cuentas, lo importante es que al utilizar cualquiera de ellas, de buenos resultados dentro del tiempo esperado.
Y para aportar mi grano de arena al tema de XP, diré lo que más me ha gustado del mismo:
Las pruebas unitarias.
Difícilmente podré seguir viviendo sin ellas.
Abril 7, 2008 // 1:09
Como dice José Lorenzo, la mayoría de las empresas usan sus propias metodologías, ya sea basada en los departamentos que puedan costear (generalmente hay uno de pruebas y documentación si usan una metodología “pesada”) o en el alcance de sus proyectos. De todas maneras, es bueno siempre conocer al menos de RUP porque sus plantillas y adapataciones de las mismas las consigues hasta en la sopa.
Del resto muy bueno el resumen, ayuda a comparar experiencias cuando uno quiera usar XP también.
Abril 7, 2008 // 12:40
Joaquín, me llegó el link a este post, te dejo algunos comentarios:
1) XP si establece algunos artefactos de documentación y son muy importantes, particularmente exige se documenten los requerimientos, el diseño y el código y establece algunos lineamientos para ello.
2) Cuando dices que no establecer documentación permite centrarse en lo importante no captas la esencia de la documentación que es el diseño o la especificación en sí necesaria para no dar pasos en falso y evitar retrabajo, a la vez que garantizar la mantenibilidad.
3) No generalices a las empresas venezolanas por un “he oído”. En Venezuela hay empresas con certificaciones de calidad: http://www.dbaccess.com.
4) No se trata de que aprenden cosas que a las empresas no les importa, se trata de que los nuevos profesionales deben impulsar las prácticas de calidad en las empresas, como buenos profesionales. En su defecto escoger correctamente las empresas en las que trabajan.
Abril 8, 2008 // 0:03
Hola Pedro, qué bueno que haya gente leyendome
En el punto 1 tienes razón, XP centra la mayor de su documentación en el diseño: tarjetas CRC y historias de usuarios. Pero no es una documentación formal al estilo RUP. ¿Me equivoco?
Desde este punto de vista, según entiendo, XP propone las pruebas unitarias y pruebas de aceptación (junto a las historias de usuario) como sustento del diseño.
En cuanto a lo último, aclaré que he oído que la “empresa promedio” es deficiente en el uso de metodologías. Por lo que dices, la que tu indicas parece sobresalir del promedio. No tengo otra manera de medir a las empresas en Venezuela porque no tengo la experiencia, lo siento.
Te pongo un ejemplo: el banco mercantil (me encanta este ejemplo). Ese banco dispone de un sistema de banca en línea, pero el número de quejas que he tenido han sido numerosas. Desde usabilidad hasta fallas específicas a un SO: sólo ocurren si usas firefox en linux.
En cuanto a tu punto 4, no le puedes achacar el problema a los recién graduados. Sólo en mi experiencia dentro de la Universidad te puedo decir que he visto muchos ejemplos de sistemas llenos de fallas de seguridad: SQL injection, XSS, etc. ¿De quién es la culpa? de los estudiantes ignorantes (sin ánimos de ofender) o de una falla en el seguimiento de los profesores.
En cuanto a lo de “En su defecto escoger correctamente las empresas en las que trabajan.” Me cuesta imaginar a un recién graduado interrumpiendo a su entrevistador para pedirle que demuestre que es una empresa digna de tenerlo entre sus empleados.
Saludos
Abril 8, 2008 // 21:20
Un saludo!!
Yo soy estudiante de la UNE sede centro y también estoy en una situación parecida a la tuya; mi tutor me habló de XP y me gustó mucho porque de verdad que me molesta enormemente la parte de “gerencia”. Al menos ahorita, ya cuando tenga mis chamos sí me daran ganas de formar peo. Mientras tanto, intento ir un poco más allá y ser cada día menos ignorante y un poco más “geek” que el resto de mis compañeros.
En mi caso, es un desarrollo tecnológico y no un proyecto factible como trabajo de grado. Es decir, debo experimentar más mientras voy conociendo.
De verdad que me gustó tu resúmen de la metodología y con tu permiso, voy a hacer mención a tu website en mi trabajo de grado.
Con respecto a la metodología de las empresas; no conozco mucho con respecto a ello. Lo único que sí me he fijado, es que en un video de Google; una de las desarrolladoras indica que en su antígua empresa las fases de planificación y análisis eran interminables, mientras que en Google las cosas simplemente suceden. En este sentido, puedo suponer que aquellas organizaciones o empresas destinadas a “experimentos” en innovación, utilizan metodologías de desarrollo ágil. De todos modos no estaría de más preguntar a la gente de Mozilla, Debian o inclusive Ubuntu, qué metodología usan (no se me había ocurrido hasta ahora jeje). Por desarrollo web, pudiesemos preguntar en code.google.com o el sitio de Yahoo! para desarrolladores.
Pudiese seguir hablando de lo aburridas que me parecen las clases de metodología de mi univ (puesto que no mencionan nada de ágil, sino se van por el enfoque clásico, en los Project Charts, etc etc etc)pero X… te deseo mucho éxito en tu proyecto y aprovecho la oportunidad de preguntarte si existe algún tipo de club de programación al que pertenezcas o conozcas y que pueda unirme para poder divertirme con personas con mis mismos intereses. En mi univ la mayoría quiere gerenciar sin ser un gurú primero =(
Un saludo.
Abril 9, 2008 // 8:16
Hola Jorge,
Es verdad, hay muchas implementaciones exitosas de metodologías ágiles en organizaciones de alta línea. Se que por ejemplo, los creadores de Basecamp (de donde nació Rails) son defensores de las metodogías ágiles y a ellos no les va nada mal.
Sin embargo, un poco queriendo estar con Dios y con el diablo, también hay muchas implementaciones de metodologías tradicionales como RUP que han sido exitosas (podría decir que IBM es líder en esta área).
Pero mi objeción era explícitamente con las empresas en venezolanas promedio. Es decir, no estaba hablando de la Mozilla Foundation ni de Canonical.
No hay problemas con que hagas referencia a este artículo en tu trabajo (claro que me pones a pensar que debería desarrollarlo más :P).
Yo personalmente estoy metido en la comunidad en español de CakePHP (cuyo sitio está caído desde hace unos días :S). Las relaciones que tengo con desarrolladores son más que todo con compañeros de la universidad y algunos desarrolladores de que trabajan con RoR en Venezuela (http://www.valhallaproject.com/).
Abril 9, 2008 // 9:55
[...] graduados, haganle caso a pedro: escojan bién en donde quieren trabajar. Yo por mi parte, no quiero trabajar en la [...]
Abril 13, 2008 // 23:09