Introdução

Aposto que você que tem algum interesse em desenvolvimento de software já se deparou com alguns desses termos: Kanban, Scrum, Extreme Programming, Lean Development, etc.

Todos esses nomes se referem a metodologias de gestão de projetos de software. Elas foram criadas a partir do conjunto de princípios que estão presentes no que chamamos de Agile. Esses princípios foram publicados no “Manifesto Ágil” (“Manifesto for Agile Software Development”, em Inglês), publicado em 2001, em Utah, por desenvolvedores que se encontraram para discutir inovações possíveis na gestão de seus projetos, procurando algo menos rígido do que o que prevalecia no mercado.

Ao longo deste E-Book, veremos que as metodologias ágeis, apesar de surgidas para melhorias no processo de gestão de projetos de software, romperam as barreiras do setor e hoje são utilizadas em empresas inovadoras dos mais diversos setores.

Para que se possa utilizar essas metodologias na sua empresa, a maneira mais rápida e eficiente é utilizando um dos frameworks possíveis – o Scrum – e uma ferramenta – o Quadro Kanban. No E-Book, iremos abordar o Scrum. Explicaremos suas características, requisitos e o efetivo funcionamento dele. Além disso, iremos dar um passo-a-passo em como, ao término do E-Book, implementar hoje esse método de trabalho na sua empresa.

Vamos?

Metodologias ágeis para gestão: o que são e como diferem das tradicionais?

5 minutos de leitura

Antes da agilidade: Waterfall

A metodologia que se usava no mundo até a publicação do “Manifesto Ágil”, Waterfall (ou Cascata), era predominante nos estudos de melhores práticas de gestão de projetos. O seu nome advém do formato que adota para criar, produzir e entregar projetos. O projeto é feito de maneira sequencial: é demandado com um objetivo final, forma-se o escopo, divide-se em pequenas tarefas, associa-se à dependência existente entre elas e traça-se os diferentes “caminhos” que serão percorridos para realização do produto.

Como este processo é sequencial, uma vez que uma etapa foi concluída, os desenvolvedores não podem voltar para uma etapa anterior – não sem descartar o projeto inteiro e recomeçar desde o início. Não há espaço para mudança ou erro, portanto, um resultado do projeto e um plano extenso devem ser definidos no início e seguidos com cuidado


“Novamente o time de vendas subestimou o projeto!”

A metodologia “Waterfall” se mostrava falha. Por que?

1. Muitas vezes, as pessoas para as quais estamos construindo software não sabem exatamente o que precisarão e não sabem o que é possível com a tecnologia disponível. Esta maneira de trabalhar não consegue arcar com isso.

2. Muitas vezes, os designers da solução não são capazes de prever os problemas que surgirão da implementação de seus projetos.

3. Mudanças nos requisitos (por exemplo, como aqueles resultantes de novas tecnologias, mudanças em um mercado ou mudanças nos objetivos de negócios) não podem ser facilmente incorporadas com a “Waterfall” e muitas vezes há procedimentos de controle de mudança árduos para serem realizados quando isso acontece.


E então veio a solução: agilidade

Devido às recorrentes falhas do mercado de desenvolvimento de software, eis que surge o “Manifesto Ágil”.

“[…]Indivíduos e interações 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 […]”

Ao invés de lidar com processos pré-estabelecidos sequenciais, façamos interações entre a equipe de desenvolvimento e o cliente. Ao invés de fazer um escopo enorme e traduzi-lo em funcionalidades (que virá a não cobrir os verdadeiros desejos do cliente), entreguemos um software funcional. Ao invés de papelada e incessantes reuniões presenciais, vamos inserir o cliente no processo produtivo. Ao invés de tentar seguir um plano – falho desde sua concepção – vamos rapidamente nos adaptar às mudanças, de um jeito rápido e barato.

Se na “Waterfall” a palavra-chave era sequência, em metodologias que seguem os princípios da “Agile” prevalecem as iterações.


Exemplo: Scrum

