Guia do scrum em português

O guia do SCRUM foi idealizado por Ken Schwaber e Jeff Sutherland e traduzido para o português do Brasil por meio dos colaboradores que atuam junto ao SCRUM.ORG que está disponibilizando gratuitamente como mais uma otima ferramenta de consulta e aprendizado do principal modelo de desenvolvimento agil utilizado no mercado atual.

Já na introdução podemos conferir uma rápida definição da visão do SCRUM “Scrum é baseado nas melhores práticas aceitas pelo mercado,utilizadas e provadas por décadas. Ele é definido então em uma teoria de processos empíricos.”

Os três pilares que fundamentam o SCRUM: TRANSPARÊNCIA, INSPEÇÃO, ADAPTAÇÃO representam uma grande mudança de atitudes nos projetos. Graças ao SCRUM você consegue ter uma rápida separação de quem está comprometido no projeto e de quem está participando com a famosa história do porco de da galinha que resolveram abrir juntos um restaurante de ovos com bacon.

Uma das principais diferenças é o modelo de auto organização e comprometimento entre os envolvidos no processo. Quando você estima o desenvolvimento de um software para outra pessoa fazer é praticamente impossível prever todas as condições dinâmicas que acontecem na implementação de uma funcionalidade e com o modelo aplicado no SCRUM você faz sua estimativa de forma que com isso possa se comprometer junto com time com as entregas das tarefas relacionadas.

O SCRUM é composto de um conjunto de papeis (Product Owner,ScrumMaster,Team,Scrum Team),reuniões (Daily Scrum,Scrum of scrums,Sprint Planning Meeting,Sprint Review Meeting,Sprint Retrospective ) e artefatos (Product backlog, Sprint backlog, Burn down) orientados por um foco no ROI (Return On Investment) e atividades baseadas no conceito de “Time-Box”.

Detalhando um pouco mais os papeis nos temos na visão do Product Owner como o responsável por direcionar as prioridades nas atividades e atingir o maior ROI do projeto. Cabe ao Scrum Master a manutenção do processo e ao Team (Desenvolvedores, Arquitetos, DBA e outros) a implementação dos Itens do BackLog selecionados para o Sprint.

O conceito de equipes auto organizáveis choca os conceitos tradicionais baseados no gerente. Nesse novo modelo a equipe “Team” conduzirá o projeto conforme as prioridades definidas pelo Product Owner. Caberá ao Scrum Master à manutenção do processo e o foco na remoção dos impedimentos  para que o Team possa trabalhar em sua missão de entregar as funcionalidades dentro do ‘Sprint’ que pode variar de duas a quatro semanas.

As reuniões diárias são fantásticas pois em um horário determinado o Team se reúne em um local previamente combinado e rapidamente cada membro responde as três principais perguntas:

O que fiz desde a última reunião?
O que farei até a próxima?
Estou tendo algum impedimento?

Com essas informações obtidas é atualizado o Burn down com o tempo restante para finalização e todos tem a visibilidade de quem está comprometido dentro do Team. Comparando com o modelo tradicional com o SCRUM você tem esse auto acompanhamento diário que ao invés de um gerente terá todo o time como gerente. Os que não entregam ficam constrangidos por que passam a comprometer a entrega do Sprint.

Nota: Apenas o Team participa dessa reunião ficando os demais como “galinhas”.

Ao final do ciclo de cada Sprint é feito uma reunião “Sprint Review” onde é apresentado pelo Team aos demais participantes (Product Owner, Scrum Master…) o resultado de negócio. Ou seja a tradução dos itens do backlog em entregáveis no formato de aplicação. Durante o  “Sprint Review” é normal surgir novas ideias e melhorias ao projeto e cabe ao Product Owner adicionar ou não como item do Backlog.  Logo na sequencia inicia a reunião “Sprint Retrospective” dedicada ao registro das lições aprendidas durante o Sprint e itens que precisam ser melhorado com a participação do Scrum Master e o Team.

Outro item bastante interessante que chamou minha atenção no SCRUM foi a valorização do conceito de “Software pronto”. Ou seja, como o Team define que uma funcionalidade está pronta. Esse é um item de muita importante no projeto, pois é uma métrica para alinhamento de expectativas. É importante que esteja publicado em um local publico no projeto como um WIKI. O Team pode posteriormente atualizar  incluindo mais requerimentos. Para você entender melhor podemos dizer que o time 2PC definiu os seguintes itens para considerar “Done”.

– 70% de cobertura de código nos objetos de negócio
– Passar em todos os testes manuais
– Rodar no browser XYZ

Já venho trabalhando com desenvolvimento ágil usando SCRUM e Visual Studio / Team Foundation Server  a quase dois anos. Os clientes estão muito satisfeitos com os resultados obtidos nos projetos.  Com  o Visual Studio 2010 esse processo ficou ainda mais simplificado por que o template padrão MSF Agil 5.0 é baseado no SCRUM daí você pode usar diretamente o mesmo sem nenhuma modificação adicional.

Para baixar o guia:
Guia do SCRUM

Post relacionado
Certificação gratuita no SCRUM.ORG

[],
Ramon Durães
MVP, Visual Studio ALM
Especialista em desenvolvimento de softaew