O documento apresenta um guia sobre a metodologia ágil Scrum, destacando seus pilares, papéis, cerimônias e artefatos. Foca na importância da transparência, inspeção e adaptação, além de descrever as responsabilidades do Scrum Master, Product Owner e equipe de desenvolvimento. Também enfatiza os princípios do manifesto ágil e como o Scrum deve ser implementado de forma completa para ser eficaz.

1. ENTER SCRUM
Breno Campos

2. TaSafo.org
Safos@yahoogrupos.com.br

3. TaSafo.org
Quem Somos?
Comunidade de
profissionais
e estudantes de
Tecnologia da Informação.

4. TaSafo.org
Como ser um Safo?
Entre na lista de discussão.
Participe dos eventos.
Venha pra frente.
Compartilhe algo.

5. Quem é Breno Campos?
• Bacharel em Sistemas de Informação – UFPa;
• Especialista em Gerência de Projetos de Software – UFPa;
• CSM – Certified SCRUM Master;
• Membro do PMI – SP;
• Trabalha a 4 anos com metodologias ágeis, principalmente
SCRUM;
• Não é desenvolvedor;
• Aficionado por Gestão de TI;
• Atualmente auxilia na Coordenação de uma Equipe de
Desenvolvimento e presta consultoria de Gestão de
Projetos;

6. ENTER SCRUM
Breno Campos

7. • Intro
• Pilares
• Papéis
• Cerimônias
• Artefatos
• Definição de Pronto
• Considerações Finais

8. MANIFESTO ÁGIL
Estamos
descobrindo
maneiras
melhores de desenvolver software
fazendo-o nós mesmos e ajudando
outros a fazê-lo.

9. Nossos Valores:
• 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

10. Nossos Princípios:
• Nossa maior prioridade é satisfazer o cliente, através da entrega
adiantada e contínua de software de valor.
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adequam a mudanças, para que o cliente possa
tirar vantagens competitivas.
• Entregar software funcionando com frequência, na escala de
semanas até meses, com preferência aos períodos mais curtos.
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar
em conjunto e diariamente, durante todo o curso do projeto.

11. Nossos Princípios:
• Construir projetos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho.
• O Método mais eficiente e eficaz de transmitir informações para, e
por dentro de um time de desenvolvimento, é através de uma
conversa cara a cara.
• Software funcional é a medida primária de progresso.
• Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes.

12. Nossos Princípios:
• Contínua atenção à excelência técnica e bom design, aumenta a
agilidade.
• Simplicidade: a arte de maximizar a quantidade de trabalho que não
precisou ser feito.
• As melhores arquiteturas, requisitos e designs emergem de times
auto-organizáveis.
• Em intervalos regulares, o time reflete em como ficar mais efetivo,
então, se ajustam e otimizam seu comportamento de acordo.

14. Os pais da criança
Ken Schwaber
Jeff Sutherland

15. Origem do nome

16. O SCRUM NÃO É!
Ferramenta
Técnica
Processo

17. Então, o que é?

18. É uma “fusão”!

19. Beleza, mas como o SCRUM roda?

20. De forma Iterativa

21. e Incremental...

22. O SCRUM é sustentado por 3 pilares.

23. Transparência Inspeção
Adaptação

24. Pra quem não entendeu...
<< Patrícia Pilar

25. Transparência
Os aspectos mais significativos
do projeto devem estar
visíveis
para
todos
os
envolvidos. Deixando claro o
que está sendo feito, o que
ainda será feito, e o que está
pronto.

26. Inspeção
Os
envolvidos
devem
inspecionar os artefatos
gerados, para verificar se o
projeto está seguindo de
acordo com o planejado,
detectando variações de
desempenho.
Deve-se tomar cuidado
com a frequência das
inspeções para que não
chegue ao ponto de
atrapalhar o andamento do
desenvolvimento;

27. Baseado
nos
resultados
obtidos da inspeção, a
adaptação
realiza
as
alterações necessárias para
que o projeto continue seu
bom andamento, ou para
consertar falhas;
Adaptação

28. O SCRUM possui 3 papéis.

29. Equipe de Desenvolvimento
• Auto gerenciáveis;
• “Sem títulos” definidos;
• TODOS são desenvolvedores;

30. Product Owner
•
•
•
•
Responsável por Maximizar o ROI;
Gerencia as demandas;
Prioriza as tarefas;
Garante que a E.D. entenda as
tarefas;
• Apenas UMA pessoa;

31. SCRUM Master
• Líder Servidor;
• Remover impedimentos;
• Proteger a equipe;

32. SCRUM Master
NÃO É
Gerente de Projetos

33. Não delega tarefas;
Não define responsabilidades;

34. Cerimônias

35. Objetivos
• Criar rotinas;
• Diminuir a quantidade de reuniões desnecessárias;

36. Time-Boxed
Tempo limite definido!

