Existem práticas recomendadas com relação à transferência da arquitetura para o desenvolvimento?

Estamos buscando melhorar o processo de entrega de tarefas da arquitetura ao desenvolvimento.

Em uma extremidade da escala, não há orientação de arquitetura que você corre o risco de ficar caótico, com cada desenvolvedor fazendo as coisas do seu jeito.

No outro extremo da escala, onde tudo é especificado, a especificação leva mais tempo que o desenvolvimento, e você corre o risco de ter tarefas de desenvolvimento muito chatas.

Alguém encontrou um meio termo ideal entre esses extremos? Quais artefatos você entrega ao desenvolvimento? Por exemplo: módulos, estrutura de classes ou diagramas de sequência?

Começarei dizendo que o próprio conceito de uma equipe separada de "Arquitetura" é uma afronta às boas práticas de desenvolvimento de software. As equipes de arquitetura em ambientes corporativos tendem a ser o culminar dos piores artistas pseudo-intelectuais da torre de marfim * * que podem ser encontrados entre os desenvolvedores.

Outras organizações tratam grupos de arquitetura como uma recompensa política e justificativa para um salário massivo para os membros mais graduados, independentemente do mérito, conhecimento ou habilidade. A maioria consiste em ambos os tipos.

Todo desenvolvedor pode e deve ser um arquiteto e deve estar envolvido nos projetos de alto nível de uma empresa. O próprio pensamento de que um único grupo tem controle ditatorial completo sobre todos os aspectos do design de software e que deve ser entregue a desenvolvedores que não contribuíram para o design, não entendem o raciocínio por trás das opções de design e podem entender falhas críticas no design, sendo mais confortável e mais próximo da implementação real e do código existente, é francamente completamente falho desde o seu âmago e resultará consistentemente em um dos três cenários:

• Os desenvolvedores não compreendem o design ou o rejeitam completamente devido às realidades da implementação atual e acabam determinando seu próprio design não documentado e implementando-o. A situação são documentos formais de design que não refletem a implementação do software.

• Os desenvolvedores seguem cegamente o design que pode ou não levar em consideração os requisitos atuais ou aspectos exclusivos das histórias de usuários, resultando em uma implementação de buggy e de baixa qualidade.

• Os desenvolvedores inteligentes que entendem os documentos de design e são capazes de implementá-los rapidamente ficam entediados por não estarem envolvidos nas discussões de design. É provável que eles sejam excluídos da participação no grupo Arquitetura devido a problemas políticos ou de antiguidade, para que fiquem frustrados, entediados e partam para pastos mais ecológicos. Isso afeta negativamente o projeto, resultando em uma fuga de cérebros, fazendo com que o ciclo vicioso de baixa qualidade do software continue.

A melhor maneira de mitigar esse problema é MUDAR o grupo Arquitetura e, possivelmente, colocá-los em posições de liderança em tecnologia. O papel do grupo de arquitetura deve ser mais ou menos um "scrum de líderes de tecnologia", se você desejar. Eles raramente devem se reunir e discutir apenas as questões de direção técnica de mais alto nível, por exemplo. pense em migrar do Java para o Scala, abandonando o Oracle para MySQL, possivelmente escrevendo bibliotecas de utilitários comuns que exigem um certo TIPO de processo de design em detrimento de outro, alternando do StarUML para o Altova UML.

O design real e real do software será um processo comunitário envolvendo TODOS os desenvolvedores de software, definidos pela direção de nível extremamente alto do grupo Arquitetura.

Sempre houve problemas no fluxo de informações da arquitetura para o teste e as operações de desenvolvimento. A maneira de resolver esses problemas depende de vários fatores, como:

• tamanho do software
• complexidade
• cultura em sua organização
• crença.

Para certas combinações desses fatores, uma abordagem ágil pura, equipes multifuncionais com design emergente é apropriada. A informação flui trabalhando juntos. As disciplinas documentam o que precisam.

Para outras combinações desses fatores, uma pequena equipe de arquitetos, testadores, especialistas em operações e desenvolvedores líderes pode começar com iterações da arquitetura lentamente construindo a arquitetura, documentando e obtendo feedback imediato sobre suas decisões de arquitetura. Lentamente, mais desenvolvedores que implementam recursos podem ser adicionados à equipe e a equipe principal original pode ser reduzida.

