Lo realmente util que son las cosas

En el desarrollo de proyectos de software hay muchas ideas de como deberian llevarse las cosas. Se pueden tomar muchas medidas:

- Reuniones todos los dias.

- Diseño, discrusion y rediseño.

- El jefe da de alta una tarea en algun sistema de gestion de tareas y un programador tiene que ir completando las horas con lo que haciendo.

- Se hace integracion continua.

- Se tiene un equipo de integracion y estandar de calidad.

-Etc..

Todas son buenas ideas y todas pueden llevar al exito en la gestión de equipo de desarrollo de software. Si alguien aplica todo esto (o algunas cosas) y llega al exito genial. Pero se puede aplicar esto (y mas cosas) y no tener exito. 

¿Que es el exito? el exito es conseguir los objetivos. Si el objetivo principal es tener lo que el cliente desea, el producto, en los plazos deseados pues se ha tenido exito. Si se tiene antes entonces has tenido mas exito. Si se tiene mas tarde has tenido menos existo. Si no lo tienes ha tiempo entoces no has tenido exito (has fallado).

Todas estas medidas (todas estas cosas) no se pueden aplicar solo porque sean buenas. Hay que tener siempre en cuenta las características de nuestro grupo de desarrollo:

- Si los programadores no estan contentos en generla (ganan poco dinero o algo asi) aprovecharan cualquier oportunidad en la que esten todos para quejarse. Por lo que una reunion no es una buena idea.

- Si los programadores no tienen iniciativa entonces no querran discutir un diseño. Quieren un diseño.

- Si el sistema de gestion no es dinamico y lleva poco tiempo usarlo entonces los programadores pensaran que es una perdida de tiempo o si los jefes dan de alta tareas en sistema de gestion y no son reflejos de lo que se esta haciendo en realidad entonces todos dejaran de usar la herramienta.

- Si no se usa la integracion continua para usar los datos que proporciona entonces al final se convierte en un mantenimiento que lleva mucho tiempo.

-Etc...

Hay que "leer al grupo". Habran cosas que se puedan implantar y funcionen. Pero habra otras donde habra que adaptarlas al grupo o no usarlas.

El conocimiento del negocio de un programador

Cuando se desarrolla una aplicación de tamaño medio/grande se produce muchas veces la siguiente situación:

1. Se dividen las tareas entre los programadores
2. Se terminan las tareas. Parece que esta todo
3. Se empieza a probar y el jefe se da con un fallo muy claro.
4. ...

¿Como puede ser que ningun programador se haya dado cuenta? El jefe se da cuenta que la realidad es que los programadores no tienen un conocimiento del negocio para darse cuenta de ese fallo, pero como es posible? la mayoria de programadores suelen llevar tanto tiempo como el jefe en el proyecto. ¿Como es posible que no conozcan mas el negocio? La respuesta es que gran parte del trabajo del jefe consiste en aprende el negocio y como la aplicación da respuesta a las necesidades del negocio mientras que toda la jornada laboral de un programador consiste en programar. Un programador no puedes saber tanto de negocio, necesidades de cliente, etc.. como un jefe ya que NO GASTA UN TIEMPO SIGNIFICATIVO EN ELLO por lo que es lógico que no tenga ese conocimiento.

Ahora lo normal es pensar, pues deberia tenerlo. Esto hay que pensarlo bien porque para que lo tenga hay que dedicar tiempo (que no podrá usar en programar) y ademas alguien (un jefe) tendrá que perder su tiempo en explciarlo.

¿Que se puede hacer? Cada caso requerirá su propia solución. A veces merecerá la pena que programador tenga el conocimiento y otras que sea simplemente el que fabrica las piezas y son otros los que encajan esas piezas.

La percepción exterior

Durante el desarrollo de una aplicación y a la hora de hacer entregas hay un factor que nunca se tiene en cuenta pero que es muy importante: La percepción exterior que da la aplicación. Da igual que "el interior" (Core, lo que no se ve pero es realmente complicado) este perfecto si la percepción que da la aplicación al ejecutarla causa sensaciones negativas como:

• Va muy lenta
• Ciertas partes no funcionan
• Hay casos de prueba que funcionan y otros no
• Etc...

