Tom Hollander, um arquiteto de solução da Microsoft da Australia fez uma apresentação entitulada "O Papel de um Arquiteto em Uma Equipe Ágil" no TechEd na Australia, onde falou sobre qual é o papel principal de um arquiteto em uma equipe ágil.
Ao falar sobre o papel do "arquiteto de soluções", Hollander não se refere a um arquiteto corporativo ou um especialista (especializado em um campo específico como servidor de email ou infra-estrutura).
A equipe de Hollander tem um processo iterativo com duração de 4 semanas, utilizando práticas de reuniões diárias em pé, integração contínua com compilações diárias seguidas de testes automatizados, e está inserindo outras funcionalidades:
- PjM: Gerente de Projeto (Project Manager), semelhante ao Scrum Master, que verifica se a equipe está seguindo o processo.
- PdM: Gerente do Produto (Product Manager), também conhecido como Cliente ou Product Owner, ele determina o que o produto deve fazer, ou seja, as funcionalidades requeridas.
- Arquiteto: responsável por propor a solução e arquitetura da aplicação.
- Dev: equipe de desenvolvimento.
- Teste: equipe de teste.
- UX: equipe de experiência do usuário (User experience team).
- Release: responsável pelo processo de compilação e liberação de uma versão.
Hollander criou uma lista com as 10 maiores sugestões para um Arquiteto de Solução ser bem sucedido em uma equipe ágil:
- Design inicial do projeto, apenas o necessário (Just enough): apenas para projetos muito simples, onde existem uma certa quantidade inicial de design (01 à 02 semanas) é absolutamente necessário de acordo com o tipo de aplicação (aplicações web, sistemas inteligentes, aplicações móveis ou batch), que são os requisitos de funcionalidades básicas para aplicações de curto, médio e longos prazos. A finalidade de um design durante o início do projeto, é para decidir: qual a tecnologia a utilizar (ASP.NET ou MVC), qual o tipo da aplicação (2 ou 3 camadas, ou aplicações orientadas a serviços), acesso ao banco de dados (utilizar Stored Procedures, ou algum framework, LINQ, DI). Ou seja, tudo que pode ser contido em um documento curto, de referência.
- Comece com uma fatia vertical: significa iniciar o projeto com um pequeno pedaço de uma funcionalidade, uma página de login de acesso, por exemplo, que utiliza muitas das tecnologias selecionadas na fase anterior, de Design Inicial do Projeto. Isso irá demonstrar se as soluções de design escolhidas estão corretas e se todas elas conseguem trabalhar em conjunto, representando um padrão a ser seguido pelos desenvolvedores para implementar novos códigos. Portanto, se as decisões iniciais de design tornarem-se inadequadas, agora é uma boa hora para mudá-las.
- Resposta imediata (Just-in-time) de design a cada iteração: no meio da quarta semana de iteração, o gerente do projeto, o gerente do produto e o arquiteto do projeto devem se reunir para discutirem os requisitos que deverão compor a próxima iteração, para terem a certeza de que todos concordam com esses requisitos, e ainda para definirem a prioridade de cada requisito, e se todos estão de acordo. Essa discussão se estende durante a semana da iteração atual. Durante a última semana da iteração atual, o arquiteto revisa os requisitos para a pŕoxima iteração, tomando as decisões de projeto necessárias para que a equipe possa trabalhar nos requisitos na semana seguinte. Se os requisitos forem bem diferentes dos anteriores, o arquiteto faz alguns protótipos, codifica algo próximo do esperado, e escreve alguns diagramas, colocando tudo em um documento de referência de até 5 páginas. Isso não significa em detalhar as soluções para o desenvolvedor, mas fazer com que os novos requisitos estejam em de acordo com o esperado.
- Confie na sua equipe... mas esteja disponível para ela: isso tem a ver com o relacionamento entre o arquiteto e o desenvolvedor. Mas o arquiteto não pode ultrapassar o seu papel, para não tomar todas as decisões sozinho, a fim de não tornar chato o trabalho dos desenvolvedores. Ao mesmo tempo, o arquiteto precisa ser um mentor para a equipe, resolvendo os problemas difíceis que possam deixar os desenvolvedores muito atarefados. O arquiteto deve estar em contato todos os dias com cada desenvolvedor, para saber o que eles estão fazendo, e ajudá-los em caso existe algum problema de codificação. Isso é especialmente necessário quando se trata de desenvolvedores que não gostam de pedir ajuda e tentam resolver os problemas sozinhos, podendo até mesmo passar uma semana inteira resolvendo. Esse tipo de relacionamento também se aplica ao PjM (gerente de projeto) e a todos da equipe.
- Escrever o código!: o arquiteto deve compreender o código para ter uma melhor ideia do impacto de suas decisões. Ele também pode verificar quando um refatoramento é necessário. Quando um arquiteto também implementa um código, ele ganha mais credibilidade da equipe. Hollander afirma que isso não é uma dissolução de atribuições, pois o arquiteto continua sendo um arquiteto, e é fato que ele não necessariamente implementa um código tão bem quanto um desenvolvedor.
- Esteja envolvido em tudo: é bom para o arquiteto estar envolvido em todas as reuniões relacionadas ao seu projeto: proposta de solução, desenvolvimento, revisão de código, planejamento dos requisitos, etc. Porque ele pode ter uma visão mais ampla e clara de perspectiva do que está acontecendo, podendo ajudar o gerente do produto a evitar tomar decisões erradas em seu estágio inicial, informando-lhes sobre os possíveis resultados.
- Conduza uma cultura de qualidade: uma equipe bem sucedida, que qualquer um gostaria de fazer parte, é construída sobre uma cultura de qualidade: ninguém verifica um código mal elaborado, uma falha importante no projeto não passa despercebida, todos os membros são honestos e abertos, e procuram pelo melhor resultado de toda a equipe. Hollander admite que é difícil construir uma equipe assim, mas é possível. Em primeiro lugar, o arquiteto deve estabelecer algumas regras no início, que não serão modificadas com o tempo caso algum membro da equipe não esteja satisfeito com elas. Um exemplo de uma regra é a decisão de se escrever testes de unidade, outra é ter a revisão de código antes de declará-lo como pronto, incluindo os códigos implementados pelo arquiteto. Assim, se o código não for aceito pelo revisor, que pode ser qualquer um da equipe, o código não está finalizado.
- Saber quando mudanças são necessárias: o arquiteto deve ser muito flexível e pronto para fazer as mudanças de design quando são necessários, pois pode ser que uma solução rápida não seja adequada, ou os novos requisitos exigem uma abordagem diferente.
- Proteja o time de interferências externas: embora isso seja geralmente o trabalho de um gerente de projetos / Scrum Master, o arquiteto pode se envolver e proteger a equipe de interferências externas, que geralmente desviam o foco da equipe e toma muito tempo de trabalho. Um exemplo pode ser as solicitações originadas da equipe de operação que deseja que certas coisas sejam feitas de uma determinada maneira, e essas solicitações não são sempre necessárias para serem implementadas.
- Escreve documentos... mas somente se alguém precisar lê-los: Hollander não é a favor de documentar tudo, nem tão pouco de não escrever nenhuma documentação. Ele acha que é necessário saber equilibrar, escrevendo documentações úteis que são lidas por alguém. Documentos são bons para lembrar detalhes de decisões como um modelo de dados, assim como as decisões de design de uma iteração, que quando são discutidas com a equipe no inicio da iteração, é recomendado que seja salvo em um documento de até 05 páginas, para que os desenvolvedores possam consultá-lo em caso de não lembrar das decisões do arquiteto. Isso ajuda a novos membros de um projeto a compreenderem por que determinadas decisões foram tomadas, caso posteriormente os desenvolvedores e o arquiteto do início do projeto forem transferidos para um outro projeto.
Para concluir, Hollander disse que o arquiteto deve saber que ele faz parte da equipe na teoria e na prática. O arquiteto não deve escrever todo o código, somente um pedaço. Ele não é o testador ou o implantador, mas sim o responsável para que todo o processo ocorra bem.