Scrum - FM2S, Manuais, Projetos, Pesquisas de Engenharia de Processos

Baixe Scrum - FM2S e outras Manuais, Projetos, Pesquisas em PDF para Engenharia de Processos, somente na Docsity!

SCRUM

Gestão Ágil de

Projetos

Prefácio

Por que Scrum?

A primeira vez que entrei em contato com Gestão de Projetos foi em 2005, no meu estágio

num grande banco de investimentos. Eu fazia parte da área de Projetos & Processos e um dos

meus desafios era cuidar da gestão de parte de desenvolvimento dos softwares do banco,

utilizando o método tradicional, em cascata. Neste, um projeto era concluído em todos

estágios distintos e seguia, passo a passo, em direção ao lançamento para os usuários. O

processo era lento, imprevisível e, em geral, nunca resultava num produto que as pessoas

queriam ou estavam dispostas a mudar para nossa instituição para obtê-lo.

Algum tempo depois, durante o Mestrado, tive acesso ao Lean e aos ensinamentos de Deming

e pensei: por que não aplicar tais conceitos à Gestão de Projetos? Foi aí que fiquei sabendo do

trabalho de Jeff Sutherland, criador do Scrum.

Para mim, é com o Scrum que os conceitos que adotei para minha vida profissional do Sistema

Toyota se liga à Gestão de Projetos. O Scrum é semelhante aos sistemas autocorretivos,

evolucionários e adaptativos. É método científico e aprendizado no dia a dia, tornando o

projeto adequado ao que o cliente quer.

Um abraço,

Murilo F. M. Santos

Virgilio F. M. Santos

Equipe FM2S

Método em Cascata

Início do

Projeto

Requisitos do

negócio

Planejamento

técnico

Codificação e

testes

Aprovação do

cliente e

Descoberta^ lançamento

Planejamento Desenvolvimento Teste Diagramas de Gantt ou método em cascata é a maneira como as pessoas estão acostumadas a trabalhar para gerenciar projetos. É a maneira como as pessoas acham que o trabalho precisa ser feito, porque assim que aprendem a fazê-lo. As equipes de projeto, com pessoas inteligente, trabalhando por meses a fio, planejando tudo como fazê-lo costumam utilizar este método. Desenham lindos diagramas com todos os detalhes do projeto e o tempo que levariam para atingir os objetivos. Então, com uma seleção cuidadosa de cores, apresentam um fluxo que mostra cada uma das fases do projeto em cascata. Esses fluxos são chamados de Diagrama de Gantt, em homenagem a Henry Gantt, que os desenvolveu. Com o advento dos computadores pessoais na década de 1980, tornou-se bem mais fácil desenvolver diagramas complicados – e torna-los realmente complexos - , e eles se tornaram verdadeiras obras de arte. Cada etapa do projeto está detalhadamente definida; cada evento importante de se ver. O único problema com eles é que estão sempre errados. Sempre. Henry Gantt inventou esses famosos diagramas por volta de 1910. Eles começaram a ser usados na Primeira Geurra Mundial pelo General William Crozier, que era o oficial chefe do Armamento do exército americano. E por que tal ferramenta, criada lá em 1900 para a guerra é ainda hoje prática comum no gerenciamento de projetos? Não está muito claro para nós, mas apesar das guerras de trincheiras não serem mais praticadas, algumas ideias que as nortearam ainda são muito populares. Já visitei diversas empresas com funcionários cujo único trabalho é atualizar diariamente os diagramas de Gantt. O problema é que quando aquele plano elegante se depara com a realidade, ele cai por terra. Só que, em vez de descartar o plano ou o modo como pensam nele, os gerentes contratam pessoas para fazer com que pareça que o plano está funcionando.

SCRUM

SCRUM: no rúgbi o termo se refere à maneira como um time trabalha junto para

avançar com a bola no campo. Alinhamento cuidadoso, unidade de propósito,

clareza de objetivo, tudo se unindo. Trata-se de uma metáfora perfeita para o que

uma equipe deseja fazer. Jeff Sutherland

Ao começar um projeto, por que não fazer paradas regulares para verificar se o que

está sendo feito está seguindo na direção certa, e se, na verdade, os resultados são

os que as pessoas desejam? E verificar se existem maneiras de aprimorar a forma

como se está trabalhando para obter resultados melhores e executados mais

rapidamente, e quais seriam os obstáculos que impedem as pessoas de obtê-los.

Criado há vinte anos atrás, por Jeff Sutherland e Ken Schwaber, o SCRUM foi feito para ser a forma mais rápida, eficaz e confiável de criar softwares para o setor de tecnologia. A técnica é uma mudança radical das metodologias prescritivas e de cima para baixo usadas na gerência de projetos no passado; pois o SCRUM é semelhante aos sistemas autocorretivos, evolucionários e adaptativos. Depois de ter ganhado praticamente 100% do mercado de gestão de projetos de software, o SCRUM começa a ganhar a gestão dos projetos tradicionais. A técnica acolhe a incerteza e a criatividade. Coloca uma estrutura em volta do processo de aprendizagem, permitindo que as equipes avaliem o que já criaram e, o mais importante, de que forma o criaram. A estrutura do SCRUM busca aproveitar a maneira como as equipes realmente trabalham, dando a elas as ferramentas para se auto-organizar e, o mais importante, aprimorar rapidamente a velocidade e a qualidade de seu trabalho. Os resultados finais do SCRUM são equipes que melhoraram drasticamente a produtividade. Os resultados são tão drásticos que grandes empresas de pesquisa e análise, como Gartner e Standish, agora afirmam que o antigo estilo de trabalho se tornou obsoleto. As empresas que ainda insistem nas ideias já tentadas e malogradas de comando e controle e que tentam impor um nível rígido de previsibilidade estão simplesmente fadadas ao fracasso se seus concorrentes usarem o SCRUM.

Sprint Pense nos diversos projetos que você faz. Aposto que raramente você recebe um feedback até que eles estejam concluídos – e isso pode levar meses, até anos. Você pode estar seguindo na direção completamente errada durante muito tempo, sem suspeitar de nada, e isso vai acabar subtraindo uma grande parte da sua vida. Nos negócios, isso pode significar a diferença entre o sucesso e o fracasso. Já viu-se esse tipo de situação acontecer o tempo todo: uma empresa passa anos em um projeto que parecia uma ótima ideia quando os funcionários começaram, mas, quando cruzam a linha de chegada, o mercado já sofreu mudanças fundamentais. Quanto mais cedo você entregar o produto para os clientes, mais rápido eles serão capazes de dizer se você está fazendo algo de que se precisam. Os Sprints às vezes são chamados de “caixas de tempo”, porque são definidos para ter certa duração. Você não pode fazer um Sprint de uma semana e, depois, um de três semanas. Você precisa ser consistente: quer estabelecer o ritmo de trabalho no qual as pessoas saibam o que pode ser feito em determinado período. Em geral, a quantidade surpreende. Um elemento crucial de um Sprint individual, porém, é que uma vez que a equipe se compromete com o objetivo, as tarefas são bloqueadas. Nada mais pode ser acrescentado por ninguém fora da equipe. Explicarei os motivos disse mais adiante, mas, por ora, saiba apenas que interferir e distrair a equipe reduz drasticamente sua velocidade.

Dinâmica Proposta de desenvolvimento SCRUM  Reunião de Planejamento do Sprint (8 horas) - Todos  Reuniões Semanais de Acompanhamento (1 hora) - Equipe  Reuniões Diárias (15 minutos) - Equipe  Reunião de Revisão e Entrega (2 horas) - Todos SPRINT 1ª SEMANA SPRINT 2ª SEMANA SPRINT 3ª SEMANA SPRINT 4ª SEMANA Reunião de Planejamento do SPRINT Revisão do Sprint