Principalmente para projetos governamentais e financeiros, é necessário que mais documentação seja escrita antecipadamente e que possa demorar muito tempo sem feedback do mundo real sobre suas escolhas. Na minha opinião, a maior razão pela qual muitos desses projetos falham. Ainda assim, se essa for sua situação, eu faria a documentação para atender aos requisitos. E, em seguida, use as opções 1 ou 2 para realmente construir o software e refinar / adaptar a documentação.

Espero que isto ajude.

Eu sei que isso não será muito popular, mas o comentário que você fez

No outro extremo da escala, se tudo estiver especificado, a especificação levará mais tempo que o desenvolvimento. E você corre o risco de ter tarefas de desenvolvimento muito chatas.

é realmente algo pelo qual você deve se esforçar. Se o design e a especificação forem sólidos o suficiente para que as tarefas de desenvolvimento sejam entediantes, o custo do desenvolvimento será reduzido. É muito menos caro consertar uma especificação do que consertar código, e o maior custo dos projetos de software não é a construção, é o suporte a longo prazo. E o código de suporte baseado em uma especificação sólida é muito mais barato.

Eu não concordo totalmente com a resposta do maple_shaft, mas não havia espaço suficiente no comentário para dizer minha parte inteira! ;-)

Concordo que todo desenvolvedor pode e deve ser um arquiteto, mas isso não significa que todo desenvolvedor deva ser responsável pela arquitetura de um produto ou sistema inteiro. Além disso, acho que você não pode pintar todas as equipes de arquitetura com o mesmo pincel largo e, quando bem feito, as equipes de arquitetura podem agregar muito valor ao processo geral de desenvolvimento de produtos. O equívoco é que os arquitetos devem ditar todos os aspectos do design do sistema. Em vez disso, eles devem se concentrar no design de nível superior e deixar os detalhes da implementação para suas equipes de desenvolvimento. No entanto, isso não quer dizer que os desenvolvedores não devam se envolver no processo de planejamento e design desde o início.

Quanto maior e mais modular e, por fim, mais complexo for um produto, maior a probabilidade de encontrar várias partes do produto manipuladas por diferentes equipes de desenvolvimento. Essas equipes não precisam entender o sistema como um todo, desde que tenham um entendimento completo das partes do sistema pelas quais são responsáveis. Freqüentemente, essas equipes adicionais são contratadas como subcontratadas com o objetivo específico de desenvolver um módulo em uma área específica de tecnologia na qual os arquitetos ou outras equipes talvez não tenham experiência. Meus talentos particulares residem no desenvolvimento de APIs, e ainda tenho que ver uma API bem fatorada que foi desenvolvida inteiramente organicamente sem ser uma bagunça completa em termos de usabilidade, ou que não exigia que alguém se destacasse como a pessoa que garantiu que havia um nível de uniformidade entre os diferentes aspectos da API. Posso continuar listando muitos exemplos e razões, mas não acho que esse tipo de situação seja a torre de marfim que muitos podem pensar que são. Infelizmente, existem muitos lugares, particularmente nas áreas de defesa, medicina e setores financeiros, nos quais a paranóia corporativa resulta em desenvolvimento de produtos mal especificado e ainda mais mal gerenciado, do tipo que tenho certeza de que o maple_shaft estava mais preocupado. Essas são as coisas que acredito que dão aos arquitetos um pouco de um nome ruim merecido (geralmente falando). Infelizmente, existem muitos lugares, particularmente nas áreas de defesa, medicina e setores financeiros, nos quais a paranóia corporativa resulta em desenvolvimento de produtos mal especificado e ainda mais mal gerenciado, do tipo que tenho certeza de que o maple_shaft estava mais preocupado. Essas são as coisas que acredito que dão aos arquitetos um pouco de um nome ruim merecido (geralmente falando). Infelizmente, existem muitos lugares, particularmente nas áreas de defesa, medicina e setores financeiros, onde a paranóia corporativa resulta em desenvolvimento de produtos mal especificado e ainda mais mal gerenciado, do tipo que tenho certeza de que o maple_shaft estava mais preocupado. Essas são as coisas que acredito que dão aos arquitetos um pouco de um nome ruim merecido (geralmente falando).

