Sie sind auf Seite 1von 177

Índice

Índice
Introdução
Por que escrevi este livro?
Para quem é este livro?
Como este livro está estruturado?
Sobre o Autor
Sobre os direitos do Scrum
Sobre outros direitos
Referências
Capítulo 1: Para quem não sabe nada de Agile...
Tudo começou com um manifesto…
Duas palavras para começar: Scrum Guide
Além do Scrum Guide
Vantagens de usar Scrum
Adaptabilidade
Transparência
Feedback Contínuo
Melhoria Contínua
Entrega Contínua de Valor
Eficiência
Motivação
Alta Velocidade
Ambiente Inovador
Referências
Capítulo 2: Um guia rápido para o Scrum
O que é Scrum?
Os Pilares
Transparência
Inspeção
Adaptação
Papéis
Product Owner
Desenvolvedores
Scrum Master
Eventos
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Artefatos
Product Backlog
Sprint Backlog
Considerações
Referências
Capítulo 3: Roadmap ágil de produto
Matriz Valor x Risco
Futurespective
Referências
Capítulo 4: Histórias de Usuário, não tarefas
Antes de tudo: O usuário
Ponto de vista do usuário
A motivação
Critérios de Aceitação
User Stories na prática
Referências
Capítulo 5: Como estimar o tempo de desenvolvimento
Scrum Poker
Razão número 1
Razão número 2
Pokerface
Colocando em prática!
Passo 1
Passo 2
Passo 3
Passo 4
Mas e o tempo?
Referências
Capítulo 6: Como priorizar o Product Backlog
Cortando o escopo
Princípio de Pareto
Conhecendo seu produto
Buy a Feature Game
Referências
Capítulo 7: Como refinar o Product Backlog
Priorização e refinamento externo
Product Backlog Completo
Parking Lot misturado com backlog
Histórias incompletas
Histórias 'completas' demais
Itens de backlog soltos
Achismos
P.O. Parcial
Time submisso
Referências
Capítulo 8: Qualidade e Definição de Pronto
Definição de Pronto
Documento colaborativo
Contrato moral
Exemplos e contra-exemplos
Ter sido atualizada com o controle de versão e permanecer compilando;
Ter passado nos testes unitários com sucesso;
Ter passado por testes de uso de outro colega da equipe;
O código encontra-se dentro dos padrões da empresa;
Softwares de apoio e documentação atualizados;
Referências
Capítulo 9: Pipelines com Kanban
Kanban
Como funciona?
Considerações Adicionais
Kanban Virtual
Referências
Capítulo 10: Prazo com Burndown Chart
Burndown Chart
Como funciona
Considerações Adicionais
Burndown Chart Virtual
Referências
Capítulo 11: Programação em … Pares?
Pair Programming
Duas cabeças pensam melhor que uma
Mentoring de Programação
Peer Review
Conclusões
Referências
Capítulo 12: Retrospectivas de Sprint que funcionam
O que é?
Como facilitar esta reunião?
Ações Concretas
O que diferencia uma ação concreta de uma abstrata?
Capítulo 13: Aplicando métodos ágeis na sua empresa
Preparação
Disseminação
Comece devagar
Referências
Capítulo 14: Ensinando Scrum aos outros colaboradores
Se preparando
A apresentação
A Prática
Feedbacks finais
Referências
Capítulo 15: Contratando profissionais ágeis
Capítulo 16: Princípios acima de processos
Princípio 1: Empirismo
Princípio 2: Auto-organização
Princípio 3: Colaboração
Princípio 4: Priorização Baseada em Valor
Princípio 5: Time-boxing
Princípio 6: Iterativo-Incremental
Referências
Capítulo Final: Seguindo em frente
Referências
Glossário
Introdução
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the universe trying to build
bigger and better idiots. So far, the universe is winning."
- Rick Cook

Fui contratado em 2007 como o primeiro programador do setor de


desenvolvimento de uma empresa que desenvolvia um produto SaaS. Eu era
o décimo funcionário, a média de idade da empresa era 21 anos e eu mesmo
tinha apenas 19, uma autêntica startup. O escritório era uma bagunça mas
crescíamos rapidamente conforme o mercado de Internet no país avançava
vertiginosamente e gastávamos cada centavo o mais sabiamente que
podíamos, os salários eram baixos mas queríamos entregar um produto de
mais alto valor agregado no mercado.

Construímos nessa época os alicerces do nosso setor de programação,


aproveitando as experiências que eu havia tido em outras duas empresas que
desenvolviam software, inclusive com tecnologias semelhantes às nossas.
Estudamos e aplicamos metodologias tradicionais de software que grandes
empresas usavam, fomos atrás de treinamentos e conversamos com muita
gente.

No entanto, nosso crescimento acelerado e sem grandes experiências nos


trouxe alguns sérios problemas e vimos que nossos "alicerces" do setor de
programação estavam mais para estacas mal apoiadas. Rapidamente, em
coisa de três anos desenvolvendo um projeto que deveria ter sido entregue em
um, chegamos no que a indústria chamou de "crise do software" na década de
60 e que culminou com a criação dos processos de desenvolvimento de
software tradicionais. No entanto, já estávamos usando tais metodologias,
lembra?
Então porque essa "crise" nos atingiu também?

Ser um "profeta do passado" é muito tentador, e igualmente fácil, mas alguns


pontos onde errávamos antigamente, e que fizeram com que nos tornássemos
melhores hoje, podem ajudar a entender o que leva uma empresa a fracassar
no desenvolvimento dos seus projetos. Aliás, estudamos história para isso,
não é mesmo? Para não cometer os mesmos erros do passado.

Primeiramente, nosso time de desenvolvimento era micro-gerenciado.


Tínhamos um gerente que era o antigo programador original da empresa, que
se dividia entre gerenciar o projeto, programar e ajudar o CEO na
administração da mesma; sendo que dessas três funções a única que ele
executava bem à época era a de programador. Cada decisão de como as
coisas deveriam ser feitas, como os detalhes deveriam ser implementados e
praticamente o que deveríamos escrever em cada linha de software era
definido por esse gerente. Obviamente a sua inexperiência como gerente era o
principal problema aqui, e não o estou julgando, apenas expondo os fatos.

Segundo, nosso time não estava comprometido. As tarefas estavam sendo


entregues uma a uma sem um padrão de qualidade claro, sem um real
entendimento de para quê servia o que estava sendo desenvolvido e sem uma
real preocupação com o produto como um todo. Apenas estávamos fazendo o
nosso trabalho enquanto programadores. Afinal, é difícil estar comprometido
com um projeto que está há dois anos atrasado e que não tem perspectiva de
"entrar nos trilhos" novamente, não é mesmo? É tipo querer fazer com que
um time de futebol que perde jogos há dois anos acreditar que pode vencer
novamente. É óbvio que se pode dar a volta por cima, o que não quer dizer
que seja fácil mudar essa mentalidade.

Terceiro, estávamos voando às cegas. Não tínhamos ideia de onde queríamos


chegar ou sequer onde estávamos. Como sabíamos que o projeto estava dois
anos atrasado? Porque o planejamento inicial, criado pelo gerente e pelo
CEO, dizia que ele deveria ter demorado um ano. Como sabíamos a próxima
tarefa que precisava ser feita? Porque ela chegava até o time de
desenvolvimento de "cima para baixo". O escopo do projeto mudava
constantemente, não se tinha uma noção clara de início, meio e fim, uma
arquitetura emergente que não estava funcionando e processos arcaicos que
não se adequavam à realidade de uma startup que estava se descobrindo
enquanto empresa.

Um caos.

Pegávamos uma tarefa de cada vez para fazer, um dia após o outro,
programando com tanta noção de existência e propósito quanto um peixe
dourado em um aquário.

No entanto, se tivemos algum mérito àquela ocasião foi o de reconhecer


nossos erros e permanecermos unidos. Entendemos que não era um problema
de pessoas, não tínhamos um time ruim ou errado para os desafios que
estavam aparecendo. Apenas não tínhamos conhecimento de como seria o
jeito certo de conduzir o projeto para nosso tipo de problema, inovação.

Nessa época, em meados de 2010, o gerente de desenvolvimento começou a


estudar um processo novo de desenvolvimento de produtos que parecia
combinar muito bem com o ambiente de inovação que queríamos
proporcionar à equipe para que gerassem os produtos que queríamos ofertar
aos clientes. Na verdade não era apenas um processo, mas sim uma família de
processos chamados de Métodos Ágeis. Eram processos mais recentes do que
os decanos que usávamos anteriormente, surgiram no final dos anos 90 e
início do século XXI e estavam causando transformações profundas em
empresas como a nossa. Um deles destacava-se dos demais em adoção e se
chamava Scrum.

À primeira vista, eram todos excêntricos, não-ortodoxos e pareciam ter sido


criado por hippies, hipsters e assemelhados. Era difícil de crer que poderiam
causar alguma transformação nas empresas apenas por mudar pequenos
hábitos, enfatizar outros e se desprender dos protocolos tradicionais. Mas não
tínhamos nada a perder e precisávamos fazer algo urgente, afinal operávamos
sem investimento, apenas com a receita da própria empresa e ela precisava
continuar crescendo através dos novos lançamentos. O CEO deu o seu aval e
poderíamos tentar o que quiséssemos, desde que não gastássemos mais
dinheiro.
Coube à mim, à época com 22 anos e recém-formado em Ciência da
Computação e recém promovido a Analista de Sistemas na empresa,
encabeçar essa grande mudança na forma como conduzíamos os nossos
projetos.

Os meses seguintes após essa decisão foram muito intensos. Muitos livros,
treinamentos, conversas com pessoas mais experientes, viagens à eventos de
agilidade. Um mundo novo de possibilidades se abria pra mim e confesso que
foi difícil aceitar muita coisa no início. Eu era um rapaz novo, mas mesmo
assim muito conservador. Acreditar que uma reunião deveria acontecer em pé
e durar menos de quinze minutos soava besteira. Achava que planejar nossas
tarefas usando cartas de baralho em uma espécie de Pôker parecia uma piada.
Mas ao invés de apenas criticar, dei o benefício da dúvida à cada uma desses
comportamentos um tanto inusitados e absorvi tudo o que podia sobre gestão
ágil de projetos neste curto espaço de tempo, ao mesmo tempo que obtive
minhas certificações de Professional Scrum Master e Professional Scrum
Developer para ter a confiança de que realmente tinha entendido o Scrum.

E, felizmente, funcionou.

Conseguimos mudar drasticamente a forma como nossos projetos eram


conduzidos, com mais transparência para que todos pudessem ver onde
estávamos e para onde estávamos indo. Conseguimos aumentar a qualidade
das entregas com uma Definição de Pronto simples porém eficiente.
Conseguimos nivelar o conhecimento do time aplicando práticas ágeis como
Programação em Pares. Conseguimos diminuir o micro-gerenciamento e
aumentar o comprometimento do time tornando os desenvolvedores auto-
gerenciáveis ao mesmo tempo em que passamos para eles a responsabilidade
de estimar o tempo de suas tarefas. Conseguimos entregar no ano seguinte o
projeto que já havíamos perdido a esperança de que conseguiríamos.
Conseguimos "virar a mesa" como diria Ricardo Semler.

Eu tenho certeza de que não fui o único catalisador dessa mudança. De que
tive um apoio imenso de pessoas incríveis que acreditaram no trabalho que eu
estava fazendo. Que se importaram com a necessidade de tudo aquilo que
estava propondo. Meu time realmente era bom, apenas estava perdido. Todos
estávamos. Soa meio religioso, mas o Scrum realmente deu um "norte" para
nós.

Hoje essa empresa ainda existe.

Emprega 80 funcionários, fatura mais de R$12 milhões ao ano e é uma


empresa Great Place To Work no Rio Grande do Sul. O Scrum não é mais
uma prática exclusiva do setor de programação, que aliás possui vários times
hoje, mas se expandiu para os demais setores como marketing, infraestrutura,
suporte e até vendas. Com ciclos contínuos de trabalho, inspeção e
aprendizado, entregamos nossos projetos e refinamos os nossos processos à
caminho da excelência continuamente, sem nunca achar que temos um
processo "pronto", permanecemos "famintos e tolos", como diria Steve Jobs.

Todos os dias me pego imaginando o que aconteceria se todas as empresas


tivessem acesso à essas informações e promovessem essas mudanças em seus
times. Que impacto isso traria na economia e na vida das pessoas?

Uma coisa eu posso afirmar: vale a pena tentar!


Por que escrevi este livro?
Faz muito tempo que quero escrever um livro sobre gerenciamento de
projetos com métodos ágeis. Sempre achei que não tinha conteúdo suficiente,
comparando os meus rascunhos com os grandes livros do segmento. Daí
notei que eu não precisava escrever um “livro grande” para ter um “grande
livro”. Na verdade o que eu queria escrever era um guia prático e atemporal,
e que o conteúdo que eu já tinha deveria estar em um livro há muito tempo.

Falar sobre gerenciamento de projetos soa muito ‘importante’, ‘imponente’,


mas no fundo o que sempre quis é falar das minhas experiências, mostrar o
que funcionou em minhas equipes e o que acho que você deveria tentar nas
suas também. Não encare este livro como algo que deva ser lido do início ao
fim de uma vez só. Estruturei ele de maneira que encontre o que precisa para
ler no momento em que precisar. Quero que ele sirva para consultas
posteriores, entende?

Não quero me prolongar mais nesta seção, afinal, este é um livro sobre
métodos ágeis de desenvolvimento de software de maneira prática. Não quero
que os leitores percam tempo demais em uma seção pouco prática como a
Introdução, cheia de...bem, blá-blá-blá.

Então avance para a próxima seção e abra sua mente para os métodos ágeis!
Para quem é este livro?
Este guia é para quem trabalha com software e está insatisfeito com os prazos
que nunca são cumpridos, com a qualidade das entregas que sempre são
baixas e com o time que nunca está comprometido. Ok, desenhei o pior
cenário, mas acho que você pegou a ideia, certo?

Um guia como esse, sobre métodos ágeis de desenvolvimento de software


não irá solucionar os seus problemas, você irá. As dicas contidas aqui apenas
irão ajudá-lo a pensar diferente (ou a repensar) as suas ações dentro de uma
equipe de desenvolvimento ou à frente de uma.

É um guia especialmente preparado para gestores de projeto e líderes


técnicos, ou para qualquer um que um dia almeje tais posições, mas
essencialmente para todos aqueles que querem entregar resultado e gerar
valor nas empresas em que trabalham.
Como este livro está estruturado?
Busquei organizar este livro de maneira linear, ajudando o agilista novato
desde os primeiros passos com a metodologia, o planejamento do roadmap,
das sprints, a condução das iterações, do dia-a-dia, etc. Assim, você pode lê-
lo de uma vez só e ter um vislumbre de como um projeto ágil poderia ser
organizado, bem como usar os capítulos individualmente como referência
posterior.

Você vai notar que vários capítulos fazem referências a elementos de outros
capítulos. Use o glossário no final do livro para entender alguns termos que
só serão abordados posteriormente, sem ter a necessidade de ficar indo e
voltando entre os capítulos para conseguir entender o todo.

O capítulo 1 é para quem não sabe nada de métodos ágeis. Se já conhece o


básico, pule ele e não perca tempo.

O capítulo 2 é um resumão do Guia do Scrum com anotações pessoais


minhas e muito mais “direto ao ponto”, mais prático.

O capítulo 3 fala de como planejar o roadmap do seu produto/software de


maneira ágil, garantindo um alto alinhamento entre o time e os stakeholders.

O capítulo 4 fala de como especificar requisitos usando User Stories, um


artefato ágil que foca a construção do produto sob a ótica do usuário.

O capítulo 5 fala sobre como estimar o tempo de desenvolvimento dos


projetos de maneira ágil, usando a ferramenta Scrum Poker.

O capítulo 6 fala sobre como o Product Owner e demais stakeholders podem


priorizar os itens do backlog usando uma técnica simples e divertida.

O capítulo 7 fala sobre como o Product Owner e o Time de Desenvolvimento


podem refinar o Product Backlog e as principais armadilhas que devem
evitar.
O capítulo 8 fala de outra ferramenta, a Definição de Pronto, usada para
garantir a qualidade das entregas e nivelar a expectativa de todos com relação
às mesmas.

O capítulo 9 fala de Kanban, uma ferramenta visual para acompanhar o


andamento das tarefas do projeto.

O capítulo 10 fala de mais um artefato (adoro eles!): o Burning Down Chart,


outra ferramenta visual mas desta vez para acompanhar se o projeto será
entregue no prazo.

No capítulo 11 temos dicas de como usar a Programação em Pares em sua


equipe, para aumentar a qualidade do software e do próprio Time de
Desenvolvimento.

No capítulo 12 falo de Retrospectivas de Sprint, e como fazê-las de maneira


que realmente gerem melhorias nos processos da sua empresa.

No capítulo 13 dou dicas de como aplicar Scrum na sua empresa, baseado na


experiência que tive aplicando em algumas.

No capítulo 14 forneço um guia de como organizar um treinamento de Scrum


para os outros colaboradores da sua empresa.

No capítulo 15 dou algumas dicas sobre contratação de profissionais ágeis.


Mais especificamente falando, forneço 15 perguntas que lhe ajudarão a
desmascarar impostores durante uma entrevista.

No capítulo 16 ensino que acima de processos, os princípios ágeis por trás do


Scrum são o que há de mais importante e que você deve utilizá-los no dia-a-
dia.

No capítulo final falo dos próximos passos a serem seguidos quando o


assunto é Agile.
E, por fim, forneço um glossário para os principais termos usados neste
mundo dos métodos ágeis para você consultar, seja durante a leitura do livro
ou depois dela.
Sobre o Autor
Luiz Fernando Duarte Júnior é um Agile Coach, professor, empreendedor e
escritor natural de Porto Alegre/RS. Graduado como bacharel em Ciência da
Computação (Ulbra, 2010) e pós-graduado como especialista em
Computação Móvel (Unisinos, 2013), trabalha desde 2006 na área de TI, em
sua maior parte na área de software, como desenvolvedor, analista,
especialista e gerente de projetos em diversas empresas e empreendimentos
pessoais.

Profissional certificado pela Scrum.org (Professional Scrum Master e


Professional Scrum Developer, ambas tiradas em 2010), atua e lidera times
ágeis de desenvolvimento de software desde o final de 2010, em empresas
como RedeHost, Route, Opideia, Busca Acelerada, Agibank, entre outras,
tendo prestado serviços como consultor nessa área também. Professor desde
2010, leciona há vários anos na Faculdade de Tecnologia de Porto Alegre
(FAQI) no curso de Análise e Desenvolvimento de Sistemas, em disciplinas
como Engenharia de Software e Projeto Aplicado.

Carrega no currículo também alguns livros publicados (Criando apps para


empresas com Android, Programação Web com Node.js, entre outros) e
dezenas de palestras e cursos ministrados em diversos eventos, dentro e fora
do país, experiências que lhe dão base para manter o seu blog pessoal
luiztools.com.br

Conheça meus outros livros:

Programação Web com Node.js


MongoDB para Iniciantes
Criando apps para empresas com Android
Java para Iniciantes
Criando aplicações móveis com Corona
Sobre os direitos do Scrum
Este livro menciona e usa trechos do Guia do Scrum, manual gratuito do
framework ágil mais usado no mundo, criado e mantido por Ken Schwaber e
Jeff Sutherland e que é marca registrada da Scrum.org e Scrum Inc.. Este uso
é permitido conforme a licença do material original que está disponível no
site oficial do Guia do Scrum. A licença utilizada pode ser conferida no site
do Creative Commons. Ambos links estão abaixo nas referências.
Sobre outros direitos
Não tenho e nunca tive intenção de infringir direitos autorais de qualquer
pessoa. Menciono em alguns momentos o nome de algumas figuras ilustres
do mundo dos Métodos Ágeis, falo de suas metodologias, mas a título de
resenha e sempre indicando fontes de onde os leitores podem obter mais
informações.

Se por ventura algum detentor de direitos se sinta ofendido ou sinta que seus
direitos foram violados, me avise urgentemente para que as devidas
providências sejam tomadas o quanto antes. Logo abaixo forneço algumas
maneiras de entrar em contato comigo.

Referências
Blog do Autor: http://www.luiztools.com.br
Posts semanais sobre empreendedorismo e desenvolvimento de software.

Perfil do Autor no LinkedIn: http://www.linkedin.com/in/luizfduartejr


Conecte-se ao autor no LinkedIn para trocar ideias e fazer networking.

Certificações do Autor: https://www.scrum.org/User-Profile/userId/199179


Link onde é possível verificar a autenticidade de minhas certificações Scrum.

Guia do Scrum: http://www.scrumguides.org/


O livro oficial da metodologia pode ser encontrado neste link.

Licença do Scrum: https://creativecommons.org/licenses/by-


sa/4.0/legalcode
Documento que detalha o que pode e o que não pode ser feito com o método
Scrum em termos de direitos autorais.

Grupo da Scrum.org no LinkedIn:


https://www.linkedin.com/groups/2855485
Um lugar para trocar ideias com outros entusiastas da cena Scrum mundial.
Capítulo 1: Para quem não sabe nada de
Agile...
"Walking on water and developing software from a specification are easy if
both are frozen."
- Edward V Berard

Aviso: se você já conhece o básico de alguma metodologia ágil, pule


rapidamente para o próximo capítulo. Não quero nenhum leitor entediado
lendo a respeito do que já sabem.

Decidiu continuar? Ok, depois não vá reclamar...


Tudo começou com um manifesto…
Mas não era um manifesto comum, era um manifesto sobre agilidade em
gerenciamento de projetos, que dizia o seguinte:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o


nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a
valorizar:

Indivíduos e interação entre eles mais que processos e ferramentas.


Software em funcionamento mais que documentação abrangente.
Colaboração com o cliente mais que negociação de contratos.
Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens
à esquerda.”

Sempre que lia o manifesto ágil imaginava Martin Fowler lendo um


pergaminho em uma roupa ‘shakespereana’. Quando terminava, Ken
Schwaber, Jeff Sutherland, Kent Beck, Cockburn e outros aplaudiam em pé,
mas isso não vem ao caso. Trouxe o manifesto ágil como primeiro ponto
deste capítulo pois ele é o principal mindset que devemos mudar para a
correta adoção de tais métodos pouco ortodoxos.

O manifesto é fruto de grandes pensadores da área de software, frustrados


com os resultados ruins nos projetos a nível global. Ninguém entrega no
prazo, todo software tem bugs, nunca entrega-se o que o cliente quer, etc, etc.
Note a preocupação em não assumir uma atitude de ‘jogue fora tudo que
sabe’, mas sim em dar mais importância às pessoas e às entregas, à ação, ao
valor gerado, ao contrário do pensamento mais tradicional que se perpetuava
da década de 70 (durante a Crise do Software) até o início dos anos 2000.

E esse é o primeiro passo para conseguir adotar métodos ágeis de


desenvolvimento de software: desapegar do tradicional. Não jogue fora suas
planilhas do Excel, CDs do MS Project e seu diploma do MBA. Não mesmo.
Apenas passe a dar menos importância para eles e mais para as pessoas do
seu time e o que elas estão gerando de valor para seus clientes. ‘Simples’
assim.

Compreender o manifesto ágil e o que se passava na cabeça dos signatários


originais é entender que o software é apenas um meio, não um fim. Que
nenhum cliente quer comprar um software, mas sim uma solução para um
problema ou melhoria em algo já existente. Entender que nenhum
desenvolvedor quer escrever códigos, mas sim fazer parte de projetos, fazer
coisas desafiadores e estar comprometido em coisas que ele acredita que
estão certas. É entender que a agilidade é inerente ao ser humano, ninguém,
ninguém mesmo, gosta de coisas que não andam.

Parodiando Bruce Lee: “Be Agile, my friend!”.


Duas palavras para começar: Scrum Guide
Criado por Ken Schwaber e Jeff Sutherland em 1993, o Scrum talvez seja a
metodologia ágil mais usada no mundo. Digo talvez porque a maioria das
empresas que diz que usa não o faz em sua totalidade, mas sinceramente, isso
não me importa, contanto que tragam resultados para seus clientes,
independente da mentira que contam para si mesmos. Ele é fruto de
adaptações do método Lean de produção da Toyota e do ciclo OODA da
aviação de combate, conforme palavras do próprio Jeff.

Scrum é sobre entregar valor aos clientes, sem necessariamente se importar


no detalhe de como isso vai ser realizado. Parafraseando o Manifesto Ágil
que você acabou de ler, ‘não que os detalhes de como o software vai ser
implementado não importem’, mas devemos sempre preferir ver o cliente
feliz com o software funcionando em mãos do que os mais lindos arquivos de
código, cheios de linguagens hipsters que não vão para produção nunca.

Este não é exatamente um livro sobre Scrum, é um livro que tangencia o


Scrum, sem repetir o que já está contido no guia da metodologia: o Scrum
Guide. Além de Scrum, falaremos neste livro sobre outras práticas ágeis que
o complementam.

Disponível gratuitamente (e em vários idiomas) no site oficial do Guia do