provocará rechazo por parte del usuario final. Por ejemplo, un equipo desarrolla una aplicación web para que los usuarios puedan  darse de alta en un censo de un pueblo. La aplicación es simple y compleja. Simple porque de cara al usuario es solo un formulario de 10 campos que se rellenan y se pulsa un botón de enviar. Compleja porque en core usa tecnologias que hacen mas facil la navegación, se conecta con un web services que verifica la firma, hace una validacion con 2 bases de datos, optimiza busquedas para validacion de .... y mas cosas. Todo esto último se ha conseguido pero el dia de probar en producción se produce el gran problema, el responsable del cliente dice que toda (no solo la interfaz) es un desastre porque hay un campo donde no se pueden poner mayusculas.

Si llevas tiempo en el desarrollo de software te sonará seguro:"Esta aplicación en una mierda porque no deja poner mayusculas en este campo" y el programador piensa: " pero si eso es una tonteria, lo del web services era lo complejo".

Como evitar esto? Es una tonteria o es algo que puede hacer fracasar un proyecto?

En estos casos, todo el mundo tiene razon y todo el mundo esta equivocado.

• La interfaz al usuario hay que probarla hasta mas no poder. Es importante eliminar cualquier fallo en el que el usuario pueda decir:"esto es de sentido común".
• Si el principal objetivo de un programador es la interfaz entonces  las partes mas complicadas no estarán implementadas y si que la aplicación no valdrá para nada.

La mejor opción es poner una capa intermedia entre el desarrollo y el cliente:

• Un departamento de pruebas.
• Comerciales que deduzcan de forma lo mas exacta posible que es lo que quiere el cliente.
• Etc...

En cualquier caso, suponer que es lo "de sentido común" (o básico) para el cliente es un error. Los clientes suelen saber lo que quieren durante la marcha. Cuando ven algo sabe si les gusta o no. Lo mejor es planificar el desarrollo para que los cambios en la interfaz te afecten lo menos posible.

  

La oposicion al cambio

En el mundo del software (y supongo que de todos los trabajos en general) la mayoria de personas son reacias al cambio. Si es un subordinado te dira cosas como:"esto no lo comprendo", "asi no se como trabajar", "yo creo que asi es peor", etc... y si es un jefe se reira de ti o te tratara de forma condescendiente.

Ojo, el cambio no siempre es bueno. O si? es dificil determinarlo. Por lo general, se puede tomar como axioma que el cambio es bueno cuando se puede demostrar que algo no funciona. Pero cambiar algo que funciona... es peligroso.

Todo el mundo que ha trabajo en el mundo del software sabe que una idea que ha tenido siempre ha tenido mas retractores que apoyos (sobre todo en los superiores). La claves para conseguir cambio es:

- Tamaño. Si un cambio es muy grande lo tienes que dividir. Y esos cambios (que han de ser pequeños) han de conseguir una victoria lo mas rapido posible. Como no se muestre algun indicio de valor al cambio enseguida se echara para atras y restara credibilidad a los impulsores.

- Apoyos. Hay que buscar apoyos. De jefes, de subordinados, de iguales... de los que sean pero los cambios son como las politicas. Para el exito de un cambio es mas importante que parezca bueno que realmente sea bueno el cambio.

- Fuerza de voluntad. No hay que desanimarse porque el cambio no parezca servir. Y si realmente no es bueno eso no significa que los impulsores del cambio no puedan tener buenas ideas en el futuro.

- Presentacion. Este es posiblemente la clave mas importante para que un cambio tenga exito. Hay que presentar la idea bien y tiene que ser entendible para el publico al que va orientado.

Recordar las cosas

Cuando un lider del proyecto quiere comunicar un hecho de importancia que quiere que todo el equipo de desarrollo tenga en cuenta (por ejemplo; la fecha de entrega de la ultima version es el dia 30 del mes que viene)  realiza una accion para comunicarlo. Esta acción siempre la piensa como algo definitiva. Puede ser algo registrable (como mandar un correo con importancia alta) o algo mas grafico (como una reunion con todo el equipo). El lider piensa que, con esta acción, todo el equipo conoce ya el hecho de importancia, lo tendra en cuenta siempre y le dara el mismo valor que él. NADA MAS LEJOS DE LA REALIDAD.

