Cadastre-se

Cadastre-se para acesAcesse conteúdos exclusivos que só usuários cadastrados no site tem acesso.

Fases de um projeto – As 5 etapas e suas características

O gerenciamento de um projeto vem acompanhado de grandes desafios e com o objetivo de minimizar tais desafios. Assim, projetos são normalmente divididos...
HomeProjetosAgilFramework Scrum - O que é como aplicar

Framework Scrum – O que é como aplicar

Tão importante quanto ter conhecimento dos modelos tradicionais em Gestão de Projetos é conhecer os demais meios que nos permitem atingir eficiência na condução dos projetos, como por exemplo Scrum.  Modelos Ágeis são hoje mecanismos importantíssimos para se atingir este objetivo e a finalidade deste artigo é apresentar um pouco sobre o Framework Scrum e tudo o que o mesmo pode nos oferecer.  

O Framework Scrum é simples e leve, utilizado para a gestão do desenvolvimento de produtos complexos imersos em ambientes complexos.

O Framework Scrum

Scrum é embasado no empirismo e utiliza uma abordagem iterativa e incremental para entregar valor com frequência e, assim, reduzir os riscos do projeto.

Baseia-se principalmente no empirismo, ou seja, só conhecemos algo de fato através da experiência.

O framework Scrum existe desde o início dos anos de 1990, porém somente na década seguinte se tornou popular, ganhando o mundo e desbancando métodos tradicionais, tornando-se a maneira mais comum de se trabalhar em projetos de desenvolvimento de software.

Vários são os benefícios de se utilizar Scrum, dentre eles:

  • Entregas frequentes de retorno ao investimento dos clientes;
  • Redução dos riscos do projeto;
  • Maior qualidade no produto gerado;
  • Mudanças utilizadas como vantagem competitiva;
  • Visibilidade do progresso do projeto;
  • Aumento de produtividade.

Porém, o maior benefício que pode ser destacado é a Redução do Desperdício.

De acordo com uma pesquisa realizada pela Standish Group e divulgada em 2002, época em que Scrum e Agilidade eram pouco utilizados, mostra que mais da metade das funcionalidades solicitadas pelos clientes para o projeto e produzidas nunca ou raramente eram utilizadas, caracterizando um enorme desperdício.

Gráfico Scrum de Desperdício

Framework Scrum: Product Owner

Dentro do framework Scrum o Product Owner é responsável pela manutenção do Produto, através do Product Backlog, ou Backlog de Histórias.

O Product Backlog é uma lista de requisitos funcionais e não-funcionais escritos de maneira não detalhada, contendo somente uma ou duas frases que descrevem as funcionalidades a serem desenvolvidas.

A razão de não ser detalhada é agilidade: ao invés de serem escritos e revistos em um documento de n páginas, os requisitos são discutidos entre toda a Equipe durante a Reunião de Planejamento.

Considera-se que o Backlog nunca está completo, ou seja, Histórias são adicionadas e removidas conforme necessário.

Designações

  • Gerencia o produto, inserindo, detalhando, removendo e priorizando as necessidades de negócios do produto no Product Backlog, a partir do contato frequente com os clientes do projeto e demais partes interessadas;
  • Gerencia os clientes e demais partes interessadas em sua relação como projeto, descobrindo quem são essas partes interessadas que devem influenciar as decisões sobre o produto, balanceando suas necessidades com relação ao produto, comunicando-se com elas para descobrir essas necessidades e influenciando as para maximizar sua colaboração com relação ao projeto;
  • Mantém a Visão do Produto, definindo-a junto aos clientes do projeto e demais partes interessadas, comunicando-a a todos os envolvidos e garantido que o trabalho seja realizado em direção a ela;
  • Gerencia as Releases do produto para os clientes, definindo a melhor estratégia para a realização das Releases e estabelecendo a Meta e a data de cada Release;
  • Realiza, como Time de Desenvolvimento, o planejamento do Sprint na reunião de Sprint Planning, para que juntos definam uma Meta para o Sprint e uma previsão do que será feito durante o Sprint;Colabora como Time de Desenvolvimento, sempre que necessário, para esclarecer dúvidas ou tomar decisões quanto aos detalhes do produto, e para refinar e aprimorar o Product Backlog, preparando-o para o próximo Sprint;
  • Aceita ou rejeita as entregas do Time de Desenvolvimento, verificando na reunião de Sprint Review se a Meta estabelecida para o Sprint foi atingida.

