Mantener la coherencia en el estilo del desarrollo

Cuando se empieza un desarrollo de proyecto de software esta implícito que el grupo de programadores va a programar el software que se desea conseguir. Cuando el software es medianamente grande te das cuenta de que no vale con que el programador consiga terminar una tarea, ademas debe:

• Seguir las normas que se han establecido para programar.
• Seguir la arquitectura que se haya definido.
• Tomar la decision correcta ante una situación que aunque no este especificada expresamente se deduce a partir de los puntos anteriores. 

Si no se resuelven estos puntos entonces al final el software es un conjunto de miles de tareas cuyo conjunto no hacen lo que queríamos al planificarlo al principio.

Es imposible conseguir que un grupo de programadores programen igual pero ¿Como hacer que varios programadores sigan unas normas?

La mejor solucion consiste en tener un integrador en el equipo que compruebe que se siguen las normas y si no se siguen las normas se le indica al programador y lo apunta en una lista que ira rellenando de semana en semana. Cada semana se debe juntar con el equipo y repasar dicha lista e indicar lo que crea relevante. Estas charlas son la clave para ir formado al equipo en las normas y el estilo que deben seguir los programadores.

Como señalar los fallos

Durante el desarrollo del software, los programadores van cometiendo pequeños errores y grandes errores. Unos pueden ser grandes meteduras de pata y otras pequeñas tonterias pero todas van sumando fallos que hay que solucionar y que penalizan las entregas. Esto es asi y se debe tener en cuenta como riesgo en la planificacion del proyecto. Pero existe otro gran problema, los programadores normalmente no son conscientes de estos fallos y cuando llega la hora de las entregas y no se llega o la calidad del software no es buena entonces aparecen los enfados y frases como:

• Era imposible llegar.
• Como puede ser? yo le hecho todo bien.

Para solucionar este problema se debe:

• Tiene que haber un supervisor, jefe, integrador, etc... que detecte estos fallos y los ponga de manifiesto.
• Se le debe comunicar al equipo de forma adecuada.

En este ultimo punto quiero incidir, Cual es la forma correcta de comunicar los fallos? 

• Si se hace de forma continua e inmediata (cuando se detecta el fallo enseguida se indica) entonces geneneras en el programador las ganas de "devolvertela" (estara deseando que el supervisor se equivoque para echarselo en cara).
• Si se hace de forma aislada entonces pierdes el poder que da estar hablando en grupo y dejas que el programador se pueda "picar" e intentar defenderse con unñas y dientes aunque no tenga razon.

La forma correcta es tener una rutina de reuniones (una a la semana) donde el supervisor hable de asuntos tecnicos y cuando lo vea oportuno indicar  cosas como:

• Esta ultima entrega ha ido mal y yo creo que...
• Las metricas de calidad han bajador debido a...
• Normalmente usamos "esto" en el codigo y deberiamos usar "esto otro" 

Miedo a la integración

En muchas ocasiones, y sobre todo cuando el proyecto alcanza un tamaño grande, ante un nuevo desarrollo/solventar incidencia se implementa una parte completamente nueva aun sabiendo que ya hay una parte implementada que deberia ser modificada/ampliada para solucionar dicho desarrollo/incidencia. Esta situación pasa porque: 

• El programador quiere “ahorrase” el tener que conocer una lógica compleja.  
• No se han proporcionado las herramientas necesarias para adquirir el conocimiento de la parte a modificar/ampliar y la tarea se hace demasiado pesada. 

Este “miedo” tambien afecta a la parte funcional ya que en muchos casos se recurre a “Comentarios”, “Anexos”, etc.. En lugar de modificar el documento donde se indique la parte a modificar/ampliar. 

La única solución a este problema es identificar la necesidad de la redefinición y que es una tarea que debe ser teniada en cuenta en las planificaciones. No se debe considerar la redefinición/ampliación como un error. Habrá casos donde la redefinición/ampliación sera un fallo ya que no hacia falta pero en otros casos no seria un fallo y es parte del desarrollo del software. 

Problemas para dividir el trabajo

Cuando se piensa en la informática,  y en concreto en la programacion, lo primero que se piensa es que el programador está en cualquier sitio del mundo. Nada más alejado de la realidad, al programador se le quiere al lado del negocio y si se piensa en tener al programador alejado es por temas laborales( por conciliación familiar, teletrabajo, etc...).

