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

doneUma 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 post!

Depois, se quiser conhecer mais do meu trabalho com Scrum, dê uma olhada em meu livro sobre o assunto.

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.

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

Como aplicar Scrum na sua empresa

Group of business associates looking and pointing at a chart put up on the wall

Se você está lendo esse post é porque provavelmente está insatisfeito com o processo de desenvolvimento de software da sua empresa. Errei? Talvez sim, nesse caso aposto que você nem mesmo tem um processo formal de desenvolvimento de software na sua empresa. Não se preocupe, a maioria das micro e pequenas que lidam com desenvolvimento de software não possuem processos. Mas você quer mudar, então isso é bom!

Neste post vou falar de como apliquei e como você pode aplicar métodos ágeis, em especial o Scrum, na sua(s) equipe(s) de desenvolvimento de software em sua empresa. Vou falar da preparação necessária que você terá de fazer e de como deverá disseminar o conhecimento na sua equipe. Assim como o próprio framework Scrum, este post é empírico, baseia-se em experiências prévias e funciona, eu garanto! 😉

Depois de ler o post, se quiser conhecer mais o meu trabalho, dê uma olhada no livro que escrevi sobre agilidade.

Preparação

O primeiro passo é se preparar. Uma vez que você está interessado em aplicar métodos ágeis na sua empresa, é importante que você fique à par sobre o assunto, que leia as leituras recomendadas, que troque ideias com quem já aplicou tais metodologias antes, etc. Você tem de estar preparado.

O segundo passo é ler o Scrum Guide, disponível gratuitamente neste link, são apenas 19 páginas e a leitura não chega a ser maçante. Ele é pequeno e simples, porém complicado de aplicar na prática, dependendo dos vícios de gerência (ou não gerência) de projetos e processos na sua empresa. Ler o post que eu fiz sobre o treinamento de Scrum que apliquei recentemente pode te ajudar a entender o básico da metodologia.

Se você não é o principal tomador de decisões acerca de implantar uma mudança nos processos de desenvolvimento da empresa, provavelmente precisará de ajuda. Converse com seu gerente à respeito, mostre o que já aprendeu, o que já entendeu e fale de como poderia ser aplicado na empresa. Essa atitude de liderança provavelmente deverá colocá-lo no papel de Scrum Master da empresa, o responsável por garantir que os processos sejam seguidos e que o time consiga trabalhar sem impedimentos.

Se for uma mudança muito brusca, faça-a aos poucos, implementando inicialmente alguns artefatos e algumas reuniões antes de querer radicalizar e seguir o método à risca.

Quando o gerente de projetos do meu time (em 2010) decidiu que utilizaríamos Scrum no desenvolvimento do nosso maior projeto a primeira coisa que fizemos foi eu e ele participarmos de um treinamento em São Paulo, com o Giovanni Bassi na GlobalCode, até então o único instrutor certificado pela Scrum.org para aplicar treinamentos na América Latina. Foi incrível, além do excelente conteúdo e professor, tivemos muitas experiências trocadas entre as equipes que lá estavam, todos profissionais dedicados e de altíssimo nível.

Mas não parei por aí, quando voltamos parti estudar mais sobre o assunto e me preparar para tirar certificações na área, quando tirei duas em sequência: Professional Scrum Master I, para liderar times Scrum, e Professional Scrum Developer, para atuar como desenvolvedor em times Scrum. Tenho maior orgulho dessas duas certificações até hoje e são os dois pilares que uso como Gerente de Projetos em minha atual função na empresa em que estou.  Usei elas como argumento para encorajar a todos da equipe quando enfim passamos a implementar o que aprendemos na empresa, pouco tempo depois do curso e foi um sucesso. as certificações me deram a confiança de que precisava para assumir o “risco” de aplicar todo um novo processo em nosso time, que na época era bem deficiente nesse quesito.

Não tem segredo para implantar uma metodologia de desenvolvimento nova na sua equipe: tem de estudar bastante e estar preparado para fazer isso.

Mas e depois que você estiver preparado, o que fazer para preparar o time para esta mudança?

Disseminação

Não adianta apenas um membro do time, no caso você, o Scrum Master, estar comprometido em seguir a metodologia nova que foi proposta. Não adianta nada somente você conhecer como funciona o processo. O time todo tem que estar “dentro” e, para isso acontecer, provavelmente você terá de treiná-los.

Existem alguns bons motivos para que você, o futuro Scrum Master do time, assuma a bronca de treinar sua equipe em métodos ágeis ao invés de pagar um curso para eles. A primeira razão tem a ver com o seu próprio posicionamento de líder: no momento que você se coloca como professor existe uma percepção diferente dos demais em relação ao seu nível de conhecimento, profissionalismo e capacidade de liderar. Claro, que para isso não sair pela culatra você tem de estar preparado, conforme mencionei no tópico anterior. Não pode vacilar! A segunda razão é que é caro pagar um curso pra todo mundo, hehehehe

O primeiro passo é imprimir algumas cópias do Scrum Guide e distribuir a potenciais multiplicadores desse conhecimento. Comente da importância de darem uma lida (são só 19 páginas caramba!), de como isso trará benefícios para toda empresa, etc. Fale também que em breve terão um treinamento (que explicarei mais adiante) e que é importante que eles tenham um mínimo de conhecimento sobre o assunto, até mesmo para trazerem dúvidas para serem respondidas e debatidas no treinamento.