O Product Owner é:

  • Único para um Time de Scrum, pois é importante haver apenas um foco de decisões sobre o produto para o Time de Desenvolvimento;
  • Disponível para tirar dúvidas e esclarecer itens do Product Backlog para o Time de Desenvolvimento, para estar presente nas reuniões de Sprint Planning, Sprint Review e Sprint Retrospective, para interagir com os clientes e demais partes interessadas e para manter e priorizar o Product Backlog;
  • Representativo com relação ao produto, com conhecimento e poder suficiente para tomar decisões rápidas e adequadas.
Product Owner

Framework Scrum: Scrum Master

Dentro do framework Scrum, ele é o facilitador da Equipe.

O Scrum Master é responsável por interagir com o PO e com outras Equipes para remover as pendências que possam impactar o Sprint.

Não é necessariamente um líder, já que as Equipes são auto gerenciáveis, mas é importante que o Scrum Master tenha contatos com outras Equipes para agilizar a resolução de problemas.

É responsável também pelo agendamento das reuniões, pela atualização diária dos gráficos de Burndown e Burnup de cada Sprint, e de apresentar os resultados na Reunião de Revisão.

Designações

  • Facilita o trabalho do Time de Scrum, de forma que seus membros se auto organizem para que juntos desenvolvam o produto, comuniquem-se efetivamente e busquem continuamente melhorar seus processos de trabalho, realizando-o com qualidade e produtividade; além de facilitar os eventos do Scrum;
  • Remove ou gerencia a remoção dos impedimentos que atrapalham o trabalho do Time de Desenvolvimento e ajuda a prevenir que os impedimentos aconteçam, quando possível;
  • Promove as mudanças organizacionais necessárias para que o Time de Scrum possa realizar seu trabalho com efetividade;
  • Assegura que o Scrum seja compreendido e adequadamente utilizado pelo Time de Scrum.

O Scrum Master é:

  • Competente em soft skills, ou seja, possui competências comportamentais e pessoais como comunicação, facilitação e política. Ele é também corajoso, proativo e autoconfiante para realizar as mudanças necessárias, remover impedimentos e proteger o trabalho do Time de Desenvolvimento;
  • Presente sempre que o Time de Scrum necessitar dele, para observar, identificar, criar visibilidade e ajudar a resolver problemas, para remover impedimentos e para proteger o Time de Desenvolvimento de interrupções;
  • Suficientemente neutro, visando aumentar a responsabilidade e capacidade do Time de Scrum de resolver seus próprios problemas e chegar a suas próprias soluções.
Scrum Master

Framework Scrum: Time de Desenvolvimento

No framework Scrum o objetivo almejado é que a equipe seja auto-organizada, permitindo que todas as decisões sejam tomadas em grupo e sem a necessidade de uma figura de liderança que gerencie as informações e atividades.

É recomendável que o Time de Desenvolvimento tenha um número máximo de 10 pessoas – mais que isso recomenda-se quebrar a equipe em outras menores.

Cada membro do time decide quais atividades irão trabalhar durante o dia, dentro do escopo definido para cada Sprint.

Os membros decidem também como farão o pareamento, onde duas pessoas trabalham na mesma atividade, trocando experiências e soluções, e assim garantindo a Qualidade do código.

