Monthly Archives: diciembre 2008

Servidor de hora en GNU/Linux

En las redes internas de la mayoría de empresas, se sucede la necesidad, muchas veces, de tener sincronización horaria en las máquinas para mejorar el rendimiento y la calidad de los datos a almacenar, de cara  a anotaciones y lanzamiento de tareas programadas.

La sincronización horaria es completamente posible de llevar, simplemente, instalando un servidor de hora NTP dentro de nuestra red, para que nos haga de servidor de sincronización.

En España, generalmente, se suele usar hora.rediris.es como servidor de hora, puesto que es un sistema formado por varios servidores, algunos de ellos con el uso de relojes GPS.

Muchos sistemas ya tienen el servidor ntpd instalado. En otros habrá que hacer la instalación, ya sea del paquete con nombre: ntp, ntp-server, ntpd…

El archivo de configuración, normalmente: /etc/ntp.conf; debería de tener un contenido parecido a este:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
server hora.rediris.es
 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
restrict 127.0.0.1
restrict ::1
 
restrict 192.168.123.0  mask  255.255.255.0 notrust
 
broadcast 192.168.123.255
disable auth
broadcastclient

Con esto, el servidor de hora recién instalado, servirá como repetidor para los equipos de la red interna. En caso de tener un solo equipo, en ese caso es mejor tomar el archivo de /etc/ntp.conf y modificarlo levemente para hacer que el sistema fucnione, y nada más.

Espero que os sirva de ayuda.

Gráfico Burndown (más de Scrum)

En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en otro artículo, volvemos a la carga.

Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.

Para esto, hemos hecho uso de un gráfico burndown.

Burndown

El gráfico de burndown se caracteriza por tener en su eje X el tiempo, solo los días laborables que se vayan a trabajar (sino el gráfico saldría algo extraño) y en el eje Y los puntos de tarea que se van a completar en el sprint.

Pila de Producto, Pila de Sprint y Puntos de Tarea

La pila de producto es la cantidad de características que nos piden que incorporemos a un producto software. Estas tareas son funcionales, generalmente.

La pila de sprint es una primera criba que se toma de la lista total de características, a modo de poder desarrollar una versión 0.1. Esto se realiza para que, al final del sprint, que no debe de ser un período de tiempo muy prolongado, se tenga algo palpable para el cliente (o dueño de producto) y pueda replantearse el resto de peticiones en función de lo que está viendo.

Los puntos de tarea son, en sí, la dificultad y el tiempo que se puede llegar a invertir en la tarea en sí. Es una unidad de medida relativa que no implica en sí tiempo, pero está bastante ligada a él.

Por ejemplo, si hacer un alta de cliente implica una sola consulta a base de datos y retornar el valor de resultado, esa tarea podemos estimar que tiene 1 punto. El caso de la modificación, implicaría tomar los datos, mostrarlos, tomar los cambios y hacerlos efectivos. Esa tarea se puede estimar en 2 ó 3 puntos. Ahora, hacer el balance de todos los clientes dados de alta y los ingresos que tuvieron en el año pasado, todo ello paginado… puede ser una tarea con una puntuación de 10, relativamente con respecto a las anteriores.

Datos en el gráfico de Burndown

El gráfico se traza para cada sprint. Se estima el tiempo que se puede o quiere tardar en realizar una serie de características. Al comenzar, el primer sprint, no se sabe la velocidad del grupo, realmente, por lo que se puede comenzar sin estimación precisa. Esto se va ajustando con el tiempo.

En principio, se comienza el trabajo, se comienzan a realizar tareas.

Al día siguiente, se hace revisión de las tareas acabadas y se apunta en el gráfico el día anterior y los puntos que se avanzó. El gráfico, al crearlo, se suele trazar una línea que cubre la diagonal de la esquina superior izquierda hasta la esquina inferior derecha. Si los puntos van cayendo sobre la línea, ya sabemos lo que se va a ir tardando en realizar el proyecto.

En caso de que los puntos vayan cayendo en el rectángulo superior, eso será indicio de que hay que eliminar historias. Si se mantiene siempre en el bloque inferior, se pueden agregar más historias.

Conclusiones

Después de un par de jornadas, se puede ver la velocidad del equipo y se tiene una percepción real de lo que se hace, lo que se tarda y las tareas que hay que ir acelerando o postergando para llegar a la fecha, sin necesidad de estar cerca de la fecha de entrega. Es, sin duda, uno de los mejores métodos de estimación de tiempos a corto plazo… para el sprint.

Hablaré en los próximos artículos sobre las estimaciones a largo plazo, gestión de hitos y más sobre la pila de producto.

Algoritmos heurísticos y algoritmos voraces

Realizando una práctica de la asignatura de programación 3, de la Universidad Nacional de Educación a Distancia (UNED), he podido comprobar la diferencia, en coste computacional y rendimiento, que supone realizar un algoritmo mediante un algoritmo heurístico, como puede ser el de vuelta atrás (backtracking) y un algoritmo voraz (reducción).

