O estilo de corrida de revezamento aplicado ao desenvolvimento de produtos pode conflitar com os objetivos de velocidade e flexibilidade mximas.

Ao invs disto, um estilo holstico, onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor s atuais necessidades competitivas.
Adequado de The New Product Development Game, Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986.

Scrum um processo gil que permite manter o foco na entrega do maior valor de negcio, no menor tempo possvel. Isto permite a rpida e contnua inspeo do software em produo (em intervalos de duas a quatro semanas). As necessidades do negcio que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade.
Entre cada duas a quatro semanas todos podem ver o real software em produo, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um Sprint.

Jeff Sutherland -> Uso inicial do scrum na Easel em 1993 -> IDX e mais de 500 pessoas usando scrum Ken Schwaber -> ADM -> Apresentao na OOPSLA 96 com Sutherland -> Trs livros sobre Scrum *
Mike Beedle -> Padres para o Scrum na PLOPD4 Ken Schwaber and Mike Cohn -> Fundaram a Scrum Alliance em 2002, inicialmente junto com a Agile Alliance

Sprint ; Backlog; Product backlog X Sprint backlog; Product owner, Scrum master e Scrum team; 5) Sprint Planning meeting; 6) Sprint review Meeting; 7) Daily Scrum; 8) Sprint Retrospective.
1) 2) 3) 4)

Cada sprint uma iterao que segue um ciclo (PDCA) do projeto (tipicamente mensais) e entrega um incremento ao software pronto. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias geis de desenvolvimento de software so iterativas, ou seja, o trabalho dividido em iteraes, que so chamadas de Sprints no caso do Scrum.

Um backlog conjunto de requisitos, priorizado pelo Product Owner (responsvel por conhecer as necessidades do cliente).

H entrega de conjunto fixo de itens do backlog em srie de interaes curtas ou sprints.

Product Backlog

O Product backlog mantido pelo Product Owner e uma lista de requisitos, contendo as funcionalidades a serem implementadas em um projeto, que tipicamente vm do cliente. O Product Owner pode alter-lo a qualquer momento, desde que os itens alterados no estejam na sprint.

O Product Backlog no precisa estar completo no incio de um projeto. Pode-se comear com tudo aquilo que mais bvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda medida que se aprende mais sobre o produto e seus usurios.
Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe ento determina que itens ser capaz de completar durante a Sprint que est por comear. Tais itens so, ento, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas tcnicas ou atividades diretamente relacionadas s funcionalidades solicitadas.

Sprint Backlog

Normalmente o sprint backlog uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog so extrados do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepo da equipe sobre o tempo que ser necessrio para completar as vrias funcionalidades.
Cabe a equipe determinar a quantidade de itens do Product Backlog que sero trazidos para o Sprint Backlog, j que ela quem ir se comprometer a implement-los. Durante um Sprint, o Scrum Master mantm o Sprint Backlog atualizando-o para refletir que tarefas so completadas e quanto tempo a equipe acredita que ser necessrio para completar aquelas que ainda no esto prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint calculada diariamente e colocada em um grfico, resultando em um Sprint Burndown Chart.

Product Owner

O Proprietrio do Produto, ou Product Owner, representa os stakeholders (todos os envolvidos no processo) e o negcio. Ele responsvel por conhecer as necessidades do cliente.

Ele altera e mantm o product backlog, alm de priorizar itens deste e descrever estes itens para a equipe.
Define as funcionalidades do produto. Decide datas de lanamento e contedo. Responsvel pela rentabilidade (ROI). Prioriza funcionalidades de acordo com o valor de mercado. Ajusta funcionalidades e prioridades. Aceita ou rejeita o resultado dos trabalhos.

Scrum master

O ScrumMaster, mantm os processos (normalmente no lugar de um gerente de projeto). Scrum Master, que tem como funo primria remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint.
O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas), mas atua como um mediador entre a equipe e qualquer influncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.

Scrum team

A Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a anlise, projeto, implementao, teste etc. Entre 5 e 9 pessoas.

Multi-funcional -> Programadores, testadores, desenvolvedores de interfaces, etc. Tempo integral -> H raras excees (Ex.: Administrador de Base de Dados).
Auto-organizvel -> Idealmente, sem ttulos, ainda que possvel. Trocas s na mudana de Sprints.

A Sprint Planning Meeting uma reunio na qual esto presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerncia ou o cliente.
Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunio de modo que seja capaz de quebrar as funcionalidades em tarefas tcnicas, aps a reunio. Essas tarefas iro dar origem ao Sprint Backlog. Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que ser iniciado. Em alguns casos, haver negociao com o Product Owner, mas ser sempre responsabilidade da equipe determinar o quanto ela ser capaz de se comprometer a fazer.

O Sprint Review Meeting feito ao final de cada Sprint, nesta reunio, o Scrum Team mostra o que foi alcanado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerncia, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto avaliado em relao aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo que a equipe atinja o objetivo geral do Sprint.

A cada dia do Sprint a equipe faz uma reunio diria, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas tambm podem estar presentes, mas s podero escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informaes sobre o estado do projeto.
O Daily Scrum no deve ser usado como uma reunio para resoluo de problemas. Questes levantadas devem ser levadas para fora da reunio e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucion-lo. Durante o Daily Scrum, cada membro da equipe prov respostas para cada uma destas trs perguntas: * O que voc fez ontem? * O que voc far hoje? * H algum impedimento no seu caminho?

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possvel.

O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que aes sero tomadas para melhorar.

Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na sada); Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas; Planos frequentes de mitigao de riscos desenvolvidos pela equipe; Discusses dirias de status com a equipe;
A discusso diria na qual cada membro da equipe responde s seguintes perguntas: -> O que fiz desde ontem? -> O que estou planejando fazer at amanh? -> Existe algo me impedindo de atingir minha meta?

Transparncia no planejamento e desenvolvimento; Reunies frequentes com os stakeholders (todos os envolvidos no processo) para monitorizar o progresso;
Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer problema no visto;

Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" no necessariamente significa "produzir mais".

Indivduos e interao

Processos e ferramentas

Software que funciona

Documentao abrangente

ao invs de
Colaborao Do cliente Negociao de contrato

Resposta a mudanas

Seguir um plano

Requerimentos

Projeto

Cdigo

Teste

x
Ao invs de fazer uma etapa por vez como est acima .... As equipes Scrum fazem um pouco de tudo em todas as etapas, a todo momento.

Aplicaes do Scrum:
Software comercial Desenvolvimento interno

Desenvolvimento contratado (terceirizao)

Sistemas para controle de satlites Websites

Projetos de preo fixo

Aplicaes Financeiras Aplicaes certificadas pela ISO 9001

Software para handhelds

Telefones celulares
Sistemas embarcados Sistemas disponveis 24x7 Desenvolvimento por hackers solitrios

Aplicaes para redes

Aplicaes de ISV

Video games Sistemas para suporte vida

(Independent Software Vendors) Algumas das maiores aplicaes em produo

Google
Microsoft Yahoo

Nokia
Siemens UOL

Philips
Electronic Arts BBC