Metodologías de desarrollo de software

Hola a todos de nuevo. Me he ausentado un periodo de tiempo debido a que estoy trabajando con el desarrollo de mi proyecto de tesis usando JSF (JavaServer Faces). En esta nueva entrada compartiré con ustedes algunos opiniones personales y algunas otras que son bastante compartidas en cuanto a las metodologías para el desarrollo de software.

En esta ocasión les platicaré un poco sobre la metodología XP (eXtremme Prograamming) pues igual en ella me apoyo para el desarrollo de mi proyecto. El interés se debe a que en pláticas con algunos compañeros existe la confusión si UML (Unified Modeling Language; Lenguaje Unificado de Modelado) es una metodología, y antes de empezar a platicarles un poco sobre XP me gustaría aclarar un poco esto en base a lecturas previas y razonamiento sobre qué es UML y qué se puede hacer con él.

En esencia, UML NO ES UNA METODOLOGIA, como su nombre lo indica, es un lenguaje para modelar las especificaciones de un sistema de desarrollo. Por tanto, UML es independiente de la metodología de desarollo, de ésta manera pueden trabajar con XP por ejemplo y apoyarse en las notaciones UML para los diagramas de clase, casos de uso, etc. UML NO ESPECIFICA COMO DESARROLLAR el software.

Ahora bien, les platicaré un poco sobre XP. eXtremme Programming es una metodología propuesta por Kent Beck y sus puntos esenciales son:

* Desarrollo del proyecto por parejas. Esto permite una retroalimentación y evita las situaciones donde entre tanta gente involucrada en el desarrollo es díficil tomar decisiones.
* Orientando todo a las pruebas, se realizan pruebas de unidad de los módulos.
* 40 horas de trabajo semanal, las horas extras mitigan los ánimos de los desarrolladores.
* Procura una homegenoidad y/o estandarización en el código.
* KISS = Keep it simple stupid!!. Mantener las cosas lo más simple posible es garantía de enredos lógicos de programación y una ardúa tarea de depuración. Lograr que funcionen las cosas como deben de funcionar y al nivel más fácil de comprender. Los "arreglos" (mejoras de eficiencia en el código, reducción del código innecesario, mayor separación entre clases de objetos, etc.) serán llevados a cabo una vez concluido el proyecto, o en su defecto, cada módulo del mismo.

De estos puntos apoyo firmemente la idea del trabajo en parejas. Ciertamente, 3, 4, 5, ..., n cerebros piensan más que 2 pero sin lugar a dudas, sin una buena organización y definición de las funciones que cada miembro del equipo de desarrollo tiene, a mediano plazo resultará en un caos donde todos piensan tener la razón y/o quieran implementar las cosas de acuerdo a sus criterios.

Un elemento MUY importante que deben de considerar es mantener una homegeneidad en el código. Me ha tocado ver aplicaciones en X herramienta (por mencionar una, Delphi) en donde los nombres de los objetos y componentes visuales de la aplicación son imprecisos. Qué más impreciso puede ser: TextEdit1 ¿? Los equipos de desarrollo deben de procurar siempre seguir lineamientos en cuanto a las nomenclaturas de objetos e inclusive en la estructura de directorios del proyecto, vaya, CADA COSA EN SU LUGAR.

Así por ejemplo, almacenen las imagenes en una carpeta imgs por ejemplo, las clases que pertenecen al modelo del problema dentro de un paquete específico, etc. Nomenclaturas "estándares" para los componentes visuales de la aplicación. Estas son prácticas y hábitos que aquel que se considere como programador debe tener muy en cuenta. Además, estas prácticas reducen el impacto "negativo" de agregar una nueva persona al equipo de desarrollo, dado que lo que esta persona debe de saber son esos lineamientos y con ello, no habrá tanto pierde.

Bueno, pues por el momento es todo. Los puntos mencionados sobre XP son los más relevantes, aunque difiero de la opinión de 40 horas a la semana, soy más de los que apoyan la idea e incluso haría más honor al nombre: ¡Programación Extrema!