Scrum

Prévia do material em texto

SCRUM
Rafael Oliveira
Lucas Lima
Marília Pereira
Carlos Bianor
1º Sérgio Santos
Prefácio
Vivemos em um ótimo período de adoções de Agilidade em diferentes organizações
Assuntos ligados à Agilidade estão sendo discutidos
O grande catalisador desse movimento é o Scrum
Período de riqueza e qualidade de Adoções Scrum; Hoje em dia é possível ver os … nos mais diferentes níveis dentro dela(agilidade)
1º Sérgio Santos
Introdução
Como era antes ?
War Room no final do Projeto
Manifesto Ágil
1º Sérgio Santos
Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Por mais que o Scrum forneça ferramentas e maneiras de se conduzir o desenvolvimento ele não pode ser considerado uma metodologia.
A diferença entre metodologia e framework é que uma metodologia fornece praticamente tudo que é necessário para condução de um projeto. Ela é mais completa que um framework, já que diz o que fazer e como fazer. Já o framework apenas indica qual a trajetória, mas não indica exatamente como fazer, existindo a possibilidade de ser empregado juntamente com outros processos e técnicas. Funciona praticamente como um "esqueleto", que fornece uma estrutura básica como suporte.
Sergio S
1º Sérgio Santos
Ken Schwaber & Jeff Sutherland
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
Neste tipo de jogo, existe uma formação compacta onde os jogadores se unem tentando chutar a bola que foi jogada para eles.
Sergio S
Métodos Ágeis - Ordem Cronológica
Conceito de Projeto
“Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. ”
1º Sergio Santos
O que é Scrum ?
Muito discutido na comunidade Ágil
1º Sergio Santos
Significado de Scrum
O termo Scrum surgiu do rugby. No jogo a palavra scrum descreve a formação ordenada dos jogadores em determinados momentos da partida. A inspiração aqui vem da união que equipes esportivas necessitam para vencer o jogo.
Sergio S
Metodologia ou Framework ?
Muito discutido na comunidade Ágil
1º Sérgio Santos
Scrum como Metodologia
Como metodologia ela nos fornece praticamente tudo que é necessário para a condução do projeto
É mais completo que um Framework
Nos diz o que fazer e como fazer
Por mais que o Scrum forneça ferramentas e maneiras de se conduzir o desenvolvimento ele não pode ser considerado uma metodologia.
A diferença entre metodologia e framework é que uma metodologia fornece praticamente tudo que é necessário para condução de um projeto. Ela é mais completa que um framework, já que diz o que fazer e como fazer. Já o framework apenas indica qual a trajetória, mas não indica exatamente como fazer, existindo a possibilidade de ser empregado juntamente com outros processos e técnicas. Funciona praticamente como um "esqueleto", que fornece uma estrutura básica como suporte.
1º Sérgio Santos
Scrum como Framework
Nos indica a trajetória
Não nos indica como fazer
Empregado juntamente com outros processos e técnicas
Funciona como um “esqueleto”
Por mais que o Scrum forneça ferramentas e maneiras de se conduzir o desenvolvimento ele não pode ser considerado uma metodologia.
A diferença entre metodologia e framework é que uma metodologia fornece praticamente tudo que é necessário para condução de um projeto. Ela é mais completa que um framework, já que diz o que fazer e como fazer. Já o framework apenas indica qual a trajetória, mas não indica exatamente como fazer, existindo a possibilidade de ser empregado juntamente com outros processos e técnicas. Funciona praticamente como um "esqueleto", que fornece uma estrutura básica como suporte.
1º Sérgio Santos
O Framework
Muito discutido na comunidade Ágil
R
O Framework
O framework de desenvolvimento ágil Scrum traz consigo de uma forma simples, porém consistente, uma gama de boas práticas ágeis que contribuem para esse desenvolvimento mais ágil.
O Scrum é um framework simples para gerenciar projetos complexos.
Quanto mais conhecemos os requisitos e as tecnologias usada, mais previsíveis são as atividades necessárias para realizar o projeto. Podemos usar metodologias com processos bem definidos como a Cascata.
Quanto menos conhecemos os requisitos ou a tecnologia é mais complexa temos um cenário caótico. É nesse cenário que o Scrum é melhor aplicado.
O Framework
É comum adeptos do Scrum utilizarem com proveito técnicas de outras metodologias ágeis, como o Taskboard(Kanban), Pair Programming(XP) entre outras. Por ser um framework, isso é perfeitamente natural.
O framework Scrum é um conjunto de valores, princípios e  práticas que fornecem a base para que a sua organização adicione suas práticas particulares de engenharia e gestão e que sejam relevantes para a realidade da sua empresa. O resultado será uma versão de Scrum que é exclusivamente sua.
Os ciclos de desenvolvimento são curtos, de no máximo 30 dias, e por este motivo, o feedback do cliente se torna mais constante já durante a fase de desenvolvimento do produto, tornando seu desenvolvimento mais assertivo e alinhado com as necessidades do negócios do cliente.
Mecânica e ciclo do Scrum
Muito discutido na comunidade Ágil
Ciclo do Framework Scrum
Ciclo Scrum – Fonte: http://www.knowledge21.com.br/sobreagilidade/scrum/como-e-o-scrum/inicio-projeto/
Ciclo Scrum
Como o SCRUM é baseado em ciclos (os chamados Sprints, que veremos em detalhes mais a frente), a cada iteração do produto, tem-se um incremento resultante e no final deste ciclo de iterações, tem-se o produto final.
Esta abordagem iterativa tem uma grande vantagem no ciclo de vida de um projeto pois, os clientes (encomendantes do projeto) podem ter contato com os itens que vão sendo resultantes da evolução do projeto (cada incremento) o que gera credibilidade e maior participação dos futuros usuários do produto final que está sendo criado (no caso, pode ser um novo software de computador). Isso potencializa as chances de sucesso no projeto.
No SCRUM, clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída).
Importante citar também que, 3 pilares sustentam a implementação de controle de processos SCRUM.
Pilares do Scrum
Transparência dos processos, requisitos de entrega e status
Inspeção constante de tudo que está sendo feito
Adaptação, tanto do processo, quanto do produto a mudanças
Práticas do Scrum
Product Owner (dono do produto)
É o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos.
É responsabilidade dele manter e comunicar a todos os outros participantes uma visão clara do que a equipe Scrum está buscando alcançar no projeto. Como tal, ele é responsável pelo sucesso global da solução.
Para garantir que a equipe construa rapidamente o que o Product Owner precisa, ele deve colaborar ativamente com o ScrumMaster e equipe de desenvolvimento e deve estar disponível para responder às perguntas tão logo estas são feitas.
Product Owner (dono do produto)
Representa a voz do cliente
Responsável pela visão de negócios do projeto 
É quem define e prioriza o product backlog (lista com a priorização e as demandas do produto)
Geralmente, é o papel desempenhado pelo cliente
Scrum Master
O ScrumMaster é responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum.
Ela age como um Coach, executando a liderança do processo e ajudando a equipe Scrum (e o resto da organização) a desenvolver suaprópria abordagem do Scrum, que tenha a melhor performance, respeitando as particularidades da organização.
O ScrumMaster também tem um papel de facilitador. Ele deve ajudar a equipe a resolver problemas e fazer melhorias no uso do Scrum. Ele também é responsável por proteger a equipe contra interferências externas e assume um papel de liderança na remoção de impedimentos que podem atrapalhar a produtividade.
Scrum Master
É uma mistura de gerente, facilitador e mediador
Seu papel é remover impedimentos e obstáculos da equipe e assegurar que as práticas de SCRUM estejam sendo executadas adequadamente de modo a se atingir os objetivos
É o responsável pela aplicação das regras
Time Scrum
No desenvolvimento tradicional de software são abordados vários tipos de trabalho, tais como: arquiteto, programador, testador, administrador de banco de dados, Designer, e assim por diante.
No Scrum é definido o papel do Time de Desenvolvimento, que é simplesmente a junção de todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.
A idéia principal é que a equipe de desenvolvimento se auto-organiza para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner.
Claro, scrum pode também ser usado em projetos que exigem equipes muito maiores. No entanto, ao invés de ter uma equipe Scrum com, digamos, 30 pessoas, seria melhor ter entre 3 ou mais times scrum, cada um com um time de 9 ou menos pessoas.
Time Scrum
Responsável por entregar a solução
Geralmente, é composta por um grupo pequeno (entre 5 e 9 pessoas) e que trabalha de forma auto-gerenciada
Com habilidades multifuncionais, fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc)
Atividades e Artefatos Principais
Product Backlog
O Product Owner, com ajuda do resto da equipe Scrum e as partes interessadas, é o responsável por determinar e gerir a seqüência deste trabalho e comunicando-o na forma de uma lista de prioridades conhecida como o Product Backlog. O Product Owner,  em conjunto com as demais partes interessadas no produto, definem os itens do Product Backlog.
Em seguida, ele garante que os itens do Backlog são colocadas na seqüência correta (usando fatores como valor, custo, conhecimento e risco), de modo que os itens de alto valor, aparecerá no topo do backlog do produto e os itens de menor valor aparecer em direção ao fundo.
O Product backlog é um documento que está constantemente evoluindo. Os itens podem ser adicionados, excluídos e revisto pelo Product Owner por conta de mudanças nas condições de negócios, ou conforme a compreensão da equipe Scrum sobre o produto aumenta.
Em geral a atividade de criar e de refinar os itens do product backlog, estimando o tamanho e esforço de cada item, é chamada de Grooming.
Product Backlog
É uma lista de itens priorizados a serem desenvolvidos para um software
Todas as funcionalidades ou mudanças no produto são definidas no Product Backlog
O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente 
O Product Backlog pode ser alterado a qualquer momento pelo Product Owner
Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado em questão
Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint (ciclo)
Sprints
No Scrum, o trabalho é realizado em iterações ou ciclos de até um mês de calendário chamado de Sprints.
O trabalho realizado em cada sprint deve criar algo de valor tangível para o cliente ou usuário. Sprints são timeboxed (duração fixa) para que tenham sempre um início e fim data fixa, e, geralmente, todos eles devem estar com a mesma duração.
Sprints
Durante o Sprint, os itens do Product Backlog que devem ser entregues são então tratados no Sprint Backlog. 
Cada Sprint (ciclo) normalmente leva de 2 a 4 semanas para ser executada, esse período é chamado de Time Box.
As tarefas agora são responsabilidade da Equipe que tem autonomia para decidir como elas devem ser executadas
O Sprint backlog é uma lista de itens selecionados do Product backlog  e ela contém as tarefas que serão realizadas durante o próximo sprint para implementar os itens selecionados
Ciclo da Sprint
Sprints Planning (planejamento de sprint)
O product backlog pode representar muitas semanas ou até meses de trabalho, o que é muito mais do que pode ser concluído em um único e curto sprint.
Para determinar quais os subconjuntos de itens do Product Backlog mais importantes para construir no próximo sprint, o product owner, junto com o time de desenvolvimento e ScrumMaster, devem realizar o Sprint Planning (planejamento de sprint).
Durante o planejamento do sprint, a equipe de desenvolvimento e o product owner devem chegar a um acordo sobre qual o Objetivo do Sprint.
Com este objetivo em mãos, eles determinam quais os itens do backlog devem ser priorizados para serem executados neste Sprint.
A maioria das equipes Scrum que estão realizando Sprints de duas semanas a um mês de duração tentam completar o planejamento do sprint em cerca de 4 a 8 horas.
Um sprint de uma semana não deve tomar mais do que 2 horas para planejar.
Daily Scrum
Todos os dias, idealmente no mesmo horário, os membros da equipe de desenvolvimento devem realizar uma reunião com tempo definido (15 minutos ou menos), chamado Daily Scrum.
Esta reunião também é muitas vezes chamada de Stand-Up Meeting, por causa de uma prática recomendada para que a reunião seja feita em pé (com a intenção de fazer com que a reunião seja rápida, 15 minutos é o ideal).
Daily Scrum
Uma abordagem comum nesta reunião é o Scrum Master perguntar para cada membro da equipe três perguntas:
Três Perguntas básicas da Reunião Diária
	O que fiz ontem que ajudou o time a atingir a meta do sprint?
	O que vou fazer hoje para ajudar o time a atingir a meta do sprint?
	Existe algum impedimento que não permita a mim ou ao time atingir a meta do sprint?
