Modelos ArchiMate para Equipes Ágeis (Parte 2)
Postado em 13 de ago. de 2022 por Antonio Plais
Originalmente postado por Marc Lankhorst*, no blog da Bizzdesign – Adaptação e tradução autorizadas
Na primeira postagem desta série, discutimos de forma geral como a estrutura da linguagem de modelagem ArchiMate coincide com a estrutura tanto de equipes de componentes como de equipes de funcionalidades. Nesta segunda parte, gostaríamos de ir um pouco mais fundo neste assunto..
Independente de como as equipes ágeis são estruturadas, você sempre separa necessariamente algumas preocupações e combina algumas outras. Conhecer e compreender essas dependências é importante para qualquer configuração com múltiplas equipes. Você quer evitar dividir as coisas que são intimamente acopladas, por exemplo, que tenham um alto grau de dependência, entre várias equipes. Isso resultaria em uma sobrecarga de comunicação desnecessária entre estas equipes. Conhecer essas dependências, naturalmente, é também o primeiro passo para reduzi-las.
Tanto para equipes de componentes como de funcionalidades, saber quem está trabalhando em quais partes de uma solução é essencial para evitar conflitos, lacunas, sobreposições e retrabalho. Tipicamente, cada equipe é completamente responsável pelos trabalhos internos naquilo que eles constroem, isso é, a sua arquitetura e desenho do software. Eles podem usar qualquer coisa que eles escolham para desenhar isso, desde rascunhos em quadros brancos até alguns modelos ArchiMate simples, e equipes diferentes podem trabalhar de forma diferente. Como essas partes se relacionam umas com as outras é onde as coisas deveriam ser padronizadas de alguma forma, de maneira que todas as equipes tenham o mesmo entendimento.
Uma técnica comum para capturar essas dependências é usar fios em um quadro Kanban ou Scrum, mas isso não escala bem através de quantidades maiores de equipes e de equipes de equipes (estender esses fios através da sua área de trabalho de quadro para quadro seria um experiência bastante interessante…), sem mencionar quando você tem equipes em vários locais. Mais ainda, existem muitos tipos de dependência, e uma análise delas apenas observando as diferentes cores dos fios não é assim tão fácil.
Dependências em um quadro Scrum (fonte: blog.xebia.fr)
Yma visão geral da sua arquitetura em termos dos principais elementos de estrutura e comportamento (ou seja, componentes e funcionalidades), e de suas dependências, ajuda a definir a estrutura das equipes e suportar a comunicação entre elas. É aqui, por exemplo, onde um conjunto de visões ArchiMate sobre a comunicação entre os componentes de aplicativo no seu panorama pode ser um importante artefato de desenho. Mais ainda, gerenciar e compartilhar estas visões por meio de uma ferramenta adequada é muito mais conveniente do que espalhar fios através do seu espeço de trabalho. Um exemplo de um panorama de arquitetura como esse é mostrado na figura abaixo, anonimizado e um pouco simplificado, obtido de um cliente de referência no setor de seguros.
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da Bizzdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.
eBook
A Prática da Arquitetura Corporativa
Esta é uma versão eletrônica do livro A Prática da Arquitetura Corporativa, de Bas van Gils e Sven van Dijk, traduzido pela Centus Consultoria. Este livro não propõe um novo framework, teoria, ou abordagem para a Arquitetura Corporativa. Ao invés disto, os autores compartilham a experiência e as lições de vários projetos que conduziram ao […]