timeBox

Já trabalhei em diversos projetos que continham como parte de sua documentação um SAD (Software Architecture Description) normalmente criado a partir de um template do RUP. Sem entrar em muitos detalhes, posso dizer que um SAD serve para documentar aspectos arquiteturais de forma geral, fornecendo varias visões complementares sobre o sistema. A ideia é que esse documento vá amadurecendo ao longo do projeto. O iniciamos de forma tímida e o detalhemos melhor a medida em que a arquitetura for ficando mais estável. Dessa forma, teremos um ótimo guia de entendimento arquitetural para futuras equipes que venham a dar manutenção no sistema.

Ok. Vamos produzir SADs em nossos projetos então!
Mas….
Porque tendemos a achar que esse documento também é muito bom para comunicar (informar, ensinar) a própria equipe envolvida atualmente no projeto sobre a arquitetura do mesmo? Pergunto isso justamente pelas experiências que tive nos projetos em que o usei. Nesses projetos, o principal movitador de criação do SAD era a ideia de disseminar o conhecimento referente a arquitetura do sistema para os membros da equipe de desenvolvimento, que na maioria das vezes, estavam unidos em um mesmo local.

….
Pra falar a verdade, na maioria das vezes a “equipe de desenvovimento” trabalhava remotamente (estratégia “fábrica de código”), então problemas como falha de comunicação, modelagem excessiva e eventualmente atrasos faziam com que a “fábrica” fosse transferida para o mesmo local físico onde ficavam os outros membros da equipe, ou então, os “analistas”, “arquitetos” e demais “especialistas “ acabavam por produzir software de verdade.
….

Nosso relacionamento com o SAD acaba sendo mais ou menos assim:

A equipe de modelagem e o arquiteto se reuniam no inicio do projeto e discutiam a arquitetura base do sistema rabiscando modelos em quadros. A partir dai o arquiteto se responsabilizava pela criação do SAD, como base no que foi discutido na reunião e por mantê-lo atualizado durante o desenvolvimento do sistema.
Sempre que alguma nova questão arquitetural surgia, ou era alterada, essa informação era passada por e-mail ou através de reuniões rápidas com a equipe, utilizando uma sala com um quadro pra rabiscar ou mesmo uma baia de algum dos desenvolvedores com algumas folhas de papel. Depois disso, o arquiteto arrumava algum tempo pra atualizar o SAD com textos e diagramas UML mais formais.

Agora me diga. Quem mais alem do arquiteto, teve realmente necessidade de manter um contato continuo com o SAD durante o tempo de desenvolvimento do sistema? Ninguém.
Então, pra que criar esse documento no inicio do projeto e continuar dando manutenção nele enquanto o sistema ainda está sendo feito, se ele não é a forma mais direta, mais viável, de se comunicar questões arquiteturais pra sua própria equipe?
Seu cliente é que pode precisar dele, no final do projeto, como um guia arquitetural para novos desenvolvedores que possam vir a dar manutenção no sistema. Alias, seu cliente é que deve decidir se esse documento deve ou não ser produzido, afinal, quem está pagando é ele.
Então, se seu cliente decidir que é valido ter um SAD (e eu creio que seja) atrase a sua criação o máximo que puder, você não vai precisar dele pra dizer algo as pessoas que trabalham com você. Seja ágil e documente somente o necessário e quando necessário.