Boas-vindas

A Gestão Ágil de Projetos invadiu o mundo dos negócios nas duas últimas

décadas e, mais recentemente, o Scrum vem dominando. Talvez pareça algo
estranho, mas, basicamente, o Scrum é um conjunto de processos e práticas
simples que permite explorar a velocidade da mudança. Sou Kelley O’Connell e
trabalho com gerenciamento de projetos há mais de 20 anos. Passei a primeira
metade da carreira executando projetos em cascata. Recentemente, venho
trabalhando e oferecendo coaching em Gestão Ágil, especificamente em
Scrum. Neste curso, vamos explorar conceitos básicos sobre o Scrum e como
usá-lo no ambiente de trabalho. Primeiro, vamos ver por que tantas
organizações estão migrando para o Scrum. Então, vamos falar das mudanças
que o Scrum exige na organização do trabalho e da equipe. Por fim, vamos
discutir como gerenciar e avaliar o trabalho de forma contínua. Espero que até o
final deste curso você esteja no caminho certo para entender como o Scrum
ajudou muitas empresas e como você também pode aproveitá-lo. Vamos
começar.

A abordagem Scrum para o sucesso do projeto

A língua muda o tempo todo. É como se ela tivesse vida própria. Conforme
usamos e adaptamos palavras, novas definições são criadas para se adequarem
ao significado atual. Um exemplo é a palavra “googol”. Quando inventada na
década de 1930, significava o número 10 elevado à 100ª potência. Setenta anos
depois e com a ortografia diferente, virou nome de uma empresa de
internet. Poucos anos depois, o substantivo deu origem ao verbo “googlar”, que
significa pesquisar qualquer coisa na internet. Da mesma forma, Scrum é uma
adaptação da palavra scrummage, usada no jogo de rugby. O Google se
transformar de nome de empresa no nome de seu aplicativo e, então, na ação
realizada no aplicativo faz sentido. Mas como pode o Scrum ter vindo do
rugby? No rugby, scrummage ou scrum é o método usado para reiniciar a
partida após uma falta. São oito jogadores de cada equipe agrupados, com a
cabeça para baixo, tentando pegar a bola. Não é bem o melhor exemplo de
gerenciamento de projetos, mas, usando a imaginação, até que faz sentido. Em
uma equipe de projeto, o objetivo é terminá-lo. Historicamente, usando
métodos tradicionais, isso significava planejar todo o projeto no início e seguir
esse plano à risca. Na vida real, o trabalho no projeto é totalmente
imprevisível. No início, é impossível saber exatamente como será o
desdobramento de um projeto e a melhor forma de enfrentar seus desafios
específicos. A Gestão Ágil de Projetos é um movimento que nasce do desejo de
se adaptar, em tempo real, às mudanças enfrentadas pelas equipes. É aí que
entra a equipe de rugby. Os fundadores da Gestão Ágil notaram que, no rugby,
o objetivo é atravessar o campo com a bola e marcar pontos, fazendo uma
jogada por vez. Então, por que não fazer o mesmo com os projetos? Em vez de
pensar somente em ganhar a partida toda, por que não pensar em atingir cada
marco e entrega? Esses gestores inovadores adotaram a palavra Scrum para
refletir essa nova abordagem, que divide as entregas e marcos em partes
menores e une toda a equipe para que ela se concentre em atingir apenas uma
meta por vez. Assim como no rugby, se a equipe conseguir
pequenos resultados com regularidade, automaticamente ganha o jogo — ou
entrega o projeto. Assim, o termo scrum, dos esportes, ganhou um
novo significado nos últimos anos. Significa administrar os projetos como uma
partida de rugby, buscando as pequenas metas e entregas que permitirão
concluir o projeto.