Por qué se necesita al programador al lado del negocio? Los principales motivos son:

- No hay una figura de comprobador/integrador técnico que asegure que lo que hacen los programadores sea correcto. Este tarea se delega en el grupo de programadores.

- El negocio requiere continuos cambios y definición on-fly( en el momento) y tiene que aclararlo en persona.

A lo largo de la historia reciente de los productos que han revolucionado la informatico y/o el mundo ( Facebook, WhatsApp, wifi, Etc..) se  puede llegar a la conclusión de que todos eran grandes soluciones que caían por su propio peso y no eran grandes soluciones por lo complejo de su implementación. Este problema es lo mismo, lo único que se necesita es dar con la idea feliz que permita tener programadores en cualquier parte del mundo de manera eficaz.

No querer ver la realidad

Cuando se planifica con tiempo el desarrollo de un software y se mira hacia la implementación se pretende hacer de forma correcta y se crea el perfil de arquitecto de software pretendiendo que diseñe el software y lo haga tan bien que implementarlo sería solo la parte fácil.

Nada más lejos de la realidad. Puede que en un futuro este planteamiento sea una realidad pero ahora no lo es y nunca ha sido una realidad por mucho que nos empeñemos en no querer la realidad.

El no querer ver la realidad siempre es lo mismo. Todo el mundo ha estado en un proyecto donde se dice: este proyecto no ha quedado bien, al siguiente lo haremos mejor. Al siguiente se hace de forma distinta pero el resultado es más o menos el mismo y ya se empieza a decir: la culpa es de esta otra persona por esto o por lo otro.

Rindamonos a lo evidente. Al menos hasta que cambien las cosas y se establezcan métodos claros y que todos sigan para que la implementación sea lo más sencillo. Es cierto que se necesita un arquitecto de software pero el arquitecto también programa, se moja las manos y resuelve problemas de bajo nivel. Si hace este tipo de tareas entonces se ganará la confianza del grupo de desarrollo y del grupo de gerencia. Con esta piedra angular el desarrollo irá por buen camino.

Una aplicación informática es una aplicación informática.

Se me ha ocurrido usar una técnica de autoayuda/formación de equipo que consiste en repetir mucho algo muy obvio pero que se nota que tenemos en cuenta porque al ser tan obvio nos centramos en otras cosas de tal manera que puede hacer que no hagamos la parte obvia. Por ejemplo, nos encomiendan hacer una casa y podemos pensar "bueno si voy a hacer una casa empecemos por algo sencillo, voy a comprar la tele" o otra como "pongo las puertas", etc.. cosas asi. Pero cuando pasa el tiempo y comprobamos lo que tenemos nos damos cuenta que "no se me ocurrio empezar por las paredes" y cuando se supone que tenemos que entregar la casa tenemos un monton de "cosas de la casa sueltas" pero no tenemos paredes.

Yo creo que si esto le ha pasado a alguien a alguna vez lo que penso al ver el fracaso es "¿por que no empece por las paredes?".

Cuando estas haciendo una aplicación informática pasa lo mismo, una aplicación informática no es un conjunto de funcionalidades que puedes implementar y luego ver como las juntas, no es un conjunto de historias de usuario que debemos cumplir, etc.. Claro que la aplicación informática debe dar solución a todo eso pero no olvides que una aplicación informatica es un conjunto de interfaces que acceden a una logica. Empieza por las interfaces. La casa debe tener una tele pero primero mejor ponle paredes. 

Supervisor técnico

En los proyectos actuales siempre veo roles que se repiten: jefe de proyecto, funcionales, técnicos, arquitectos y programadores. Con las técnicas de gestión ágiles aparece el product owner, el scrum master y el cliente (este ultimo nunca forma parte del equipo). Me falta alguien que creo que es vital para la culminación de un proyecto de desarrollo de software, el supervisor tecnico. Esta figura es el encargado de:

• Diseño técnico.
• Que los programadores sigan las especificaciones técnicas y los estilos de programación.
• Ser el validador de que lo implementado es lo que realmente se ha indicado en los funcionales.