No solo qué, sino también cómo

No soy un fan de la teoría del justo medio, esa teoría que dice que si una persona sostiene que dos más dos da cuatro y otra dice que dos más dos da cinco, entonces la respuesta correcta debería ser cuatro coma cinco.

Aún así, me gustan las columnas de Scott Ambler en la Dr. Dobbs y su continua prédica sobre el 'agil revisado', donde argumenta a favor de un proceso agil con algunas prácticas agregadas para disciplinar el proceso.

No estoy siempre de acuerdo con enfoque de 'agil disciplinado', pero me parece impecable el punto que hace sobre los requerimientos funcionales y los no funcionales. Recuerda Ambler que la comunidad ágil ha hecho un esfuerzo mucho mejor con los RF que los RNF: estos últimos siguen dependiendo, en gran medida, de que el programador sea lo suficientemente bueno y despierto como para tenerlos en cuentas y saber como tenerlos en cuenta y son dificilmente implementables con la misma estrategia que las historias del usuario.

El problema con los RNF es que, por lo general, no son autocontenidos, y la idea del backlog priorizado del que se seleccionan historias para implementar completas dentro de un sprint requiere un cierto grado de independencia entre éstas. Se dirá que los RF no son totalmente autocontenidos e independientes, pero podríamos decir, para ser más rigurosos, que el grado de dispersión (inventemos la definición: cuantos componentes involucra un requerimiento) de un RFN tiende a ser mayor que la de un RF. Los RFN tienen que ver con cuestiones de rendimiento, disponibilidad, usabilidad que involucran, normalmente, a la solución como un todo., mientras que los RF son más autocontenidos.

No me cuesta estar de acuerdo con que sabemos como manejar los RF mejor que los RNF, pero no diría que es un problema de la agilidad, a lo sumo es un problema que venía de antes y la agilidad no resuelve, como sí resuelve el problema que el enfoque tradicional tenía con los cambios en las definiciones. De hecho, me parece que la mejor solución para la implementación de los RNF vino con UP (un proceso con cierta agilidad), aunque ya la esbozaba aquel que vió en la oscuridad en su mítico libro sobre los sucesos primigeneos: la construcción de la linea base de arquitectura, el proceso de diseño de la arquitectura (alguna buena palabra para decir 'envisioning'? http://www.thefreedictionary.co /envision ) o se desee llamar a esa tarea.

Me gusta la visión de UP, que llama a esa tarea la construcción de la linea base, por sobre la idea de llamarla architecture envisioning. El concepto de linea base incluye una característica que, para mí, lo hace superior: la construcción de software además del modelado de la arquitectura, mientras que el architecture envisioning, si bien no niega la posibilidad de hacer de sotfware que en realidad ande, no la adopta como central. Pienso, como argumenté en artículos anteriores, que toda cuestión delicada que pueda ser sometida a una prueba empírica, debe pasar por ella: una linea base nos da una mejor idea de cuan buena en la arquitectura de las que nos pueden dar un par de modelos.

Los modelos tempranos (inevitables, por otra parte) son promesas, más útiles para hacer una primera revisión crítica de las ideas que para representar las ideas en su forma final. Deberíamos tratar de validar esas promesas antes de construir demasiado sobre ellas.

Por cierto, y como nota Ambler, el asunto no se acaba ahí. La línea base de arquitectura da un excelente marco para que los desarrolladores entiendan las restricciones y los requerimientos no funcionales, así como la estrategia de resolución que se les dará en la solución que está siendo implementada.

La educación de los desarrolladores debe ser también parte de la solución. No soy un fan de los cursos de siete horas al día donde comemos mediaslunas en los breaks, pero me gustan las soluciones de elearning y me gusta esa habilidad que he visto en algunos arquitectos, líderes o gerentes de proyectos de motivar a su equipo a aprender.

Y por último, Ambler propone algo que me gustaría tener: un equipo de test independiente que pruebe todas las releases. Cuando he trabajado con un equipo de test independiente, este ha sido más un equipo de certificación que de prueba de software. El concepto era que el software debía llegar al equipo de testing sin errores, para que ellos certificaran que así fuera. Siempre pensé que un equipo de testing independiente del equipo de desarrollo pero integrado al proyecto, con la misión de encontrar los bugs y no de certificar su inexistencia, podía llegar a aumentar la velocidad de liberación y la calidad. Hasta ahora, parece que me quedará con las ganas de probar empiricamente si tengo razón.

Como quiero yo, un desarrollador, que funcione el equipo de test?. Tal vez sea un buen tema para otro post.