BT

Qual a cor é o seu Backlog?

por Shane Hastie , traduzido por Andrew Kurauchi em 04 Mai 2010 |

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

Colors in the backlog

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figura: Cores do Backlog

Note as duas dimensões - valores positivos vs negativos e aspectos visíveis e invisíveis.
Os componentes verdes são os aspectos visíveis normalmente encontrados no product backlog - as histórias dos usuários que definem as funcionalidades que devem ser entregues no produto. Esses componentes serão visíveis para os usuários do produto final.
As tarefas amarelas são invisíveis para os usuários mas forncem um valor significativo para o produto. Essa categoria inclue trabalhos feitos para:
  • Arquitetura
  • Infraestrutura
  • Elementos Comuns
  • Bibliotecas
  • Frameworks
  • Fazer com que componentes sejam reutilizáveis
Tarefas amarelas (que são invisíveis mas valiosas) precisam ficar explícitas no product backlog e no plano de release, para que os stakeholders do projeto possam priorizá-los junto com os aspectos visíveis.
 
As partes vermelhas (Defeitos Visíveis) são inseridos conforme o produto é desenvolvido - em um mundo ideal, haveriam poucos componentes vermelhos, mas seria ingênuo pensar que não haveria nenhum.
 
Os pretos (Débitos técnicos) acontecem quando os amarelos são ignorados; débitos técnicos podem ter sido resultado de trabalho anterior, quando o projeto é feito baseado em uma base de código existente.
 
Quando estiver fazendo um plano de release inicial, é importante planejar tanto os componentes verdes e amarelos - focar apenas em aspectos visíveis pode resultar em um produto que parece maravilhoso, mas que não pode ser implantado, ou que não consegue lidar com as ameaças de segurança do mundo real. Do mesmo modo, concentrar-se apenas nos amarelos nos leva de volta ao BDUF (big up-front design) e atrasa as entregas de qualquer valor visível no projeto e que torna o compromentimento do cliente perdido.
 
Ele sugere sugere a contrução de um plano de building que trata de ambos "com um zipper" - intercalando os componentes funcionais e arquiteturais, como na imagem:

 

 

 

 

 

 

 

 

 

 

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

Os vermelhos e pretos (Defeitos visíveis e débitos técnicos) não aparecerão no plano de release inicial, mas terão um impacto significativo na velocidade (taxa com que as tarefas são feitas e valores entregues) disponível para o projeto.
 
Defeitos precisam ser corrigidos assim que são identificados. Se não resolvidos, podem resultar em impactos significativos quando forem tratados posteriormente. Após algumas iterações, a equipe terá um entendimento sobre a provável taxa de inserção de defeitos e podem ajustar a velocidade planejada para garantir que defeitos são removidos o mais perto possível do ponto de inserção.
 
Se o projeto começa com um débito técnico então eles devem ser considerados quando o planejamento do trabalho for feito - uma base de código antiga tem grande chance de já conter defeitos escondidos e o código pode não ser facilmente refatorado e novamente a taxa de entrega será reduzida de acordo com a qualidade do produto base.
Quando um novo produto está sendo feito, não há um débito técnico inicial, mas há o risco do débito ser inserido. Atrasar a correção de defeitos, ignorar os componentes amarelos, atrasar decisões importantes até depois do "último momento responsável" todos resultam em uma acumulo de débitos técnicos e em uma redução na taxa de entrega.
 
É importante que os pontos em que defeitos e débitos técnicos são identificados durante o projeto fiquem visíveis para a equipe do projeto - por isso o conceito de usar cores no backlog. Novas histórias precisam ser adicionadas para o product backlog para mostrar os defeitos e o trabalho que deve ser feito para pagar o débito técnico.
 
Ele recomenda fortemente que as cores da lista de histórias principal mostrem o tipo de trabalho a ser feito - A história é uma nova funcionalidade, um componente arquitetural, um defeito que deve ser corrigido ou algum débito técnico que precisa ser pago?
 
Ao realçar as cores no backlog e fazendo com que os quatro aspectos do desenvolvimento do produto fiquem visíveis, um planejamento mais realista pode ser feito e possibilitando o tracking do projeto.
 
Quais são as cores no seu backlog - que técnicas você usa para tornar todo o trabalho visível?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT