Profissionais TI - Pra quem respira informação

Muitas vezes é difícil delimitar prioridades, principalmente quando tudo parece ser indispensável. No Scrum, ao definir uma Sprint Backlog, como você classifica as prioridades? Os erros de produção, a evolução do software ou as refatorações tomam o topo da lista? Existe alguma regra para categorizar os itens do Backlog? Bom, vamos discutir sobre isso!

O que parece ser mais importante? A correção do erro que ocorre ao cadastrar um novo fornecedor ou a implementação da nova funcionalidade que permite a validação do XML de Notas Fiscais? Ambas parecem ser essenciais para o cliente! Embora a decisão seja complicada, existem alguns parâmetros que talvez possam ser úteis para simplificá-la.

Primeiro, é necessário refletir sobre o objetivo da Sprint, no qual muitas vezes passa despercebido pela equipe. Para isso, reflita sobre a pergunta: o objetivo é estabilizar o software (corrigindo os bugs), fornecer novos recursos (lançamento de novas funcionalidades) ou aplicar manutenções para contemplar requisitos não-funcionais, como segurança, usabilidade e desempenho? A partir do momento em que o objetivo é encontrado, priorizar os itens se torna mais fácil.

Porém, em algumas situações, o objetivo abrange, simultaneamente, as correções e as evoluções. Imagine que foi acordada a implementação de uma nova funcionalidade de controle de movimentações bancárias para o departamento financeiro, mas, ao mesmo tempo, há um erro no módulo contábil relacionado ao cálculo de impostos tributários, prejudicando a produtividade do setor. Para encontrar a prioridade mais crítica, uma das alternativas é utilizar a política do impedimento: qual dos dois itens impedirá a utilidade do software? Bom, o controle bancário é importante, mas é provável que o departamento contábil esteja praticamente paralisado enquanto o erro no cálculo de impostos não é corrigido, e isso é ruim! A prioridade, neste cenário, se refere à continuidade do negócio do cliente, portanto, o erro se destaca e deve ser corrigido. Por outro lado, caso fosse possível contornar o erro no módulo contábil (o que tecnicamente chamamos de workaround), o controle bancário para o financeiro poderia receber uma atenção maior.

Em segundo lugar, não devemos nos esquecer de um dos principais paradigmas do Desenvolvimento Ágil: entregar valor. Se você possui uma lista de itens que devem ser priorizados, discuta com a equipe sobre quais deles irão resultar em um incremento com maior valor para o cliente. Observar os itens com a perspectiva do usuário ao invés de uma perspectiva técnica pode ajudar a definir as prioridades. Para isso, levante a questão: “O que o cliente espera do próximo incremento?” – certamente, funcionalidades úteis para o negócio! Aproveitando o ensejo, lembre-se de que comentei brevemente sobre Engenharia de Valor no artigo sobre o Agile 2014.

É importante mencionar que o conceito de valor do incremento pode mudar conforme o tempo, logo, nem sempre o que foi decidido na Sprint anterior será adequado para a Sprint atual. Isso significa que você não deve utilizar os mesmos parâmetros de prioridade repetidamente. O valor do incremento deve ser “recalculado” à medida que novas regras, tecnologias e fatores externos surgem na realidade do projeto.A questão do valor nos leva à definição de produto potencialmente utilizável. A qualidade do que será entregue para o cliente depende justamente dessa categorização de prioridades. De nada adianta, por exemplo, lançar uma nova funcionalidade e, dias depois, receber uma série de reclamações devido à uma falha no código. Além de ferir a utilidade, essa funcionalidade se tornará mais um item de correção para a próxima Sprint, aumentando novamente a dificuldade em priorizar os itens.

Vale realçar que, naturalmente, se novos bugs forem introduzidos no software, ele não será mais potencialmente utilizável. O advérbio “potencialmente”, neste contexto, indica que o sistema de informação deve atuar como recurso fundamental para as operações do cliente.

Em terceiro lugar, em caso de dúvidas, a delimitação de prioridades pode ser discutida com o próprio cliente, ou, na sua ausência, com o Product Owner. O cliente conhece bem os critérios de sobrevivência do seu próprio negócio e pode fornecer informações relevantes para a elaboração do Sprint Backlog. Talvez um erro de produção pode não demandar tanta atenção quanto uma refatoração que irá melhorar o desempenho de uma funcionalidade já existente. O cliente, que convive diariamente com o andamento do negócio e com a utilização do software, é a melhor pessoa para fornecer essa orientação.

Para fechar o artigo, vou deixar uma frase que ouvi no seriado “The Blacklist”:

“We don’t need to work harder. We just need to work smarter.”
(Não precisamos trabalhar com mais esforço. Só Precisamos trabalhar com mais inteligência.)

Aplique essa frase durante a definição de Sprints. Não é preciso ficar até altas horas concluindo tarefas que, no final das contas, não irão gerar um valor considerável para o cliente. Em vez disso, identifique itens potenciais para o próximo incremento. Se estes itens forem apropriadamente avaliados, não haverá insatisfação do cliente, como também não haverá desmotivação da equipe.

Abraços!

Obs: The Blacklist é uma grande série. Vale a pena assistir!

Publicado originalmente em Blog Subrotina