Qual a cor é o seu Backlog?

Na recente SDC conference em Sydney e Wellington, Philippe Kruchten realizou uma palestra entitulada "Que cor é o seu Backlog". Em sua palestra ele fala sobre colocar em foco aspectos arquiteturalmente significativos do software em projetos ágeis, juntamente com a entrega dos componentes funcionais do sistema.

Kruchten sustenta que o foco de Agile em YAGNI (You Ain't Gonna Need It), refatoração e deixar as decisões para o "último momento responsável" traz um risco de atrasar demais decisões importantes. Em qualquer projeto há um conjunto de decisões chave que devem ser tomadas cedo, pois vão determinar o cenário para o trabalho a ser feito - para essas decisões o "último" momento responsável é na verdade muito próximo ao início do projeto.

Essas decisões chave são as que conduzem a estrutura arquitetural do sistema em desenvolvimento. Tomar decisões ruins (ou simplesmente não fazer nenhuma escolha conciente) pode resultar em um sistema incapaz de se adaptar às necessidades de negócio em evolução. São escolhas sobre a estrutura arquitetural do sistema que devem ser consideradas cedo no processo de desenvolvimento.

Ele afirma que muitos projetos ágeis focam nas necessidades funcionais (expressadas em histórias) e negligenciam os aspectos arquiteturais com uma atitude irresponsável de "nós podemos refatorar isso depois", deixando frequentemente o "depois" para tarde demais. Ele dá um exemplo de um sistema de negociações financeiras que usava métodos ágeis.

Histórias de usuário foram identificadas, releases planejados e desenvolvimento iniciado. As primeiras iterações ressoavam sucesso - features foram entregues, o comprometimento dos clientes era ótimo e a funcionalidade era exatamente o que o negócio havia solicitado. Assim que havia features suficientes para constituir um "produto minimamente viável" um release foi colocado em ambiente de produção e o projeto encontrou uma barreira - as features funcionavam, mas o produto não podia lidar com o volume de transações necessárias no ambiente real. Os clientes tinham que voltar ao antigo sistema (que não havia sido desligado) e a equipe de desenvolvimento precisou refatorar o produto para lidar com as demandas do ambiente real - infelizmente refatorar significou refazer completamente a maior parte do trabalho, os únicos componentes que puderam ser salvos foram os designs de tela. O projeto foi cancelado e a organização cliente ficou muito relutante em tentar Agile novamente.

Ele não está recomendando realizar uma grande etapa de design antes, mas encoraja considerar cuidadosamente os aspectos chave de qualidade do sistema e assegurar que as features arquiteturais sejam consideradas juntamente com as histórias funcionais. Features arquiteturais são guiadas pelos requisitos "não funcionais" ou de qualidade do produto - aspectos como performance, confiabilidade, capacidade, fácil manutenção, segurança, usabilidade e testabilidade. Esses são os aspectos que tem um impacto arquitetural no produto - eles devem ser projetados desde o início ao invés de refatorados posteriormente.

Ele reconhece a necessidade vital de mostrar progresso - nós não queremos que a equipe de desenvolvimento gaste as primeiras duas ou três iterações trabalhando em aspectos que não têm nenhum valor visível para os usuários. Ele sugere que é possível tecer requisitos arquiteturais no plano de release do produto, assegurando que enquanto o produto é desenvolvido, tanto os fundamentos arquiteturais quanto as features funcionais são feitos e nós podemos mostrar progresso tanto em termos de aumento nas funcionalidades quanto na habilidade de cumprir metas de qualidade. Então, por exemplo, a primeira iteração pode resultar em uma única tela de entrada, mas com testes que mostram que esse componente do sistema vai poder lidar com a demanda esperada no ambiente de produção.

Ele disponibiliza uma técnica para tornar o trabalho visível e assegurar que as necessidades arquiteturais são consideradas e priorizadas juntamente com o trabalho baseado nas features visíveis - aplicando o conceito de cores para os itens no product backlog. Ele afirma que há provavelmente quatro cores para o trabalho no backlog:

• Verde - features a serem entregues, as histórias funcionais de usuário
• Amarelo - Infraestrutura arquitetural que atende aos requisitos de qualidade
• Vermelho - Defeitos que são identificados e precisam ser corrigidos
• Preto - Débito técnico que se acumula conforme o produto é desenvolvido e as decisões chave são adiadas ou é feito um trabalho ruim

Figura: Cores do Backlog

Figura: Planeje seus releases para misturar componentes de valor visível e invisível como um zíper