Palestra sobre métodos ágeis para desenvolvimento de software.

1. www.konia.com.br
Métodos Ágeis
Como trabalhar com engenharia de software sem perder
a agilidade?
Adriano Bertucci
Consultor ALM – Konia Tecnologia
Microsoft Visual Studio ALM MVP
adriano.bertucci@konia.com.br
@adrianobertucci

2. www.konia.com.br
O Que veremos?
 Métodos Ágeis
 Métodos Tradicionais
 Dinâmica conceitual
 Scrum
 Dinâmica conceitual

3. Como ganhar dinheiro resolvendo
problemas que voce não conhece, com
pessoas desconhecidas, em um tempo
curto e com poucos recursos (e se
www.konia.com.br
Motivação
divertindo)?
Tradicional Nuvem privada Nuvem pública

4. www.konia.com.br
Relatório do Chaos (Chaos Report)

5. www.konia.com.br
Relatório do Chaos (Chaos Report)
 Estudo do The 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!!
!!

6. www.konia.com.br
MOTIVAÇÃO

7. Como tratamos desenvolvimento de
software?
www.konia.com.br

8. www.konia.com.br
Da para fazer diferente?

9. Problemas do mundo de desenvolvimento
 Métodos tradicionais/clássicos de desenvolvimento
www.konia.com.br
 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
 Softwares
 Grande quantidade de erros
 Falta de flexibilidade

10. www.konia.com.br
Como resolver isso?
 Melhores Tecnologias
 Padrões de Projeto (reutilização de idéias)
 Componentes (reutilização de código)
 Middleware/frameworks (aumenta abstração)
 Novas Metodologias
Métodos Ágeis

11. O que é desenvolvimento de software?
www.konia.com.br
Modelagem (Jacobson)
Engenharia (Meyer)
Disciplina (Humphreys)
Poesia (Cockburn)
Artesanato (Knuth)
Arte (Gabriel)
Erro comum: olhar para software como
apenas um desses itens e ignorar os
demais

12. www.konia.com.br
O que são métodos agéis?
“Agile não é um conjunto de práticas, mas um
conjunto de crenças e princípios”
Jim Highsmith

13. www.konia.com.br
PRINCIPIOS
Retorno de investimento
Inovação
Melhoria de processo
Pessoas
Cultura
Comunicação
Adaptação x Antecipação

14. www.konia.com.br
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. www.konia.com.br
Manifesto ágil

16. www.konia.com.br
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

17. www.konia.com.br
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

18. www.konia.com.br
EVITE MULTI-tarefa

19. www.konia.com.br
O segredo da comunicação…

20. www.konia.com.br
O desafio de uma equipe auto
organizada

21. www.konia.com.br
Premissas básicas 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

22. www.konia.com.br
Como funciona?

23. www.konia.com.br
Mudança de postura!
Tradicional Ágil
Equipe
Equipe
Equipe
Equipe
GP
Equipe
Equipe
Equipe
Equipe
GP
Cross-funcional
Auto-organização

24. www.konia.com.br
Iterativo e incremental
Desenvolvimento monolítico
Interface
Cliente
Servidor
BD
C
Desenvolvimento incremental
Iterativo = não espere ter tudo correto na primeira vez
Incremental = construa em ”pedaços” verticais (features) ao invés de horizontais (camadas)
Talvez não seja
necessário construir
o resto
C
Interface
Cliente
Servidor
BD
Ref: Henrik Kniberg

25. www.konia.com.br
Iterativo e incremental

26. 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
www.konia.com.br
das pessoas

27. Importante!!!
Metodologias ágeis é uma febre?
www.konia.com.br
Uma onda passageira?
É o início de uma mudança na forma
de trabalho...

28. www.konia.com.br
O Paradoxo da multitarefa

29. www.konia.com.br
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

30. www.konia.com.br
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
Ágil
Tradicional

31. www.konia.com.br
Relatório do Chaos (Chaos Report)

32. www.konia.com.br
Principais métodos ágeis
 Adaptative Software Development (ASD)
 Crystal Clear (Crystal)
 Extreme Programming (XP)
 Scrum
 Lean Software Development
 Feature Driven Development (FDD)
 Test Drive Development (TDD)
 Kanban

33. www.konia.com.br
Mudança de perspectiva

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

35. Qual projeto de software possui todos os requisitos definidos (corretamente)
www.konia.com.br
Motivo 1
Não preciso de ciclos iterativos
no início?
Eu sei e defino todos os
requisitos no início do
projeto

36. www.konia.com.br
Motivo 2
O cliente descobre o que quer ao longo do caminho
Os objetivos do meu
projeto estão muito
claros desde o início

37. www.konia.com.br
Motivo 3
Qual projeto de software envolve baixa incerteza?
Meu projeto envolve
baixa incerteza

38. Em qual projeto de software consigo ter estimativas precisas?
www.konia.com.br
Motivo 4
Minha estimativa está
toda definida e com
índice de erro muito
baixo

