Scrum

Les comparto este artículo que leí en una revista y me pareció muy interesante...

El Papel de la Arquitectura de Software en Scrum
¿Cómo incorporarla?
 Por Edwin Rafael Mago Vásquez y Germán Harvey Alférez Salinas

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 para la gestión y desarrollo de software basadas 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.

En los proyectos basados en Scrum se consideran tres roles:
  • Dueño del producto (Product Owner): Es quien determina las propiedades 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 al aceite y el filtro que lubrica adecuadamente a Scrum".

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, "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ínea de productos de software.

Viendo la importancia de la arquitectura en el desarrollo del 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.

El Sprint 0 comprende tres fases que fueron tomadas del ciclo de vida de entregas evolutivas. 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 Srpint 0 es un documento inicial que explica la arquitectura. El documento puede basarse en los pasos definidos por el método ADD (Attrbute Driver Design). Este método ha sido probado exitosamente en proyectos anteriores. Con ADD se puede definir una arquitectura de software mediante un proceso de descomposición basado en los atributos de calidad de Software.

El documento inicial de la arquitectura se debe avaluar 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.

Si 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 público 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 cambian 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. 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 se 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 casa 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 del 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 previa.
  • El arquitecto junto con el dueño del producto y los miembros del equipo preparan el Product Backlog.
Conclusión

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.