Os desenvolvedores começam com um design de projeto simplista e, em seguida, começam a trabalhar em pequenos módulos. O trabalho nesses módulos é feito em sprints semanais e, ao término de cada sprint, as prioridades do projeto são avaliadas e os testes são executados. Esses sprints permitem que os bugs sejam descobertos e que o feedback do cliente seja incorporado ao produto antes que o próximo sprint seja executado. Isso é, o cliente faz parte do processo produtivo e são realizadas iterações semanais com ele para validação.


Por que a Agile?

1. A metodologia Agile permite que mudanças sejam feitas após o planejamento inicial. É feita justamente para podermos facilmente reescrever o programa sem prejudicar todas as outras tarefas (passadas ou futuras), conforme as já esperadas alterações cliente surgirem.

2. Como a metodologia Agile permite que você faça alterações, é mais fácil adicionar recursos que o manterão atualizado com os últimos desenvolvimentos da indústria.

3. No final de cada Sprint, as prioridades do projeto são avaliadas. Isso permite ao cliente adicionar o seu feedback para que eles finalmente possam obter o produto que desejam.

4. O teste no final de cada sprint garante que os bugs sejam capturados e cuidados durante o ciclo de desenvolvimento. Eles não serão encontrados apenas no final.

5. Porque os produtos são testados tão completamente com Ágil, que poderiam ser lançados no fim de todo ciclo. Como resultado, é mais provável que alcance sua data de lançamento.

Hoje, os princípios ágeis reinam nas formas de gestão para desenvolvimento de software. Dentre todas as metodologias usadas, cabe ao gestor e ao time escolher quais utilizar ou – como vamos discutir mais à frente – desenvolver a própria, juntando mais de uma metodologia

Vamos focar agora na metodologia de gestão de projetos de software que rompeu com a ideia e com o uso apenas para o mundo de software, e hoje é utilizada nas empresas dos mais diversos setores: o Scrum.

Metodologia Scrum

10 minutos de leitura

Toda metodologia Agile aborda a complexidade no trabalho, tornando a informação transparente para que qualquer um possa inspecionar e se adaptar de acordo com as condições atuais ao invés das – equivocadas e não mais aplicáveis ao contexto – condições previstas. Isso permite que as equipes se protejam das armadilhas comuns de um processo de desenvolvimento em cascata (“Waterfall”): o caos resultante de requisitos em constante mudança; subestimação de tempo, recursos e custo; compromissos na qualidade do software; e relatórios de progresso imprecisos.

Os princípios ágeis são utilizados para guiar as diferentes metodologias de trabalho nas maiores empresas de tecnologia do mundo, como Google, Amazon, IBM e Microsoft. Contudo, um ponto muito relevante sobre os princípios ágeis é que eles surgiram para suprir a necessidade de uma metodologia adequada para projetos de software, mas seus adeptos vão muito além de empresas de TI. Algumas das maiores corporações do mundo, dos mais diferentes setores, são adeptas de alguns desses frameworks de trabalho, como: Bancos (Bank of America, Merrill Lynch, Credit Suisse, …), Consultorias (McKinsey & Co., Accenture, …), Mídia (CNN, The Economist, …) e tantos outros. Por mais diferentes que sejam seus nichos de mercado ou modelos de negócio, todas essas empresas têm uma coisa em comum que as fazem adeptas dessas novas metodologias de trabalho: a necessidade por agilidade para responder ao micro e macroambiente em que estão inseridas.

Deu para ter uma noção do quão relevante são esses novos métodos de trabalho?

Agora, vamos abordar o framework de princípios ágeis mais famoso, um dos menos atrelados ao uso exclusivo para desenvolvimento de software e, não por acaso, um dos mais fáceis de serem aplicados a qualquer empresa: o Scrum.


Scrum

Como surgiu?

O Scrum, a metodologia ágil mais famosa dentre o leque existente – e, também, a mais utilizada em empresas – foi criada no início da década de 90, com sua criação sendo atribuída a Jeff Sutherland e Ken Schwaber. Os dois, mais tarde, viriam a escrever o livro que funciona como manual para gestores implementarem o framework, “Guia do Scrum”. Seu nome advém do rugby e se refere a um time atuando em conjunto para atingir uma “goal” (em inglês, “goal” se refere tanto a “gol” – objetivo do time de rugby – quanto uma “meta” estabelecida) – uma analogia ao ambiente organizacional de uma empresa.

