Como os arquitetos podem trabalhar com equipes Scrum auto-organizadas?

20

Uma organização com várias equipes ágeis do Scrum também possui um pequeno grupo de pessoas nomeadas como "arquitetos corporativos". O grupo EA atua como controle e gatekeeper para qualidade e aderência às decisões. Isso leva a sobreposições entre a decisão da equipe e as decisões da EA.

Por exemplo, a equipe pode querer usar a biblioteca X ou o REST em vez do SOAP, mas o EA não aprova isso.

Agora, isso pode levar à frustração quando as decisões da equipe são anuladas. Levando longe o suficiente, pode levar a uma situação em que o pessoal da EA "agarra" todo o poder e a equipe acaba se sentindo desmotivada e não muito ágil.

Os guias do Scrum têm a dizer sobre isso:

Auto-organização: ninguém (nem mesmo o Scrum Master) diz à equipe de desenvolvimento como transformar o Backlog do produto em incrementos de funcionalidade potencialmente liberável.

Isso é razoável? A equipe da EA deve ser dissolvida? As equipes devem recusar ou simplesmente cumprir?

Martin Wickman
fonte

Respostas:

20

Uma equipe de desenvolvimento é composta por 3 a 9 pessoas com habilidades multifuncionais que realizam o trabalho real

O Scrum Master deve convidar o "Enterprise Architect" para fazer parte da equipe do projeto. Então a comunicação entre arquiteto e programadores seria excelente.


fonte
2
Bom ponto; no entanto, não vejo como isso funcionará se houver várias equipes com as quais os arquitetos trabalham.
sleske
1
"Ei, EA, agora você está sentado aqui e ainda está se comunicando com as mesmas pessoas. Apenas com mais frequência." Como exatamente isso ajuda a resolver qualquer conflito entre o EA e os outros desenvolvedores?
precisa saber é o seguinte
@lesleske, por que não dividir o grupo "arquitetos corporativos" entre equipes? ou empregar mais arquitetos? o problema é que a empresa deseja equipes SCRUM e ágeis, ou ainda scrumish. Izkata, as reuniões diárias mudam muito na comunicação da equipe, seriamente, quando a EA sentir que faz parte da DT e não um grupo de arquitetura extraterrestre, há melhores chances de um compromisso.
1
@ariwez: "por que não dividir o grupo" arquitetos corporativos "entre equipes?" Porque temos mais equipes que arquitetos; também os arquitetos trabalham principalmente em problemas que afetam várias equipes.
sleske
@sleske: "Indivíduos e interações sobre processos e ferramentas"
17

A escolha da tecnologia usada faz parte dos requisitos do software, o que significa que faz parte da solicitação de recurso que você não use determinadas tecnologias, por qualquer motivo.

Os arquitetos falam pelos sistemas e pela base de código porque os sistemas e a base de código não podem falar por si mesmos. Ter um arquiteto geralmente é do interesse de longo prazo de uma empresa, especialmente uma que se baseia em software construído internamente.

Os arquitetos não estão dizendo aos desenvolvedores como transformar o backlog em incrementos (sprints), estão dizendo quais tecnologias podem ou não ser usadas. Você está confundindo duas questões diferentes.

A solução é não mudar nada. Se suas equipes estão frustradas porque os arquitetos são muito restritivos ou arrogantes, esse é um problema de pessoal que não tem nada a ver com o SCRUM e deve ser tratado com as partes interessadas da empresa como uma questão de satisfação dos funcionários e, se possível, os resultados finais ("Levamos x%mais tempo para desenvolver recursos yporque o arquiteto znão nos permite usar o Turbo Pascal.")