A propaganda é a alma do negócio, e aqui não é diferente. Você terá de persuadir a sua equipe de que é importante o engajamento e comprometimento de todos para que o processo dê certo. Caso contrário será você dando “murro em ponta de faca” sozinho e a implantação fracassará. Mesmo que você tenha poderes plenos para decidir isso sozinho, jamais implante um novo processo ou tecnologia na empresa de maneira ditatorial, nunca dá certo, você pode perder alguns funcionários importantes no processo (nenhum profissional competente com um pingo de amor próprio gosta disso) e provavelmente perderá tempo e dinheiro até descobrir que precisa da colaboração de todos para que funcione.

Neste outro post eu ensino uma dinâmica de como montar um treinamento de Scrum para os colaboradores da sua empresa. Espero que ajude.

* 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

Burndown Chart: como manter o prazo do projeto em dia

No Scrum chamamos as ferramentas usadas em conjunto com os processos de artefatos. E dentre os fantásticos artefatos usados pelas Metodologias Ágeis o Burndown Chart é um de meus favoritos. Ele soma a simplicidade de um gráfico bidimensional, do tipo que vemos no Ensino Médio, com o poder da Gestão à Vista da Administração tradicional. Não obstante, apesar de não ser um artefato oficial do Scrum, se alinha muito aos três pilares do framework ágil: transparência, inspeção e adaptação, e neste post vamos entender o porquê e como usar esta ferramenta.

Burndown Chart no Google Sheets
Burndown Chart no Google Sheets

Depois de ler o artigo, se quiser conhecer mais sobre meu trabalho com métodos ágeis, dá uma olhada neste meu livro aqui.

O que é?

O Burndown Chart é uma ferramenta de acompanhamento do pipeline de desenvolvimento. Ele pode ser tão macro a ponto de englobar todo o ciclo de vida de um produto (chamado também de Release Burndown) ou tão micro a ponto de englobar apenas o progresso de desenvolvimento de uma Sprint (um mês geralmente), sendo incomum menos que isso.

De qualquer forma, o Burndown Chart sempre será um cartaz de qualquer tamanho que deve estar sempre visível ao time (transparência, lembra?) onde o eixo y (vertical) representa o montante de trabalho a ser realizado (que pode ser o total de Pontos de Função ou custos do Planning Poker) e o eixo x (horizontal) o tempo que temos para trabalhar (geralmente a duração da Sprint). Traça-se uma linha diagonal entre o topo o eixo y até o final do eixo x, como uma hipotenusa de um triângulo de ângulo reto (90 graus). Essa é a linha ideal.

Como funciona?

Todos os dias o gerente do projeto, ou Scrum Master no caso de times scrum, deve atualizar o Burndown Chart traçando um ponto no plano cartesiano (eixo x vs. eixo y) e ligando ao ponto do dia anterior como uma reta, criando um gráfico descendente (pelo menos esse é o objetivo. Comparando com a linha ideal sabemos se vamos cumprir ou não o prazo do projeto: se nossa linha de desenvolvimento estiver abaixo da linha ideal, atingiremos o prazo, caso a linha esteja acima da ideal, fracassaremos.

Obviamente o dia-a-dia pode fazer com que consigamos compensar dias menos produtivos e buscar novamente a linha ideal. Ou o contrário, podemos cair na armadilha de acreditar que um ou dois dias abaixo da linha ideal vai nos garantir uma entrega no prazo e descobrir alguma tarefa que não havia sido prevista e que trancará todo o pipeline. A chave para o sucesso no uso da ferramenta é mantê-la atualizada todos os dias, preferencialmente antes da Reunião Diária sugerida pelo Scrum, para que seja usada como insumo para os desenvolvedores decidirem o que farão hoje.

Note que, como citado nos comentários, não é obrigatório que apenas o Scrum Master ou GP o atualize diariamente. Esta tarefa pode ser delegada a qualquer membro do time, desde que seja de ciência do mesmo.

Considerações Adicionais

Como deve ter notado, cria-se o Burndown Chart após a Sprint Planning, com base no montante de pontos calculados no Planning Poker (ou Pontos de Caso de Uso em times mais tradicionais). Já sua atualização se dá através da observação dos cartões de um kanban, seja ele físico ou digital, conforme expliquei no post anterior desta série sobre Agile.

Além disso, conforme mencionado no post sobre Planning Poker, é comum que os times tenham de rodar duas ou três iterações/Sprints para que descubram a “velocidade do time”. Essa métrica é mais facilmente descoberta através da observação dos últimos Burndown Charts das sprints passadas. Basta olhar quanto pontos foi possível desenvolver nas últimas sprints para ter uma ideia da velocidade do time e estimar melhor na próxima sprint.

Burndown Chart Virtual

É meio que chover no molhado pois provavelmente você já usou alguma ferramenta de criação de gráficos como Excel ou Google Sheets e o Burndown Chart nada mais é do que um gráfico qualquer, mas alinhado com o progresso do time de desenvolvimento.

Como já mencionei anteriormente, nada supera a visibilidade de um artefato físico como um gráfico colado na parede e um kanban enorme que é visível de qualquer ponto da sala. No entanto, para aqueles que insistirem em ter um Burndown Chart visual, a única dica que dou é que o link dele esteja disponível à todos, bem como seus outros artefatos virtuais como kanbans no Trello e tudo mais.

* 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!