El problema consiste en resolver, dar las posibles soluciones, de un tablero de shikaku. Se trata de un juego japonés que consiste en resolver un tablero, con unos números, mediante el uso de rectángulos que tengan un área igual al número que encierran, no pudiendo solaparse. Es decir, un número 4 en el tablero, puede formar rectángulos de 1×4, 2×2 y 4×1, y mientras tenga al número en cualquiera de las casillas que ocupa, es una combinación correcta. Un ejemplo gráfico:

Tablero de Shikaku

Al principio, la solución más fácil, consiste en tomar todas las posibles combinaciones de los rectángulos, e ir probando combinaciones hasta dar con todas las combinaciones de solución. El problema, es que el costo computacional de la solución es muy alto cuantos más números haya y, sobre todo, cuantos más números con muchas combinaciones existan. Esto supone un coste exponencial e imposible de calcular en muchos casos.

Una solución, es el uso de un algoritmo voraz de reducción, que elimine muchas de las combinaciones posibles, antes de la aplicación de la solución. En sí no es complicado, ya que solo consta de tomar una de las combinaciones y comprobar si es posible su aplicación en el tablero, respecto a los números que hay colocados y que no se salga del propio tablero. Esto reduce mucho las probabilidades, pero aún no lo suficiente.

Otra reducción que se puede llevar a cabo es, si una combinación no es posible de encajarla en el tablero con ninguna de las combinaciones posibles de otro número, entonces esa combinación no es posible. Se puede eliminar.

Estas reducciones suelen ser rápidas, puesto que su coste computacional es muy bajo, y realizan una criba de elementos muy alta, de forma que rebajan mucho el coste que supondría ejecutar el algoritmo de vuelta atrás sin reducciones.

En la práctica, programado en Java y con tableros de la página de Nikoli, he comprobado que no se tarda más de 6 segundos en resolver los tableros más complejos, mientras que, sin reducciones, podría tardarse horas.

Por lo tanto, la elección del algoritmo sí importa.

Scrum y XP en la práctica

Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro… bueno, pues ese futuro ya es presente :-)

La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.

Scrum

En la imagen se puede apreciar el cómo quedó la pared de la oficina cuando comenzamos la experiencia. Comento un poco como lo hicimos, aunque la verdad, fue algo muy básico.

Usando Scrum

Lo primero que hicimos fue localizar los grandes grupos a desarrollar. En este caso, lo que había que desarrollar, principalmente, era una interfaz web para un cliente específico. Así que nos encargamos de convertir, cada parte importante de la interfaz en un bloque de tareas.

Dentro de cada uno de los bloques (alrededor), se agrupaban las tareas que había que realizar para completar ese bloque.

Los papeles se ordenan de arriba a abajo, según su prioridad, de más alta a más baja, respectivamente. Todos ellos, a su vez, se colocan en la parte izquierda del marco que se vaya a emplear para el proyecto de scrum. La idea es que, cuando una tarea se esté realizando, se pase a una zona central y, cuando haya sido terminada, se pase a la zona derecha. Nosotros usamos la separación física existente entre vidrio y vidrio, considerando la parte central justo la línea de unión entre ambos.

¿En qué beneficia?, pues básicamente en que cuando una tarea se finaliza, todos ven que se ha finalizado y que, cuando alguien no sabe que hacer, se puede levantar y mirar las tareas que hay por realizar.

Cabe señalar dos aspectos muy importantes y a tener muy en cuenta:

  • Hay que definir, y muy bien, lo que significa terminado. Ya que alguien puede considerar una tarea terminada cuando ha terminado de codificarla (sin probarla), mientras que quien la solicita, considera que se termina cuando ya no se debe de tocar más, ha sido comprobada, validada y está lista para producción.
  • El scrum master es la única persona que debe de mover los papeles, así como agregar nuevos o eliminar, según se dé el caso. Esto es para controlar que, realmente, se ha terminado, como se decía antes, la tarea. Además, el hecho de agregar/eliminar tareas es una actividad muy sensible, que no se debe de dejar a todos, puesto que sino, podrían sucederse situaciones indeseables.

Y un poquito de Xtreme programming

Hay otra práctica que realizamos ese mismo día, y es la del empleo del Xtreme Programming, otra vez, a nivel muy básico. En esencia, se trataba de realizar la programación más costosa (o la que se hacía ya con sueño :-P ) entre dos personas, una haciendo de piloto (al teclado) y otra haciendo de navegante (cabeza pensante).

Los beneficios de esta técnica fueron la velocidad a la hora de desarrollar ciertas partes, puesto que la presión que ejerce el navegante al piloto y la dinámica que se crea, hace que el desarrollo carezca de partes de inactividad y cada tarea se acabe antes.

Algunas conclusiones

Puedo decir que la valoración acerca de estas técnicas, en sus inicios dentro de la empresa, han sido muy positivas, llegándose a conseguir los objetivos deseados, por lo que seguiremos empleando dichas técnicas, así como implementando cada una de ellas de forma más completa para ganar en eficiencia y conseguir que los proyectos se puedan medir de forma más precisa en el tiempo.

Pero de eso ya contaré más adelante… :-)