Metodologia agil scrum x pmbok

METODOLOGIAS ÁGEIS

SCRUM

Marisa Wittmann1

SCRUM

2

De onde vem o nome Scrum?

Takeuchi e Nonaka publicaram em 1986, na Harvard Business Review um estudo denominado The New New Product Development Game, baseado no rugby.

Nesse estudo os autores comparam equipes de alta performance e multifuncionais à formação scrum do jogo de rugby.

O rugby é um esporte coletivo de intenso contato físico.Um tipo de jogada chamada scrum é utilizada para o reinício do jogo. Quando na regra do jogo esta jogada é indicada, formam-se 3 linhas ordenadas de 8 jogadores de cada time.

O momento desta jogada, é de auto-organização, velocidade e urgência sendo características fundamentais que equipes de projetos devem ter quando utilizam Scrum.

Devido à analogia apresentada por eles, Jeff Sutherland e Ken Schwaber, idealizaram o framework Scrum e deram este nome.

SCRUM

3

Nos métodos tradicionais de Gerenciamento de Projetos, dá-se muita importância para as áreas :•Escopo•Prazo•Custo

Projetos entregues seguindo apenas este tripé, geralmente resultam em entregas sem valor e com pouca qualidade, causando a insatisfação do cliente.

Pelas estatísticas, visualizamos o índice de fracasso nos projetos .

Agilidade é apresentar resultados com valor agregado.

SCRUM

4

Por ser uma metodologia ágil, diversos profissionais passaram a entender que poderíamos desenvolver produtos e serviços sem documentação, sem padrão, sem cuidado e sem qualidade.

Isto não é verdade, as metodologias ágeis podem trazer muito sucesso ao projeto, e são utilizadas inclusive na indústria.

Apesar das metodologias existirem há muito tempo, foi em 2001 que um grupo formado por Kent Beck e mais dezesseis renomados desenvolvedores Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, Paulo Mourapode , assinaram o:

“MANIFESTO PARA O DESENVOLVIMENTO ÁGIL DE SOFTWARE” e o grupo foi batizado de aliança dos ágeis.

SCRUM

5

Pode ser acessado em: http://manifestoagil.com.br/ e possui a seguinte base:

Melhorar o desenvolvimento considerando as prioridades:

•Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;

•O software funcionando é mais importante do que uma documentação completa;

•A colaboração com o cliente e dos clientes está acima de apenas negociações de contratos;•Respostas a mudanças acima de seguir planos.

•Isso não quer dizer que documentação não seja importante e que os processos e as ferramentas sejam inúteis, significa que o item a esquerda é mais valorizado, apenas isto.

http://manifestoagil.com.br/

SCRUM

6

O Scrum superou a barreira de que servia apenas a área de TI para ser utilizado em por outras áreas como:

Abril DigitalAgência Goiana de Habitação S/A – AGEHABBanco FatorGlobo.comGolInstituto Nokia de TecnologiaPetrobrasSulAmérica Seguros – Saúde / AutosTRIP Linhas AereasUOLVivo

SCRUM

7

O Scrum pode e é usado em vários projetos fora do desenvolvimento de softwares.

É recomendado:

Quando mudanças são constantes;

Quando a equipe aprende sobre o produto ou serviço ao longo do projeto;

Quando a complexidade e incerteza reduzem a visibilidade do produto, negócio;

Quando a colaboração é muito importante.

SCRUM

8

Apresentação da equipe Scrum

PO - Product Owner

SM - Scrum Master

Team Development

SCRUM

9

Papel: PO - Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento.

O PO garante o ROI do projeto (Retorno sobre o Investimento)

Valor é a soma do valor do conhecimento + o valor para o cliente.

Equilibrar o trabalho reativo X o trabalho preventivo.Gerencia as expectativas dos Stakeholders

Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões.

SCRUM

10

Papel: PO - Product Owner Ele é a única pessoa responsável por gerenciar o Backlog do Produto

Expressando claramente os itens do Backlog do Produto;

Ordenando os itens do Backlog do Produto para alcançar melhor as metas e missões;

Garantindo o valor do trabalho realizado pelo Time de Desenvolvimento;

Garantindo que o Backlog do Produto seja visível, transparente, claro para todos, mostrando em que o Time Scrum vai trabalhar a seguir;

Garantindo que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

O PO pode fazer este trabalho ou delegar, porém estas atividades são de responsabilidade dele.

Scrum Master X Product Owner

11

O Scrum Master colabora com o Product Owner de várias maneiras, incluindo:

Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;

Comunicando claramente a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento;

Ensinando o Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;

Compreendendo a longo prazo o planejamento do Produto no ambiente

empírico;

Compreendendo e praticando a agilidade;

Facilitando os eventos Scrum conforme exigidos ou necessários.

Papel: SM - Scrum Master

Scrum Master X Equipe de Desenvolvimento

12

O Scrum Master serve a Equipe de Desenvolvimento de várias maneiras, incluindo:

