01 Trabalho Acadêmico Scrum

Prévia do material em texto

UNIVERSIDADE PAULISTA - UNIP
CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
GERENCIAMENTO DE PROJETO DE SOFTWARE
SCRUM
MANAUS
2015
UNIVERSIDADE PAULISTA - UNIP
CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
Turma: 04/DS4P34
Carlos Alberto Gomes Junior – RA: B3676I-4
Jesse Oliveira da Silva – RA: C060HB-3
Jonatha Alves de Oliveira – RA: C13C1H-4
Mahilson Reis de Oliveira – RA: C10CBG-9
Pedro Alexandre Moura Rebouças – RA:C213FF2
Trabalho realizado como requisito parcial para a obtenção do título de graduação no curso de Análise e Desenvolvimento de Sistemas. Elaboração para apresentação e defesa em sala de aula para complemento da nota NP1 - Universidade Paulista – UNIP. 
Orientador: Prof.º Waterloof
MANAUS
2015
RESUMO
Este trabalho visa pôr em prática conhecimentos adquiridos no curso de Gerenciamento de Projeto de Software, onde o principal objetivo é abordar o tema Método de Desenvolvimento Ágil para processos de desenvolvimento de software, fazendo com que cada componente/aluno passe a interagir como uma equipe de trabalho disseminando o assunto e adquirindo o domínio necessário para que possamos nos habilitar junto ao processo de criação de produtos com ênfase na qualidade, cumprimento de prazos ,satisfação do cliente e assim alcançar os objetivos do projeto. 
Palavras-chave: Método, desenvolvimento Ágil, software, interagir, equipe, domínio, qualidade e prazos. 
ABSTRACT
This work aims to put into practice knowledge acquired in the course of Software Project Management, where the main objective is to address the issue agile development method for software development processes, making each component / student pass to interact as a team work disseminating it and acquiring the necessary field so we can enable with the process of creating products with emphasis on quality, timeliness, customer satisfaction, thereby achieving the project objectives.
Keywords: method, Agile development, software, interact, staff, area, quality and deadlines.
LISTA DE FIGURAS
	FIGURA 1 – REPRESENTAÇÃO SCRUM ........................................
	11
	FIGURA 2 – O SCRUM É A BASE SOBRE A QUAL OS PROCESSOS ÁGEIS SÃO CONSTRUÍDOS ....................................
	
11
	FIGURA 3 – REPRESENTAÇÃO ESQUEMÁTICA DE UMA SPRINT ...............................................................................................
	
17
LISTA DE TABELAS
	TABELA 1 – EXEMPLO DE PRODUCT BACKLOG RESUMIDO ....
	14
	TABELA 2 – TEMPO DEDICADO DIARIAMENTE À EXECUÇÃO DAS TAREFAS ..................................................................................
	
14
	TABELA 3 – DIVISÃO DO PRODUCT BACKLOG EM SPRINTS ....
	15
	TABELA 4 – DIVISÃO DE UMA TAREFA EM SUBTAREFAS .........
	16
SUMÁRIO
	1 – INTRODUÇÃO .............................................................................
	08
	1.1 – CENÁRIO ..................................................................................
	08
	1.2 – OBJETIVOS ..............................................................................
	09
	2 – EMBASAMENTO TEÓRICO ........................................................
	09
	2.1 – VANTAGENS DE SER ÁGIL ....................................................
	09
	3 – SOBRE O SCRUM .......................................................................
	10
	3.1 – UM FRAMEWORK ....................................................................
	11
	3.2 – PAPÉIS ......................................................................................
	12
	3.3 – ARTEFATOS DO SCRUM ........................................................
	13
	3.3.1 – PRODUCT BACKLOG ...........................................................
	13
	3.3.2 – O SPRINT BACKLOG ............................................................
	14
	3.3.3 – INCREMENTO DO PRODUTO ..............................................
	16
	3.4 – AS CERIMÔNIAS DO SCRUM .................................................
	17
	3.4.1 – SPRINT ..................................................................................
	17
	3.4.2 – REUNIÃO DE PLANEJAMENTO DA SPRINT ......................
	18
	3.4.3 – SCRUM DIÁRIA .....................................................................
	19
	3.4.4 – REVISÃO DA SPRINT ...........................................................
	19
	3.4.5 – RETROSPECTIVA DA SPRINT .............................................
	20
	4 – CONCLUSÃO ...............................................................................
	21
	6 – REFERÊNCIAS ............................................................................
	22
