Relação entre Scrum e arquitetura
O objetivo deste blog pode parecer estranho para muitos. Há muita crença que metodologias ágeis consistem em não gerar documentação, ou, se houver alguma, será apenas o mínimo minimorum. Sempre ouço o lema “a documentação é o código”. Por outro lado, arquitetura lembra muitas vezes documentação. Então se uma vertente remonta a não documentação e a outra à documentação, qual a relação entre elas?
Scrum tem a ver com gerência de projetos, não podendo ser confundido com uma metodologia para desenvolvimento de software como XP. Esta comparação é similar a alguém PMI e UML. Ele foi pensado em equipes de até oito pessoas. Ou seja, são projetos relativamente pequenos. Existe uma estimativa que em torno de 83% dos projetos são feitos por equipes de até oito pessoas. Um ótimo exemplo para a documentação ser apenas o código é em projetos feitos com até oito pessoas e sem muita esperança de manutenção - corretiva ou evolutiva.
Para projetos maiores existe o conceito de Scrum Escalável. Nesse tipo de projeto haverá mais papéis além do tradicional - equipe, scrum master e product owner, haverá também arquiteto e DBA. Aqui reside a principal relação entre arquitetura e Scrum.
Mas há outra situação que não é muito comentada. Considere o seguinte lema: “ao finalizar o desenvolvimento de um sistema, ele já é legado”. Sistemas legados costumam ter alguns problemas como: dificuldade de compreensão das regras de negócio, desconhecimento das razões que levaram a determinadas decisões, problemas na estruturação dos módulos de código, miscelânea de estilos de programação, obsolescência das ferramentas de desenvolvimento e impossibilidade de reaproveitamento dos equipamentos nos quais são executados para execução de softwares mais atuais.
Assim, se há possibilidade de o sistema ser utilizado por vários anos, há possibilidade de manutenção de qualquer espécie. Nesses casos é altamente aconselhável ter uma boa documentação do sistema além do código. Note que o desconhecimento das razões que levaram a determinadas decisões é muito comum, e por isso é muito importante ter em sua arquitetura uma descrição de seus raciocínios.