Como funciona?

O framework de trabalho do Scrum envolve 3 elementos para um bom funcionamento dos processos: (1) Papéis (personas envolvidas), (2) Cerimônias (eventos que devem ocorrer) e (3) Artefatos (documentação necessária).


Papéis

Product Owner: O PO, como é chamado, é o usuário principal do produto ou qualquer pessoa com uma compreensão sólida dos usuários, do mercado, da concorrência e das tendências futuras para o tipo de projeto que está sendo desenvolvido. Tem papel chave na questão da comunicação dentro do projeto, pois ele coordena a relação com o Time e quaisquer outros stakeholders envolvidos no projeto.

Scrum Master: É um líder-servil para o Time. Ele não tem autoridade sobre o Time, mas tem autoridade sobre como o processo do trabalho está caminhando. Suas principais funções são (1) garantir que os valores e práticas do Scrum estão sendo seguidos durante o trabalho, (2) remover quaisquer impedimentos que surjam durante o trabalho do Time e (3) facilitar o trabalho do Time junto com o P.O.

Time Scrum: Todos que trabalham em efetivamente construir o produto. Trabalham em conjunto, fazendo de tudo a seu alcance para conseguir entregar tudo que foi acordado para aquela Sprint. Sem hierarquia, sem tarefas fechadas, mas com trabalhos de duração definida e designado a cada um dos membros. Em suma, é um grupo de pessoas trabalhado a cumprir um objetivo: fechar a Sprint com sucesso.


Eventos

Sprint: O Scrum baseia-se na ideia de que o projeto será finalizado após uma sequência de Sprints. As Sprints são prazos de trabalho que variam de 1 semana a 1 mês – 2 semanas sendo a duração mais comum. Nelas, o Time tem, quase que obrigatoriamente, dar um jeito de cumprir com o conjunto de tarefas planejados para aquele período de tempo.

Ao término de toda Sprint, com o trabalho realizado e os entregáveis resultantes desse determinado período de tempo, deve-se ter um incremento no produto/projeto que, caso necessário, poderia ser lançado/colocado em prática. A ideia por trás disso é uma consequência dos princípios ágeis: devemos construir produtos incrementais, para serem testados e validados continuamente ao longo do processo, ao invés de continuamente fazermos incrementos no produto para testá-lo e validá-lo ao final, quando as mudanças serão: (1) maiores (devido a maior divergência entre o entregável desejado e o realizado); (2) mais custosas, pois exigirão retrabalho e alterações naquilo que já estava pronto (é estimado pelo Google que uma alteração no escopo após ter escrito uma linha de código é cerca de 1.000x mais cara que qualquer mudança antes alteração antes da etapa de desenvolvimento) e (3) resultarão em atraso (por estar muito próximo da deadline).

Sprint Planning: O momento que antecede uma Sprint. Nessa cerimônia, todos os membros (Product Owner, Scrum Master e Time) se reúnem para priorizar as tarefas em termos de dificuldade na execução e valor para o usuário. Em seguida, são escolhidas aquelas que devem ser realizadas na próxima Sprint.

Daily Scrum: É o evento responsável por manter uma sincronia no trabalho de todos envolvidos no projeto. Uma reunião diária com, novamente, todos os participantes que não deve durar mais que 15 minutos – inclusive é sugerido que ocorra de pé (para ninguém se acomodar) ou com prazo definido por uma xícara de café – onde são abordados 3 pontos:

1. O que os membros do time fizeram hoje?

2. O que os membros do time farão amanhã?

3. Houve algum impedimento para a realização do trabalho? Se sim, o quê?

Caso tenha havido algum impedimento no trabalho dos membros do time, a responsabilidade recai sobre o Scrum Master para conseguir “destravar” essa tarefa. Como facilitador do processo Scrum, é sua função principal garantir um fluxo contínuo de trabalho.