1 – INTRODUÇÃO
Segundo BOEHM (2006) uma nova abordagem para desenvolvimento de software tem despertado grande interesse entre as organizações de todo o mundo. Estamos vivendo uma tendência para desenvolvimento ágil de aplicações devido ao ritmo acelerado de mudanças na tecnologia da informação, pressões por constantes inovações, concorrência acirrada e grande dinamismo no ambiente de negócios. 
Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e consultores da área de software (batizados de “Agile Alliance” – “Aliança dos Ágeis”) assinaram o “Manifesto para o Desenvolvimento Ágil de Software” (“Manifesto for Agile Software Development”), que se inicia da seguinte maneira.
Desenvolvendo e ajudando outros a desenvolver software, estamos desvendando formas melhores de desenvolvimento e adaptação a realidade do cliente com a qualidade esperada.
Indivíduos e interações acima de processo e ferramentas.
Software operacional acima de documentação completa.
Colaboração dos clientes acima de negociação contratual.
Respostas a mudanças acima de seguir um plano.
Ou seja, embora haja valores nos itens à direita, valorizamos os da esquerda mais ainda. 
Normalmente, um manifesto é associado a um movimento político emergente: atacando a velha guarda e sugerindo uma mudança revolucionária (espera-se que para melhor). De certa forma, é exatamente do que se trata o desenvolvimento ágil.
Embora as ideias básicas que norteiam o desenvolvimento ágil tenha estado conosco por muitos anos, só há menos de duas décadas que se consolidaram como um “movimento”.
O termo Scrum foi utilizado pela primeira vez como um processo da manufatura, apresentado por Ikujiro Nonaka e Hirotaka Takeuchi em um artigo intitulado “The New Product Development Game”, publicado na “Harvard Business Review”, em 1986. Mais tarde, na década de 1990, Ken Schwaber e Mike Beedle criaram a metodologia baseando-se em suas experiências no desenvolvimento de sistemas e processos.
1.1 – CENÁRIO
No mundo da tecnologia da informação surgem novas demandas todos os dias, quem trabalha com softwares sabe da importância de estarmos sempre em busca do novo, seja ele uma nova plataforma, ferramenta ou até um novo pensamento.
Os clientes com quem trabalhamos não dominam a área, mas sabem exatamente quando um software instalado em sua empresa apresenta mau funcionamento ou simplesmente não lhe serve nas atribuições do dia a dia.
Neste sentido devemos encarar estas características como um incentivo e entregar sempre o melhor trabalho para nosso cliente, mesmo que ele por si, não saiba distinguir qual o melhor software lhe atenderá no momento. 
1.2 – OBJETIVOS
Nossa equipe tem por objetivo utilizar o método de desenvolvimento ágil Scrum como modelo para futuro gerenciamento e desenvolvimento de projetos, sendo ele um modelo bem definido e de fácil adaptação, servirá como guia de boas práticas para atingir o sucesso do projeto. 
Sabemos que o Scrum por si só não vai nos dizer exatamente o que fazer, não irá resolver todos os problemas, mais com certezaos problemas serão mais facilmente identificados.
2 – EMBASAMENTO TEÓRICO
A partir deste capítulo será estudado todo o processo que envolve os métodos relacionados ao Scrum, observando alguns dos principais conceitos e ideias para uma melhor compreensão deste método, colocando em evidência o conhecimento fundamentado de autores conceituados para concepção do tema em destaque deste trabalho.
2.1 – VANTAGENS DE SER ÁGIL
	Compreender os valores do Agile Manifesto, traz novas sugestões para a melhoria de métodos, processos e técnicas de desenvolvimento e gestão de projetos. 
	De acordo com HIGHSMITH (2014) agilidade que dizer “a habilidade de criar e responder a mudanças, buscando a obtenção de lucro em um ambiente de negócio turbulento”.
	Dentro deste contexto o uso da agilidade traz vantagens como:
	- criar um ambiente propício para definição de mudanças de requisitos e inovação durante o ciclo de desenvolvimento do produto, assim como mais colaborativo e produtivo entre desenvolvedores e cliente, resultando em entregas mais rápidas de produto, melhor adaptador à realidade do cliente e com a qualidade esperada.
	- facilita o gerenciamento do projeto, uma vez que existe maior integração e comprometimento da equipe do projeto, que consequentemente se sente mais motivada: a moral da equipe é elevada.
	- reforça o planejamento constante do projeto, o que minimiza os riscos, considerando que o planejamento é mais importante do que o plano. Não se deve parar de planejar até que se tenha encontrado a satisfação do cliente com a entrega do produto final.
	- valoriza a satisfação do cliente em primeiro lugar.