Scrum, o Scrum Guide é um guia de 19 páginas que diz mais sobre o
gerenciamento de projetos com métodos ágeis do que muito best-seller de
centenas de páginas sobre o assunto. Meu sonho é um dia escrever um livro
tão curto e tão poderoso quanto esse. Enquanto isso não acontece, eu preciso
que você leia ele.

São só 19 páginas, vai lá que eu espero. ;)

Ler o Scrum Guide lhe dará a base para entender este guia que escrevi, lhe
dará as perguntas certas, a motivação adicional e vai fazer entender o valor
que este guia que tem em mãos tem, como um apêndice, algo adicional ao
Scrum Guide original. Como não queria enrolação, não repetirei aqui a
valiosa informação presente neste livro, embora ela seja pré-requisito para o
entendimento dos tópicos que vamos tratar mais adiante. Além disso, este
guia é o complemento ideal, na minha humilde opinião, para o Scrum Guide,
uma vez que o mesmo deixa a desejar quando o assunto é pôr em prática os
métodos ágeis no dia-a-dia.

O link para o Scrum Guide em Português encontra-se no final deste capítulo,


na seção de Referências. Aliás, sempre que eu mencionar aqui no livro algo
que você não conheça, dê uma olhada na seção referências do mesmo
capítulo para ver se não coloquei material complementar por lá.
Além do Scrum Guide
Agora que já leu o Scrum Guide (ao menos eu espero), você está pronto para
avançar na leitura deste livro.

Nenhum conceito aqui descrito foi criado por mim. Nenhum artefato,
treinamento, ferramenta, software, metodologia, etc. Este guia é um apanhado
de tudo o que foi útil em meus últimos 8 anos anos servo-liderando equipes
de software e que eu gostaria de ter tido quando iniciei esta jornada. Este
também não é um livro sobre Scrum, embora eu confesse que é minha
metodologia favorita.

Ou seja, é bem provável que algumas coisas que você vá ler lhe dêem aquela
sensação de ‘deja vu’. Isso é normal. Minha intenção é de que este seja um
guia complementar ao Scrum Guide, para que você possa ir além das suas 19
páginas e tenha mais recursos para implantar métodos ágeis na sua empresa.

Mesmo no caso em que não deseje aplicar o Scrum, tenho certeza de que
muitas das ideias podem lhe ajudar individualmente a gerenciar melhor os
seus projetos.

Ao menos é o que espero…


Vantagens de usar Scrum
Por que eu realmente devo utilizar métodos ágeis em meu ambiente de
trabalho?

Por que usar Scrum?

Quais as vantagens?

Vou tratar disso logo abaixo, onde falarei de vantagens inerentes à aplicação
de Scrum no seu time, embora os métodos ágeis compartilhem de
praticamente as mesmas premissas. Alguns pontos parecerão confusos, com
termos que talvez você ainda não esteja familiarizado. Isso é proposital,
veremos cada um deles em detalhes mais pra frente, continue lendo!

Adaptabilidade
O controle de processos empíricos e a entrega iterativa fazem com que os
projetos sejam adaptáveis e abertos à incorporação de mudanças.

Enquanto os métodos tradicionais de desenvolvimento, em especial o cascata,


valorizam análise extensa e definições rígidas de requisitos, visando
"segurança" (ou a falsa sensação dela), o Scrum abraça a imprevisibilidade
que um projeto longo possui ao inserir mais resiliência em projetos.

Isso não é apenas algo etéreo, está lá, documentado no Scrum Guide como o
terceiro pilar do framework!

Como diria Bruce Lee, abrace a mudança, a imprevisibilidade, seja como a


água, meu amigo! Não apenas o chinês está muito certo como outro dito
oriental, desde vez japonês, do Karatê Goju-ryu, fala sobre resiliência quando
cita que os pinheiros que duram mais tempo são aqueles que "aprendem" a se
vergar nas tempestades. De nada adianta uma árvore imponente se ela for
rígida e "imóvel", sempre haverá uma tempestade forte o bastante para
quebrá-la, e o mesmo acontece com projetos.
Como diria a equipe de engenharia do Spotify, "construa princípios sólidos e
metas claras, mas adapte a execução conforme a necessidade". Isso é ser ágil.

Transparência
Todos as fontes de informações, tais como, o quadro de tarefas (Kanban) e o
gráfico Burndown, são compartilhadas gerando um ambiente de trabalho
aberto.

Na administração tradicional a Gestão à Vista não é algo novo e


comprovadamente vantajoso para as organizações. Isso porque permite que
todos vejam o que está acontecendo e consigam tomar atitudes em relação à
isso.

Scrum fala de adaptação, mas não há como se adaptar ao que não se consegue
ver, e por isso que o primeiro pilar da metodologia é a transparência. Tudo
começa com ela.

Sem transparência não há:

● inspeção adequada
● adaptação
● engajamento
● confiança
● evolução do time
● sucesso no projeto

Gerentes temem expor informações que possam gerar medos e conflitos no


time. Ao fazerem isso, impedem que o time amadureça e realmente "abrace a
causa". John Maxwell diz que não tem como o time saber se está ganhando se
ele não pode ver o placar!

Tem um ditado que diz também o seguinte (adoro eles!): se você não sabe
para onde está indo, qualquer lugar serve. Um projeto não fracassa se não
havia um objetivo para o mesmo, certo?!
Feedback Contínuo
O feedback contínuo é fornecido através de processos denominados como a
Reunião Diária e a Sprint Review.

O Scrum fornece diversos mecanismos de feedback, o que garante o segundo


pilar do framework: inspeção.

Feedback contínuo não é dar tapinhas nas costas na reunião de final de ano da
empresa. Feedback contínuo tem a ver com transparência, pois o time precisa
saber se suas ações estão gerando resultado. Você precisa saber se está no
caminho certo. O seu colega precisa saber como pode lhe ajudar e você
precisa saber se ele precisa de ajuda também.

Inspeção leva à adaptação, em um ciclo virtuoso que gera a melhoria


contínua.
Melhoria Contínua
As entregas melhoram progressivamente, Sprint por Sprint, através do
processo de refinamento do Backlog do Produto e do processo em si.

Na metodologia de inovação em startups denominada Lean Startup, existe um


ciclo chamado construir-medir-aprender (build-measure-learn no original)
que trabalha da seguinte maneira:

● Você constrói um incremento de produto


● Você mede o desempenho dele
● Você aprende com os erros e refina-o
● Volte ao passo 1

E assim o é também no Scrum.

O framework é enxuto, apenas 19 páginas. Talvez não cubra nem sequer 10%
da "ciência" da gestão de projetos. Mas os seus princípios fundamentais te
ajudam a pensar de uma maneira diferente, com o mindset correto. Ele
próprio te ensina que a inspeção vai te levar inerentemente ao aprendizado
(adaptação) e com isso à melhoria contínua dos processos e produtos.
Esqueça aquela ideia que alguns métodos pregam que você deve apenas
confiar cegamente em um livro e seus problemas estarão resolvidos!

Entrega Contínua de Valor


Os processos iterativos permitem a entrega contínua de valor tão frequente
quanto exigido pelo cliente.

Tenha em mente que ninguém compra software. Ninguém.

"Como assim?" - pergunta o leitor atônito.

Sim, as empresas que usam softwares nunca quiseram ter aqueles programas
instalados em seus servidores ou nas máquinas dos funcionários. Eles sempre
quiseram soluções para seus problemas, sempre quiseram ser mais
produtivas, mais assertivas, mais competitivas, etc.

Só quem gosta de software é programador. Cliente gosta de solução que


entrega valor. Se o seu time não entrega valor, ele não vai ir muito longe. E
se ele demora demais para entregar valor, também não.

A chave aqui é entregar valor continuamente, em pequenas porções mas


frequentes, deixando sempre o cliente satisfeito e com um "gostinho de quero
mais". A cada iteração do Scrum (sprint), um incremento de produto é
entregue ao cliente, um que gera valor ao mesmo. É assim que tem que ser
em todos os projetos.

Você nunca terá como entregar tudo o que o cliente quer, no prazo que ele
quer e dentro do orçamento dele. Isso não existe!

Mas o processo de criar e priorizar um Backlog de Produto garante que as


exigências de maior valor ao cliente sejam atendidas primeiramente e que o
valor que ele tanto busca (não confunda valor com custo) seja entregue em
partes, à cada iteração.

Uma abordagem colaborativa com stakeholders (como a do Scrum) e a ênfase


no valor de negócio, garantem uma estrutura orientada para o cliente. E não
orientada ao software.

Lembre-se: seus clientes não querem seus softwares. Eles querem o valor
gerado pelos mesmos. Eles querem ser "melhores" do que eram antes de
comprar seu software.
Eficiência
O Time-boxing e a minimização de trabalho não-essencial conduzem a níveis
mais altos de eficiência.

Eu sou obcecado por eficiência. Admito.

As coisas mais excêntricas existentes no Scrum são em prol da eficiência. E


por isso que seguir o Scrum à risca é tão importante, principalmente em
equipes imaturas do ponto de vista de agilidade.

Pense nas time-boxes: restrições pétreas quanto à duração de eventos no ciclo


de desenvolvimento. Sprints de x semanas. Reuniões de x horas. E por aí vai.
Isso não é algo negociável. Esse tipo de restrição estimula os
desenvolvedores do time a pensar no que é mais importante ser desenvolvido
HOJE rumo ao objetivo de AMANHÃ. Não há tempo a perder com coisas
que não geram valor à meta da sprint. Estimula o Product Owner a manter o
backlog priorizado com o que realmente deve entrar no produto na próxima
sprint, deixando para um futuro incerto o que não é essencial à aplicação.

Todos sabemos (ou deveríamos saber) que a falácia da próxima feature e a


over-engineering são alguns dos piores maus que podem arruinar um projeto
de software e até mesmo uma empresa. As restrições de tempo do Scrum (e
as demais também) te ajudam a não cair nessas tentações, como essa outra, de
reescrever todo o código da sua aplicação para que fique "melhor", por
exemplo.
Motivação
Os processos de conduzir a Reunião Diária e de Retrospectiva da Sprint
conduzem a níveis mais altos de motivação entre os colaboradores.
Uma das chaves para a motivação é o que Simon Sinek chama de Golden
Circle, neste brilhante vídeo. Conforme evidenciado não apenas nesse
trabalho (do vídeo) mas em muitos outros, é necessário um ambiente de alta
confiança para que o time se sinta motivado a seguir em frente em prol dos
objetivos gerais da sprint.

Processos do Scrum (sim, ele ajuda nisso também) como a Reunião Diária e a
Retrospectiva da Sprint promovem a transparência e a colaboração,
resultando em um ambiente de trabalho de alta confiança, e garantindo baixo
atrito entre os colaboradores, além de uma alta motivação, uma vez que o
time tem o suporte e aval necessários para que consiga avançar sem
impedimentos (uma das funções do Scrum Master).

Quando os times confiam em si mesmos e seus líderes confiam no time, a


motivação se torna algo inabalável, gerando a responsabilidade coletiva e o
comprometimento, que é o que todo gerente quer da sua equipe e toda
empresa quer ver nos seus funcionários.

O processo de aprovar, estimar e comprometer-se às tarefas (ou histórias de


usuário, casos de uso, etc) permite que os membros do time se sintam
responsáveis pelo projeto e por seu trabalho, resultando em uma qualidade
muito maior. Não importa se você vai usar planning poker ou não, mas se não
houver confiança no time para tomar essas decisões, não haverá motivação
para executar as tarefas.

Tudo começa na confiança!


Alta Velocidade
Uma estrutura de colaboração permite que os times multifuncionais atinjam
o seu pleno potencial e alta velocidade.

Se o seu time vem vencendo nos demais quesitos como motivação, entrega
contínua de valor, transparência, adaptação, etc você terá o que todo gerente
de software almeja: alta velocidade!

Pausa para aquele momento em que uma música de cornetas toca e as nuvens
se abrem para os céus porque você atingiu a iluminação.

Não, agilidade não é entregar software, pura e simplesmente, mais rápido. É


sobre entregar valor mais cedo. Mas quando você entrega valor mais cedo, a
percepção que TODOS têm (interna e externamente) é que o time está
avançando mais rápido.

Pense comigo: o que vale mais, eu (um professor sedentário) correndo em


linha reta por 100m ou o Usain Bolt correndo em ziguezague para chegar no
mesmo destino que está 100m à frente? É o mesmo para software!

Se você não está trabalhando com um backlog priorizado, não está


entregando software com foco no cliente (ou seja, entregando valor para ele),
você está "andando em zigue-zague" rumo ao mesmo objetivo que poderia
estar perseguindo em linha reta!

A alta velocidade obtida com o Scrum não está na quantidade de linhas de


código que seu time vai escrever por sprint. Mas sim nas linhas certas que
serão escolhidas para serem escritas. Aquelas que trarão os maiores
resultados para o cliente em menos tempo.

Ponto.

Isso é velocidade, de maneira inteligente!

Ambiente Inovador
Os processos de Retrospectiva da Sprint e de Review da Sprint criam um
ambiente de introspecção, aprendizagem e adaptabilidade, que levam a um
ambiente de trabalho inovador e criativo.

Não custa repetir: transparência, inspeção e adaptação. Os três pilares do


Scrum.

Esse ciclo virtuoso é a chave para a inovação. A inspeção e adaptação


frequentes do Scrum levam o seu produto sempre aonde ele deve estar, agora,
neste momento. E não conforme foi planejado um ano atrás com a diretoria
em um lindo restaurante estrangeiro com todo mundo em seus belos ternos
sob medida.

Ninguém sabe o amanhã, e embora seja extremamente válido (é


aconselhável) definir as estratégias e médio e longo prazo, é a execução em
curto prazo (aliado aos pilares do Scrum) que vão garantir a existência do
projeto para TALVEZ chegar no destino desejado. Se ele ainda fizer sentido
um ano depois de traçado.

A chance de revisitar o processo e ajustá-lo a cada sprint é única e dá uma


vantagem muito grande ao time frente às metodologias tradicionais: a
vantagem de poder errar. Mas errar rápido e aprendendo com esse erro,
acertar.

Ninguém tem as respostas sobre como os softwares têm de ser desenvolvidos


em todos os casos. Nem o Scrum. Mas se ele tem algo de valioso e
memorável são que a inspeção e adaptação às mudanças devem ser o cerne
dos projetos.

Be water, my friend!
Referências
Manifesto Ágil: http://www.manifestoagil.com.br/
Documento que marcou o início do movimento ágil de desenvolvimento de
software mundialmente falando.

Agile Manifesto: http://agilemanifesto.org/


O documento original, em Inglês.

Crise do Software: https://pt.wikipedia.org/wiki/Crise_do_software


Entenda o que aconteceu com os projetos de software na década de 70.

John Maxwell: http://www.luiztools.com.br/17-leis


Conheça o trabalho do líder e autor.

Lean Startup: http://www.luiztools.com.br/lean-startup


Metodologia ágil para desenvolvimento de negócios inovadores.

Site oficial do Scrum: http://www.scrum.org


Cursos, capacitações, certificações, conteúdo, etc.

Guia do Scrum: http://www.scrumguides.org


Site oficial para baixar os guias do Scrum em diversos idiomas. Leitura
imprescindível para todos que planejam implementar agile em suas empresas.

Grupo da Scrum.org no LinkedIn:


https://www.linkedin.com/groups/2855485
Um lugar para trocar ideias com outros entusiastas da cena Scrum mundial.
Capítulo 2: Um guia rápido para o Scrum
“Computer science education cannot make anybody an expert programmer
any more than studying brushes and pigment can make somebody an expert
painter.”
- Eric S. Raymond

Aviso: mesmo no caso de você já conhecer o Scrum, lhe recomendo ler este
capítulo que não apenas resume o Scrum Guide mas resume minha
experiência de 7 anos no assunto. Não obstante, pode servir de consulta
rápida (assim como o glossário no final do livro) para os termos mais
comuns deste universo.

Conheço e aplico métodos ágeis há pelo menos 7 anos na data em que


escrevo este livro, principalmente o framework empírico Scrum.

Durante o final da minha faculdade a empresa onde trabalhava necessitava


urgente de uma reorganização dos seus processos de desenvolvimento de
software e queriam que eu me tornasse um de seus líderes de
desenvolvimento. Obviamente agarrei a oportunidade, que foi muito
importante para minha carreira, e isso me rendeu uma ida à São Paulo
participar da segunda turma de um treinamento latino-americano oficial da
Scrum.org para desenvolvedores Scrum. O treinamento de uma semana foi
incrível e me capacitou para tirar duas certificações na área de gerenciamento
de projetos com métodos ágeis e passei a atuar como facilitador do
framework Scrum na empresa, em treinamentos e em consultorias.

Neste capítulo eu resumo e comento o famoso Scrum Guide, o livro de


apenas 19 páginas que detalha tudo o que você precisa saber sobre o Scrum
antes de passar a aplicá-lo em seu time de produto. Sim, eu pedi que você
lesse o livro no capítulo anterior. Afinal, se eu contasse que ia dar um resumo
aqui, você não iria ler, certo?!

Não me leve a mal, não vou lhe enganar com um Scrum Guide editado e
expandido, longe disso. Apenas não existe maneira melhor de eu conseguir
lhe passar a forma como entendo e aplico métodos ágeis nas equipes que
trabalho sem esse resumo.
O que é Scrum?
A definição formal, cunhada pelos criadores Ken Schwaber e Jeff Sutherland,
diz que Scrum é ...

“Um framework dentro do qual pessoas podem tratar e resolver problemas


complexos e adaptativos, enquanto produtiva e criativamente entregam
produtos com o mais alto valor possível.”

Entenda um framework como uma caixa de ferramentas, uma estrutura básica


na qual você constrói algo em cima. Scrum não é algo pronto que resolve
todos seus problemas, mas sim um conjunto de processos que norteiam o
desenvolvimento de produtos complexos.

Apesar de leve e simples de entender, Scrum é extremamente difícil de


dominar, uma vez que envolve muita disciplina em sua aplicação.
Implementações de Scrum que não seguem as regras previstas em seu manual
são o que chamamos de Scrum flácido, e tendem a não alcançar o potencial
máximo da metodologia. Não trabalhei em muitas empresas que usassem
Scrum como metodologia (embora as melhores usassem) então não sei dizer
se alguma empresa no mundo segue o manual à risca, sempre há alguma
“flacidez” nas implementações por aí.

Mas por que confiar e seguir cegamente este framework?

Scrum é um processo empírico, baseado pura e simplesmente nas


experiências passadas de seus criadores que desde o início da década de 90
aplicam Scrum em projetos de software com sucesso, já sendo uma das
metodologias ágeis mais usadas no mundo. E uma vez que você se torna
adepto do Scrum, o empirismo passa a fazer com que você respeite o
processo cada vez mais e adicione novos processos e artefatos
complementares baseados nas SUAS experiências com o mesmo.

Ou seja, é um processo que evolui não só com o passar do tempo, mas com as
suas experiências. E isso não é algo inventado pela comunidade Agile, estava
previsto desde o início através dos pilares do Scrum.
Os Pilares
O Scrum se baseia em três pilares de sustentação, suas ideologias e suas
principais qualidades, na minha opinião:

Transparência
Aspectos significativos do processo devem estar visíveis aos responsáveis
pelos resultados. Isso vale para dashboards, métricas, resultados, metas. No
cenário ideal, todos sabem o porquê de cada tarefa que realizam, sabem qual
a sua contribuição para o objetivo maior, e qual é esse objetivo.

Inspeção
Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e
o progresso em direção a detectar variações. Esta inspeção não deve, no
entanto, ser tão frequente que atrapalhe a própria execução das tarefas. Sabe
aquele ditado da administração: "O que não é medido não é gerenciado"?
Pois é, este pilar é exatamente isso. Como espera que sua equipe melhores os
processos continuamente sem inspeção?
Adaptação
Se um ou mais aspectos de um processo desviou para fora dos limites
aceitáveis ou produto não será inaceitável, o processo ou o material sendo
produzido deve ser ajustado. Novamente, de nada adianta ter objetivos claros
e inspeção frequente se nenhuma ação é tomada em prol de melhorias?

Note que estes três pilares se retroalimentam: após a adaptação, novamente


voltamos para a transparência (em relação ao que foi adaptado) e à inspeção,
para verificar se as adaptações estão melhores que antes ou se há novas
correções a serem feitas. Este círculo virtuoso lembra, e muito, o ciclo
Construir-Medir-Aprender do Lean Startup, metodologia muito utilizada por
empresas inovadoras para construir produtos tecnológicos de alto
crescimento.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e


artefatos.
Papéis
Time Scrum é o nome dado ao conjunto de pessoas que possuem todo o
conjunto de skills necessárias para desenvolver um produto de software. No
Scrum, ao contrário de metodologias de desenvolvimento mais tradicionais
como o RUP, temos pouquíssimos papéis. Poucos mesmo. Em um Time
Scrum (sim, com T maiúsculo) não temos diferenciação de papéis específicos
como testador ou designer e nem mesmo hierarquia como gerentes ou
diretores. Temos pessoas comprometidas em fazer um trabalho bem feito, no
escopo e prazo combinado.

Todo Time Scrum deve incluir todos os papéis descritos a seguir, e somente
eles:

Product Owner
É o responsável pelo ROI (retorno sobre o investimento) do projeto, por
gerenciar e priorizar o Product Backlog (veja mais adiante) e, para que o
Scrum funcione realmente e ele consiga trabalhar, toda a organização deve
respeitar as suas decisões. No mundo mais tradicional da gestão de projetos,
o P.O. seria o Gerente de Produto (Product Manager), aquele que tem a visão,
que define o roadmap, que colhe os insights de mercado e os transforma em
requisitos para os desenvolvedores trabalharem.

O P.O. é membro do Time Scrum e deve estar presente e disponível para


solucionar dúvidas do time em relação ao produto e ao backlog. Se esse papel
for assumido por alguém da empresa do cliente, esta pessoa idealmente deve
ter um canal de comunicação ininterrupto com o time de desenvolvimento,
para que ele possa avançar sem atrasos.

Um P.O. ausente geralmente leva a requisitos pouco definidos, features


"meia-boca" e insatisfação do cliente com a entrega gerada. O mesmo vale
para Product Owners incompetentes em sua função, mas isso é outra
história...

Desenvolvedores
São os responsáveis por desenvolver o produto. O time de desenvolvedores
(que não precisa e não deve ser composto apenas por desenvolvedores) é
autogerenciável, multifuncional e compartilham a responsabilidade pelo
sucesso ou fracasso do projeto. Aqui não há espaço para duelo de egos ou "eu
faço apenas o design", quando o time falha, é culpa de todos e isso deve ser
reafirmado em todas reuniões, afinal, eles são um time.

O time de desenvolvimento é quem decide o quanto consegue entregar a cada


iteração, para que haja comprometimento com a entrega. O time de
desenvolvimento é quem decide como será feita cada feature, pois cabe aos
seus membros a capacidade técnica para executar o projeto.
Scrum Master
É o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e
até mesmo dentro da organização onde estão inseridos. Cabe ao Scrum
Master, que é um líder-servidor, liderar o time para que os objetivos do
Product Owner sejam alcançados e para que o time de desenvolvimento
consiga avançar sem impedimentos, removendo-os quando necessário.

Todos os eventos Scrum são facilitados pelo Scrum Master da equipe, que
idealmente não deve ter outra função paralela no time Scrum. Se gerenciar os
processos e remover impedimentos não tomar tempo suficiente do seu Scrum
Master, é porque ou o projeto é muito pequeno ou o Scrum está sendo
adotado de maneira errônea.
Eventos
O Scrum chama seus eventos de time-boxes, uma vez que são eventos de
duração fechada. Um evento pode ser encerrado em tempo menor do que o
previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto
facilitador dos eventos. Permitir a extrapolação cria um sentimento
inconsciente de impunidade e faz com que a equipe não respeite os objetivos
e o planejamento da Sprint. Por sua vez, as falhas constantes em entregar os
objetivos de uma Sprint forçará o time de desenvolvimento a ser mais
eficiente no planejamento, focar mais nos objetivos e se comprometer de
maneira mais coerente com as entregas.

Lembre-se: time-box!

Sprint
As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum.
Durante o período da Sprint um incremento utilizável do produto é criado.
Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma
também o planejamento, as reuniões diárias, a revisão e a retrospectiva.

Geralmente recomenda-se que times iniciantes no Scrum comecem com


Sprints pequenas, como uma semana ou 15 dias, para só então irem
aumentando até chegarem no valor ideal: um mês. No entanto, evite que,
após esse período inicial de adaptação, as sprints tenham tamanho variável ou
isso irá criar confusão no time. Sempre faça com que o time tenha que
estimar as tarefas com o tempo que possuem, e não com o tempo que
gostariam. Isso pode soar um pouco tirano, mas dê mais tempo à uma equipe
e ela se tornará cada vez menos eficiente pois terá margem para postergação.

Sprint Planning
Time-box de 8h para uma sprint de um mês, ou menos tempo de acordo com
o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em
relação às prioridades e os objetivos desta Sprint. É nela também onde o time
irá deliberar sobre o que conseguem fazer nesta sprint em relação às
necessidades do P.O., formalizando o Sprint Backlog, ou lista de coisas que
serão feitas no próximo mês.