Sprint Review e Retrospective: Reunião de fechamento da Sprint ocorrida. Ela é dividida em 2 partes:

Sprint Review (Revisão da Sprint): apresenta-se, ao Product Owner, os entregáveis acordados e são coletados quaisquer feedbacks para ajustes necessários.

Sprint Retrospective (Retrospectiva da Sprint): logo em seguida da Sprint Review, ocorre a análise de como o trabalho ocorreu e são discutidas ideias para melhorias dos processos para as Sprints seguintes. Aqui, cada membro do Time Scrum especifica ações e comportamentos que os membros do Time devem:

– Começar a fazer

– Para de fazer

– Continuar a fazer no decorrer do trabalho do projeto.


Artefatos

Product Backlog: o Backlog de um produto/projeto é uma lista de funcionalidades (software) ou entregáveis (geral) priorizadas, contendo breves descrições curtas de tudo que se imagina compor o produto/projeto final.

Ao aplicar o Scrum, não é necessário iniciar um projeto com um longo e antecipado esforço para documentar todos os requisitos – por, como já discutido acima, alterações de escopo ocorrerem com frequência no decorrer do desenvolvimento. Normalmente, o Time Scrum e o Product Owner começam por escrever tudo o que eles podem pensar para a priorização do Backlog.

Com agilidade, essa 1ª versão do Product Backlog é quase sempre mais do que suficiente para rodar uma primeira Sprint. A partir disso, o Backlog do produto/projeto é então permitido crescer e mudar à medida que se aprende mais sobre o entregável final desejado e seus clientes/stakeholders.

Sprint Backlog: é a lista de entregáveis que devem estar entregues ao término da Sprint, sendo estes pedaços selecionados do Product Backlog e atribuídos para o trabalho corrente. O Sprint Backlog deve ser escolhido cuidadosamente em termos de complexidade e valor criado pelos entregáveis: é aconselhável que se cada sub-Backlog criado (para cada Sprint) mantenha uma constante de esforço/valor criado por Sprint realizada, garantindo que não haverá (1) ociosidade do time e (2) excesso de trabalho – resultando, muitas vezes, em atrasos – em nenhuma Sprint do processo.


Exemplo de funcionamento: uma sprint do começo ao fim

1. Selecionamos 1 Product Owner, 1 Scrum Master e o Time Scrum para o trabalho.

2. Montamos o Product Backlog e priorizamos os itens componentes

3. Fazemos a Sprint Planning, na qual definimos sua duração e quais itens estarão entregues ao término dela (Sprint Backlog).

4. Durante a Sprint, realiza-se o trabalho e, diariamente, ocorrem reuniões breves (Daily Scrum) para manter a sincronia e sinergia entre as tarefas.

5. Ao término da Sprint, faz-se a Sprint Review, na qual apresenta-se o produto – que deve ser possível de ser testado e avaliado – ao Product Owner, clientes e outros stakeholders envolvidos.

6. Faz-se uma Sprint Retrospective, na qual todos os agentes envolvidos na execução do trabalho avaliam os processos atuais e sugerem melhorias para as Sprints subsequentes.

7. Repete-se o processo a partir do (2), fazendo quaisquer alterações necessárias no Backlog que surgirem, até que a última Sprint ocorra e o produto/projeto esteja finalizado.

De maneira superficial, esse é o Scrum. Existem livros e enormes bibliografias que abordam a sua completude e alguns pontos não citados no artigo, mas muito úteis e interessantes também.

(Exemplo de cerimônias e artefatos que integram o Scrum e não foram mencionados:  Planning PokerBurndown Chart)

Mas, com o que foi citado, você já pôde entender bem mais sobre esse inovador método de trabalho e, se quiser, optar por implementar ou não essa ferramenta no seu ambiente de trabalho.

Agora, vamos falar do passo a passo em como implementar o Scrum na sua empresa

Como implementar o Scrum na sua empresa

12 minutos de leitura

 

Refrescando a memória

Consiga um lugar para organizar os pensamentos ou o seu Backlog, se já estiver pronto. Isso pode ser feito tanto em um software como o Trello ou Pipefy, ou mesmo apenas em um quadro branco.

