1.
MÉTODOS ÁGEIS
Aula 02
Adriano Bertucci
Email: adriano@bertucci.com.br
Twitter: @adrianobertucci
Site: www.adrianobertucci.com

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)?

3.
RELATÓRIO DO CHAOS (CHAOS REPORT)

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!!!!

5.
MOTIVAÇÃO

6.
COMOTRATAMOS DESENVOLVIMENTO DE
SOFTWARE?

7.
DA PARA FAZER DIFERENTE?

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

12.
PRINCIPIOS
Retorno de investimento
Inovação
Melhoria de processo
Pessoas
Cultura
Comunicação
Adaptação x Antecipação

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

14.
MANIFESTO ÁGIL

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

20.
EVITE MULTI-TAREFA

21.
O SEGREDO DA COMUNICAÇÃO…

22.
O DESAFIO DE UMA EQUIPE AUTO
ORGANIZADA

23.
MUDANÇA DE POSTURA!
Equipe
Equipe
Equipe
Equipe
GP
Equipe
Equipe
Equipe
Equipe
GP
Tradicional Ágil
Cross-funcional
Auto-organização

24.
COMO FUNCIONA?

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

28.
ITERATIVO E INCREMENTAL

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

30.
IMPORTANTE!!!
Metodologias ágeis é uma febre?
Uma onda passageira?
É o início de uma mudança na forma de
trabalho...

31.
O PARADOXO DA MULTITAREFA

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

33.
O QUE MUDA?
Custo
da
mudança
Intensidade
e stress
Tempo
Tempo Tempo
Entrega
de valor
Transparência
Envolvimento
do cliente
Tempo
Ref: Henrik Kniberg
Tradicional
Ágil

34.
RELATÓRIO DO CHAOS (CHAOS REPORT)

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

38.
MUDANÇA DE PERSPECTIVA

39.
5 motivos para NÃO
usar métodos ágeis?

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?

47.
SCRUM

48.
SCRUM - ORIGEM

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.

51.
Beleza, mas como o SCRUM roda?

52.
De forma Iterativa

53.
e Incremental...

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

56.
O SCRUM possui 3 papéis.

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

58.
Product Owner
• Responsável por Maximizar o
ROI;
• Gerencia as demandas;
• Prioriza as tarefas;
• Garante o entendimento das
tarefas;
• Apenas UMA pessoa;

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

60.
SCRUM Master
NÃO É
Gerente de Projetos

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

62.
MACRO FASES
 Pregame
 Planejamento
 Desenho e alto nível da
 Arquitetura
 Modelo Abrangente
 Game
 Sprints (Modelagem incremental, desenvolvimento, revisões e
ajustes)
 Postgame
 Fechamento (Agrupamento da Documentação,Treinamento, Lições
Aprendidas)

63.
FLUXO DO SCRUM

64.
PREGAME

65.
PRODUCT BACKLOG

66.
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).

67.
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

68.
PRIORIZAÇÃO E CLASSIFICAÇÃO DO
BACKLOG

69.
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

70.
OS OBJETIVOS SMART DE UMA SPRINT

71.
SPRINT PLANNING MEETING

72.
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.

73.
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

74.
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

75.
SPRINT BACKLOG

76.
KANBAN -VISIBILIDADE

77.
BURNDOWN

78.
DASHBOARD –VISIBILIDADE

79.
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

80.
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?

81.
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

82.
PRATICANDO…
DINÂMICA DOS AVIÕES

83.
TRABALHO - ARTIGO…
 Diserte sobre SCRUM, descrevendo seu funcionamento, seus beneficios e as
dificuldades em se adotar a metodologia.
 DATA DE ENTREGA 06/06/2014