Backlog DEEP, Histórias INVEST e Tarefas SMART

Atualizado em 29/12/2019 com os slides e vídeo!

Quem trabalha comigo há algum tempo sabe o quanto eu repito a frase “agile não é bagunça” e quando o assunto é o backlog do time, isso não pode ser menos verdade. Existe uma má interpretação do Manifesto Ágil e da própria cultura Lean-Agile em geral que entende que não se precisa ter documentação em projetos rodando sobre frameworks ágeis.

Pura mentira!

A grande mudança de mindset nos métodos ágeis é criar a documentação estritamente necessária e somente quando for necessária, ao invés de gastar meses escrevendo documentos de Visão do Produto, Especificações Funcionais e Não-Funcionais e por aí vai. Isso não quer dizer, no entanto, que jamais vamos ter este tipo de documentação ou algo próximo à elas, mas que vamos distribuir a sua produção ao longo de várias sprints conforme nosso entendimento for aumentando e a necessidade se torne emergente.

Falo disso nesse rápido vídeo introdutório sobre backlog:

E por que eu falo que agile não é bagunça?

Porque justamente em um ambiente auto-gerenciável e sem metodologias prescritivas é que precisamos do mais alto grau de organização e isso começa com nosso requisitos ágeis. No artigo de hoje falarei sobre três acrônimos bem populares para ajudar na organização dos requisitos ágeis:

É importante ressaltar que estes acrônimos são norteadores para a criação e organização destes artefatos e de que não devem se tornar uma “religião” nem criar fanáticos que impeçam os projetos de prosseguirem apenas porque alguma demanda não atende 100% a todos requisitos do acrônimo. Use-os como guias e não como grilhões.

No final deste artigo você encontra este material em forma de slides e nesse link você vê o vídeo da minha palestra sobre este assunto.

Vamos começar?

Backlog DEEP

DEEP é um acrônimo para Detalhado, Estimado, Emergente e Priorizado e são as características que o Product Owner deve buscar sempre em seu backlog.

Detalhado quer dizer que o backlog deve ter os detalhes suficientes para garantir clareza que propicie execução, mas não detalhado em demasia que gere desperdício. Entenda que a necessidade de profundidade no detalhamento é proporcional à emergência de uso do backlog, ou seja, os itens que vão entrar na próxima sprints (mais emergentes) devem estar melhor detalhados, enquanto que os itens que vão entrar daqui a várias sprints, podem estar bem menos detalhados.

Detalhamento de Backlog
Detalhamento de Backlog

Estimado quer dizer que todo item quando chega a um nível de detalhamento suficiente deve ter uma estimativa de esforço associada a ele, uma vez que o backlog não é apenas uma ferramenta de trabalho, mas e planejamento. Essa estimativa pode ser em horas, em pontos, em t-shirt size, em E/EE/EEE ou o que você possa imaginar e que faça sentido para seu time. Essa estimativa inclusive lhe auxilia a entender se o nível de detalhes está bom o suficiente, pois via de regra itens de backlog com uma estimativa muito alta deveriam ser quebrados em itens menores (a técnica de Planning Poker ou de Nivelamento de Features ajuda nisso).

 

T-Shirt Size
T-Shirt Size

Emergente quer dizer que o backlog evolui conforme o Product Owner vai aprendendo sobre o produto e o mercado vai lhe dando feedback sobre seus lançamentos (seu MVP, por exemplo), ele não é estático. O constante refinamento do backlog permite que o produto reaja bem a mudanças de estratégia e de escopo, ao invés de se apegar a um planejamento waterfall. O segredo aqui é rever todo o backlog a cada ciclo construir-medir-aprender do Lean Startup.

Ciclo do Lean Startup
Ciclo do Lean Startup

Priorizado quer dizer que a ordem em que os elementos estão dispostos no backlog importa. Os itens mais prioritários devem estar ao topo, enquanto que os menos prioritários devem estar mais embaixo. Os critérios e técnicas utilizados para priorização variam muito de Product Owner para Product Owner, de produto para produto e de mercado para mercado. Para o Scrum, não importa qual é a sua técnica, mas sim que o resultado deve gerar valor para os clientes e para a empresa.

