Scrum aplicado na gestão de projetos

Um projeto é um esforço temporário empreendido para criar um produto único, serviço ou resultado. Estas características temporária e única determinar se um esforço especial é um projeto (PMI, 2013).

O gerenciamento de projetos consiste na aplicação de conhecimentos, habilidades, ferramentas e técnicas adequadas às atividades do projeto, a fim de cumprir seus requisitos (PMI, 2013). E, é considerada a primeira camada da engenharia de software (PRESSMAN, 1995).

Com o advento do Manifesto Ágil, diversas metodologias alternativas que viviam a margem do desenvolvimento de software tradicional ganharam destaque, principalmente o Scrum.

O Scrum vem sendo utilizado para o desenvolvimento de produtos complexos e não é um processo ou uma técnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro do qual você pode empregar diversos processos e técnicas (SCHWABER, 2013).

O Scrum  é fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Sendo, apoiado em três pilares (Transparência, Inspeção e Adaptação) que sustenta qualquer implementação de controle de processos empíricos (SCHWABER, 2013).

Conteúdo do Scrum

O framework Scrum consiste em um conjunto formado por Times Scrum e seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras (SCHWABER, 2013).

Times Scrum

São projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada Time Scrum possui três papéis: 1) o ScrumMaster; 2) o Product Owner; e 3) o Time Scrum.

Eventos com Duração Fixa (Time-Boxes)

Temos a reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint.

Artefatos

Utiliza quatro artefatos principais: 1) Backlog do Produto; 2) Backlog da Sprint; 3) Burndown de Versão para Entrega 4) Burndown de Sprint.

Regras

Fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e os artefatos do Scrum.

Papéis no Scrum

O comprometimento

Figura 01 – Comprometimento do Time Scrum. Galinha: – Oi Porco, Eu estou pensando que nós devemos abrir um restaurante. Porco: – Eu não sei. Como vamos chamar? Galinha – Pode ser Bacon & Ovos. Porco – Não, obrigado. Eu estou comprometido, mas você está somente envolvido!

Scrum Master

O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum: às práticas, às regras, e ajuda o Time Scrum na organização e a adotarem o Scrum. Além disso, educa o Time Scrum treinando-os e levando-os a serem mais produtivos e a desenvolverem produtos de maior qualidade, bem como, a entender o Product Owner, o autogerenciamento e a interdisciplinaridade. No entanto, o Time Scrum é auto-organizável (SCHWABER, 2013).

Product owner

O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time Scrum. Essa pessoa mantém o Backlog do Produto e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar (SCHWABER, 2013).

Time Scrum

Os Times de desenvolvedores transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Os membros do Time frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, projeto de interface de usuário ou projeto de banco de dados. Os Times também são auto-organizáveis. Ninguém – nem mesmo o ScrumMaster – diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis. O tamanho ótimo para um Time é de cinco à nove pessoas. (SCHWABER, 2013).

Time-Boxes

Reunião de Planejamento da Versão de Entrega

O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e comunicar. O planejamento da versão para entrega responde às questões: “Como podemos transformar a visão em um produto vencedor da melhor maneira possível? Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?” (SCHWABER, 2013).

Reunião de Planejamento da Sprint

Esta é a primeira reunião, geralmente dura 8 horas, seu objetivo é fazer o planejamento da Sprint. Ela é dividida em duas partes. Na primeira parte, o Product Owner definirá prioridade, seleção dos itens do Backlog e a meta da Sprint. Na segunda parte, a equipe definirá a Sprint Backlog (quais são as tarefas necessárias para cumprir a meta). Os participantes desta reunião são: o Product Owner, Time Scrum e Scrum Master (SANTOS, 2010).

Revisão da Sprint

Esta reunião acontece no final da Sprint, geralmente dura 4 horas, outras pessoas podem ser convidadas (se necessário). O objetivo da reunião é apresentar o que a equipe fez durante a Sprint e fazer a entrega do produto (software funcionando) para o Product Owner. Ela deverá ser feita em um auditório ou em uma sala de reunião. Os participantes, desta reunião, são: o Product Owner, Time Scrum, Scrum Master e Convidados (SANTOS, 2010).

Retrospectiva da Sprint

Esta reunião acontece logo após a Revisão da Sprint, geralmente dura 3 horas. O objetivo dela é avaliar o que deu certo e que deu errado durante a Sprint e fazer os ajustes possíveis para a próxima Sprint, ou seja, o ciclo de melhoria contínua. Os participantes, desta reunião, são: o Time Scrum e Scrum Master (SANTOS, 2010).

Reunião Diária

Nesta reunião, somente membros da equipe devem participar. A duração dela é de 15 minutos. As pessoas fazem a reunião de pé. O objetivo desta reunião é fazer que as pessoas respondam a 3 questões: – O que eu fiz ontem ? – O que irei fazer hoje ? – Encontrei algum impedimento ? (SANTOS, 2010)

Artefatos do Scrum

O plano mínimo necessário para iniciar um projeto Scrum, consiste de um Documento de Visão e um Product Backlog. A Visão descreve porque o projeto está sendo implementado e o que se deseja ao seu final (SCHWABER, 2013).

Backlog do Produto (Product Backlog)

O Backlog do Produto é um lista de requisitos priorizada, contendo todos os requisitos desejados e mudanças pretendidas (? apud VASCONCELOS, 2010). É ele que reúne os requisitos funcionais e não funcionais nesta lista que prioriza os itens de maior valor para o item de menor valor definidos pelo Product Owner (? apud VASCONCELOS, 2010). O Backlog do Produto nunca está completo, ele evolui à medida que o produto e o ambiente em que ele será usado evoluem. Desta forma, percebemos que ele é dinâmico, no sentido de que está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil (? apud VASCONCELOS, 2010). É em cima do Backlog do Produto selecionado que o Time Scrum trabalhará, buscando os melhores métodos e iniciando a Sprint (? apud VASCONCELOS, 2010)

