Principios Ágiles (I)

Software que funciona por encima de documentación exhaustiva.

Se trata de uno de los principios de SCRUM, Marco de Trabajo para la gestión y desarrollo de productos software.

¿Quiere este principio decir que sobra la documentación?

Bajo ningún concepto, por lo que este tiene que ser un firme propósito de enmienda que nos tenemos que plantear seriamente.

De alguna manera, escapar de la oficina y con un poco de tiempo para reflexionar, permite encontrar errores en nuestra estrategia. Tienes la oportunidad de repensar las cosas. A menudo, eso me ayuda a corregir un error que cometí o que alguien más está a punto de hacer.

Larry Ellison – CEO de ORACLE

Mejor reflexionar

La falta de reflexión y la velocidad no son buenas consejeras y ciertamente repensar las cosas tiene grandes beneficios a largo plazo. Siendo realistas, por lo general la documentación del software no suele ser de muy buena calidad eso en aquellos casos en los que existe. Esta situación no se produce por mala intención, en muchas ocasiones lo que ocurre es que damos más importancia a la velocidad de entrega que a la generación de un código y un diseño de software de calidad.

Este aparente beneficio inicial es sin duda un gran problema a largo plazo ya que repercutirá sin ninguna duda en un alto coste en la sostenibilidad de los sistemas y en una gran dependencia del conocimiento intrínseco de nuestro equipo.

Este principio de Agilidad no significa que tengamos que olvidar la documentación, todo lo contrario, significa que tenemos que centrarnos en la documentación de calidad. En generar únicamente documentación que aporte valor para nuestros sistemas y su posterior mantenimiento.

 

NO es suficiente con documentar

Siendo la documentación uno de los componentes de un diseño de software de calidad, tampoco podemos ser tan ingenuos como para pensar que por llenar el código de comentarios vamos a obtener un código más eficiente y mantenible.

Un código de calidad tiene que poseer otras muchas características aunque me quedare con las tres que considero principales:

• Mínima Complejidad: Intentaremos hacer el diseño lo más sencillo posible. Eliminando cualquier nivel de complejidad innecesario.
• Facilidad de Mantenimiento: Estructuración del código y documentación suficiente.
• Estandarización: Seguir estándares siempre que sea posible y definir una forma de trabajo común para el equipo. 

 

En resumen

Necesitamos software de calidad que funcione con una documentación de valor. Esto significa que tenemos un gran trabajo por delante, y cualquier mejora en la calidad del software repercutirá directamente en unos sistemas mas robustos y eficientes.

Aquí os dejo una presentación de SCRUM en la cual esta incluido el principio de este post y otros que pretendo ir comentando posteriormente.