O Scrum começa com o Product Owner, o representante do usuário final, tendo autoridade para dizer o que vai ou não ter no projeto. Cabe ao Product Owner a listagem e priorização de uma lista de tarefas e requisitos necessários para o produto final – o Backlog. O Time Scrum – responsável pela produção e desenvolvimento do projeto em questão – é formado e um Scrum Master (o “resolvedor”) é alocado.

Em seguida, a base do Scrum: a Sprint. A Sprint é um prazo predeterminado em que o time responsável pelo desenvolvimento do projeto deve cumprir com um conjunto de tarefas listados no Backlog. O normal é durar cerca de 2 semanas – podendo variar entre 1 e 4 semanas. Faz-se o Sprint Planning, escolhendo quais partes do projeto serão contempladas na Sprint a se iniciar e aí mãos a obra: o Time tem a duração da Sprint para cumprir com o trabalho proposto.

Ao término, faz-se o Sprint Review, no qual se discute o que pode ser melhorado nos processos do Scrum e discute-se a produtividade em termos de entregáveis por período de tempo.


Pré-Requisitos

1 Scrum Master (SM): seja o SM da metodologia que você está tentando implementar. Seu papel será, justamente, garantir o cumprimento dos processos.

1 Product Owner (PO): consiga um PO adequado, que vá conseguir tanto transmitir as ideias do cliente/usuários do projeto que está sendo desenvolvido quanto esteja muito disposto a fazer tudo a seu alcance para o sucesso do projeto.

Time Scrum: monte o time com a quantidade de membros que você julgar conveniente ou tiver disponível.


Passo-a-Passo

1. Arrume o seu Backlog

O Product Backlog é uma lista de features que as pessoas querem que seja incluída no produto, em ordem de prioridade. Qualquer um pode adicionar qualquer coisa ao Backlog. Mas apenas o Product Owner – o dono do Backlog – tem o poder de realizar a priorização dos itens listados. O Backlog pode conter qualquer coisa relacionada ao produto: desde novos entregáveis e melhorias até problemas, riscos e bugs que possam surgir.

A priorização dos itens do Backlog – quais devem vir primeiro e quais mais tarde – deve ser feita olhando os itens (em sua maioria features do produto) como unidades de uma fila. O Product Backlog é uma fila de entregáveis a serem realizados e a ordem desejada deve considerar a complexidade do trabalho envolvido ao mesmo tempo que maximiza valor criado para usuário com a entrega feita.


2. Estimando o Backlog

Estime seu Backlog – para ter uma noção do tamanho dos itens – em função de pontos, não em função de tempo. Times de desenvolvimento são infinitamente mais capazes de dar palpites sobre estimativas em função de “tamanho” do trabalho do que em termos de “duração” do trabalho.

A pergunta correta não é “quanto tempo vai demorar?”, mas “quão grande é?”

Escolha um sistema de pontos para pontuar cada item do Backlog. Minha dica? A sequência de Fibonacci: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, … (não é a intenção do artigo explorar a relevância dos números de Fibonacci e suas diversas utilizações). Como no Scrum a regra de ouro é simplicidade, sugiro manter o range de possíveis valores entre 1-21.

Por mais claro que seja que “21” se trata do maior item e “1” do menor, pode haver uma falta de referencial no momento da alocação dos pontos entre os itens do Backlog. Para resolver isso, escolha: (i) o maior item e atribua a ele a maior pontuação (no caso, 21) e (ii) o menor item e atribua a ele a menor pontuação (no caso, 1).

Nesse estágio – de estimativas – pode-se jogar o Planning Poker. Cada membro do time recebe uma carta com cada uma das possíveis pontuações e vota uma pontuação para cada funcionalidade. Cada rodada é uma funcionalidade e todos devem virar as cartas da rodada ao mesmo tempo – para não haver vieses de opinião.

Caso não tenha entendido o Planning Poker (afinal, é complicado mesmo) muito bem, clique aqui.

Com essas estimativas em mãos, o Product Owner tem agora uma ótima base para fazer a priorização oficial do Backlog.


