Mejores Prácticas para el Desarrollo de Software

El poder identificar y transferir las mejores prácticas al interior de una organización es crítico para poder obtener una ventaja competitiva y es por ello que se ha convertido en una de las técnicas de administración más prominentes a partir de la segunda mitad de los años noventa.

Una práctica es un método o técnica utilizada para llevar a cabo una parte de un proceso y describe cómo se realiza. Las mejores prácticas son aquellas técnicas o métodos que permiten incrementar la satisfacción del cliente al incorporar su uso en nuestro proceso.

Este artículo está enfocado en las mejores prácticas en el desarrollo general, análisis, diseño y las relacionadas a los requerimientos.

Prácticas aplicables al proceso de desarrollo en general

A pesar de las diferencias particulares entre las distintas metodologías ágiles, existe un conjunto de mejores prácticas que son comunes a la mayoría de ellas y que se aplican al proceso de desarrollo en general.

Participación activa de los clientes. Los clientes deben proveer información de manera regular, tomar decisiones de manera constante e involucrarse activamente en el proceso de desarrollo a través de herramientas y técnicas que faciliten su inclusión.

Visualización de los requerimientos. Al principio de un proyecto ágil es necesario invertir algún tiempo para identificar el alcance del proyecto y crear la pila inicial de requerimientos organizados por prioridad.

Información de una única fuente. Se obtiene al capturar la información en un lugar únicamente.

Visualización de la arquitectura. Al principio de un proyecto ágil es necesario un modelado inicial de la arquitectura desde un nivel de abstracción alto para identificar una estrategia que permita la implementación de la solución.

Documentar continuamente. Elaborar documentación entregable a través del ciclo de vida del producto de forma paralela a la creación de la solución.
Ver más allá del modelado. Algunas veces los requerimientos que tienen una mayor prioridad son complejos, lo cual motiva que se inviertan esfuerzos para explorarlos antes de comenzar su desarrollo para reducir el riesgo general del desarrollo.

Múltiples modelos. Cada tipo de modelo tiene sus fortalezas y debilidades. Un desarrollador efectivo necesitará contar con una variedad de modelos en su caja mental de herramientas que le permitan aplicar el modelo adecuado en la forma más apropiada para la situación actual.

Gestión de requerimientos

Adoptar modelos inclusivos. Para facilitar la participación activa de los clientes con el modelado y la documentación, es necesario reducir las barreras idiomáticas evitando utilizar términos técnicos y utilizando herramientas simples como notas adheribles.

Tomar una primera aproximación amplia. Es mejor intentar plasmar la idea general en lugar de enfocarse en algún aspecto particular del sistema, esto permite obtener un conocimiento general del sistema. Tratar de definir la totalidad de los requerimientos al inicio del proyecto suele fallar debido a dos razones principales:

• Cuando los clientes reciben la indicación de plasmar todos sus requerimientos en papel al inicio del proyecto intentan definir tantos requerimientos potenciales como les es posible sin saber si realmente serán necesarios.
• Los clientes saben que si no lo hacen ahora será muy difícil agregarlos después debido a la práctica común de evitar realizar cambios en etapas avanzadas del proyecto.

Tratar los requerimientos como una pila priorizada. Se ubican los requerimientos en una pila ordenados por prioridad de acuerdo a cuando deben implementarse, decisión que debe tomarse en conjunto con el cliente. En caso de requerirse un cambio a un requerimiento debe tratarse como un nuevo requerimiento y agregarse a la pila. Los requerimientos que se encuentran al principio de la pila deben estar bien detallados y en los del final el detalle debe ser escaso.

Preferir requerimientos ejecutables sobre documentación estática. En la manera posible, especificar los requerimientos en forma de “pruebas de usuario” que puedan ejecutarse y diseñar como si fueran pruebas de desarrollo ejecutables, en lugar de documentación “estática” no ejecutable.

Reconocer que existe una amplia variedad de clientes. Incluso entre los miembros de una misma empresa es común que haya puntos en los que no exista un acuerdo sobre lo que se espera del sistema. Por ello es necesario definir a la persona que servirá de intermediario entre el cliente y el equipo de desarrollo, y que funcionará como la fuente oficial de información y priorización.