Jonathan Rich
fonte
Não se trata de satisfação pessoal, é de produtividade, qualidade e preocupação com o valor do produto. Presumo que os desenvolvedores das equipes possam fazer essa distinção.
27613 Martin Mickick
2
Alguém, em algum momento, tomou a decisão de que não pode. É por isso que os arquitetos existem.
Jonathan Rico
4
Atualmente, estou trabalhando em um aplicativo do lado do servidor de pilha tripla que mistura Rails, Java e .NET que realmente não precisava ser muito complicado. Portanto, sim, os gatekeepers podem ser uma coisa boa, mas as decisões tecnológicas devem se originar com os desenvolvedores chegando ao consenso e na aprovação da gerência ou comunicando preocupações, não os não-desenvolvedores que tomam decisões arbitrárias de tecnologia ou tomam as decisões da equipe de desenvolvedores no meio de um sprint.
Erik Reppen
4
@erik E quando três equipes separadas chegarem às três decisões de consenso separadas, você poderá obter uma mistura de Rails, Java e .Net.
MarkJ
@ MarkJ se você tiver três equipes separadas trabalhando isoladamente para o mesmo aplicativo Web do servidor, você merece o que recebe.
amigos estão dizendo
6

Esse tipo de coisa é necessária para manter o equilíbrio entre a necessidade de uma equipe grande para concluir o projeto e a necessidade de manter as equipes ágeis pequenas.

Geralmente, o 'scrum do líder da equipe' é composto por um membro eleito de cada uma das equipes menores. Isso fornece parte da natureza auto-organizada e também fornece algum tipo de representação para que as decisões tomadas pelo grupo de alto nível sejam aceitas pelo grupo ágil.

Para o seu cenário específico, algo deve ser feito para interromper a desmotivação ágil da equipe, mas provavelmente não a rebelião ou a simples aceitação. A equipe precisa perceber que você está lá para criar um bom software, e não respeitar os ideais. Ter um monte de equipes diferentes, cada uma usando tecnologias diferentes para fazer coisas semelhantes no mesmo projeto, levará a um software pior. Ter um monte de equipes diferentes usando diferentes padrões de codificação no mesmo projeto levará a um software pior.

Então, você precisará de alguma maneira de chegar a um consenso sobre como o projeto vai funcionar. O scrum do líder da equipe é usado em outros lugares de maneira eficaz. Pode ser necessário fazer algo diferente ou investigar por que seu grupo não está fazendo isso de maneira eficaz.

Telastyn
fonte
2
Claro, mas mudando de idéia: forçar todas as equipes a usar a mesma tecnologia ruim é ainda mais desagradável (todas seguem o mesmo caminho feio). Considerando que ter "diversidade" é obrigado a produzir pelo menos algumas soluções que prosperarão.
precisa
2
@MartinWickman às vezes há decisões de negócios por trás da escolha de tecnologias ruins. Se 80% dos desenvolvedores de um mercado específico têm experiência com tecnologia de baixa qualidade, pode fazer muito sentido para os negócios usar essa tecnologia, pois permite contratar contratados quando necessário. Em um mercado pequeno, talvez você não consiga encontrar nenhum programador Python que valha a pena.
Jonathan Rico
@ JonathanRich Quando digo porcaria, quero dizer porcaria. Isso inclui não ser capaz de encontrar alguém que saiba disso.
precisa
1
@MartinWickman - Claro, estou assumindo que os desenvolvedores designados de primeira linha (atribuídos ou auto-organizados) não são idiotas completos.
Telastyn
1
@ JonathanRich falha na lógica de negócios, IMO. Quantidade maior não significa maior proporção de qualidade e são necessários muito menos desenvolvedores Python para fazer o trabalho, se eles são pelo menos competentes.
precisa
5

A pergunta é: Qual é o motivo pelo qual essa equipe de arquitetos existe? A única razão pela qual consigo pensar é impor a interoperabilidade entre várias equipes. Ou as equipes estão trabalhando em várias partes do único produto e essa equipe de arquitetos existe para manter todas as partes trabalhando juntas.