3 – SOBRE O SCRUM
	Segundo o seu autor SCHWABER (2004) o Scrum não é um processo previsível, ele não define o que fazer em toda circunstância. Ele é usado em trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de práticas que torna tudo visível. 
	O Scrum é um framework ágil que auxilia no gerenciamento de projetos complexos e no desenvolvimento de produtos. É conhecido como framework que prescreve um conjunto de práticas leves e objetivas, muito utilizadas na área de desenvolvimento de software. As práticas do Scrum também podem ser utilizadas para projetos de outra natureza, desde que possuam certo grau de complexidade, pois só assim suas práticas de inspeção e adaptação fazem sentido. 
	Ainda de acordo como SHWABER (2004) o Scrum tem como premissa a existência de um processo iterativo e incremental para o desenvolvimento, trazendo uma nova dimensão na capacidade de resposta e adaptabilidade da gestão de processos.
O nome foi inspirado em uma jogada de rugby, na qual as equipes disputam a posse de bola a partir de uma formação “Scrum”. O Scrum maximiza a entrega de software de modo eficaz, adaptando-se à realidade das mudanças. As funcionalidades de maior valor são desenvolvidas antecipadamente, equanto se reflete sobre a necessidade ou não das menos prioritárias. Se mudanças forem necessárias, a equipe ágil poderá facilmente mudar as prioridades. Sua principal motivação é o fato de que o desenvolvimento de software envolve variáveis técnicas e de ambiente como requisitos, recursos e tecnologia, que podem mudar durante o processo, tornando-o imprevisível e requerendo flexibilidade para acompanhar as mudanças. 
Figura 1 – Representação Scrum
3.1 – UM FRAMEWORK
O Scrum foi elaborado tendo como foco a resolução de problemas complexos em ambientes de alta imprevisibilidade. Essas são características bem comuns no universo de desenvolvimento de software, já que há pouca estabilidade nas tecnologias utilizadas e o trabalho a ser feito está sempre respondendo à dinâmica intensa do mercado. Ele foi estruturado como um framework, e não como uma extensa metodologia ou como “o” processo a ser utilizado, pois seria uma contradição. O Scrum é a base sobre a qual você empiricamente construirá os seu processos ágeis.
Figura 2 – O Scrum é a base sobre a qual os processos ágeis são construídos.
No início, essa estrutura do Scrum foi pouco entendida pelo mercado, gerando uma série de mitos relacionados ao framework, como os que dizem que o Scrum é fraco em documentação, é apenas para projetos pequenos, cobre apenas a “fase” de execução de um projeto, etc. No entanto, a leveza do Scrum, pela inexistência de diversos desses pontos, permite que você jugue as reais necessidades do seu ambiente e adicione o que é mais necessário para garantir a entrega de resultados dentro de uma boa gestão.
Assim, Scrum não é o seu processo, mas o framework sobre o qual construiremos os processos.
3.2 – PAPÉIS
No Scrum, a responsabilidade pela execução das tarefas no planejamento e execução é dividida em papéis, ou seja, os recursos humanos usados no projeto são organizados de acordo com o papel que cada um ocupa no projeto. As três responsabilidades principais encontradas na maioria das literaturas sobre Scrum são:
Product Owner: trata-se do dono ou proprietário do produto, o responsável pela visão de negócios do projeto. Ele define quais serão as funcionalidades esperadas para o sistema, as prioridades funcionais, isto é, o que deve ser feito inicialmente e o que pode ficar para o final do projeto. O mais comum é que esse papel seja desempenhado pelo cliente e, por isso, ele deve aprovar ou não os resultados gerados pela equipe de desenvolvimento. Em resumo, o Product Owner define as características esperadas para o produto e realiza sua aprovação.
Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência. Diferente de um líder que acompanha o projeto e “pega no pé” da equipe o tempo todo, espera-se que o Scrum Master atue mais como um agente motivador do processo, um guardião para prevenir risco e até para controlar os ânimos exagerados da equipe.
Scrum Team: trata-se da equipe responsável por desenvolver e entregar a solução do sistema, geralmente formada por um grupo pequeno e que trabalha de forma auto gerenciada, isto é, não existe a presença de um líder que direcione desenvolvimento constantemente. A ideia é que a própria equipe divida as tarefas de acordo com as habilidades e aptidões de cada um.
3.3 – ARTEFATOS DO SCRUM
Scrum possui alguns artefatos que dão uma visão do andamento do projeto e das Sprints. São eles Product Backlog, Sprint Backlog e Incremento do Produto. Embora utilizados ao longo de um projeto, esses artefatos possuem momentos de criação diferentes.
3.3.1 – PRODUCT BACKLOG
O Product Backlog se refere à lista de requisitos que o sistema a ser desenvolvido deve atender, ou seja, relação uma relação de todas as necessidades dos clientes, são os requisitos funcionais. Essa relação deve ser priorizada para que a equipe entenda as reais necessidades de utilização do sistema por parte do cliente. Durante o desenvolvimento pode ser que essas prioridades sejam alteradas. Com base nessa relação de requerimentos, a equipe pode estimar o tempo de execução das tarefas e ter uma ideia da duração do projeto. A tabela 1 apresenta o Product Backlog a seguir resumido para o caso de uma farmácia. Dizemos que é resumido porque cada item pode necessitar de uma descrição mais detalhada para compor a documentação do sistema, explicando a abrangência do item. Observamos a tabela representa a descrição de cada necessidade, a prioridade e a estimativa de tempo para sua realização. Essa tabela ajuda o time Scrum (Scrum Team) a entender a prioridade na execução das tarefas e uma boa estimativa do tempo necessário para sua execução. A tabela é meramente ilustrativa, pois cada empresa usará um modelo para se adaptar a sua realidade e necessidades.
Como em qualquer projeto, no início do desenvolvimento essa lista que compõe o Product Backlog pode ser apenas parcial, já que não existe uma ideia completa de todas as funcionalidades envolvidas. Gerenciar a venda de medicamento, por exemplo, pode envolver diversas outrassubtarefas que são decompostas em outras funcionalidades menores e integradas. Com o amadurecimento da equipe, essa lista será alterada de acordo com as novas necessidades. A composição do Product Backlog pode ser apenas modular, ou seja, são definidas apenas as partes principais às quais o produto deverá atender. Com o tempo, esses módulos podem ser mais entendidos e refinados.
	Product Backlog - prioridade e estimativas de tempo
	Item
	Prioridade
	Estimativa
	
	
	(Horas)
	Manter o cadastramento de clientes
	1
	15
	Manter o cadastramento de medicamentos
	2
	15
	Controlar o acesso por meio de login e senha
	3
	6
	Gerenciar a abertura e encerramento do caixa
	4
	5
	Gerenciar a venda de medicamentos
	5
	100
	Emitir nota fiscal eletrônica
	6
	20
	Suportar a atualização de medicamentos via Web
	7
	40
	Gerenciar o estoque, permitindo entrada e saída
	8
	40
	Emitir relatório de vendas por período
	9
	20
	Permitir a geração de relatório com os itens mais vendidos
	10
	20
 Tabela 1 – Exemplo de Product Backlog resumido.
