La mejor documentación. Las pruebas.

El gran quebradero de cabeza de la documentación de un proyecto no es hacer la propia documentación ni que los miembros del proyecto la lean; el gran problema de la documentación es lo fácilmente que se queda desfasada. Es muy frustrante para los miembros de un equipo que se le pida que siga un documento y cuando lo ha hecho y empieza su trabajo basándose en ese documento que le digan:”Umm.. es que eso está mal..” ó “puff, pues di que eso no cambio hace tiempo…”.
La forma de evitar esto es:

1 º Hacer pruebas automáticas. Software que solo sirve para probar una casuística en concreto de la aplicación. Toda versión de la aplicación que está desarrollando el equipo debe pasar las pruebas para considerarse correcta.

2º Documentar esas pruebas en los propios ficheros fuente de la aplicación.

De esta manera, al estar siempre las pruebas actualizadas ya que si no lo están no se puede generar versión, la documentación de las pruebas también lo estará y además siempre es más ameno leer documentación siguiendo ejemplos (las propias pruebas).
Si se desea una documentación mas “presentable” (por ejemplo, un fichero word) siempre se puede generar a partir de los comentarios de las pruebas. Pero no hay que olvidar que la fuente de documentación son los fuentes de las pruebas y que el documento presentable es un producto generado a partir de los comentarios de las pruebas.

¿Cómo sabes que has terminado?

Sea cual sea el software que se está desarrollando y la técnica que se utilice para desarrollarlo lo que es seguro es que se va a hacer división de tareas y esas tareas acaran asignadas a algún desarrollador. Una vez que se asigne una tarea a un desarrollador, este tardará un tiempo X y dirá:”ya está terminada. ¿Que es lo siguiente?” pero ¿Cómo sabe el responsable que la tarea está realmente terminada?

Ojito que la pregunta es más difícil de responder de lo que parece.

Se debe confiar en la buena fe del desarrollador y suponer que al menos el desarrollador cree que la tarea está terminada. El responsable debe siempre preguntarle ¿Cómo sabes que has terminado? Y dejar que el desarrollador se explique y dejar que “ejecute” algo que sirva de ejemplo.

La pregunta “¿Cómo sabes que has terminado?” puede resultar insultante por lo que es recomendable buscar otras frases como: “A ver. Enséñame como lo has hecho.” o “y el caso X como lo has resuelto”.

El efecto demo

Mucho Ojo, Mucho Ojo…. Siempre que se va a presentar una aplicación a un cliente hay un 99% de posibilidades de que algo falle y un 50% de posibilidades de que no funcione nada. Esto es lo que se conoce como “EL EFECTO DEMO”. Un fallo ante el cliente desprestigia la imagen de la empresa, hace bajar enteros la opinión que tiene del equipo de desarrollo y hace que sea menos comprensivo ante retrasos y fallos futuros.
Si eres un responsable de proyecto y quieres evitar el efecto demo se deben tomar precauciones como:

• Tener a un técnico en la sala y que sea él quien maneje el equipo que va realizando la demo. El responsable solo debe hablar, mostrar y pedir al técnico que haga cosas pero nunca tocar un botón. Esto da imagen de coordinación y además evita que el responsable tenga que resolver un problema técnico que pueda surgir.
  
• Simular toda la demo exactamente cómo se va a hacer delante del cliente. De esta manera es como una visión de cómo va a salir la demo y permite conocer de antemano los posibles problemas y ver mejoras.
  
• Enseña solo lo que funcione. No enseñes ninguna parte de la aplicación que no funcione o que funcione a medias. Si de tu boca sale: “Esta hecho la parte de…” y luego falla el cliente se empezará a sentir “timado” y a desconfiar de ti.
  

Aprender de los errores

Un proyecto fallido es una gran tragedia no solo para la empresa si no para tu estado de ánimo. Al no poder sacar el proyecto a delante la frustración te puede hacer pensar que has hecho un mal trabajo, que no sirves, etc. Pero un proyecto fallido es también una oportunidad para aprender de errores, de cosas que se deberían haber hecho y de cosas que es mejor hacer de otra manera.

La forma de analizar el proyecto es la siguiente:

1º Haz una lista de conceptos que resuman las tendencia erróneas que se siguió para desarrollar el proyecto. Cada concepto tiene que ser una descripción breve, no intentes explicar nada.

2º Para cada concepto pon ejemplos de situaciones que pasaron en el proyecto y justifican que en el proyecto se tomo esa tendencia.
















3º Indica como solucionarías cada concepto en particular.












4º Analiza la lista en general y haz un resumen en el que indicas las conclusiones que pueden ser:

• Algunos conceptos no tienen solución y otros se solucionan con lo que he indicado.
  
• Todos se solucionan pero no con lo indicado, con otra aproximación.
  
• El rumbo del proyecto es incorrecto.
  
• Etc..

Repartir el trabajo

Sea cual sea la técnica, metodología, sistema, etc… que se utilice en la dirección de un proyecto de software lo que está claro es que “tienes un trabajo” y que ese trabajo hay que dividirlo entre los miembros del equipo.
Las divisiones del trabajo en tareas implican tres conceptos básicos:

• Responsabilidad. Un miembro del equipo es responsable de que una tarea este realizada y con la calidad requerida. Este miembro no tiene porque ser el mismo que ha implementado la tarea. Es más, recomiendo que no sea el mismo.
  
• Repartición. Se debe dividir el trabajo de forma que se pueda repartir el trabajo y este lo más claro posible lo que tiene que hacer cada miembro del equipo.
  
• Integración. Lo que se divide hay que juntarlo para hacer un todo (el trabajo solicitado).

Para poder asumir responsabilidades y decidir cómo se hace una integración se necesita “Jerarquia”.
Para poder repartir el trabajo y tener claro que trabajo le toca a cada miembro del equipo hace falta “Departamentos”.
Es de lógica, para poder desarrollar un proyecto (sea cual sea la metodología que utilices) necesitas jerarquía y división en departamentos.

¡Sorpresa! Hay una metodología que seguir

Un factor a tener en cuenta con los miembros de un equipo de desarrollo, y sobre todo con miembros del equipo con mucha experiencia, es que la gran mayoría no estarán acostumbrados a seguir ninguna metodología y sobre todo no estarán receptivos a empezar ahora. Cada proyecto es un mundo y se necesitaría ver a los miembros uno a uno (y analizar el conjunto) para ver la mejor manera de que puedan seguir una metodología.

Mi recomendación: “Decirlo todo (la metodología, lo que tiene que hacer cada individuo, lo que acarrea no seguir la metodología, etc..) desde el principio y si empiezan a surgir problemas solventar los que se puedan y si no se pueden resolver ceder un poco.”

Pero ten en cuenta que:

• No puedes llevarte mal con todo el mundo y en los proyectos del mundo real no puedes cambiar a todo el equipo si no te gusta por lo que si puedes ceder cede.
  
• No puedes ceder siempre porque al final acabará todo en “programación heroica” por lo que tienes que imponerte.

Tienes que buscar el punto justo entre “ceder” e “imponer”.