Designações

  • Planeja seu trabalho, definindo com o Product Owner o que será realizado no decorrer do Sprint, para então detalhar, de forma autônoma, como esse trabalho será realizado;
  • Realiza as tarefas de desenvolvimento do produto para atingir a Meta do Sprint, garantindo a qualidade do que é produzido, além de acompanhar seu progresso no Sprint em direção a essa Meta;
  • Interage com o Product Owner, sempre que necessário, para ter dúvidas esclarecidas ou solicitar decisões quanto ao produto, e colabora com ele para refinar e aprimorar o Product Backlog, preparando-o para o próximo Sprint;
  • Identifica e informa ao Scrum Master sobre impedimentos que obstruam seu trabalho e previne-se deles, quando possível;
  • Obtém feedback dos clientes do projeto e demais partes interessadas sobre o trabalho realizado durante o Sprint, ao apresentar e demonstrar os resultados desse trabalho ao final do Sprint;
  • Entrega valor com frequência para os clientes do projeto.

O Time de Desenvolvimento é:

  • Multidisciplinar, possuindo todas as habilidades e conhecimentos necessários para gerar, em cada Sprint, o Incremento do Produto pronto, de acordo com a Definição de Pronto;
  • Auto organizado, planejando e executando seu trabalho com autonomia, propriedade e responsabilidade;
  • Suficientemente pequeno, de forma que seus membros se comuniquem efetivamente e se auto organizem, sendo capazes de produzir Incrementos do Produto prontos que representem valor visível para os clientes;
  • Motivado, uma vez que possua o ambiente, apoio e a confiança necessários para realizar seu trabalho;
  • Orientado à excelência técnica, buscando sempre aprender e realizar seu trabalho com qualidade e consciência;
  • Focado nas metas estabelecidas junto ao Product Owner.
Time de Desenvolvimento Scrum

Sprints

Sprints são as iterações cíclicas de Atividades. Diferente da metodologia tradicional cujo ciclo demora meses ou anos, no Scrum, assim como no XP e em outras Metodologias Ágeis, as iterações são curtas, de poucas semanas.

Sprint Review

Na reunião de Sprint Review (ou revisão do Sprint), Time de Desenvolvimento e Product Owner trabalham em conjunto, com a facilitação do Scrum Master, para demonstrar o trabalho pronto, produzido durante o Sprint, a clientes do projeto e demais partes interessadas.

Seu principal objetivo é a obtenção de feedback dessas pessoas sobre o Incremento do Produto produzido, o que o Product Owner utilizará como matéria-prima para modificar o Product Backlog para Sprints futuros.

É, portanto, uma reunião de inspeção e adaptação do produto.

A reunião de Sprint Review acontece no último dia do Sprint, antes da reunião de Sprint Retrospective, e tem a duração máxima de quatro horas.

Sprint Review

Sprint Retrospective

Na reunião de Sprint Retrospective, o Time de Scrum inspeciona o Sprint que está se encerrando quanto a seus processos de trabalho, dinâmicas, comportamentos, práticas, ferramentas utilizadas e ambiente, e planeja as melhorias necessárias.

Facilitados pelo Scrum Master, Time de Desenvolvimento e Product Owner identificam o que foi bem, e que por essa razão pode ser mantido no próximo Sprint, e o que se pode melhorar, buscando as causas raízes dos problemas enfrentados no período e traçando planos de ação com formas práticas para se realizarem as melhorias.

A reunião é uma colaboração e nunca deve se configurar como trocas de acusações ou discussões improdutivas.

Sprint Retrospective

Product Backlog

No framework Scrum o Product Backlog ou Backlog do Produto é uma compilação de tudo o que o seu cliente gostaria de realizar no projeto. Pense com uma grande wishlist com todos os recursos e funcionalidades que os usuários gostariam de ver presentes no trabalho final.

Esta lista deve ser organizada pelo Product Owner de acordo com valor, risco, prioridade e necessidade.

Por natureza o backlog é algo dinâmico e muda constantemente para incluir as novas solicitações dos clientes, usuários e do mercado em si.

Desta forma os produtos são sempre aperfeiçoados em cada Sprint.

Backlog do Produto

Sprint Backlog