Como demonstrado na tabela 1, podemos alocar o tempo estimado para execução de cada tarefa. Outra forma bastante comum para apresentar o tempo de execução das tarefas é distribuindo o tempo estimado durante a semana. Exemplo na tabela 2 que o tempo para execução foi dividido diariamente.
	Tarefas
	Seg
	Ter
	Qua
	Qui
	Sex
	Manter o cadastramento de clientes 
	4
	4
	4
	3
	-
	Manter o cadastramento de medicamentos
	-
	4
	4
	4
	3
	Controlar acesso por meio de login e senha
	-
	-
	-
	1
	5
Tabela 2 – Tempo dedicado diariamente à execução das tarefas
O Product Backlog será usado para gerar diversos Sprint Backlog, um grupo de funcionalidades agrupadas que serão desenvolvidas durante um sprint.
3.3.2 – O SPRINT BACKLOG
Uma vez que todas as funcionalidades esperadas foram definidas no Product Backlog, passamos a determinar os diversos sprints necessários à sua execução. Dessa forma, o Sprint Backlog contém uma lista de tarefas a serem desenvolvidas, extraídas e priorizadas de acordo com o Product Backlog.
A própria equipe pode determinar os itens que vão compor um Sprint baseado nas prioridades e estimativas de execução. A decisão dos itens que comporão o sprint normalmente é tomada por meio de uma reunião de planejamento (Sprint Planning Meeting) da qual participam o Product Owner, o Scrum Master e a equipe de desenvolvimento. Cabe ao Scrum Master acompanhar e gerenciar o andamento das tarefas de um Sprint. O tempo restante para término das tarefas pode ser calculado diariamente e apresentado em forma gráfica para o controle. Nesse momento, a equipe técnica pode entender o que deve ser feito e tirar dúvidas quando necessário.
Ao termino do Sprint outra reunião pode ser necessária para realizar a verificação e validação dos itens desenvolvidos. Nessa reunião (conhecida por Sprint Review Meeting) é feita uma retrospectiva dos pontos positivos e negativos que aconteceram no sprint. Isso é importante para que todos possam adquirir experiências para novos sprints e outros. Como muitos dizem, aprendemos como os erros e isso é uma verdade no Scrum. A cada Sprint, é feita uma retrospectiva para que erros cometidos hoje não se propaguem no futuro.
Com base no Product Backlog da tabela 1, podemos dividir todos os requisitos em três sprints conforme apresenta a tabela a seguir. 
	Sprint
	Requisitos
	1
	Manter o cadastramento de clientes
	
	Manter o cadastramento de medicamentos
	
	Controlar o acesso por meio de login e senha
	2
	Gerenciar a abertura e encerramento do caixa
	
	Gerenciar a venda de medicamentos
	
	Emitir nota fiscal eletrônica
	3
	Suportar a atualização de medicamentos via Web
	
	Gerenciar o estoque, permitindo entrada e saída
	
	Permitir a geração de relatório com os itens mais vendidos