Papéis Dono do Produto:  Ser a voz do cliente  Garantir o retorno  Definir as funcionalidades chave  Gerenciar stakeholders  Escrever as histórias dos usuários e os testes  Definir as metas É dele o papel que decide que trabalho deve ser feito. Ele é o dono da lista de pendências ( backlog ), o que está ali e, o mais importante, em que ordem. A inspiração para o dono do produto veio do papel do Engenheiro Chefe da Toyota. Esse profissional é responsável por toda uma linha de produção. Para isso, eles têm de aproveitar o talento dos grupos especializados em engenharia da carroceria, chassis, elétrica, etc. Ele precisa escolher profissionais de todos esses grupos para criar uma equipe interfuncional capaz de fazer um carro. E o mais interessante, é que eles são líderes, mas sem autoridade formal. Ninguém se reporta a eles – ao contrário: são eles que se reportam aos seus grupos. As pessoas podem dizer aos Engenheiros Chefes que eles estão errados, e então eles têm de se certificar que estão certos. Eles não fazem avaliações de desempenho, não promovem funcionários e nem dão aumentos. Mas decidem sobre o carro e como ele será feito, por consenso e não por imposição. O Dono do Produto precisa ser capaz de dar à equipe o feedback do cliente em cada um dos Sprints. Eles precisam passar metade do tempo conversando com as pessoas que estavam comprando o produto (coletando suas opiniões sobre o último lançamento e como aquilo agrega valor) e a outra metade com a equipe, criando as Pendências (mostrando a eles o que os clientes valorizaram e o que não valorizaram). Um Dono de Produto deverá possuir quatro características essenciais:

• Precisa ser bem-informado em relação ao setor. Com isso, devemos dizer duas coisas: o Dono do Produto deve entender o processo que a equipe está executando o suficiente para saber o que pode ser feito e, tão importante quanto isso, o que não pode. Mas ele também precisa entender bem o o quê o suficiente para saber como traduzir o que pode ser feito em um valor verdadeiro e significativo. Esse profissional precisa conhecer o mercado a ponto de saber o que fará a diferença.
• Deve ter o poder de tomar decisões. Assim como a diretoria não deve interferir na equipe, ele precisa ter autonomia para decidir sobre a visão de como o produto será, e o que precisa ser feito para chegar até lá. Isso é importante porque o Dono

está sob pressão de diversos stakeholders , tanto internos quanto externos, e precisa ser capaz de se manter firme. Ele deve ser responsável pelos resultados, mas permitir que a equipe tome as próprias decisões.

• Ele tem que estar disponível para a equipe, para explicar o que precisa ser feito e o porquê. Embora o Dono do Produto seja basicamente o responsável pela definição das Pendências, é necessário que haja um diálogo constante com a equipe. Em geral, o especialista da equipe informa as decisões que o Dono do Produto precisa tomar. Então, essa figura precisa ser confiável, consistente e estar disponível. Sem acesso a ele, a equipe não saberá o que fazer, e muito menos em que ordem fazer. Eles dependem do Dono do Produto para obter “a visão” e, também, para que a inteligência de mercado saiba o que é importante.
• Ele precisa ser responsável pelo valor. A avaliação do Dono do Produto é feita de acordo com a receita que gera por “ponto” de esforço. Se a equipe está produzindo quarenta pontos por semana, eu quero medir quanta receita é gerada para cada ponto. Mas a medida de valor poderia ser quantos sucessos a equipe obteve. O importante é decidir qual medida de valor será usada, e cobrar do Dono do Produto que ela seja entregue em maior quantidade. No Scrum, esse tipo de métrica é fácil de observar, por causa da incrível transparência do método. Como a tarefa do Dono do Produto é extensa, é comum em grande projetos, haver uma equipe de Donos.

