Uma introdução ao SCRUM, palestra nível iniciante que apresenta o framework, seus atores, artefatos e cerimônias.
Sinta-se a vontade para baixar, copiar e distribuir. Apenas cite a fonte.
Palestra apresentada em faculdades por volta de 2012.
PS: Sobre a diferença entre entre Scrum Master e Gerente de Projetos, amadureci muito minha visão sobre isso, se quiser bater um papo, entre em contato.
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;
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.
13.
14. Os pais da criança
Ken Schwaber
Jeff Sutherland
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
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;
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;
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.”