É comum o uso de artefatos externos ao Scrum nesta fase, como o Scrum


Poker, usado para estimar o custo de tarefas a serem realizadas, como
veremos em um capítulo posterior. O ideal é que independente da técnica
usada para estimar (pontos de função, por exemplo), que cada tarefa não
ocupe um membro do time por mais de um dia. Se isso acontecer, veja como
pode quebrar a tarefa grande em tarefas menores.

Outro artefato muito popular também é o Kanban (especialmente usando


Trello, como veremos em um capítulo mais adiante), um board onde temos
colunas com cards, onde em cada card temos uma tarefa a ser realizada,
previamente estimada. Cada coluna representa um estágio do ciclo de
desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING
(fazendo), Testing (testando) e DONE (pronto).

O Scrum Master deve cuidar para que os participantes do Sprint Planning não
desviem do objetivo principal da próxima Sprint, traçado pelo PO, e que não
percam tempo estimando software que não será desenvolvido na próxima
sprint. Caso algum requisito necessite de pesquisa e desenvolvimento de uma
prova de conceito, não estime ele como sendo uma tarefa conhecida, ao invés
disso inclua a tarefa de P&D nesta sprint e idealmente deixe o requisito para a
próxima.

Daily Scrum
Timebox de 15 min que deve acontecer diariamente, sempre no mesmo local
e horário para gerar consistência e evitar perda de tempo, facilitada pelo
Scrum Master. Nesta reunião, que deve ser muito dinâmica e que
popularmente é feita em pé (para evitar prolongamentos e distrações), cada
membro do time deve responder apenas três perguntas: o que eu fiz ontem, o
que eu vou fazer hoje e se tem algo me impedindo.

A reunião diária é o método mais eficaz de alinhamento dos membros do


time que tive a oportunidade de experimentar. Ela permite a descoberta
rápida de problemas e desvios de curso e suas respectivas correções, por isso
deve ser respeitada.
Artefatos passíveis de serem usados nessas reuniões incluem um Burndown
Chart, que nada mais é do que um gráfico de features a serem desenvolvidas
(eixo y, vertical) versus tempo da Sprint (eixo x, horizontal). O gráfico
começa no alto do eixo y (ou seja, faltam todas features) e no ponto 0 do eixo
x (ou seja, ainda tem todo o tempo da sprint sobrando) e deve ser atualizado
diariamente com o progresso do time. Um Burndown Chart sempre visível
garante o dia inteiro, todos os dias, que todos sabem o quanto falta para
terminar a sprint, e caso estejam longe do seu objetivo, de resolverem os
problemas. A ideia aqui não é analisar o Burndown Chart na reunião diária,
que é curta e deve se manter assim, mas apenas acompanhar rapidamente,
também de maneira diária, o progresso do time. Falaremos mais dele no
capítulo apropriado

Esse evento é um dos eventos que representam o pilar de inspeção do Scrum.


Sprint Review
Time-box de 4h para sprints de um mês onde o incremento do produto, que
está pronto para uso, é apresentado ao Product Owner (e demais
stakeholders) para apreciação. Também é na review (que deve ser facilitada
pelo Scrum Master) que o Product Owner apresentará os números, gráficos e
tudo o mais que for importante à equipe saber sobre o produto. Novas
prioridades, movimentos do mercado, etc, tudo focado em manter os
objetivos coerentes ao longo das sprints.

Esse é o evento que melhor representa o pilar de inspeção do Scrum e caso o


Time tenha sido bem sucedido, é importante que todos sejam parabenizados.
Sprint Retrospective
Time-box de 3h para sprints de um mês onde o time de desenvolvedores e o
Scrum Master (que atua apenas como facilitador) falam sobre os resultados
obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o
processo, fortemente arraigado ao pilar de adaptação.

Como adaptação é um dos pilares-chave do Scrum, dediquei um capítulo


inteiro deste livro a lhe ensinar como conduzir retrospectivas de Sprint que
realmente funcionam.
Artefatos
O Scrum determina alguns poucos artefatos, que são ferramentas para lhe
auxiliar na aplicação da metodologia. No entanto, noto que cada vez mais
equipes adotam artefatos adicionais para suprir necessidades individuais ou
coletivas de quem adota esta metodologia ou qualquer outra metodologia ágil
em geral. Boa parte dos capítulos seguintes deste livro são sobre artefatos não
contemplados no Scrum Guide mas que adicionam um enorme valor à adoção
de métodos ágeis em equipes de software.

Mas antes, vamos conhecer os artefatos originais:

Product Backlog
Lista ordenada por prioridade de tudo que deve ser necessário no produto, e
origem única dos requisitos para qualquer mudança a ser feita no mesmo.
Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo
momento, o product backlog deve ser mantido longe do time de
desenvolvimento, para evitar dispersão pensando no futuro.

Muitas empresas têm usado a ferramenta Trello para seus products backlogs e
é bom ter em mente que ele nunca está pronto de verdade. Variáveis como
mercado, concorrência, novas tecnologias e modelos de negócio inovadores
tendem a fazer com que o Product Backlog tenha de ser alterado para que o
próprio produto sobreviva. Essas e outras decisões cruciais acerca do produto
cabe ao Product Owner tomar, baseado em inputs do cliente.

Sprint Backlog
Uma versão reduzida de backlog apenas com os itens que devem ser
desenvolvidos nesta Sprint, retirados do backlog original. Também pode ser
organizada em formato de kanban (como veremos no capítulo apropriado) no
Trello, mas em um board separado do Product Backlog.

Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas


prioridades do Product Owner e é sua responsabilidade dar cabo de todos
itens até o fim da sprint, servindo o Scrum Master como um facilitador para
que nada interrompa o ciclo de desenvolvimento.

Ao contrário do Product Backlog, o Sprint Backlog é imutável após sua


construção e deve ser defendido pelo Time de Desenvolvimento e pelo Scrum
Master, para garantir que o planejamento inicial, com suas metas, prazos e
escopo, sejam realizados com sucesso. Caso isso não seja possível, o ideal é
encerrar a Sprint neste exato momento, realizando review e retrospectiva,
para então começar outra inserindo as mudanças emergentes.
Considerações
É isso. O Scrum Guide tem apenas 19 páginas e esse capítulos umas 2000
palavras. O Scrum é pequeno, mas difícil de ser posto em prática porque
exige muita disciplina. Nos treinamentos que já ministrei aplico sempre um
exercício prático aos alunos para enriquecer a experiência e vivenciar na
prática, mesmo que por poucas horas, como funciona o ciclo de
desenvolvimento de um produto usando Scrum. Esse mesmo treinamento está
disponível no final deste livro, mas lhe recomendo ler os capítulos na
sequência em que cá estão.

Vamos em frente!
Referências
Site oficial do Scrum: http://www.scrum.org
Material oficial, treinamentos e certificações.

Grupo da Scrum.org no LinkedIn:


https://www.linkedin.com/groups/2855485
Um lugar para trocar ideias com outros entusiastas da cena Scrum mundial.

Lean Startup: http://www.luiztools.com.br/lean-startup


Metodologia iterativa utilizada por startups para criar produtos inovadores.

RUP: https://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process
O Rational Unified Process, metodologia de desenvolvimento usada por
grandes corporações, como IBM, para gerenciar projetos gigantescos.
Trello: http://www.trello.com
Ferramenta online gratuita para criação de boards virtuais para gerenciamento
de projetos e tarefas.
Capítulo 3: Roadmap ágil de produto
"A journey of a thousand miles begins with a single step."
- Laozi
-
Quando estamos iniciando um novo produto ou até mesmo evoluindo um
produto já existente é muito importante um mínimo de organização para que
saibamos onde queremos chegar, o que queremos ter no produto, etc. Mesmo
em casos onde a mudança seja constante, ter um roadmap ajuda a tomar
decisões de escopo, de priorização e principalmente, de ter uma ideia do quão
longe estamos de chegar aonde queremos.

Existem diversas técnicas para criação de roadmaps de produtos. Dentre as


técnicas mais ágeis e que não tentam ser lá muito precisas, até porque tentar
prever o futuro é algo bem impreciso na minha opinião, temos a
Futurespective e a Matriz Valor x Risco. E é delas que falarei neste capítulo,
embora outra dinâmica complementar seja a Buy a Feature Game que falarei
em outro capítulo.
Matriz Valor x Risco
A matriz de valor x risco é um artefato ágil para dimensionar o tamanho de
um projeto ou roadmap, além de ajudar na priorização do mesmo e definição
dos épicos e features de um produto.

Você pode fazer esta dinâmica com folhas A3, quadros brancos ou ainda flip-
charts. Ela não é uma dinâmica muito boa de aplicar em times grandes, o
ideal é que não passe de 5 pessoas e, por se tratar de uma dinâmica focada no
negócio, o ideal é não ter a presença de membros que não possuam (ou não
gostem) a visão de negócio do produto.

Desenhe uma matriz bi-dimensional com dois eixos, tipo um plano


cartesiano. No eixo vertical, escreva Valor e no eixo horizontal, escreva
Risco. Cada eixo deve ter duas ou mais partes, como Baixo, Médio e Alto
Valor, ou Baixo, Médio e Alto Risco, de baixo para cima e da esquerda pra
direita, respectivamente. Se você procurar na Internet vai ver variações, como
na imagem abaixo, que ajudam a entender como a sua matriz pode ser
organizada.
Em post its escreva as features ou épicos do seu produto e posicione um-a-um
os posts its nos quadrantes apropriados, considerando o quanto valor eles irão
agregar para os clientes e/ou para a empresa e o quanto de risco eles
possuem.
Considere Valor como não sendo algo meramente financeiro. Valor pode ser
engajamento, pode ser marketing boca-a-boca, pode ser algo que gere mais
NPS, pode ser algo que reduza o churn, que aumente a conversão, etc.
Embora tudo isso de uma forma ou de outra se traduza em dinheiro, não
precisa se apegar a valores financeiros diretos. Essa definição mais
abrangente de valor é algo a ser levada a sério, pois até mesmo aparece na
prova da certificação de PSPO.

Considere Risco como qualquer coisa que torne mais arriscado pegar esta
feature ou épico para implementar. Pode ser muito esforço necessário, muito
custo, desconhecimento dos detalhes, falta de tecnologia ou de pessoal
especializado para tocar a tarefa. Pode ser um prazo muito justo ou uma
complexidade muito alta de desenvolvimento. Tudo isso representam riscos
para que tenhamos sucesso na empreitada deste épico.

Após terminar de colocar os post its nos lugares certos cabe ao time decidir a
sua estratégia de priorização do roadmap. Não há uma única estratégia válida
aqui pois cada empresa tem a sua realidade, mas uma análise importante dos
quadrantes incluem:

● alto valor e alto risco (topo á direita): geralmente o que possui


alto risco e alto valor são as que realmente darão um retorno altíssimo
para a empresa. O fator risco deve ser mitigado o mais rápido possível
para que não sejamos surpreendidos no futuro por algo que acabe
minando o projeto como um todo. Atacar o alto risco/alto valor
primeiro é uma estratégia segura a longo prazo;
● alto valor e baixo risco (topo á esquerda): uma estratégia de curto
prazo, boa quando se está com a corda no pescoço e precisam-se de
ações rápidas e que gerem valor. Em outras situações, ataque estas após
as alto risco/alto valor.
● baixo valor e baixo risco (embaixo à esquerda): não é uma boa
estratégia, geralmente só devem ser priorizadas em casos de ociosidade
ou em períodos "entressafras";
● baixo valor e alto risco (embaixo à direita): jamais faça elas, não
valem a pena.

Ao definir sua regra de priorização, você terá o seu roadmap definido e


priorizado. Se precisar de alguma estimativa de alto nível, convém jogar um
Scrum Poker (que falarei mais adiante) sobre o menor épico que valha a pena
desenvolver (alto valor e baixo risco?) e, após estimá-lo, projetá-lo sobre os
demais post its para ter uma ideia total do roadmap.

Por exemplo, se o menor épico ganhar um 3 e você decidir que ele demora
em média 2 meses, some os demais pontos e divida por 3 para saber o
número de meses do seu roadmap. Mantenha uma escala exponencial como a
de Fibonacci para pontuar tarefas baseadas em seu risco, para não cometer o
erro de estimar um roadmap muito "no detalhe".
Futurespective
Essa dinâmica pode ser complementar à Matrix Valor x Risco ou mesmo
substitui-la. Sua abordagem é ainda menos precisa e muito mais ágil, quando
estamos em uma de duas situações:

● você quer ver se o seu time está alinhado com a visão estratégica da
empresa em relação ao(s) produto(s) que estão desenvolvendo;
● você quer construir um roadmap do produto de maneira
colaborativa, com o seu time, para dar uma visão comum a todos;

Seja qual for o seu objetivo, esta dinâmica é bem interessante e pode render
bons frutos, apenas não se preocupe em gerar um plano de ação detalhado
com ela, pois isso não irá acontecer. Conheci ela durante um workshop do
Daniel Wildt e achei bacana reproduzir aqui.

Separe o seu time em grupos de até 3-5 integrantes. Evite grupos muito
grandes para evitar discussões desnecessárias. Essa não é uma dinâmica que
trará precisão no seu roadmap, mas um alinhamento geral muito bom, então
não tem necessidade de discutir nos mínimos detalhes os prazos e prioridades
das coisas.

Estabeleça que cada participante vai escrever 10 post-its com épicos ou


features que ele acredite ser importante para o produto e que ainda não foram
desenvolvidas.

Após todos escreverem, cada membro deve apresentar aos demais o que ele
escreveu. Juntos, devem definir quais x itens devem ser prioridade para os
próximos 3 meses (desconsiderando repetidos), sendo que x deve ser o
número de integrantes da equipe que está fazendo a dinâmica. Depois, quais
os próximos x que devem ser prioridade para os 3 meses posteriores e assim
por diante, até os itens terminarem.

Para tomarem a decisão de prioridade, pode ser usada a Matriz Valor x Risco,
a Buy a Feature Game ou qualquer outra dinâmica que você conheça. O
resultado dessa dinâmica será um roadmap de alto nível que garante uma
visão comum entre os membros do time.

Eventualmente este roadmap irá ser alterado, mas não tem problema, como
diz no Manifesto Ágil: mais vale responder às mudanças do que seguir um
plano.
Referências
Futurespective: https://www.benlinders.com/2015/how-futurespectives-
help-teams-to-reach-their-goals/
Excelente artigo falando mais desta dinâmica.

Matriz Risco x Valor: https://sync.appfluence.com/templates/risk-value-


matrix/
Excelente artigo falando mais desta técnica.

Manifesto Ágil: https://www.manifestoagil.com.br/


Os princípios originais que deram luz às metodologias ágeis como Scrum,
XP, Crystal, etc
Capítulo 4: Histórias de Usuário, não tarefas
"Technology is useless if not used for the greater good of serving the
customer."
- Werner Vogels

Dentro da Engenharia de Software temos um sub-campo que é a Engenharia


de Requisitos. A Engenharia de Requisitos é a "ciência" que estuda todas as
formas de elicitar, analisar, validar, especificar e documentar requisitos,
visando gerar insumos para a fase de projeto do software, coordenada por
arquitetos de software ou analistas de sistemas, dependendo da empresa.

É nesta "fase de requisitos" que exploramos o quê, como e para quem iremos
desenvolver as próximas funcionalidades do sistema. E no Scrum não é muito
diferente disso, essa fase existe, embora distribuída em "pedaços", no início
de cada sprint, sendo executada durante a Sprint Planning, que você deve ter
lido sobre no capítulo anterior.

Mas uma coisa que o Scrum não nos diz é: como organizar e/ou documentar
as tarefas que devem ser realizadas a cada Sprint? Uma ideia é fazê-lo com
User Stories ou Histórias do Usuário: um artefato ágil para especificar
requisitos.
Antes de tudo: O usuário
Vamos partir aqui de algumas premissas básicas: toda funcionalidade que
vamos desenvolver vai impactar a vida de no mínimo uma pessoa. Se não
impacta a vida de ninguém, não deveria existir. O impacto pode ser grande ou
pequeno, desde um botão que vai economizar 15 minutos de tarefas
repetitivas ou um formulário que vai atender a uma norma legal do governo
que poderia fechar a empresa.
Então sempre começamos com um "quem".

Toda user story, como o próprio nome sugere, começa com um usuário. Este
usuário é o ator principal da história, uma persona que todos no time
conhecem e entendem como pensa, como age, quais são as "dores", etc. É
importante mapear essas personas que serão utilizadas antes de escrever user
stories com elas.
A descrição de uma persona, e isso não faz parte da user story em si, pode ser
como abaixo (exemplo da Umbler):

"Luiz é um desenvolvedor e também um empreendedor. Ele cria diversos


projetos usando tecnologias como ASP.NET e Node.js e gosta de publicá-los
em ambientes confiáveis e com preços razoáveis. O Luiz ocasionalmente tem
amigos que o ajudam nestes projetos e quase sempre bola maneiras de
rentabilizar os projetos. O Luiz prefere fazer deploy via Git ao invés de FTP
por ser mais rápido e confiável, além de gostar de pagar apenas pelos
recursos que consome no servidor ao invés de um fixo mensal."
Eu poderia continuar escrevendo sobre essa persona, mas acho que você já
deve ter entendido a ideia.

Assim, quando uma user story começa com "Enquanto Luiz...", todo o time,
que já conhece aquela persona (os mesmos podem ser apresentados antes da
leitura de cada história) e já entende as motivações dela, tornando mais fácil
tomar decisões futuras. Sempre que o desenvolvedor que estiver
implementando uma funcionalidade que é "para o Luiz" estiver em dúvida
sobre algo, ele sempre deve se projetar (através de empatia, jovem
gafanhoto!) e pensar "se eu fosse o Luiz, como eu gostaria que isso
funcionasse?".
Ponto de vista do usuário
Depois de definirmos para quem estamos desenvolvendo uma nova funcionalidade, devemos definir o
que será desenvolvido.

Note que quem escreve as histórias do usuário é quem gerencia o produto: o Product Owner. Como
alguém não-técnico e centrado no produto, cabe ao P.O. especificar "o quê" deve ser feito e "para
quem", mas não "o como". A funcionalidade deve ser descrita a nível de usuário e a nível de negócio,
jamais a nível de programação.

Um bom exemplo seria:

"Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus
projetos web."

Um mau exemplo seria:

"Enquanto Luiz, eu gostaria de ter um formulário em React para criação de banco MongoDB, com os
campos nome do banco, usuário e senha, que quando preenchidos iniciassem uma tarefa de criação de
instância no datacenter 03 da Umbler e me retornasse os dados de acesso por email quando estivesse
pronto."

Um dos "mandamentos" é que o time deve se auto-gerenciar, eles devem decidir como cada
funcionalidade deve ser desenvolvida. O P.O. sabe que MongoDB é uma demanda do mercado e que
devemos ter isso em nosso catálogo de produtos pois temos muitos "Luizes" como clientes, mas se isso
deve ser implementado com React, se deve ser assíncrono, em qual datacenter vai ficar, etc é com a
galera técnica.

Sendo assim, sua história de usuário deve ser:


1. sem detalhes de implementação;
2. focada no que o usuário quer fazer;
3. explicada do ponto de vista do usuário;
4. curta e objetiva;
A motivação
O último elemento de uma user story é a motivação. Por que o usuário quer essa funcionalidade? Para
quê ela vai servir exatamente (do ponto de vista de 'entrega de valor')? O que isso vai impactar na vida
dele?

Estas e outras perguntas devem ser respondidas na motivação, que é a terceira e última parte da user
story.

Muitas vezes quando estamos desenvolvendo não entendemos porque estamos desenvolvendo aquela
feature. E quando isso acontece, geralmente não tomamos as melhores decisões sobre dúvidas que
temos. Esta listagem deve ter uma busca no topo ou uma paginação? Esta tarefa deve ser síncrona ou
assíncrona? Essa informação será pesquisada com texto-livre ou através de opções fixas?

A motivação costuma deixar isso tudo muito mais claro e ajudar a criar features que realmente
entregam valor ao usuário. Como no exemplo abaixo:

"Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus
projetos web porque usando serviços de terceiros sai mais caro e a latência é alta."

Aqui deixamos explícito que o usuário quer 'MongoDB na Umbler' porque isso seria mais barato e mais
rápido para seus projetos web. Sendo assim, no momento da implementação desta funcionalidade (que
confesso pode ser quebrada em tarefas menores, mas é apenas um exemplo), podemos inferir que nossa
solução:

1. não pode ser resolvida através de integrações (add-ons);


2. tem de ter uma baixa latência (no mesmo datacenter que o projeto dele);
3. deve ser cobrado na mesma moeda do país dele (as soluções atuais são em dólar);

Essa informação ajuda a nortear as decisões, bem como se aliarmos às informações da persona do Luiz,
veremos que se ele gosta de Git, é provável que goste de fazer deploy do seu banco MongoDB via linha
de comando também.

Alguns autores defendem que a motivação, o "por quê" da user story, é opcional. Embora eu entenda
que em alguns casos até possa ser verdade, eu encorajo a você sempre tentar deixar isso o mais
explícito possível, usando aquela "máxima" de "o óbvio sempre precisa ser dito".
Critérios de Aceitação
Quando a User Story possui regras de negócio ou requisitos não-funcionais específicos, vale definir os
critérios de aceitação da mesma. Basicamente os critérios de aceitação são um checklist de requisitos
que esta história em particular deve atender para que a mesma possa ser dada como pronta (DONE)
pelo Product Owner.

Usando a mesma história que vínhamos criando, podemos ter os seguintes critérios de aceitação:

● a senha do banco MongoDB criada deve ter no mínimo 10 caracteres alfanuméricos;


● a tela deve ser desenvolvida conforme layout criado pelo time de UX;
● o nome do banco MongoDB criado pelo usuário não pode ser igual a outro já existente;

Se você estiver usando cards ou post its grandes para escrever suas user stories, você pode usar o verso
do card para os critérios de aceitação. Caso contrário terá de documentá-los em outro local. Onde
trabalho atualmente usamos o Visual Studio Online para Task Management, e nesta ferramenta temos
um campo para Acceptance Criteria dentro do cadastro das User Stories.
User Stories na prática
O jeito mais tradicional de usar user stories é usar o Product Backlog como insumo e escrevê-las em
post its, uma por post it. Algumas equipes costumam imprimir cards já com o esqueleto da user story
nele, para não esquecerem nenhuma das três informações centrais e até mesmo com outros campos
como o número de pontos daquela tarefa, por exemplo.

Segue um exemplo bem elaborado, que pode servir de inspiração:

Esses cards são muito práticos e podem facilmente ser combinados com outras técnicas e artefatos que
veremos aqui no livro como Kanban, para organizá-los e Scrum Poker, para estimá-los (um conceito
chamado de Story Points). Uma ressalva aqui é quanto ao "tamanho" da história.

Algumas histórias ficam tão abrangentes que costumamos chamá-las de épicos. Devemos sempre
quebrar épicos em histórias de maneiras que elas possam ser "digeridas" pelo time que vai implementá-
la. Não existe uma regra clara que diferencia um épico de uma história, mas o bom senso ajuda
bastante. Algumas dicas nesse sentido são:

● se não cabe em uma sprint, é um épico;


● se consigo quebrar em dois ou mais story cards, é um épico;
● se no Scrum Poker gerou muita divergência de pontuações é um épico;

E um último ponto digno de nota é: não subestime a utilidade de artefatos mais tradicionais da
engenharia de requisitos. Vão ter projetos, em que um story card não vai ser o suficiente e você terá de
ter um artefato de apoio como um mockup, um diagrama UML ou até um caso de uso. Enquanto que
para muitos times e projetos user stories se encaixam como uma luva, para outros, você precisará de
técnicas complementares ou até substituir essa técnica por uma mais tradicional. Então fique atendo,
Scrum não é bala de prata!

Referências
Engenharia de Requisitos: http://www.devmedia.com.br/artigo-engenharia-
de-software-introducao-a-engenharia-de-requisitos/8034
Um artigo introdutório sobre o assunto, para quem nunca leu sobre. Muita
coisa apesar de ser da escola mais tradicional de gerenciamento de projetos,
possui muito valor.

Slides sobre User Stories: https://www.slideshare.net/AnneliseGripp/user-


stories-83093522
Apresentação bem bacana de uma famosa agilista sobre User Stories.
Capítulo 5: Como estimar o tempo de
desenvolvimento
"Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law."
- Douglas Hofstadter.

Em 2008 eu estava ainda no início da minha carreira como programador.


Ainda era um profissional Júnior, mas meu crescimento exponencial como
desenvolvedor estava começando a chamar a atenção de várias empresas que
me chamavam para contínuas entrevistas me oferecendo salários cada vez
maiores para trocar meu serviço atual por uma nova oportunidade. Não me
entenda mal, eu não era tão bom assim. Mas em um mercado com déficit de
profissionais como o nosso, um jovem de 19 anos que já tinha um ano de
experiência de mercado com programação era algo bem visto.