A revolução ágil
Um gerente tradicional, trabalhando com projetos em cascata, dificilmente os
conclui com sucesso, muito menos conforme o planejamento inicial. É como um
meteorologista fazendo previsão do tempo para daqui a um ano. Se desse
certo, seria por sorte. Não que a metodologia em cascata, em si, seja ruim. Em
alguns casos, faz todo sentido, como na construção civil, em que a execução
sequencial de um conjunto predefinido de etapas resulta em um
edifício. Podemos planejar e programar o projeto todo com antecedência. Isso
acontece sempre que uma casa ou um prédio é construído. O problema é
quando aplicamos a técnica a um trabalho muito empírico, como o
desenvolvimento de software. O trabalho empírico é como um experimento
científico. Tentamos algo, observamos os resultados e, se não der certo,
tentamos algo diferente. É claro que não podemos fazer isso ao construir uma
casa, mas com software ou outros produtos fazemos isso diariamente. Essa é a
principal razão pela qual o modelo em cascata não funcionou bem no
desenvolvimento de software. É simplesmente impossível planejar o processo
de descoberta. A frustração de desenvolvedores de software altamente
qualificados trabalhando em projetos em cascata foi o que culminou na
revolução ágil. Cansados de uma taxa de insucesso similar à de um
meteorologista, eles concluíram que precisavam de uma opção melhor. O
resultado ficou conhecido como Manifesto Ágil. Tomando por base a
mentalidade da produção enxuta, em que fabricamos apenas o suficiente e a
tempo de cumprir a meta, eles estudaram como aplicar isso ao
desenvolvimento de software. O resultado foi o Manifesto Ágil e seus
princípios. Dê uma olhada no Manifesto Ágil. Você pode acessá-lo neste
endereço. Como se isso não fosse revolucionário o bastante, esse grupo
inovador reforçou o manifesto com 12 princípios fundamentais. O manifesto e
os princípios se tornaram a base de um novo conjunto de metodologias de
gerenciamento de projetos e desenvolvimento de software. Existem algumas
ideias em comum que tornam a Gestão Ágil diferente. Uma das principais
mudanças é que pedimos aos parceiros de negócios que trabalhem conosco
durante todo o projeto. Não basta que apareçam no começo para descrever o
que querem e, no final, dizerem que erramos. Precisamos de interação contínua
e direta para entregar o que eles realmente precisam. Outra questão essencial é
que não queremos mais avaliar o sucesso usando marcos e fases do
projeto. Queremos software funcional, que diga a todos como estamos indo, e
queremos feedback constante. Talvez a mudança mais revolucionária seja
permitir que as equipes se auto-organizem. Elas se sairão muito melhor fazendo
o planejamento e os testes partindo da base do que usando algum plano
inicial. O planejamento inicial é teórico. O planejamento evolutivo é prático e
tático, permitindo atingir as metas com mais rapidez e qualidade. Entre o
manifesto e seus princípios, esse grupo de desenvolvedores de software desistiu
de ser a versão de alta tecnologia do meteorologista. Eles estavam prontos para
o sucesso. Existe uma maneira melhor de desenvolver software: a Gestão Ágil.

Scrum: a principal metodologia de projetos

O Scrum quer que você falhe. Aliás, o lema do Scrum é “falhar rápido”. É sério.
Sei que parece estranho, mas há uma boa razão para isso. Em projetos
tradicionais, os gerentes e desenvolvedores trabalham meses ou anos até ver
resultados. Em 80% dos casos, o software e os projetos falham. Então, podemos
perguntar: eles vão continuar falhando? Na verdade, não. O segredo é se
concentrar na segunda palavra: rápido. O fracasso é bom, se soubermos
aprender com ele. Porém, se tivermos que esperar muito, já não aprenderemos
tanto. O Scrum resume o Manifesto Ágil e seus princípios a uma estrutura muito
simples, que incentiva o foco em pequena escala e ciclos rápidos de
aprendizagem. Este é o verdadeiro significado de falhar rápido: aprender
rápido. Com isso em mente, os fundamentos da estrutura são concebidos para
incentivar esse ciclo rápido de feedback. A estrutura do Scrum não é
prescritiva. Costumamos dizer que ela tem limites de segurança, como as
proteções laterais que vemos nas estradas. Essas proteções não dizem
exatamente em qual faixa devemos dirigir, mas nos mantêm no caminho para
uma boa viagem. O Scrum também. Tendo como diretrizes os princípios da
Gestão Ágil e uma estrutura flexível de atividades executadas em um
cronograma curto e uniforme, seu projeto estará pronto para o
sucesso. Resumindo, aqui vai a estrutura do Scrum em sua forma mais
simples. Para começar, o Product Owner tem uma lista de pendências com
as prioridades de trabalho da equipe. Mais ou menos a cada duas semanas, a
equipe analisa a lista de pendências e decide o que completar nas próximas
duas semanas. A equipe desenvolve e testa sua solução para os itens da lista de
pendências até que estejam prontos para uso. Ao final dessas duas semanas, a
equipe apresenta suas realizações ao Product Owner e às partes
interessadas. Por fim, a equipe reflete sobre os acontecimentos das duas
semanas e decide o que fazer para melhorar as práticas de trabalho. É isso. O
prazo curto e o foco em um produto concluído no final forçam a equipe a falhar
rápido. Ou melhor, a aprender rápido.

Solução de problemas em projetos com o Scrum

As equipes de projetos em cascata costumam enfrentar três restrições: prazo,
custos e escopo. Após o início do projeto, elas não podem alterar nenhum
desses itens. O problema é que, ao longo do projeto, o ambiente de negócios
ao redor muda. Isso significa que, quando terminamos, aquilo que
desenvolvemos perdeu valor. Não é culpa de ninguém. As necessidades dos
negócios estão mudando cada vez mais rápido. Os requisitos dos projetos
também vêm mudando rapidamente para acompanhá-las. Portanto, antes do
Manifesto Ágil, as equipes estavam fadadas ao fracasso em qualquer
projeto. Então, deixamos de nos concentrar nas três restrições de projetos e
decidimos flexibilizar uma delas: o escopo. Foi uma grande mudança. O
representante da empresa pode contar com uma determinada equipe – os
custos, por um determinado prazo, para desenvolver o que considera mais
valioso. É simples. Todas as metodologias ágeis seguem essa grande mudança
de paradigma. Mantendo tudo fixo, exceto o escopo, temos uma estrutura que
entrega exatamente o que é necessário o mais rápido possível. A Gestão Ágil
engloba muitas metodologias que seguem os mesmos princípios. Uma delas é
o Scrum, que deu um passo adiante, criando uma estrutura que ajuda as
equipes a manter o foco e as protege das distrações. No Scrum, existem duas
funções essenciais: o ScrumMaster e o Product Owner, responsável pelo
produto. Os autores do Manifesto Ágil reconhecem que não tinham acesso aos
especialistas certos na empresa com a frequência necessária para orientar suas
decisões diárias. O Scrum resolveu isso criando a função de Product Owner. É
um representante da empresa 100% comprometido com a equipe. É o trabalho
dele em período integral. Eles também perceberam que alguém precisava
ajudar a equipe a resolver os problemas cotidianos e contrabalançar as
constantes mudanças nos requisitos. Assim, a função de ScrumMaster foi
elaborada para proteger a equipe e permitir que ela conclua o trabalho sem
distrações. Essa função dedicada também ajuda a melhorar os
processos internos da equipe. Além dessas funções, no Scrum precisamos fazer
entregas rápidas, para que sempre saibamos se estamos no caminho certo. Para
falhar rápido e aprender rápido, precisamos de feedback rápido. No Scrum, o
prazo para que as equipes entreguem valor é de duas a quatro
semanas. Precisamos finalizar um produto aprovado pela empresa e
pronto para o cliente com essa frequência. O Scrum também reconhece que,
para entregar isso rapidamente, a equipe precisa de reuniões diárias. São as
reuniões diárias em pé. Por fim, o último elemento essencial nessa estrutura é
reconhecer que uma equipe saudável precisa de tempo para refletir e pensar no
que fazer para melhorar. Assim, no Scrum há um evento obrigatório chamado
“retrospectiva”, para que a equipe se avalie e decida o que melhorar. Essa é a
estrutura. O foco do Scrum é maximizar a eficiência da equipe. Como o escopo
é o ponto de flexibilidade nos projetos ágeis, o foco do Scrum é como entregar
o máximo possível de valor dentro das restrições de prazo e orçamento.

Funções essenciais em equipes de Scrum

A estrutura do Scrum é leve, mas incrivelmente flexível, eficiente e
poderosa. Porém, assim como um carro, a melhor estrutura não leva a
lugar algum sem um motor potente. Em toda equipe de Scrum, existem duas
funções essenciais: o Product Owner e o ScrumMaster. Vamos começar com o
Product Owner, ou PO. O PO é o representante da empresa na equipe. Ele
trabalha em período integral, todo dia, pois contribui para o produto final
diariamente. Ele revisa todo o trabalho concluído pela equipe e o aceita ou
pede alterações à equipe, para garantir que o máximo de valor seja
entregue. Anteriormente, a empresa era representada por
requisitos documentados que raramente eram atualizados. Em uma equipe de
Scrum, o PO está sempre solicitando trabalho e garantindo que os membros
entendam bem os detalhes da solicitação, mas a função dele vai além disso. Ele
também interage diariamente com as partes interessadas. Para o PO, não basta
interagir com a equipe. Ele também deve estar atento a todas as mudanças que
ocorrem no contexto empresarial. Como resultado, o PO cuida da visão do
produto. Ele define e gerencia a lista de tarefas pendentes e as prioriza. Lembre-
se de que, no Scrum, o escopo é flexível. Como o tempo e os custos
permanecem fixos, o PO sabe muito bem que o trabalho deve ser
constantemente classificado, priorizando o de maior valor. Ele também
pressiona para que a equipe conclua o máximo de trabalho possível em cada
pequeno prazo de entrega. Mas como é possível que uma equipe atenda a
essas demandas? Os fundadores do Scrum identificaram a necessidade de
contrabalançar o papel do PO, criando a função do ScrumMaster. Ele protege a
equipe e o processo. O ScrumMaster é o facilitador que mantém a equipe
dentro dos limites de segurança do Scrum. Ele equilibra as demandas do PO
conforme as necessidades da equipe. É a primeira válvula de segurança para
garantir que o ritmo da equipe seja sustentável. Não queremos que ela fique
esgotada antes de cruzar a linha de chegada. Veja que é uma declaração
importante. O Scrum é uma estrutura que não valoriza atos de heroísmo, sejam
individuais ou em equipe. Valoriza a sustentabilidade e o diálogo sobre o
que pode ou não ser realizado. O ScrumMaster é o porta-voz de maior
visibilidade da equipe. Ele valoriza a transparência. Cria gráficos e quadros para
mostrar o progresso da equipe a qualquer curioso ou interessado. Ele também é
a primeira pessoa a ser acionada quando algo atrapalha a equipe. O
ScrumMaster trabalha para eliminar qualquer obstáculo até que a equipe possa
continuar. Enquanto o PO se concentra no que precisa ser feito, o ScrumMaster
se concentra em como a equipe faz o trabalho. Mais uma coisa. O ScrumMaster
também responsabiliza a equipe pelos seus compromissos com o Product
Owner. Ele aponta tendências no desempenho da equipe ao longo do
tempo, ajudando-a a melhorar seus processos e práticas. Como podemos ver,
cada função é essencial para que a estrutura funcione corretamente. Sem uma
dessas funções, o Scrum torna-se muito menos eficaz do que trabalhando com
as duas.

Definição da equipe de Scrum

Uma vez, recebi uma tarefa, mas não tinha as ferramentas necessárias para
realizá-la com sucesso. Era como se eu estivesse destinada a fracassar. Ao
montar sua equipe de Scrum, espero que planeje fazer de tudo para ajudá-la a
ter sucesso. O Scrum envolve colaboração e comunicação diárias. Tudo que for
feito para facilitar isso na equipe trará grandes vantagens no futuro. Por isso, se
possível, coloque os membros da equipe na mesma sala, corredor ou
espaço, para tornar a colaboração mais eficaz. Em muitas empresas isso é
inviável, por causa da estrutura física. Tudo bem. Mesmo assim é possível ter
sucesso com o Scrum. Você só precisa trabalhar mais, para garantir que
ocorra colaboração suficiente. Você pode experimentar
videoconferências, teleconferências e salas de chat dedicadas em todas as suas
unidades, por exemplo. Isso pode facilmente ajudar a equipe a manter
contato. Agora vamos falar da composição da equipe. A maior prioridade é
garantir uma equipe dedicada. Quando os membros da equipe ficam
alternando entre um projeto e outro, eles perdem muita eficiência, o que atrasa
a entrega. Trabalhar com uma equipe principal dedicada resulta em mais
concentração, eficiência e agilidade na entrega. O tamanho ideal da equipe é de
sete membros, variando de cinco a nove. Sei que parece específico, mas
pesquisas indicam que esses números maximizam a capacidade das pessoas de
estreitar relacionamentos e colaborar com eficácia. É claro que podemos ter
mais pessoas, mas os canais de comunicação necessários para manter todos
informados ficam cada vez mais difíceis ao acrescentar mais gente. No mundo
perfeito, teríamos uma equipe de cinco a nove pessoas com todas as
habilidades necessárias para concluir o trabalho. São os recursos com
“habilidades em T”: eles têm grande conhecimento geral em diversas áreas e
conhecimento profundo em uma única área, como um T. Por exemplo: trabalhei
com uma desenvolvedora de Java muito competente, a barra vertical do T, que
também tinha habilidades como analista de banco de dados, a barra transversal
do T. Então, ela conseguia trabalhar em mais de um tipo de entrega. É difícil
encontrar recursos assim, então devemos providenciar recursos de consultoria
que possam ser usados quando a equipe precisar de habilidades
especializadas. Algumas habilidades especializadas que vejo com frequência são
arquitetos, analistas de banco de dados e analistas de segurança. São pessoas
de quem às vezes precisamos para trabalhar com a equipe, mas talvez não haja
trabalho suficiente para mantê-las totalmente ocupadas. Isso é muito comum, e
com o nível certo de comprometimento inicial e comunicação contínua, pode
ser um grande sucesso. Uma unidade pequena que trabalha em conjunto o
tempo todo sempre vai enfrentar conflitos internos. Precisamos de algumas
regras básicas para evitar problemas. São as normas para a equipe, e devemos
ajudar a equipe a defini-las antes mesmo que o trabalho comece. Essas normas
são compromissos que os membros da equipe assumem, especificando como
vão trabalhar juntos, resolver divergências e chegar a um consenso sobre o
projeto. Uma das normas mais comuns em equipes de Scrum é aceitar
divergências, mas seguir em frente com a decisão tomada pelas equipes. Outra
norma comum é sobre o uso de notebooks em reuniões, para garantir que
todos prestem atenção à conversa. Podemos definir normas até sobre como
responsabilizar uns aos outros. Há muito espaço para criatividade nas normas
da equipe, mas elas devem ter o compromisso de todos, para que sejam
úteis. Também devem ser aplicadas com justiça, e a equipe deve confiar um no
outro o bastante para que todos se responsabilizem mutuamente por cumprir
as normas. Se você trabalhar nesses elementos e auxiliar a equipe na
preparação inicial, o sucesso chegará depressa. Quando a equipe é preparada
para o sucesso, ela consegue trabalhar com eficácia rapidamente. Você vai se
surpreender.

Elaboração da visão do projeto

