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"