Tabela 3 – Divisão do Product Backlog em sprints.
Essa tabela pode ser ainda mais detalhada, apresentando as subtarefas que devem ser realizadas para cada tarefa. Veja na a seguir um exemplo de detalhamento da tarefa “Controlar acesso por meio de login e senha”. Como dissemos anteriormente, cada empresa desenvolvedora segue um padrão com mais ou menos detalhes de acordo com sua necessidade.
	Tarefa
	Operações (subtarefas)
	Controlar o acesso por meio de login e senha
	Definir layout da tela
	
	Definir criptografia a ser usada no banco de dados
	
	Codificação das funcionalidades
	
	Testes de inclusão de usuários, alteração de senha e logon no sistema
Tabela 4 – Divisão de uma tarefa em subtarefas.
Para que haja sucesso na definição de cada Sprint é importante que toda a equipe de desenvolvimento participe. Quando falamos toda a equipe, não falamos apenas nos programadores responsáveis pela codificação do sistema, pois normalmente as equipes são multidisciplinares, envolvendo pessoal de arquitetura design, testes, entre outros. É importante que cada profissional apresente sua experiência e use conhecimentos para melhoria do processo.
Muito mais do que apenas listar os itens a serem desenvolvidos na reunião para a definição do sprint é importante que a equipe discuta como isso será feito, analise diferentes possibilidades. Trata-se de uma oportunidade de investigar e planejar as atividades envolvidas em cada item. “Voltando ao item manter cadastro de clientes”, no momento de implementar esse item existem diversas subtarefas envolvidas, tais como: codificação, design das telas, banco de dados, restrições de acesso, teste etc. Esse é o momento que a equipe deve usar para entender exatamente o que deve ser feito, identificar as ligações e implicações existentes entre as diferentes atividades, pois é muito mais do que apenas transformar um requisito em código. 
3.3.3 – INCREMENTO DO PRODUTO
Ao final de cada sprint, a equipe de desenvolvimento entrega um incremento do produto, resultado do que foi produzido durante a sprint. Esse é um dos conceitos principais do Scrum e vai ao encontro da sua natureza empírica, já que permite ao dono do produto perceber o valor do investimento e também vislumbrar outras possibilidades.
Para a equipe de desenvolvimento, é importante entender que o incremento deve ser algo potencialmente entregável – o cliente pode optar por colocar imediatamente em produção. A equipe, portanto, deve produzir código que tenha qualidade, e chega-se à definição de funcionalidade “pronta”. Toda a Equipe Scrum deve entender o que significa “pronto”. Uma funcionalidade somente é considerada “pronta” se tiver por todas as etapas definidas pela equipe de desenvolvimento. Uma funcionalidade que não esteja pronta ao final da sprint deve retornar ao Product Backlog para que seja incluída e uma próxima sprint.
Conforme a Equipe Scrum amadurece, é esperado que as definições de pronto (Definition of Done) se expanda para acomodar mais critérios visando à melhoria na qualidade.
3.4 – AS CERIMÔNIAS DO SCRUM
Scrum possui alguns eventos de duração fixa (time-boxed) realizadas em intervalos regulares. Cada um desses eventos é uma oportunidade para inspeção e adaptação.
3.4.1 – SPRINT
Todo o desenvolvimento em Scrum é feito de forma interativa e incremental – ciclos completos de desenvolvimento de duração fixa que, ao final resultem em incrementos potencialmente entregáveis do produto. Essas iterações são chamadas sprints.
Cada sprint tem duração de até um mês, o que permite feedbacks constantes do dono do produto quanto ao produto sendo desenvolvido. Da mesma forma, ele tem a possibilidade de analisar o que foi produzido e reorganizar o backlog do produto caso seja necessário.
Uma sprint consiste na reunião de planejamento da sprint Scrum diária, o trabalho de desenvolvimento, a revisão da sprint e a retrospectiva da sprint.
 Figura 3 – Representação esquemática de uma Sprint.