WSJF - Técnica de Priorização do SAFe
WSJF – Técnica de Priorização do SAFe

Histórias INVEST

O acrônimo INVEST é um trocadilho para dizer que devemos “investir” tempo na escrita de boas histórias de usuário, tema de outro artigo aqui do blog. INVEST significa Independente, Negociável, Valiosa, Estimável, Small (Pequena) e Testável.

Independente significa que uma boa história de usuário não depende de outras e que outras não dependem dela. Que qualquer história deveria poder ser desenvolvida em qualquer ordem, conforme a prioridade que o Product Owner determinar. Sabemos que isso não é lá muito fácil de se alcançar, mas é sempre bom chegar o mais próximo possível disso.

Negociável significa que toda boa história é uma co-criação, uma negociação entre profissionais de negócio e profissionais técnicos. Uma história deve capturar a essência de um requisito, mas não os seus detalhes, que devem ser criados de forma colaborativa e emergente. Ao longo do tempo, mais detalhes serão adicionados a cada história conforme o produto evolui e os usuários demonstram novos comportamentos. Aqui entram os 3C’s necessários em todas histórias: Card, Conversation e Confirmation.

Valiosa quer dizer que toda história deve agregar valor ao produto e principalmente, ao usuário-chave da mesma. Uma historia jamais deveria agregar valor apenas ao desenvolvedor ou apenas ao negócio, e sim sempre centrada no cliente. O Product Owner sempre se deve perguntar se ele tornará melhor a vida do cliente ao colocar aquela historia em produção. A técnica de Nivelamento de Features pode ajudar a determinar o quão valiosa é cada história.

Estimável é semelhante ao que já falamos no DEEP sobre o backlog. Para entregar um backlog estimado que me permita planejar meu roadmap de produto, é necessário ter histórias estimadas primeiro. E para conseguir estimar as histórias elas precisam ser pequenas e claras, com detalhes suficientes e bom nível de entendimento entre negócio e técnicos. Esta estimativa não precisa ser precisa, mas deve dar noções de grandeza que ajudem na tomada de decisão, priorização, etc.

Small (Pequena) para que seja possível entregá-la em no máximo uma sprint, caso contrário ela será um épico. O grande desafio obviamente é o equilíbrio entre histórias pequenas o suficiente para que seja possível estimar, mas não tão pequenas que não entreguem valor algum para o cliente. Na verdade esse é o desafio de todo o INVEST, conciliar todas as características desejáveis em uma história. Via de regra, uma história não deveria levar mais do que alguns dias de um par de programadores trabalhando nela, se está levando mais de uma semana é uma dica de que deveríamos pensar em quebrá-la.

Testável indica que toda história deve poder ser coberta de testes para validar se seus requisitos funcionais e não-funcionais foram atendidos, geralmente abordados nos critérios de aceitação da história. Uma história que não podemos testar para garantir seu funcionamento não é uma boa história, pois ou não está Independente ou é pequena demais e não entrega valor algum.

Livro para Agile Coaches
Livro para Agile Coaches

Tarefas SMART

E para terminar, o acrônimo SMART é o mais famoso dentro e fora da computação uma vez que é usado para definir muito mais do que tarefas de qualidade, mas boas métricas, bons objetivos e por aí vai. Isso porque SMART é um acrônimo para Specific (Específica), Mensurável, Alcançável, Relevante e Temporal.

Specific (Específica) indica que toda tarefa deve ter uma responsabilidade única, ser coesa com seu objetivo e entregar apenas uma parte de uma história de usuário. Para quem é programador, é o mesmo que aplicar o princípio SRP (Single Responsibility Principle) do SOLID para tarefas. Ser específica ajuda a história ser Alcançável, Mensurável e Temporal, além de garantir o entendimento de todos no time.

Mensurável é uma característica desejável para apoiar o planejamento da sprint. Se eu não tenho como medir uma tarefa, como sei se entregaremos ela a tempo? Aqui não importa a unidade de medida, embora o ágil encoraje muito mais o uso de pontos do que de horas, desde que a unidade faça sentido para todos no time e gere informação valiosa para o time e para a empresa.