Ao responder a estas questões, todos conseguem visualizar de uma maneira geral como está progredindo o trabalho do Sprint em direção à meta.
Burndown Chart
O gráfico de Burndown mostra visualmente a soma das estimativas dos esforços restantes do Backlog ao longo do tempo e, permite também uma comparação com os atuais trabalhos realizados.
Apesar de não fazer parte do Scrum, é muito utilizado para acompanhamento dos Sprints.
Kanban Board
Também não faz parte do Scrum, mas o Scrum pode se beneficiar muito do Quadro de Kanban para promover a gestão a vista e a transparência.
A ideia é poder visualizar o fluxo de trabalho que está sendo feito, pode ser feito com softwares específicos ou com um quadro.
Definition of Done (Definição de Pronto)
No Scrum nós consideramos como resultado do Sprint produto ou funcionalidade concluída.
Para saber quando, e como, uma parte do produto ou funcionalidade deve ser considerada concluída nós utilizamos um documento chamado Definition of Done.
Embora, isso varie significativamente de um extremo ao outro para cada time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho está completado no incremento do produto.
Sprint Review (Revisão do Sprint)
O objetivo desta atividade é verificar e adaptar o produto que está sendo construído.
Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.
No final do Sprint, a Equipe demonstra os resultados para o Product Owner e para os demais interessados, de modo que os itens do Backlog sejam considerados prontos e então possa se dar início a um novo Sprint.
Deve-se rever o trabalho que foi concluído e não concluído. Um trabalho incompleto não pode ser demonstrado.
Sprint Retrospective (Retrospectivado Sprint)
Enquanto o objetivo do Sprint Review é verificar necessidades de adaptações no produto, o Sprint Retrospective tem como objetivo verificar necessidades de adaptações no processo de trabalho.
Todos os membros da equipe refletem sobre a sprint passada, com finalidade de aprendizado. Fazem então, melhorias contínuas de processos.
Questões principais que são feitas na retrospectiva do sprint:
O que correu bem durante a sprint?
O que poderia ser melhorado na próxima sprint?
Revisão Scrum
Product Backlog – Uma lista de itens priorizados a serem desenvolvidos
Time Box – Período de 2 a 4 semanas de desenvolvimento
Sprint backlog – Tarefas selecionadas do product backlog para serem realizadas no timebox.
Sprint Planning Meeting – Reunião de todos os envolvidos onde será definido o sprint backlog.
Burndown Chart – Gráfico de linhas que representam a conclusão dos backlogs e a estimativa até o fim do sprint.
Daily meeting – Reuniões diárias de 15 minutos realizadas de pé para programação do dia: O que foi feito ontem? O que será feito hoje ? Quais os impedimentos ?
Sprint Review – Reunião de apresentação dos backlogs completos para o product owner ao final do sprint.
Sprint Retrospective – Reunião da equipe sobre reflexões do sprint passado com finalidade de aprendizado
http://www.mindmaster.com.br/scrum/
http://www.devmedia.com.br/introducao-ao-scrum/33724
http://www.desenvolvimentoagil.com.br/scrum/
http://gerenciandoriscosemprojetos.com/gerenciando-projetos-com-scrum/
http://www.devmedia.com.br/introducao-ao-scrum/33724
http://www.devmedia.com.br/scrum-xp-e-manifesto-agil-como-a-agilidade-lida-com-a-complexidade/29568/
Links de pesquisa