Em uma das empresas que trabalhei nessa época, uma enorme fábrica de
software em São Leopoldo/RS, a pressão era enorme pois o nosso cliente-
chave, uma grande companhia de mídia do sul do país, queria tudo pra ontem
e pagando muito pouco. Éramos uma equipe de seis pessoas, incluindo aí um
Analista de Sistemas, um Gerente de Projetos, uma testadora e três
desenvolvedores, tocando um dos principais projetos do cliente que incluía
um portal de classificados que tinha milhões de usuários por mês.

A situação com esse cliente não era nada boa. Não estávamos conseguindo
atendê-lo com a agilidade que precisávamos e muitas cabeças estavam
rolando. O Analista do time, que não vou citar o nome, havia recém sido
promovido à essa função com a demissão do Analista anterior. Para ajudar,
nosso Gerente de Projeto era compartilhado com outra equipe, o que não
deixava que ele se dedicasse full-time ao nosso projeto. Para ajudar ainda
mais foi trazida para a equipe uma testadora full-time, uma vez que
geralmente os testers da empresa faziam parte de um setor compartilhado por
todos times. Mas como nossa situação era extrema, a empresa estava
adotando medidas extremas.

Lembro que na primeira semana minha na empresa, quando ainda estava me


adaptando à nova rotina, sistemas, etc e até mesmo passando por
treinamentos do RH, fui convidado para uma reunião do time. Lembro que o
gerente estava irado com os resultados e xingou todo mundo diversas vezes.
Me senti muito mal com aquilo, pois eu recém havia entrado e estava sendo
cobrado por coisas que o desenvolvedor anterior, que havia sido demitido,
não tinha conseguido entregar à tempo. No entanto, não encarei isso como o
"fim do mundo"e disse para mim mesmo que ia dar um jeito nisso. No
entanto, eu não sabia onde estava me metendo.

Logo percebi que eu não conseguiria atender às expectativas de prazos dos


projetos. Não pela minha pouca experiência, mas porque elas eram irreais.
Todos os prazos eram definidos pelo Analista de Sistemas, que participava
sozinho de reuniões com o cliente para especificação dos requisitos, escrevia
os casos de uso, calculava pontos de caso de uso ou algo semelhante a isso e
depois distribuía para os desenvolvedores do time. Qual você acha que é a
chance de uma estimativa egoísta como essa estar certa, considerando que o
analista era inexperiente, não conhecia o time direito (eu principalmente,
estava lá há poucos dias), o cliente pressionava-o constantemente para ser
mais rápido, etc?

Quem você acha que poderia fazer uma estimativa melhor sobre o quanto
tempo poderia demorar para realizar uma tarefa?

a. o time de desenvolvedores em conjunto;


b. o desenvolvedor que vai fazer aquela tarefa sozinho;
c. o gerente do projeto sozinho;
d. o analista de sistemas sozinho;

Não vou dar a resposta ainda, você vai descobri-la lendo o restante deste
capítulo. Apenas gostaria de dizer que não durei muito tempo naquela
empresa. Eles não me demitiram, eu me demiti após alguns meses de trabalho
pois estava enlouquecendo. Toda semana tínhamos reuniões como aquela
primeira, apenas para xingar todo mundo. No entanto, o modus operandi era
sempre o mesmo e embora todos os prazos sempre estourassem, eles
continuavam estimando da mesma maneira. Até um jovem de 19 anos sabe
que se você sempre fizer a mesma coisa, sempre terá os mesmos resultados.

Se você estiver em uma situação como essa, esse capítulo é para você!
Scrum Poker
Aviso: talvez você conheça este artefato pelo nome de Planning Poker.
Evitarei o uso desse nome uma vez que é uma marca registrada da empresa
Mountain Goat Software. Usarei Scrum Poker no lugar, que é o segundo
nome da ferramenta.

Como todo projeto de software começa com as estimativas, aqui não será
diferente. Durante o Sprint Planning o Scrum Guide nos diz que devemos
definir o que será desenvolvido na próxima Sprint. Mas como saber quantas
tarefas cabem em uma sprint? Vamos ter de estimar. E o Scrum Guide não te
diz como fazer isso...

No mundo do desenvolvimento de software, poucas coisas são tão difíceis


quanto estimar o tempo de desenvolvimento de um projeto. Existe um ditado
entre os profissionais de TI que diz:

“As duas coisas mais difíceis em desenvolvimento de software são dar nomes
às coisas que você programa e expirar cache.”

Eu adicionaria uma terceira: estimar tempo de desenvolvimento. Ouso citar


que é mais impreciso que a previsão do tempo, que todos sabemos que não dá
pra confiar muito...

Existem inúmeras técnicas, métodos, ferramentas e abordagens, mas em sua


maioria, elas falham ao serem unilaterais: o gerente do projeto estima quanto
tempo cada tarefa vai levar (usando seu método favorito, como Pontos de
Função ou Pontos de Caso de Uso, por exemplo), soma as tarefas e diz ao
time que eles têm de desenvolver o "Google inteiro" nos próximos 30 dias.

Quem nunca passou por esse tipo de situação?

O Scrum Poker, ao contrário, conduz o time a encontrar métricas que


funcionem para todos e a construir o escopo do que será feito na próxima fase
de desenvolvimento de maneira colaborativa. Ok, o gerente (P.O. neste caso)
ainda tem um papel essencial aqui: o de priorizar o que deve ser feito
primeiro, mas não é ele quem decide quanto tempo o time vai levar para
realizar seu intento. Apenas o time pode decidir isso.

Soa estranho? Mas não deveria...

Invenção oriunda do mundo dos Métodos Ágeis de desenvolvimento de


software, o Scrum Poker parte do pressuposto que somente os responsáveis
por executar uma tarefa podem dizer quanto tempo ela vai levar para ser
desenvolvida. E ninguém mais. Isso por duas razões básicas:

Razão número 1
O Scrum Poker incentiva a colaboração e, dessa maneira, os prazos estimados
serão lapidados por todos do time ao longo do processo (como verá mais
adiante), ajudando a mitigar erros de estimativas de gerentes otimistas (para
não dizer carrascos) ou de programadores pessimistas (para não dizer
preguiçosos).
Razão número 2
Uma vez que todos colaboram no processo de estimativa, existe um
sentimento de comprometimento compartilhado com o projeto. Se o time não
entregar no prazo, a culpa pelo atraso é inteiramente deles, uma vez que o
prazo não foi dado pela gerência.

Quem não gosta da técnica tende a argumentar que o Scrum Poker é uma
arma na mão de equipes preguiçosas, que a palavra final não deveria ser dos
desenvolvedores que podem querer "jogar" as métricas para o alto para
ganhar mais tempo. Mas aí eu pergunto: o culpado é o Scrum Poker? Ou é o
seu time preguiçoso? Não culpe a ferramenta pela pela imperícia do usuário...
Pokerface
O Poker no nome vem por conta de as estimativas serem feitas com um
baralho. Não um baralho comum, mas um que usa a Sequência de Fibonacci
(ou um cálculo próximo dela). Pra quem não conhece, a Sequência de
Fibonacci é mais uma invenção (ou seria melhor dizer "formalização"?) feita
por um matemático italiano para descrever o comportamento do crescimento
de uma população de coelhos. Daí para ser usada em estimativas de projetos
é um pulo (com o perdão do trocadilho), uma vez que o crescimento dos
números (e consequentemente do prazo) vai se tornando exponencial
conforme a complexidade do software aumenta e nos leva para o
desconhecido.

Na Sequência, que começa com os números inteiros 0 e 1, cada número é


resultado da soma dos dois números anteriores, ou seja, temos 0, 1, 2, 3, 5, 8,
13, 21, 34, 55, 89...No baralho de Scrum Poker essa escala foi simplificada,
mas a ideia é essa mesmo. Conforme a complexidade e o tamanho de um
software aumentam, não há como dizer com precisão quanto tempo vai levar
para desenvolvê-lo. E antes de torcer o nariz para o que estou dizendo, vai
por mim, estou há 10 anos nesse ramo. Já vi um bocado de projetos
estourarem prazo pela gerência não querer entender que não dá para estimar o
desconhecido com precisão.

Mas voltando ao baralho, a escala usada nos gera as seguintes cartas:


Algumas variações também incluem uma carta para o infinito, e outra para o
café, algumas vezes removendo a carta 100. Vou explicar cada uma mais
adiante.

Cada jogador (i.e. desenvolvedor do time) deve ter um desses baralhos no dia
em que for feita a estimativa do tempo que o projeto irá levar. Baralhos
prontos para imprimir não são difíceis de encontrar na Internet e nas
referências no final deste capítulo coloco links para alguns deles (os melhores
estão no topo da lista). Caso algum link esteja quebrado, não tem problema,
apenas procure por Scrum Poker (ou melhor, Planning Poker) no Google
Images e você encontrará várias.
Colocando em prática!
Primeiramente existe um tema de casa que deve ser feito pelo gerente do
projeto e/ou pelo analista de sistemas, dependendo de como isso está
organizado na sua empresa. Obviamente o Scrum Poker funciona melhor
caso a empresa já esteja adotando métodos ágeis no desenvolvimento de seus
projetos e, no caso do Scrum, o Scrum Master deve sentar com o Product
Owner antes da Sprint Planning para elucidar as tarefas e ver quais são as
prioridades para a próxima Sprint.

Uma vez que o Product Backlog esteja organizado, o Scrum Master (que não
joga Poker) senta junto com o time com o topo do Product Backlog
priorizado e quebrado em tarefas. O ideal mesmo é que o Product Owner
estivesse disponível para tirar dúvidas durante a reunião, mas sabemos que
isso não acontece na prática, e o Scrum Master acaba sempre como porta-voz.

A dinâmica funciona da seguinte maneira: para cada uma das tarefas (que
podem ser cards, caso esteja usando Kanban, como veremos nos capítulos
mais adiante) executamos essas ações:

Passo 1
O Scrum Master lê a tarefa em voz alta e responde dúvidas dos
desenvolvedores, cada qual com seu baralho de Scrum Poker em mãos. O
ideal é que ele comece com a tarefa mais fácil de todas, para que possamos
usar ela como referência depois, para estimar as demais.

Passo 2
Cada desenvolvedor escolhe uma carta do seu baralho, em segredo, baseado
no quão complexo acha a tarefa. Aqui vale uma explicação sobre as cartas
numéricas (os valores em horas são apenas para ter uma ideia):

● Carta 0: a tarefa não precisa ser feita por algum motivo (talvez já
esteja pronta)

● Carta 1: a tarefa é muito, mas muito simples, provavelmente menos


de 1h de desenvolvimento de qualquer membro da equipe

● Carta 2: a tarefa é simples, provavelmente leve menos de um turno


de trabalho, como uma manhã por exemplo.

● Carta 3: a tarefa é simples, mas trabalhosa e não deve ser


subestimada ocupando pelo menos um turno de trabalho, como uma
tarde (geralmente é mais longa que uma manhã).

● Carta 5: a tarefa é de complexidade mediana, provavelmente


tomando um dia de trabalho de um desenvolvedor, se não tiver
impedimentos

● Carta 8: a tarefa é complexa, vai demandar algum estudo ou muito


desenvolvimento, provavelmente tomando alguns dias da semana, com
2 ou 3 no máximo.

● Carta 13: a tarefa é muito complexa, vai demandar estudo


moderado ou é apenas muito longa de desenvolver, levando em média
uma semana de um desenvolvedor (5 dias úteis)

● Carta 20 em diante: a tarefa é complexa demais e não vale a pena


ser estimada. Sugere-se quebrar a mesma em tarefas menores, que
possam ser estimadas com mais exatidão

● Carta Interrogação (?): não entendi a tarefa sr. Scrum Master,


pode lê-la de novo e dar mais detalhes?

● Carta Infinito (quando houver, caso contrário, use a 100): não


temos como fazer esta tarefa sr. Scrum Master, ela é longa demais e
não cabe em qualquer pipeline de desenvolvimento. Sugiro quebrarmos
ela em tarefas menores ou dizer ao Product Owner que não tem como
fazermos (mais raro).

● Carta Café (ou Cerveja em algumas empresas): estou cansado de


tanto estimar, que tal tomarmos um café e depois voltamos?
Passo 3
Depois que todos escolhem suas cartas em segredo, revelam-se as escolhas,
sendo que o Scrum Master é o facilitador dessa dinâmica. Compara-se os
resultados e:

● Se todos forem iguais, anota-se o número obtido junto à tarefa e


reinicia-se a dinâmica com a próxima tarefa a ser estimada.

● Se houver divergências, o desenvolvedor que escolheu a carta com


menor valor justifica sua posição. Depois o desenvolvedor que
escolheu a maior carta justifica sua posição. O Scrum Master também é
convidado a explicar melhor esta tarefa. Todos jogam novamente até
entrarem em consenso.
Passo 4
Depois que todas as tarefas prioritárias foram estimadas (ou ao menos que o
feeling lhe diga que já passaram tempo demais estimando tarefas) o time de
desenvolvimento, baseado nas prioridades, seleciona quais tarefas ele se
compromete a executar nesta Sprint (obviamente de acordo com o tamanho
da Sprint que varia de 15 dias a 1 mês usualmente).

E é isso. Simples, não?!


Mas e o tempo?
Note que não existe um cálculo mágico para converter os pontos do Scrum
Poker em horas de trabalho, mas que depois de duas ou três sprints é comum
o time encontrar um consenso e descobrir a sua velocidade, sendo que o
Scrum Master deve auxiliar nesse processo de descoberta.

Os tempos estimados que menciono junto às cartas na seção anterior são


apenas uma ideia de valores que funcionam para os times de
desenvolvimento com os quais trabalhei. No fundo, os números do Scrum
Poker são uma medida relativa, conforme mencionei na etapa 1, geralmente
sendo usadas as tarefas mais fáceis para estimar as mais difíceis. Perguntas
como: "A tarefa x é mais difícil que a y, que estimamos em z?" norteiam as
jogadas pois é mais fácil estimar empiricamente, baseados em nosso
conhecimento prévio, do que pensando no futuro.

Um ponto importante que vale ressaltar é que as métricas são coletivas, ou


seja, a responsabilidade é de todos e não apenas do desenvolvedor que
provavelmente irá pegar a tarefa para si. Assim, não vale jogar qualquer carta
apenas porque você acha que não terá de botar a mão naquela tarefa. Afinal,
se o time falhar em entregar no prazo, a culpa será de todos, pois foi o time
que estimou as tarefas.

Outra dica é, depois de descobrir o tempo médio de cada uma, quebrar todas
as tarefas para que não extrapolem um dia de trabalho. A precisão costuma
ser muito prejudicada quando as tarefas são grandes demais, e um dia é um
bom padrão a ser adotado. Se uma tarefa for levar mais de um dia, quebre ela
em duas tarefas, por exemplo, e volte a estimar.

E por fim, é válido comentar novamente que o Scrum Poker funciona melhor
no mundo agile, principalmente quando usado em conjunto de um Kanban e
de um Burndown Chart. Geralmente ao término da Sprint Planning o Scrum
Master organiza as tarefas do Sprint Backlog em cards no Kanban (se ainda
não o fez) e constrói o Burndown Chart baseado no número de pontos da
soma das tarefas desta sprint versus o tempo da Sprint. Essas duas
ferramentas serão melhor apresentadas nos próximos capítulos, pois apesar
de não serem ‘oficiais’ no Scrum, são praticamente unânimes entre as equipes
ágeis e agregam muito valor para os pilares de inspeção e adaptação do
Scrum, que mencionei no capítulo anterior.

Vamos em frente!
Referências
Marca registrada do Planning Poker:
http://tsdr.uspto.gov/#caseNumber=3473287&caseType=US_REGISTRATION_NO&sea
Site onde é possível verificar o Trademark do Planning Poker original.

Pontos de Função:
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
Método mais tradicional de estimativa de tempo de desenvolvimento de
software.

Pontos de Caso de Uso:


https://en.wikipedia.org/wiki/Use_Case_Points
Outro método tradicional de estimativa de tempo de projetos de software.

Sequência de Fibonacci:
https://pt.wikipedia.org/wiki/Sequ%C3%AAncia_de_Fibonacci
Caso não conheça, link útil para entender do que se trata.

Baralhos de Scrum Poker:


1.https://blogagility.files.wordpress.com/2014/11/blogagility_planningpokerdeck_v2.jpg
2.http://www.pranjol.com/sites/default/files/field/image/PlanningPoker.jpg
3.http://arquivo.devmedia.com.br/artigos/Roger_Ritter/tecnicas_ageis/image006.gif
4.http://www.tekool.net/blogfiles/printable-agile-planning-
poker/agile_planning_poker_front.png
5.http://www.culturaagil.com.br/wp-content/uploads/2014/11/planning-
poker.png
6.http://www.mohammadsami.com/blogs/wp-
content/uploads/2014/03/Planning-Poker-Cards.png
7.http://www.agilefragile.com/images/other/agile-planning-poker-cards.JPG
Links para imagens de baralhos de Scrum Poker bons para imprimir e usar
em seu time ou para inspirar o seu designer a criar um personalizado para sua
empresa. Imagens encontradas na Internet, todos os direitos reservados aos
seus autores.
Capítulo 6: Como priorizar o Product Backlog
“Considering the current sad state of our computer programs, software
development is clearly still a black art, and cannot yet be called an
engineering discipline.”
- Bill Clinton

Trabalho e ensino outros a trabalharem com Scrum desde 2010. Independente


das empresas adotarem ou não a metodologia ágil mais utilizada (e com mais
cases de sucesso conhecidos) no mundo, sempre há o que aprender com seus
métodos inusitados e com a cultura que permeia este mundo ágil em geral.
Um dos pontos-chave em qualquer projeto, seja com Scrum ou não, é a
priorização de tarefas, tema deste capítulo.

Alguns especialistas que conheço dizem que basta perguntar ao cliente o que
ele quer e depois, o que ele quer primeiro.

Pergunte ao seu usuário e/ou cliente tudo o que ele quer no software e você
terá uma pilha de documentos com vários centímetros de altura e dezenas
(talvez centenas) de páginas. Depois pergunte à ele o que é mais importante e
ele vai lhe responder que tudo é importante. Pergunte o que é mais urgente e
ele vai te responder que tudo é urgente. Esqueça, isso não funciona. Pelo
menos dessa forma tão direta não.

Como fazer então? O primeiro passo é cortar o escopo!


Cortando o escopo
Simplesmente nunca teremos tempo hábil (e nem faz sentido) desenvolver
tudo o que o cliente acha que precisa no software. Principalmente na primeira
versão (já ouviu falar em MVP?) e é o seu dever ensinar isso a ele.

Gerentes de projeto tem de lidar com escopo, custo e prazo nos projetos.
Dificilmente conseguimos equilibrar essas três variáveis e, na minha opinião,
escopo é a que faz mais sentido cortar. Não apenas porque manter um
equilíbrio nessa balança de três pratos é quase utópico mas porque é o mais
inteligente a se fazer, pensando no sucesso do projeto como um todo.

Jason Fried fala no seu livro Getting Real que é melhor fazer meio-software
do que um software meia boca. E eu concordo com ele.

É no escopo onde temos sempre a maior quantidade de desperdício em um


projeto. E desperdício aumenta os custos e estoura os prazos, simples assim.
A Toyota passou a GM com seu método Lean focando em apenas uma coisa:
reduzir o desperdício.

Mas como reduzir o desperdício de escopo? Uma dica é usando o Princípio


de Pareto.
Princípio de Pareto
Use o Princípio de Pareto ou a "regra do 80/20", como muito bem apontada
por Tim Ferriss em seu best-seller Trabalhe 4h por semana. Pareto, uma
matemático italiano, determina uma relação de 80/20 ou simplesmente
maioria/minoria que é aplicada há muitas coisas em nosso cotidiano. Por
exemplo, 80% do uso de um software se dá em apenas 20% das
funcionalidades.

Isso quer dizer que apenas 20% de tudo que for desenvolvido será utilizado
realmente. O restante cairá no esquecimento.

Scrum enfatiza o foco na geração de valor para o cliente a cada entrega e a


chave para geração de valor é reduzir o desperdício priorizando muito bem o
que deve ser DONE em cada Sprint (falaremos da Definição de Pronto no
próximo capítulo). Ok, dentro do Scrum isso é uma tarefa para o Product
Owner, mas se você leu até aqui é porque de alguma forma está envolvido
com as decisões de produto também, certo?

Atualmente trabalho em um banco (Agiplan, o maior privado do RS) e como


todo banco, temos alguns processos e projetos inchados, burocráticos e
cheios de desperdícios. Alguns são culpa do Banco Central, outros são culpa
nossa mesmo.Algumas vezes parece que Agile e Lean jamais andarão de
mãos dadas com a palavra banco, mas essa é a minha função lá e tem sido um
trabalho bem interessante.

Cito o case do banco pois lá eu tenho cuidado da priorização de tarefas para


os times de desenvolvimento, além das minhas atribuições normais como
Scrum Master. Um aplicativo mobile de cartão de crédito, por exemplo, é
cheio de features, por mais que pareça algo simples como "comprar-e-pagar".
É troca de senha, de data de vencimento, aviso de viagem, solicitação de mais
limite, ajuste do limite atual, etc. Se deixar a equipe de negócio se empolga e
quer um Nubank pronto em duas sprints. Quem nunca passou por isso?

Minha estratégia neste projeto foi bem simples: priorização. Não vamos
entregar um Nubank em duas sprints, mas consegui priorizar as features
baseado no que agregaria mais valor ao cliente o mais rápido possível.
Assim, em três sprints teremos um app de cartão funcional com os 20% de
features que trazem 80% dos benefícios. E sim, nós vamos entregar, pois falta
apenas uma das três sprints e já estamos com boa parte das funcionalidades
essenciais prontas.

Mas como se chega neste nível de qualidade na priorização? Como saber o


que é mais prioritário dentre centenas de features que aparecem no backlog
todos os meses?
Conhecendo seu produto
O jeito mais óbvio é conhecendo o seu produto, o seu time e entendendo o
seu mercado. Óbvio que isto não é algo simples de se alcançar e existem
diversos outros fatores que impactam na priorização. Se você está lançando
uma versão nova de um produto, olhar o que os usuários realmente usam na
sua aplicação pode ajudar bastante a decidir o que deve entrar ou não em uma
nova versão. Se está lançando um novo produto, tente entrevistar usuários de
produtos concorrentes, vai lhe ajudar a entendê-los e fazer algo superior à
concorrência.

Quais são as dores do seu usuário? Priorize o que "dói mais". Se o que o
usuário mais reclama é de não ter um bom limite de crédito nos cartões
concorrentes, foque em fazer uma análise de crédito automatizada, eficiente e
que forneça um crédito condizente com a realidade (e histórico) de cada
cliente. Permitir que ele escolha a cor do seu cartão pode ficar pra depois.

O quê seu usuário mais utiliza no dia-a-dia? Entregue primeiro o que ele
espera como "mínimo viável" em produtos do seu nicho. Se o usuário
consulta o limite disponível no cartão todos os dias, mas apenas viaja para o
exterior anualmente, o que você acha que deve ser feito primeiro: consulta de
limite ou aviso de viagem? Se seu usuário troca de senha do cartão apenas
uma vez por ano (no máximo), mas paga faturas todos os meses, qual
funcionalidade deve ser o foco nas primeiras entregas?

Este tipo de raciocínio, sem muita técnica, ajuda bastante a priorizar o que é
realmente importante e deve ser posto na frente em um projeto de software.
Buy a Feature Game
Obviamente existem diversas técnicas que podem ser utilizadas para fugir do
"achismo" e até mesmo lidar com conflitos de egos que muitas vezes
irrompem em reuniões para priorização de backlog. Vou falar da minha
favorita: a técnica Buy a Feature Game, que é bem simples, lúdica e
eficiente.

Primeiro, escreva as histórias ou features do seu projeto em cards e deixe-os


todos espalhados em uma mesa. Não traga qualquer feature aqui, apenas
aquelas que já estão no roadmap próximo e/ou são minimamente importantes
ao projeto. Cada card postado na mesa deve ser lido, com a atenção de todos.
O ideal é que cada card possua um "preço" também, que pode ser a
estimativa de horas para desenvolvimento ou os story points, mas se não
estiver tudo estimado, não invalida a dinâmica, apenas reduz um pouco a sua
eficiência.

Para cada um dos envolvidos na priorização (de 4 a 7), geralmente


stakeholders ou até mesmo usuários, entregue à eles um maço de notas falsas,
tipo Banco Imobiliário. Se todas as tarefas estiverem estimadas e com
"preço", some os preços, divida o valor pelo número de participantes e
distribua esta quantia em notas para cada participante (poucas notas grandes,
muitas notas pequenas).

O dinheiro da dinâmica pode ser apenas post-its com os valores escritos ou


dinheirinho de brinquedo, à venda em bazares. Apenas não permita a
fabricação de dinheiro falso ao longo da dinâmica nem injeção ou lavagem
de dinheiro aproveitado de outras dinâmicas. :)