inserir figura de exemplo com a lista do Backlog do Produto.

Estórias dos Usuários (User Story)

É uma pequena descrição, que detalha um item do Product Backlog. Uma estória ajuda no entendimento e também é, utilizada como lembrete para as atividades de planejamento. Ela também permite fazer a estimativa de velocidade da equipe. Usualmente a estimativa é feita em pontos (story points) ou horas/dias (SANTOS, 2010)

Exemplo de User Story.

Estimativa e o Planning Poker

Para fazer estimativa de velocidade da equipe, antes é preciso o escrever as estórias de usuário. O Planning Poker é a “prática” que ajuda na estimativa de uma estória ou de uma tarefa.  É importante, ter em mãos o fluxo de atividades para executar uma tarefa (prototipação, modelagem de classes, modelagem de banco, codificação, teste unitário, revisão em pares e etc). Geralmente o Planning Poker usa uma escala de pontos não linear, que pode ser baseada no Fibonacci: (1,2,3,5,8,13,…) + 20, 40, 100 ou em outra escala (SANTOS, 2010).

Carta do Planning Poker

Figura 02 – Cartas do Planning Poker

Existem diversos modelos prontos para customizar as cartas do Planning Poker. Poderá baixar o modelo que utilizamos no dia-a-dia <Clique Aqui>.

Jogando o Planning Poker

Antes de começar o jogo, ou seja, definir os pontos para cada estórias, é importante definir um valor de referência. Exemplo: Identificar a estória que pode ser atribuído o menor valor (dois pontos, por exemplo), esta estória será utilizada como referência para pontuação das demais estórias (SANTOS, 2010).

Particularmente, utilizo a escala de 1 ponto por dia de trabalho, sendo alocado para cada equipe, podendo ser 4 horas, 6 horas ou 8 horas.

Backlog da Sprint (Sprint Backlog)

O Sprint Backlog consiste nas tarefas que o time executa, para transformar itens do Backlog do Produto em um incremento “pronto”, ou seja, é todo o trabalho que o time identifica como necessário para alcançar a Meta da Sprint. Portanto é feito depois da reunião de planejamento do Sprint, mas antes da primeira reunião diária do Scrum. Podemos defini-lo, em sua forma mais produtiva, como um quadro de atividades pregado na parede. No geral, aborda o Sprint BackLog como: lista de funcionalidades a serem desenvolvidas nesta Sprint; pode conter o desdobramento em tarefas; estimada pela equipe; imutável durante a Sprint (VASCONCELOS, 2010). É elaborada na segunda parte da reunião de Planejamento da Sprint (SANTOS, 2010). Conforme podemos visualizar na Figura 03.

QuadroKambam

Figura 03 – Quadro de Kamban (KNIBERG, 2007)

Burndown da Sprint (BurnDown Chart)

BurnDown Chart é uma forma prática pra fazer o acompanhamento da evolução diária das entregas do Product Backlog, pois fornece normalmente um gráfico em linha para mostrar o tamanho das entregas a partir do total selecionado para aquele Sprint ou projeto, de maneira que esse valor vá gradativamente sendo decrementado até chegar em zero (VASCONCELOS, 2010).

O gráfico Burndown é a principal ferramenta de gerenciamento do processo de desenvolvimento de software. Atualização do Burndown, deve ser diária, isto facilita a tomada de decisão, pois, poderemos decidir em melhorar a produtividade da equipe e/ou para mitigar risco da Sprint (SANTOS, 2010). Conforme podemos visualizar na Figura 03.

Pronto

Ao final de cada Sprint a equipe deverá fazer uma entrega valor para o cliente (Product Owner e demais Stakeholders). Segundo Manifesto Ágil, valor para o cliente é igual a software funcionando. Logo, para fazer tal entrega, na reunião de Planejamento da Sprint, será imprescindível estabelecer a “Definição de Pronto” (SANTOS, 2010)

Espero ter ajudado nas explicações do framework Scrum como uma excelente opção para Gerência de Projetos com equipes pequenas.

Até o próximo artigo.

Prof. Norton Guimarães
@nortoncg

Referências

KNIBERG, Henrik. Scrum e XP Direto das Trincheiras.  2007. Disponível em: <https://www.cti.ufu.br/sites/cti.ufu.br/files/scrum-e-xp-direto-das-trincheiras.pdf> Acesso em: 26 maio 2016.

PMI. Um  guia  do  conhecimento  em  gerenciamento  de  projetos.  Guia  PMBOK®  5a.  ed.  –  EUA:  Project Management Institute, 2013.

PRESSMAN, Roger S. Engenharia de Software. 3ª Ed. São Paulo: Makron Books, 1995.

SANTOS, Rildo F. SCRUM Experience. Versão 16, 2010. Disponível em: < http://www.etecnologia.com.br/scrum/Scrum%20Experience%20[O%20Tutorial%20SCRUM]%20v16.pdf > Acesso em: 26 maio 2016

SCHWABER, Ken, Guia do Scrum, 2013. Disponível em: < http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf > Acesso em: 26 maio 2016.

VASCONCELOS, MIRIAN R. S.. Gerenciando Projetos com a Metodologia Ágil SCRUM com base no PMBOK. (Graduação em Sistemas para Internet) – IF Goiano – Campus Morrinhos, 2010.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

1 thought on “Scrum aplicado na gestão de projetos

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *