Archivo Mensual de Marzo, 2006

A pesar de que me voy durmiendo por las esquinas gracias a unas maravillosas pastillas antialérgicas que me tomo por una gripe (WTF?), voy a intentar escribir algo. En este caso, me llaman la antención las clases de videoconferencia que estoy recibiendo en mi facultad. Se dan en un aula equipada con un proyector, una máquina con un software específico y una webcam de bastantes buenas prestaciones. La mecánica consiste en un servidor VNC que controla el profesor, y que vemos todos, y una serie de cámaras web repartidas en cada aula donde se reciben las clases. El servidor VNC sirve para que el escritorio de la máquina donde se ponen las transparencias sea visto por las máquinas conectadas al proyector de cada aula donde hay alumnos. Las cámaras web sirven para que nos veamos todos ;-). En las máquinas conectadas a los proyectores se puede ver un sistema basado en Unix en la que hay unas cuantas pantallitas que el profesor aumenta a su antojo. Hay tantas pantallitas como cámaras y una adicional donde se ven las transparencias. Así puedes ver al profesor, los alumnos de otras facultades y las transparencias, todo en pequeñito menos lo que elija el profesor en cada momento. Con esta foto os podeis hacer una idea:

En esta otra, se nos puede ver disfrutanto a tope de la cara del profesor:

Además hay unos altavoces, naturalmente, por donde oimos al profesor hablar. Además en cada aula hay un micrófono por si algún alumno quiere preguntar algo (cosa que nunca ha ocurrido y presiento que no va a ocurrir x-D). Por cierto que la máquina Unix creo que es un Linux, concretamente Suse, ya que usa Yast. Sé que Yast es libre y se puede usar en cualquier otro sistema operativo pero bueno. Lo mejor del tema es que puedes estar a tu aire en clase y no se nota en absoluto (incluso el que se sienta a mi lado se pone siempre a sobar, aunque el otro día el profe hizo una ronda de preguntas con el consiguiente zoom en cada aula y le pilló, con la única consecuencia de unas risas por parte de todos, incluido el profesor y el alumno dormido). Lo malo es que a las clases les falta interactividad, ya que es un coñazo preguntar porque te tiene que pasar el micro el operador de tu aula (¿se me olvidó comentarlo? en cada aula hay un operador manejando todo el invento). Pero bueno, creo que para dar asignaturas de libre elección está muy bien. Me recuerda un poco al capítulo de los Simpsons en que aparece el futuro, y las clases del colegio son por videoconferencia en plan nacional, patrocinadas por Pepsi (“Si tenemos tres Pepsis y nos bebemos una.. ¿Cuántas Pepsis nos quedan? A ver, la niña del colegio de Kansas”). ¿Será esto el futuro?
Por cierto, que estas clases son impartidas por el Gate de la UPM. Y ahora me voy a dormir un poquito encima del portatil…

Technorati Tags: videoconferencia facultad UPM

Ya que me tengo que documentar sobre extreme programming o programación extrema para una asignatura de la facultad, qué mejor que recoger mis conclusiones aquí. Así que ahí va lo que he recabado:

Programación extrema

¿Qué es?

La programación extrema es una metodología de ingeniería de software para el desarrollo del mismo, que hace énfasis en los siguientes aspectos: satisfacción del cliente y trabajo en equipo.

¿Cuándo se debe usar?

La programación extrema fue creada pensando en las siguientes circunstancias:
• Proyectos en los que los requisitos tienen altas probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente no tiene claro lo que quiere, o porque el cambio de requisitos está ligado al dominio del problema a resolver).
• Proyectos con alto riesgo (por ejemplo, proyectos con una fecha de entrega que es indispensable cumplir, o proyectos totalmente novedosos para la industria).
• Proyectos con un grupo pequeño de programadores (entre 2 y 12), aunque el equipo completo sea bastante más extenso (incluye a jefes de equipo y representantes de clientes).

Aspectos destacados

Los aspectos que habitualmente se destacan cuando se habla de programación extrema son los siguientes:
• Desarrollo basado en iteraciones incrementales, usando user stories como guía.
• Muchos lanzamientos con pequeños cambios
• Simplicidad.
• Refactorización (reescritura de código/diseño para mejorar la legibilidad y/o comprensión del mismo sin cambiar el significado).
• Constante interacción con el cliente durante todo el desarrollo (user stories, dudas durante el desarrollo, pruebas de aceptación…).
• Codificación en parejas.
• Propiedad colectiva de todo el código
• Pruebas unitarias codificadas antes que el propio código, que deben ser pasadas antes del lanzamiendo del mismo
• Pruebas de integración e integración del código realizadas secuencialmente y de forma frecuente
• Pruebas de aceptación realizadas frecuentemente

¿Qué prácticas engloba?

La programación extrema está compuesta por una serie de prácticas y actividades. En la imagen podemos ver el mapa de un proyecto que usa esta metodología:

Las prácticas que componen la programación extrema se pueden agrupar en cuatro grandes bloques: plan, diseño, codificación y pruebas. Sin embargo, estos bloques no deben realizarse en orden, si no que cada uno consta de una serie de actividades, y todas ellas se irán realizando de manera evolutiva.

Las actividades son las siguientes:
• Planificacion
  • Se escriben user stories, cuya idea principal es describir un caso de uso en dos o tres líneas con terminología del cliente (de hecho, se supone que deben ser escritos por el mismo), de tal manera que se creen test de aceptación para el user storie y permita hacer una estimación de tiempo de desarrollo del mismo.
  • Se crea un plan de lanzamiento (release planning), que debe servir para crear un calendario que todos puedan cumplir y en cuyo desarrollo hayn participado todas las personas involucradas en el proyecto. Se usará como base los user stories, participando el cliente en la elección de los que se desarrollarán, y según las estimaciones de tiempo de los mismos se crearán las iteraciones del proyecto.
  • Se hacen pequeños lanzamientos con mucha frecuencia.
  • El desarrollo se divide en iteraciones, cada una de las cuales comienza con un plan de iteración para el que se eligen las user stories a desarrollar y las tareas de desarrollo.
  • Las personas cambian de área para evitar cuellos de botella y fomentar la propiedad colectiva del código.
  • Se cambia el proceso lo que sea necesario para adaptarlo a tu proyecto.
• Diseño
  • Se eligen los diseños más simples que funcionen.
  • Se elige una metáfora del sistema para que el nombrado de clases, etcétera, siga una misma línea, facilitando la reutilización y la comprensión del código.
  • Se escriben tarjetas CRC (class-responsabilities-collaboration) de clase-responsabilidades-colaboración para cada objeto, que permiten abstraerse el pensamiento estructurado y que el equipo de desarrollo al completo participe en el diseño.
  • Se “refactoriza sin piedad”. Basicamente, consiste en no tener miedo de cambiar un diseño o eliminar un código que ya no sirve, o al menos que ya no es claramente la mejor solución.
• Codificación
  • El cliente está siempre disponible, a ser posible cara a cara. La idea es que forme parte del equipo de desarrollo, y esté presente en todas las fases de XP (escribe los user stories con la ayuda de los desarrolladores, participa en la elección de los que entrarán en el plan de lanzamientos, prueba pequeños lanzamientos, participa en las pruebas de funcionalidad…). La idea es usar el tiempo del cliente para estas tareas en vez de para que cree una detalladísima especificación de requisitos, y evitar la entrega de un producto peor que le hará perder tiempo.
  • El código se ajustará a unos estándares de codificación, asegurando la consistencia y facilitando la comprensión y refactorización del código.
  • Las pruebas unitarias se codifican antes que el código en sí, haciéndo que la codificación de este último sea más rápida, y que cuando se afronte la misma se tenga más claro qué objetivos tiene que cumplir lo que se va a codificar.
  • La programación del código se realizará en parejas, para aumentar la calidad del mismo. En cada momento, sólo habrá una pareja de programadores integrando código.
  • Se integra código y se lanza dicha integración de manera frecuente, evitando divergencias en el desarrollo y permitiendo que todo el mundo trabaje con la última versión del desarrollo. De esta manera, se evitará pasar grandes periodos de tiempo integrando el código al final del desarrollo, ya que las incompatibilidades habrán sido detectadas enseguida.
  • Se usa la propiedad colectiva del código, lo que se traduce en que cualquier programador puede cambiar cualquier parte del código. El objetivo es fomentar la contribución de ideas por parte de todo el equipo de desarrollo
  • Se deja la optimización para el final
  • No se hacen horas extra de trabajo
• Pruebas
  • Todo el código debe tener pruebas unitarias, y debe pasarlas antes de ser lanzado.
  • Cuando se encuentra un error de codificación o bug, se desarrollan pruebas para evitar volver a caer en el mismo.
  • Se realizan pruebas de aceptación frecuentemente, publicando los resultados de las mismas. Estas pruebas son generadas a partir de las user stories elegidas para la iteración, y son “pruebas de caja negra”, en las que el cliente verifica el correcto funcionamiento de lo que se está probando. Cuando se pasa la prueba de aceptación, se considera que el correspondiente user storie se ha completado.

.

Fuentes utilizadas para obtener la información:
• Extreme Programming: A Gentle Introduction
• Extreme Programming
• Extreme Programming practices
• Programación Extrema
• Acepta el cambio

Technorati Tags: xp extreme programming agile development d-link