Facilitador do trabalho.

Protege a equipe no sentido de não permitir que interfiram no trabalho da equipe.

Remove qualquer impedimento para o trabalho da equipe.

Esses impedimentos são problemas que surgem no projeto e que geralmente são externos a equipe. Ele está preocupado em perceber estes impedimentos e removê-los para que a equipe possa trabalhar. Ele não fica em cima da equipe perturbando e cobrando se o trabalho foi feito ou não.

Scrum Master X Equipe de Desenvolvimento

13

SM é o treinador, funcionando como o técnico de um time de futebol.

Treinando a Equipe de Desenvolvimento em auto gerenciamento e interdisciplinaridade;

Treinando a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

Ensinando e liderando a Equipe de Desenvolvimento na criação de produtos de alto valor;

Facilitando os eventos Scrum conforme exigidos ou necessários;

Scrum Master X Organização

14

Liderando e treinando a organização na adoção do Scrum;

Planejando implementações Scrum dentro da organização;

Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;

Causando mudanças que aumentam a produtividade do Time Scrum;

Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações.

O Scrum Master serve a Organização de várias maneiras, incluindo:

Equipe de Desenvolvimento

15

São auto organizadas.

Ninguém (nem mesmo o Scrum Master) diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;

São multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo.

Os integrantes da Equipe de Desenvolvimento recebem o título de Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa;

O time de desenvolvimento deve conter vários especialistas, porém todos os membros, inclusive os que não são especialistas, devem ser capazes de ajudar no cumprimento de qualquer tarefa. E é justamente nesse ponto que ocorre a disseminação do conhecimento entre os indivíduos da equipe, que com o tempo serão capazes de realizar tarefas que antes não eram capazes.

TIME SCRUM – Tamanho da Equipe

16

O tamanho ideal da Equipe de Desenvolvimento:deve ser pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho.

Menos de 3 integrantes na Equipe de Desenvolvimento:diminuem a interação e resultam em um menor ganho de produtividade. encontrar restrições de habilidades durante a Sprint, gerando uma equipe incapaz de entregar um incremento potencialmente utilizável.

Havendo mais de 9 integrantes:é exigida muita coordenação. geram muita complexidade para um processo de gerenciamento empírico.

Os papéis de Product Owner e de Scrum Master:não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint.

Histórias contadas pelos Stakeholders

Histórias descrevem as funcionalidades que devem gerar valor;

São as necessidades ou requisitos informados pelos cliente sobre o produto;

Algumas histórias no início do projeto são chamadas de épicos porque elas são histórias ainda muito amplas, complexas e pouco detalhadas.

STAKEHOLDERS

PO

PO: MELHORA AS HISTÓRIAS CONTADAS

PODECIDE

“lixo”

SIM

NÃO

Como funciona - SCRUM

Reunião de Planejamento da Sprint

Produto

É definidaa META ou

Objetivo

Reunião de Planejamento Reunião Diária Reunião de Revisão Reunião de Retrospectiva

ARTEFATOS DO SCRUM

EVENTOS DO SCRUM

Eventos da Sprint - SCRUM

EVENTO TIME-BOX SPRINT TIME-BOX REUNIÃO

Reunião de Planejamento da Sprint1ª. Parte: O que será PRONTO 2ª. Parte: como será PRONTO

1 mês 8hs1ª.parte : 4hs 2ª. Parte: 4hs

2 semanas 4hs1ª.parte : 2hs 2ª. Parte: 2hs

Reunião Diária 15 minutos

Reunião de Revisão da Sprint 1 mês 4hs

2 semanas 2hs

Reunião de Retrospectiva da Sprint 1 mês 3hs

2 semanas 1:30hs

1 2 3 4 5 6 7 8 9 10

1 2 3 4 5 6 7 8 9 30

1 2 3 4 5 6 7 8 9 20

P D D D D D D D D D D D D D D D D D D D D D D D D D D D D D

1 2

REV

RET

1 2

P D

SPRINT de 1 mes SPRINT

3 4

D D

19


Time Scrum trabalhando no Backlog da Sprint

Produto

Inspeção Inspeção ok?

não

Incremento

sim

A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. O propósito da Retrospectiva da Sprint é: Inspecionar como a última Sprint foi em relação as pessoas, processos e ferramentas; Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho; 20


Objetivo

A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade. Durante a reunião cada integrante da Equipe de Desenvolvimento esclarece: O que foi completado desde a última reunião? O que será feito até a próxima reunião? Quais os obstáculos que estão no caminho?

Conceito de“PRONTO”

Planejamento

Gestão do Escopo

Controle

Gestão da Qualidade

Execução

Gestão da

Qualidade

Gestão do TempoGestão da

ComunicaçãoGestão da

Comunicação

Gestão da

Comunicação

Gestão da

Comunicação

Gestão da

Comunicação

Gestão do Custo

Reunião de Planejamento

Reunião Diária

Reunião de Revisão

Reunião de Retrospectiva


21