¿Cómo pueden los arquitectos trabajar con equipos Scrum autoorganizados?

20

Una organización con varios equipos ágiles de Scrum también tiene un pequeño grupo de personas designadas como "arquitectos empresariales". El grupo EA actúa como control y guardián de la calidad y el cumplimiento de las decisiones. Esto lleva a solapamientos entre la decisión del equipo y las decisiones de EA.

Por ejemplo, el equipo puede querer usar la biblioteca X o usar REST en lugar de SOAP, pero el EA no aprueba eso.

Ahora, esto puede llevar a la frustración cuando se anulan las decisiones del equipo. Llevado lo suficientemente lejos, puede conducir a una situación en la que la gente de EA "toma" todo el poder y el equipo termina desmotivado y no es muy ágil.

Las guías Scrum tienen esto que decir al respecto:

Autoorganizado: Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir el Backlog del Producto en Incrementos de funcionalidades potencialmente liberables.

¿Es eso razonable? ¿Debería disolverse el equipo de EA? ¿Deberían los equipos rechazar o simplemente cumplir?

Martin Wickman
fuente

Respuestas:

20

Un equipo de desarrollo está formado por 3–9 personas con habilidades interfuncionales que realizan el trabajo real.

Scrum Master debería invitar a "Enterprise Architect" a formar parte del equipo del proyecto. Entonces la comunicación entre el arquitecto y los programadores sería excelente.


fuente
2
Buen punto; Sin embargo, no veo cómo esto puede funcionar si hay varios equipos con los que trabajan los arquitectos.
sleske
1
"Oye, EA, ahora te sientas aquí y todavía te estás comunicando con las mismas personas. Solo que con más frecuencia". ¿Cómo exactamente ayuda esto a resolver alguno de los conflictos entre el EA y los otros desarrolladores?
Izkata
@sleske, ¿por qué no dividir el grupo de "arquitectos empresariales" entre equipos? o emplear más arquitectos? El problema es si la empresa quiere SCRUM y equipos ágiles, o algo así. Izkata, las reuniones diarias cambian mucho en la comunicación del equipo, en serio, cuando EA sentirá que él / ella es parte del DT y no un grupo de arquitectura extraterrestre, hay más posibilidades de un compromiso.
1
@ariwez: "¿por qué no dividir el grupo de" arquitectos empresariales "entre equipos?" Porque tenemos más equipos que arquitectos; También los arquitectos trabajan principalmente en problemas que afectan a múltiples equipos.
sleske
@sleske: "Individuos e interacciones sobre procesos y herramientas"
17

La elección de la tecnología utilizada es parte de los requisitos del software, lo que significa que es parte de la solicitud de características que no utilice ciertas tecnologías, por cualquier razón.

Los arquitectos hablan por los sistemas y la base de código porque los sistemas y la base de código no pueden hablar por sí mismos. Tener un arquitecto generalmente es lo mejor para los intereses a largo plazo de una empresa, especialmente uno que se basa en software que se construye internamente.

Los arquitectos no les están diciendo a los desarrolladores cómo convertir la acumulación en incrementos (sprints), están diciendo qué tecnologías pueden y no pueden usarse. Estás combinando dos problemas diferentes.

La solución es no cambiar nada. Si sus equipos se frustran porque los arquitectos son demasiado restrictivos o demasiado prepotentes, ese es un problema de personal que no tiene nada que ver con SCRUM y debe abordarse con las partes interesadas del negocio como un tema de satisfacción de los empleados y, si es posible, el resultado final ("Nos lleva x%más tiempo desarrollar características yporque el arquitecto zno nos deja usar Turbo Pascal").

Jonathan Rich
fuente
No se trata de la satisfacción personal, se trata de la productividad, la calidad y el cuidado del valor del producto. Supongo que los desarrolladores en los equipos pueden hacer esa distinción.
Martin Wickman
2
Alguien, en algún momento, tomó la decisión de que no puede. Por eso existen los arquitectos.
Jonathan Rich
44
Actualmente estoy trabajando en una aplicación del lado del servidor de triple pila que combina Rails, Java y .NET que realmente no necesitaba ser muy complicada. Entonces, sí, los guardianes pueden ser una buena cosa, pero las decisiones tecnológicas deben originarse con desarrolladores que lleguen a un consenso y la administración apruebe o comunique sus preocupaciones, no que los no desarrolladores tomen decisiones tecnológicas arbitrarias o tomen decisiones laterales en el medio del sprint.
Erik Reppen
44
@erik Y cuando tres equipos separados lleguen a sus tres decisiones de consenso separadas, es posible que obtenga una mezcla de Rails, Java y .Net.
MarkJ
@MarkJ si tiene tres equipos separados trabajando de forma aislada para la misma aplicación web del lado del servidor, se merece lo que obtiene.
Erik Reppen
6

Este tipo de cosas son necesarias para mantener el equilibrio entre la necesidad de un equipo grande para realizar el proyecto y la necesidad de mantener pequeños los equipos ágiles.