Durante a execução da Sprint, o escopo pode ser negociado entre a equipe de desenvolvimento e o donodo produto, tanto em composição quanto a contexto, conforme o conhecimento de negócio e produto evolua durante o desenvolvimento, novas tecnologias sejam criadas, etc. No entanto, não deve ser feita qualquer alteração que afete a meta da sprint.
 
3.4.2 – REUNIÃO DE PLANEJAMENTO DA SPRINT
No início de cada sprint, a equipe Scrum se reúne para planeja o que será feito naquela sprint. Essa reunião chama-se Reunião de Planejamento da Sprint e tem duração fixa de até oito horas para uma Sprint de um mês. Para Sprints menores, o tempo é reduzido de forma proporcional.
A reunião é dividida em duas partes, cada uma com duração fixa correspondente à metade da duração total. Cada parte responde às seguintes perguntas:
- O que será entregue no incremento resultante nesta sprint?
- Como faremos para entregar o incremento nesta sprint?
Na primeira parte da reunião de planejamento da sprint, a equipe de desenvolvimento faz uma previsão das funcionalidades que serão desenvolvidas durante a sprint. O dono do produto apresenta os itens do topo do Backlog do Produto à equipe de desenvolvimento, e a equipe scrum inteira colabora na definição dos intens. A quantidade de itens selecionados para a sprint, entretanto, é prerrogativa da equipe de desenvolvimento, somente ela é capaz de avaliar o que consegue realizar durante a sprint.
Uma vez selecionados os itens, a equipe Scrum define uma meta da sprint. Essa meta serve como um guia sobre o que será desenvolvido durante a Sprint e representa o compromisso firmado entre a equipe de desenvolvimento e dono do produto. 
 	Na segunda parte da reunião de planejamento da sprint, a equipe de desenvolvimento decide como transformará os itens selecionados em um incremento durante a sprint. Eles se coordenam para decompor os itens em unidades de um dia ou menos, o suficiente para pelo menos os primeiros dias da sprint.
	Os itens selecionados mais o plano para o desenvolvimento do incremento dão origem ao Backlog da Sprint.
 3.4.3 – SCRUM DIÁRIA