Alcançável é um requisito básico para toda tarefa. O time tem que ter as competências e recursos necessários para conseguir entregar a tarefa. Simplesmente não adianta definir como prioridade uma tarefa que ninguém sabe fazer ou que vai levar tanto tempo que ela por si só deveria ser uma história ou épico. Definir tarefas inalcançáveis para o time é o primeiro passo para perder o time, até mesmo por isso que geralmente a atividade de quebra de histórias em tarefas e feitas pelo Dev Team e não pelo PO.

Relevante tem a ver com o valor que esta tarefa agrega ao todo da história. Se a tarefa não agrega em nada, ou seja, é irrelevante para a história, ela não deveria ser feita. Tarefas são quebradas para ajudar os desenvolvedores a organizarem seu trabalho, mas cada uma deveria poder ser explicada em como contribui para a história principal.

Temporal quer dizer que toda tarefa tem um tempo para ser realizada, ela tem de estar delimitada a uma timebox específica, previamente combinada entre os membros do time e utilizada para ajudar na priorização e planejamento da sprint.

Claro, nenhum desses acrônimos é bala de prata e usar todos eles juntos, todos os dias, é um desafio imenso. Mas não desista, é justamente esta busca pela perfeição no trabalho com backlog, histórias e tarefas que cria maturidade em times ágeis.

E você, conhece algum outro acrônimo que eu não citei aqui? Deixe nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Os 6 melhores livros para estudar metodologias ágeis

Atualizado em 23/10/19 com a adição de uma indicação bônus!

Vez ou outra eu recomendo livros que já li aqui no blog, geralmente relacionados à empreendedorismo, que é o que mais tenho lido nos últimos anos. Hoje resolvi falar de livros sobre uma outra paixão minha: gerenciamento ágil de projetos. Desde 2010, quando conheci e me especializei no uso de Scrum e outras metodologias ágeis que não parei mais de estudar e ensinar o assunto para outras pessoas.

Após algum treinamento ou palestra, sempre vem aquela pergunta: que livros você recomenda? Pois bem, aqui vão eles!

É bom reforçar que, antes de ler qualquer livro, você já deve ter lido e entendido o Manifesto Ágil de 2001.

Os livros que eu recomendo são (sem nenhuma ordem específica):

Clique nas capas para mais detalhes e para adquirir os livros. Não, eu não faço pirataria e não vou colocar (nem permitir nos comentários) livros para download que não sejam realmente gratuitos.

Boa(s) leitura(s)!

Guia do Scrum
Guia do Scrum

O Guia do Scrum

Download gratuito

Existe uma frase popular que diz: “O Scrum é um framework simples de entender, mas difícil de dominar”. Por que isso?

Estamos falando de um framework ágil, e não de uma metodologia de desenvolvimento de software como RUP, ou seja, não há uma receita pronta aqui, mas sim uma estrutura mínima a ser seguida em um eterno fluxo de construir-medir-aprender assim como o do Lean Startup. Há apenas esse livro gratuito, de 19 páginas, para ser estudado e praticado ad infinitum.

Este guia é a base para entender o básico do Scrum e deve ser usado, na minha opinião, como ponto de partida de qualquer equipe que queira se tornar ágil. No entanto, conforme a equipe avança e percebe a necessidade de mais ferramental e informações, entram os demais livros abaixo listados.

Aqui no blog tem um bom resumo dele, caso queira saber mais, neste post.

Scrum
Scrum

Scrum: A arte de fazer o dobro de trabalho na metade do tempo

Comprar na Amazon

O Scrum foi co-criado por Ken Schwaber e Jeff Sutherland. Esse sr. Jeff serviu como militar e mais tarde, durante vários anos, atuou como gerente de projetos em grandes empresas públicas e privadas incluindo o FBI, sendo que essas experiências foram adicionadas ao que mais tarde ele e sr. Ken chamariam de Scrum.

É um excelente livro que conta as aventuras de Jeff Sutherland na aeronática americana em meio à guerra do Vietnã e como isso influenciou seu modo de gerenciar projetos. Também conta como aprendeu os princípios do Lean, das artes marciais japonesas e como isso tudo influenciou seu modo de pensar e acabou originando o Scrum. Em meio às histórias das origens do Scrum, ele fala muito sobre princípios e conta cases de aplicações bem sucedidas, de software à jornalismo.

