2. MOTIVAÇÃO
Como ganhar dinheiro resolvendo
problemas que voce não conhece,
com pessoas desconhecidas, em
um tempo curto e com poucos
recursos (e se divertindo)?
4. RELATÓRIO DO CHAOS (CHAOS REPORT)
Estudo doThe Standish Group conclui (Chaos Report):
Pesquisa sobre a utilização das funcionalidades do software ...
Mais de 64% de um sistema de software
quase nunca não é utilizado!
DESPERDÍCIO!!!!
8. PROBLEMAS DO MUNDO DE
DESENVOLVIMENTO
Com métodos tradicionais/clássicos de desenvolvimento
Supõem que é possível prever o futuro
Pouca interação com os clientes
Ênfase em burocracias
(documentos, formulários, processos, controles rígidos, etc.)
Avaliação do progresso baseado na evolução da burocracia e não do
código
Com software
Grande quantidade de erros
Falta de flexibilidade
9. COMO RESOLVER ISSO?
MelhoresTecnologias
Padrões de Projeto (reutilização de idéias)
Componentes (reutilização de código)
Middleware/frameworks (aumenta abstração)
Melhores Metodologias
Métodos Ágeis
10. O QUE É DESENVOLVIMENTO DE
SOFTWARE?
(Gabriel)Arte
(Knuth)Artesanato
(Cockburn)Poesia
(Humphreys)Disciplina
(Meyer)Engenharia
(Jacobson)Modelagem Erro comum: olhar para software como
apenas um desses itens e ignorar os demais
11. O QUE SÃO MÉTODOSAGÉIS?
“Agile não é um conjunto de práticas, mas um
conjunto de crenças e princípios”
Jim Highsmith
13. MANIFESTO ÁGIL - HISTÓRICO
Movimento iniciado por programadores experientes e consultores em
desenvolvimento de software.
Questionam e se opõem a uma série de mitos e práticas adotadas em abordagens
tradicionais de Engenharia de Software e Gerência de Projetos.
ManifestoÁgil:
Assinado por 17 desenvolvedores em Utah em fevereiro/2001.
http://agilemanifesto.org
15. 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.
16. 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.
17. 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.
18. UM PROJETOÁGIL IDEAL…
O gerente de projeto concorda em prosseguir sem que todos os requisitos
estejam bem definidos
Os desenvolvedores concordam em prosseguir sem ter todos os requisitos
documentados
Os membros da equipe sabem que alguém vai ajudar quando ocorrerem
problemas
19. UM PROJETOÁGIL IDEAL…
Os gerentes percebem que não precisam dizer à equipe o que fazer, ou garantir o
que vai ser feito
A equipe percebe que ninguém vai dizer o que fazer, isto faz parte do trabalho da
equipe
Não existem mais a impressão de divisão (testers and programmers), todos são
desenvolvedores
25. UM PROJETOTRADICIONAL…
0. Levantamento de Requisitos
1.Análise de Requisitos
2. Desenho da Arquitetura
3. Implementação
4.Testes
5. Produção / Manutenção
26. PREMISSAS BASICAS DO MODELO
TRADICIONAL
É necessário fazer uma análise de requisitos profunda e detalhada antes de
projetar a arquitetura do sistema
É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da
arquitetura antes de começar a implementá-la
É necessário testar o sistema completamente antes de mandar a versão final para
o cliente
27. ITERATIVO E INCREMENTAL
Interface
Cliente
Servidor
BD
C
Iterativo = não espere ter tudo correto na primeira vez
Incremental = construa em ”pedaços” verticais (features) ao invés de horizontais (camadas)
Desenvolvimento monolítico
1
2
3
4
1
Desenvolvimento incremental
2 3
Talvez não seja
necessário construir
o resto
C
Interface
Cliente
Servidor
BD
Ref: Henrik Kniberg
29. IMPORTANTE!!!
Metodologias ágeis são uma tentativa de
refinar as metodologias iterativas, tirando
o foco do processo em si e dando mais
ênfase para a contribuição das pessoas
32. O QUE MUDA?
Métodos tradicionais
O planejamento deve propiciar a prevenção de mudanças
Métodos ágeis
A mudança é incorporada ao escopo
Razões
Necessidades de negócio
Novas oportunidades
Mudanças de legislação
Requisitos incompletos
35. E SE FOSSE ESSA A REALIDADE?
A atitude dos desenvolvedores de software seria completamente diferente:
Tomaríamos as grandes decisões o mais tarde possível
Implementaríamos agora somente o que precisamos agora
Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades)
36. E ESSA É A NOVA REALIDADE! (EM MUITOSCASOS)
Orientação a Objetos: facilita e cria oportunidades para mudanças
Técnicas de Refatoração
Testes automatizados: nos dão segurança quando fazemos mudanças
Prática / cultura de mudanças: aprendemos técnicas e adquirimos experiência em
lidar com código mutante
37. PRINCIPAIS MÉTODOS ÁGEIS
Adaptative Software Development (ASD)
CrystalClear (Crystal)
Extreme Programming (XP)
Scrum
Lean Software Development
Feature Driven Development (FDD)
Test Drive Development (TDD)
Kanban
40. Cinco Motivos para não usar Métodos Ágeis
Motivo 1
Eu sei e defino todos os
requisitos no início do
projeto
Não preciso de ciclos iterativos
Qual projeto de software possui todos os requisitos definidos (corretamente) no início?
41. Cinco Motivos para não usar Métodos Ágeis
Motivo 2
Os objetivos do meu
projeto estão muito claros
desde o início
O cliente descobre o que quer ao longo do caminho
42. Cinco Motivos para não usar Métodos Ágeis
Motivo 3
Meu projeto envolve baixa
incerteza
Qual projeto de software envolve baixa incerteza?
43. Cinco Motivos para não usar Métodos Ágeis
Motivo 4
Minha estimativa está toda
definida e com índice de
erro muito baixo
Em qual projeto de software consigo ter estimativas precisas?
44. Cinco Motivos para não usar Métodos Ágeis
Motivo 5
Meu processo é rígido e
controlado (comando-
controle)
As tarefas são delegadas, equipes ficam desmotivadas mais facilmente
Qual equipe gosta de trabalhar desmotivada?
45. Cinco Motivos para não usar Métodos Ágeis
Requisitos definidos desde o início
Objetivos claros desde o início
Comando-controle
Baixa incerteza
Estimativas precisas
Qual projeto de desenvolvimento de software possui
estas características?
46. E os Cinco Motivos?
Requisitos definidos desde o início
Objetivos claros desde o início
Comando-controle
Baixa incerteza
Estimativas precisas
Qual projeto de desenvolvimento de software possui
estas características?
49. Os pais da criança
Jeff SutherlandKen Schwaber
Scrum foi criado no início da década de 1990 por Jeff Sutherland e Ken Schwaber, nos EUA
50. O QUE É O SCRUM
Um processo iterativo e incremental para o gerenciamento
de projetos de desenvolvimento de produtos
(especialmente software).
Mais um framework que uma metodologia.
MaisAtitude que uma processo.
Cultura
Auto-Gerenciamento, time multi-disciplinar,
envolvimento do cliente, comprometimento,
papéis, entregas frequentes, liderança, colaboração,
Respeito, etc.
54. ÊNFASE: PROCESSO EMPÍRICO
Princípio
Características desconhecidas
Prioridades devem ser consideradas
Escopo irá mudar!
Essência do SCRUM
Inspeção
• Verificar o que foi feito no período
Adaptação
• Melhorar o processo
Planejar
Planejar o sprint
Desenvolver
Realizar o sprint
Inspecionar (check)
Sprint review e retrospectiva
Adaptar
Lições para o próximo planejamento
PLAN
DO
ACT
CHECK
55. O USO DO SCRUM
Ref.:
3rd Annual ”State of Agile Development” Survey June-July 2008
3061 respondentes, 80 países
58. Product Owner
• Responsável por Maximizar o
ROI;
• Gerencia as demandas;
• Prioriza as tarefas;
• Garante o entendimento das
tarefas;
• Apenas UMA pessoa;
67. BUSINESSVALUE - ROI
Business Value será uma moeda de troca durante o projeto e o
cliente empresta um determinado valor dessa moeda para a
equipe e esta por sua vez, terá que devolver o valor
correspondente em forma de software, ou seja, é uma dívida
que a equipe assume com o cliente e que deverá ser amortizada
a cada ciclo(Sprint), até que a mesma seja totalmente liquidada
(zerada).
68. USER STORIES
User stories
Identificação de atores envolvidos
Como um [papel do usuário]
quero [funcionalidade]
para [valor de negócio]
I.N.V.E.S.T. (independente, negociável, valorizável, estimável, small e testável)
Quebrar grandes e juntar pequenas
Definição do conceito de DONE (testes)
Diferentes perspectivas
Prioridades das user stories
Valor entre 1 e 150?
Deve ter
Deveria ter
Poderia ter
70. TAREFAS
Administrate
users
Register new
user
Edit existing
user
Delete user
Find user
User admin
User admin
User admin
User admin
Do GUI
design
Write failing
test
Do integration
test
Create DB
schema
Write server-
side logic
Write form
validation
Dividir
Quebrar em tarefas durante a reunião de sprint planning
13
5
3
8
2
Ref: Henrik Kniberg
73. ESTIMATIVAS
Estimativas
Tempo e/ou complexidade?
Fibonacci
1, 2, 3, 5, 8, 13, 21…
Planning poker
As duas estratégias de uso de planning poker
Jogar as cartas para cada estória
Colocar cada estória embaixo de uma carta
Algumas práticas utilizadas:
Pontos para funcionalidades e horas para tarefas
1-day tasks (máximo 2 e mínimo 1/2)
Considerar tarefas como teste, pesquisas, documentação, etc.
74. VELOCIDADE DA SPRINT – O QUE
TEREMOS?
Técnicas de estimativas
Instinto, sentimentos e percepções
O cálculo de velocidade pode ser baseado:
HOMEM DIA DISPONIVEL * FATOR FOCO = VELOCIDADE
75. O DIA A DIA DO SCRUM
ScrumMaster e Equipe
Dia-a-dia do SCRUM
Sprint
2 semanas a 4 semanas
Daily meetings (Daily Scrum)
Impedimentos
Obstáculos ao trabalho da equipe
Manter a taskboard
Burndown
Tarefas e estimativas
Tarefas não-planejadas
80. DAILY MEETINGS
Daily Meetings (Daily Scrum)
Reunião diária de 15 minutos
Mantém equipe informada e integrada
O que você fez ontem?
O que pretende fazer para amanhã?
Quais são seus impedimentos?
Questões técnicas
No final da reunião
Não se resolve problema, apenas se identifica
81. SPRINT REVIEW
Cliente, PO, SM e Team
Apresentação do produto
Foco no QUE foi feito e não COMO foi feito
Aceite formal e feedback do cliente
Melhoria na forma de priorização?
82. PRÓXIMA SPRINT
Lições aprendidas
Alimentam o próximo sprint
Velocidade da equipe
Erros x acertos
Previsto x realizado
Fator de foco da equipe
Repositório de lições
Disseminação na empresa
Usar parte do sprint anterior para planejar o próximo sprint
Lições aprendidas
84. TRABALHO - ARTIGO…
Diserte sobre SCRUM, descrevendo seu funcionamento, seus beneficios e as
dificuldades em se adotar a metodologia.
DATA DE ENTREGA 06/06/2014