Diariamente a equipe de desenvolvimento se reúne por no máximo 15 minutos, período em que cada membro responde aos outros membros:
- O que fiz desde a última Scrum Diária?
- O que pretendo fazer até a próxima Scrum Diária?
- Existe algo me impedindo de concluir alguma tarefa?
Esse formato geral de uma Scrum Diária, também conhecida como Reunião Diária. Como a equipe de desenvolvimento trabalha de forma colaborativa, essa reunião permite que os membros se comuniquem e sincronizem seu trabalho. Como os grupos auto organizados, a reunião não tem como objetivo qualquer tipo de relatório, nem para o Scrum Master, nem para o Dono do Produto, nem para ninguém, somente para eles mesmos.
Scrums diárias fazem parte do ciclo de inspeção e adaptação de Scrum. Por meio da análise diária do andamento da sprint, a equipe de desenvolvimento pode corrigir imediatamente algum problema no processo.
 
3.4.4 – REVISÃO DA SPRINT
	Ao final da sprint temos outra cerimônia de Revisão da Sprint. Pode participar dela quem quer que esteja interessado no produto, além da Equipe Scrum.
	Embora essa cerimônia também seja utilizada para demonstrar as novas funcionalidades feitas durante a Sprint, seu principal objetivo é o de inspecionar o que a equipe de desenvolvimento produziu e colher opiniões e impressões dos presentes para caso seja necessário adaptar o plano para a sprint seguinte. Então seu foco é o aprimoramento do produto.
	Na revisão da Sprint, o dono do produto válida ou não as entregas da sprint, de acordo com a meta acordada com a equipe de desenvolvimento durante a reunião de planejamento da sprint. A equipe de desenvolvimento discute sobre a Sprint, o que correu bem, os problemas enfrentados e as soluções encontradas e, após a demonstração, reponde às perguntas dos presentes. Também é nesse momento, quando necessário, que será atualizado qualquer artefato utilizado para determinar o progresso atual do projeto.
3.4.5 – RETROSPECTIVA DA SPRINT
O último evento de uma sprint é a retrospectiva e ocorre imediatamente após a revisão da sprint. Participam dessa reunião todos os membros da equipe Scrum, e seu foco é o aprimoramento do processo e a interação entre os membros da equipe de desenvolvimento, as práticas e ferramentas utilizadas, o que funcionou e o que precisa ser melhorado na próxima sprint. Além de identificar problemas, é importante também identificar medidas a serem tomadas para a melhoria do processo para as próximas sprint.
Como o objetivo é a melhoria do processo, os membros da equipe de desenvolvimento não devem encarar a crítica como algo pessoal, mas aceitar que há problemas na equipe e que eles precisam se auto organizar, com a ajuda do Scrum Master na busca por uma solução. 
 
4 – CONCLUSÃO
Agilidade é a forma prática para alcançar altos níveis de inovação em projetos. Usar o Scrum parece ser simples, e de fato é simples. O grande desafio encontrado não é o de usar as boas práticas do Scrum e sim deixar o time, o cliente e a nossa empresa prontos para receber as mudanças de paradigmas que a metodologia ágil exige. 
Usar Scrum no projeto nos ajuda a construir somente o que o cliente valoriza e não mais do que isto, criando produtos melhor adaptados a sua realidade.
REFERÊNCIAS
Furgeri, Sérgio. Modelagem de Sistemas Orientado a Objetos, 1ª Ed., São Paulo: Editora Érica, 2013, p.45, 46, 47, 48, 49 e 50.
Pressman, Roger S. Engenharia de Software, 7º Ed., Porto Alegre AMGH, 2011, p.95 e 96.
PFLEEGER, Shari Lawrence. Engenharia de software. São Paulo: Prentice Hall, 2004.