El hecho que el lider ha expuesto es importante para el lider porque esta alineado directamente con su trabajo y es un hito para él pero si los miembros del equipo no tienen este hecho importante como un hito directo en su trabajo diario entonces tenderan a olvidarlo o no lo olvidaran pero no le daran el mismo valor al hecho importante que le da el lider (siguiendo con el ejemplo de la fecha de entrega, los programadores no le daran importancia a la fecha ya que los programadores solo ven importantes sus hitos, es decir la tarea de una semana que les ha tocado y como mucho la tarea siguiente pero no les importa tanto que el dia 30 se tenga que entregar la version).

La unica forma, real, de solucionar esto es tener reuniones periodicas con el equipo y comentar las tareas individuales de cada uno alineandolas con el hecho importante. Pero ojo, periodicas porque sino olvidaran el hecho importante.

Falta de horizonte

Un gran problema que tienen los programadores, ya sean jóvenes o viejos, es la falta de un objetivo. Es es una característica normal, no solo en programadores, el hecho de no tener muy claro que se quiere o si tenerlo pero no saber como conseguirlo y dejar pasar el tiempo hasta que surge algo que nos hace ponernos en el camino correcto.

Pero en esa espera pasan cosas curiosas y contradictorias; por ejemplo, todos sabemos que en un desarrollo, sobre todo si es largo, la programación se vuelve cíclica (desarrollos nuevos-pruebas-incidencias-desarrollos nuevos-pruebas-etc…) y esto hace que “siempre sea todo los mismo” (misma tecnología, mismos problemas, mismos procedimientos, etc..). Por lógica, cualquier cosa que se salga de la rutina debería ser bien recibida, al menos de primeras. Pues la experiencia me ha demostrado que no. Los programadores no quieren cosas nuevas, prefieren seguir en el ciclo que se ha convertido la programación del proyecto.

Los test unitarios deben ser en ejecución.

Los test unitarios, por deficion, son trozos de codigo que se ejecutan para probar otras partes de codigo. Estas partes se prueban de forma aislada, sin tener en cuenta la integracion con otras partes del sistema.

Este planteamiento es correcto pero tal y como estan pensados los frameworks de hoy en dia (Junit, testGN, etc..) los trozos de codigo deben de ser demasiado simples. Siempre que ves un ejemplo tienes algo como esto:

Probar la funciona

int suma (int a, int b){
             return a +b;
}

Y ejemplo te indica con todo lujo de detalles como probar esta funcion pero que pasa si:

• La funcion depende de base de datos.
• La funcion depende de un web services al que se conecta.
• La funcion depende de una cache de datos que solo se inicializa en casos muy concretos.
• Etc (y este etc es muy largo)

Cualquier programador que haya participado en el desarrollo de una aplicación medio compleja sabe que la unica manera fiable de probar un procedimiento es en ejecucion. Por lo que LOS TEST UNITARIOS SE DEBERIAN LANZAR EN EJECUCIÓN.

Hay framewoks como MOQ que se hacercan a esta visión de las pruebas unitarias. La idea es buena pero simular algo no es lo mismo que verlo funcionar. Ademas, los test suelen ser costosos de programar y la mayoria de tiempo de desarrollo se gasta en preparar el MOQ y lo que deberia llevarse mas tiempo de desarrollo es probar la propia logica del metodo que quieres probar.

Lo que se debe hacer para lanzar test unitarios es ejecutar la aplicación tal cual. Y una vez que este arrancada que una parte se ejecute en ultimo lugar y lance las pruebas de los metodos. De metodos de verdad, es decir no es lo mismo hacer la prueba de metodo "suma(int a, int b)" que el metodo "altaAlumno (Alumno alumno, Clase clase, Centro centro)" <-- Creo que se deduce facil la diferencia en la complejidad.

Plantear el desarrollo de una tarea

En el dia a dia de un proyecto (de desarrollo de una aplicación informática) lo mas común es afrontar la implementación de una tarea.

       ej) Se esta implementando el proyecto "Portal de gestión de alumnos" y se quiere empezar con la tarea "Pagina de alta de alumnos". Una vez recogidos los requerimientos, hecha la planificación. se ha hecho el diseño, etc... (ya se tienen todos los pasos previos al desarrollo) ya podemos empezar con el desarrollo. No mas normal es tener una planificación como la siguiente:

Una tarea se divide en subtareas que se pueden o no solapar entre si. En las solapadas podemos poner a varios programadores (uno con cada tarea ques pueda solapar) y asi optimizar el tiempo de desarrollo de la tarea total.