Então, onde está o meio termo que o OP estava procurando? A resposta tem tudo a ver com a abertura de canais de comunicação. Os arquitetos precisam entregar especificações que descrevam seus projetos com detalhes suficientes, para garantir que as equipes de desenvolvimento entendam onde estão os limites. Histórias e cenários de recurso no sentido mais amplo, onde tudo é considerado uma caixa preta. Os arquitetos precisam garantir que as equipes tenham acesso ao tempo do arquiteto para confirmar quaisquer suposições e responder a perguntas sobre especificações que pareçam muito amplas ou pouco claras. Depois disso, é realmente necessário garantir que as equipes individuais estejam cientes do que as outras equipes estão trabalhando e que elas sabem com quem se relacionar com as outras equipes para garantir que cada parte do sistema funcione bem com as outras partes. Essas equipes se encontram diretamente. Uma vez que o sistema foi projetado no nível mais amplo, os arquitetos devem ser apenas as pessoas para as quais as equipes se voltam quando precisam de uma verificação de sanidade e para garantir que a "visão" do produto seja mantida. Eles também devem levar em consideração qualquer processo de integração necessário e fornecer as coberturas necessárias para as equipes de desenvolvimento dos gerentes, clientes e outras partes interessadas, ao mesmo tempo em que garantem que essas várias pessoas possam se reunir para trabalhar entre eles como as coisas devem funcionar.

Os arquitetos da IMHO devem, antes de tudo, ser facilitadores e comunicadores e designers, em segundo. Quanto ao nível de especificação? Penso que os melhores arquitetos são os que perguntam às equipes sobre o nível de detalhe que uma equipe deseja e, entre eles, encontram um equilíbrio que funcione. Equipes diferentes podem ter requisitos diferentes em termos da quantidade de documentação ou direção necessária. As equipes seniores podem encontrar um diagrama mais elaborado e um bate-papo rápido pode ser suficiente para prosseguir, enquanto as equipes preenchidas com desenvolvedores relativamente jovens podem exigir um pouco mais para fazê-las funcionar. Acima de tudo, o arquiteto precisa incentivar os desenvolvedores a exercitar seus próprios talentos de design para obter o melhor resultado final de cada equipe.

Desde que você se esforça para melhorar algo, então você já sentiu um problema em seu processo. A causa raiz da situação específica pode ser a seguinte: Os desenvolvedores não podem se identificar com a arquitetura, porque ela lhes foi imposta por alguém externo. A entrega da arquitetura ao desenvolvimento provavelmente não resolverá essa causa raiz.

Faça da arquitetura uma parte da equipe de desenvolvimento. Derrube a fronteira entre o arquiteto e o desenvolvedor. Isso garante que a informação flua. Se a equipe de desenvolvimento participar da modelagem da arquitetura, ela não a considerará algo estranho. Infundir conhecimento sobre arquitetura na equipe. Ensine a eles os fatores determinantes da arquitetura corporativa para evitar o caos que você mencionou. Envolva os desenvolvedores quando forem necessárias decisões arquitetônicas para evitar o tédio que você mencionou. A transferência não é mais necessária e você cumpriu seu papel como arquiteto em uma equipe de desenvolvimento.

Você precisa fornecer o máximo de informações possível para a futura equipe manter o código. Se você não possui diagramas de sequência, por exemplo, o desenvolvedor é forçado a rastrear o código passo a passo, perdendo tempo.

Também há espaço para a nova equipe fazer suposições inválidas.

Em geral, deve haver um documento sobre o que é o projeto, as especificações técnicas, os casos de teste de unidade e os diagramas de sequência / classe.

Eu diria que os diagramas de classe exibem a criação de um modelo e o código é uma solução. O diagrama de classes representa a visão estática da arquitetura do seu projeto. Quero dizer que você tem pacotes> classes, interfaces, enum> atributos, métodos, etc ...> etc. Se você olhar bem, o metamodelo UML2 possui exatamente a mesma estrutura que um projeto java ou dotnet.

O que usamos em nossos projetos são simplesmente diagramas de classes que são salvos em um único modelo. Geramos visualizações do modelo, se o classificador já existe, ou criamos uma nova na gráfica, se for nova. Os desenvolvedores podem ver nossos diagramas e modelo porque salvos na raiz da pasta do projeto no CVS. O que eu gosto é que também o desenvolvedor pode modelar, porque se algo for alterado no nível do código, o modelo será atualizado automaticamente no CVS para toda a equipe.

Funciona muito bem e não é necessário conhecer a UML porque o diagrama de classes é realmente simples e a engenharia reversa fará o trabalho e criará a visualização gráfica do código. Navegação simples, visualizações avançadas e detalhadas, onde muitos comentários podem ser adicionados com diagramas sempre atualizados e visíveis no CVS diretamente no projeto. Meu diagrama de classes UML agora é Magic :-)