En general, el 'scrum líder del equipo' está compuesto por un miembro elegido de cada uno de los equipos más pequeños. Eso proporciona algo de la naturaleza autoorganizada, así como también proporciona algún tipo de representación para que las decisiones tomadas por el grupo de alto nivel sean aceptadas por el grupo ágil.

Para su escenario particular, algo debe hacer para detener la desmotivación del equipo ágil, pero probablemente no la rebelión o la simple aceptación. El equipo necesita darse cuenta de que estás allí para hacer un buen software, no para someterte a los ideales. Tener un montón de equipos diferentes, cada uno con diferentes tecnologías para hacer cosas similares en el mismo proyecto, conducirá a un software peor. Tener un montón de equipos diferentes que usan diferentes estándares de codificación en el mismo proyecto conducirá a un software peor.

Por lo tanto, necesitará alguna forma de llegar a un consenso sobre cómo va a funcionar el proyecto. El scrum líder del equipo se usa en otros lugares de manera efectiva. Es posible que deba hacer algo diferente o analizar por qué su grupo no lo está haciendo de manera efectiva.

Telastyn
fuente
2
Claro, pero darle la vuelta: obligar a todos los equipos a usar la misma tecnología horrible es aún más desagradable (todos siguen el mismo camino feo). Mientras que tener "diversidad" está obligado a producir al menos algunas soluciones que prosperarán.
Martin Wickman
2
@MartinWickman a veces hay decisiones comerciales detrás de la elección de tecnologías deficientes. Si el 80% de los desarrolladores en un mercado en particular tienen experiencia con tecnología deficiente, entonces puede tener mucho sentido comercial usar dicha tecnología porque le permite contratar contratistas cuando sea necesario. En un mercado pequeño, es posible que no pueda encontrar ningún programador de Python que valga la pena.
Jonathan Rich
@JonathanRich Cuando digo horrible, quiero decir horrible. Eso incluye no poder encontrar a nadie que lo sepa.
Martin Wickman
1
@ MartinWickman - Claro, estoy asumiendo que los desarrolladores de nivel superior designados (asignados o autoorganizados) no son idiotas completos.
Telastyn
1
@JonathanRich lógica de negocios defectuosa, OMI. Una mayor cantidad no significa una mayor proporción de calidad y se necesitan muchos menos desarrolladores de Python para hacer el trabajo si son al menos competentes.
Erik Reppen
5

La pregunta es: ¿Cuál es la razón por la que existe este equipo de Arquitectos? La única razón por la que puedo pensar es para hacer cumplir la interoperabilidad entre varios equipos. O los equipos están trabajando en varias partes de un solo producto y este equipo de arquitectos existe para mantener cada parte trabajando en conjunto.

Realmente no creo que este esquema pueda funcionar bien en un entorno ágil, por las razones exactas que usted dice. Los diversos equipos deben ser independientes y también lo deben ser sus entradas y salidas. Por lo tanto, restringir sus resultados solo debe ser parte de los requisitos de entrada. Pero esas limitaciones deberían ser razonables. Algo como "No debe usar la biblioteca X" no es un buen requisito, pero decir "Debe limitar al mínimo el número de bibliotecas de terceros usadas" o "Agregar nuevas bibliotecas, que no se usan en otros equipos debería ser limitado". debería estar bien.

Luego disolvería el equipo de arquitectos en todos los equipos y usaría su experiencia en cuestiones de arquitectura. Al formar parte del equipo, podrán ver mejor los problemas que tiene el equipo y podrían tener mejores ideas u opiniones más educadas sobre el cambio de las partes centrales de la arquitectura. También se debe alentar a los arquitectos de todos los equipos a que se comuniquen para garantizar que la arquitectura se mantenga constante en todos los equipos.

Eufórico
fuente
5

El grupo de Scaled Agile Framework habla muy bien de esto. La mayoría de nosotros tratamos a nivel de equipo, pero al escalar necesitamos reconocer que también hay roles que desempeñar a nivel de programa y cartera. Deben tomarse decisiones arquitectónicas en toda la organización, y eso debería alimentar lo que está sucediendo en los niveles inferiores de la organización. ¡No tiene nada de malo tomar decisiones arquitectónicas!

En relación con esto, el reciente libro de Dean Leffingwell sobre requisitos ágiles de software es una buena lectura sobre este tema, lo he estado leyendo yo mismo.

Jay S
fuente
4

También tenemos múltiples equipos ágiles (algunos hacen Kanban, algunos Scrum) y arquitectos. Los arquitectos son responsables de la infraestructura que abarca todos nuestros productos (bibliotecas auxiliares, autenticación, infraestructura de construcción), etc. Toman decisiones técnicas, pero también implementan cosas, principalmente componentes de infraestructura.

Esto funciona bien, y generalmente no hay conflicto. Creo que un punto crucial es:

Los arquitectos no tienen autoridad formal sobre los equipos, y no pueden simplemente anularlos. Normalmente, los arquitectos toman decisiones que se aplican a todos los productos, y los equipos toman decisiones para su producto. Si hay un conflicto, entonces el arquitecto y el equipo solo necesitan llegar a un acuerdo o escalar a la gerencia (aunque eso rara vez ocurre).