Sinceramente? É uma leitura prazerosa e rica, mas não ensina Scrum para ninguém, gosto de indicar pois ajuda a entender os princípios e o mindset que originou o Scrum.

Implementando o desenvolvimento Lean
Implementando o desenvolvimento Lean

Implementando o desenvolvimento Lean de software: Do Conceito ao Dinheiro

Comprar na Amazon

Outro excelente livro que li já tem vários anos, desta vez de Mary e Tom Poppendieck. A Mary é uma engenheira com algumas décadas de desenvolvimento nas costas, que fala muito bem sobre Lean Software Development, outra técnica adaptada da indústria japonesa Toyota para o mercado de software, assim como o Kanban e até mesmo o Scrum (em partes).

Assim como o livro “Scrum: a arte de fazer o dobro de trabalho na metade do tempo”, que citei logo acima, a autora se prende demais em contar cases de sucesso e acaba demorando para entrar no Lean em si. No entanto, é muito enriquecedor do ponto de vista de princípios.

Programação Extrema
Programação Extrema

Programação Extrema Explicada: Acolha as mudanças

Comprar na Amazon

De todos os livros que vou indicar aqui, este é o único que nunca li. No entanto, conheço a trajetória de seu autor principal, que hoje trabalha no Facebook como mentor dos desenvolvedores mais jovens, Kent Beck.

Este livro é indicado pois é a obra-prima de Kent Beck (com a ajuda de Cynthia Andres), um dos signatários originais do manifesto ágil, movimento que difundiu as metodologias ágeis pelo mundo, e criador também das metodologias TDD (Test Driven Development) e XP (Extreme Programming).

Apesar do XP ser uma metodologia “concorrente” ao Scrum (que é a minha favorita), há conceitos muito valiosos no XP que cobrem “furos” do Scrum, como Pair Programming, só para citar um exemplo. Vale a indicação.

Uma versão tupiniquim e compilada deste livro pode ser encontrada na obra eXtreme Programming: Práticas para o dia-a-dia no Desenvolvimento Ágil de Software, do Daniel Wildt e sua turma. Uma leitura muito agradável e dinâmica, até mesmo mais contemporânea que o original do Kent Beck.

Kanban
Kanban

Kanban: Mudança evolucionária de sucesso para seu negócio de tecnologia

Comprar na Amazon

David J. Anderson teve uma ideia genial quando, em 2002, adaptou o modelo de kanban (cartões de sinalização) do chão de fábrica japonês para o mundo do desenvolvimento de software. Embora tenha se popularizado apenas em 2007, tornou-se algo extremamente mainstream nas empresas dentro e fora do âmbito de tecnologia. E aí entra esse livro.

O livro oficial do Kanban de David é a obra máxima sobre Kanban e a referência principal da Lean Kanban University, a organização criada para manter e promover o método no mundo. Embora Kanban um método evolucionário, seus princípios, principais práticas, método de implantação (STATIK) e diferentes tipos de abordagem são discutidos a fundo neste guia indispensável para profissionais à frente de projetos de software.

Para todos que acham que sabem implementar Kanban, este livro vai te mostrar que você não sabe tanto assim.

Scrum e Métodos Ágeis
Scrum e Métodos Ágeis

Scrum e Métodos Ágeis: Um Guia Prático

Comprar na Amazon

E por último, mas não menos importante, o livro que eu escrevi sobre Scrum e Métodos Ágeis em 2016. Trabalho com Scrum desde 2010, principalmente como Scrum Master, o responsável por garantir e aperfeiçoar os processos dentro do time. Depois de tantos anos, sprints e times diferentes, resolvi exteriorizar o que eu considero que funcionou nos times que eu trabalhei para complementar o Guia do Scrum, ou seja, não é um substituto ao Guia do Scrum, mas um adendo ao mesmo.

O Scrum fala por exemplo sobre fazer a Sprint Planning, mas não te diz como estimar as tarefas. Ele fala a Definição de Pronto, mas não te diz como criá-la. Fala sobre transparência no projeto, mas não te dá dicas de como alcançá-la. O meu livro procura preencher estas lacunas e só coloquei ele aqui por último na lista para não soar favoritismo.