Certo, agora que já sabemos tudo o que precisa ser realizado, a equipe define as tarefas a serem desenvolvidas na próxima Sprint.

Esta listinha é conhecida como – surpresa! – Sprint Backlog.  O Sprint Backlog é necessariamente um afunilamento mais detalhado do Product Backlog.

Incremento

É o produto que deve estar “pronto” após a Sprint.

Pronto aqui é uma palavra relativa já que o incremento pode (e deve) ser aperfeiçoado em próximos Sprints.

Cada equipe vai definir anteriormente o que pronto significa de acordo com o contexto. É importante, no entanto, que o incremento seja algo concreto e utilizável.

Uma demo de software ou uma página que possa ser navegada pelo usuário, por exemplo.

Scrum - Incremento do Produto

Kanban

Não é tradicionalmente parte do framework Scrum mas é uma boa ferramenta de planejamento e funciona bem em conjunto com o framework.

Basicamente é um quadro – ou um app, folha de papel, parede em branco, etc – com quatro lista de tarefas: “para fazer”, “em progresso”, “esperando verificação” e “feito”.

A do Sistema Kanban é uma ótima maneira de visualizar rapidamente o status de um projeto, independentemente do uso do Scrum.

Kanban

Gráfico Burndown

O Gráfico Burndown é um artefato do framework Scrum utilizado pelas equipes para representar diariamente o progresso do trabalho em desenvolvimento.

Ou seja, após cada dia de trabalho o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado.

É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do seu ritmo de trabalho, verificando se o ritmo está adequado para atingir a meta da Sprint, cumprindo com o que foi planejado.

Gráfico Burndown

Gráfico Burnup

O gráfico de Burnup oferece informações do progresso do projeto como um todo e não apenas de um Sprint como no caso do gráfico de Burndown.

Ele mostra claramente em que ponto a equipe está (Entregas) e onde ela deve chegar.

O gráfico de Burnup demonstrado abaixo é construído sobre dois eixos: no eixo horizontal tempos o fator tempo e no eixo vertical temos o fator que representa o montante de trabalho.

Este montante de trabalho pode ser representado em pontos, medidas de esforço, horas, etc, de acordo com o que é utilizado no dia a dia de trabalho pela equipe.

Neste gráfico temos 2 linhas:

  • Azul: representa o montante de trabalho entregue ao cliente. Ou seja, representa o total de histórias (ou item do backlog) entregues ao longo do projeto;
  • Vermelha: representa o montante de trabalho que está sendo pedido pelo cliente.  Ou seja, representa o total de histórias (ou item de backlog) criadas para o projeto.

A distância entre estas duas linhas representa, a cada dia (ou outra unidade de tempo utilizada), o montante de trabalho que falta ser entregue para que se atinja o objetivo do projeto naquele momento.

Gráfico Burnup

Guia SBOK

Conclusão

Desde o seu surgimento do framework Scrum, ele tem crescido muito e sua utilização vem se tornando cada vez mais ampla na grande maioria das empresas.

Porém, o fato do framework Scrum ser muito simples, não significa que o mesmo é fácil de ser implementado.

Mudanças organizacionais e quebra de paradigmas por parte dos desenvolvedores são fundamentais para o seu sucesso.

Se você ainda se opõe a utilização de Scrum ou então persiste em olhar desconfiado, tente mudar.

Referências

  • SABBAGH, Rafael. Scrum, Gestão Ágil para Projetos de Sucesso.
Tão importante quanto ter conhecimento dos modelos tradicionais em Gestão de Projetos é conhecer os demais meios que nos permitem atingir eficiência na condução dos projetos, como por exemplo Scrum.  Modelos Ágeis são hoje mecanismos importantíssimos para se atingir este objetivo e a finalidade...Framework Scrum - O que é como aplicar

Este site utiliza cookies para melhorar a sua experiência de navegação. Ao continuar navegando, assumiremos que você consente com isso. Fique à vontade também para ler nossa Política de privacidade. Mais informação

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close