3. Sprint Planning: Requisitos

A próxima coisa que deve ser feita é determinar a duração da Sprint. Na metodologia, costuma variar entre 1 semana e 1 mês – sendo 2 semanas a mais frequente. Reflita bastante antes de tomar a decisão sobre a duração da Sprint, pois, ao longo do projeto, é recomendado – na verdade, é quase mandatório – que a duração não mude.

Monte o Sprint Backlog: o conjunto de itens do Backlog que é desejado estarem entregues ao término da Sprint. Inclua um pouco mais do que você acredita que o time é capaz de realizar – evitando ociosidade na hipótese de o time finalizar o trabalho antes da data.

Antes do início da Sprint, o Product Owner apresenta ao time cada item do Backlog e explica como ele/ela o vê em uma perspectiva funcional. O time discute cada um dos itens, fechando o escopo para cada um. Se possível, decompondo cada um em User Stories: framework que segue o formato “Como um ____ (tipo de usuário), eu quero ____ (funcionalidade) para que eu possa ____ (objetivo)”. A especificação em termos de User Stories é muito boa, pois permite a você dar um contexto, um sentido à cada funcionalidade – atribuindo quem vai precisar da funcionalidade e o propósito da interação do usuário com ela.


4. Sprint Planning: Tarefas

Quebre os requisitos atribuídos para a Sprint em tarefas. Exemplo? A “Home” de um Website: Documentação, Design, Desenvolvimento, Testes Unitários, Testes Gerais e Aprovação. Inclua todas as tarefas necessárias para se ter um Sprint Backlog 100% completo. Por último, traduza as tarefas em entregáveis – entregáveis são mais metrificáveis do que tarefas.

Priorize o Sprint Backlog, incluindo os sub-entregáveis definidos para cada requisito.

Agora, cabe ao time se comprometer a entregar todo o Sprint Backlog. Ao término da Sprint, esse Backlog deve constituir um produto que pode ser avaliado e manuseado por usuários.


5. Crie um espaço de trabalho colaborativo

Deixe a sala repleta de quadros brancos. Qualquer coisa que precisar ser repassada para o restante do time ou que se deseja anotar com relação ao projeto, cole na parede! Mencionamos alguns softwares que podem ajudar nessa tarefa – de exercer o papel de um Quadro Kanban – mas poucas coisas traduzem ao senso de colaboração melhor do que escrever em algo físico, dentro do ambiente de trabalho.

Crie o quadro do projeto com 5 colunas: “Product Backlog” (todos os requisitos), “A Fazer” (entregáveis a realizar na Sprint), “Fazendo” (trabalho que está sendo realizado), “Aguardando Aprovação” (aguardando aval do Product Owner) e “Feito”. Trabalhe com post-its e deixe o time livremente mover os cartões conforme o trabalho evolui.


6. Sprint!

Regras:

– Os Times tomam as próprias decisões durante a Sprint. O Scrum Master não dá instruções sobre o trabalho, mas suporte e assistência. É importante que o Time tome as decisões para se sentirem donos do que está sendo feito e assumam as responsabilidades do projeto, aumentando o engajamento.

– A duração da Sprint é fixa. Não muda. Se houve trabalho em excesso, uma pena; ele será transferido para a próxima Sprint. Se faltou trabalho, puxa pedaços do Backlog que pertenceriam à próxima Sprint. A Sprint sempre vai durar o que foi planejado para ela durar.

– Você só pode seguir para o próximo entregável uma vez que o anterior tenha sido aprovado. Feito significa “Feito.”. Para conseguir trabalhar com uma escala de tempo fixa, é imperativo que não haja retrabalho.


7. Reuniões

Diariamente – mesmo – deve ser sediado o Daily Scrum.

Essa reunião deve ser feita formando um meio circulo envolta do quadro branco da Sprint. Todo o time, Scrum Master e Product Owner devem estar presentes. É feita de forma a não tomar mais do que 15 minutos do tempo dos envolvidos e são respondidas, por cada um dos membros do Time:

1. “O que fiz? ” (Ontem-Hoje)

