En un equipo ágil, ¿quién es responsable de tomar decisiones de arquitectura y diseño de alto nivel que afectan a todo el sistema, no solo al trabajo que se realiza en el sprint actual?
¿Quizás el dueño del producto, el scrum master, el equipo scrum o alguien más?
Respuestas:
fuente
Arquitectos, por supuesto, pero tal vez no los tipos tradicionales de arquitectos.
No me refiero al tipo de arquitecto cirujano principal que piensa todo y luego deja que los monos hagan todo el tipeo. Me refiero a un programador líder experimentado que comprende las compensaciones de costo / beneficio de las decisiones difíciles de revertir y que asesora a los equipos sobre qué hacer.
Los arquitectos efectivos son difíciles de encontrar, pero puede ser una posición fantástica, por lo que probablemente tenga al menos un programador experimentado y atento que pueda hacerlo bien. Tal persona necesita
Este último punto hace tropezar a mucha gente. Cuando los agilistas bien intencionados dicen cosas como "El equipo es dueño de la arquitectura", tienen ese "derecho", pero el consejo me parece casi completamente sin sentido en su aplicación. Si confiaras en que los equipos se responsabilizarían de su propia arquitectura, entonces no estarías haciendo la pregunta en primer lugar, ¿verdad? Por lo tanto, supongo que haces la pregunta porque hay alguna preocupación de que
Si necesita que alguien se haga responsable, déselo a quien quiera aceptarlo. Seriamente. Esa persona al menos se preocupa. Dele a esa persona los recursos que necesita para hacer el trabajo y ayúdelo cuando lo necesite. Probablemente no importa cuán competente sea la persona, porque si les importa, intentarán aprender lo que necesitan aprender. Naturalmente, esa persona necesita apoyo en forma de buenos libros para leer y una comunidad de compañeros y mentores a quienes pueden pedir ayuda y asesoramiento.
Si le preocupa que la persona equivocada se haga cargo de la responsabilidad, entonces espero que sepa quién es "la persona adecuada" y luchará para instalarla como arquitecto. Un libro como The New Strategic Selling lo ayudará a aprender las técnicas de venta para que eso suceda.
Si solo necesita un chivo expiatorio, empuje silenciosamente a otros para que le den la responsabilidad a la carrera de la persona que más le gustaría destruir o perjudicar. Al menos sé honesto al respecto.
Volviendo al trabajo de un arquitecto eficaz, pueden pensar en su trabajo como un puesto de gestión, en lugar de simplemente un puesto de toma de decisiones. Si no delegan al menos las decisiones más rutinarias a los equipos, se convertirán en un cuello de botella y ralentizarán a toda la organización . Agregar más arquitectos en la parte superior no hace que eso vaya más rápido. Cultivar mejores decisiones de arquitectura desde cero. La técnica de la junta de delegación ayudará a su arquitecto a sentirse más cómodo con el tiempo delegando más y más decisiones a los equipos a medida que esos equipos ganen confianza al mostrar competencia.
Pienso en un gran arquitecto como alguien que me ayuda a comprender cómo diseñar mejor mis sistemas, que me aconsejará pacientemente cuando lo solicite, y que ocasionalmente me impedirá tomar una decisión muy mala. Tal arquitecto actúa como un líder en el verdadero sentido de la palabra: alguien que otros siguen voluntariamente .
Sé que eso fue mucho.
Referencias
Miller, la nueva venta estratégica . Este libro incluye un modelo para comprender por qué no pudo cerrar una venta específica. Encuentro esto invaluable para entender por qué los compañeros de trabajo no harán lo obviamente maravilloso que estoy sugiriendo.
Weinberg, convertirse en un líder técnico . Este libro me ayudó a aprender cómo hacer la parte que no es arquitecto del trabajo efectivo del arquitecto.
Appelo, Delegation Boards y Delegation Poker . No subestimes lo difícil que es la delegación y cuánto apestamos. Aprende a hacerlo de manera más efectiva y más cómoda.
fuente
Por lo tanto, el equipo se autoorganiza para tomar decisiones arquitectónicas de la forma que considere conveniente. No existe una regla estricta y rápida, puede ir desde el consenso hasta un "consejo" de los miembros más importantes, hasta designar a un miembro en particular como la autoridad de arquitectura, hasta dejar que el arquitecto elija si hay un miembro con ese título de trabajo. .
fuente
Creo que la respuesta a "" ¿quién es responsable de tomar decisiones de arquitectura y diseño de alto nivel? "Depende del tamaño y la cantidad de equipos.
Para uno o dos equipos con 3-7 en cada equipo, entonces el equipo autoorganizado puede hacer con el liderazgo de los miembros senior.
Para 3 o más equipos, la mayor complejidad lleva a la necesidad de un equipo de arquitectura que pueda ver si los distintos sub-equipos están haciendo un trabajo que interactuará con los otros equipos. En mi experiencia, ese punto se alcanza cuando hay aproximadamente 8 equipos o alrededor de 50 personas.
fuente
Hay algunos recursos excelentes del equipo de Scaled Agile Framework (SAFe) en su sitio.
Básicamente, le ayuda a escalar ágilmente en su organización, yendo por encima de un lanzamiento único y en la planificación de carteras y programas. Su documentación muestra sugerencias sobre cómo involucrar a sus arquitectos empresariales y de sistemas en el proceso para introducir epopeyas arquitectónicas en el tren de lanzamiento.
Edite para mayor claridad para abordar la pregunta más directamente:
En un entorno ágil escalado, existen múltiples niveles de propiedad sobre la arquitectura. El ágil equipo de implementación será el propietario de la arquitectura emergente de bajo nivel refactorizando según sea necesario para continuar con la implementación de sus trabajos pendientes. Las decisiones arquitectónicas de nivel superior (sistemas operativos compatibles, navegadores, plataformas, bibliotecas) están bajo la responsabilidad de su sistema y arquitectos empresariales. Presentarán los casos de negocios para cuando estos cambios deben ocurrir y recomendarán que estos cambios arquitectónicos se agreguen al tren de lanzamiento para los equipos de implementación.
Por lo tanto, en lo que respecta a las decisiones de arquitectura de alto nivel que van más allá del sprint, generalmente las tomará a un nivel superior al equipo. Estos profesionales tradicionalmente ya tienen un rol de 'arquitecto' dentro de la empresa.
fuente
Creo que la mayoría de las otras respuestas están pensando en esto desde la perspectiva de estar dentro de un proyecto.
Si ese es el único nivel de arquitectura en una organización, el resultado será francamente un caos. He presenciado este caos de primera mano, lamentablemente sucede.
Según TOGAF, el Departamento de Arquitectura Empresarial hace planes de alto nivel para y con el negocio para crear y reemplazar el entorno de TI. Enterprise Architect habrá definido principios arquitectónicos y los ha firmado en los niveles más altos de la organización y ayudará a crear la arquitectura de alto nivel y los requisitos para cada proyecto. Cada proyecto se inicia para proporcionar un bloque de construcción arquitectónico en esa arquitectura de alto nivel.
Entonces, a nivel de proyecto, el Arquitecto de soluciones creará la arquitectura del proyecto (posiblemente de manera iterativa) y obtendrá la aprobación del Arquitecto de empresa.
Ahora, para centrarse en un proyecto ágil. Un proyecto ágil tiene requisitos. No tienen la forma de un "Documento de Requisitos" masivo, sino que son épicas e historias. Estas epopeyas aún requieren planificación. No envías a un equipo de desarrolladores en algunos sprints a lo desconocido. Usted sabe a un alto nivel lo que el sistema necesita hacer, con qué otros sistemas necesita interactuar y qué restricciones de hardware / sistema operativo / lenguaje tiene la organización y esto guía y limita las opciones arquitectónicas abiertas para el Arquitecto de soluciones. Por ejemplo, si usted está comprometido con el servidor .NET y SQL, que tendría que hacer una muycaso convincente para implementar un sitio de comercio electrónico basado en Magento usando PHP y MySQL debido a los costos involucrados en el soporte de dos bases de datos, dos idiomas, dos servidores web, etc. Alternativamente, un proyecto podría elegir usar una biblioteca completamente diferente o una apariencia diferente y sentir y esto podría tener implicaciones para todos los demás proyectos en vuelo. Es esencial tener la supervisión de un Arquitecto Empresarial para evitar que ocurra este tipo de "Deuda Arquitectónica".
fuente
Depende del diseño organizacional de la organización y si el producto está en una cartera. Las organizaciones más grandes y orientadas a roles pueden designar arquitectos de alto nivel para dirigir este tipo de actividades.
En general, un arquitecto sénior facilitará y guiará las decisiones de diseño, ya que no solo afectan la acumulación de productos, sino que pueden afectar varios productos en una cartera de productos.
Las compañías más pequeñas y ágiles pueden confiar en desarrolladores que son expertos en sistemas para liderar el equipo de desarrollo para alinearse con el diseño arquitectónico.
En última instancia, las decisiones arquitectónicas deben ser acordadas por el equipo de entrega que trabaja en el producto. Los arquitectos experimentados y los líderes tecnológicos se centrarán más en facilitar la discusión sobre cómo debería ser el diseño, en lugar de dictar el diseño.
fuente
Creo que la mayoría de las respuestas ya destacan que el equipo, ni una sola persona, debería tomar estas decisiones.
Lo que no tocan es otro principio ágil:
Pensar en arquitecturas de alto nivel y decisiones de diseño a menudo no se toman con la simplicidad en mente, lo que posiblemente lleve a desperdiciar mucho esfuerzo y a agregar una complejidad innecesaria que podría hacer que las cosas sean más difíciles de extender.
Durante su iteración actual, debe tomar decisiones de arquitectura y diseño para sus necesidades actuales. En lugar de mirar hacia un futuro que nunca podría convertirse, concéntrese solo en lo que necesita ahora. Probablemente YAGNI, una arquitectura bien pensada ahora, deje que el equipo lo maneje poco a poco.
Otras lecturas:
fuente