Já se não estiver tudo estimado mas se você estiver trabalhando com story
points ou horas e já souber quanto o seu time entrega por sprint, divida essa
quantia entre os participantes em notas, seguindo aquela mesma lógica do
Banco Imobiliário (poucas notas grandes, muitas notas pequenas). Você pode
jogar o B-a-F Game uma vez para várias sprints, por exemplo, somando a
capacidade das sprints na hora de distribuir as notas.
Se suas sprints são de 15 dias e você entrega 30 pontos em cada sprint, você
pode priorizar uma vez a cada 30 dias, emitindo 60 pontos de notas para os
participantes, por exemplo. Para que os valores não fiquem muito limitados,
sugiro multiplicar story points por $10 ou até $100 mesmo, enquanto que
horas geralmente não possuem esse problema.

Sem nenhuma regra, cada participante pode depositar o seu dinheiro sobre
cada card, representando o seu interesse e/ou o quanto aquela feature vale a
pena ser implementada. Aqui, cada um terá a sua própria percepção de
prioridade, mas como o dinheiro é limitado, eles serão obrigados a trabalhar
com esta limitação na hora de distribuir as notas.

Esta limitação de dinheiro ilustra bem as limitações reais de um projeto como


a verba, as horas-homem, etc. Ajuda os stakeholders a "sofrerem" com as
decisões difíceis que o gerenciamento de um projeto exige. Caso seus cards
possuam outras limitações, como precedência, crie combos de produtos do
tipo "para comprar esse, tem de comprar o outro primeiro".

Quando todos terminam sem dinheiro (deixe que discutam e troquem as notas
de lugar até o final da dinâmica), basta somar quanto cada card recebeu e os
que receberam mais dinheiro são os mais prioritários. Opcionalmente, se
estiver trabalhando com as estimativas, uma feature só vira de fato prioridade
se ela recebeu um valor mínimo equivalente ao valor necessário para sua
compra.

Se uma feature exige 100h de desenvolvimento, ela não entrará na próxima


sprint se não alcançar $100 de 'doações' dos stakeholders, por exemplo.

Permita uma pequena discussão sobre o resultado da distribuição de notas


logo após exibir os cards que se mostraram mais prioritário (i.e. que
receberam mais $). Isso tende a gerar algumas movimentações de capital, o
que é perfeitamente normal, mas ao término da sessão, o que ficou definido é
o que será utilizado como prioridade do backlog e orientará os times nas
próximas semanas.
Obviamente que nenhum método é perfeito, mas assim como o Scrum Poker,
que vimos no capítulo anterior, este método baseia sua eficácia no consenso
entre os envolvidos no projeto e o conhecimento que cada um tem do produto
e do mercado para priorizar de uma maneira caótica, mas organizada.
Referências
Produto Mínimo Viável (MVP)
Um Minimum Viable Product, tal qual concebido por Eric Ries no best-seller
Lean Startup, é um protótipo de produto que permite que empreendedor
validar o interesse do seu mercado pelo produto, o quanto eles pagariam pelo
mesmo, quais as funcionalidades mais importantes, etc. Aprenda mais sobre
neste link: http://www.luiztools.com.br/post/criando-um-mvp-na-pratica/

Jason Fried
Fundador da 37signals, uma empresa que nasceu como uma agência web e
que mais tarde se tornou famosa pela criação de SaaS como o fantástico
Basecamp, tornando-os referência em criação de produtos inovadores no
mundo inteiro.
http://www.basecamp.com

Getting Real (Caindo na Real)


Um livro de Jason Fried e David Heinemeier Hanson, fundadores do
Basecamp, sobre como construir produtos digitais de maneira eficiente e
prática. http://www.luiztools.com.br/post/resenha-getting-real/

Princípio de Pareto
Lei natural observável no mundo à nossa volta cunhado por um matemático
italiano. Ele trata de coisas como 80% das riquezas do mundo estão nas mãos
de 20% das pessoas, ou 80% dos resultados de uma empresa vêm de 20% dos
funcionários, etc. https://pt.wikipedia.org/wiki/Princ%C3%ADpio_de_Pareto

Tim Ferriss
Timothy Ferriss é um empreendedor americano, investidor de risco,
palestrante e autor de livros best-sellers que fogem do convencional para
ensinar as pessoas como terem sucesso nos negócios, na saúde, etc.
https://tim.blog/
Trabalhe 4h por semana
Primeira e mais famosa obra de Tim Ferriss, quando ainda empreendia no
ramo de venda de suplementos nutricionais online. O livro trata de como
você pode, de maneira inteligente e eficiente, criar um negócio online e viver
de renda passiva morando onde quiser.
http://www.luiztools.com.br/post/trabalhe-4-horas-por-semana-resenha/
Capítulo 7: Como refinar o Product Backlog
"Perfection [in design] is achieved, not when there is nothing more to add,
but when there is nothing left to take away."
- Antoine de Saint-Exupéry

Dentre as tarefas principais do papel de Product Owner, dentro do Scrum,


está o refinamento do product backlog. O Product Backlog, ou Backlog de
Produto, é o artefato ágil para gerenciar os requisitos de um determinado
produto. Este artefato é de domínio exclusivo do Product Owner, que refina-o
constantemente para que os itens mantenham-se priorizados (usando diversas
técnicas), detalhados e que façam sentido com a estratégia de mercado em
cima deste produto.

Imagine que quando um novo produto está sendo criado temos uma vaga
ideia do que queremos que ele se torne. Dentre tudo o que gostaríamos de ter
no produto (o roadmap), o Product Owner deve priorizar o que é mais
urgente, trará maior valor aos clientes ou trará o ROI mais rapidamente. Estes
itens mais prioritários são então detalhados (em User Stories, por exemplo)
para que sejam entregues ao time de desenvolvimento trabalhar durante a
próxima iteração. Enquanto o time trabalha no desenvolvimento destes itens
(o Sprint Backlog), o P.O. trabalha no refinamento dos itens da sprint
seguinte, para que tenhamos itens priorizados e detalhados para a Sprint
Planning seguinte.

Parte desse processo de refinamento, limitado em até 10% da capacidade de


trabalho do time de desenvolvimento, pode ser compartilhado com o time de
desenvolvimento, em sessões de Product Backlog Refinement, também
chamadas de Grooming Sessions. Nestas sessões, o Product Owner faz uma
prévia do que ele planeja para a Sprint Planning seguinte, o time já faz
questionamentos, já agenda spikes e/ou POCs e já dá um overview de riscos e
preocupações que eles possuem em cima do que está sendo planejado.
Futuramente, usa-se o feedback recebido nas Sprint Reviews e do próprio
mercado (quando as primeiras versões do produto estão em produção) para
ajudar neste processo de refinamento, criando um ciclo virtuoso de melhoria
contínua.

Até aí tudo bem, mas o que pode dar errado no processo de refinamento do
Product Backlog?

Muitas coisas!
Priorização e refinamento externo
Quem prioriza o Product Backlog é o PO. Ponto. Qualquer outra opinião ou
feedback externo é bem vindo, mas a decisão final das prioridades de
requisitos a serem entregues pro time de desenvolver é do PO. Obviamente
que o mesmo deve estar alinhado com a estratégia da empresa para não criar
um produto que não ajude a organização a atingir a sua visão, mas jamais o
PO deve ser alguém que "apenas" repassa as prioridades da empresa para o
time de desenvolvimento. Tire esse poder do Product Owner e teremos um
Waterfall 2.0.

Outra falha é muitas vezes o P.O. copiar-e-colar os itens de backlog de algum


documento dos stakeholders. A construção do product backlog é um trabalho
criativo, iterativo e incremental. Não é uma conversão de um modelo
tradicional para um modelo ágil para que o time se sinta melhor dizendo que
trabalha ágil.
Product Backlog Completo
Jamais o P.O. deve querer refinar completamente o Product Backlog de uma
vez só, no início do projeto. Se o seu escopo é fechado e o seu produto final
já está delimitado, qual o sentido de rodar Scrum ou qualquer outro método
ágil? Qual a chance de você estar certo hoje sobre as features que serão
necessárias no seu produto daqui a 6 meses? Onde entra a inovação neste
processo?

O refinamento do Product Backlog deve ser iterativo e incremental, assim


como o Scrum e o Lean Startup pregam. Mantenha um estoque de itens
priorizados e detalhados para até um mês à frente, no máximo. Mais do que
isso e a chance de você jogar muito trabalho fora é enorme.

Isso é uma verdade ainda maior no que tange estimativas de tempo de


projeto. Jamais deixe que o time de desenvolvimento estime mais do que uma
sprint e meia. A chance de estimativas "perderem a validade" nestes casos é
muito grande em virtude de mudanças de arquitetura, dependências,
prioridades, etc é muito grande e com isso perdemos o tempo que se levou
estimando.
Parking Lot misturado com backlog
Features que não são debatidas, priorizadas ou detalhadas há mais de um mês
devem sair do Product Backlog para não atrapalhar refinamentos posteriores.
A sugestão é criar um backlog separado, chamado de Parking Lot ou Icebox.
Abordagens mais drásticas como a do Getting Real dizem que estas features
deveriam simplesmente ser excluídas. Se elas realmente forem importantes,
voltarão a aparecer.
Histórias incompletas
As histórias devem sempre buscar entregar valor ao usuário final, de uma
ponta a outra, o chamado "fatiamento vertical de features". Histórias que
entregam cenários pela metade, os famosos componentes (fatiamento
horizontal), devem ser evitadas ao máximo pois causam um acúmulo de itens
com pendências que não podem subir para produção.

Só geramos valor com o produto quando o usuário passa a gerar valor com
ele. Até então, temos investimento ou desperdício, mas nunca geração de
valor.

Além disso, um item do product backlog somente deveria ser dado como
refinado quando os seus critérios de aceitação estão claros. Apenas escrever a
história (ou pior ainda, apenas ter um título) não é o bastante. Um artefato
que ajuda o Product Owner a ter certeza que sua história está pronta para
entrar na próxima sprint é a Definição de Preparado (Definition of Ready).

Basicamente uma Definição de Preparado é um checklist (assim como a


Definição de Pronto) que deve ser repassado para garantir que cada história
realmente está 'preparada' para entrar em desenvolvimento. Obviamente isto
pode variar de time para time mas coisas como critérios de aceite, o modelo a
ser seguido de user story, um screenshot da UI desenhada, etc são coisas que
você pode ter. Nenhuma história deveria ser discutida em uma Sprint
Planning sem antes ter sido preparada em groomings.
Histórias 'completas' demais
O papel do P.O. é definir para 'quem' criamos 'algo' e 'porquê', mas jamais
'como' o time deve fazer isso. A multidisciplinaridade de um time de
desenvolvimento deve garantir, por exemplo, que tenhamos profissionais de
UX para criar as melhores experiências e interfaces gráficas, que tenhamos
profissionais de QA para garantir a qualidade da entrega, profissionais de
sistemas para garantir a melhor técnica de programação e assim por diante.
Deve haver confiança de que cada pessoa é capaz de executar a sua atribuição
da melhor maneira possível e que a soma de todos é que constrói o melhor
produto, e não o ego de uma pessoa apenas.

Se o PO define como os programadores devem escrever o código, como os


designers devem criar as telas e como os testers devem testá-las, porque
temos um time? Não é mais fácil terceirizar tudo pela Internet? E qual a
chance dele ser bom de fato em todas estas skills, além da skill de negócio
que é a mandatória do papel?

Detalhe as histórias até o ponto que o time de desenvolvimento tenha as


informações necessárias para aplicar as suas skills da melhor forma que eles
entenderem, sem jamais restringir a sua capacidade criativa e intelectual
impondo requisitos técnicos demais que fogem ao escopo de negócio. Mesmo
no âmbito de negócio, o P.O. deveria consultar os stakeholders para garantir
sempre o alto alinhamento com a empresa.
Itens de backlog soltos
Todo item de backlog deve fazer parte de uma hierarquia que faça sentido
dentro da estratégia do produto, para que seja possível entender porque ele é
importante ou onde ele se encaixa.

Itens de backlog soltos geram software desenvolvido que não se encaixa em


lugar nenhum, telas que não "conversam" com as demais telas do sistema,
regras de negócio e de experiência que não são uniformes, etc. Quer você
opte por apenas dois níveis (épicos e histórias) ou mais níveis (no TFS temos
épicos, features, histórias e tarefas, por exemplo), é importante que cada
história faça parte de algo maior.

A composição total dos épicos é o que chamamos de roadmap e o ideal é que


ele seja público (transparente) e que não seja mais longo do que 3 meses para
produtos inovadores e complexos. Além disso, ele deve ser minimamente
possível de se realizar dentro do time-to-market pelo time existente, mesmo
sem um estudo detalhado e estimativas minunciosas.
Achismos
Ok, o Product Owner tem a palavra final sobre o Product Backlog, mas ele
sempre deve ter argumentos para explicar a sua priorização e detalhamento.
Itens obscuros devem ser estudados, itens complexos devem ter spikes e
POCs, itens que dividem opiniões devem ter dados de mercado e assim por
diante.

Forçar sua opinião para definir uma história sem argumento é o primeiro
passo para quebrar a confiança com seu time ou pior ainda, quebrar a cara
com seu produto.
P.O. Parcial
A função de Product Owner é uma demanda de tempo integral que não se
ajusta bem a mais responsabilidades. Refinar o product backlog apenas uma
vez por semana antes da próxima Sprint Planning não é o bastante, esse
refinamento deve ser diário, de acordo com a evolução do projeto nas mãos
do time.
Time submisso
O time deve contribuir com o product backlog durante o refinamento e
principalmente durante a Planning. Um time submisso que apenas executa o
que o Product Owner decide acaba se metendo em confusão rapidamente.

Dificilmente o Product Owner irá se atentar ou mesmo priorizar débito


técnico. Cabe ao time levantar esta bandeira quando necessário. Poucos P.O.s
tem capacidade, principalmente em início de projeto, de entender se um time
está se sobrecarregando ou não em uma Sprint Planning, o próprio time tem
de ter esse discernimento e dizer 'chega' quando acreditarem que já se
comprometeram com itens suficientes para a sprint. E os incidentes? Se o
produto já está em produção, podem acontecer incidentes e é importante o
time manter o P.O. a par do volume de chamados que costumam entrar ao
longo do período da sprint.

Referências
Definition of Ready: http://blog.adaptworks.com.br/2012/12/definition-of-
ready-qualidade-na-entrada-das-sprints/#.WoJiUZM-dZ0
Artefato ágil para garantir que um item de backlog somente possa ser pego
por um desenvolvedor sob determinadas condições.

Buy a Feature Game: http://www.innovationgames.com/buy-a-feature/


Técnica para priorização de roadmap.

Futurespective: https://www.benlinders.com/2015/how-futurespectives-
help-teams-to-reach-their-goals/
Outra técnica para priorização de roadmap.

Planning Poker: https://www.culturaagil.com.br/planning-poker-tecnica-


baseada-consenso/
Técnica usada para estimar esforço de desenvolvimento.

Épicos: https://www.atlassian.com/agile/project-management/epics-stories-
themes
Um framework de estruturação de roadmap com uma boa granularidade. Não
é exatamente o que eu uso, mas é interessante.
Capítulo 8: Qualidade e Definição de Pronto
"In the one and only true way. The object-oriented version of 'Spaghetti code'
is, of course, 'Lasagna code'. (Too many layers)."
- Roberto Waltman.

Em 2015 eu fui chamado para ajudar a gerenciar o projeto de uma startup de


tecnologia no Rio Grande do Sul. Apesar de ser gaúcha, ela atendia clientes
do mundo inteiro com um produto extremamente inovador relacionado a
marketing digital. Quando eu falo "ajudar a gerenciar", era exatamente isso
que eu fazia, visto que a empresa possuía um CEO e possuía um líder
técnico, e por algum motivo eles não se entendiam de maneira que o
desenvolvimento do produto fluisse rumo ao que levaria a empresa ao
product-market fit a curto prazo e a uma situação financeira saudável a médio
prazo. Ou seja, eu não detinha o poder de decisão de produto e nem de
tecnologia, cabendo a mim os papéis de "consultor" e "facilitador", visando
uma mudança radical de processos na empresa.

Durante três meses não promovi grandes mudanças. Analisei o modus-


operandi do time, identifiquei as principais deficiências, conheci o produto e
o mercado e estudei como as startups do Vale do Silício estavam conduzindo
seus projetos para entender o que estava funcionando (ou não) para startups
como eles. Em dado momento senti confiança suficiente para começar a
ousar mudanças na equipe, mesmo sendo um completo "estrangeiro" dentro
deste time que já tinha três anos de existência e quase nenhum faturamento.

Passamos a ter sprints, a fazer reuniões de planejamento e de ter


retrospectivas para melhorar os processos. Passamos a usar um kanban para
alinhar as tarefas, manter um registro de releases passadas e muito mais. A
transparência do projeto aumentou a velocidade com que o time desenvolvia,
passamos a entregar mais features e mais rápido, mais alinhadas com o
mercado e com isso passamos a adquirir novos clientes semanalmente. No
entanto, nem tudo eram flores e alguns atritos começaram, uma vez que
muitas coisas que eu propunha entravam em conflito com a forma como o
CEO e o líder técnico acreditavam que era o correto de se conduzir o projeto.
Um destes pontos era como a qualidade do projeto deveria ser gerenciada.

Perdíamos novos clientes na mesma velocidade em que adquiríamos, devido


a inúmeros bugs na ferramenta que impediam que todo seu potencial fosse
aproveitado. O líder técnico queria muito convencer todos que o problema de
qualidade do time somente seria sanado com a contratação de um testador
profissional. Mas não tínhamos dinheiro pra isso, logo, ele não acreditava que
pudéssemos resolver esta questão de qualidade.

Eu discordava, pois conhecia o poder de uma Definição de Pronto bem


elaborada. Ficamos nesse impasse durante alguns meses, eu não conseguia
convencer os líderes do projeto que deveriam adotar este artefato e
inevitavelmente o projeto foi encerrado por falta de verba e de interesse dos
fundadores.

Foi uma pena. O produto era bom, apenas precisava ser "lapidado". O time
era bom, apenas estava "viciado" em um modelo fadado ao fracasso havia
três anos.

Foi um dos maiores fracassos da minha carreira.


Definição de Pronto
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 neste capítulo!

Basicamente a definição de pronto é o documento que define o que "pronto"


(done) significa para todos envolvidos no projeto. 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 é um checklist de coisas a serem
realizadas/verificadas, 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 de ouro: coloque ao lado do Kanban, bem próximo da
coluna DONE.
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, que deve estar consonante com o que o cliente espera.

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

Um bom começo é, durante a primeira Sprint Planning, o time definir a


versão inicial 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?), faça


iterações 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), traga novamente 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 Scrum Poker, por exemplo, e sempre a leve em consideração para
estimar cada uma das tarefas.
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. Também não é um elemento legal, jurídico,
que os programadores tenham de assinar e que possam sofrer litígios, embora
pedir que todos assinem a definição de pronto possa ser interessante, como
um reforço ao compromisso firmado.

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 exequível, coerente. É 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 é 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, pontos de partida. 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 atualizada 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, deve 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, 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, pois
sabemos que muitos requisitos possuem dependências.

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 (Test Driven Development) 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.
Muitos times assumem esse compromisso sem saber a encrenca na qual estão
se metendo.
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 a gente sabote os testes visando não encontrar bugs.
Geralmente outro colega da equipe (chamado cross-tester ou peer-reviewer),
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!". No capítulo 7 falarei mais
disso.

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. Nenhum software jamais será tão
estúpido quanto um usuário final para descobrir comportamentos
inesperados na aplicação.
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, para dizer o mínimo. 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. Obviamente para que isso funcione, estas
normas também devem estar visíveis e serem de conhecimento geral do Time
de Desenvolvimento. Nas referências deste capítulo você vai encontrar alguns
links das convenções de código de algumas empresas famosas.

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,
Producteev ou Pivotal Tracker, para citar alguns exemplos). 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 prontas.

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 frágil.

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.
Referências
Testes Unitários: https://pt.wikipedia.org/wiki/Teste_de_unidade
Caso não conheça a técnica, este artigo lhe dá um overview de Unit Testing.

TDD: https://pt.wikipedia.org/wiki/Test_Driven_Development
O mesmo dito anteriormente, mas sobre a técnica de Desenvolvimento
Orientado a Testes.

Peer-review: https://pt.wikipedia.org/wiki/Revis%C3%A3o_por_pares
Revisão em pares para completos leigos.

Padrões de Codificação do Google:


https://google.github.io/styleguide/javaguide.html
Documento de padrões de código dos funcionários do Google para uso da
linguagem Java (eles usam diversas linguagens na empresa).

Padrões de Codificação da Oracle:


http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
Antigos (embora ainda em uso) padrões de codificação da linguagem Java
criados pela Sun.

Padrões de Codificação da Microsoft: https://msdn.microsoft.com/en-


us/library/ff926074.aspx
Documento-mãe dos padrões de codificação para a plataforma .NET da
Microsoft (reza a lenda que nem mesmo eles seguem seus padrões à risca...).

Trello: http://www.trello.com
Ferramenta online gratuita para criar boards e cards para gerenciamento de
projetos e tarefas.

Pivotal Tracker: http://www.pivotaltracker.com/


Ferramenta online bem específica para para gerenciar projetos ágeis, suas
sprints, tarefas, etc.

Producteev: http://www.producteev.com
Uma ferramenta não tão específica quanto Pivotal Tracker, mas igualmente
útil.

Media Wiki: https://www.mediawiki.org/wiki/MediaWiki


Sistema de gerenciamento de conteúdo (CMS) para criar wikis.
Capítulo 9: Pipelines com Kanban
“For a long time it puzzled me how something so expensive, so leading edge,
could be so useless. And then it occurred to me that a computer is a stupid
machine with the ability to do incredibly smart things, while computer
programmers are smart people with the ability to do incredibly stupid things.
They are, in short, a perfect match.”
- Bill Bryson

Uma das coisas que mais me fascina neste mundo pouco ortodoxo de
gerenciamento de projetos usando métodos ágeis são os artefatos.

Eu já falei de Scrum Poker anteriormente, uma técnica utilizada no mundo


ágil para estimar tempo de desenvolvimento de projetos de software. Mas e
depois de as estimativas terem sido feitas, como eu gerencio o andamento do
projeto?

E aí que entra o Kanban para cuidar dos pipelines de desenvolvimento de


maneira ágil. Da manufatura de peças industriais até o desenvolvimento de
modernos SaaS, o Kanban é uma unanimidade no que tange transparência,
alinhamento e controle do andamento de um projeto. Se eu tivesse de
escolher apenas uma técnica ágil para aplicar em um projeto, certamente
escolheria ela.

Lembro em 2012 quando decidi abrir minha própria empresa e virei um faz-
tudo de TI. Como eu não tinha um foco definido, pegava contratos de
desenvolvimento e de consultoria dentro de qualquer área que pagasse bem.
Logo descobri que minhas experiências com Scrum tinham um alto valor no
mercado e passei a ensinar outras empresas a usar esta metodologia.

Uma dessas empresas foi uma software house gaúcha que desenvolvia
projetos web e mobile para grandes agências digitais. Clientes grandes como
marcas de sabão em pó, refrigerantes e marketing digital contratavam os
serviços dessa empresa para terceirizar suas demandas de programação. Com
uma equipe aumentando e novos projetos aparecendo, era hora deles se
profissionalizarem. O dono da empresa era um ex-colega de trabalho e me
chamou para treinar ele e sua equipe em métodos ágeis.

Apliquei o mesmo treinamento que proponho aqui neste livro nos capítulos
finais. Após o treinamento o time seguiu tudo como mandava o figurino
durante os primeiros dias e as mudanças nos resultados foram drásticas. Ao
longo do tempo, no entanto, algumas partes do processo foram sendo
substituídas e/ou negligenciadas. Felizmente os princípios não se perderam e
o time se manteve produtivo mesmo sem seguir o Scrum à risca, mostrando
que o time era bom, apenas precisava de algumas orientações gerais.

Anos mais tarde voltei naquela empresa para ver como estavam. Trocaram de
escritório, atendem clientes maiores e o faturamento continua a crescer.
Curiosamente notei que ainda usavam o Kanban, tal qual ensinei a usar anos
antes. De tudo que ensinei, é o que jamais abriram mão e o que os manteve
"na linha", crescendo.

O Scrum não é uma verdade universal ou uma bala de prata. Ele é um


primeiro caminho para que você descubra o que funciona e o que não
funciona com a sua equipe, e para que você evolua a partir desse diagnóstico.

Nas artes marciais japonesas chamam isso de Shu Ha Ri. Primeiro você
aprende a forma (Shu), depois você inova (Ha) e por último você esquece
tudo e apenas "faz" (Ri).

Esta software house chegou no Ri. E fico feliz de ter ajudado eles no
processo.
Kanban
Kanban é uma palavra japonesa para "cartão" ou para "sinalização", e não é
algo originário no mundo de software, sendo usado há décadas na área
industrial para o controle de transporte e produção de mercadorias. O Kanban
do gerenciamento de projetos é literalmente o uso de cartões para sinalizar o
andamento do projeto, então o nome casa muito bem.