Reunião Planejamento do Sprint  Preparação para reunião:  Marketing: trará as tendências de mercado e opiniões dos potenciais clientes  CRM: trará principais reclamações do clientes, principalmente aquelas que geraram ouvidoria e cancelamentos  Suporte: trará as principais reclamações, dúvidas e sugestões recebidas no mês  Implantação: trará os problemas e sugestões enfrentados pela área, ao visitar os clientes, bem como razões da baixa aderência em algum cliente  Comercial: trará motivos da não conversão de leads, reclamações e sugestões  Equipe SCRUM: trará as pendências de última reunião, horas disponíveis para o desenvolvimento e a quantidade de trabalho que foi feito no último SPRINT Ao listar o que precisa ser feito, é tentador fazer uma lista parecida com lista de casamento: igreja, flores, celebrante, noivo, noiva, etc. A questão é, se você der cada um desses itens para uma equipe separada que não esteja intimamente envolvida nos resultados das decisões tomadas entre rosas brancas e margaridas, talvez você não consiga o resultado que espera. Quantas vezes no trabalho você recebeu uma tarefa que não sabia exatamente por que deveria cumpri-la? Alguém pede a você que determine a variação das vendas mensais na Região A, analisando lojas com mais de 55 m². Você faz, mas não sabe por que isso precisa ser feito. E, por causa disso, talvez forneça o tipo errado de dados, interprete a questão erroneamente, ou talvez você apenas se ressinta de ter recebido um monte de trabalho extra. O problema é que você não está conseguindo e nem fornecendo informações suficientes para que o trabalho seja feito da maneira correta. As pessoas pensam em narrativas, histórias. É desse modo que compreendemos o mundo. Então, a primeira coisa em que você deve pensar ao considerar uma tarefa é em um personagem ou em um papel – por exemplo, um cliente, uma noiva, um leitor. Para quem a tarefa será realizada? Por meio de quais lentes precisamos olhar quando estamos construindo isso, tomando aquela decisão, ou entregando uma peça? Então, você precisa pensar no quê – no que quer que seja feito primeiro. É aqui que costumamos começar e parar. Mas é apenas o meio do processo que deveríamos estar seguindo. Depois, você precisa pensar em motivação. Por que esse personagem quer isso? Como isso vai ajudar e maravilhar esse cliente específico? E, de certo modo, essa é a parte principal. A motivação colore tudo. E antes de priorizar o que precisa ser feito em sua empresa, você precisa definir o personagem, o usuário, o cliente – a pessoa que vai usar o que você vai produzir. Você precisa saber do que gostam, do que não gostam, suas paixões, entusiasmos, frustrações e alegrias. Logo, precisa compreender as suas motivações. Como esses

tipos de personagens informam o que desejam? Por que eles precisam do que está propondo? O que eles vão fazer com isto? Isto também influenciará o modo como você faz estimativas das coisas. Eles querem uma função simples de calendário; isso é fácil. Um selo inalterável de tempo para objetivos legais – isso é um pouco mais complexo. Traga para reuniões histórias curtas. Elas devem ser curtas o suficiente para você estima-las. Imagine a história da Amazon.com: “como cliente, eu quero a maior livraria virtual do mundo para que eu possa comprar qualquer livro no instante que eu desejar”. Agora, essa história certamente engloba a Amazon, mas, na verdade, é grande demais para que possamos fazer qualquer coisa com ela. Escreva histórias que a equipes consigam compreender. Para isto, devem ser específicas o suficiente para serem práticas, mas não prescrevem como serão feitas. Lembre-se: a equipe decide de que forma o trabalho será realizado, mas o que será realizado é decidido pelo valor que traz aos negócios. Depois, faça duas perguntas: a história está pronta? Como você vai saber disso?

E como estimar? Poker do Desenvolvimento  Cada membro, tem um baralho de cartas com os números: 1 , 3 , 5 , 8 , 13 e assim por diante.  Ao analisar o esforço necessário para concluir uma tarefa, todos puxam a carta que julgam definir melhor  Se as cartas puxadas foram 5 , 8 e 13 , por exemplo, a equipe considera o esforço como a média entre as 3 cartas  Se a diferença é superior a 3 , então abre-se para a discussão sobre os motivos da diferença. Após a discussão, vota-se novamente Não estime as Pendências em horas, porque as pessoas são péssimas nesse tipo de previsão. Faça isso usando uma classificação relativa por tamanho: Pequeno, Médio ou Grande. Ou, melhor ainda, use a sequência de Fibonacci e faça estimativas de pontos para cada item: 1, 2, 3, 5, 8, 13, 21, etc.