Realmente não acho que esse esquema possa funcionar bem em ambiente ágil, por motivos exatos que você diz. As várias equipes devem ser independentes e, assim, suas entradas e saídas. Portanto, restringir suas saídas só deve fazer parte dos requisitos de entrada. Mas essas restrições devem ser razoáveis. Algo como "Não deve usar a biblioteca X" não é um bom requisito, mas dizer "Deve limitar o número de bibliotecas de terceiros usadas ao mínimo" ou "A adição de novas bibliotecas que não são usadas em outras equipes deve ser limitada". deve ficar bem.

Depois, eu dissolvia a equipe do arquiteto em todas as equipes e usava seus conhecimentos em questões de arquitetura. Ao se tornar parte da equipe, eles poderão ver melhor os problemas que a equipe está enfrentando e podem ter idéias melhores ou opiniões mais instruídas sobre a alteração das principais partes da arquitetura. Também deve ser incentivado que os arquitetos das equipes se comuniquem para garantir que a arquitetura permaneça consistente entre as equipes.

Eufórico
fonte
5

O grupo no Scaled Agile Framework fala muito bem disso. A maioria de nós lida com o nível de equipe, mas ao expandir, precisamos reconhecer que há papéis a desempenhar também no nível de programa e portfólio. As decisões de arquitetura precisam ser tomadas em toda a organização, e isso deve alimentar o que está acontecendo nos níveis mais baixos da organização. Não há nada de errado em tomar decisões arquitetônicas!

Relacionado a isso, o livro recente de Dean Leffingwell sobre requisitos de software ágil é uma boa leitura sobre esse tópico, eu mesmo já o li.

Jay S
fonte
4

Também temos várias equipes ágeis (algumas fazem Kanban, outras Scrum) e arquitetos. Os arquitetos são responsáveis ​​pela infraestrutura que abrange todos os nossos produtos (bibliotecas auxiliares, autenticação, construção de infraestrutura) etc. Eles tomam decisões técnicas, mas também implementam coisas, principalmente componentes de infraestrutura.

Isso funciona bem, e geralmente não há conflito. Eu acredito que um ponto crucial é:

Os arquitetos não têm autoridade formal sobre as equipes e não podem simplesmente substituí-las. Normalmente, os arquitetos tomam decisões que se aplicam a todos os produtos e as equipes tomam decisões para seus produtos. Se houver um conflito, o arquiteto e a equipe precisam apenas chegar a um acordo ou encaminhar para o gerenciamento (embora isso raramente aconteça).

Eu acho que é realmente importante fazer com que arquitetos e desenvolvedores sejam pares. Ambos trabalham em direção a um objetivo comum, apenas em áreas diferentes. Se ninguém pode simplesmente "anular" o outro, a cooperação será melhor.

sleske
fonte
2
Concordando com @MartinWickman que "limite" é a chave, em vários sentidos: primeiro, as opiniões dos arquitetos devem ser atendidas nos limites do software , onde componentes de várias equipes se conectam; secundário, que os arquitetos conhecem seus próprios limites de autoridade , para que não tomem as decisões da equipe desde que as decisões não afetem a interoperabilidade.
Rwong
3

Não vejo nenhum conflito aqui. Pelo que entendi, todo o EA (como um pomposo título que acho que é) deve fazer é o controle de qualidade. Todo mundo deveria estar ciente disso.

Você deve considerar que, em qualquer metodologia de desenvolvimento (que mereça ser considerada uma), a coleta de requisitos é uma etapa crucial, seja iterativa ou inicial.

Alguns desses requisitos são definidos pela política da empresa. E eles estabelecem as regras básicas:

  • A equipe terá que cumpri-los como em qualquer outro requisito. O desafio da política está simplesmente fora do escopo do projeto e deve ser tratado separadamente.
  • O trabalho da EA é impor esses requisitos e não impor sua fantasia pessoal. Eles não gostam do X, então essa é a sua opinião pessoal. Nada mais nada menos. Trate-o como qualquer outra opinião. No entanto, se o EA puder mostrar que o uso do X viola um requisito existente, eles têm todo o direito de proibir o uso do X e se eles conhecem uma alternativa viável e a equipe não, então é seu direito aplicá-los.