El planificador de la tarea es el que ha decidido que la subtarea 1 y la 2 no se pueden solapar. Esta decision hay que respetarla. Pero se puede paralelizar. La respuesta es si.

Normalemente esta subtarea se asigna a un solo programdor (el principal motivo de asignar a un solo programador es que el tiempo de coordinacion y comunicacion entre programadores perjudicaria demasiado al desarrollo) pero una subtarea que tenga el suficiente tamaño (requiere tirar muchas lineas de codigo en varios ficheros disintos y en varios proyectos de codigo distintos) se puede dividir en algun momento del desarrollo (si nos hace falta) si el desarrollo se lleva a cabo de la siguiente manera:

                      ej) La subtarea "Gestion de BD de alumnos" de la tarea "Pagina de alta de alumnas" se desarrolla siguiendo estos pasos:

• DAO de alumnos
• DAO de cursos
• Negocio de alumnos
• Vista de alta

El programador empieza por "DAO de alumnos". ¿Como empezar? La forma correcta no empezar de cualquier manera si no definiendo el estilo que va seguir toda la implementación. Si el DAO tiene cuatro funciones mejor es definir un estilo de programacion que van a seguir las cuatro antes de empezar a picar de cualquier manera. Si se hace asi, en realidad no se tienen que picar las cuatro funciones antes de seguir con el siguiente paso, basta con picar una y el resto lo podria hacer otro programador si se da el caso que no se cumple con la planificación. El programador siempre podrá pasar al siguiente paso de la subtarea ya que otro programador podra terminar el paso anterior por él. Esto es lo que se puede llamar "empezar picando la viga":

Al picar la parte correspondiente de la viga de una subtarea, el programador ya puede pasar a la siguiente subtarea ya que los trozos que faltan los puede picar otro programador

Ojo, la parte de la viga no solo debe ser el ejemplo para implementar el resto de la subtarea. Ademas tiene que ser una parte que permita al programador pasar a la siguiente subtarea.

                           

El poder de las metricas

¿Como saber cuando un desarrollo va mal?

Esta pregunta es fácil de responder; si se va por detrás de lo planificado entonces "el proyecto va mal", si se hace una entrega y el software no cumple con el nivel de calidad entonces "el proyecto va mal", si las expectativas del cliente son claramente diferentes de lo que ofrece el software entonces "el proyecto va mal".

Realmente es fácil saber si un proyecto va mal. Hay muchos indicadores, hay muchas METRICAS. Las métricas son formas de medición: Son 1 o un 0, Son un SI o un NO, Son un valor entre 1 y 7, etc.. Son valores fácilmente obtenibles que dan una representación en una escala de como va el desarrollo.

Pues estas METRICAS son el principal quebradero de cabeza de los desarrolladores ya que cuando entregan un software (o parte de él) y los jefes se cabrean porque el software "no vale" usan una de estas METRICAS para darlo a entender.

Cuando un desarrollo va mal, los responsables suelen reunir a todo el equipo y la forma de enderezar el rumbo es usar frases como:

• Tenemos que probar mejor.
• Se necesita mas compromiso.
• Tenemos que dar software de mayor calidad.
• ....

Estas frases es lo que se desea y no una guia para conseguirlo y al final los desarrolladores acaban haciendo lo mismo que han estado haciendo hasta entonces y que en realidad no sirve porque "el proyecto va mal".

Y ¿cual es la solución? Puede que la solución sea la misma arma que se usa para decirles a los desarrolladores que "el proyecto va mal" . LAS METRICAS. Lo que se debe hacer es buscar el mecanismo que permita medir de forma univoca si el software implementado por un desarrollador es bueno o no lo es.

Pongo un ejemplo:

Partimos de un portal web y se le pide a un desarrollador que incluya una nueva pagina en ese portal. Entonces el programador usara su entorno de programación para desarrollar la pagina y cuando cree que la tiene terminada la entrega y listo. Esa pagina se integra al portal y cuando se entrega al cliente la pagina falla. Ya tenemos el lio.

El responsable tendria que haber puesto UN MEDIO que sirve de METRICA para que el desarrollador puede saber si su trabajo es correcto o no. Por ejemplo, el responsable puede poner un servidor de integracion continua que genera versiones del portal web todos los dias e indicarle al programador que solo se puede puede dar por terminada la pagina cuando funciona correctamente en el portal generado.

MEDIO        =>    Integracion continua.
METRICA    =>    Funciona en la version generada