Dinâmica  Dinâmica  O que será entregue no SPRINT Mensal? O time Scrum irá prever quais funcionalidades, solicitadas pelas áreas, podem ser desenvolvidas durante o SPRINT. Para isto, as demais áreas irão apresentar uma lista com as histórias dos itens solicitados pelos clientes e , junto do time Scrum, irão colaborar para entender o que deve ser feito para atender as sugestões levantadas. Depois, define-se a meta, que é o objetivo a ser alcançado, por meio do desenvolvimento das mudanças. Isto funcionará como guia para a equipe durante o SPRINT.  Como nós iremos escolher o que deve ser feito? Depois de definido o que deve ser entregue, o time de desenvolvimento escolho como irá entregar as funcionalidades solicitadas. Este trabalho poderá variar em tamanho ou no esforço estimado. Entretanto, deve-se planejar o trabalho para um mês, mas as atividades planejadas para a primeira semana, devem ser decompostas em tarefas que durem no máximo um dia.  Meta Sprint: qual é a meta do Sprint? dá ao time de desenvolvimento alguma flexibilidade quanto a funcionalidade a ser implementada dentro do sprint. A medida que o time Scrum trabalha, ele mantém a meta na mente.

uma reunião posterior. A ideia é obter as informações mais valiosas e práticas no menor tempo possível.

• Todos devem participar de forma efetiva. Para isto, faça com que todos fiquem de pé. Desse modo, haverá conversas ativas, onde todos falam e ouvem, e as reuniões serão curtas.
• Não trate as reuniões diárias como relatório individual “Eu fiz isso, Eu vou fazer aquilo....”. A equipe deve conversar de forma rápida sobre como poderá seguir em direção à conclusão do Sprint. A passividade não é apenas algo indolente, mas também algo que afeta o desempenho do restante da equipe. Assim que detectada, deve ser eliminada, imediatamente. Uma equipe Scrum deve ser agressiva e por isto, sair da reunião sabendo a coisa mais importante que precisam atingir naquele dia. Chame sua equipe para o ataque e pergunte se eles desejam ser horríveis ou lembrados como ótimos.

Revisão do Sprint ou Demonstração do Sprint Duração de 4 horas. Tem como função avaliar as funcionalidades criadas e adaptá-las ao backlog do produto, se necessário. Esta é uma reunião informal, e a apresentação das funcionalidades criadas tem como objetivo coletar feedbacks e estimular a colaboração. A reunião deverá incluir:

• O dono do produto:
  • Identificando o que foi feito durante o Sprint;
  • Discutindo o backlog do produto conforme ele é apresentado. Depois, projetando quando as próximas funcionalidades serão entregues, de acordo com o progresso da equipe
• A equipe de desenvolvimento:
• Discutindo o que foi bem durante o Sprint, quais problemas ocorreram e como eles foram solucionados;
• Demostrando as funcionalidades criadas e respondendo as questões feitas;
• O grupo inteiro colabora sobre o que fazer no próximo Sprint, e assim, esta reunião já prepara valiosos inputs para a reunião de planejamento mensal Resultado: backlog de produto revisado. Isto define a lista das prováveis necessidades para o próximo Sprint. Além deste input, o backlog do produto poderá ser ajudado para acomodar às novas oportunidades levantadas. Trata-se da reunião na qual a equipe mostra o que conseguiu fazer durante o Sprint. Qualquer pessoa pode participar, não apenas o Dono do Produto, o Mestre Scrum e a equipe, mas também os stakeholders , os gestores, os clientes, e qualquer outra pessoa. Esta é uma reunião aberta na qual a equipe demonstra o que conseguiu colocar na coluna Feito. A equipe só deve demonstrar o que satisfaz a Definição de Feito. O que está total e completamente concluído e pode ser entregue sem qualquer trabalho adicional. Pode não ser o produto completo, mas deve ser um atributo concluído do produto.