O documento resume metodologias ágeis e tradicionais de gerenciamento de projetos, comparando projetos com produção contínua. Também descreve o Scrum, um framework ágil que usa sprints curtos, daily meetings e product backlog para entregar software incrementalmente.

1. Resumindo Metodologias
Ágil e tradicional

2. Resumindo Gerenciamento de
projetos
segundo PMI

3. O que é Projeto?
Conjunto de atividades temporárias, realizadas em grupo,
destinadas a produzir um produto, serviço ou resultado
únicos.

4. Quais suas características?
● Temporário
● Exclusivo
● Incerteza

5. Projeto x Produção contínua
Projeto
● Temporário
● Exclusivo
● Grau de Incerteza
Produção Contínua
● Continuidade
● Repetitivo
● Zero de Incerteza

6. Quais são os Pilares de um projeto?
● Escopo
● Tempo
● Custo

7. O que é PMI?
O PMI é a maior associação sem fins lucrativos do mundo
para profissionais de gerenciamento de projetos, com
mais de meio milhão de associados e de Profissionais
Certificados em 185 países.

9. o que é PMBoK?
No PMBoK Guide® 3º Edition (2004), a partir de agora,
apenas PMBoK,são abordados quarenta e quatro
processos divididos nas nove áreas de conhecimentos,
formando um fluxo contínuo de processos.

11. Resumindo Gerenciamento de
projetos Ágeis
usando Scrum

12. O tal do Manifesto

13. Itens
● Os indivíduos e suas interações acima de procedimentos
e ferramentas;
● O funcionamento do software acima de documentação
abrangente;
● A colaboração com o cliente acima da negociação e
contrato;
● Adaptação a mudanças é mais importante do que seguir
o plano inicial.
http://agilemanifesto.org/

14. Princípios
● Garantir a satisfação do cliente, entregando rápida e continuamente
software funcional;
● Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
● Software funcional é entregue frequentemente (semanal ou mensal - o
menor intervalo possível);
● Cooperação constante entre as pessoas que entendem do 'negócio' e os
desenvolvedores;
● Projetos surgem por meio de indivíduos motivados, devendo existir uma
relação de confiança.
● A melhor forma de transmissão de informação entre desenvolvedores é
através da conversa 'cara a cara'
http://agilemanifesto.org/

15. ● Software funcional é a principal medida de progresso do projeto;
● Novos recursos de software devem ser entregues constantemente. Clientes
e desenvolvedores devem manter um ritmo até a conclusão do projeto.
● Design do software deve prezar pela excelência técnica;
● Simplicidade;
● As melhores arquiteturas, requisitos e designs emergem de equipes
auto-organizáveis.
● Em intervalos regulares, a equipe reflete sobre como se tornar mais
eficaz e então refina e ajusta seu comportamento.
Princípios
http://agilemanifesto.org/

16. O tal do SCRUM

17. Um processo para construir software incrementalmente
em ambientes complexos, onde os requisitos não são
claros ou mudam com muita freqüência
O que é?

18. Semelhanças
Princípios semelhantes aos de XP (Extreme Programming):
● Equipes pequenas
● Requisitos pouco estáveis ou desconhecidos
● Iterações curtas para promover visibilidade para o
desenvolvimento

19. Ciclo de Vida
Scrum divide o desenvolvimento em:
● Sprints de 30 dias.
● Equipes pequenas, de até 7 pessoas, são formadas por:
○ projetistas
○ programadores
○ engenheiros
○ gerentes de qualidade.

20. Ciclo de vida
○ Estas equipes trabalham em cima de funcionalidade
(os requisitos, em outras palavras) definidas no
início de cada Sprint. A equipe toda é responsável
pelo desenvolvimento desta funcionalidade

21. Ciclo de vida
Daily Meeting
Todo dia, é feita uma reunião de 15 minutos onde o time
expõe:
● O que foi feito ontem
● O que será feito hoje
● Levantar os fatores de impedimento
● Se a tarefa que comecei ontem conseguirei terminar
hoje

22. Fases

23. Product Backlog
Roadmap
Sabemos que temos que fazer mas não sabemos quando

24. Sprint Planning
● Planejamento do que vai entrar na sprint.
● Conversa para fragmentar as User Stories
● Refinamento do Product Backlog

25. Sprint Backlog
Conjunto de Stories e seus critério de aceitação

26. Stories
User Story ou “história de usuário” é uma descrição concisa
de uma necessidade do usuário do produto (ou seja, de um
“requisito”) sob o ponto de vista desse usuário. A User Story
busca descrever essa necessidade de uma forma simples e
leve

27. Stories
A User Story possui três aspectos críticos, chamados de “os
três C’s”:
● Cartão
● Conversas
● Confirmação.

28. (C1) Cartão
Os padrões mais utilizados para
se escrever o Cartão da User
Story estabelece três parâmetros
da necessidade do usuário:
“QUEM”, “O QUÊ” e “POR QUÊ”.

29. Forma ERRADA
“Eu, enquanto Comprador de Livros, quero buscar livros
por nome para escolher o que vou comprar.”
buscar livros por nome é um problema ou uma solução?

30. Forma MAIS INDICADA
“Eu, enquanto Comprador de Livros, quero encontrar um
livro cujo nome sei para escolher e comprá-lo.”

31. Expressar a User Story a partir do problema e não de uma
solução

32. (C2) Conversa
São conversas sobre a User Story, por onde a solução de
negócios e os detalhes dessa solução são discutidos,
negociados, definidos e então documentados na forma de
Critérios e Testes de Aceitação.

33. (C3) Confirmação
São critérios e testes deles derivados que documentam os
detalhes da User Story

34. Ou seja, são regras que estabelecem como a funcionalidade
deve se comportar uma vez implementada.

35. Esses critérios são chamados de Critérios de Aceitação

36. Cada User Story possui seu próprio conjunto de Critérios e
Testes de Aceitação.

37. Características desse tal de critério de
aceitação?
● Critérios de Aceitação são expressos por enunciados
pequenos e de fácil entendimento.
● São utilizados para determinar quando a funcionalidade
produzida pelo Time de Desenvolvimento está completa
● A partir desses critérios, o Time de Desenvolvimento
gera os Testes Unitários Automatizados .

38. Os Critérios de Aceitação são negociados e definidos antes
do desenvolvimento da funcionalidade, geralmente em
sessões de Refinamento do Product Backlog.

39. Um exemplo

40. User Story
“Eu, enquanto Comprador de Livros, quero utilizar meu
cartão de crédito no pagamento dos livros escolhidos, para
ter praticidade e segurança no pagamento.”

41. Critérios
Critério #1: somente podemos aceitar cartões de crédito
com bandeiras com que temos convênio.
Critério #2: somente podemos aceitar cartões de crédito
com data de expiração no futuro.

42. Testes Unitário
Critério #1: somente podemos aceitar cartões de crédito com bandeiras com
que temos convênio.
● Comprador de Livros utiliza cartão de crédito Visa
○ Aceitou = correto.
○ Recusou = errado, deve ser corrigido!
● Comprador de Livros utiliza cartão de crédito MasterCard
○ Aceitou = correto.
○ Recusou = errado, deve ser corrigido!
● Comprador de Livros utiliza cartão de crédito Amex
○ Recusou = correto.
○ Aceitou = errado, deve ser corrigido!

43. Testes Unitário
Critério #2: somente podemos aceitar cartões de crédito com data de expiração
no futuro.
● Comprador de Livros utiliza cartão de crédito com expiração em
01/01/2020
○ Aceitou = correto.
○ Recusou = errado, deve ser corrigido!
● Comprador de Livros utilizou cartão de crédito com expiração em
01/01/2000
○ Recusou = correto.
○ Aceitou = errado, deve ser corrigido!

44. Outras metodologias
● Crystal
● Feature Driven Development
● Adaptive Software Development