Eu jamais sairia de férias deixando para escolher o destino ao chegar no
aeroporto, com base nos voos disponíveis. Não sei você, mas eu prefiro
escolher o destino e os passeios antes de começar a viagem. Assim, consigo
exatamente o que quero. Um projeto Scrum também funciona assim. A visão é
o mapa que guia você e a equipe até o destino. O Product Owner a define antes
de começar o trabalho. A visão diz a todos aonde vocês estão indo e que
produto ou aprimoramento valioso vão entregar no final. O destino
apresentado na visão é o que chamamos de Produto Mínimo Viável, PMV. O
PMV envolve desenvolver um produto apenas o suficiente para poder lançá-lo
aos primeiros usuários. Então, é possível obter feedback desses usuários
finais. Nessa abordagem, se trabalharmos um pouco para lançar um produto
utilizável, cumprimos a meta. Existem boas razões para abordar o trabalho
dessa forma. Primeiro: quanto mais rápido conseguimos oferecer algo às partes
interessadas, mais rápido obtemos feedback e entendemos o que mais é
necessário. Segundo: dando atenção à entrega rápida, minimizamos a
possibilidade de aumento do escopo ou trabalho supérfluo, em que há
acréscimo de itens desnecessários. A disciplina e a execução ainda são
necessárias, mas agora temos uma maneira de observá-las. Depois de elaborar
a visão, é hora de começar a desmembrá-la em partes funcionais. Aqui vai uma
visão que podemos usar. Ajudar os profissionais ocupados a ter mais tempo e
se sentirem mais saudáveis, fornecendo um aplicativo móvel em que eles
possam rapidamente pedir um almoço saudável, saboroso e acessível, com
opção de entrega ou retirada no local. O PO pode fazer isso com
antecedência, mas é fundamental que a equipe entenda bem essas
funções. Somente com essa conscientização, a equipe vai realmente
entender seu papel para que a entrega esteja conforme a visão. O primeiro nível
de desmembramento é identificar seus temas. Os temas são agrupamentos de
tarefas semelhantes. Os restaurantes fazem isso todo dia. Aperitivos, saladas,
entradas e sobremesas são os temas com que trabalham. Não é só para ajudar
os clientes com o cardápio. Também são úteis na organização da cozinha. Você
provavelmente prepara a sobremesa e a salada separadamente, não é? O
mesmo vale para os temas. Usando o exemplo da visão de um aplicativo móvel
para que os clientes peçam refeições, os temas do nosso aplicativo poderiam
ser perfil, pedido, pagamento e entrega, entre outros. Esses temas ajudam de
duas maneiras. Primeiro: eles ajudam a levantar ideias sobre o que precisa ser
desenvolvido para atender ao PMV do tema. Segundo: eles ajudam a agrupar as
tarefas para obter eficiência e minimizar os riscos, como garantir que a
segurança seja desenvolvida antes que o desenvolvimento do perfil esteja
concluído. Após a identificação dos temas, eles são novamente divididos, agora
em recursos. Os recursos são as pequenas parcelas de trabalho que
podemos usar para nos manter organizados. No nosso exemplo, poderíamos
dividir o tema do perfil em recursos como login, salvar senha, pedidos
recentes, favoritos e locais recentes. Sabendo que nossa meta é um PMV, talvez
o Product Owner diga que os únicos recursos necessários nesta versão seriam
segurança, login e salvar senha. Os outros seriam interessantes, mas não
obrigatórios para concluir a versão inicial do produto. Assim, você e a equipe
podem usar a visão e o PMV para se manterem organizados e focados no
destino.

Como escrever histórias de usuários