Você já deve ter visto isso em alguma empresa: um painel na parede com
diversas colunas e post-its espalhados entre elas, com cores diferentes e cheio
de rabiscos. Possivelmente era um kanban.

Um dos pilares do Scrum é a transparência, conforme discutido no capítulo


inicial, que diz que todos os responsáveis pela execução de um projeto devem
ter noção do andamento do mesmo. Assim, o kanban não é uma ferramenta
exclusiva para gerentes de projeto, mas sim uma ferramenta para deixar todo
o time alinhado.

Não obstante, os outros dois pilares do Scrum, inspeção e adaptação, são


fortalecidos pelo Kanban, uma vez que qualquer membro do time pode
inspecionar o andamento do projeto e sugerir melhorias para os cartões do
kanban, como será visto a seguir.
Como funciona?
Um Kanban é um painel, tipicamente uma parede, placa de vidro, placa de
ferro com pintura epóxi ou fórmica. Esse painel é dividido em colunas, sendo
que as mesmas podem variar conforme o projeto ou necessidades da empresa,
mas tipicamente vemos essas três colunas:

● TODO: Nessa coluna listamos as tarefas que devem ser feitas nessa
Sprint (curto prazo)

● DOING: Nessa coluna listamos as tarefas que estão em andamento,


que já foram iniciadas. Deve ter também uma sinalização de quem está
executando esta tarefa.

● DONE: Nessa coluna listamos as tarefas concluídas nesta Sprint,


que só são removidas após o término da mesma. Os requisitos para que
um cartão chegue até esta coluna variam de equipe para equipe e,
segundo os métodos ágeis, deve ser documentado em um artefato
chamado Definição de Pronto.

Outras colunas comuns de serem vistas em kanbans de times de software


(afinal é uma prática independente de setor, tendo sido originada na indústria)
são:
● IMPEDIMENTOS: Tarefas trancadas por algum motivo, com
alguma sinalização do motivo do impedimento. Esta coluna deve ser
revisada diariamente pelo Scrum Master a fim de resolver os
impedimentos.

● TESTING: Tarefas que estão em ambiente de testes ou


homologação, com alguma sinalização de quem deve testá-la (ou quem
está testando atualmente) e quase prontas para a coluna DONE.

● IDEIAS & SUGESTÕES: Tarefas que surgiram ao longo da sprint,


que não foram iniciadas para não atrapalhar o prazo, mas que podem
servir de insumo para a próxima reunião de planejamento.

Em cada uma dessas colunas são colocados cartões contendo a descrição de


uma tarefa (geralmente sob a perspectiva do usuário, como uma User Story),
o responsável por sua execução (podendo estar vazio no caso da coluna
TODO) e o tempo de execução, seja em pontos obtidos no Scrum Poker,
pontos de função ou qualquer outra métrica que estiver utilizando. Esses
cartões são preenchidos durante o Sprint Planning ou logo após ele, sendo
tarefa do Scrum Master.

Não podemos ter cartões repetidos e cada cartão fica apenas em uma coluna
por vez, geralmente avançando da esquerda para a direita, como em uma
linha de produção. TODO para DOING, DOING para DONE. Note que este
artefato substitui (ou complementa) o Sprint Backlog sugerido no Scrum, que
é o conjunto de tarefas que serão executadas nesta sprint pelo time, e pode ser
usado em conjunto do Burndown Chart (que será visto mais pra frente), para
que fique mais claro se o time vai ou não alcançar a meta no ritmo em que
estão.

Exemplos de cards a serem usados no kanban podem ser encontrados nos


links das referências deste capítulo. Não é difícil de encontrar outros
exemplos procurando no Google Images por Kanban Scrum Cards ou algo
parecido e note como cada um é completamente diferente um do outro,
variando principalmente de acordo com a forma como a equipe prioriza e
estima as tarefas, o que pode ir de algo muito simples (Scrum Poker + post-
its) até algo bem mais complexo e não-tão-ágil assim (Use Cases + User
Stories).

O segredo aqui é achar algo que funcione em seu time e que se sintam
confortáveis de usar. Na dúvida, comece com algo simples e rápido, não
perca tempo tentando montar o primeiro kanban perfeito logo de cara, levam
algumas sprints para você entender o que é útil realmente ao seu time.
Considerações Adicionais
Cabe ao Scrum Master cobrar o uso dos métodos ágeis pela equipe, e isso
inclui cobrar atualizações das tarefas do Kanban.

Cartões há muito tempo parados na mesma coluna devem ser investigados


(principalmente se existir uma coluna IMPEDIMENTOS), cartões novos que
surgirem devem ser muito bem pensados se entram ou não no pipeline (uma
vez que podem comprometer a entrega final) e assim por diante. Cheguei a
mencionar isso no capítulo anterior sobre a Definição de Pronto, que uma
tarefa só deveria ser considerada pronta se estivesse atualizada no Kanban.

Devido à isso, é bem comum que o local escolhido para as reuniões diárias
propostas pelo framework Scrum seja em pé, na frente do kanban, para que
seja mais fácil para todos alinharem suas ideias e tarefas. Obviamente isso é
uma dica minha, não é uma regra.

Também não falei a respeito de bugs. Cartões de bugs tendem a ter mais
prioridade sobre os demais, sendo um dos poucos que podem ser adicionados
ao pipeline no meio de uma sprint, e não é incomum eles usarem cartões ou
post-its de cor diferente, para diferenciá-los dos demais. Encoraja-se não criar
uma coluna exclusiva para bugs, mas sim usar as já existentes.
Kanban Virtual
Tenho certeza que alguns leitores irão torcer o nariz para a ideia de ter um
painel cheio de cartões colados na parede do escritório. Eu poderia ficar aqui
escrevendo dezenas de linhas a respeito das vantagens de fazer o kanban à
moda tradicional, mas como eu mesmo não tenho usado dessa maneira
ultimamente, vou falar de uma ferramenta quase tão boa quanto, vamos falar
de coisa boa, vamos falar do Trello!

O Trello é uma ferramenta online gratuita em que podemos criar boards, que
nada mais são do que painéis onde podemos ter colunas/listas com cards
dentro delas. Cada card pode ser associado a uma pessoa (você pode convidar
tantas pessoas quanto quiser para o seu board), ter checklists, prazo,
mensagens, etc e você pode arrastar os cards de uma coluna/lista para outra
facilmente com o mouse. Lhe soa familiar? Pois é, podemos facilmente usar o
Trello como um kanban!

Como o Trello permite que você tenha vários boards, é possível usar o Trello
para não somente colocar o kanban/Sprint Backlog, mas também o Product
Backlog que será mantido pelo Product Owner com colunas organizadas por
tipo de tarefa, por exemplo, como desenvolvimento, marketing, design, etc.
Existem outras ferramentas mais poderosas que o Trello para gerenciar seus
projetos ágeis, mas a simplicidade dele é sem igual e se você nunca usou, lhe
aconselho a tentar.

Referências
Kanban: https://pt.wikipedia.org/wiki/Kanban
Um pouco do Kanban original, da engenharia de produção, para completos
leigos.

User Stories:
https://pt.wikipedia.org/wiki/Hist%C3%B3ria_de_usu%C3%A1rio
Para quem não conhece esse artefato ágil, vale a leitura.

Trello: http://www.trello.com
Ferramenta online gratuita para criação de boards e cards para gerenciamento
de projetos e tarefas.

Exemplos de cards para Kanban: 1.http://www.eylean.com/blog/wp-


content/uploads/2015/09/kanban-task-4.png
2.http://www.eylean.com/blog/wp-content/uploads/2015/09/kanban-task-
3.png
3.http://gwb.blob.core.windows.net/markpearl/Windows-Live-
Writer/The_7CC0/Planned%20Story%20Card%20v2%20(2)_2.png
Links para imagens com exemplos de cards a serem usados em kanbans
Scrum. Imprima diretamente ou use como inspiração para pedir ao designer
da equipe que crie os seus personalizados.

Pivotal Tracker: http://www.pivotaltracker.com/


Uma ótima ferramenta que substitui o kanban em times que não gostam da
ideia de um quadro com cartões.
Capítulo 10: Prazo com Burndown Chart
"Good design adds value faster than it adds cost."
- Thomas C. Gale

No Scrum chamamos as ferramentas usadas em conjunto com os processos


de artefatos e a esta altura do livro você já deve saber disso. 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 capítulo vamos entender o porquê e como usar esta ferramenta.

Mas antes de entrar nos detalhes, deixa eu lhe contar uma história. Eu sou
professor do ensino superior na Faculdade de Tecnologia de Porto Alegre.
Uma das disciplinas que eu leciono é a de Engenharia de Software, onde
entre vários assuntos eu falo de processos de desenvolvimento de software e
ensino o Scrum pros alunos. Certo dia estava eu conduzindo a aula
normalmente quando um aluno me perguntou como que eu sabia que um
projeto ia ser entregue no prazo ou não. Ao invés de simplesmente explicar o
Burndown, resolvi mostrar na prática.

Montei grupos de 3 a 5 pessoas com os alunos e fizemos uma Sprint Planning


onde expliquei o que precisava ser desenvolvido em "dias de 30 minutos".
Cada time montou o seu Sprint Backlog, jogaram Planning Poker para
estimar o tempo de cada tarefa e depois disse para montarem o gráfico
Burndown, do mesmo jeito que vou lhe ensinar mais adiante.

Ao término do primeiro dia, disse que fizessem a reunião diária e que


atualizassem o gráfico Burndown com os pontos de tarefas que foram
concluídas no dia anterior. Após a reunião, fiz apenas uma pergunta para
cada equipe: vocês vão entregar no prazo? Eles me olharam meio confusos,
especialmente o aluno que havia me feito essa pergunta mais cedo no mesmo
dia. Então eu disse que olhassem para o Burndown atualizado e me dissessem
o que viam lá. Instantaneamente todos souberam me dizer se entregariam ou
não o projeto no prazo, como se fosse a coisa mais simples do mundo dar
essa resposta.

Esse é o poder de um gráfico objetivo e claro.


Burndown Chart
O Burndown Chart é uma ferramenta de acompanhamento do pipeline de
desenvolvimento, mas do ponto de vista de métricas, e não das tarefas em si.
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 Scrum 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, a quantidade de tarefas que deveríamos realizar todo dia para que
o projeto seja entregue no prazo.
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.
Considerações Adicionais
Como deve ter presumido, cria-se o Burndown Chart após a Sprint Planning,
com base no montante de pontos calculados no Scrum 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 capítulo anterior.

Além disso, conforme mencionado no capítulo sobre Scrum 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.

Uma sugestão seria imprimi-lo todo dia atualizado, mas além de não ser
econômico, também não é ecológico, não é mesmo?

Referências
Gestão à Vista: https://pt.wikipedia.org/wiki/Tableau_de_bord
Board de gestão à vista para quem nunca ouviu falar disso antes.

Burndown Chart: https://en.wikipedia.org/wiki/Burn_down_chart


Um pouco mais sobre o Burndown Chart, para quem não conhecia antes
desse capítulo.

Google Docs: http://docs.google.com


Suíte online de ferramentas de escritório gratuitas do Google, incluindo o
Google Sheets, concorrente do Excel que pode ser usado para gerar o
Burndown Chart de maneira virtual e online.

Análise de Pontos de Função:


https://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
Técnica mais tradicional da engenharia de software para estimar tempo de
desenvolvimento de software.
Exemplos de Burndown Chart prontos:
1. https://upload.wikimedia.org/wikipedia/commons/0/05/SampleBurndownChart.png
2. https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png
3. http://joel.inpointform.net/wp-content/uploads/2010/11/reading-burn-
down-chart2.png
4. http://www.scrumhub.com/wp-content/uploads/2014/09/burndown-
chart-formula.jpg
Todas são imagens que ilustram muito bem o como um Burndown Chart
deve se parecer. Imagens encontradas na Internet, todos os direitos estão
reservados ao seus respectivos autores.
Capítulo 11: Programação em … Pares?
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live."
- Martin Golding

Em 2011 eu havia implantado um programa de captação de talentos na


empresa em que eu trabalhava, uma empresa de hospedagem de sites.
Conseguimos dobrar a nossa equipe de desenvolvimento nos doze meses
anteriores e agora que tínhamos desenvolvedores suficientes, estávamos com
outro problema que era o de nivelar o conhecimento de todo mundo.

Quando entrava apenas um programador de cada vez era mais simples, eu


colocava ele sentado do meu lado e íamos programando em conjunto,
fazendo uma mentoria personalizada. Não ficávamos sentados em dupla o dia
inteiro, mas ocasionalmente repetíamos esse ritual até que eu (e ele)
tivéssemos confiança de que ele estava pronto para tocar os projetos de
verdade da empresa. Mas como fazer isso em uma escala maior? Entravam
programadores na nossa equipe que entendiam bem de banco, mas não de
web. Ou entendia de web mas não de orientação à objetos.

Primeiro eu precisava botar ordem na casa.

Fiz uma matriz de habilidades onde para cada desenvolvedor que havia
entrado na equipe eu listava quais habilidades ele tinha, quais ele precisava
melhorar e quais aprender. Olhando a tabela completa, foi fácil perceber que
a equipe era bem heterogênea mas que se completava. Foi fácil perceber
também que se eu tivesse de preencher essas lacunas com cada um deles
demoraria uma eternidade.

Foi aí que me lembrei do Pair Programming, que li certa vez em um artigo


sobre Extreme Programming, uma metodologia "concorrente" do Scrum.
Passei a fazer Pair Programming apenas com alguns poucos programadores
que provavelmente seriam os líderes dos times e eles por sua vez fariam Pair
Programming com os demais.
Foi uma excelente forma de multiplicar os resultados rapidamente.

Uma das práticas mais icônicas e controversas das metodologias ágeis é a de


programação em pares. Talvez as reuniões em pé sejam mais famosas, mas a
adoção da programação em pares realmente é a que mais divide opiniões. A
nossa intuição diz que colocar dois programadores para realizar a tarefa que
um deles faria sozinho é desperdício, mas isso não é verdade, e neste capítulo
vou explicar o porquê.
Pair Programming
Oriunda da metodologia ágil XP (Extreme Programming, do autor e
engenheiro de software Kent Beck, hoje coaching de programação no
Facebook), a programação em pares não é "apenas" dois programadores
sentados e enquanto um programa o outro mexe no celular. Programar em
pares requer disciplina, humildade e trabalho em equipe.

As ideias de Beck foram uma forte influência para a cultura ágil no início dos
anos 2000, tendo ele sido inclusive um dos 17 signatários originais do
Manifesto Ágil, famoso por ser a "constituição" das metodologias ágeis (do
qual falei logo no início deste livro).

Temos dois papéis aqui: o de motorista (driver no original), e o de navegador


(navigator), semelhante ao que temos em ralis, onde um dirige e o outro dá
instruções, controla a rota, etc. O motorista é o programador da rodada, ele
fica com o teclado e mouse programando o que tem de ser feito, enquanto
que o navegador (também chamado de observador/observer) dá sugestões, ele
avisa de erros e espera a sua vez de programar, afinal, de tempos em tempos,
os papéis devem se inverter.

Ambos os papéis são importantes, embora possa parecer que apenas o driver
está trabalhando, o que não é verdade. Assim como nos ralis, de onde os
termos driver e navigator vieram, é fácil para o driver perder seu rumo uma
vez que está preocupado em manter a estabilidade do carro, se manter na
trilha (quando há) e dirigir dentro das regras do campeonato ao mesmo tempo
que tenta sobreviver ao mesmo. Cabe ao navigator garantir que todo o
trabalho do driver seja orientado às metas e objetivos da corrida, que nos ralis
não é apenas chegar em primeiro, mas cumprir uma série de requisitos no
processo.

Ainda assim, existe a troca de papéis. Não existe uma regra clara de quando
devem ocorrer as trocas de papéis, e no caso do pair programming estar
sendo usado para mentoring (ver adiante), essa troca pode nem ocorrer ou ser
mais esporádica. Mas falarei disso mais pra frente.
Ok, imagino que você tenha entendido como ela funciona. A desvantagem
óbvia é o custo de desenvolvimento, não há o que falar aqui, pesquisas
indicam aumentos de 15% a 100% no custo de desenvolvimento.

Mas quais as vantagens?


Duas cabeças pensam melhor que uma
Essa expressão é bem antiga e nunca vi uma situação em que não seja
verdade.

Duas pessoas focadas em realizar uma tarefa intelectual produzem melhores


resultados que apenas uma e isso também vale para programação. Por melhor
que seja o desenvolvedor, sempre há um ponto de vista diferente que poderia
ser explorado no código, um erro que passou despercebido ou mesmo uma
forma melhor de fazer a mesma tarefa. Programadores tendem a trabalhar
sempre da mesma forma, de maneira viciada, e colocar outro programador do
lado ajuda a fazer com que eles compartilhem seus truques e modus operandi,
gerando programadores ainda melhores na sua equipe.

Mesmo quando temos dois programadores de mesmo nível, sempre há troca


de experiências e o nível de confiança é maior na solução sendo entregue,
pois o sentimento de responsabilidade também é maior. No entanto, talvez o
maior ganho do ponto de vista coletivo do time seja quando se colocam dois
programadores com experiências distintas como um veterano e um novato
(expert-novice no original) como falarei a seguir.
Mentoring de Programação
Falei de troca de experiências no tópico anterior, como uma forma de
aumentar a qualidade dos programadores da equipe. Mas e se os
programadores forem de níveis muito diferentes? Pair programming funciona
neste caso?

Aí é que funciona!

Simplesmente a melhor maneira de um programador aprendiz evoluir


rapidamente para júnior é colocá-lo para programar junto de outro mais
experiente (pleno ou sênior). Apenas mude um pouco a dinâmica: coloque o
menos experiente com a mão na massa e o mais experiente dando as
“barbadas”. Se nunca fez isso na sua empresa será uma experiência
impressionante para você.

O nome bonito disso é mentoring.

Programadores novatos tendem a perder muito tempo em coisas triviais por


falta de experiência na profissão. Todo programador veterano sabe que deve
usar e abusar do Google, e que não vale a pena tentar adivinhar como
funciona alguma coisa, que é melhor perguntar pra alguém que já saiba ou
buscar na Internet. Sites como o StackOverflow são o melhor amigo do
desenvolvedor e devem ser usados à exaustão. Geralmente os veteranos
possuem atalhos da IDE utilizada pela empresa que podem ensinar aos
novatos para aumentar sua produtividade, sem contar que com a supervisão
de um veterano, é possível dar tarefas mais interessantes aos novatos do que
ficar fazendo programinhas que nunca serão usados.

Independente se você planeja aplicar pair programming ou não na sua


empresa, você deveria testar mentoring para treinar os novatos (também
chamado de expert-novice no XP), vale a pena e está acima de qualquer
preconceito conservador que você possa ter sobre colocar duas pessoas para
realizar uma tarefa.
Peer Review
Sabe aquela música do Capital Inicial que diz assim: "O que você faz quando,
ninguém te vê fazendo?", para os programadores existe apenas uma resposta
possível: gambiarra!

Isso não quer dizer que os programadores sejam incompetentes ou de má


índole, apenas que eles são humanos. Quando não há uma vigilância
tendemos a fazer as coisas de maneira mais prática e nem sempre do melhor
jeito, inconscientemente (você leu a citação do início deste capítulo?). E aí
que entra outro aspecto da programação em pares que você pode aplicar, o
peer review, ou revisão em pares.

Se você nunca aplicou a técnica, não precisa começar hoje para ver os
benefícios. Apenas diga a um desenvolvedor da equipe que você irá revisar o
código dele mais tarde, para ver se está tudo ok. Apenas isso já será o
suficiente para aumentar a qualidade do código produzido. Falo isso por
experiência própria, pois aplico esse método com meus alunos de
programação. No momento que o profissional sabe que seu código será
revisado por outra pessoa, ele passa a se preocupar mais com o fato de que
outro terá de conseguir entendê-lo e terá vergonha de deixar alguma
gambiarra ou algo fora do padrão para trás. Se ele deixar, ou é inexperiente
ou é preguiçoso mesmo.

O peer review não é necessariamente programação em pares, como o próprio


nome sugere, mas uma revisão que um programador X faz do código feito
previamente por um programador Y, com a diferença que ele faz essa revisão
junto do programador original, geralmente com ele explicando para o outro o
que tinha na cabeça quando desenvolveu daquele jeito.

Novamente, pode parecer retrabalho e desperdício, mas os ganhos de


qualidade nas entregas são absurdos e a economia com manutenção posterior
são grandes, uma vez que menos bugs e refatorações serão necessárias. Note
que o objetivo aqui não é bancar o auditor ou botar no paredão aquele
programador que você sabe que volta e meia dá umas "deslizadas", mas sim
ajudar o time a melhorar a qualidade do produto final. Essa inclusive foi
outra dica dada no capítulo sobre Definição de Pronto, a de incluir um peer
review em todas tarefas antes de considerá-las como prontas.
Conclusões
Se você nunca tentou fazer atividades de programação em pares na sua
equipe, vale uma tentativa. Comece com algo pequeno como mentoring ou
peer review, antes de avançar com algo drástico como o pair programming
full time na sua equipe. Dê uma lida no framework XP, muitas das técnicas
ensinadas por Kent Beck fazem mais sentido quando você olha o todo, ao
invés do Pair Programming de maneira isolada, como o TDD, por exemplo.
Você vai gastar mais no desenvolvimento inicial? Sim. Mas o aumento na
qualidade pode vir bem a calhar, principalmente em épocas turbulentas
quando a qualidade do projeto não vai muito bem.

Referências
Kent Beck: https://pt.wikipedia.org/wiki/Kent_Beck
Criador da metodologia Extreme Programming (XP) e Programming Coach
no Facebook.

Extreme Programming:
https://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema
Provavelmente a segunda metodologia ágil mais famosa do mundo, perdendo
apenas para o Scrum.

Test Driven Development (TDD):


https://pt.wikipedia.org/wiki/Test_Driven_Development
O desenvolvimento orientado a testes é outra metodologia criada por Kent
Beck para aumentar a qualidade das entregas de software.

Pair Programming: https://en.wikipedia.org/wiki/Pair_programming


Para você ler um pouco mais sobre o assunto.

Peer Review: https://pt.wikipedia.org/wiki/Revis%C3%A3o_por_pares


Mais sobre a revisão em pares.

Mentoring e Coaching: http://www.ibccoaching.com.br/portal/coaching/o-


que-e-coaching-e-mentoring/
Entenda mais sobre o assunto é como é aplicado em linhas gerais,
independente da área de atuação.
Capítulo 12: Retrospectivas de Sprint que
funcionam
"Truth, like gold, is to be obtained not by its growth, but by washing away
from it all that is not gold."
- Leo Tolstoy

O Scrum é um framework ágil de gerenciamento de projetos que envolvem


produtos complexos, geralmente usado em equipes de software, embora
existam diversas adaptações para outros tipos de times.

Costuma-se dizer que o Scrum é simples de entender, mas difícil de aplicar e


embora esse paradoxo soe confuso, é exatamente isso. Em partes isso se deve
à total necessidade de se aplicar seus três pilares: transparência, inspeção e
adaptação, e em partes devido à sua simplicidade de definir poucas reuniões e
poucos artefatos, muitas vezes lhe deixando sem ideias de como facilitar
(enquanto Scrum Master) reuniões como a Retrospectiva da Sprint (Sprint
Retrospective).

Neste capítulo quero dar uma boa ideia nesse sentido, de como conduzir uma
Retrospectiva de Sprint que realmente funcione segundo os pilares do Scrum.
O que é?
A Retrospectiva da Sprint, segundo o próprio Scrum Guide, é:

“A Retrospectiva da Sprint é uma oportunidade para o Time Scrum


inspecionar a si próprio e criar um plano para melhorias a serem aplicadas
na próxima Sprint.”

Ou seja, de todas time-boxes do Scrum, certamente a Sprint Retrospective é a


mais alinhada com os pilares da Inspeção e Adaptação, pois esse é o seu
cerne. Já vi muitas equipes não realizarem as retrospectivas e portanto não
evoluírem seus processos de gerenciamento e desenvolvimento de software.
As pessoas tendem a ignorar que o maior motivo de termos tantos softwares
inúteis ou mal acabados é por falta de comunicação, seja com o cliente, com
o chefe ou entre os desenvolvedores. E a retrospectiva é justamente uma
oportunidade formal da equipe se comunicar e se aprimorar enquanto time
ágil.

Principalmente os programadores, profissionais das ciências exatas, não


gostam da ideia de "perder tempo" falando sobre os problemas do time ou
pensando em processos, quando poderiam estar programando, que é o que
gostam de fazer. Esse pensamento imaturo persistiu na minha mente durante
alguns anos no início da minha carreira até que eu percebi que o software
pelo software não adianta de nada. Que o que fazia (programar) era apenas
um meio, e não o fim. Se meu software não solucionasse o problema do
cliente, ele era apenas um monte de lixo, por mais tempo e esforço que eu
tivesse colocado em seu desenvolvimento.

Parar e refletir sobre os objetivos e sobre os processos necessários para