2. “O que vou fazer? ” (Hoje-Amanhã)

3. “Houve algum impedimento no meu trabalho? ”

O Scrum Master é o responsável por garantir que essa reunião ocorra – e ocorra bem. Além disso, é ele o responsável direto por resolver questões que surjam com as respostas da pergunta 3: os impedimentos. Se surgiram impedimentos que não permitiram um fluxo contínuo de trabalho por parte do time, cabe a ele ir atrás para resolver isso – lidando com stakeholders externos a equipe se necessário – e garantir o bom funcionamento do Scrum.


8. Acompanhe o progresso

Atualize diariamente o “Burndown Chart”: o gráfico que relaciona progresso planejado x realizado (eixo Y) em função do tempo (eixo X).

Um gráfico com o eixo Y contendo quantos pontos – colocados na priorização – você tem que estar conseguindo “abater” através do release de entregáveis, imaginando um esforço constante do Time. E um outro gráfico com o eixo Y marcando os pontos a serem cumpridos de acordo com as datas.

Dessa forma, atualizando diariamente o gráfico, tem-se uma ferramenta extremamente visual para saber se a equipe toda está adiantada, de acordo com ou atrasada quanto ao timing previsto tanto para a Sprint quanto para o projeto todo.


9. Termine quando você disse que faria

Termine toda funcionalidade antes de ir para a próxima e dê um jeito de cumprir com o planejado. Todo o time deve cooperar para atingir o maior propósito do Scrum: entregar o que fora prometido até o término da Sprint. Siga o princípio de que “feito significa feito!” Para evitar retrabalhos e para que você sempre esteja apto a poder – caso necessário – entregar o produto/projeto a qualquer momento.


10. Reveja, Reflita, Repita.

Agora que você terminou o seu trabalho durante a Sprint, está na hora das reuniões de Sprint Review (uma revisão) e Sprint Retrospective (uma retrospectiva).

A Sprint Review pode incluir todo tipo de stakeholders relacionado ao projeto externo a equipe de desenvolvimento. Ela ocorre por 3 motivos:

1. Permitir que os membros do time mostrem o que alcançaram e demonstrarem sua contribuição ao produto.

2. Permitir que todos os stakeholders vejam o que está sendo feito e providenciar um feedback pontual e regular, enquanto ainda há espaço para ajustes no produto.

3. Ajuda que todos mantenham o foco no deadline da Sprint – ninguém vai querer aparecer na reunião sem nada de útil para mostrar aos outros.


A Sprint Retrospective, por seu lado, é restrita a equipe responsável e se refere à melhoria dos processos internos e do próprio Scrum:

1. Revisite o seu Burndown Chart (gráfico de progresso) e veja as variações na produtividade do time ao longo da Sprint. Com ele e o quadro Scrum ao lado, pergunte:

2. O que deu certo? (Garanta que isso vai continuar na próxima Sprint)

3. O que poderia ter saído melhor? (Tente entender o porquê e corrigir)

4. O que faremos de diferente na próxima Sprint? (Escolha algumas ações concretas que time pode fazer e irá acarretar em melhorias de produtividade)

Pronto. Você acabou de rodar o Scrum na sua empresa. Agora, repita o processo desde o ponto 3 até esgotar todo o Product Backlog.


Fechamento

A implementação do Scrum não irá acontecer de um dia para o outro e não há uma – por mais que tenha sido dado bons guidelines acima – uma receita correta a ser seguida. Será um trabalho de constante testes, iterações, feedbacks e ajustes.

Cada empresa tem a sua cultura organizacional e, por mais que o Scrum seja um framework de trabalho que traz benefícios imensuráveis para a produtividade e engajamento da sua equipe, você, gestor, precisa avaliar se de fato a sua empresa tem sinergia com essa metodologia.

Faça o processo ser natural, mostre a todos a importância dessa ferramenta e deixe que todos colaborem com uma construção da metodologia mais apropriada a vocês e aproveite todos os benefícios que a metodologia ágil mais famosa do mundo tem a oferecer!

Leia também

Como saber se é a hora de contratar um desenvolvedor freelancer ou CLT?