Hablemos de estándares

Los estándares, en el mundo del software, son uno de los facilitadores más sencillos que existen. Sin embargo, tienen muchos detractores y están muy mal vistos por colectivos que ven en el desarrollo del software un medio de expresión, un "arte", y que están en contra de las normas y directrices.

Las normas y directrices ayudan a luchar contra las diferencias que presentan los distintos componentes de un proyecto:

• Diversidad cultural
• Creencias
• Niveles de conocimiento
• Años de experiencia
• Personalidad
• Barrera idiomática
• Jerga Profesional

¿Y qué deberían cumplir estas normas, reglas o estándares?

• Simples, fáciles de entender
• Si es posible, incluir ejemplos de uso, y demostración de su utilidad práctica
• Los estándares no pueden ser extensos. Nadie va a recordar un documento de 200 hojas.
• Los estándares pueden ser muchos. Por ejemplo, si en nuestra empresa se programa en 20 lenguajes, puede haber una mini guía o estándar por cada uno.

Recomendaciones:

• Mantener vivos los estándares. Pocas cosas hay peores que dejar las cosas en el olvido. Las tecnologías evolucionan, y los estándares están muy relacionados con las tecnologías del momento. Es por eso que los documentos donde se recojan los estándares han de estar actualizados constantemente. Las actualizaciones han de estar disponibles, y la gente ha de conocer de forma clara el motivo de la actualización. 
• Evitar actualizaciones muy frecuentes: por ejemplo, que sólo los proyectos nuevos a partir de una fecha utilicen la última versión de los estándares. No hay peor cosa para la gente que esté en un proyecto, que la distraigan cambiando las normas. Bastante cambian ya los requisitos, los hitos, las entregas, etc., como para que encima cambie la forma en que hacemos las cosas en el día a día.
• Realizar formaciones. De nada sirve dar a la gente al principio del proyecto un documento para que se lo lea. Tampoco será muy útil tratar de castigar o penalizar a quien no lo siga. Mucho más práctico será realizar cursos periódicamente, que además de sobre los estándares, puede incluir las últimas novedades de la tecnología que se use (esto suele ser mejor reclamo que los estándares en sí).
• Incentivar el uso. Puede aplicarse un incentivo positivo: por ejemplo, dar premios o bonus a los desarrolladores que mejor resultados tengan en los tests relacionados con estos estándares (y mejor si son pruebas automatizadas).
• Penalizar el desuso. Yo en general, estoy en contra de esta práctica, pero habrá quien la vea útil. Es la contraria de la anterior, y consistiría en penalizar a los desarrolladores con peores prácticas (desde el punto de vista de los estándares recomendados).

Pues nada, ahora que sabemos la teoría, dejaremos para un próximo post el ir aterrizando estándares "palpables" para algunas tecnologías. Nos vemos.