¿Un paquidérmico SEI caminando ágil?
Las metodologías ágiles son sin duda alguna el tema de moda en la industria del desarollo de software y por ende son un buen negocio que muchas empresas no quieren desaprovechar. Las planteamientos de estos marcos de trabajo son radicalmente diferentes a lo que plantea RUP, y van en contra de lo robusto y excesivamente analítico (Parálisis del análisis en algunos casos) que plantea el SEI.
En el siguiente articulo: "Integrating SoftwareArchitecture-Centric Methods into Extreme Programming (XP)", se muestra la posición de este instituto en torno a las metodologías ágiles y como involucrarlas dentro del contexto de un proyecto de este tipo. Aunque se podría ver mas como un documento comercial cuyo único es objetivo vender, lo considero un buen referente para incluir sus buenas practicas en este tipo de proyectos. Es un poco viejo pero QAW, ADD, ATAM, CBAM y ARID siguen estando vigentes y pueden ser una gran ayuda que equilibre el radical extremo al que llega ágil. El diseño emergente.
Este post se basa en las recomendaciones del documento para la inclusión de las practicas del SEI dentro del contexto XP y la experiencia de la aplicación de tres de estas en un proyecto SCRUM (QAW, ADD, ATAM).
QAW
SCRUM parte de una alta colaboración entre el negocio y el proveedor tecnológico cambiando los largos documentos de especificación por la automatización de las pruebas de aceptación (ATDD) y otras practicas como TDD tomadas de XP. Al inicio solo se identifican las necesidades a un nivel muy alto y son documentadas como historias de usuario. Estas historias deben contener criterios de aceptación y ser discutidas entre el equipo y el cliente con el fin de obtener toda la información necesaria para entregar valor. El problema con este enfoque es que se centra en las necesidades funcionales del software y quedan un poco relegados los atributos de calidad que aunque en la mayoría de los casos no son expresados por el negocio, determinan la buena o mala percepción de este en torno al software. De hecho los atributos de calidad rara vez se encuentran aislados de lo funcional ("El usuario puede retirar un limite diario de $300.000 de una cuenta con los fondos suficientes en menos de 10 segundos") pero identificarlos es en muchas ocasiones complejo.
Aquí es donde QAW genera valor. En el proceso de identificación a través de la generación de escenarios de negocio que permiten discutir las diferentes situaciones a las cuales el software será sometido y por ende permitirá identificar aquellos puntos mas sensibles (Desempeño, Modificabilidad, Disponibilidad, etc) que deben ser considerados. Los escenarios generados durante el QAW podrían convertirse en historias de usuarios o Tech stories e incluso podrán ser automatizados con ATDD convirtiéndose de esta manera en criterios de aceptación.
En SCRUM se plantea la realización de una Iteración 0 en la cual no se genere valor directo al negocio pero que permitirá construir la base de desarollo con la cual se implementarán las funcionalidades, esta base podría incluir entre otras cosas la definición arquitectónica que recibirá como uno de sus insumos los atributos de calidad.
El ejercicio podría realizarse en unas cuantas horas o máximo un día Su objetivo es identificar un conjunto de atributos de calidad que serán clave para la definición arquitectónica pero que serán refinados según las necesidades del equipo junto con el cliente en sprints posteriores.
ADD
Con los drivers arquitectónicos claros (Atributos de calidad, restricciones técnicas, restricciones de negocio y necesidades funcionales), se puede realizar un diseño arquitectónico de alto nivel (En la Iteración 0) que será construido en conjunto por todos los miembros del equipo. En este punto ADD se convierte en una muy buena herramienta que permitirá definir una propuesta de arquitectura de referencia que satisfaga los drivers identificados.
El objetivo de la arquitectura en este punto es generar una visión general y compartida de los objetivos que deben lograrse y alinear los esfuerzos de todo el equipo en torno a esto por lo tanto el diseño planteado con seguridad variará en el tiempo.
ATAM
La evaluación arquitectónica probablemente se vea en ágil como una propuesta inútil dado que previo a la implementación se basará solo en conjeturas que no necesariamente van a materializarse en el código desarollado. A mi me parece importante principalmente al interior de grandes organizaciones donde el éxito de un proyecto depende de la visión de múltiples áreas de tecnología (Operaciones, Infraestructura tecnológica, Seguridad, etc) donde realizar una evaluación permitirá obtener la visión de muchas de ellas involucrandolas desde el inicio y verificando como cumplir con sus expectativas en torno al sistema.
Es obvio que estas mismas áreas debieron estar en el QAW porque de los contrario sus escenarios no estarían planteados y por ende no serian contemplados en el diseño arquitectónico.
Sería ideal que los artefactos generados durante las tres actividades planteadas estuvieran visibles para todo el equipo durante la ejecución del proyecto, con el fin de que se pueda retroalimentar constantemente y todos tengan la misma visibilidad.
No hay comentarios:
Publicar un comentario