Creo que es realmente importante hacer que los arquitectos y desarrolladores sean pares. Ambos trabajan hacia un objetivo común, solo en diferentes áreas. Si nadie puede simplemente "anular" al otro, la cooperación será mejor.

sleske
fuente
2
Estar de acuerdo con @MartinWickman en que "límite" es la clave, en varios sentidos: en primer lugar, las opiniones de los arquitectos deben ser atendidas en los límites del software , donde se conectan componentes de múltiples equipos; secundario, que los arquitectos conozcan su propio límite de autoridad , por lo que se abstendrán de intervenir en las decisiones del equipo siempre que las decisiones no afecten la interoperabilidad.
rwong
3

No veo ningún conflicto aquí. Por lo que entiendo, todo el EA (como un título pomposo que creo que es) está destinado a hacer es QA. Todos deberían ser conscientes de eso.

Debe considerar que, en cualquier metodología de desarrollo (que merece ser considerada una), la recopilación de requisitos es un paso crucial, ya sea iterativo o inicial.

Algunos de estos requisitos están establecidos por la política de la empresa. Y estos establecen las reglas básicas:

  • El equipo tendrá que cumplir con ellos como con cualquier otro requisito. Desafiar la política simplemente queda fuera del alcance del proyecto y debe manejarse por separado.
  • El trabajo de EA es hacer cumplir estos requisitos y no imponer su imaginación personal. No les gusta X, esa es su opinión personal. Nada más y nada menos. Trátelo como cualquier otra opinión. Sin embargo, si el asesor experto puede demostrar que el uso de X viola un requisito existente, están en su derecho de prohibir el uso de X y si conocen una alternativa viable y el equipo no, entonces es su derecho hacerla cumplir.

Pero de cualquier manera, un requisito se cumple o no. Si esa determinación es difícil de hacer, entonces falta el requisito y debe reiterarlo para que sea verdaderamente comprobable (en un sentido más amplio). Debe manejar eso como cualquier requerimiento de reiteración.

back2dos
fuente
Claramente están haciendo más que control de calidad. Están tomando decisiones sobre el uso de herramientas.
Erik Reppen
@ ErikReppen: Estaba un poco confuso. Quise decir que el control de calidad es lo que se supone que deben hacer.
back2dos
@ back2dos: Creo que necesita cambiar el control de calidad para la estandarización. Sé lo que estás diciendo, pero QA es un equipo completamente diferente y confunde tu punto.
gbjbaanb
2

Su arquitecto no debe anular las decisiones tomadas por sus equipos ágiles. Su arquitecto debe incluir estos en los requisitos / historias pasados ​​a los equipos. Deben mantener a los equipos actualizados cuando cambie el panorama del proyecto y se introduzcan nuevos requisitos de interoperabilidad.

Los arquitectos que dan órdenes y examinan decisiones técnicas es un defecto cultural. Se ven a sí mismos como el "jefe" en lugar de simplemente mantener una meta / visión compartida y mantener equipos separados en la misma página. Las metodologías ágiles se basan en la comunicación y el contacto. Cuando sus arquitectos no se involucran hasta que se toman las decisiones, están fallando en la agilidad.

Sean McSomething
fuente
"Cuando sus arquitectos no se involucran hasta que se toman las decisiones, están fallando en la agilidad". - Si invertimos esta afirmación: "Cuando el equipo no involucra a los Arquitectos al tomar decisiones, entonces el equipo está fallando en la agilidad". Si el equipo toma decisiones que son un cambio en la tecnología, los patrones existentes, etc., entonces el equipo debe incluir un Arquitecto para garantizar que el producto en general siga siendo coherente.
Pitufo de Metro el
2

Martin, creo que puedes tener una idea errónea sobre cómo funciona un equipo autoorganizado en su entorno.

Usted citó la Guía de Scrum: "Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir la Cartera de Productos en Incrementos de funcionalidad potencialmente liberable".

Esta no es una licencia para que el equipo Scrum haga lo que quiera (siempre que lo haga) sin tener en cuenta las necesidades tecnológicas y comerciales de la empresa en su conjunto, y las necesidades de los otros equipos.

Seguro que los interesados ​​pueden abusar de su influencia. Ese es uno de los desafíos de la colaboración, y ciertamente no se limita al EA. Pero la colaboración no termina en el límite del equipo.

Bob Lieberman
fuente
0

Cascada o Scrum (esto parece mezclar dos, lo que sí, no va a funcionar), eso me parece una capa de administración bastante inútil en primer lugar. Los encargados de las decisiones tecnológicas deben ser desarrolladores principales, el gerente general de desarrollo cuyo trabajo debe ser evitar que las preferencias del desarrollador conviertan su aplicación en una hidra de opciones tecnológicas, y el presupuesto de quien tenga que pagar la factura potencial.

Nada me sigue asombrando como los no desarrolladores que realmente tienen el descaro de tomar decisiones tecnológicas sin siquiera consultar a las personas reales que tienen que sufrir las consecuencias de esas decisiones.

Erik Reppen
fuente
Esto se lee más como una queja que como una respuesta.
Bryan Oakley
Alguien tiene que hacerlo.
Erik Reppen