SCRUM
Alunas:
Líbia de Souza Boss
Libni de Souza Boss
Rayanne Moraes dos Santos
Engenharia de Software – TADS 03
Profº: Tiago Lacerda
Métodos ágeis – O Manifesto ÁgilMétodos ágeis – O Manifesto Ágil
Em 2001, um grupo de 17 profissionais se reuniu visando otimizar a forma de construir software. A partir deste encontro, surgiu o termo agile (ágil) e um conjunto de quatro valores básicos:• Indivíduos e interações são mais importantes que processos e
ferramentas.• Software funcionando é mais importante do que documentação
completa e detalhada.• Colaboração com o cliente é mais importante do que
negociação de contratos.• Adaptação a mudanças é mais importante do que seguir o
plano inicial.Fonte: www.agilemanifesto.org
Princípios Ágeis
Satisfação do cliente através da entrega rápida e frequente de produto funcional.
Produto funcional é a principal medida de progresso do projeto.
Mudanças são vistas como parte natural do processo e são bem-vindas.
Cooperação diária entre a equipe de projeto e o pessoal de negócio.
Comunicação aberta dentro da equipe. Equipe de pessoas motivadas, com o suporte necessário e confiança. Atenção contínua para o bom design e excelência técnica. Simplicidade. Nada de desperdícios! Foco maior nas pessoas do que nos processos. Melhoria contínua.
Scrum definição:
SCRUM é um processo iterativo e incremental para o desenvolvimento de projetosIncentiva a comunicação e o constante trabalho de equipe
O seu objetivo é entregar o
máximo de valor de negócio
no menor tempo
Como surgiu o Scrum?
A metodologia Scrum, desenvolvida por Ken Schwaber e Jeff Sutherland nasceu da necessidade de encontrar uma metodologia que abordasse o problema do desenvolvimento de software de uma forma não tradicional, em que tal como num jogo de Rugby, a equipe age como um todo para atingir os seus objetivos.
A equipe e o comprometimento
Comprometimento x Envolvimento
Os membros do Time Scrum são chamados “porcos”. Qualquer outra pessoa é chamada de “galinha”. “Galinhas” não podem dizer aos “porcos” como eles devem fazer seu trabalho.
O que é a Sprint ?
Sprint é a iteração (ciclo) de desenvolvimento• Reunião de Planejamento da Sprint• Trabalho de Desenvolvimento• Revisão e Retrospectiva da Sprint
Cada Sprint deve ter uma Meta
Tem duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra• Duração deve contemplar horizonte curto suficiente para
que mudanças não alterem a Meta
ScrumMaster deve assegurar que não seja feita nenhuma mudança que afete a Meta da Sprint
Scrum: processos
TIMEBOX• Conceito do SCRUM que “obriga” que eventos sejam
realizados periodicamente
Cerimônias do Scrum
Reunião de Planejamento
Feita a cada início da Sprint;Participantes: Product Owner, Scrum Master e Equipe;Dividida em duas partes: 1 – O Product owner detalha os itens prioritários do Product Backlog.
2 – Os membros do time detalham cada item priorizado pelo Product Owner, planejando o que será feito na Sprint.
Revisão da Sprint
Feita ao término da Sprint; É demonstrado o que foi feito na sprint; Sugestões podem ser feitas, cabendo ao Product Owner
adicioná-las ao Product BackLog Participantes: Product Owner, Scrum Master e Equipe;
Cerimônias do Scrum
Cerimônias do Scrum
Retrospectiva da Sprint
Feita logo após a Sprint Review (Revisão da sprint);É demonstrado o que foi bem na sprint e o que deve ser melhorado na próxima sprint;Participantes: Scrum Master e Equipe;
Cerimônias
Reunião de Planejamento da Sprint (8 horas)
Reunião Diária (15 minutos) Revisão da Sprint (4 horas*) Retrospectiva da Sprint (3
horas*)
Artefatos - Product Backlog
Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto.
Exemplo de Product Backlog: Sistema de Reserva On-Line
Estimativa e o Planning Poker
Porque o Planning Poker funciona? Porque apresenta múltiplas opiniões quanto a estimativa de um item; Porque estimula o dialogo entre os membros do Time durante as
rodadas; Porque estudos mostram que estimativas feitas em grupo são mais
bem sucedidas que estimativas individuais;
Definição de “Feito” (DoD):
Feito, para desenvolvedor: Encerrou a codificação...
Feito, para Analista de Teste: Quando ele encerrou o teste e não encontrou nenhum bug...
Feito, para PO: Quando foi entregue...
Feito, para os usuários finais e/ou clientes: Quando o software começou a funcionar em ambiente de produção...
Artefatos - Sprint Backlog
Sprint Backlog é uma lista de tarefas que a equipe se compromete a fazer em uma Sprint.
Quadro de Acompanhamento Task Board - Kanban
Tendo as atividades da Sprint Backlog planejadas, prepara-se o quadro de acompanhamento
Artefatos - Burndown
Gráfico que mostra a evolução da equipe dentro de um determinado Sprint. Mede-se: quantidade de horas em tarefas X dias úteis do Sprint
Gráfico que mostra a evolução do Projeto ao longo de finalizações de Sprints. Mede-se: quantidade de pontos de Sprint X Sprints finalizados.
Ciclo do Scrum
BACKLOG DO PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O representante do cliente, o PRODUCT OWNER, levanta com o cliente requisitos mais prioritários no momento
Ele então insere estes requisitos em uma lista priorizada, chamada BACKLOG DO PRODUTO
A equipe então se reúne com o representante do cliente e decide, a partir dessa lista de requisitos, o que será feito no próximo ciclo de desenvolvimento: o BACKLOG DA SPRINT
A equipe faz o trabalho no ciclo de desenvolvimento, chamado de SPRINT
Vantagens
Os papéis são bem definidos, todos têm conhecimento sobre as suas responsabilidades;
É um processo ágil e flexível, tornando melhor a reação as mudanças que ocorrem durante o projeto;
É focado no controle e gerenciamento, buscando minimizar os riscos e maximizar a qualidade;
Os times são pequenos, a comunicação é mais eficiente; Espírito colaborativo.
Desvantagens
Necessita a associação de uma outra metodologia de Engenharia de Software, por exemplo XP;
Monitoração constante por parte do gestor, que deverá estar disposto a efetuar alterações e mudanças constantemente;
É difícil de ser implementada, principalmente devido a resistência de mudanças culturais.
Conclusão
Concluindo, Scrum vê o desenvolvimento de software de forma empírica. Se o cliente viver durante mais de um mês, ele vai mudar de idéias. Se um projeto durar mais do que um mês, os requisitos iram mudar e o desenvolvimento terá de se adaptar a essas mudanças. É infrutífero perder tempo, esforço e dinheiro planejando um projeto no seu início se não podemos esperar que o mundo pare enquanto trabalhamos nele.
O software nunca está completamente definido em sua fase embrionária. Então porque tratar o desenvolvimento de software como um processo definido? Assim sendo, Scrum se resume em duas palavras: Bom Senso.
Bibliografia
www.agilemanifesto.org http://pt.wikipedia.org/wiki/Scrum http://www.agilealliance.org/article/articles_by_categor
y/17 http://www.codeproject.com/KB/architecture/scrum.as
px Tutorial SCRUM Experience, Rildo F. Santos, versão
17.
Top Related