Nós falamos sobre temas e recursos como agrupamentos de tarefas. São ideias
muito úteis para ajudar a nos organizar, mas ainda são muito grandes para que
a equipe trabalhe e agregue valor em prazos curtos. Fazemos o
desenvolvimento para clientes ou usuários. Cada interação entre eles e nosso
produto é um caso de uso que nos conta uma história de como eles vão utilizá-
lo. Chamamos isso de histórias de usuários, e esse é o nível de detalhes de que
precisamos para saber o que fornecer. A história do usuário é o nível tático do
trabalho que pode ser entregue rapidamente. Ao mesmo tempo, não é tão
pequena a ponto de não gerar valor. Qualquer pessoa da equipe pode escrever
histórias de usuários, mas geralmente é o PO. Como parte interessada e
representante do cliente, é dever dele garantir que tudo na lista de
pendências agregue valor ao cliente, então ele geralmente escreve as histórias
de usuários. Ao escrever histórias de usuários, use como orientação o acrônimo
INVEST, criado por Bill Wake. Primeiro, boas histórias de usuários são
independentes. Podem ser entregues à parte de outras histórias e têm valor por
si só. Se você tiver tempo para fazer somente uma coisa, essa história pode
permanecer separada. Elas também são negociáveis. Até que a história seja
aprovada, ela pode ser reescrita, alterada ou cancelada a qualquer momento. As
histórias de usuários devem ser valiosas. Elas agregam valor ao PO, às partes
interessadas e aos clientes. Simplificando, elas são relevantes. Elas também
precisam ser estimáveis. Devemos ser capazes de estimar o tamanho da história
em pontos de história. Isso significa que a história é descritiva o suficiente para
que saibamos como finalizá-la. Somente então será possível entender o esforço
necessário. As histórias de usuários também devem ser sucintas, pequenas o
bastante para serem concluídas em uma iteração, ou sprint. Por último,
testáveis. As histórias fornecem informações suficientes para que
possamos desenvolver testes para elas. Embora pareça muito trabalho para uma
história de usuário, temos um formato que ajuda a escrever boas histórias. É
este aqui. Este formato simples é muito informativo. Ao entender de qual cliente
estamos falando, compreendemos melhor a necessidade, e isso ajuda a
nos concentrarmos em uma atividade dentro do nosso produto. Definir
claramente a necessidade e, o mais importante, o benefício esperado com o
requisito ajuda a estimular as conversas da equipe visando esclarecer o que é
valioso. Usando como exemplo nosso aplicativo móvel para pedir
refeições, uma boa história de usuário seria “como cliente móvel, desejo criar
um perfil para que seja mais rápido realizar pedidos futuros”. Isso é conhecido
como história de usuário funcional, ou seja, ela tem uma função para o usuário
final. Você também vai escrever histórias não funcionais. Elas ajudam a
confirmar a funcionalidade de que os usuários finais precisam sem beneficiá-los
diretamente. Aqui vai um exemplo. Como desenvolvedora, desejo atualizar o
software de banco de dados para a versão mais recente, para que tenhamos um
produto com suporte. Mas não basta ter boas histórias de usuário: cada uma
deve ter critérios de aceitação, ou CA. O CA é a ferramenta mais poderosa que a
equipe tem para reduzir erros ao concluir uma história. Sempre que a história
do usuário é escrita, o PO e a equipe trabalham juntos para determinar o CA da
história. Assim, cada história tem seu próprio CA. No caso da nossa história
funcional sobre a criação de um perfil, o CA pode ser que as seguintes
informações do cliente sejam registradas e salvas: nome, e-mail, número de
telefone e senha. Outro CA nessa história garantiria que números de telefone, e-
mails e senhas inválidos fossem rejeitados. Seu CA deve ser o mais explícito
possível, para que todos na equipe saibam o que significa terminar a história. As
histórias de usuários são as ferramentas táticas que as equipes de Scrum usam
para entregar o trabalho correspondente ao produto. Escrever boas histórias
pode ser um desafio, mas, com a prática, fica cada vez mais fácil.
Como definir limites para chegar ao sucesso
A esta altura, seus temas e recursos devem estar divididos em histórias de
usuários. Além disso, você deve ter estimado suas histórias usando pontos, para
saber quanto trabalho precisa ser feito. Essa é sua lista de pendências do
produto. O próximo passo é criar limites para que a equipe conclua esse
trabalho. Essas diretrizes incluem definir o que significa “concluído” para a
equipe, priorizar a lista de pendências e estabelecer o ritmo das
iterações. Primeiro, a equipe precisa definir o que significa “concluído” para as
histórias. Cada história tem seus próprios critérios de aceitação, mas essa
definição é um pouco mais genérica. Ela estipula os requisitos mínimos para
todas as histórias. Como eles se aplicam a tudo que está na lista de
pendências, não devemos repeti-los nos CA de cada história. Essa definição
global de “concluído” ajuda a economizar tempo, além de conferir mais
precisão aos CA específicos de cada história. Veja alguns exemplos de critérios
de “concluído” para todas as histórias: “uma história na equipe é
considerada concluída depois de testada no ambiente de pré-lançamento”, ou
então “uma história na equipe é considerada concluída depois que o código for
revisado e todos os erros forem corrigidos”. Em seguida, o Product Owner deve
priorizar a lista de pendências. É a chamada revisão da lista de pendências, em
que as histórias são constantemente ordenadas pelo valor. Quanto mais valioso
o resultado da história, mais alta sua posição na lista. Lembre-se de que o
Scrum permite flexibilidade no escopo, mas a duração é fixa, então o PO espera
que os itens mais valiosos sejam entregues primeiro. Assim, mesmo se o prazo
acabar, um produto valioso será entregue. Por fim, precisamos estabelecer o
ritmo ou duração das iterações. No Scrum, cada iteração ou sprint pode durar
de uma a quatro semanas, com preferência pela menor escala temporal. As
melhores práticas do Scrum dizem que devemos falhar e aprender rápido. Por
esse motivo, devemos estabelecer a menor duração possível para as
iterações. Quando trabalho com equipes, geralmente recomendo que
optem por iterações de duas semanas. Essa duração realmente ajuda a equipe a
se concentrar no que está acontecendo durante a iteração. Uma iteração de
duas semanas está na zona de Goldilocks. Se a iteração for muito curta, as
equipes tendem a entrar em pânico, e a qualidade diminui. Se for muito longa,
inconscientemente, a equipe vai relaxar, por pensar que tem bastante
tempo. Porém, essa zona intermediária de duas semanas é a ideal. Cria um
senso de urgência na equipe, sem provocar pânico. Traçar esses limites ajuda a
equipe a entender o que significa “concluído” para cada história, o valor de
histórias específicas e o prazo em que serão entregues. Agora, a equipe tem a
estrutura de execução de que precisa para obter sucesso.

Pontos de história e estimativas no Scrum

