Trabajo colaborativo - Diseño arquitectónico grupal

Diseño arquitectónico grupal

La academia y referencias bibliográficas nos enseñan diferentes técnicas y procesos de diseño de arquitectura de software, como documentarla y como implementarla. Pero rara vez se preocupan por el lado humano de esta que aunque no lo parezca a simple vista, es el más importante. ¿Acaso no diseñamos software para las personas?

Con el tiempo las metodologías ágiles han tomado fuerza y nos han planteado un camino radicalmente diferente al que se planteaba algunos años atrás (Incluso hoy). De hecho en estas metodologías el concepto de arquitectura desaparece y plantean un diseño que emerge a partir de la implementación de las funcionalidades que requiere el usuario.

Todos los extremos son malos en mi concepto y por eso les expongo una experiencia que tuve diseñando arquitectura en grupo que toma los buenos elementos de la tradicional y paquidérmica forma de diseñar y se basa en el trabajo en equipo que proclaman las metodologías ágiles.

Formato de la actividad

Roles

• Arquitecto: Es la persona que conoce de arquitectura de software por lo que tiene claros los insumos que requiere, y orienta la reunión de trabajo en torno a conseguirlos. Es una persona también con experiencia en diseño de arquitectura.

• Moderador: Es quien vela por que el plan se cumpla.

• Grupo de desarrollo: Son representantes del equipo de desarrollo.

• Grupo de operaciones: Son representantes del área de operaciones, ya sea infraestructura, bases de datos, o cualquier otra que se considere pertinente hacer partícipe del ejercicio.

• Grupo de negocio: Son las personas que tienen la necesidad que será resuelta con el software a implementar. Son expertos en el negocio.

• Equipo de trabajo: Se conforma por el arquitecto y los grupos de desarrollo, operaciones y negocio.

Instrucciones

• Se debe disponer de varias sesiones de trabajo continuas con el equipo que se conforme.

• Previo a la sesión inicial se debe realizar un plan de trabajo, se sugiere el siguiente:

• Seleccionar funcionalidad representativa y presentar (4h). Si ya se tiene delimitado y claramente definido el alcance entonces seleccione aquellas funcionalidades más representativas con base en las cuales realizarán el diseño. También es preciso exponer el objetivo del sistema a los asistentes especialmente a los que no lo conocen.
• 
  

• Delimitar el alcance (10h). Si no tiene claramente definido el alcance entonces con la ayuda del grupo de negocio delimítelo. No es necesario que lo haga con un gran nivel de detalle.

• Identificar necesidades de información (2h). 
• 
  
• Identificar restricciones técnicas (3h). Las necesidades de información podrían entregar algunas de ellas pero con la ayuda del grupo de desarrollo y operaciones se puede identificar restricciones adicionales.
• 
  
• Identificar restricciones de negocio (3h). Esto se debe hacer con el grupo de negocio. ¿Cuánto tiempo tenemos?, ¿Hay limitaciones de presupuesto?, etc.
• 
  
• Identificar atributos de calidad (4h): De esta actividad puede participar todo el equipo.
• 
  
• Diseñar la arquitectura del sistema (8h).
• 
  
• Presentar las reglas que delimitarán la realización de la actividad.

El plan propuesto plantea aproximadamente 24 Horas para diseñar la arquitectura partiendo del supuesto de que el alcance ya está definido y entendido y 30 Horas partiendo de la definición del mismo.

Reglas

• Se debe respetar la palabra de quien está aportando.

• Se respeta el tiempo definido en el plan de trabajo, aún si los asistentes consideran que falta discutir algo (Siempre habrá algo por discutir).

• Todos pueden hacer parte de las discusiones que se generen en cada uno de los puntos del plan pero deben esperar su turno para hacerlo.

• Quien proponga algo debe justificarlo en torno a la funcionalidad, las restricciones técnicas o de negocio o los atributos de calidad. Si no lo puede justificar desde esta perspectiva entonces no se considera viable.

• El negocio es el responsable de delimitar el alcance, los otros grupos pueden hacer sugerencias pero es el negocio quien toma la decisión.

• Todo el equipo puede hacer parte de la selección de funcionalidades representativas.

• Todo el equipo puede hacer parte de la identificación de las necesidades de información.

• Las restricciones técnicas de infraestructura estarán principalmente en manos del grupo de operaciones aunque pueden recibir retroalimentación de otros grupos, restricciones en torno a decisiones de diseño previas u otros temas de implementación estarán en manos del grupo de desarollo.

• Las restricciones de negocio estarán principalmente en manos del grupo de negocio.

• Los atributos de calidad deben ser discutidos por todo el equipo.

• El diseño de la arquitectura estará liderado por el arquitecto pero debe recibir retroalimentación de todo el equipo. En este punto el grupo de negocio podria no estar presente.

Experiencia personal al participar de la actividad

• Es bastante complicado a demás de costoso, contar con la presencia de cada una de las personas que se proponen en los roles, pero es ideal que asistan porque de esta manera el diseño de la arquitectura será implícitamente validado por los interesados.

• En el ejercicio del cual participé como arquitecto solo asistieron los roles del grupo de desarrollo y negocio, el rol de moderador lo asumió el mismo arquitecto pero es bastante complicado jugar desde dos posiciones.

• Durante la ejecución de la actividad se evidenció bastante interés por parte de los interesados, personalmente lo disfruté mucho. Salir de la oficina y compartir con las personas a demás de valioso es divertido

• La cantidad de información que se recolecta en 30H en el peor de los casos es bastante valiosa, la visión de personas con diferentes perfiles la enriquece bastante y aterriza el diseño a la realidad.

• Durante la sesión de diseño la presencia del arquitecto es muy importante especialmente si quienes participan del ejercicio no tiene experiencia previa en el tema o no conocen tácticas y patrones de diseño.