Mas de qualquer forma, um requisito é atendido ou não. Se essa determinação é difícil de fazer, o requisito está ausente e você precisa reiterá-lo para se tornar verdadeiramente testável (em um sentido mais amplo). Você deve lidar com isso como qualquer reiteração de requisitos.

back2dos
fonte
Eles claramente estão fazendo mais do que o controle de qualidade. Eles estão tomando decisões sobre o uso de ferramentas.
precisa
@ErikReppen: Eu estava um pouco confuso. Eu quis dizer controle de qualidade é o que eles deveriam fazer.
precisa saber é o seguinte
@ back2dos: acho que você precisa alterar o controle de qualidade da padronização. Eu sei o que você está dizendo, mas o controle de qualidade é uma equipe completamente diferente e confunde o seu ponto de vista.
Gbjbaanb
2

Seu arquiteto não deve anular as decisões tomadas por suas equipes ágeis. Seu arquiteto deve incluí-los nos requisitos / histórias passados ​​para as equipes. Eles devem manter as equipes atualizadas quando o cenário do projeto mudar e novos requisitos de interoperabilidade forem introduzidos.

Arquitetos dando ordens e examinando decisões técnicas é uma falha cultural. Eles se vêem como o "chefe", em vez de simplesmente manter um objetivo / visão compartilhada e manter equipes separadas na mesma página. Metodologias ágeis são baseadas em comunicação e contato. Quando seus arquitetos não se envolvem até que as decisões sejam tomadas, eles falham na agilidade.

Sean McSomething
fonte
"Quando seus arquitetos não se envolvem até que as decisões sejam tomadas, eles fracassam na agilidade". - Se invertermos esta afirmação: "Quando a equipe não envolve os arquitetos na tomada de decisões, a equipe falha na agilidade". Se houver decisões sendo tomadas pela equipe que sejam uma mudança na tecnologia, nos padrões existentes, etc ..., a equipe precisará incluir um arquiteto para garantir que o produto geral permaneça coeso.
Metro Smurf
2

Martin, acho que você pode ter uma idéia errada sobre como uma equipe auto-organizada funciona em seu ambiente.

Você citou o Guia Scrum: "Ninguém (nem mesmo o Scrum Master) diz à equipe de desenvolvimento como transformar o Backlog do produto em incrementos de funcionalidade potencialmente liberável".

Essa não é uma licença para a equipe do Scrum fazer o que quiser (desde que seja entregue) sem levar em consideração as necessidades de tecnologia e negócios da empresa como um todo e as necessidades das outras equipes.

Claro que as partes interessadas podem abusar de sua influência. Esse é um dos desafios da colaboração e certamente não se limita ao EA. Mas a colaboração não termina nos limites da equipe.

Bob Lieberman
fonte
0

Waterfall ou Scrum (isso parece misturar dois, o que sim, não vai funcionar), isso parece uma camada de gerenciamento bastante inútil para mim em primeiro lugar. Os guardiões das decisões de tecnologia devem ser os principais desenvolvedores, o gerente geral de desenvolvimento, cujo trabalho deve ser impedir que as preferências dos desenvolvedores transformem seu aplicativo em uma hidra de opções tecnológicas, e quem quer que o orçamento tenha que pagar a conta em potencial.

Nada continua me impressionando, como os não-desenvolvedores realmente tendo a ousadia de tomar decisões tecnológicas sem sequer consultar as pessoas reais que sofrem as conseqüências dessas decisões.

Erik Reppen
fonte
Isso parece mais um discurso retórico do que uma resposta.
Bryan Oakley
Alguém tem que fazer isso.
precisa saber é o seguinte