Requisitos de arquitectos fuera del equipo Scrum

Hace algún tiempo me preguntaron qué opinaba sobre encargar a los “Sabios Arquitectos” de una empresa la supervisión técnica de los distintos equipos de proyecto. A menudo escucho el argumento de que estos arquitectos no forman parte del equipo y, por lo tanto, no deberían decidir cómo el equipo desarrolla algo…

…sin embargo, ese no es un argumento especialmente bueno, ya que hay suficientes personas externas que también imponen requisitos a un equipo. No obstante, estos requisitos siempre son filtrados por el Product Owner – él decide si son importantes o no.

“Sabios Arquitectos” no hacen propuestas de solución

Un “Sabio Arquitecto” suele dar al equipo requisitos no funcionales, que yo considero más bien como condiciones o restricciones. Por lo tanto, no puede indicarle al equipo cómo resolver un problema. Pero sí puede establecer ciertas directrices, por ejemplo: “El sistema debe poder escalarse a un número determinado de usuarios concurrentes (usuarios que acceden al sistema simultáneamente)”, “debe procesar X transacciones por minuto”, “debe funcionar en Linux”, “debe poder integrarse con esto y aquello”, etc.

Los requisitos no funcionales se convierten en Product Backlog Items y pueden ser priorizados por el Product Owner según la importancia que les otorgue. Si, por ejemplo, no considera determinante que el sistema funcione en Linux y podría funcionar igualmente bien en otro sistema operativo, el Product Owner puede eliminar ese requisito o moverlo hacia abajo en el Product Backlog (para que el equipo al menos pueda ver que el arquitecto lo desea).

Este texto proviene del blog de Mike Cohn y fue traducido al español.