chegar lá é vital para a eficiência (e muitas vezes para eficácia também) do
time.
Como facilitar esta reunião?
Como todas reuniões, o Scrum Master deve ser o facilitador desta reunião de
até 3h para Sprints de um mês. Ele deve convocar o time, explicar o motivo
da reunião e apenas auxiliar o andamento da mesma e o respeito ao tempo
limite. Somente o time de desenvolvimento (segundo a ótica do Scrum, todos
que não são P.O. ou Scrum Master são desenvolvedores) que realmente
"participa" da reunião.

A dinâmica abaixo é um exemplo de como ela pode ser conduzida, uma vez
que o Scrum Guide apenas dá linhas gerais, sem um exemplo prático.

Escolha uma sala da empresa com quadro branco com canetas marcadoras
(também chamados de "caneta para quadro branco" ou "pincéis atômicos") ou
na ausência desse recurso, um mural que possa ser riscado já serve. Vamos
precisar também de post-its (se tiver 3 cores diferentes, melhor) e canetas
esferográficas comuns. Na ausência de post-its, recorte pequenos cartões do
tamanho de um cartão de visita que já resolve. Um bom número é 3
cartões/post-its por pessoa do time de desenvolvimento.

Divida o quadro/mural em três colunas: BOM, MELHORAR e AÇÕES.

Na coluna BOM devemos colocar cartões com aquilo que foi executado e
que deu certo, que a equipe deveria manter na próxima sprint como uma boa
prática.

Na coluna MELHORAR devemos colocar cartões com aquilo que foi


executado de maneira ruim e que pode melhorar na próxima sprint.

Para cada coisa que precisa melhorar, deve existir um registro na coluna
AÇÕES com uma ação concreta e factível para o mesmo. Tem que ser algo
que possa de fato ser colocado em prática, preferencialmente que alguém da
equipe se comprometa pessoalmente de que não irá acontecer na próxima
sprint.
As regras de preenchimento são: apenas um fala por vez, e somente aquele
que estiver portando um token, que geralmente é um marcador de quadro
branco ou caneta, previamente escolhida. Quando a pessoa fala (o que não
deve demorar mais de 1 minuto por pessoa) o que deseja, ela escreve em um
cartão/post-it de forma resumida e gruda no quadro/mural na coluna que tem
a ver com sua contribuição. A próxima pede o token para poder começar a
falar até que todos tenham falado ao menos uma vez.

Ao término da retrospectiva o Scrum Master coleta os dados e garante a


cobrança dos indivíduos sobre as considerações para que não tornem a
aparecer na próxima Sprint (principalmente as coisas que podem melhorar). É
comum guardar os cartões para cobrança posterior ou ao menos uma foto do
quadro completo, que permita zoom depois para ler os cartões.
Ações Concretas
Talvez o ponto mais crítico da retrospectiva seja as ações definidas para
melhorar o processo. Como Scrum Master, é seu dever garantir que os itens
que "devem melhorar" não retornem na próxima retrospectiva, caso contrário
o pilar da "adaptação" do Scrum não estará sendo aplicado e o processo, que
deveria ser vivo, ficará estagnado. Via de regra, para cada item que está na
coluna "MELHORAR" deve ter um item na coluna "AÇÕES" para resolver o
problema. E aqui que mora o problema: as ações devem ser concretas.

O que diferencia uma ação concreta de uma abstrata?


Imagine que algo que deve melhorar é a comunicação com o P.O., que
representa o cliente da equipe. Que algumas features tiveram de ter retrabalho
porque não atenderam às necessidades do cliente, sendo que trazer essas
necessidades pro time é responsabilidade do PO que não esteve presente. Isso
certamente deve melhorar para que a qualidade das entregas igualmente
melhore. Assim, para esse item que deve melhorar devemos ter uma ação
concreta para que não ocorra novamente. Certamente alguém irá sugerir
"conversar mais com o PO", mas note como isso é vago, em contraponto,
uma ação concreta seria "marcar uma reunião semanal com o PO para alinhar
a execução das features" e mais do que isso "definir que todas segundas-
feiras às 11h teremos uma reunião de 30 minutos com o PO para mostrar
como estão sendo desenvolvidas as features que estão em DOING no
Kanban". Percebe a diferença?

É difícil chegar nesse nível de ação concreta, mas é o que devemos buscar.
Cabe ao Scrum Master tensionar a reunião para que as ações tenham esse
nível de qualidade para que de fato elas sejam postas em práticas e o processo
seja melhorado. Perguntas como: "Como? Quando? Quem?" devem ser
instigadas até que a ação seja refinada neste nível de detalhe.

No entanto, um alerta: jamais defina ações, que por mais precisas que sejam e
por mais boa intenção que tenham, sejam inexequíveis, isto é, não tenham
como ser executadas. Quando uma ação é definida, o time inteiro está se
comprometendo com ela e caso a ação seja impossível de ser realizada,
haverá frustração quando os mesmos problemas voltarem a acontecer. Então
defina ações que resolvam o problema e que sejam concretas, precisas, mas
jamais inexequíveis.

Usando o mesmo exemplo anterior, do P.O. ausente, de nada adianta definir


que as reuniões ocorrerão todas as segundas às 11h se o P.O. não pode nesse
horário. Nesse caso, uma ação concreta mais facilmente executável seria
"conversar hoje, logo após esta reunião, com o P.O. para definir um dia e
horário semanal que ele possa estar presente na equipe para discutirmos o
andamento das tarefas". Mas note que ainda é uma ação precisa: hoje
falaremos com ele, hoje vamos marcar um dia e hora semanal na agenda dele
para conversar com a gente.

Referências
Boas leituras sobre o assunto:
1. https://www.scrumalliance.org/community/articles/2014/april/key-
elements-of-sprint-retrospective
2. https://www.mountaingoatsoftware.com/agile/scrum/sprint-
retrospective
3. https://msdn.microsoft.com/en-us/library/jj620912(v=vs.120).aspx
4. https://www.quora.com/Agile-Software-Development-What-is-the-
difference-between-the-Sprint-Review-and-the-Sprint-Retrospective
Capítulo 13: Aplicando métodos ágeis na sua
empresa
“You can’t have great software without a great team, and most software
teams behave like dysfunctional families.”
- Jim McCarthy

Se você está lendo esse capítulo é porque provavelmente está insatisfeito com
o processo de desenvolvimento de software da sua empresa e está ansioso por
começar uma nova abordagem. 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 capítulo 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 capítulo é empírico, baseia-se


em experiências prévias e funciona, eu garanto! ;)
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, conforme já mencionei no início deste


livro, 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 capítulo sobre o resumo do Scrum Guide pode te ajudar a entender o
básico da metodologia e complementar o guia original.

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 fui 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 você, o futuro Scrum Master do time,
assumir 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. :)

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.
Comece devagar
Muitos times possuem resistência à mudanças. Na verdade todos nós
possuímos, em maior ou menor grau. Sendo assim, uma dica para caso você
tenha de aplicar Scrum em uma equipe “difícil” de lidar é fazê-lo aos poucos.

Comece aplicando as regras de time-boxes nas reuniões. Insira a reunião


diária na rotina do time, ela é a menos dolorosa e a mais proveitosa de todas.
Vá adotando alguns artefatos como o Burndown Chart e o Kanban, para dar
mais visibilidade ao projeto e despertar o “gosto” pelo mundo agile.

Novamente, mesmo que você possua poderes plenos para fazer uma mudança
radical de processos em sua empresa ou equipe, não o faça. A menos que
estejam enfrentando uma crise muito séria e seja necessário um “chacoalhão”
para colocar tudo nos eixos e fazer todos acordarem, opte por uma mudança
em “doses homeopáticas”, se é que me entende.

O empirismo é algo muito interessante mas não garante sucesso de nada. As


experiências que originaram o framework Scrum podem ser completamente
diferentes da realidade da sua empresa, da sua equipe e você terá de ajustá-lo
para se encaixar ao seu mundo. Grandes empresas como Microsoft possuem
diferentes processos para diferentes níveis de operação, por exemplo,
simplesmente porque não dá pra adotar um mesmo processo para a empresa
inteira, para todos os setores, por exemplo. Já grandes organizações
governamentais tem outros tipos de dificuldades, como burocracias
adicionais, que impedem uma agilidade completa. ‘Dá pra fazer, só não pode
achar que é fácil, que é apenas ler um livro e mudar o mundo. Tem muito
trabalho envolvido.

No próximo capítulo vou ensinar uma dinâmica de como montar um


treinamento de Scrum para os colaboradores da sua empresa. Espero que
ajude.

Referências
Scrum.org: http://www.scrum.org
Site oficial da metodologia Scrum. Informações, treinamentos, certificações.
Tudo lá.

GlobalCode: http://www.globalcode.com.br/
Local onde fiz curso de Scrum e onde acontecem importantes eventos, como
o The Developers Conference (TDC).

Lambda3: http://www.lambda3.com.br/
Empresa do Giovanni Bassi, instrutor que me ensinou Scrum.

Certificações do Autor: https://www.scrum.org/User-Profile/userId/199179


Link onde é possível verificar a autenticidade de minhas certificações Scrum.
Capítulo 14: Ensinando Scrum aos outros
colaboradores
“The best programmers are not marginally better than merely good ones.
They are an order-of-magnitude better, measured by whatever standard:
conceptual creativity, speed, ingenuity of design, or problem-solving ability.”
- Randall E. Stross

Imagino que se você está lendo este capítulo é porque está interessado em
disseminar o conhecimento de como aplicar metodologias ágeis de
desenvolvimento de software à sua equipe, certo?

Mais do que isso, se você está querendo ensinar é porque provavelmente


entendeu o valor que isso tem para os times de desenvolvimento e está
preparado para assumir a bronca de se tornar um Scrum Master e ajudar seu
time a entregar software com mais qualidade e mais rápido do que fazendo, e
isso é ótimo.

Passei por esse mesmo período em 2010, quando tive a oportunidade de


participar da implantação de método ágeis em uma equipe de 12
desenvolvedores que se dividiam em 3 times. Mais tarde, em questão de
pouco mais de 1 ano, éramos 24 desenvolvedores em 4 times e o Scrum foi
decisivo para o sucesso que obtivemos nos produtos que criamos e para
manter uma cultura uniforme de desenvolvimento mesmo dobrando o
tamanho do time.

Espero que este capítulo possa ajudá-lo a obter o mesmo grau de sucesso ou
até mais do que tive.
Se preparando
Reserve uma manhã ou tarde inteira, no mínimo, para realizar essa prática.
Eu costumo fazê-la em uma manhã, em uma segunda-feira de preferência,
que é para que eles tenham o restante da semana para aplicar o que foi
aprendido.

Você precisará de um projetor digital ou televisor grande, uma sala que caiba
toda sua equipe (ou faça turmas), um quadro branco ou mural para colar/fixar
post-its/cartões, muitas folhas A4 (no mínimo 1 por pessoa) e tudo o que
você encontrar para rabiscar: canetas, lápis, giz de cera, etc.

Leve para o treinamento algumas cópias do Scrum Guide impresso, no


mínimo 1 cópia para cada 3-4 pessoas que irão participar. Instale algum
software de cronômetro (como o CoolTimer, veja nas referências) ou tenha o
seu celular carregado para usá-lo como cronômetro. E por fim, leve uma
gravata com nó pronto e um boné, se não tiver uma gravata, um blazer, jaleco
ou paletó já resolve.

Explicarei mais adiante.


A apresentação
Crie uma apresentação de slides ou alguma outra dinâmica qualquer que lhe
permita dar um overview do Scrum e de alguns artefatos que você pretende
utilizar na equipe para melhorar os processos de desenvolvimento.

Caso não tenha ideia alguma para a apresentação, use o meu exemplo do
Slideshare que deixei o link nas referências deste capítulo.

Estruture apenas tópicos e poucas frases na referida apresentação, isso faz


com que o palestrante tenha de ter mais domínio sobre o assunto e passe mais
confiança de que você sabe do que está falando. Em meu blog pessoal tenho
dois posts que podem te ajudar a se preparar para esse momento que cito na
seção de referências ao final deste capítulo.

A sua apresentação de slides deve abrir o treinamento e não deve demorar


mais de 1h. Peça que sua audiência leia o Scrum Guide antes de vir para o
treinamento e que tragam dúvidas e questionamentos. Use cada uma dessas
dúvidas para iniciar debates e facilitar a colaboração de todos, visando que
fique claro que somente terão sucesso se todos tentarem.

Após o treinamento, diga que farão uma prática para que eles vejam como
funcionam as reuniões, os artefatos e o até mesmo os problemas que o Scrum
não vai resolver e que eles terão de buscar soluções por conta própria.
A Prática
A prática envolve o desenvolvimento de um produto que, em teoria, não é
complexo: um flyer. Diga para que se organizem em times de 3-4 integrantes,
distribua as cópias do Scrum Guide, as folhas A4, as canetas, e guarde o
"cronômetro", a gravata e o boné para você.

Explique que iremos simular o desenvolvimento de um produto para entender


como funciona a metodologia Scrum na prática e que quando estiver de
gravata (coloque a gravata para mostrar) você estará no papel de Product
Owner e falará como sendo o cliente, autoridade sobre as prioridades do
projeto e sempre preocupado com o ROI (retorno do investimento).

Agora, quando estiver de boné (tire a gravata e coloque o boné), você estará
no papel do Scrum Master, "cobrando" do time a utilização do Scrum
corretamente e removendo os impedimentos que estejam impedindo o projeto
de prosseguir.

Sempre que algum time quiser falar com o Scrum Master ou com o Product
Owner, deverá chamá-lo adequadamente para que você coloque a gravata ou
boné e aja de acordo com sua persona.

O próximo passo é entrar em acordo com todos de quanto tempo irá demorar
a prática. Se você reservou a manhã inteira como eu mesmo faço, você terá
3h totais para o treinamento, sendo 1h para a palestra e 2h para a prática (já
fiz prática em menos de 2h, mas ficam meio corridas demais). Explique que
usará um cronômetro para contabilizar os dias e consequentemente a duração
das sprints e que devem respeitá-lo quando disser que o dia acabou e coisas
do tipo. Se você tem 2h, será possível fazer um bate papo ao final da sprint
para conversarem sobre o que acharam.

Para organizar a sprint dentro do tempo disponível, sugiro usar a seguinte


divisão:

- 10 minutos para um Sprint Planning geral, sendo 5 para a


explanação do Product Owner e 5 para o time entrar em acordo
- 40 minutos para o desenvolvimento do produto, em 4 dias de 10
minutos
- 5 minutos para o Sprint Review de cada time
- 5 minutos para um Sprint Retrospective geral

A prática começa com os primeiros 10 minutos de Sprint Planning, que nesse


caso serão facilitados pelo Product Owner (você de gravata).

Será feito apenas uma Sprint Planning geral, com todos os times escutando e
fazendo perguntas. Você deve explicar que deseja aplicar o Scrum na sua
empresa, que já tem profissionais preparados para isso e que está na fase de
começar a disseminar esse conhecimento e interesse no framework por toda
organização (conforme comentei no post anterior). Para isso vai contratar
uma equipe de artistas gráficos para criar um panfleto bacana com um
resumão do Scrum Guide que caiba em uma folha A4.

Ou seja, a prática envolve aplicar os conhecimentos sobre Scrum que foram


aprendidos no Scrum Guide e na palestra em um material escrito ao mesmo
tempo em que terão de seguir o processo Scrum.

Dê tantos detalhes quanto julgar necessários, mas tente deixar com que os
participantes lhe questionem os detalhes mais importantes, como o formato
do panfleto, se será em cores, se é frente e verso, se eles têm de entregar a
versão final, se é apenas esboço, etc.

Uma das lições desse treinamento é sempre que o time tem de se comunicar
com o Product Owner para que a "magia" aconteça. Então se eles não
perceberem a necessidade de fazer as perguntas certas, o fracasso logo
adiante vai ensinar isso a eles. Pense no produto final que deseja e anote, mas
não diga pra eles como será, deixe que eles tenham de interagir com você
para descobrir.

Não tome mais do que 5 minutos nessa explanação inicial e diga que eles
devem deliberar sobre a viabilidade do projeto, planejar as atividades do
mesmo e com o que se comprometem a entregar. Dê a eles 5 minutos para
conversarem entre si (somente os membros do mesmo time) e conforme
forem terminando, diga para chamarem o Product Owner com o resultado do
seu planejamento. Lhes responda as últimas perguntas e anote o que cada
time se comprometeu a entregar, isso é muito importante, pois você cobrará
essa entrega mais tarde.

Geralmente o excesso de confiança faz com que digam que irão entregar
tudo, mesmo sem terem muita ideia de como irão dividir as tarefas e
executarão o trabalho.

A cada dia de 10 minutos que se passar os integrantes do time terão que


realizar uma Reunião Diária (Daily Scrum) de no máximo 2 minutos. O
Scrum Master, enquanto facilitador do processo deve avisar a todos quando o
dia "virar" e cobrar que todos estejam fazendo a reunião diária dentro do
prazo estipulado e sendo bem objetivos. Você pode inclusive sempre terminar
a reunião diária com a pergunta clássica, de equipe em equipe: "Vamos
conseguir entregar time? Alguém tem algum impedimento para que eu
resolva?". Deixe em aberto a possibilidade de chamarem o Product Owner
(coloque a gravata quando isso acontecer) ou o Scrum Master (boné) quando
quiserem tirar dúvidas do produto (P.O.) ou do processo (SM).

É comum que os times percam muito tempo nos primeiros um ou dois dias e
comecem a correr depois da metade da sprint, quando estiverem faltando
apenas uns 20 minutos (2 dias hipotéticos).

Caso algum time tente negociar prazos com o Product Owner não aceite, mas
com muita relutância permita alterações no tamanho do escopo, mas sem
exageros. A tendência é de falha nessa primeira tentativa, mas não os avise
disso, esse é o principal insumo para a retrospectiva que é feita ao término da
sprint.

Quando os 4 dias de 10 minutos terminem (o CoolTimer adiciona um efeito


dramático à isso pois você pode escolher um MP3 bem barulhento para
quando isso acontecer), diga a todos para pararem o que estão fazendo e que
será feito agora a Sprint Review, onde os times apresentarão suas criações
para o Product Owner (coloque a gravata) avaliar.
Faça com que o time se levante e esteja visível para os demais times quando
estiver demonstrando seu panfleto. A dinâmica exata dessa apresentação
depende do seu sadismo, você pode interromper a apresentação conforme ela
for sendo realizada para tecer comentários sobre o que faltou ou o que não
gostou, por exemplo, bancando o cliente ruim. Ou então dizer o que achou do
produto pronto ao término da apresentação, que não deve durar mais que 5
minutos por equipe.

O ponto que não deve ser esquecido aqui é comparar a entrega da equipe com
o que ela havia prometido. No Scrum, o time define o tempo que irá levar
para desenvolver as tarefas, e portanto, deve ser cobrado se não entregar o
que o próprio time havia prometido.

Ao término das reviews, e consequentes frustrações de quem não entregou o


que o cliente esperava, é hora da retrospectiva. Eu não vou falar aqui em
detalhes dessa dinâmica porque já fiz isso em um capítulo anterior deste
livro, que falo somente de como conduzir retrospectivas de sprint que
realmente funcionam.

Em linhas gerais, aqui é onde o time (e somente o time, apenas com a


mediação do Scrum Master) vai expor o que considerou que fluiu legal no
desenvolvimento deste produto (deixe que eles falem), o que não fluiu tão
bem assim e as ações que o time se compromete a executar na próxima sprint
para que os mesmos erros não voltem a acontecer. Esse é o momento de
maior aprendizado e toda prática. Como todo bom erro, é na falha em que
mais aprendemos e geralmente os times falham nessa prática.
Feedbacks finais
Ao fim, depois que todos colaboraram, dê a sua opinião. Isso é extra-oficial,
não faz parte do Scrum, mas sim do treinamento. Explique o propósito disso
tudo novamente, dê a sua opinião do que foi bom, do que pode melhorar,
incentive o time a aplicar as melhorias sugeridas logo na próxima sprint de
verdade que irão fazer com um produto de verdade que será desenvolvido.
Aproveite esse momento de emoção e empolgação como um impulso para
definitivamente colocar em prática essa metodologia (por isso que disse que
tinha de ser numa segunda-feira).

Tive a oportunidade de aplicar este mesmo treinamento em meia-dúzia de


empresas da Grande Porto Alegre sempre com um excelente grau de sucesso.
Espero que você consiga usá-lo ou adapte-o às suas necessidades, mas que
tenha sucesso também em melhorar os processos da sua empresa.

Referências
Cool Timer: http://www.baixaki.com.br/download/cool-timer.htm
Software de cronômetro personalizável e muito bacana para quebrar o gelo.

Slides sobre Scrum: http://pt.slideshare.net/luizfduartejr/treinamento-de-


scrum
Apresentação que uso em treinamentos de Scrum em empresas de software.
Use diretamente ou inspire-se neles para criar o seu treinamento.

Como criar boas palestras: 1.http://www.luiztools.com.br/post/dicas-para-


criar-boas-palestras-parte-1-os-slides/
2.http://www.luiztools.com.br/post/dicas-para-criar-boas-palestras-parte-2-
apresentacao/
Série de dois posts publicados há vários anos em meu blog e que podem
auxiliá-lo a criar suas apresentações e se portar como orador.

Scrum Guide: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-


Guide-Portuguese-BR.pdf
Guia oficial do Scrum em diversos idiomas. Imprescindível ter algumas
cópias impressas para o treinamento.
Capítulo 15: Contratando profissionais ágeis
“Never hire someone who knows less than you do about what he’s hired to
do.”
- Malcolm Forbes

Desde que conheci Scrum em 2010, vejo um grande movimento no mercado


de desenvolvimento de software em torno da adoção de metodologias ágeis e
cada vez mais a procura por profissionais com o mesmo mindset e até mesmo
experiência com Scrum e cia. Vagas para Scrum Master, principalmente, mas
para outros papéis do Scrum, têm aparecido em sites de empregos com cada
vez mais frequência, embora o próprio framework diga que Product Owner,
Scrum Master e o Developer Team são papéis e não cargos.

Mas aí surge uma dúvida: como descobrir se a pessoa que estou entrevistando
tem perfil ágil para trabalhar em meu time?

Claro, dependendo de qual papel ela irá assumir no time, existem diferentes
características desejáveis, como a lista abaixo demonstra:

Product Owner: expert em Scrum, domínio de conhecimento do negócio,


habilidade de comunicação excelente, habilidade para lidar com incertezas,
habilidades de negociação, acessível, proativo, decisivo, pragmático e com
foco nos objetivos.

Scrum Master: expert em Scrum, líder-servidor, moderador, resolve


problemas, acessível, motivador, perceptivo, mentor, habilidades de
coordenação e introspectivo.

Time Scrum: conhecimento em Scrum, colaborativo, auto-organizado,


altamente motivado, proativo, especialistas técnicos, perspectiva
multifuncional, trabalha em times, independente, responsável, intuitivo, foco
nos objetivos e introspectivo.

E, para ajudar a identificar candidatos que possuam o potencial ágil que você
busca, as perguntas abaixo podem ser realizadas durante a entrevista. Note
que a maioria delas não possui uma única resposta correta, mas todas ajudam
a entender como o candidato raciocina sobre agilidade.

#1 - Em primeiro lugar, qual o propósito de ser ágil?

A resposta mais comum aqui, e a mais errada também, é: entregar os projetos


mais rápido. Pessoas leigas no assunto tendem a confundir agilidade com
velocidade. Ser ágil não é programar mais em menos tempo, isso é ser
eficiente e seria ótimo se fossem sinônimos. Ser ágil é realizar entregas de
maneira mais frequente (em partes pequenas) e com mais qualidade.

#2 - Como você caracterizaria o seu papel como __________?

A lacuna que deixei na pergunta é para você colocar o papel que o candidato
irá assumir: Scrum Master, Product Owner ou Team Dev. Você pode
emendar outras perguntas na sequência, dependendo do papel, como segue
(retirado do livro SBOK):

Scrum Master: qual a diferença entre um Scrum Master e um gerente de


projetos tradicional? Como seria um dia típico nessa função?

Product Owner: qual a diferença entre um PO e um gerente de produtos


tradicional? Como você gerencia seu product backlog?

Dev Team: qual a diferença entre um dev Scrum e um “dev normal"? À quem
você deve reportar suas atividades?

Nestas perguntas, a ideia é ver se o candidato realmente sabe do que se trata o


papel ao qual ele está se candidatando. Essa pergunta é mais importante para
o Scrum Master e o PO, mas entender o quão auto-gerenciável é um Dev no
momento da contratação também pode ser muito útil.

#3 - Quando foi a última vez que você disse 'não' para outro membro de
equipe? Como você lidou com a situação? Qual a razão disso?
Novamente uma pergunta importantíssima para entender se os candidatos a
PO e Scrum Master possuem as virtudes necessárias para esses papéis, como
foco e disciplina. Dizer 'não' é importantíssimo dentro de times Scrum para
garantir que os objetivos serão atingidos.

#4 - Como o seu papel se relaciona com os demais do time Scrum?

Essa é mais uma pergunta para entender se o candidato tem o perfil