37. Sprint
• Principal cerimônia do SCRUM;
• Todas as outras estão contidas
nela;
• Time-Boxing de 1 a 4 semanas;
• Durante essa iteração (Sprint),
é gerada uma release (uma
versão utilizável do produto);

38. Sprint
• A Sprint é blindada, o que foi
planejado deve ser executado!
• A Sprint pode ser cancelada, mas
somente o Product Owner tem
poder para isso. Seus motivos
podem
variar,
como
o
cancelamento
do
projeto,
mudança de tecnologia ou outros.

39. Sprint Planning
• Reunião onde é Planejado o que será
executado na Sprint;
• Time-Box: 8 horas para uma sprint de
quatro semanas e deve ser
proporcional para sprints menores;
• O time tenta prever o que ocorrerá
durante a sprint (feriados, faltas, etc);
• A equipe deve estimar as tarefas
priorizadas pelo PO, e alocá-las na
sprint, obedecendo a quantidade de
esforço estimada.

40. Daily Meeting
• Também conhecida como Stand up
meeting é feita para sincronizar a
equipe, deixar todos a par dos
acontecimentos, e dos avanços de
cada um;
• Time-Box: 15 minutos, o motivo de
ser uma “reunião em pé”, é para
durar mais do que o necessário;

41. Daily Meeting
• Três perguntas:
• “O que você fez até aqui?”;
• “O que você pretende fazer até
a próxima daily meeting?”;
• “Quais impedimentos você está
tendo?”

42. Sprint Review
• Os participantes dela são os
integrantes do time Scrum (time
de desenvolvimento, SM e PO);
• Time-Box: 4 horas para uma sprint
de 4 semanas e deve ser
proporcional
para
sprints
menores;
• O P.O. verifica o que está pronto, e
o que não está, é apresentado as
tarefas realizadas;

43. Sprint Retrospective
• É realizada para que o time possa se
inspecionar, encontrar acertos e falhas,
e pensar em meios de tentar corrigir o
que não saiu como o esperado;
• Ocorre entre a Sprint Review e o Sprint
Planning;
• Time-Box: 3 horas para uma sprint de
um mês e deve ser proporcional para
sprints menores;

44. Artefatos

45. Objetivo
• Maximizar a transparência das informações.

46. Product Backlog
• É o ‘container’ que guarda todas as
tarefas definidas pelo PO;
• É o PO que mantém o backlog, ou seja,
ele inclui tarefas, retira tarefas e as
ordena de acordo com suas prioridades;
• Um backlog de produto dificilmente está
completo, as primeiras iterações
estabelecem requisitos iniciais, e com o
passar dos ciclos o número de requisitos
tende a aumentar;

47. Product Backlog
• Vale lembrar, que o backlog de produto
é dinâmico, o PO pode alterá-lo em
qualquer parte do ciclo, pode adicionar
tarefas, retirá-las, mudar prioridade de
acordo com sua necessidade. Os itens
de maior prioridade, devem ser melhor
detalhados, visando manter a agilidade.
Itens mais abaixo na lista de prioridade,
não precisam estar tão detalhados, visto
que ainda não entrarão na iteração.

48. Sprint Backlog
• É o ‘container’ que recebe todas as
tarefas que foram priorizadas e
estimadas para a iteração corrente;
• Deve estar visível para todos, afim de
manter a transparência e mostrar a
todos o que a equipe está realizando;

49. Sprint Backlog
• Ao contrário do backlog do produto,
este não é dinâmico. As tarefas que
foram alocadas para uma sprint não
podem ser retiradas, adicionadas ou
trocadas;
• O sprint backlog deve ser atualizado a
medida que as tarefas forem sendo
concluídas, para que toda a equipe
possa ver o andamento dos trabalhos.

50. Gráfico Burndown
• Tem por objetivo manter transparente o
progresso da equipe. Demonstrando a
“queima” das tarefas pelo tempo.
• Começa no topo, indicando o total de
pontos de esforço da sprint, e vai
descendo com o passar do tempo (e da
realização das tarefas).

51. Definição de Pronto
• Esta definição deve ser válida para toda
a equipe;
• O que o time define como pronto? Um
código que foi escrito? Escrito e
testado?
Escrito,
testado
e
documentado?;
• Resumindo, se alguém disser que o
trabalho está Pronto, todos do time
devem saber o que Pronto significa;

52. Finalizando
“Papéis, artefatos, eventos e regras do Scrum são imutáveis e
embora seja possível implementar somente partes do Scrum, o
resultado não é Scrum. Scrum existe somente na sua totalidade,
funcionando bem como um container para outras técnicas,
metodologias e práticas.”

53. Tá Safo?

54. Obrigado!
brenobcampos@gmail.com
http://www.linkedin.com/in/brenobcampos
http://www.coyoti.com.br/blog

55. Fontes:
http://www.scrum.org/Scrum-Guides
http://manifestoagil.com.br/
http://coyoti.com.br/blog/scrum-para-iniciantes-parte-1-de-2