39. www.konia.com.br
Praticando…
PRODUÇÃO X PRODUTIVIDADE
Analista Projetista Programador Testador Cliente
Æ OE
Ref: Luiz Cláudio Parzianello

40. www.konia.com.br
Praticando…
PRODUÇÃO X PRODUTIVIDADE
Pequenos Lotes
Æ
…
Æ Æ OE Æ
…
Æ OE Æ OE ™ Æ OE
…
ÆÆ OEOE ™™
…
Ref: Luiz Cláudio Parzianello
Æ Æ OE Æ OE ™
… … … …
Grandes Lotes

41. www.konia.com.br
Praticando…
PRODUÇÃO X PRODUTIVIDADE
 Qual é o arranjo logístico mais rápido?
 Qual equipe apresentou o maior esforço por projeto?
 Quais as vantagens de cada abordagem?
 Quais as desvantagens de cada abordagem?
 Qual a justificativa para manter os grandes lotes?

42. SCRUM

43. www.konia.com.br
SCRUM - Origem

44. Scrum foi criado no início da década de 1990 por Jeff Sutherland e Ken
Schwaber, nos EUA
www.konia.com.br
Os pais da criança
Ken Schwaber Jeff Sutherland

45. www.konia.com.br
O que é SCRUM?
 Um processo iterativo e incremental para o gerenciamento
de projetos de desenvolvimento de produtos (especialmente
software).
 Mais um framework que uma metodologia.
 Mais Atitude que uma processo.
Cultura
Auto-Gerenciamento, time multi-disciplinar,
envolvimento do cliente, comprometimento,
papéis, entregas frequentes, liderança, colaboração,
Respeito, etc.

46. Beleza, mas como o
SCRUM roda?

47. www.konia.com.br
De forma iterativa

48. www.konia.com.br
e Incremental…

49. www.konia.com.br
Ê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

50. www.konia.com.br
O uso do SCRUM
Ref.:
3rd Annual ”State of Agile Development” Survey June-July 2008
3061 respondentes, 80 países

51. www.konia.com.br
O SCRUM possui 3 papéis.

52. www.konia.com.br
Equipe de desenvolvimento
 Auto gerenciáveis
 “Sem títulos” definidos
 TODOS são desenvolvedores

53. www.konia.com.br
Product Owner
 Responsável por Maximizar o ROI
 Gerencia as demandas
 Prioriza as tarefas
 Garante o entendimento das tarefas
 Apenas UMA pessoa

54. www.konia.com.br
Scrum Master
 Líder Servidor
 Remover impedimentos
 Proteger a equipe

55. www.konia.com.br
SCRUM Master
NÃO É
Gerente de Projetos

56. www.konia.com.br
Não delega tarefas;
Não define responsabilidades;

57. www.konia.com.br
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)

58. www.konia.com.br

59. www.konia.com.br
Fluxo do scrum

60. www.konia.com.br
pregame

61. www.konia.com.br
Product backlog

62. www.konia.com.br
Business value - 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).

63. www.konia.com.br
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

64. www.konia.com.br
Priorização e classificação do backlog

65. www.konia.com.br
Tarefas
Administrate
users
User admin
Register new
user
User admin
Find user
User admin
2
Edit existing
user
User admin
Delete user
Write failing
test
Do GUI
design
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
Ref: Henrik Kniberg

66. www.konia.com.br
Os objetivos SMART de uma Sprint

67. www.konia.com.br
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.

68. www.konia.com.br
Sprint Planning Meeting

69. Velocidade da sprint – o que teremos?
www.konia.com.br
 Técnicas de estimativas
 Instinto, sentimentos e percepções
 O cálculo de velocidade pode ser baseado:
 HOMEM DIA DISPONIVEL * FATOR FOCO = VELOCIDADE

70. www.konia.com.br
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

71. www.konia.com.br
Sprint backlog

72. www.konia.com.br
KANBAN - VISIBILIDADE

73. www.konia.com.br
Burndown

74. www.konia.com.br
Dashboard – visibilidade

75. www.konia.com.br
Daily meetings
Daily Meetings (Daily Scrum)
Reunião diária de 15 minutos
Mantém equipe informada e
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

76. www.konia.com.br
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?

77. www.konia.com.br
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

78. www.konia.com.br
Praticando Scrum
 Fábrica de Aviões

79. Science to Business
Copyright – Direitos autorais
Copyright © 2011-2014 Konia Tecnologia. Este documento é inédito e a advertência precedente é fixada para proteger Konia Tecnologia. no caso de
publicação não autorizada. Todos os direitos reservados. Nenhuma parte deste documento pode ser reproduzida em qualquer forma, inclusive fotocópia
ou transmissão eletrônica para qualquer computador, sem autorização prévia por escrito de Konia Tecnologia. As informações contidas neste
documento são confidenciais e propriedade da Konia Tecnologia. e não podem ser usadas ou reveladas exceto quando expressamente autorizado por
escrito por Konia Tecnologia.
Adriano Bertucci
Consultor ALM – Konia Tecnologia
Microsoft Visual Studio ALM MVP
adriano.bertucci@konia.com.br
@adrianobertucci