colaborativo necessário para que um time Scrum funcione, bem como se ele
domina o Scrum em sua plenitude, não apenas o seu 'quadrado'.

#5 - Sua organização recentemente decidiu implantar o uso de


metodologias ágeis no desenvolvimento de produtos. Que implicações
isso pode trazer aos stakeholders?

Essa pergunta é decisiva para a contratação de um Scrum Master. Toda


implantação de métodos ágeis implica em mudança cultural na empresa e,
principalmente, afeta a forma como os stakeholders interagem com o time de
desenvolvimento de produto, o que nem sempre é visto com 'bons olhos'.
Como Scrum Masters são responsáveis pela implantação do Scrum nas
empresas, é dever deles saber do impacto que isso causa.

#6 - Como você organiza/gerencia a colaboração entre o time e os


stakeholders?

Colaboração é a chave para o sucesso dos projetos, seja entre os membros do


time entre si e os membros do time com os stakeholders. Lembra da pergunta
#3? Essa tem um pouco a ver também.

#7 - Uma nova feature atrasou drasticamente devido a um débito técnico.


Os stakeholders querem-na entregue mesmo assim, devido à quantia que
já foi investida. Como você lida com isso?

Essa é a clássica pergunta sem resposta, mas que mostrará o raciocínio do


candidato em situações complicadas como essa. Deve ele abrir mão da
qualidade em prol do prazo? Deve dizer não aos stakeholders em prol da
qualidade? O que o Scrum diz sobre isso?

#8 - O departamento de vendas têm vendido novas features sem falar


com seu time, responsável pelo produto, primeiro. Como você lida com
isso?

E nesse caso? O time de vendas "serve" ao time de produto, o contrário ou


nenhum dos dois? Quem está certo e quem está errado? Perguntas
complicadas, que o candidato não espera ter de responder, são as melhores
para mostrar quem realmente ele é e como encara questões como trabalho em
equipe, agile, etc.

#9 - Como é sua abordagem para lidar com roadmaps de produtos?

Uma questão muito boa para Product Owners e Scrum Masters, mas que pode
ser usada também em devs, embora com propósito diferente. Tente descobrir
que ferramentas o candidato já usou, como é um dia típico dele em relação ao
roadmap de produto.

#10 - Como você refina a si mesmo e o seu papel dentro do time?

Os 3 pilares do Scrum são transparência, inspeção e adaptação e não


podemos esperar menos do que isso em um candidato. Como que o candidato
inspeciona seu desempenho e adapta-se visando melhoria contínua?

#11 - Como você lida com bugs + débito técnico vs novas features no dia-
a-dia?

Outra pergunta essencial para Scrum Masters e POs, que geralmente lidam no
dia-a-dia com esse conflito de aperfeiçoar o que já existe vs criar coisas
novas. Como que o candidato 'descobre' o que é realmente mais importante
nesse momento para a empresa?

Referências
SBOK - Scrum Body of the Knowledge:
http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
Um guia de implantação do Scrum escrito pela Scrum Study. Um tanto denso
(lembra o PMBOK), mas interessante mesmo assim.
Capítulo 16: Princípios acima de processos
“First learn computer science and all the theory. Next develop a
programming style. Then forget all that and just hack.”
- George Carrette

Trabalho com métodos ágeis desde 2010. De lá pra cá, nestes 7 anos de
estrada, vejo muitas equipes falharem na adoção do framework, seja pela
disciplina inerentemente necessária à essa tarefa, seja pela displicência das
equipes em realmente "fazer acontecer".

Sinceramente não acredito que o "Scrum flácido" seja o principal causador


dessas falhas, mas sim uma "mentalidade flácida". Não são raros os times que
acham que colocar o Scrum Guide embaixo do braço vai resolver todos os
seus problemas de entregas fora do prazo, escopo indefinido, falta de
comprometimento e muito mais.

Muito mais do que decorar as regras do Scrum, neste capítulo sugiro que
você se foque em entender os princípios mais importantes por trás dessa
famosa metodologia. O Scrum não funciona apenas por ter reuniões de 15
minutos em pé todos os dias. Ele funciona por causa dos princípios por trás
de cada um dos seus eventos, papéis e, porque não dizer, "excentricidades".
Princípio 1: Empirismo
Você sabe o que é algo 'empírico'?

É algo advindo do conhecimento prático, o oposto de algo que só funciona na


teoria, entende?

Scrum é um framework empírico, criado com base em décadas de experiência


dos seus fundadores à frente de projetos de software e essa é a filosofia
central dele. Não apenas você deve acreditar nos anos de experiência dos srs.
Ken Schwaber e Jeff Sutherland como Scrum enfatiza que você aprenda com
a sua experiência ao longo das sprints. Que você se baseie no empirismo da
sua própria trajetória para, no mínimo, não cometer os mesmos erros.

Transparência, inspeção e adaptação, os três pilares do Scrum que falamos no


início desse livro, lembra?.

Após rodar algumas sprints (da maneira correta, fazendo reviews e


retrospectivas, conforme dita o Scrum Guide e frisei ao longo do livro), você
começará a gerar o seu próprio conhecimento empírico, realimentado o
framework e aumentado a qualidade dos seus processos.
Princípio 2: Auto-organização
Esse aqui talvez seja o ponto mais falho, uma vez que nem todo mundo tem a
disciplina de se auto-organizar. O fato é que as pessoas entregam
significativamente um maior valor quando são auto-organizadas e isto resulta
em times mais satisfeitos e responsabilidade compartilhada; e em um
ambiente inovador e criativo que é mais propício ao crescimento.

Lembra da fábula da "galinha e o porco"? É uma história bem velha, mas


sempre atual.

A galinha queria abrir um restaurante com o porco, sugerindo o nome "Ovos


com Presunto". No entanto o porco recusou. Isso porque ele estaria
comprometido, enquanto a galinha estaria meramente envolvida.

Eu não vou explicar aqui o que isso quer dizer, imagino que você tenha
entendido que não quer “galinhas” no seu time, mas sim “porcos”.

Auto-organização requer um comprometimento altíssimo com os demais


membros do time e com a empresa. É um princípio fundamental não apenas
para o Scrum, mas para a vida da gente.
Princípio 3: Colaboração
Esse princípio concentra-se nas três dimensões básicas relacionadas com o
trabalho colaborativo: consciência, articulação e apropriação. Também
defende o gerenciamento de projetos como um processo de criação de valor
compartilhado, com times trabalhando e interagindo em conjunto para
atingirem melhores resultados.

No livro As 17 Incontestáveis Leis do Trabalho em Equipe, de John


Maxwell, a primeira lei é a Lei do Monte Everest. Ninguém jamais conseguiu
subir o monte Everest sozinho. Sabe por quê? Porque quanto maior o
objetivo, maior a necessidade de se trabalhar em equipe, de maneira
colaborativa.

Quando o time é competitivo e/ou quando os membros são egoístas, o


objetivo do grupo não é alcançado, e muitas vezes os pessoais também não.

Scrum prega a colaboração, não apenas interna (dentro do time), quanto


externa (com o cliente). Um dos pontos-chave do Manifesto Ágil inclusive
cita que a colaboração com o cliente deve ser mais importante do que ficar
renegociando contratos.
Princípio 4: Priorização Baseada em Valor
Esse princípio destaca o foco do Scrum em entregar o máximo de valor de
negócio possível, durante todo o projeto.

Quando falamos que Scrum é um framework para desenvolvimento de


produtos complexos, que seu cerne é entregar valor de maneira frequente e
com qualidade, não estamos falando necessariamente de software. Esse é
apenas o uso mais comum do framework.

Entregar valor é atender a demanda do seu mercado. É resolver o problema


do seu cliente.

Não tem nada a ver com fazer over-engineering ou escovar bits. Lembra-se
do Manifesto Ágil que citei anteriormente? Software funcionando é mais
importante do que documentação abrangente. Está lá, e eu diria mais: cliente
satisfeito é mais importante que usar a linguagem de programação da moda.
Que valor é mais importante que tecnologia.

Priorizar features porque elas são sexies ou ficar trocando de tecnologia toda
hora apenas para mostrar o quão cool você é jamais devem ser as prioridades.
No fim do dia, o sucesso de um projeto é definido pela felicidade do seu
cliente e/ou usuários.

E quem está já há algum tempo neste mercado sabe que cliente feliz é a chave
para o seu sucesso.
Princípio 5: Time-boxing
O tempo é considerado uma restrição limitada em Scrum, e que ele deve ser
usado para ajudar a gerenciar o planejamento e execução do projeto com
eficácia. Os elementos Time-boxed em Scrum incluem os Sprints, as
Reuniões Diárias, a Reunião de Planejamento da Sprint, e a Reunião de
Revisão da Sprint. Já falei de tudo isso aqui no livro e, se ainda não ficou
claro, sugiro ler os referidos capítulos novamente.

Na verdade não só no Scrum, mas o conceito de time-boxing deve ser levado


para toda a vida, se você deseja ser mais produtivo.

O princípio de eventos com prazo e duração limitados norteia-nos para que os


objetivos sejam atingidos de maneira eficaz e eficiente.

É duro dizer a um colega do time que ele estourou o tempo que tinha para
falar na reunião diária. Mas tenha a certeza que da próxima vez ele será mais
objetivo, se quiser ser ouvido por completo.

É triste muitas vezes o time falhar na entrega porque faltava "apenas" mais
um dia para terminarem as features. Mas tenha a certeza que na próxima
sprint eles aprenderão com esse erro e estimarão melhor as tarefas. Ou se
descuidarão menos com distrações e imprevistos.

Jamais falhe com as time-boxes, pois essa é uma estrada que leva rumo ao
fracasso no gerenciamento ágil de projetos. Estender sprints gera precedentes.
Esticar reuniões gera passivos. “Flexibilize” as time-boxes e você estará
enfraquecendo o processo como um todo.

Afinal, se eu não tenho um prazo, posso sempre deixar pra fazer depois...
Princípio 6: Iterativo-Incremental
Muita gente confunde iterativo com interativo. E não é um typo, existe um 'n'
a mais na segunda palavra e uma grande diferença entre as duas.

Iteração é uma execução de um laço, uma repetição. Um desenvolvimento


iterativo-incremental é aquele cujas etapas se repetem indefinidamente, e a
cada iteração, um novo incremento do produto é entregue pronto.

Isso é o símbolo do Scrum. Inclusive está na capa deste livro, lembra?

Mesmo que não use Scrum, desenvolver produtos de maneira iterativa-


incremental é sempre uma boa ideia. Iterações e colaboração com o cliente
garantem uma entrega alinhada com a percepção de valor do cliente, o que
por sua vez gera uma maior qualidade no projeto como um todo.

Mesmo que não use Scrum, aplicar estes princípios em seus projetos não faz
mal à ninguém, muito pelo contrário, faz muito bem.

Quando ensino programação aos mais jovens (nossa, soa muito velho dizer
isso!), sempre reforço o que chamamos de baby steps, ou passos de bebê.
Programe um pouco, teste aquele pouquinho. Nunca dê “um passo maior que
a perna” ou vai ser difícil consertar se estiver errado.

O mesmo vale para projetos de qualquer tipo. Aja de maneira iterativa e


incremental.

Referências
As 17 Incontestáveis Leis do Trabalho em Equipe:
http://www.luiztools.com.br/post/as-17-incontestaveis-leis-do-trabalho-em-
equipe-resenha/
Excelente livro de John Maxwell sobre liderança e trabalho em equipe.

Fábula da galinha e do porco:


https://www.implementingscrum.com/images/060911-scrumtoon.jpg
Muito mais profunda do que aparenta e sempre atual.

Manifesto Ágil: https://www.manifestoagil.com.br/


Os princípios originais que deram luz às metodologias ágeis como Scrum,
XP, Crystal, etc
Capítulo Final: Seguindo em frente
“There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies.”
- C.A.R. Hoare

Sinceramente espero que você não tenha chegado até aqui lendo do início ao
fim. Não me entenda mal, eu quero que você leia este livro todo algum dia,
mas não espero que o leia de uma vez só, não sem ter tempo de aplicar as
ideias aqui descritas.

Comece pequeno, com um projeto mais simples e uma equipe enxuta. Siga o
Scrum tal qual manda no Scrum Guide e depois vá adicionando os artefatos e
técnicas descritas neste livro conforme a necessidade for surgindo e a
confiança for crescendo. Não se afobe e não dê um passo maior que a perna,
principalmente se você não for o "chefe" e estiver conquistando credibilidade
com a aplicação de métodos ágeis na equipe ou no setor de desenvolvimento.

O livro acabou, e agora?

Comecei esse livro pedindo que lesse o Scrum Guide e o Manifesto Ágil, os
dois documentos mais elementares para quem quer ingressar nesse universo.
Termino este livro recomendando outras leituras igualmente interessantes nas
referências abaixo. Mesmo os livros que talvez você considere como
repetidos sempre trazem alguma coisa nova, um novo olhar, uma nova
abordagem, para o que você já vem fazendo no dia-a-dia que é criar software.

Como este livro, aliás!

Se chegou até aqui após ter aplicado Scrum com sucesso, mesmo que
moderado, meus parabéns. Adoraria conversar com você, trocar ideias e estou
à disposição em meu blog http://www.luiztools.com.br, em minha página no
Facebook http://fb.com/luiztools e em minha do Twitter
http://twitter.com/luiztools para ajudar no que eu puder. Conheça meus outros
livros na seção Meus Livros do blog, de repente tem mais algum que te
interesse por lá. ;)

Um abraço e boa sorte!

Conheça meus outros livros:

Programação Web com Node.js


Criando apps para empresas com Android
MongoDB para Iniciantes
Java para Iniciantes
Criando aplicações móveis com Corona

Referências
Scrum: A arte de fazer o dobro de trabalho na metade do tempo
https://www.amazon.com.br/gp/B00OEI3TKM
Excelente livro de Jeff Sutherland, um dos criadores do Scrum, não ajuda
muito a implementar o Scrum, mas a entender sua essência e conhecer
diversos cases.

Implementando o desenvolvimento Lean de software: Do Conceito ao


Dinheiro
https://www.amazon.com.br/gp/8577807568/
Outro excelente livro, desta vez da Mary Poppendieck, engenheira com
algumas décadas de desenvolvimento nas costas, que fala muito bem sobre
Lean Development, outra técnica adaptada da indústria para o mercado de
software, assim como o Kanban.

Programação Extrema (XP) Aplicada: Acolha as Mudanças


https://www.amazon.com.br/gp//B0187IKY34/
E por fim, a obra-prima de Kent Beck, um dos signatários originais do
manifesto ágil e criador do TDD e XP. Apesar de ser uma metodologia
"concorrente", há conceitos muito valiosos no XP que cobrem "furos" do
Scrum.
Glossário
Um pequeno glossário de termos oriundos do nosso universo ágil, em ordem
alfabética.

Agile
Termo usado comumente para designar as metodologias (ou métodos) ágeis
de se desenvolver software, em oposição aos métodos tradicionais, formais e
burocráticos.

Agile Coach
Profissional responsável pela disseminação e melhoria contínua de processos
ágeis dentro de uma organização. Dependendo da empresa ele pode ser um
Scrum Master mais focado na estratégia do processo em alto nível, enquanto
que sua contraparte é mais operacional. Em outras empresas pode ser apenas
um Scrum Master "desvinculado" de um processo ágil específico (o Scrum),
também referido algumas vezes como Agile Master.

Agile Master
Ver Agile Coach.

Aliança
Ver Alliance.

Alliance
Nome dado a junção lógica, temporária ou permanente, de várias Tribes pela
necessidade de uma grande entrega ou pela sinergia entre as mesmas. Algo
como uma versão ágil de superintendências tradicionais. Popularizado pela
empresa sueca Spotify.

Artefato
Nome dado às técnicas e recursos físicos usados como apoio ao processos
ágeis.

Backlog de Produto
Lista de tarefas e recursos a serem desenvolvidos em um software.

Backlog de Release
O mesmo que que Backlog de Produto, mas sendo um subconjunto de tarefas
e recursos que devem ser realizados para cumprir o projeto de uma nova
release do produto.

Backlog de Sprint
O mesmo que o Backlog de Produto, mas sendo um subconjunto de tarefas e
recursos que devem ser realizados na sprint atual.

Burndown Chart
Gráfico que mostra a relação entre tarefas a serem realizadas e tempo
disponível para realização das mesmas dentro de uma iteração, dando uma
previsão se o prazo será cumprido ou não. Ver capítulo 6 para mais detalhes.

Buy a Feature Game


Técnica colaborativa de priorização de roadmap onde os participantes usam
dinheiro falso limitado para comprar as features. As features que receberem
mais dinheiro são as mais prioritárias.

Chapter
Dentro de uma Tribe (ver Tribe), transversalmente às Squads (ver Squad), os
profissionais de mesma skill reúnem-se em chapters. Por exemplo, todos os
programadores Java das Squads de uma Tribe formam o Chapter Java.
Popularizado pela empresa sueca Spotify.

Chapter Leader
O líder técnico de um chapter, a referência na tecnologia do chapter. Ver
Chapter.

Comunidade
Ver Guild.
Condição-Alvo
Dentro do Improvement Kata da Toyota, uma condição-alvo é o próximo
passo de curto prazo a ser alcançado rumo a uma visão de longo prazo.

Daily Meeting
Reunião diária de 15 minutos para alinhamento do time, onde todos ficam
sabendo o que cada um fez no dia anterior, o que fará hoje e se há algum
impedimento a ser resolvido.

Daily Scrum
Outro nome para o Daily Meeting.

Definição de Preparado
Artefato Ágil para criar um conceito comum do que READY significa entre
todos os membros do Time Scrum. Um item de backlog somente pode ser
posto para TODO por um desenvolvedor se ele passar na Definição de
Preparado.

Definição de Pronto
Artefato ágil para criar um conceito comum do que DONE significa entre
todos os membros do Time Scrum. Um item de backlog somente pode ser
posto em DONE por um desenvolvedor se ele passar na Definição de
Preparado.

Definition of Done
Ver Definição de Pronto.

Definition of Ready
Ver Definição de Preparado.

Desenvolvedor
Dentro do framework Scrum é qualquer profissional que pertença ao time e
que não seja o Scrum Master ou o Product Owner. Isso inclui designers,
testers, programadores, etc.
Desenvolvimento Orientado à Testes
Ver Test Driven Development.

Extreme Programming
Metodologia ágil muito utilizada no mundo, talvez apenas não mais do que o
Scrum.

Futurespective
Técnica usada para alinhar o roadmap de um produto entre o time e até
mesmo os stakeholders, onde colaborativamente constrói-se o roadmap
baseado no entendimento pessoal e coletivo dos participantes do que é o mais
importante.

Grooming
Nome popular da cerimônia de Refinamento do Product Backlog, onde P.O. e
Time de Desenvolvimento discutem e esclarecem os itens do Product
Backlog antes da próxima Sprint Planning.

Guia do Scrum
O guia oficial da metodologia Scrum, disponível gratuitamente na Internet
pelos seus criadores. Ver capítulo 2 para mais detalhes.

Guild
Nome dado a comunidades ágeis que possuam um interesse comum dentro de
uma empresa, transversalmente às Tribes (ver Tribe). Por exemplo, todos os
profissionais de programação da empresa, independente da tribe, podem
formar uma guild de Programação Segura. Popularizado pela empresa sueca
Spotify.

Head
O líder de uma Alliance.

Improvement Kata
Técnica de melhoria contínua da Toyota para a busca de uma visão através da
decomposição da mesma em condições-alvo menores e mais facilmente
atingíveis.
Iteração
Um ciclo fechado de desenvolvimento de software de curta duração, onde um
conjunto limitado de tarefas serão realizadas e que resultarão em um
incremento no produto final.
Ver também: Sprint.

Jeff Sutherland
Co-criador do Scrum.

Kanban
Um artefato “roubado” da indústria tradicional, sendo um quadro com cartões
que sinalizam o andamento das tarefas ao longo do pipeline de
desenvolvimento de uma iteração. Ver capítulo 5 para mais detalhes.

Kata de Melhoria
Ver Improvement Kata.

Ken Schwaber
Co-criador do Scrum.

Kent Beck
Criador do Extreme Programming (XP) e do Test Driven Development
(TDD).

Manifesto Ágil
Documento assinado por grandes nomes da engenharia de software mundial
se comprometendo a melhorar os métodos pelos quais os softwares estavam
sendo desenvolvidos até então, tornando os processos mais ágeis e menos
burocráticos. Ver capítulo 1 para mais detalhes.

Matriz Risco x Valor


Técnica ágil usada para priorizar roadmap e backlog usando um plano
cartesiado de risco e valor dividido em quatro quadrantes, onde pode-se
tomar decisões baseadas em diferentes estratégias.
Minimum Viable Product
Ver Produto Mínimo Viável.

MVP
Ver Produto Mínimo Viável.

Next Target Condition


Ver Condição-Alvo.

Pair Programming
Técnica ágil onde um programador mais experiente senta junto de um menos
experiente para juntos realizarem uma tarefa do projeto de maneira mais
eficiente. Ver capítulo 7 para mais detalhes.

Peer Review
Técnica ágil onde um programador testar o software desenvolvido por outro
programador, para garantir mais qualidade na entrega. Ver capítulo 7 para
mais detalhes.

Planejamento da Sprint
Reunião onde define-se o escopo de tarefas da próxima Sprint e estima-se o
tempo de desenvolvimento das mesmas.

Planning Poker
Artefato ágil utilizado para estimar tempo de desenvolvimento de software
usando cartas de baralho em uma sequência de Fibonacci. Ver capítulo 3 para
mais detalhes.

P.O.
Ver Product Owner.

Pontos de Caso de Uso


Artefato mais tradicional para estimar tempo de desenvolvimento de software
usando pontos atribuídos à casos de uso conforme sua complexidade, mão de
obra disponível, experiência prévia, etc.
Pontos de Função
O mesmo que Pontos de Caso de Uso mas sendo uma estimativa mais
granular, a nível de métodos e funções de código.

Product Backlog
O mesmo que Backlog de Produto.

Product Owner
Papel dentro de um Time Scrum semelhante ao tradicional Gerente de
Produto, responsável pela visão do produto, gerenciamento do Product
Backlog e retorno sobre o investimento (ROI).

Produto Mínimo Viável


Protótipo do produto final com o mínimo de funcionalidades para validar
interesse do mercado, precificação e funcionalidades importantes.

Programação em Pares
Ver Pair Programming.

Release Backlog
Ver Backlog da Release.

Retrospectiva da Sprint
Reunião final de uma Sprint onde inspeciona-se os processos utilizados na
última sprint e adapta-os visando melhoria contínua. Ver capítulo 7 para mais
detalhes.

Reunião Diária
Ver Daily Meeting.

Revisão da Sprint
Penúltima reunião de uma sprint onde o time apresenta os resultados obtidos
durante a última sprint para os envolvidos no projeto.

Scrum
Método ágil mais usado no mundo para construção de produtos de software
complexos. É um framework iterativo incremental. Ver capítulo 2 para mais
detalhes.

Scrum Guide
Ver Guia do Scrum.

Scrum Master
Papel dentro de um Time Scrum semelhante ao de um Gerente de Projeto
tradicional, mas mais alinhado com o perfil de líder-servidor, sendo suas
principais funções garantir que os processos sejam seguidos e que o time
avance rumo às metas sem impedimentos.

Scrum Poker
Ver Planning Poker

Sprint
É uma iteração, um ciclo dentro do processo do Scrum com geralmente 30
dias onde constrói-se um incremento de software pronto e entregável. Ver
também: iteração.

Sprint Backlog
Ver Backlog da Sprint.

Sprint Planning
Ver planejamento da Sprint.

Sprint Retrospective
Ver Retrospectiva da Sprint.

Sprint Review
Ver Revisão da Sprint.

Squad
Nome popular dado a times ágeis multidisciplinares, não necessariamente
adotando Scrum. Popularizado pela empresa sueca Spotify.
TDD
Ver Test Driven Development.

Team Leader
O mesmo que Tribe Leader.

Test Driven Development


Metodologia de desenvolvimento de software criada por Kent Beck cujo foco
é construir soluções partindo dos testes necessários, para depois codificar o
funcionamento dos mesmos.

Time de Desenvolvimento
Todos membros de um Time Scrum que não são Product Owner ou Scrum
Master fazem parte do Time de Desenvolvimento. Ver também:
Desenvolvedor.

Time Scrum
O Time Scrum é formado por todas as pessoas necessárias para criar o
incremento de software desejado pelo cliente, tendo um Product Owner, um
Scrum Master e tantos Desenvolvedores quanto necessário.

Time-box
Um evento de duração fechada e que faz parte dos processos do Scrum.

Tribe
Nome dado a um conjunto de squads (ver Squad) que possuam uma proposta
de valor em comum, que atuem em produtos/sistemas separados, mas para
uma mesma frente da empresa. Popularizado pela empresa sueca Spotify.

Tribe Leader
O gestor ágil de uma tribo. Responsável pela gestão de recursos, alinhamento
estratégico com a empresa, formação das squads, etc. Ver Tribe.

Tribo
Ver Tribe.
XP
Ver Extreme Programming.