O QUE É SCRUM

Prévia do material em texto

O QUE É SCRUM?
Scrum é um framework de gerenciamento de projeto ágil leve usado principalmente para desenvolvimento de software. Ele descreve uma abordagem iterativa e incremental para o trabalho de projeto.
Visão geral do Scrum Framework
Scrum pode ser usado em todos os tipos de desenvolvimento de software: para desenvolver pacotes de software completos, para desenvolver apenas algumas partes de sistemas maiores, para projetos internos ou de clientes.
O Scrum Framework implementa as pedras angulares definidas pelo manifesto ágil:
Indivíduos e interações sobre processos e ferramentas
Software trabalhando mais que documentação abrangente
Colaboração do cliente sobre negociação de contrato
Respondendo a alterações ao seguir um plano
O Scrum Framework em si é muito simples. Ele define apenas algumas diretrizes gerais com apenas algumas regras, papéis, artefatos e eventos. No entanto, cada um destes componentes é importante, serve a um propósito específico e é essencial para uma utilização bem sucedida do quadro.
Os principais componentes do Scrum Framework são:
Os três papéis: 
Scrum Master, 
Scrum Product Owner, 
Scrum Team
Um Backlog priorizado contendo os requisitos do usuário final
Sprints
Eventos Scrum: 
Reunião de Planejamento Sprint (Reunião WHAT, Reunião HOW), 
Reunião Diária Scrum, 
Reunião Sprint Review, 
Reunião Retrospectiva Sprint
Importante em todos os projetos Scrum é a auto-organização e comunicação dentro da equipe. Não há mais um gerente de projeto em um sentido clássico. No Scrum Framework, o Scrum Master eo Scrum Product Owner compartilham suas responsabilidades. No entanto, no final, a equipe decide o que e o quanto eles podem fazer em uma dada iteração do projeto (Sprint).
Outro aspecto central no Scrum Framework é a melhoria contínua: inspecionar e adaptar. As Equipes Scrum têm de inspeccionar e avaliar frequentemente os seus artefactos e processos criados, a fim de os adaptar e optimizar. A médio prazo, isso otimizará os resultados, aumentará previsivelmente e, portanto, minimizará o risco geral do projeto.
O Scrum Framework tenta lidar com o fato de que os requisitos são susceptíveis de mudar rapidamente ou não são completamente conhecidos no início do projeto. Os requisitos de baixo nível são definidos apenas no momento em que eles vão ser realmente implementado. Em Scrum, as alterações e otimizações de produtos, requisitos e processos são parte integrante de todo o ciclo de engenharia.
Outra pedra angular do Scrum Framework é a comunicação. O Scrum Product Owner trabalha em estreita colaboração com a Scrum Team para identificar e priorizar a funcionalidade. Essa funcionalidade é anotada em histórias de usuário e armazenada em um Scrum Product Backlog. O Product Backlog consiste em tudo o que precisa ser feito para entregar com sucesso um sistema de software de trabalho.
A Equipe Scrum tem o poder de selecionar apenas as histórias de usuários que têm certeza de que podem concluir dentro de 2-4 semanas de Sprints. Como a equipe Scrum é autorizado a cometer seus próprios objetivos, eles serão mais motivados e trabalhar com melhor desempenho possível. O Scrum Master é outro papel importante no Scrum Framework, pois funciona como um servidor-mestre com a Scrum Team. Suas principais tarefas são fazer com que a equipe do Scrum entenda como o Scrum opera, proteger a Equipe Scrum de interrupções externas e remover os impedimentos que impedem o Scrum Team de atingir sua máxima produtividade.
O Scrum Framework em sua forma simples é melhor usado para projetos menores, de uma equipe. Mas com a introdução de papéis adicionais como o "Chief Scrum Product Owner"
INTRODUÇÃO AO SCRUM - UM EXEMPLO DO MUNDO REAL
Antes de iniciar o primeiro Sprint
Alex é designado como o Proprietário do Produto Scrum de um novo projeto de desenvolvimento de software. Uma de suas primeiras tarefas é iniciar engenharia de requisitos. Ele escreve os casos de uso mais importantes e os discute com os arquitetos, representantes de clientes e outras partes interessadas. 
Depois de coletar os casos de uso de alto nível e requisitos, ele os grava no Scrum Product Backlog e inicia uma sessão de estimativa e priorização com os arquitetos e alguns desenvolvedores sênior. Como resultado desta sessão, todos os itens do Scrum Product Backlog têm uma estimativa aproximada inicial e uma priorização. Agora ele começa a quebrar os requisitos de alto nível em histórias de usuário de menor porte. Com esta lista, ele então convoca para a primeira reunião de Planejamento Sprint.
Introdução ao Scrum - um exemplo de mundo real em várias fases Scrum e sprints
Sprint 1 - Dia 0
Durante a reunião de planejamento Sprint Alex apresenta os itens Scrum Product Backlog da prioridade mais alta para o mais baixo. A equipe esclarece perguntas abertas e para cada item a equipe discute se eles têm capacidade suficiente, o know-how necessário e se tudo o mais necessário está disponível. Após esta discussão se comprometem a completar as histórias 1,2,3,6,7 e 8 até o final deste sprint. Os itens 4 e 5 não podem ser realizados neste sprint, uma vez que alguma infra-estrutura técnica ainda não está no lugar.
Após a reunião de planejamento Sprint Frank - o Scrum Master da equipe - chama a equipe para definir os detalhes de como os itens comprometidos serão implementados. As tarefas resultantes são escritas para baixo nos cartões na placa Sprint Task preparada. Agora, todos os Scrum Team seleciona uma tarefa para trabalhar.
Sprint 1 - Dia 1
Na parte da manhã, toda a equipe se reúne para o Daily Scrum Meeting. Todos dão uma breve declaração sobre o que foi alcançado até agora, atualiza a estimativa de horas restantes nos cartões da Sprint Task board, diz o que ele ou ela está planejando fazer hoje e diz se há algum impedimento que o impede de continuar seu trabalhos. Hoje, um dos membros da equipe diz que ele tem problemas, porque ele precisa de uma nova licença para uma das ferramentas de software que ele está usando. Frank verifica se outros membros da equipe têm o mesmo problema e diz que vai cuidar disso depois da reunião. Depois de 15 minutos, todos voltam ao trabalho.
Após a reunião Frank atualiza o Sprint Burndown. Depois ele chama o fornecedor de software da ferramenta, ordena licenças e os encaminha para as pessoas que precisam deles.
Sprint 1 - Dia 2
Na manhã seguinte, toda a equipe se reúne para a reunião do Daily Scrum. À tarde, um dos membros da equipe Scrum não tem certeza sobre os detalhes de uma das histórias de usuários. Ele chama Alex -Scrum Product Owner- e discute os pontos abertos com ele. Depois que o membro da equipe descobre o que fazer, então ele pode continuar com sua implementação.
Sprint 1 - Dia 28
Este é o último dia do primeiro Sprint e Frank -Scrum Master - convidou a equipe para a Sprint Review Meeting. A equipe preparou uma máquina com a implementação de software atual. Alex -Scrum Product Owner- fica na frente da máquina e verifica se a implementação atende às suas expectativas e se os recursos são documentados conforme necessário. No final da Sessão de Revisão conclui:
As histórias 1,2,6 e 7 terminam como esperado.
História 3 não poderia ser concluído no tempo e não foi apresentado em tudo.
História 8 tem alguns pontos que têm de ser re-factoring.
À tarde, a equipe se reúne para a Reunião de Retrospectiva Sprint e discute o que correu bem durante o sprint eo que poderia ser melhorado. Um dos comentários é que a equipe tem a sensação de que eles não sabem o suficiente sobre a arquitetura do sistema global. Frank leva a tarefa de convidar o arquiteto do sistema para dar uma introdução mais detalhada.
Sprint 2 - Dia 1
Alex -Scrum Product Owner - acrescenta novos itens ao Scrum Product Backlog com base em suas recentes reuniões com clientes. Além disso, ele adiciona itens adicionais para o re-factoring da história 8. Alex, em seguida, convida a equipe para a Sprint Planejamento Reunião para Sprint 2. A equipe discute e se compromete a histórias com a orientação de Frank-Scrum Master- e começa a segunda Sprint .
O QUE FAZ FALHA O MODELO DE DESENVOLVIMENTO DE SOFTWARE DE WATERFALL DE MUITAS MANEIRAS?
Estudos têm mostrado que em mais de 80% dos projetos de software investigados e falhados, o uso da metodologia Waterfall foi um dos principais fatores de falha. Mas por que?
Fases no Modelo de Desenvolvimento de Software de Cachoeira Clássica
Como mostrado acima, ao implementar a metodologia de cachoeira há uma estrita cadeia seqüencial das diferentes fases do projeto. Uma fase anterior deve ser concluída antes de iniciar a próxima fase. Voltando é na maioria dos casos difícil, caro, frustrante para a equipe e demorado.
O cronograma do projeto está planejado no início. Um produto liberável é entregue apenas no final do cronograma do projeto. Se uma fase é retardada todas as outras fases também são atrasadas.
Para evitar isso, os usuários da metodologia da cachoeira normalmente tentam antecipar todas as possibilidades de antemão. Isso significa que em uma das primeiras fases do projeto eles tentam definir todos os requisitos como finos e completos possível. Contudo, Exigência em uma fase tão inicial do projeto é muitas vezes muito difícil e, portanto, muitos requisitos mudam (ou devem mudar) ao longo do projeto. Estudos têm mostrado que em projetos maiores e complexos cerca de 60% dos requisitos iniciais são alterados ao longo do projeto. Outros requisitos são implementados como definidos mas não são realmente necessários pelo cliente e consomem tempo valioso que poderia ter sido melhor usado para implementar funcionalidade com maior valor agregado para o cliente.
A separação em diferentes fases do projeto força os usuários a estimar cada fase separadamente. O problema é que a maioria dessas fases normalmente não são separadas. Eles estão trabalhando juntos e em paralelo.
A abordagem de cascata para o desenvolvimento de software pode ser usado para a implementação de projetos pequenos e simples.
O QUE FAZ A ESTRUTURA DO SCRUM SUCEDER?
A estrutura Scrum altera o triângulo clássico de gerenciamento de projetos. O compromisso já não está entre tempo, orçamento e qualidade. Agora está se tornando o triângulo de Orçamento, Tempo e Funcionalidade.
Triângulo de Gerenciamento de Projetos A qualidade
não é mais uma opção. No Scrum, os fatores que definem quando um recurso está completo (em termos de qualidade, testes necessários, documentação, etc.) são definidos pela Diretiva de Doação (DoD) no início do projeto. Nenhum recurso incompleto ou não testado será liberado para o cliente. Agora, a funcionalidade a implementar será definida ao longo do curso do projeto e implementada de forma incremental. Este desenvolvimento incremental permite permanecer flexível e mudar de forma controlada sem os custos adicionais e os riscos de comprometer grandes pedaços de trabalhos anteriores. No final de cada incremento (Sprint) está disponível um resultado que pode ser mostrado e discutido com o cliente para obter e incorporar feedback o mais rapidamente possível.
Como esta flexibilidade não se aplica apenas aos requisitos de software, mas também aos próprios processos operacionais, o Scrum Framework permite otimizar o uso de recursos (tempo, orçamento) e minimiza o desperdício.
Estudos têm demonstrado que Scrum tem seguintes efeitos positivos na prática:
Produtividade aumentada
Melhor qualidade do produto
Custos reduzidos ou estáveis do projeto após a introdução de métodos ágeis
Maior satisfação do cliente
Maior satisfação e motivação dos colaboradores
Assim, mesmo se introduzir e usar o Scrum Framework às vezes não for trivial, a abordagem flexível e iterativa do Scrum Framework facilita o gerenciamento da complexidade e melhor lida com o fato de sempre mudar os requisitos do cliente e do negócio. Assim, Scrum é na maioria dos casos uma alternativa melhor às metodologias clássicas.
SCRUM ROLES - A EQUIPE SCRUM
Dentro do Scrum Framework três funções são definidas:
A equipe Scrum
Scrum Master
Proprietário do produto Scrum
Cada um destes papéis tem um conjunto definido de responsabilidades e só se eles cumprirem essas responsabilidades, interagir de perto e trabalhar juntos, eles podem terminar um projeto com sucesso.
Scrum Roles & Stakeholders
Equipe Scrum
Dentro do Scrum Framework, todo o trabalho entregue ao cliente é feito por Equipes Scrum dedicadas. Uma equipe Scrum é uma coleção de indivíduos que trabalham juntos para entregar os incrementos de produtos solicitados e comprometidos.
Para trabalhar eficazmente, é importante para uma equipe Scrum que todos dentro da equipe
Segue um objetivo comum
Adota as mesmas normas e regras
Mostra respeito uns aos outros
Ao configurar uma nova equipe Scrum sempre tem que ter em mente que nenhuma nova equipe vai entregar com o maior desempenho possível desde o início. Depois de configurar a equipe tem de passar por certas fases como descrito pelo modelo de Tuckman: Formação, Storming, Norming, Performing.
Quanto tempo demora até que o Scrum Team esteja em Performing Phase depende da equipe, e no entanto normalmente leva cerca de 3 Sprints até que as equipes estejam maduras o suficiente para entregar seus resultados de forma previsível.
Modelo Tuckman 
Características de um Scrum Team
Scrum As equipes sempre têm as seguintes características:
Os membros da equipe compartilham as mesmas normas e regras
A equipe Scrum como um todo é responsável pela entrega
A equipe Scrum está capacitada
Ele está trabalhando tão autônomo quanto possível
A equipe Scrum é auto-organizadora
As habilidades dentro da equipe Scrum são equilibradas
Uma equipe Scrum é pequena e não tem sub-equipes
As pessoas dentro da equipe Scrum trabalham em tempo integral na equipe
As pessoas são colocadas
Regras & Normas
Claro que seu ambiente define algumas das normas que as equipes têm que seguir, mas algumas regras e normas são desenvolvidas durante a fase de Norming. Este conjunto de regras comuns é muito importante. Caso contrário, os membros da equipe teriam que perder constantemente tempo valioso para alternar entre diferentes sistemas de valores e conjuntos de regras. Exemplos dessas normas e regras são:
Hora e local da Reunião Diária do Scrum
A Definição de Feito (DoD) usada para decidir se o trabalho está terminado ou não
Diretrizes de codificação
Ferramentas para usar
Responsabilidade 
A equipe Scrum como um todo é responsável por entregar a entrega comprometida em tempo e com a qualidade definida. Um bom resultado ou uma falha nunca é atribuído a um único membro da equipe, mas sempre o resultado da equipe Scrum.
Empowerment & Self organisation
O Scrum Team tem de ser capacitado para definir
O que ele vai se comprometer a entregar no final do sprint
Como os resultados esperados têm de ser divididos em tarefas
Quem executará a tarefa e em que ordem eles serão executados
Somente se a equipe de Scrum for autorizada a decidir essas coisas, ela funcionará com a motivação e o desempenho mais alto possível.
Conjunto 
equilibrado de habilidades Indivíduos dentro da equipe Scrum certamente terão habilidades especializadas e foco. No entanto, para obter o melhor desempenho possível, seria ótimo ter um conjunto equilibrado de habilidades. Somente então a equipe de Scrum será capaz de lidar com os desafios em constante mudança e pode agir como autônomo como é possível.
Por um lado isso significa que uma equipe Scrum deve ser multidisciplinar (desenvolvedores, testador, arquitetos etc) desde o início. Por outro lado, isso também significa que cada membro da equipe deve aprender um pouco da especialização um do outro, por exemplo A se necessário para finalmente atingir o objetivo comprometido um desenvolvedor também deve executar ou escrever testes.
Como conseqüência, isso também significa que dentro do Scrum Framework não é diferenciado entre, por exemplo, "testador" e "arquiteto", todos eles compartilham o mesmo título "Scrum Team Member" mesmo se a habilidade principal não for desenvolver código de produção.Tamanho do Scrum Team
Scrum As equipes são pequenas. O tamanho ideal é de 7 +/- 2 pessoas.
Se houver mais pessoas, a sobrecarga de comunicação fica muito grande ea equipe deve ser dividida em várias equipes Scrum. Essas equipes Scrum devem ser coordenadas e comunicar entre si, mas de outra forma funcionam de forma independente.
Colocação
Para minimizar a sobrecarga de comunicação desnecessária cada Equipe Scrum deve ser colocada. Se o trabalho tiver que ser distribuído em vários locais, as equipes Scrum independentes devem ser criadas. 
Responsabilidades da Equipe Scrum 
A Equipe Scrum e cada um dos membros da equipe tem certas responsabilidades que devem ser cumpridas:
Eles têm que dividir os requisitos, criar tarefa, estimá-los e distribuí-los. Em outras palavras, isso significa que eles têm que criar o Sprint Backlog.
Eles têm que realizar a curta reunião diária Sprint.
Eles têm de garantir que no final da funcionalidade Sprint potencialmente enviado é entregue.
Eles têm de atualizar o status e os esforços restantes para suas tarefas para permitir a criação de um Sprint Burndown Diagrama.
O mestre do SCRUM
Broad fala é o trabalho do Scrum Master para garantir que o Scrum Team adere à teoria Scrum, práticas e regras.
O Scrum Master faz parte da Scrum Team e atua como um servo-líder para a Scrum Team. No início, este será um trabalho em tempo integral para que o Scrum Master não possa contribuir diretamente para os resultados da Sprint. No entanto, após alguns Sprints os processos irão resolver de modo que a carga de trabalho para o Mestre Scrum vai cair e ele poderia contribuir activamente para o Sprint Goal.
Uma vez que é crucial que haja confiança entre o Scrum Master e os outros membros da equipe, seria ideal se a Scrum Team selecionasse o próprio Scrum Master. No entanto, na realidade, a maioria das vezes o Gerenciamento seleciona o Scrum Master. Para obter a confiança necessária, o Scrum Master não deve ter nenhuma responsabilidade de gerenciamento de linha para um dos membros da equipe. Caso contrário, a necessária comunicação aberta e descoberta de decisão serão dificultadas.
Responsabilidades do Scrum Master
O Scrum Master tem várias responsabilidades importantes:
Proteja a equipe Scrum de solicitações externas e interrupções
Agir como agente de mudança e adaptar processos para maximizar a produtividade da equipe
Treine a equipe Scrum
Remover os impedimentos para a equipe Scrum
Garantir uma comunicação eficiente entre o Scrum Team e o Scrum Product Owner
Facilitar os vários eventos Scrum
Para efetivamente fazer isso, um número de habilidades são úteis:
Moderação
Coaching
Desenvolvimento de know-how
Protegendo o Scrum Team / Removendo impedimentos 
Um trabalho importante do Scrum Master é proteger os membros da equipe de "solicitações urgentes". O Gerenciador de Linha ou o Proprietário do Produto Scrum tentará frequentemente atribuir solicitações novas, não planejadas e não comprometidas à equipe ou aos membros individuais da equipe. No entanto, um dos aspectos-chave do Scrum é que todos os deliverables e work-packages são conhecidos e comprometidos pela Scrum Team antes da Sprint e que a Scrum Team pode trabalhar 100% nestes deliverables. O trabalho do Scrum Master é discutir tais pedidos e adiar a solicitação até o próximo sprint iniciar ou cancelar o sprint atual e start-over.  
Os desenvolvedores dentro da equipe Scrum devem concentrar-se apenas no desenvolvimento do valor do cliente através da entrega de funcionalidade potencialmente enviável. O Scrum Master ajuda removendo os impedimentos que bloqueiam ou impedem o desenvolvimento. Exemplos poderiam ser a organização de reuniões, esclarecimento de perguntas ou realização de trabalho de apoio.
Agente de Mudança
Uma das pedras angulares do Scrum Framework é a melhoria contínua através da inspeção e adaptação. O Mestre Scrum hospeda e modera a Reunião Retrospectiva Scrum e seu trabalho é, então, para facilitar a mudança das deficiências identificadas.
Facilitação de Eventos Scrum 
O Scrum Framework define várias reuniões que têm de ser organizadas e facilitadas pelo Scrum Master: Agente de Mudança Uma das pedras angulares do Scrum Framework é a melhoria contínua através da inspeção e adaptação. O Mestre Scrum hospeda e modera a Reunião Retrospectiva Scrum e seu trabalho é, então, para facilitar a mudança das deficiências identificadas. Facilitação de Eventos Scrum O Scrum Framework define várias reuniões que têm de ser organizadas e facilitadas pelo Scrum Master: Agente de Mudança Uma das pedras angulares do Scrum Framework é a melhoria contínua através da inspeção e adaptação. O Mestre Scrum hospeda e modera a Reunião Retrospectiva Scrum e seu trabalho é, então, para facilitar a mudança das deficiências identificadas. Facilitação de Eventos Scrum O Scrum Framework define várias reuniões que têm de ser organizadas e facilitadas pelo Scrum Master:
Reuniões Diárias do Scrum
Reuniões de planejamento da Sprint
Reuniões de Revisão da Sprint
Reunião Retrospectiva da Sprint
PROPRIETÁRIO DO PRODUTO SCRUM
O Scrum Product Owner é um papel central no Scrum Framework. A maioria das responsabilidades do gerente de produto clássico e do gerente de projeto são combinadas dentro deste único papel.  
Ele representa o cliente final e / ou outras partes interessadas e é responsável por maximizar o valor do produto, garantindo que o trabalho certo é feito no momento certo.
Como conseqüência, isso significa que o Proprietário do Produto Scrum deve trabalhar em estreita colaboração com a Equipe Scrum e coordenar suas atividades durante toda a vida do projeto. Ninguém mais tem permissão para dizer à equipe de desenvolvimento para trabalhar de um conjunto diferente de prioridades.
O Proprietário do Produto Scrum tem várias responsabilidades:
Gerenciando a Backlog do Produto Scrum
Gerenciamento de liberação
Gerenciamento de partes interessadas
Trabalhar em estreita colaboração com a equipa Scrum
É claro que o Proprietário do Produto Scrum pode delegar certas atividades (como manter fisicamente o Scrum Product Backlog), mas no final ele continua sendo responsável.
Gerenciando o Backlog do Produto Scrum 
O Scrum Product Owner é a única pessoa autorizada a gerenciar o conteúdo do Backlog do Produto Scrum. Isso significa que ele tem que:
Criar, manter e descrever claramente os itens Scrum Product Backlog
Priorizar os itens para melhor atingir os objetivos e missão
Garantir que a Equipe Scrum compreenda os itens no Scrum Product Backlog
Gerenciamento de Liberação
O Proprietário do Produto Scrum é responsável por alcançar os objetivos do projeto. Ele cria e mantém o plano de lançamento e decide sobre entregas, funcionalidades e, portanto, sobre os custos de um projeto. 
Ele gerencia a equipe Scrum por criação e priorização de itens Scrum Backlog apropriados. 
Gestão das partes interessadas 
Os intervenientes externos não devem comunicar directamente com a equipa Scrum. Em vez disso, o Proprietário do Produto Scrum deve coletar e discutir as funcionalidades necessárias com os diferentes Stakeholders (por exemplo, cliente, marketing, serviço, etc.). Esses requisitos são então combinados e filtrados antes de entregá-los à equipe sob a forma de Itens de Backlog de Produto Scrum priorizados. Trabalhar em estreita colaboração.
com a equipa Scrum 
Para um projecto bem sucedido, é importante que o Scrum Product Owner e a Scrum Team trabalhem em conjunto de perto. Ele é responsável por que todos na Equipe Scrum compreendam o que é necessário. 
O Proprietário do Produto Scrum também é responsável por verificar e aceitar os resultados da Sprint durante a sessão de revisão da Sprint.
COMO O QUADRO DO SCRUM TRABALHA SEM GESTOR DE PROJETO?
Em um projeto tradicional normalmente um gerente de produto define os requisitos. A realização é então delegada a um gerente de projeto e ele coordena todas as atividades necessárias para realizar o projeto. 
O Scrum Framework não define um "gerente de projeto" no sentidoclássico, embora essas atividades sejam obviamente necessárias. No Scrum Framework, as responsabilidades de um gerente de projeto são distribuídas pelas funções do Scrum Product Owner e Scrum Master. 
A definição do papel e das responsabilidades do Scrum Master leva em conta que as decisões sobre funcionalidade, plano de lançamento e custos podem ser feitas muito mais fácil e melhor se uma pessoa é responsável pelo conteúdo e pelo planejamento. Caso contrário, haverá sempre uma tensão entre o Proprietário do Produto Scrum (não responsável pelo projeto) e o gerente do projeto (não responsável pelo conteúdo). Se estas responsabilidades são combinadas tudo será muito mais fácil. 
No entanto, o Scrum Master assumirá algumas das responsabilidades de um gerente de projeto tradicional. Acompanhar as tarefas dentro de um Sprint e resolver os impedimentos estão dentro de sua responsabilidade. Como ele faz parte da equipe Scrum, é muito mais fácil e muito mais eficiente lidar com esses tópicos diretamente na equipe. Acompanhar as tarefas dentro de um Sprint e resolver os impedimentos estão dentro de sua responsabilidade. Como ele faz parte da equipe Scrum, é muito mais fácil e muito mais eficiente lidar com esses tópicos diretamente na equipe. Acompanhar as tarefas dentro de um Sprint e resolver os impedimentos estão dentro de sua responsabilidade. Como ele faz parte da equipe Scrum, é muito mais fácil e muito mais eficiente lidar com esses tópicos diretamente na equipe.
O SCRUM BACKLOG DO PRODUTO
Na definição mais simples, o Scrum Product Backlog é simplesmente uma lista de todas as coisas que precisam ser feitas dentro do projeto. Ele substitui os tradicionais artefatos de especificação de requisitos. Esses itens podem ter natureza técnica ou podem ser centrados no usuário, por exemplo, na forma de histórias de usuários. O proprietário do Scrum Product Backlog é o Scrum Product Owner. O Scrum Master, a Scrum Team e outras partes interessadas contribuem para que ele tenha uma ampla e completa lista de Tarefas. 
Trabalhar com um Scrum Product Backlog não significa que a Scrum Team não tem permissão para criar e usar outros artefatos. Exemplos de artefatos adicionais podem ser um resumo das várias funções de usuário, descrições de fluxo de trabalho, diretrizes de interface de usuário, storyboards ou protótipos de interface de usuário. Contudo, Esses artefatos não substituem o Scrum Product Backlog, mas complementam e detalham seu conteúdo. 
O Scrum Product Owner usa o Scrum Product Backlog durante a Sprint Planning Meeting para descrever as principais entradas para a equipe. A equipe de Scrum determina então que artigos podem terminar durante o sprint de vinda. 
Cada Backlog de Produto Scrum tem certas propriedades que o diferenciam de uma simples lista de tarefas:
Uma entrada no Scrum Product Backlog sempre adiciona valor para o cliente
As entradas no Scrum Product Backlog são priorizadas e ordenadas de acordo
O nível de detalhe depende da posição da entrada no Scrum Product Backlog
Todas as entradas são estimadas
O Scrum Product Backlog é um documento vivo
Não há itens de ação ou tarefas de baixo nível no Scrum Product Backlog
Exemplo Scrum Product Backlog 
Apenas entradas que adicionam valor
Cada entrada no Scrum Product Backlog deve ter algum tipo de valor para o cliente. Entradas sem qualquer valor do cliente são pura resíduos e não deve estar presente de qualquer maneira. O Scrum Product Backlog pode incluir entradas para a exploração das necessidades do cliente ou várias opções técnicas, uma descrição dos requisitos funcionais e não funcionais, o trabalho necessário para lançar o produto e outros itens, como a criação do ambiente ou a reparação de defeitos . Algumas tarefas podem não adicionar valor direto à funcionalidade. No entanto, podem acrescentar valor aumentando a qualidade ou reduzindo os incidentes a longo prazo. Documento 
Vivo 
O Backlog do Produto Scrum é alterado ao longo de todo o projeto. Se necessário, Novos requisitos são adicionados e os requisitos existentes podem ser modificados, definidos com mais detalhes ou até mesmo excluídos. Requisitos não são mais congelados no início. Em vez disso, o conjunto final de requisitos no Scrum Product Backlog também é desenvolvido iterativamente, juntamente com o software resultante. Isso é diferente da engenharia de requisitos tradicional, mas permite maximizar o valor do cliente e minimiza o esforço de desenvolvimento. 
Nível diferente de detalhes 
Os requisitos do Scrum Product Backlog têm uma granularidade diferente. Apenas os requisitos que devem ser implementados durante um dos próximos sprints são definidos em maior detalhe e tudo o resto é mais grosseiro. A razão simples para isso é que não faz sentido investir tempo e esforço na especificação desses requisitos, Como a maioria desses requisitos terá mudado de qualquer maneira até a implementação começa. 
Nenhuma tarefa de baixo nível 
O Backlog do Produto Scrum não deve conter as informações detalhadas sobre o requisito. Idealmente, os requisitos finais são definidos em conjunto com o cliente durante o sprint. A repartição e distribuição destes requisitos é da responsabilidade da equipa Scrum. 
O Backlog do Produto Scrum está ordenado 
Todas as entradas são priorizadas eo Backlog do Produto Scrum é solicitado. O Scrum Product Owner com a ajuda da Scrum Team faz a priorização. Valor Agregado, Custos e Riscos são os fatores mais comuns para priorização. Com esta priorização, o Proprietário do Produto Scrum decide o que deve ser feito em seguida. 
Todas as entradas são estimadas 
Todas as entradas dentro do Scrum Product Backlog têm de ser estimadas de acordo com a definição acordada (por exemplo, pontos da história). Essa estimativa pode ser usada para priorizar entradas no Scrum Product Backlog e planejar lançamentos. Trabalhando 
com o Backlog 
O backlog precisa de atenção e cuidados regulares - ele precisa ser gerenciado com cuidado. No início do projeto, a equipe Scrum e seu Scrum Product Owner começam por escrever tudo o que podem pensar facilmente. Isso é quase sempre mais do que suficiente para um primeiro sprint. 
Após esta configuração inicial, o Scrum Product Backlog tem de ser mantido em um processo contínuo que compreende as seguintes etapas: Essa estimativa pode ser usada para priorizar entradas no Scrum Product Backlog e planejar lançamentos. Trabalhando com o Backlog O backlog precisa de atenção e cuidados regulares - ele precisa ser gerenciado com cuidado. 
No início do projeto, a equipe Scrum e seu Scrum Product Owner começam por escrever tudo o que podem pensar facilmente. Isso é quase sempre mais do que suficiente para um primeiro sprint. Após esta configuração inicial, o Scrum Product Backlog tem de ser mantido em um processo contínuo que compreende as seguintes etapas: Essa estimativa pode ser usada para priorizar entradas no Scrum Product Backlog e planejar lançamentos. Trabalhando com o Backlog O backlog precisa de atenção e cuidados regulares - ele precisa ser gerenciado com cuidado. 
No início do projeto, a equipe Scrum e seu Scrum Product Owner começam por escrever tudo o que podem pensar facilmente. Isso é quase sempre mais do que suficiente para um primeiro sprint. Após esta configuração inicial, o Scrum Product Backlog tem de ser mantido em um processo contínuo que compreende as seguintes etapas: No início do projeto, a equipe Scrum e seu Scrum Product Owner começam por escrever tudo o que podem pensar facilmente. Isso é quase sempre mais do que suficiente para um primeiro sprint. 
Após esta configuração inicial, o Scrum Product Backlog tem de ser mantido em um processo contínuo que compreende as seguintes etapas: No início do projeto, a equipe Scrum e seu Scrum Product Owner começam por escrever tudo o que podem pensar facilmente. Isso é quase sempre mais do que suficiente para um primeiro sprint. Após esta configuração inicial, o Scrum Product Backlog tem de ser mantido em um processo contínuo que compreende as seguintesetapas:
À medida que novos itens são descobertos, eles são descritos e adicionados à lista. Os existentes são alterados ou removidos conforme apropriado.
Solicitando a Backlog do Produto Scrum. Os itens mais importantes são movidos para o topo.
Preparando as entradas de alta prioridade para a próxima Reunião de Planejamento da Sprint
(Re-) Estimativa das entradas no Scrum Product Backlog
O Scrum Product Owner é responsável por garantir que o Scrum Product Backlog esteja em boa forma, este é um processo colaborativo. Ao usar o Scrum Framework, cerca de 10% das equipes do Scrum devem reservar tempo total para manter o Scrum Product Backlog (discussão, estimativa etc.).  
A manutenção colaborativa do Scrum Product Backlog ajuda a esclarecer os requisitos e cria um buy-in da Scrum Team.
HISTÓRIAS DE USUÁRIOS DO SCRUM
As entradas no Scrum Product Backlog são muitas vezes escritas na forma de User Stories. Uma história de usuário conta uma pequena história sobre alguém usando o produto. Ele contém um nome, uma breve narrativa e critérios de aceitação e condições para a história ser completa. A vantagem das histórias de usuários é que elas se concentram exatamente no que o usuário precisa / deseja sem entrar nos detalhes sobre como alcançá-lo.  
Existem diferentes recomendações sobre como definir histórias de usuário. Um modelo poderia ser a seguinte: 
Como um [ator], eu [quer | deve] [ação], para que [conquista]
Ou em uma versão mais curta: 
Como [ator], eu [quer | deve] [conquista] 
Ator: O "dono" da história do usuário. Isso geralmente é um usuário, mas é recomendável ser mais específico aqui. Ao usar atores específicos (por exemplo, O que o ator quer alcançar realizando a ação. Este é o resultado da execução da ação vista do ponto de vista do ator. O que o ator quer alcançar realizando a ação. Este é o resultado da execução da ação vista do ponto de vista do ator.
Exemplo História do usuário
ESTIMAÇÕES DO ESFORÇO DO SCRUM - PLANNING POKER®
Todas as entradas dentro do Scrum Product Backlog devem ser estimadas para permitir que o Scrum Product Owner dê prioridade às entradas e planifique lançamentos. Isso significa que o Scrum Product Owner precisa de uma avaliação honesta de quão difícil será o trabalho. No entanto, recomenda-se que o Proprietário do Produto Scrum não compareça à estimativa para evitar a pressão (intencional ou não) da Equipe Scrum.
O próprio Scrum Framework não prescreve uma única maneira para as equipes Scrum estimarem seu trabalho. No entanto, dentro do Scrum Framework a estimativa não é normalmente feita em termos de tempo - uma métrica mais abstraída para quantificar o esforço é usado. Os métodos de estimativa comuns incluem o dimensionamento numérico (1 a 10), tamanhos de t-shirt (XS, S, M, L, XL, XXL, XXXL) ou a sequência de Fibonacci (1, 2, 3, 5, 8, 13, 34, etc.). 
Importante é que a equipe compartilha um entendimento comum da escala que ele usa, de modo que cada membro da equipe está confortável com ele. 
Planning Poker® / Scrum Poker
Um método comumente usado durante o processo de estimativa é jogar o Planning Poker® (também chamado Scrum Poker). Ao usar o Planning Poker®, a influência entre os participantes é minimizada e, portanto, um resultado de estimação mais preciso é produzido. 
Para jogar o Planning Poker® é necessário o seguinte: A influência entre os participantes é minimizada e, portanto, um resultado de estimação mais preciso é produzido. Para jogar o Planning Poker® é necessário o seguinte: A influência entre os participantes é minimizada e, portanto, um resultado de estimação mais preciso é produzido. Para jogar o Planning Poker® é necessário o seguinte:
A lista de recursos a serem estimados
Decks de cartões numerados.
Um baralho típico tem cartões que mostram a sequência de Fibonacci incluindo um zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; Outras progressões semelhantes são também possíveis. A razão para usar a seqüência de Fibonacci é refletir a incerteza na estimativa de itens maiores. Uma estimativa alta geralmente significa que a história não é bem compreendida em detalhes ou deve ser dividida em várias histórias menores. Histórias menores podem ser estimadas em maior detalhe. Seria uma perda de tempo discutir se é 19, 20 ou 25; A história é simplesmente (também) grande. 
O jogo é então jogado nas seguintes etapas:
O Scrum Product Owner apresenta a história a ser estimada. A Equipe Scrum faz perguntas e o Proprietário do Produto Scrum explica com mais detalhes. Se muitas histórias tiverem que ser estimadas, uma limitação de tempo (por exemplo, apenas um minuto para explicação) pode ser definida também. Se a restrição de tempo é alcançada ea Equipe Scrum não entende a história, é um sinal de que a história precisa ser reescrita.
Cada membro da Scrum Team escolhe privadamente o cartão que representa a estimativa.
Depois que todos escolhem um cartão, todas as seleções são reveladas.
Pessoas com estimativas altas e baixas podem explicar sua estimativa.
A estimativa começa de novo até que um consentimento seja encontrado.
Este jogo é repetido até que todas as histórias sejam estimadas.
O QUE É UM SPRINT?
No Scrum Framework, todas as atividades necessárias para a implementação de entradas do Scrum Product Backlog são realizadas no Sprints (também chamadas de 'Iterações'). Sprints são sempre curtos: normalmente cerca de 2-4 semanas.  
Cada Sprint segue um processo definido como mostrado abaixo:
O Sprint Processo
Cada Sprint começa com duas sessões de planejamento para definir o conteúdo do Sprint: o WHAT-Meeting eo HOW-Meeting. A combinação dessas duas reuniões também é definida como Reunião de Planejamento Sprint. Na Reunião WHAT, a Equipa Scrum compromete-se com as Histórias de Utilizador a partir da Backlog de Produto Scrum e utiliza uma Reunião HOW para quebrar as Histórias de Utilizador comprometidas em tarefas mais pequenas e concretas. Então a implementação começa. 
No final do Sprint, uma Reunião de Revisão Sprint é conduzida para permitir que o Proprietário do Produto Scrum verifique se todos os itens comprometidos estão completos e implementados corretamente. Além disso, uma Reunião Retrospectiva Sprint é realizada para verificar e melhorar os processos de execução do projeto: O que foi bom durante o Sprint, o que deve continuar como é eo que deve ser melhorado.
GRÁFICO DE QUEIMADURA DE SCRUM
O Scrum Burndown Chart é uma ferramenta de medição visual que mostra o trabalho concluído por dia contra a taxa de conclusão projetada para a versão atual do projeto. Seu objetivo é permitir que o projeto esteja no caminho para entregar a solução esperada dentro do cronograma desejado.
Simple Burndown Chart
A taxa de progresso de uma Scrum Team é chamada de "velocidade". Exprime a quantidade de eg pontos de história completados por iteração. Uma regra de importação para calcular a velocidade é que somente as histórias que são concluídas no final da iteração são contadas. É estritamente proibido contar o trabalho parcialmente terminado (por exemplo, codificação apenas - teste em falta). 
Depois de alguns Sprints, a velocidade de uma Scrum Team provavelmente será previsível e permitirá uma estimativa bastante precisa do tempo necessário até que todas as entradas no Scrum Product Backlog sejam concluídas. Se a velocidade de uma equipe Scrum for, por exemplo, 30 pontos da história ea quantidade total de trabalho restante é 155, podemos prever que precisamos de cerca de 6 Sprint para concluir todas as histórias no Backlog. 
No entanto, na realidade, as entradas no Scrum Product Backlog irão mudar ao longo da duração do projecto. Novas histórias são adicionadas e outras histórias são alteradas ou até mesmo excluídas. No Simple Burndown Chart não é possível distinguir a velocidade da Equipe Scrum e a mudança no escopo. Para refletir isso, pode-se usar outra forma de diagrama.
Separando Mudanças de Velocity e Scope
Aqui um gráfico de barra em vez de um diagrama de linha é usado. O tamanho de cada barrarepresenta a quantidade total de trabalho restante no início de cada sprint. A velocidade da equipe é subtraída da parte superior, enquanto as mudanças no Escopo alteram a parte inferior da barra. 
Para obter ainda mais precisos, também podemos levar em conta a taxa de mudanças no trabalho total. No entanto, temos de ter cuidado ao usar este modelo, uma vez que a taxa de mudança será alta no início do projeto, mas vai cair no final.
Gráfico de Burndown Estendido com Previsão
REUNIÃO DE PLANEAMENTO SPRINT
Cada Sprint e cada Reunião de Planejamento Sprint começa com uma reunião WHAT. O objetivo desta sessão é definir um Backlog de Sprint realista contendo todos os itens que poderiam ser totalmente implementados até o final do Sprint. 
Preparação
Para uma Reunião WHAT bem-sucedida é necessária alguma preparação:
O Proprietário do Produto Scrum define o Objetivo Sprint.
Com base nesse objetivo, as entradas relevantes no Scrum Product Backlog são escolhidas pelo Proprietário do Produto Scrum.
Essas entradas são atualizadas e divididas em pequenas histórias para que possam ser concluídas dentro de um Sprint.
As entradas são estimadas e priorizadas.
A equipe define sua capacidade para a próxima Sprint.
Objetivo Sprint
O Proprietário do Produto Scrum define o Objetivo Sprint. É uma breve descrição do que o sprint tentará alcançar e do que deve ser realista e compreensível para todos. 
Capacidade da Equipe
A capacidade total da Equipe Scrum pode mudar de Sprint para Sprint. Para chegar a compromissos realistas é necessário conhecer a capacidade total da equipe para o próximo Sprint considerando, por exemplo, férias, feriados, esforços para Scrum Meetings e tempo necessário para outras atividades durante o Sprint. 
A Sessão de Reunião
Durante a sessão o Proprietário do Produto Scrum apresenta o Objetivo Sprint e discute-o com a equipe. Depois disso, o Scrum Team itera através dos itens relevantes no Scrum Product Backlog e a equipe se compromete com as entradas que eles acham que podem ser totalmente concluídas dentro do Sprint. A decisão deve basear-se na capacidade disponível e no conhecimento sobre as entradas. 
No final da sessão, a lista de todas as entradas confirmadas do Scrum Product Backlog fornece a base para o HOW-Meeting eo Scrum Backlog. 
O HOW-Meeting
O objetivo do How-Meeting é preencher o Sprint Backlog identificando as tarefas concretas necessárias para a implementação completa das entradas do Scrum Product Backlog. As tarefas normalmente incluem atividades de projeto, implementação, teste e documentação. 
O HOW-Meeting pode ser feito em uma sessão separada após o WHAT-Meeting, Durante a Reunião WHAT ao confirmar as entradas ou ambas. 
Depois de identificar as atividades necessárias, elas são estimadas pela equipe. Base para esta estimativa deve ser pessoa-horas. A equipe deve quanto tempo ele vai precisar para fazer tudo o que é necessário para terminar esta atividade.
O SPRINT BACKLOG
Dentro do Sprint Backlog todas as atividades necessárias para concluir as entradas confirmadas do Scrum Product Backlog são armazenadas. Todas as entradas têm de ser estimadas em uma base pessoa-hora, a fim de acompanhar o progresso e os esforços restantes. 
O Backlog Sprint é um artefato vivo e é atualizado em uma base diária. Se um membro da equipe começa a trabalhar em uma atividade seu nome é gravado dentro do backlog sprint. Novas atividades podem ser adicionadas ao Sprint Backlog durante o Sprint. No final do dia todos os esforços restantes são atualizados e isso define quanto trabalho é deixado até o Sprint objetivo é alcançado. A definição de Feito (ver abaixo) é usada para decidir se um item é feito ou não. 
O Sprint Backlog pode ser mantido eletronicamente dentro, por exemplo, um Excel-Folha ou com cartões em uma tarefa bordo. Este último tem algumas vantagens (por exemplo, Transparência e acesso fácil), mas adicionam complexidade adicional se a Equipe Scrum estiver distribuída em vários sites. A figura abaixo mostra um exemplo de como uma tábua de tarefa poderia ser organizada. A estrutura deve ser adaptada para refletir as necessidades do projeto.
DEFINIÇÃO DE FEITO (DoD)
A fim de ser capaz de decidir quando uma atividade do Sprint Backlog é concluída, a definição de feito (DoD) é usado. Trata-se de uma lista abrangente de atividades necessárias que garantem que apenas recursos verdadeiramente feitos são entregues, não apenas em termos de funcionalidade, mas em termos de qualidade também. O DoD pode variar de um Scrum Team para outro, mas deve ser consistente dentro de uma equipe. 
Pode haver diferentes DoD em vários níveis:
DoD para um item Scrum Product Backlog (por exemplo, escrever código, testes e toda a documentação necessária)
DoD para um sprint (por exemplo, instalar o sistema de demonstração para revisão)
DoD para uma liberação (por exemplo, notas de lançamento de escrita)
SPRINT BURNDOWN REPORTS / CHARTS
O Sprint Burndown Report mostra o progresso dentro do Sprint para alcançar o Objetivo Sprint. Ele fornece transparência sobre o desempenho atual (taxa de burndown) e permite uma estimativa fácil se o objetivo da Sprint pode ser alcançado no tempo ou se a equipe tem que encontrar medidas adicionais para acelerar a conclusão das atividades restantes.
Sprint Burndown Report / Chart
O Backlog Sprint inicial define o ponto de partida para os esforços restantes. O esforço restante de todas as atividades é coletado em uma base diária e adicionado ao gráfico. No começo, o desempenho é muitas vezes não tão bom como previsto pela taxa de burndown ideal devido a estimativas erradas ou impedimentos que têm de ser removidos, a fim de obter a velocidade máxima.
REUNIÃO DIÁRIA DO SCRUM / REUNIÃO DIÁRIA DO STAND-UP
A reunião diária de Scrum é uma reunião diária curta, idealmente durante o começo da jornada de trabalho. Cada membro da equipe que trabalha para a conclusão de um determinado sprint precisa participar. Durante esta reunião, cada membro da equipe deve fornecer resumidamente as respostas das três perguntas a seguir:
O que ele / ela realizou desde a última reunião Scrum diária?
O que ele / ela vai realizar até a próxima reunião Scrum?
Quais são os impedimentos que impedem que ele / ela realize suas tarefas?
Todos os membros da equipe devem participar e eles devem ficar de pé durante a reunião. A reunião Scrum diária não deve durar mais de 15 minutos. Por outro lado, nenhuma questão ou preocupação levantada durante a reunião pode ser ignorada devido à falta de tempo. Questões ou preocupações devem ser registradas pelo Scrum Master e precisam ser tratadas especificamente após a reunião.
REUNIÃO DE REVISÃO SPRINT
No final de cada sprint uma reunião Sprint Review é realizada. Durante esta reunião a Equipa Scrum mostra quais itens Scrum Product Backlog eles completaram (de acordo com a Definição de Feito) durante o sprint. Isso pode acontecer na forma de uma demonstração das novas funcionalidades. 
É importante notar que itens de Backlog não concluídos não devem ser demonstrados. Caso contrário, isso pode sugerir que esses itens são concluídos também. Em vez disso, itens incompletos / atividades restantes devem ser retomados no Scrum Product Backlog, reestimados e concluídos em um dos seguintes sprints. 
A reunião da Sprint Review deve ser mantida muito informal. Nenhum slide do PowerPoint deve ser usado e tempo para preparação e realização da reunião deve ser limitado. Durante a reunião, o Scrum Product Owner inspeciona as entradas de backlog implementadas e aceita a solução ou adiciona novas histórias ao Scrum Product Backlog para adaptar a funcionalidade. 
Os participantes na revisão do sprint normalmente incluem o Scrum Product Owner, o Scrum Team eo Scrum Master. Além disso, a administração, clientes e desenvolvedores de outros projetos também podem participar.
SPRINT RETROSPECTIVE MEETING
Depois que a reunião da revisão do Sprint ocorreu a equipe do Scrum eo mestre do scrum se reúnem para a retrospectiva de Sprint. Nesta reuniãotodos os membros da equipe refletem sobre o sprint passado e verificar três coisas: o que correu bem durante o sprint, o que não, e que melhorias poderiam ser feitas no próximo sprint. A reunião deve ser programada (por exemplo, 3 horas). 
A Retrospectiva da Sprint é parte integrante do processo de "inspeção e adaptação". Sem esta reunião a equipe nunca será capaz de melhorar a sua produção global e não pode se concentrar no desempenho geral da equipe. Portanto, sugestões accionáveis para melhorar o desempenho devem estar disponíveis no final da reunião.
PROJETOS DISTRIBUÍDOS E GRANDES
O Scrum Framework - como descrito até agora - funciona melhor para uma única equipe Scrum em um local. No entanto, na realidade, uma única equipe Scrum muitas vezes não consegue realizar projetos ou recursos espalhados por vários locais. Consequentemente, o número de equipas tem de ser aumentado e / ou as equipas serão distribuídas. 
As razões para isso podem ser técnicas (por exemplo, especialistas não estão disponíveis localmente), relacionadas ao tamanho (projeto muito grande) ou relacionadas a negócios (por exemplo, uso de recursos em países de baixo custo ou aceleração pelo uso de diferentes fusos horários) . 
Como a comunicação é uma parte integrante do Scrum Framework, cuidado especial tinha que ser tomado para superar os desafios ao trabalhar dentro de um ambiente distribuído. Portanto, todos os membros da equipe devem ter acesso às ferramentas de comunicação Vídeo conferência e web cams) para quebrar as barreiras de comunicação mais tangíveis. 
Organização do Projeto - Múltiplas Equipes
A maneira mais simples de estender o Scrum Framework ao trabalhar em um projeto em larga escala é aumentar o número de equipes no mesmo local.
Várias equipes em um único local
Se várias equipes têm de ser usadas para implementar os requisitos, é importante certificar-se de que o número de equipes não cresce muito rápido. O melhor é começar com uma única equipe e depois de os primeiros sprints terem sido completados adicionando um pequeno número de outras equipes. Se necessário, após essas equipes serem produtivas, outras equipes poderão ser adicionadas.
Aumentando o número de equipes
Para criar novas equipes existem duas possibilidades:
Divisão de uma equipe existente em novas equipes e adicionar novos membros
Adicionando equipes completamente novas
A divisão de uma equipe existente tem a vantagem de que o know-how necessário já está disponível na equipe ea equipe pode obter produtiva mais rapidamente. A desvantagem é que já as equipes de trabalho estão despedaçadas. 
Ao adicionar equipes completamente novas, essas equipes existentes podem continuar com seu trabalho sem muita interrupção. No entanto, levará mais tempo para construir o sistema necessário know-how na nova equipe Scrum. 
Independente da decisão de como adicionar novas equipes, as seguintes regras devem ser seguidas:
Comece com um pequeno número de equipes
Sempre espere até que uma fundação seja construída e as equipes se estabilizem
Aumentar o número de equipes em pequenos passos
Organização do Projeto - Equipes Distribuídas
Ainda mais complicado será se essas novas equipes forem distribuídas em vários locais. Agora também mais frequentemente os obstáculos da comunicação ocorrerão e o cuidado especial deve ser tomado para introduzir e envolver todos os membros da equipe adequadamente.
Várias equipes em vários locais
Para se certificar de que os novos membros da equipe são introduzidos adequadamente e construir o conhecimento necessário o mais rápido possível, novos membros da equipe poderiam, por exemplo, temporariamente adicionado a uma equipe existente, de preferência mesmo em outro local. Com esta abordagem o know-how é transferido e as relações pessoais com as pessoas em outras equipes e locais construir.
Equipes virtuais
Outra possibilidade para a distribuição é que a equipe em si está espalhada por vários locais. Essa equipe é chamada de "equipe virtual".
Equipes virtuais
O principal desafio aqui é garantir uma boa comunicação entre os membros da equipe uma vez que algumas pessoas podem não ser capazes de participar fisicamente em reuniões ou não têm acesso a "ajudantes de comunicação" como o Conselho de Sprint. 
Uma possibilidade seria usar ferramentas de colaboração e / ou comunicação. Co-localizados pessoas poderiam, por exemplo, ser adicionado às reuniões via videoconferência ou as reuniões podem até ser realizadas completamente em uma "sala virtual" fornecido pela maioria das plataformas de colaboração. 
Equipe Scrum Product Owner
A comunicação adequada entre o Scrum Product Owner e a equipe é crucial para a implementação bem-sucedida do projeto. Para garantir que o Proprietário do Produto Scrum esteja sempre disponível para a equipe, Muitas vezes é necessário ter vários Scrum Product Owners trabalhando juntos. Idealmente, há um Proprietário de Produto Scrum dedicado por equipe. 
Os Proprietários do Produto Scrum devem então construir uma Equipe Proprietária do Produto Scrum dedicada para trabalhar efetivamente em conjunto. Um dos Proprietários do Produto Scrum deve ser designado para o papel de 'Chief Scrum Product Owner', que é responsável por assegurar que o produto é desenvolvido de forma coordenada. 
Uma vez que esta equipe é responsável pela engenharia de requisitos completa, também pode ser benéfico para adicionar outras funções e partes interessadas, como arquitetos ou representantes de clientes. Os Proprietários do Produto Scrum devem então construir uma Equipe Proprietária do Produto Scrum dedicada para trabalhar efetivamente em conjunto. 
Um dos Proprietários do Produto Scrum deve ser designado para o papel de 'Chief Scrum Product Owner', que é responsável por assegurar que o produto é desenvolvido de forma coordenada. Uma vez que esta equipe é responsável pela engenharia de requisitos completos também pode ser benéfico para adicionar outras funções e partes interessadas, como arquitetos ou representantes de clientes. 
Os Proprietários do Produto Scrum devem então construir uma Equipe Proprietária do Produto Scrum dedicada para trabalhar efetivamente em conjunto. Um dos Proprietários do Produto Scrum deve ser designado para o papel de 'Chief Scrum Product Owner', que é responsável por assegurar que o produto é desenvolvido de forma coordenada. Uma vez que esta equipe é responsável pela engenharia de requisitos completa, também pode ser benéfico para adicionar outras funções e partes interessadas, como arquitetos ou representantes de clientes.
Scrum Product Owner Team
Todos os Scrum Product Owners devem trabalhar dentro de um único Scrum Product Backlog contendo todas as histórias relevantes para o projeto. 
Equipes de Componentes ou Equipes
Ao distribuir o trabalho, podemos dividir as equipes de diferentes maneiras: como Equipamentos de Componentes ou Equipamentos. 
Equipes de componentes
Ao usar equipes de componentes, cada equipe é responsável apenas pela implementação de componentes dedicados no sistema. Para terminar uma história do usuário é na maioria dos casos necessário dividir as histórias em partes menores que poderiam ser implementadas dentro de um único componente. As dependências resultantes entre as equipes tornam necessária a integração numa base regular. Em muitos casos, uma única história de usuário não pode ser concluída em um único sprint como a implementação em uma equipe depende dos resultados de outras histórias em outra equipe que ainda não estão disponíveis. Isso é chamado de "Pipelining" e deve ser evitado, na medida do possível.
Equipes de componentes 
A vantagem de usar equipes de componentes é que é mais fácil garantir a arquitetura adequada do sistema. Por outro lado, as pessoas se especializam apenas em pequenas partes do sistema e o conhecimento sobre o sistema como um todo pode se perder. Sem esse conhecimento, a otimização local pode ocorrer uma vez que a equipe às vezes pode tomar decisões que são otimizadas para o componente único, mas melhores soluçõesde uma perspectiva do sistema poderiam ter sido feitas. 
Equipes de recursos
São totalmente responsáveis pela implementação das histórias de usuários contidas no Scrum Backlog. A equipe não é mais cortada ao longo de componentes do sistema, mas implementar tudo o que é necessário para terminar a história.
Equipes de Destaque 
equipes de times têm de ser interdisciplinares e, idealmente, podem agir de forma completamente autônoma. A vantagem é que o conhecimento do sistema é difundido ea integração é mais fácil. No entanto, é mais difícil garantir a consistência da arquitetura do sistema e pode ser difícil ou leva tempo para garantir que o conhecimento suficiente está disponível em todas as equipes. 
Componente e equipes de recursos Na realidade, muitos projetos maiores usam tanto: equipes de componentes dedicados e equipes de recursos.
Equipes de componentes e recursos 
Equipe C é uma equipe de componentes e fornece os serviços de infra-estrutura necessários para as outras equipes que são usadas como equipes de recursos. A Equipe C não implementa diretamente as histórias de usuários, mas obtém os requisitos das histórias de usuários comprometidas pelas equipes de recursos. Isso permite minimizar o número de pessoas necessárias com conhecimentos especializados (por exemplo, know-how de bancos de dados). 
O Scrum Master em um ambiente de distribuição
Em um ambiente de distribuição, o papel do Scrum Master é ainda mais importante, já que tais configurações normalmente têm mais impedimentos que exigem a atenção e o esforço do Scrum Masters. 
Uma regra importante é que o Scrum Master tem de ser localizado onde a equipe é de outra forma, será difícil remover os obstáculos no trabalho diário.
COORDENAÇÃO MULTI-EQUIPE E PLANEJAMENTO
Scrum of Scrum
Para coordenar as diferentes Scrum Teams "Scrum of Scrum" - Reuniões podem ser usadas. É semelhante ao Daily Scrum, mas o foco aqui é no nível da equipe. 
A reunião tem lugar todos os dias e deve ser limitada, por exemplo, a 15 minutos. Cada equipe envia um membro para participar e responder às seguintes perguntas:
O que a equipe terminou?
O que a equipe planeja terminar hoje?
Há algum impedimento?
As respostas devem concentrar-se nas coisas que afetam qualquer outra equipe. 
O Chefe Product Product Scrum deve moderar a reunião. Participar não só o Scrum Master das equipes, uma abordagem também poderia ser a mudança de participação em uma base diária dentro da equipe. 
Revisões comuns de Sprint
Em vez de várias pequenas reuniões Sprint Review um Sprint Review comum com todas as equipes também poderia ser usado. Isso mostrará a todos o que foi feito dentro do Sprint e qual o status do projeto. 
Retrospectivas comuns da Sprint
Para a Retrospectiva da Sprint há duas possibilidades. A primeira possibilidade é que cada equipe tenha sua própria reunião da Sprint Retrospective seguida por uma Retrospectiva da Sprint Comum onde todos os resultados são discutidos que dizem respeito a várias equipes. 
Outra possibilidade é que os tópicos sejam coletados, selecionados e depois trabalhados em grupos menores com membros de todas as equipes. Essa abordagem levará mais tempo, mas a vantagem é que os membros de várias equipes estão trabalhando em conjunto. Planejamento de várias equipes 
- Backlog de produtos Scrum
Mesmo quando se trabalha com várias equipes, é importante manter apenas um Backlog de produto Scrum comum para todas as equipes. O Backlog do Produto Scrum deve ser mantido pelo Chefe Product Owner do Scrum, mas preenchido por todos os Product Proprietários do Scrum. 
Se necessário, os itens do Scrum Product Backlog podem ser divididos em mais histórias específicas da equipe e mantidos em um Scrum Product Backlog específico para a equipe, por exemplo, apenas as partes relevantes para uma equipe de infraestrutura. 
Backlogs específicos da equipe Sprint Scheduling
Em um ambiente Scrum distribuído é possível escolher como sincronizar as diferentes equipes. Uma possibilidade é usar sprints síncronos. Neste caso, todas as equipes começam e terminam seus sprints no mesmo dia.
Sprints síncronos Sprints 
síncronos são a abordagem mais fácil, uma vez que torna a comunicação ea coordenação mais simples.
Outra possibilidade é usar sprints assíncronos. Aqui os sprints não começam no mesmo dia. O uso de sprints assíncronos tem a vantagem de que nem todas as reuniões têm de ser realizadas no mesmo dia e torna possível, por exemplo, que os Proprietários de Produtos Scrum participem em mais dessas reuniões.  
Quando uma equipe fornece serviços para outras equipes Sprints assíncronos também pode ser uma boa opção porque aqui os resultados da equipe de prestação de serviços já está disponível durante o tempo de desenvolvimento das outras equipes e poderia ser integrado.
Estimativas de Estimação de Sprints 
Assíncronas
É importante que todos os itens no Backlog de Produto de Scrum sejam estimados usando a mesma base para estimativa. Se os pontos de história são usados ​​todas as equipes têm de concordar com a mesma métrica e uma escala comum para usar. Se as Equipes de Componentes forem usadas, é importante que os membros de todas as equipes participem da estimativa para garantir que todos os esforços sejam cobertos.
PLANEAMENTO DA LIBERTAÇÃO DE SCRUM
Um plano de nível muito alto para vários Sprints (por exemplo, de três a doze iterações) é criado durante o planejamento de Release. É uma diretriz que reflete expectativas sobre quais recursos serão implementados e quando eles são concluídos. Ele também serve como uma base para monitorar o progresso dentro do projeto. As liberações podem ser entregas intermediárias feitas durante o projeto ou a entrega final no final. 
Para criar um plano de lançamento, as seguintes coisas devem estar disponíveis:
A prioridade e estimativa Scrum Product Backlog
A velocidade (estimada) da Equipe Scrum
Condições de satisfação (metas para o cronograma, escopo, recursos)
Dependendo do tipo de projeto (baseado em características ou data), o plano de liberação pode ser criado de diferentes maneiras: 
Se o projeto estiver orientado a recursos, a soma de todos os recursos dentro de um release pode ser dividida pela velocidade esperada. Isso resultará no número de sprints necessários para completar a funcionalidade solicitada.
Plano de Liberação para um projeto orientado a recursos
Se o projeto for dirigido pela data, podemos simplesmente multiplicar a velocidade pelo número de Sprints e obteremos o trabalho total que pode ser concluído dentro da linha de tempo determinada.
Release Plan para um projeto
orientado por data Como o Backpack de Produto Scrum, o plano Release não é um plano estático. Isso mudará durante todo o projeto quando novos conhecimentos estiverem disponíveis e, por exemplo, as entradas no Scrum Product Backlog serão alteradas e reestimadas. Portanto, o plano de lançamento deve ser revisitado e atualizado em intervalos regulares, por exemplo, após cada Sprint.
MANIFESTO AGILO
Em fevereiro de 2001, 17 desenvolvedores de software se reuniram no resort de Snowbird, Utah , para discutir métodos de desenvolvimento leve. Eles publicaram o Manifesto para Desenvolvimento de Software Ágil para definir a abordagem agora conhecida como desenvolvimento de software ágil. Alguns dos autores do manifesto formaram a Agile Alliance, uma organização sem fins lucrativos que promove o desenvolvimento de software de acordo com os princípios do manifesto.
O Manifesto Ágil lê, em sua totalidade, como segue:
Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando os outros a fazê-lo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações sobre processos e ferramentas
software trabalhando mais que documentação abrangente
Colaboração do cliente sobre negociação de contrato
Respondendo a alterações ao seguir um plano
Ou seja, enquanto há valor nos itens à direita, valorizamos os itens à esquerda mais. 
Os significados dos itens do manifesto à esquerdadentro do contexto de desenvolvimento de software ágil são descritos a seguir:
Indivíduos e interações - em desenvolvimento ágil, auto-organização e motivação são importantes, assim como interações como co- localização e programação de pares .
Software de trabalho - software de trabalho será mais útil e bem-vindo do que apenas apresentar documentos aos clientes em reuniões.
Os requisitos de colaboração de clientes não podem ser totalmente coletados no início do ciclo de desenvolvimento de software, portanto o envolvimento contínuo de clientes ou partes interessadas é muito importante.
Respondendo à mudança - o desenvolvimento ágil está focado em respostas rápidas à mudança e ao desenvolvimento contínuo.
O Manifesto Ágil é baseado em doze princípios:
Satisfação do cliente por entrega rápida de software útil
Boas-vindas exigências em mudança, mesmo atrasadas no desenvolvimento
Software de trabalho é entregue com freqüência (semanas, em vez de meses)
O software de trabalho é a principal medida do progresso
Desenvolvimento sustentável, capaz de manter um ritmo constante
Cooperação estreita e diária entre empresários e desenvolvedores
A conversa cara-a-cara é a melhor forma de comunicação (co-localização)
Os projetos são construídos em torno de indivíduos motivados, que devem ser confiáveis
Atenção contínua à excelência técnica e ao bom design
Simplicidade - a arte de maximizar a quantidade de trabalho não feito - é essencial
Equipes auto-organizadas
Adaptação regular à mudança das circunstâncias
A imagem de fundo bem conhecida do site Agile Manifesto foi tomada por Ward Cunningham, que queria capturar o momento durante a reunião de fim de semana em Snowbird.
Em 2005, um grupo liderado por Alistair Cockburn e Jim Highsmith escreveu um adendo de princípios de gerenciamento de projetos , a Declaração de Interdependência , para orientar a gestão de projetos de software de acordo com métodos de desenvolvimento ágil.
Em 2009, um movimento liderado por Robert C Martin escreveu uma extensão dos princípios de desenvolvimento de software , o Manifesto de Artesanato de Software , para orientar o desenvolvimento de software ágil de acordo com a conduta profissional e o domínio