El Papel de la Arquitectura de Software en Scrum

Como ustedes saben, Scrum es una metodología ágil para la gestión del desarrollo de software, que está basada en un proceso iterativo e incremental. Debido a la importancia de la arquitectura de software, es primordial definir claramente su papel en scrum. Es por esto que en el presente artículo se describe una propuesta del papel de la arquitectura de software en el ciclo de desarrollo de Scrum y de las responsabilidades del arquitecto de software en esta metodología.

La competitividad del mercado de desarrollo de software y la necesidad de los clientes de reducir el “time to market” obligan a las organizaciones de desarrollo de software a ser agresivas en sus calendarios de entrega. Esto ha hecho que hayan surgido metodologías de desarrollo de software ágiles tales como Scrum: una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental. Su estructura está basada en sprints los cuales son iteraciones de 1 a 4 semanas. Scrum se usa en proyectos de entorno complejos, donde se desea obtener resultados rápidos y la productividad es lo más importante [1].

En los proyectos basados en Scrum se consideran tres roles:

• Dueño del producto (Product Owner): Es quien determina las prioridades de los entregables.
• Maestro de Scrum (Scrum Master): Administra y facilita la ejecución del proceso.
• Equipo de Trabajo (Stakeholders): Trabajan en conjunto para entregar resultados en cada sprint.

Como se puede observar, en medio de los participantes del proceso no quedan claras las responsabilidades del arquitecto de software. Sin embargo, como comenta Charlie Alfred, “la arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum” [2].

Si se compara el rol del arquitecto de edificaciones con el del arquitecto de software, se puede observar que ambos modelan las construcciones a un alto nivel de abstracción, proveen posibles soluciones, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades del problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. Al igual que es imposible pensar que un rascacielos puede ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales puedan ser implementados sin una arquitectura bien pensada.

Según Bass, Clements y Kasman [3], “la arquitectura de software de un programa o sistema informático, es la estructura o estructuras del sistema, que incluyen elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos.” Esta definición nos lleva a concluir que la arquitectura de software garantiza el buen desarrollo del software y a tener un sistema que cumpla con los requerimientos funcionales y no funcionales del cliente. Además, la arquitectura es clave en la reutilización de artefactos de software en sistemas de líneas de productos de software.

Viendo la importancia de la arquitectura en el desarrollo de software, en éste artículo se presenta una propuesta para gestionar la arquitectura de software en Scrum. En el primer capítulo se trata el tema de la localización de la arquitectura de software en el ciclo de desarrollo de Scrum; en el segundo capítulo se describen las tareas del arquitecto de software en Scrum; finalmente se presentan las conclusiones y el trabajo futuro.

Arquitectura de software en el ciclo de desarrollo de Scrum

La idea fundamental de la presente propuesta es adicionar un sprint inicial llamado “Sprint 0” al inicio del ciclo de desarrollo. El objetivo principal del arquitecto en el Sprint 0 es analizar y diseñar la generalidad del sistema, que satisfaga los requisitos y sea entendible por los miembros del equipo desde sus diferentes puntos de vista durante el desarrollo. Un punto clave, es reutilizar artefactos de software creados a partir de la arquitectura para ser más ágiles en el desarrollo de productos específicos.

En la Figura 1 se puede observar que el Sprint 0 comprende tres fases que fueron tomadas del ciclo de vida de entregas evolutivas [3]. En el Sprint 0 se construye la arquitectura de forma iterativa mediante un análisis preliminar de los conductores arquitectónicos (requisitos funcionales, de calidad y del negocio), y de un estudio de factibilidad del proyecto. No se necesita tener todos los requisitos claros para comenzar la fase de diseño arquitectónico.

Para determinar los conductores arquitectónicos, se debe identificar los objetivos del negocio de más alta prioridad, que son pocos. Estos objetivos del negocio se convierten en los escenarios de calidad o casos de uso. De esta lista, se deben escoger los que tendrán un mayor impacto sobre la arquitectura.El diseño arquitectónico puede comenzar una vez que se encuentran definidos los conductores arquitectónicos. El proceso de análisis de requisitos será entonces influenciado por las preguntas generadas durante el diseño arquitectónico.

El resultado del Sprint 0 es un documento inicial que explica la arquitectura. El documento puede basarse en los pasos definidos por el método ADD (Attribute Driven Design). Este método ha sido probado exitosamente en proyectos anteriores [4]. Con ADD se puede definir una arquitectura de software mediante un proceso de descomposición basado en los atributos de calidad del software.