Todos os dias usamos dois tipos de estimativa: real e relativa. Usamos a
estimativa real ao ler um mapa. Para ir de A a B, são 15 quilômetros. É muito
específico. Já a estimativa relativa consiste em comparar duas coisas para
ter uma ideia geral de algo, como “uma girafa é duas vezes mais alta que uma
zebra” ou “um bolo tem a mesma largura de uma torta”. Na Gestão Ágil e no
Scrum, utilizamos os dois tipos de estimativa. Usamos a estimativa relativa para
ter uma noção da quantidade de trabalho, comparando histórias de usuários
umas às outras. Ela nos dá uma ideia da dimensão de algo. As próprias histórias
são indicações aproximadas de como o usuário deseja interagir com o
produto. Por ser um relato aproximado da necessidade, não podemos ser muito
específicos quanto à sua dimensão. Além disso, como é apenas uma previsão
inicial, as partes interessadas não devem achar que sabemos exatamente o
que é necessário para concluir o trabalho. A estimativa relativa ajuda a enxergar
que se trata apenas de uma estimativa, não de um compromisso. Porém,
quando nos comprometemos com uma tarefa, precisamos saber muito bem o
que é necessário para realizá-la. Assim, quando for hora de fazer o
trabalho, precisamos especificar quanto tempo vai demorar, então passamos
para a estimativa real. As equipes de Scrum usam o Planning Poker para fazer
estimativas relativas de suas histórias. Os pontos de história são a unidade de
medida que usamos para expressar o tamanho relativo. Aqui vai um ótimo
curso sobre como jogar Planning Poker com sua equipe de Scrum. A estimativa
deve ser simples e rápida. Não deveria levar dias ou horas para determinar
quanto esforço vamos dedicar a algo. Talvez seja preciso prática, mas, depois
que pegamos o jeito, fazemos isso rapidamente.

Criação do roteiro e planejamento de lançamentos

Depois de todo trabalho preparando os temas, recursos e lista de pendências e
identificando a duração das iterações, é hora de estimar quando as tarefas serão
realizadas. O Scrum também tem ferramentas para isso. Usamos dois
mecanismos diferentes: o roteiro e o planejamento de lançamentos. O roteiro é
bastante geral e visa à aplicação dos temas ao longo do tempo. Assim, todos
terão uma noção geral de qual será o foco num determinado período. Usando o
exemplo da criação de um aplicativo móvel para pedir refeições, identificamos
os temas perfil, pedido, pagamento e entrega. Agora precisamos decidir a
melhor sequência para trabalhar nesses temas. Embora o pagamento talvez seja
o mais importante para os nossos parceiros de negócios, do ponto de vista das
dependências, provavelmente faz mais sentido priorizar o perfil e o
pedido. Como tudo no Scrum, essa é uma diretriz, não uma regra, mas seguindo
essa ideia, veja como seria o roteiro. Como podemos ver, esses temas não estão
necessariamente ordenados pelo valor. Depois disso, podemos organizar as
histórias conforme os cronogramas de temas que elaboramos. É assim que
criamos o planejamento de lançamentos, que é a próxima camada de
detalhes. É um plano geral que visa ligar o roteiro às iterações. Ele permite
visualizar como faremos as entregas. No Scrum, precisamos concluir histórias
totalmente funcionais ao final de cada iteração. Porém, não somos obrigados a
divulgá-las às partes interessadas no fim de cada iteração. Ou seja, podemos
concluir todo o trabalho de duas ou três iterações e divulgar os resultados
juntos. Vamos usar os pontos de história para ajudar a equipe a decidir o
que consegue fazer em cada iteração. Depois de trabalhar junta por um
tempo, a equipe alcançará uma velocidade estável. Isso significa que todos
saberão quantos pontos de história conseguem completar em cada
iteração. Até que a velocidade se estabilize, faremos estimativas do número de
pontos a concluir em cada iteração. Por exemplo: suponha que a equipe
tenha acabado de começar e considere que, em grupo, consiga lidar com 10
pontos a cada iteração de 2 semanas. Pretendemos fazer o lançamento após 3
iterações, ou seja, 30 pontos por lançamento. Vamos analisar o roteiro e as
histórias que organizamos ao longo do tempo com base nos temas. Só
precisamos selecionar as histórias de maior prioridade por tamanho, para
encaixá-las em cada iteração. Deve ser algo assim. Veja que não estou
planejando por ordem de prioridade. Neste nível de detalhe, trata-se de
maximizar o número de pontos por iteração. Então, se a próxima história de
maior prioridade, a história C, de oito pontos, for grande demais para a primeira
iteração, descemos na lista até encontrarmos uma que se encaixe — a história
D, de cinco pontos. Lembre-se de que o roteiro é uma estimativa de quando a
equipe vai concluir essas histórias. Ele deve ser atualizado no fim de cada
iteração. A equipe segue aprendendo e escrevendo novas histórias durante a
iteração, então o roteiro deve ser um documento vivo. É apenas um guia, mas
nos ajuda a manter o foco para que o projeto atinja os objetivos.

Planejamento das iterações no Scrum

