A primeira vez que li sobre formas ágeis de fazer desenho/concepção de sistemas foi numa entrevista ao Martin Fowler (parte 1, 2, 3 e 4), em que ele diz o seguinte:
«I distinguish between planned and evolutionary design. Planned design says that when you think about a piece of software, you create the design first, then you code it. A planned design could take the form of UML diagrams. Or you could express it in terms of dividing a system into subsystems and defining the interfaces between those subsystems. With planned design, there’s a definite switch between the two modes of creating the design and then coding it. And those tasks may often be performed by different people. Architects come up with design. The developer then code it. The design is not necessarily considered completely fixed, but it is considered mostly fixed. You can argue that the better the design, the less it will change as you code it.
With evolutionary design, you expect the design to evolve slowly over the course of the programming exercise. There’s no design at the beginning. You begin by coding a small amount of functionality, adding more functionality, and letting the design shift and shape.
[…]
I think there’s still room for some upfront design, but not a lot. People like Kent Beck and Ron Jeffries say it is eliminated. In a way they are right; you could build even a complex system purely through evolutionary design. But there are cases where you’ll go faster with some upfront design. So I would disagree with the idea that you don’t put your database in before you evolve your need for a database. I would make an initial decision about the presence of a database and go from there, but I would still evolve most of the design.»
Esta posição, já de 2002, exprime uma separação que parece haver entre metodologias ágeis e a arquitectura de software, se entendida como algo que se faz antes de se desenvolver um sistema. Pessoalmente, parece-me uma visão algo ortodoxa, e simultaneamente muito optimista. Não tenho nada contra a evolução e iteração, pelo contrário, mas considero essencial haver uma linha condutora.
No Channel 9 há duas entrevistas que também abordam este assunto. A primeira é com Colin Bird, CTO da Conchango, e outra com Roy Osherove, autor do blog ISerializable.com. Ambos dizem essencialmente o mesmo, que é sempre necessário ter uma arquitectura, e que esta vai também evoluir.
Diz o Colin: «The challenge of Agile Architecture is how deep you go, how soon. […] You can’t have no idea where you are going, you need a direction, a vision, and the vision of the architecture will evolve. […] What you get with agile is an evolving architecture, a process of refactoring not just at the code level, but a rewrite of the architecture as you understand the problem space better, as the business changes.»
E diz o Roy: «Agile doesn’t say “don’t do design for the future”, but do enough design so that when changes happen, you are able to handle them. […] Architecture is a good thing. But doing one year of architecture before development is not good. […] Design upfront is not bad, you just have to know when to stop. A good skeleton is enough.»
As opinião são semelhantes, e bem menos “ortodoxas” que a do Martin Fowler. Aquilo que me parece que fica a faltar, no entanto, é como introduzir esse elemento de concepção em metodologias ágeis tipo Scrum. Outras pessoas da Conchango estiveram no Architecture Insight 2006 da Microsoft no País de Gales, e fizeram uma apresentação sobre este tema. Infelizmente, não me parece que esta tenha informação suficiente a detalhar como é que a tal visão e arquitectura são construídas, sendo antes muito vaga. Há um arquitecto na equipa de cada Sprint do Scrum? Fica claro que tem de haver uma arquitecura, que esta tem de ser “minimalista”, capaz de evoluir, e apenas a necessária e suficiente, mas não como é que isto se enquadra no espírito das metodologias ágeis.
Uma questão que se me coloca relativamente ao ponto específico da capacidade de evoluir, é se isso não passa apenas por recorrer a princípios/padrões como Loose Coupling ou Dependency Injection, que já são regra geral considerados boas práticas, seja a metodologia ágil ou não.
Quanto à granularidade a que se deve ir no desenho, infelizmente não há respostas. O Colin diz «It depends.», para mais à frente referir que esta pode incluir Diagramas de Classes, artefactos que tipicamente seriam produzidos já em sprints.
Não me parece que haja respostas claras nesta questão, mas certamente que voltarei ao assunto. Afinal, “IT have been the bad guys for a while, it’s time to change that.”, e estas metodologias podem claramente ajudar.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]
