Product Backlog

Resumidamente, está tudo no manifesto ágil:

Eu leio nas entrelinhas "comunicação", "qualidade" e "feito é melhor que perfeito", "comunicação" e "melhoria continua" (mudar o plano para seguir o caminho certo).

Sobre requisitos, gosto muito do exercício do Paulo Caroli descrito na página do Martin Fowler, de exercitar com o time em cada user story qual é a certeza tecnica e a certeza de negócio de cada item. Itens com baixos índices em um deles devem ser melhor esclarecidos (negócio) ou estudar a tecnologia / arquitetura.

Com isso fica claro quais possíveis problemas / incertezas, qual task dá mais retorno e deve ser priorizada, qual exige mais esforço. O resultado fica algo como:

O livro Direto ao ponto é recomendado para essa etapa de inception.

User stories devem possuir definition of ready e definition of done, como descrito no blog da adapworks.

Afinal, como pode ser desenvolvido algo que não está claro quando isso está pronto e quando pode ser começado?

Segundo o artigo do David Rice, 45% das features de software em produção nunca foram usadas.

Isso tem um efeito destrutivo no time de desenvolvimento. Olha essa talk no TED to Dan Ariely:

Versão resumida: é muito desmotivador ver seu trabalho ser destruído ou não usado. Ignorar o resultado é tão ruim quanto.
Outro ponto: as pessoas tendem a super valorizar o que elas constroem. Por isso é importante validar com os usuários o que eles acham dos resultados.

É importante falar de motivação também. No vídeo do Dan ele fala um pouco sobre isso, de porquê algumas pessoas escalam montanhas (um processo bem sofrido).

Em alguns times eu já ví acontecer a prática de "ah, se vocês entregarem o que foi planejado na sprint e mais o requisito XYZ eu pago um churrasco". Isso parece o candle problem. Não conhece? Olha essa TED talk:

Versão resumida: focar nesses 3 elementos: autonomia, domínio (mastery) e proposito.

Como tudo na vida exige negociação, é importante esse vídeo do Simon Sinek (o vídeo está na lista de mais vistos).

Quer implantar ágil no time e o time não vê valor? Quer usar uma nova ferramenta e o time não abraça? Você está indo direto com as soluções prontas (o que) ou você está fazendo as perguntas certas e explicando o porquê?

Update: quase me esqueço de abordar esse tópico, os débitos técnicos. O Klaus Wuestefeld tem uma apresentação chamada "Os Nove Registros da Eficiência no Desenvolvimento de Software", achei slides do Dionatan Moura sobre o assunto.

A proposta é avaliar seu time de 0 a 5 em cada um dos itens e trabalhar nos de menor pontuação. A ideia do registro é que a capacidade do time é limitada ao registro mais fechado.

Legal ver que vários tópicos são sobre comunicação (clima do time, colaboração). Um dos pontos interessantes é o último, qualidade. Quanto de tempo seu time tem dedicado para trabalhar em débito técnico. Alguns times esperam isso ser priorizado em alguma sprint. Isso não acontece, nem nunca vai acontecer. Isso deve ser trabalhado em todas as sprints, tendo um percentual de alocação para isso.

Muito provavelmente você já ouviu a analogia da cozinha e limpeza da mesma. Você não deveria ter que pedir no restaurante para lavarem os pratos e panelas antes de fazer sua refeição, isso deveria ser feito sempre em todas as refeições. Mesma idéia para testes de software e débitos técnicos.

Update 2: Um outro ponto interessante é prover visibilidade para o cliente e pessoas do time.

Imagine esses dois cenários:

1) você chama um taxi/uber/cabify/99 pop (escolhe um) para ir até o aeroporto. O motorista chega em 5 mins, mas demora duas horas para levar você até o destino devido a congestionamento. Você vê todo o processo. A corrida dá X reais.

2) você chama o mesmo serviço (taxi) para ir ao mesmo destino (aeroporto). Desta vez, o motorista demora duas horas para chegar até você, pelo mesmo motivo: congestionamento. A corrida é feita em 5 mins. O preço é o mesmo X reais.

Qual das duas opções você prefere? Qual das duas você vai ficar ok com o motorista? Qual vai ficar brabo?

Moral da história: dê visibilidade. E quando eu lembrar quem fez essa analogia eu dou os créditos (não achei no google).

Esse post nasceu basicamente porque eu queria falar da metologia do Paulo Caroli de organizar o backlog, mas acabei abordando outros assuntos relacionados. Também não queria abordar o básico do MVP e usar as imagens clássicas do balanço, do carro, do cortador de grama…​

Algumas referências adicionais:

Ficou claro a mensagem? Tem algum gráfico diferente? Alguma opinião sobre os itens levantados? Manda aí nos comentários.