Mas eu realmente acho que ele é um bom livro. 🙂

Agile Coaching
Agile Coaching

Bônus: Agile Coaching – Um Guia Prático

Comprar na Amazon

Pois é, não resisti à tentação e estou aqui divulgando mais um livro meu. Três anos depois de eu ter lançado meu primeiro livro sobre agilidade muita coisa mudou na minha carreira. Na data em que escrevo este trecho novo estou participando da segunda transformação ágil na minha carreira e aprendi muita coisa desde o primeiro livro.

Encare esta indicação como um tópico mais avançado, para quem já leu e aplicou os ensinamentos do meu primeiro livro. Esta obra é o que eu gostaria de ter tido acesso quando fui nomeado como Agile Coach em 2017, sério. Espero que lhe ajude se estiver na mesma situação.

Ah, e também tem o meu curso, logo abaixo!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Como criar uma Definição de Pronto que funciona?

done

Atualizado em 11/07/19!

Uma Definição de Pronto (Definition of Done, no original) é um artefato Scrum usado para garantir a qualidade do produto desenvolvido a cada iteração (Sprint). Um documento, um contrato entre os membros do Time Scrum e demais envolvidos para que todos entendam o que um produto “pronto” (done) significa.

Mas como criar uma definição de pronto que realmente funcione, que não seja apenas uma burocracia sem sentido no meio de um processo de desenvolvimento que deveria ser ágil?

Vou mostrar algumas ideias aqui no artigo!

Depois, se quiser conhecer mais do meu trabalho com Scrum, dê uma olhada em meu livro sobre o assunto. E se preferir assistir a um vídeo ao invés de ler o artigo, confira abaixo uma amostra gratuita do meu curso online de Scrum e Métodos Ágeis:

Basicamente a definição de pronto é o documento que define o que é considerado, para todos envolvidos no projeto, o que “pronto” (done) significa.

Quais são os requisitos para arrastar um card para a coluna DONE do Kanban? Se um desenvolvedor diz que algo está pronto, o que isso significa? O que o Product Owner espera ver, em termos gerais, durante a Sprint Review?

Essas são algumas perguntas que podem nortear a construção deste documento, que geralmente e um checklist de coisas a serem realizadas/verificada, antes de uma tarefa ser dada como pronta e, como manda o pilar da transparência do Scrum, deve ser visível e conhecido por todos do time. Dica: coloque ao lado do Kanban.

Documento colaborativo

Um primeiro ponto a se considerar é que a criação da definição de pronto deve ser realizada de maneira colaborativa, ou seja, por todos os membros do Time Scrum. Claro, alguns membros possuem mais direitos, e outros mais deveres, como o Time de Desenvolvimento, por exemplo, que será o principal encarregado de implantar os itens da definição de pronto na sua rotina de desenvolvimento. Já o Scrum Master deverá garantir e auxiliar o time na execução do que prega este documento, afinal, ele faz parte do processo Scrum e deve ser respeitado. E por fim, o Product Owner espera que todos os itens dados como prontos e entregues estejam dentro do padrão de qualidade acordado na definição de pronto.

Achou complicado? Não deveria, é mais simples do que parece.

Um bom começo é, durante a primeira Sprint Planning, o time definir a v1 da sua definição de pronto. Pense em uma folha A4 e comece com coisas simples como dizer que “todo item dado como pronto deve ter passado em testes unitários” e depois se aprofunde em itens mais “avançados” como testes de regressão, teste em pares, etc e até mesmo itens difíceis dependendo da disponibilidade do Time Scrum como “aprovar com o Product Owner”. Sim, é bem complicado deste último item ser factível pois geralmente o Product Owner não é (mas deveria ser) tão acessível quanto gostaríamos.