Requerimientos independientes de la plataforma. Los requerimientos deben ser independientes de la plataforma para que puedan conservar su simpleza y claridad.

Más pequeño es mejor. Los pequeños requerimientos, características e historias de usuario son más fáciles de estimar y de desarrollar que aquellos que son grandes, además de que son más fáciles de priorizar y por tanto de manejar.

Trazabilidad. Se refiere a la capacidad de conocer la relación de un requerimiento hacia todos los artefactos que afecta: modelos de análisis, modelos arquitectónicos, modelos de diseño, código fuente y casos de prueba. La trazabilidad debe verse reflejada en una matriz, lo que permite analizar el impacto que tendría en el sistema un cambio de requerimiento.

Explicar las técnicas. Todo el equipo debe tener un entendimiento básico de una técnica de modelado, incluyendo los clientes. Por ejemplo, el tomar unos momentos para explicar qué es una tarjeta CRC y por qué se utiliza, puede ayudar a facilitar el proceso.

Adoptar la terminología de los clientes. No debemos insistir en que los clientes sean capaces de entender terminología técnica del desarrollo. Para ellos se está construyendo el sistema, por tanto, es su terminología la que debemos utilizar para el modelado del sistema. Un artefacto útil para consolidar está práctica es elaborar y mantener un glosario de términos de negocio.

Análisis y diseño

Los diseños ágiles se van construyendo, no se definen por completo al inicio. El diseño general del sistema se construye conforme avanza el desarrollo del proyecto cambiando y evolucionando constantemente.

Los modelos de diseño son apenas lo suficientemente buenos. No es necesario modelar cada detalle en los modelos ya que no es necesario que se encuentren completos, los detalles se refinan durante el proceso de codificación.

Cada modelo puede ser utilizado para diversos propósitos. Cada modelo puede ser utilizado para diversos propósitos, por ejemplo un caso de uso puede usarse para modelar la naturaleza esencial de un proceso o para modelar un proceso a detalle.

Los diseñadores también deben codificar. Cuando el modelo desarrollado por alguien más se entrega a otra persona para codificarlo hay un riesgo significativo de que no capte sus detalles adecuadamente. Separar las funciones del diseño y la codificación es riesgosa, es mejor contar con especialistas en el equipo que puedan
diseñar y codificar.

Probar con código. Nunca debe asumirse que un diseño funciona, sino que debe probarse codificándolo para determinar si funciona.

La retroalimentación es importante. Nunca debe olvidarse que es necesario buscar activamente retroalimentación sobre el trabajo que se realiza. Esto permite mejorar el sistema.

Utilizar herramientas de generación de código. En caso de que exista la posibilidad de que a partir del diseño se genere automáticamente código, esa posibilidad debe aprovecharse.

El diseño es importante y debe realizarse todos los días. Es de suma importancia pensar en lo que se va a construir. A través del diseño es posible obtener una idea general y plasmarla antes de lanzarse a la construcción.

Analizar detenidamente el ambiente de implementación. Esto es importante porque permite determinar cuestiones como la portabilidad que tendrá el sistema, lo cual limita la elección de tecnologías para el desarrollo del proyecto.

Documentar las partes complicadas del sistema. A través de la documentación generada debemos poder entender el funcionamiento del sistema, así como las razones que sustentan las decisiones de diseño.

Conclusión

Szulanski [1] tiene mucha razón al decir que: “así como las competencias distintivas de una empresa pueden ser difíciles de imitar por otras, sus mejores prácticas pueden ser difíciles de replicar internamente”. El proceso de propagar las mejores prácticas a través de una organización está lleno de desafíos, pero es un esfuerzo que bien vale la pena realizar.

Referencias
[1] Szulanski, G. “Exploring Internal Stickiness: Impediments to the transfer of Best Practice Within the Firm”, Strategic Management Journal, Vol. 17, pp. 27-43.
[2] R. Chillarege. “Software Testing Best Practices”. IBM Research Center for Software. Engineering, 1999.
[3] R. Damelio. “The basics of Benchmarking”. Productivity Press, 1995.
[4] S. W. Ambler. “Agile Modeling: Effective Practices for Extreme Programming and the Unified Process”. John Wiley & Sons, 2002.
[5] S. W. Ambler. “Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agi leSoftware Delivery in the Enterprise”. IBM Press, 2012