Conforme a equipe se prepara para uma iteração, torna-se necessária uma
colaboração mais detalhada, e é exatamente isso o que fazemos na reunião de
planejamento da iteração. A participação plena é fundamental. Precisaremos de
todos os membros da equipe de desenvolvimento, do ScrumMaster e do
Product Owner. Essas responsabilidades não podem ser delegadas. Usando a
lista de pendências priorizada, o PO apresenta as histórias de maior valor para a
equipe na sequência. A equipe precisa estar à vontade para fazer perguntas. O
objetivo é que todos tenham plena compreensão do objetivo da história e de
seus CA específicos. Na reunião, também é útil publicar a definição de
“concluído” da equipe para todas as histórias. Como a definição de “concluído”
da equipe se aplica a tudo, ter essa informação à mão ajuda a garantir que
todas as tarefas sejam identificadas. No planejamento das iterações, fazer
perguntas é primordial. No final do planejamento, a equipe vai se
comprometer a terminar todo o trabalho. Problemas de entendimento devem
ser evitados, e essa é a ocasião certa para esclarecer as histórias. Depois que
todos entenderem os detalhes das histórias, a equipe anota as tarefas
necessárias para concluir cada uma. Vamos ao exemplo do aplicativo para pedir
refeições. Na história “criar identificação do usuário”, a tarefa seria “gravar
identificação do novo usuário no banco de dados” e levaria cerca de meia
hora. Vamos ver como atribuir as histórias. Cada tarefa deve ficar clara e ser
estimada usando o tempo. Nas iterações, utilizamos pontos para identificar as
histórias a incluir em cada iteração. Nas tarefas, usamos o tempo para
preencher a capacidade — as horas que cada membro da equipe pode
dedicar. Sabendo o número de horas de todo o trabalho planejado na
iteração, precisamos verificar se a equipe tem capacidade para realizá-lo. Como
orientação geral, em um dia de trabalho de oito horas, as pessoas geralmente
têm apenas seis horas de tempo produtivo. As outras duas horas costumam ser
gastas com telefonemas, interrupções, e-mails, etc. Estamos tentando evitar o
comprometimento excessivo. Portanto, a comparação entre horas necessárias e
horas disponíveis é uma boa etapa de confirmação. Por fim, agora que as
histórias foram claramente explicadas e as tarefas em cada uma delas foram
definidas, é hora de se comprometer com o trabalho. O Scrum leva a etapa de
compromisso muito a sério. Perguntamos a cada pessoa da equipe se ela se
compromete com as histórias da iteração, e ela deve responder “sim” ou “não” e
por quê. Se alguém não puder se comprometer, o PO e a equipe precisam
trabalhar juntos para mudar a forma da iteração até que todos possam se
comprometer. O planejamento das iterações é um esforço
colaborativo importante no Scrum. Repita essa reunião no início de cada
iteração. Você vai ficar cada vez melhor.

Monitoramento do progresso no Scrum

Quando trabalhamos em projetos críticos, as partes interessadas costumam
perguntar aos membros da equipe como vão as coisas. Isso é bom. As pessoas
estão se dedicando ao resultado do projeto. Pode ser uma distração para a
equipe, pois alguns membros têm uma perspectiva completa da situação, e
outros não. O Scrum aborda esses desafios publicando radiadores de
informações. Isso abrange tudo que publicamos em paredes ou sites de
equipe e que ajude todos a entender o que está sendo feito e o andamento. As
formas variam muito, conforme a necessidade do ambiente e do projeto. Já vi
equipes publicarem as normas para a equipe, a visão do projeto, a definição de
“concluído”, os roteiros e o planejamento de lançamentos. No mínimo, as
equipes publicam o quadro de tarefas e o gráfico de burndown. Então, vamos
detalhar isso. O formato do quadro de tarefas varia, mas alguns
componentes são essenciais. Ele mostra as histórias prometidas na iteração, as
tarefas atuais e a situação delas e as tarefas já concluídas. Este é um exemplo
simples de um quadro de tarefas. Ele mostra claramente as histórias prometidas
e as tarefas relacionadas, mas vai além, mostrando quais tarefas foram
iniciadas e quais já foram concluídas. Essa ferramenta simples e prática informa
a todos no que a equipe está trabalhando. Esse quadro se torna a essência da
execução da iteração. A equipe se reúne ao redor dele para acompanhar o
que está acontecendo na iteração e se ajudar, caso alguém tenha
dificuldades. Outra ferramenta primordial para apresentar informações sobre o
andamento é o gráfico de burndown da iteração. Ele é usado pela equipe para
avaliar seu sucesso ao executar a iteração. Embora o quadro de tarefas informe
a conclusão das atividades, ele não compara isso com a situação da equipe na
iteração. O gráfico de burndown faz isso. Aqui vai um exemplo. O gráfico
informa exatamente onde estamos na iteração dia após dia e quanto trabalho
nos comprometemos a fazer em toda a iteração ou horas. O ideal é que o
detalhamento seja feito de forma linear. A linha “real” informa exatamente
como estamos indo em comparação com o ideal. É uma ferramenta muito
poderosa que mostra o andamento da equipe a todos os interessados. Fácil de
criar, usar e entender. Essas são as principais características dos
grandes radiadores de informações. São úteis para a equipe, e os interessados
vão gostar de entender a situação com clareza.