Como tudo no Scrum (pilares da inspeção e adaptação, lembra?), itere e melhore sua definição de pronto a cada Sprint. Pegue o que deu errado na Sprint Review (ela nunca sai 100% como foi planejado pelo Time de Desenvolvimento), aborde na Sprint Retrospective e aplique de maneira aperfeiçoada na próxima Sprint Planning. Comece simples e avance rapidamente. Lembre-se que a função deste artefato é garantir a qualidade, mas lembre-se também de se manter ágil. A dose certa de um e de outro é você que vai descobrir.

E por último, eu sugiro fazer na Sprint Planning pois dependendo dos itens colocados na sua definição de pronto, o tempo para que cada entrega fique pronta pode mudar drasticamente. Tenha a definição de pronto pronta antes de jogar Planning Poker, por exemplo.

Livro para Agile Coaches
Livro para Agile Coaches

Contrato moral

A definição de pronto é algo com o qual o time se compromete a cumprir para garantir a qualidade das entregas. Sendo assim, é um contrato moral. Moral porque estamos falando de pessoas e processos, não há um elemento de software envolvido, lhe cobrando diariamente que cumpra os requisitos do documento, embora o time possa optar por usar algum, como um dos itens da definição, mas nada a substitui.

Sendo um contrato moral e ao mesmo tempo algo colaborativo, o time terá de achar o checklist que agrade a todos, incluindo aqui o Product Owner, que é quem tem a palavra final sobre os itens do Backlog que o Time de Desenvolvimento está trabalhando. Jamais crie uma definição em que não há unanimidade dentro do Time pois caso contrário ela será sabotada, mais cedo ou mais tarde. Caso o time seja inexperiente, como Scrum Master “force” algumas regras pedindo um voto de confiança, explique que esse documento poderá ser alterado na próxima Sprint caso o Time não se adapte.

Mas principalmente: crie um documento que seja útil para garantir a qualidade das entregas que seja executável, exequível. É muito fácil cair na tentação de adicionar dezenas e dezenas de itens de qualidade que jamais serão empregados no projeto como “validar pessoalmente com o cliente final” seja porque não é prático, seja porque realmente e inviável (ex: cliente do outro lado do mundo). Se o Time optar por ferramentas, escolha o menor conjunto delas possível, caso contrário o tempo de desenvolvimento poderá ser enormemente afetado ou a definição enormemente sabotada.

E se você acha que seu Time não dará atenção a um contrato moral, que tipo de time você montou para executar o projeto?

Exemplos e Contra-exemplos

A seguir alguns exemplos de itens que já implementei em Times Scrum que eu liderei como Scrum Master e que sei que funcionam. Obviamente, alguns deles não funcionam dentro de realidades fora das que eu vivenciei, uma vez que a maioria das empresas que trabalhei desenvolviam software para si mesmas (cliente interno). Também obviamente não pegue todos e coloque na sua definição. Use-os como ideias, não tenho intenção alguma definir o que significa “pronto” para o SEU time de desenvolvimento.

Lembre-se que a definição de pronto deve ser clara e não permitir desculpas como “está pronto, só falta testar”…

Toda tarefa de software, para ser considerada pronta, deve…

Ter sido atualizado com o controle de versão e permanecer compilando;

Isto é o mínimo que se espera de algo dado como pronto. Em Times que usem versionamento de código (algum não usa?) o desenvolvedor, após concluir a codificação da tarefa, pegar a última versão do servidor, rodar seus testes (ver abaixo), fazer a fusão (merge) do que for necessário e garantir que, antes de enviar seu código amalgamado ao servidor, que tudo continua compilando. Ponto.

Contra-exemplo: cuidado com o envio de software inacabado (mesmo que algumas features individuais já estejam) para produção. Versionadores de código (como TFS, SVN, Git, etc) possuem recursos como branches e forks que permitem aos desenvolvedores manterem sempre uma versão de produção 100% operacional e livre de bugs enquanto trabalham em outra versão mais instável. Colocar na definição de pronto que o requisito de software desenvolvido esteja rodando em produção é muito perigoso.

Ter passado nos testes unitários com sucesso;

Se você ainda não usa Testes Unitários em sua equipe de desenvolvimento, deveria. A ideia aqui, basicamente, é que, se você testar cada uma das micro-partes que envolvem o seu software (unidades) isoladamente, a probabilidade de que o todo funcione é muito maior, ao mesmo tempo em que lhe obriga a manter um baixo acoplamento do seu software para que ele possa ser testado em micro-pedaços.