El documento inicial de la arquitectura se debe evaluar con el fin de saber si la arquitectura cumple con los requisitos de calidad. Para realizar esta evaluación, se propone el método ATAM (Architecture Tradeoff Analysis Method). El ATAM revela cuán bien una arquitectura satisface los objetivos particulares de calidad y provee una aproximación de cómo los objetivos de calidad interactúan.

Figura 1. Propuesta de gestión de la arquitectura de software en Scrum.

Si en la evaluación de la arquitectura se encuentra que se deben realizar cambios a la misma, entonces ésta se debe refinar hasta llegar a tener como resultado del Sprint 0 el documento pulido de la arquitectura junto con el sistema esqueleto. Finalmente, la arquitectura creada en el Sprint 0 beneficiará el desarrollo en los siguientes sprints.

Rol del arquitecto de software en Scrum

El rol y actividades del arquitecto de software cambia de enfoque dependiendo de si se está en el Sprint 0, o en sprints subsecuentes.

Sprint 0. En sistemas complejos, una persona difícilmente puede cubrir con amplitud técnica las decisiones arquitectónicas y dar credibilidad a la arquitectura de software [5]. Esto quiere decir que la participación del equipo es de vital importancia para la creación y el mantenimiento de la arquitectura. Un equipo de arquitectos de software que se aísle del equipo de Scrum, puede producir una arquitectura que corra el riesgo de ser rechazada. Es por esto que recomendamos que el arquitecto o los arquitectos de software sean miembros del equipo de Scrum. Una de las actividades que se debe realizar en equipo es la evaluación de la arquitectura. Específicamente, en el método ATAM se requiere la participación mutua de tres equipos que trabajan en conjunto con los arquitectos de software: el de evaluación, el de tomadores de decisiones del proyecto, y el de los involucrados en la arquitectura.

Sprints subsecuentes. El arquitecto de software asegura que el equipo de Scrum entienda el enfoque y los retos arquitectónicos más importantes en cada sprint. Los equipos de Scrum realizan construcciones cortas, guiados por las estrategias de la arquitectura. A continuación se nombran algunas de las responsabilidades del arquitecto de software desde el Sprint 1 en adelante:

• El dueño del producto y el maestro de Scrum trabajan con el arquitecto para priorizar los requisitos a implementar en cada iteración.
• El arquitecto comunica las decisiones y facilita las conversaciones arquitectónicas de distintos puntos de vista en cada sprint.
• El arquitecto asegura que haya conformidad entre las entregas en cada sprint y la arquitectura.
• El arquitecto responde preguntas y da orientación arquitectónica cuando sea necesario.
• Junto con el maestro de Scrum, coordina a los miembros del equipo para adaptarse a la arquitectura prevista.
• El arquitecto junto con el dueño del producto y los miembros del equipo preparan el Product Backlog.

Conclusión y trabajo futuro

La arquitectura de software y Scrum no se repelen, más bien se complementan. El arquitecto describe las tácticas que se deben seguir para cumplir con los requisitos de calidad del sistema, teniendo clara la imagen global de éste. Además, permite que los artefactos a construir se reutilicen con el fin de reducir el tiempo de desarrollo y mejorar la calidad del producto.

En el presente artículo ofrecimos una propuesta para incluir la arquitectura de software en Scrum. En el Sprint 0 se realizan las actividades concernientes al análisis y diseño de la arquitectura de software, y el sistema esqueleto. En los siguientes sprints el arquitecto de software se asegura de que la implementación cumpla con la arquitectura.

En un futuro proyecto implementaremos la presente propuesta en una línea de productos de software.

Referencias

1. O. Soto & G.H. Alférez. “Scrum, ¿Un Paradigma de Administración de Proyectos que Cumple lo que Promete?” Software Guru, Agosto 2009. http://bit.ly/sg30r3
2. C. Alfred. “Scrum and Architecture Partners or Adversaries”. http://bit.ly/sg30r4
3. L. Bass, P. Clements, & R. Kasman. Software Architecture in Practice. Addison Wesley, 2da ed., 2003.
4. O. Soto & G.H. Alférez. “An Architecture Proposal for Academic Software in Adventist Universities”. Catalyst, Asia-Pacific International University, Vol. 4, num. 1. http://bit.ly/sg30r5
5. R. Malan & D. Bredemeyer. “Architecture Teams”. http://bit.ly/sg30r6
6. R. Sullivan. “Scrum and Architecture”. http://bit.ly/sg30r7