Agile

8 mar, 2013

Design não surge do código

100 visualizações
Publicidade

Eu conheço um monte de gente que está migrando para o Agile ou que já está seguindo os métodos Agile de desenvolvimento. Quase todos estão usando algo com base nos princípios do Scrum, misturado com práticas de XP, como integração contínua e refatoração e testes unitários automatizados – basicamente como Mike Cohn diz que as coisas devem ser feitas em seu livro Succeeding with Agile.

Design emergente em Scrum e XP

Mas nenhum deles está fazendo design emergente como Cohn descreve, ou da forma como Kent Beck explica que é feito o design em Extreme Programming: tentando se dar bem sem qualquer projeto inicial e trabalho de arquitetura, codar recursos de imediato e contar com primeiro teste de desenvolvimento, refatoração e técnicas para elaborar um projeto em tempo real, uma ou duas semanas de cada vez.

Para a primeira iteração, escolha um conjunto de histórias básicas e simples,  que você espera que vai te forçar a criar toda a arquitetura. Em seguida, restrinja o seu horizonte e implemente as histórias da maneira mais simples que pode funcionar. No final desse exercício, você terá a sua arquitetura. Pode não ser a arquitetura que você esperada, mas depois você vai ter aprendido alguma coisa. Kent Beck

Você não precisa de design e arquitetura upfront?

Talvez seja porque todo mundo que eu conheço está trabalhando em escala – construindo grandes sistemas corporativos e sistemas online utilizados por muitos clientes, sistemas que têm um monte de restrições e dependências. Muitos deles estão trabalhando em projetos brownfield, nos quais você precisa entender primeiro o design do sistema existente e a aplicação, antes de apresentar um novo design e antes de fazer quaisquer alterações. Desempenho crítico, sistemas de missão crítica em ambientes altamente regulados.

Emergente, o design incremental não funciona para esses casos. E não escala para grandes projetos ou qualquer projeto que precisa ser entregue junto com outros e que tenha especificado os pontos de integração e dependências – o que é praticamente todos os projetos em que eu já trabalhei.

Bob Martin, uma das pessoas que ajudaram a definir a forma como o desenvolvimento Agile deve ser feito, pensa que essa abordagem incremental para fazer design é:

Um dos mitos mais insidiosos e persistentes do desenvolvimento Agile é que arquitetura e design upfront  são ruins; você nunca deve passar um tempo upfront tomando decisões arquitetônicas. Em vez disso, deve evoluir sua arquitetura e o seu design do nada, um caso de teste de cada vez. Perdoe-me, mas isso é merda de cavalo.

Martin continua dizendo que:

Há problemas de arquitetura que precisam ser resolvidos abertamente. Há decisões de design que devem ser feitas cedo. É possível você mesmo codar um cul-de-sac muito desagradável, que você poderia evitar com um pouco de planejamento.

Arquitetura e design em entrega de Agile disciplinado

A maneira que a maioria das pessoas que conheço aborda desenvolvimento Agile é mais bem descrita por Scott Ambler em Disciplined Agile Delivery, um modelo para escalar Agile para grandes sistemas, projetos e organizações. Como a pesquisa de Ambles mostra , quase todas as equipes (86%) gastam pelo menos algum tempo (em média, um mês ou mais) no planejamento inicial, definição de escopo e pensando na arquitetura – o que ele chama de “Inception Phase” (emprestado de Unified Process do Rational) ou o que a maioria dos outros chamam de “Sprint 0” ou “Iteração 0“.

Na prática, é provável que você não vá precisar fazer muita modelagem arquitetônica inicial: a grande maioria das equipes de projeto trabalha com as decisões de arquitetura técnicas que foram feitas anos antes. Sua organização provavelmente já escolheu uma infraestrutura de rede, uma plataforma de servidor de aplicação, uma plataforma de banco de dados, e assim por diante. Nessas situações, a sua equipe terá que investir tempo para entender essas decisões e considerar se a infraestrutura existente é suficiente (e, se não, identificar potenciais melhorias).

É quando você tem um projeto de desenvolvimento real totalmente novo, quando você não tem nada para alavancar, que você deve gastar mais tempo no pensamento upfront sobre o design – e não menos.

Você pode “ser Agile” sem design emergente?

É claro que você pode. Bob Martin aponta que não há nada em “Desenvolvimento Agile” que diz que você não deve fazer  upfront design – quanto mais design você precisa para o tamanho do sistema que você está construindo e do ambiente em que você está trabalhando.

Você pode e deve fazer, design incremental e iterativo e desenvolvimento, começando com um plano de para onde você está indo e como você acha que vai chegar lá. À medida que você avança, demonstra o seu desing, responde aos comentários e lida com as mudanças nos requisitos, é aí que o projeto incremental, na verdade, entra em jogo – lidar com mudanças de direção, preenchimento de lacunas, correção de mal-entendidos. O design vai mudar e talvez se tornar algo que você não esperava. Mas você precisa de um ponto de partida – designs não surgem apenas a partir do código.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/01/design-doesnt-emerge-from-code.html