Contra-exemplo: colocar TDD na definição de pronto sem que o time tenha experiência com a metodologia. TDD é bem complicado e difícil de ser seguido à risca, mais do que o próprio Scrum.

Ter passado por testes de uso de outro colega da equipe;

Desenvolvedores tendem a ser os piores testadores do mundo quando o assunto é testar suas próprias criações. Certamente temos um gene defeituoso que faz com que auto-sabotemos os testes visando não encontrar bugs. Geralmente outro colega da equipe (chamado cross-testing ou peer-review), que não está preocupado com o trabalho que vai dar corrigir qualquer erro encontrado, é um testador melhor que o desenvolvedor original. E se isso não for suficiente para garantir a qualidade, em casos extremos mude para “teste de uso de quem vai usar a feature”, chamando para o teste de uso o próprio usuário da feature.

Ah, esse teste de uso deve ser em ambiente de homologação. Nada de chamar o colega ou o usuário final pra usar na tua máquina. Isso evita aquela famigerada frase: “na minha máquina funciona!”.

Contra-exemplo: teste de uso automatizado. Isso faz com que você perca a experiência da usabilidade do software. Podem existir testes automatizados, mas eles não devem substituir por completo os testes manuais quando o recurso envolver interface gráfica.

O código encontra-se dentro dos padrões da empresa;

É comum, embora não deveria, desenvolvermos uma v1 de qualquer funcionalidade de maneira meio…porca. O que não é “comum” é que essa v1 seja a versão “pronta” daquele requisito. Refatoração é a chave aqui. Garanta com esse item que o código passe por uma avaliação estrutural para ver se está 100% de acordo com as normas de desenvolvimento da empresa (ex. do Google). Obviamente para que isso funcione, estas normas também devem estar visíveis e serem de conhecimento geral do Time de Desenvolvimento.

Contra-exemplo: empresas que possuam normas de desenvolvimento muito particulares tendem a fracassar ao usar este item na definição de pronto. O que seria algo muito particular? Na minha opinião algo que foge aos padrões de codificações oficiais da linguagem/framework utilizados. Quando escrevo código em Java, uso os padrões da Oracle (Camel Case para métodos, por exemplo). Já quando escrevo código em C#, uso os padrões da Microsoft (Pascal Case para métodos, por exemplo). Isso facilita a vida para todos, inclusive novos funcionários e geralmente a resistência por adotar essa prática é culpa do ego dos veteranos da empresa.

Softwares de apoio e documentação atualizados;

Um último item na definição de pronto deve dar cabo de tarefas burocráticas e pouco interessantes, mas igualmente necessárias, como essas. Todo Time de Desenvolvimento usa algum software para controlar seu progresso (Trello, por exemplo). Mas para garantir que esse software mantenha sua utilidade, ele deve permanecer atualizado com o andamento do projeto e aqui o trabalho do Scrum Master deve ser bem forte, porque o time sempre se “esquece” de atualizar. Cobrar atualizações diárias, sempre antes da Daily Scrum, geralmente resolvem este problema, mesmo antes das tarefas serem dadas como pronto.

O mesmo vale para a documentação do projeto. Eu particularmente sempre gostei de Wikis internos por serem um formato de documentação viva, colaborativa e fácil de usar e manter. Obviamente tem empresas que preferem o bom e velho Word. Encontre o que funciona para você, mas garanta que um mínimo de documentação esteja sempre atualizada e visível, como diagramas da arquitetura, do banco de dados, de implantação, etc.

Contra-exemplo: tão nocivo quanto não ter documentação é tê-la em demasia, então tome cuidado com este item, caso contrário o time pode não se comprometer de verdade, gerando um comprometimento flácido.

Conclusão

Estas foram algumas ideias de como criar ou incrementar a sua definição de pronto. A combinação de uma definição de pronto clara, com objetivos e escopos definidos, tendem a garantir entregas consistentes e de qualidade, levando o projeto ao sucesso.

Associar a sua definição de pronto a acrônimos como DEEP, INVEST e SMART também pode ajudar bastante!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis