O que é Projeto?
Conjunto de atividades temporárias, realizadas em grupo,
destinadas a produzir um produto, serviço ou resultado
únicos.
Slide 4
Slide 4 text
Quais suas características?
● Temporário
● Exclusivo
● Incerteza
Slide 5
Slide 5 text
Projeto x Produção contínua
Projeto
● Temporário
● Exclusivo
● Grau de Incerteza
Produção Contínua
● Continuidade
● Repetitivo
● Zero de Incerteza
Slide 6
Slide 6 text
Quais são os Pilares de um projeto?
● Escopo
● Tempo
● Custo
Slide 7
Slide 7 text
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.
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
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.
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Resumindo Gerenciamento de
projetos Ágeis
usando Scrum
Slide 12
Slide 12 text
O tal do Manifesto
Slide 13
Slide 13 text
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/
Slide 14
Slide 14 text
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/
Slide 15
Slide 15 text
● 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/
Slide 16
Slide 16 text
O tal do SCRUM
Slide 17
Slide 17 text
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 é?
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
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.
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
Fases
Slide 23
Slide 23 text
Product Backlog
Roadmap
Sabemos que temos que fazer mas não sabemos quando
Slide 24
Slide 24 text
Sprint Planning
● Planejamento do que vai entrar na sprint.
● Conversa para fragmentar as User Stories
● Refinamento do Product Backlog
Slide 25
Slide 25 text
Sprint Backlog
Conjunto de Stories e seus critério de aceitação
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
Stories
A User Story possui três aspectos críticos, chamados de “os
três C’s”:
● Cartão
● Conversas
● Confirmação.
Slide 28
Slide 28 text
(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Ê”.
Slide 29
Slide 29 text
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?
Slide 30
Slide 30 text
Forma MAIS INDICADA
“Eu, enquanto Comprador de Livros, quero encontrar um
livro cujo nome sei para escolher e comprá-lo.”
Slide 31
Slide 31 text
Expressar a User Story a partir do problema e não de uma
solução
Slide 32
Slide 32 text
(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.
Slide 33
Slide 33 text
(C3) Confirmação
São critérios e testes deles derivados que documentam os
detalhes da User Story
Slide 34
Slide 34 text
Ou seja, são regras que estabelecem como a funcionalidade
deve se comportar uma vez implementada.
Slide 35
Slide 35 text
Esses critérios são chamados de Critérios de Aceitação
Slide 36
Slide 36 text
Cada User Story possui seu próprio conjunto de Critérios e
Testes de Aceitação.
Slide 37
Slide 37 text
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 .
Slide 38
Slide 38 text
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.
Slide 39
Slide 39 text
Um exemplo
Slide 40
Slide 40 text
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.”
Slide 41
Slide 41 text
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.
Slide 42
Slide 42 text
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!
Slide 43
Slide 43 text
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!
Slide 44
Slide 44 text
Outras metodologias
● Crystal
● Feature Driven Development
● Adaptive Software Development