Slides apresentados na disciplina in0953.2012 do Professor Silvio Meira

1. Agile
Eric Cavalcanti
ecavalcanti@gmail.com
@ericoc

2. O Problema
Chaos Report
18%
2004 53%
29%
19%
2006 46% Fracassados
35%
Comprometidos
Bem sucedidos
24%
2009 44%
32%
!"#$%&'(")&*%+,-."/0$12""

3. Principais fatores de
insucesso
requisitos incompletos
falta de envolvimento
de usuários
mudanças de
requisitos e especificações
falta de apoio de negócios
falta de recursos

4. Como resolver?

5. Abordagem Tradicional

6. BDUF
Big Design Up Front

7. Analista de Requisitos, Analista de Negócios,
Engenheiro de Requisitos, Engenheiro de Qualidade,
Gerente de Configuração, Líder de Projeto...
Programadores

8. Processo!!

9. Ainda assim...

10. Ainda mais...
Código Complexo.
Manutenção difícil.
Baixa produtividade.
Cronograma sempre atrasado.
Insatisfação de todos.
Design degradado.
Documentação defasada, excessiva e ilegível.
Fracasso em grande parte dos projetos.

11. Por quê?

12. Previsibilidade

13. O desenvolvimento de software depende
muito mais das pessoas e da comunicação

14. “Ao contrário do cenário numa linha de
produção em massa, o software não é algo
previsível ou imune a mudanças”
Larman

15. “Desenvolver software é como
desenvolver novos produtos”
Larman

16. “Desenvolver é como criar uma receita,
enquanto produzir é seguir a receita”
Poppendieck

17. “O desenvolvimento é um processo de
aprendizado, que envolve tentativa e erros”
Larman

18. “Como a manufatura previsível, não pode ser comparada ao
software, dificilmente as práticas e valores enraizados nesse
paradigma trazem algum benefício” Larman

19. 64% das funcionalidades
desenvolvidas nos softwares
não são utilizadas
Standish Group

20. Muitas vezes, pelo fato do cliente
só poder pedir uma vez, ele
acaba pedindo coisas que não
tem certeza que precisa

21. Essas funcionalidades
fazem parte dos
64% que ele nem
repara que estão lá,
quando o software é
entregue

22. 70% dos usuários utilizam as
funcionalidades básicas de um software.
20% utilizam as funcionalidades
intermediárias.
10% utilizam as funcionalidades avançadas.
Microsoft

23. Cone da Incerteza
Construx

24. É natural que os
usuários tenham novas
idéias e suas opiniões
mudem quando vêem
as primeiras versões
do software

25. Os softwares mais famosos
e utilizados no mundo são
os mais simples

29. “Menos é Mais”
A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008

30. DANIEL COOK

31. Abordagem Ágil

32. Final da década de 90
eXtreme Programming
Feature Driven Development
Scrum
Adaptive Development
Crystal Clear
Dynamic Systems Development Method

33. 2001
Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Brian Marick
Bennekum Robert C. Martin
Alistair Cockburn Steve Mellor
Ward Cunningham Ken Schwaber
Martin Fowler Jeff Sutherland
James Grenning
Manifesto Ágil
Dave Thomas
Jim Highsmith
Andrew Hunt

34. Indivíduos e interação entre eles
mais que processos e ferramentas

35. Software em funcionamento
mais que documentação abrangente

36. Colaboração com o cliente
mais que negociação de contratos

37. Responder a mudanças mais
que seguir um plano

38. Princípios por trás do
manifesto ágil

39. Nossa maior prioridade é
satisfazer o cliente, através
da entrega adiantada e
contínua de software de
valor

40. Aceitar mudanças de requisitos,
mesmo no fim do desenvolvimento

41. Processos ágeis se adequam a
mudanças, para que o cliente
possa tirar vantagens
competitivas

42. Entregar software
funcionando com
frequencia, na escala de
semanas até meses, com
preferência aos
períodos mais curtos

43. Pessoas relacionadas à negócios e desenvolvedores
devem trabalhar em conjunto e diariamente,
durante todo o curso do projeto

44. Construir projetos ao redor de
indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar
que farão seu trabalho.

45. O método mais eficiente e eficaz de
transmitir informações é através de uma
conversa cara a cara.

46. Software
funcional é a
medida primária
de progresso.

47. Processos ágeis promovem um ambiente
sustentável. Os patrocinadores, desenvolvedores
e usuários, devem ser capazes de manter
indefinidamente, passos constantes.

48. Contínua atenção à excelência
técnica e bom design, aumenta
a agilidade.

49. Simplicidade: a arte de
maximizar a quantidade de
trabalho que não precisou
ser feito

50. As melhores arquiteturas,
requisitos e designs emergem
de times auto-organizáveis

51. Em intervalos regulares, o time reflete em como
ficar mais efetivo, então, se ajustam e otimizam
seu comportamento de acordo

52. Por que adotar
abordagens ágeis?

53. STATE OF
AGILE SURVEY
2011
6.042 participantes
VersionOne

54. STATE OF
AGILE SURVEY
2011
>80% 90%
trabalham em são pelo menos"esclarecido"
organizações que usam sobre técnicas de
práticas de desenvolvimento ágil de
desenvolvimento ágil software
em um certo grau
VersionOne

55. STATE OF
AGILE SURVEY
2011
45% utilizam abordagem
ágil a mais de 2 anos
VersionOne

56. STATE OF
AGILE SURVEY
2011
Scrum e variantes de Scrum
são de longe os mais utilizados
VersionOne

57. STATE OF
AGILE SURVEY
2011
As razões mais comuns para a adoção ágil gira em torno de
tempo de aceleração para o mercado, gereciamento de
mudanças de prioridade e aumento produtividade
VersionOne

58. STATE OF
AGILE SURVEY
2011
Princípios fundamentais ágeis atualmente em uso são Daily Standup, Iteration
Planning e Unit Testing. O mais notável é o uso crescente de Kanban (24%).
VersionOne

59. O Scrum

60. A origem
1995
Jeff Sutherland
Ken Schwaber
1986

61. Se destaca dos demais métodos ágeis pela
ênfase dada ao gerenciamento do projeto

62. Práticas de Engenharia
de d
c lu
t in
No

63. Papéis
do Scrum

64. Product
Product Owner Determina a visão do produto
Owner Define as funcionalidades
Escolhe as datas de release
Dá o feedback
Gerencia os stakeholders
Aceita ou rejeita os resultados
Prioriza de acordo com o ROI

65. Pequenos (5 a 9 pessoas)
Desenvolve as funcionalidades
Auto-organizável
Auto-gerenciável
Multifuncional
Estima o esforço
Defina as tarefas
O Time Responsável pela qualidade

66. Scrum Master
Líder Servidor
Protege o time
Remove impedimentos
Guia do Scrum

67. Como funciona?

68. Então ao invés de um grande grupo gastando
um monte de tempo construindo uma grande
coisa, temos uma equipe pequena gastando um
tempo curto construindo uma pequena coisa.
Mas integrando regularmente para ver o todo.
Henrik Kniberg

69. Product Backlog
Uma lista de coisas que
queremos que sejam
entregues

70. As funcionalidades são
geralmente escritas em
estórias de usuários.

71. Como um <perfil>,
quero <funcionalidade>,
para <valor de negócio>
Como um agente de viagens, quero reservar lugar,
para facilitar o atendimento dos clientes
corporativos

72. O time estima o trabalho
associado a cada estória.

73. As estórias são rankeadas em ordem
de importância pelo product owner.

74. O product owner é o dono do
backlog do produto.

75. Team Velocity

76. Sprint Backlog

77. Executando a Sprint
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Código Testa
Análise Código Testa
Análise Código Testa
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Análise Análise
Código Código Código
Testa Testa Testa

78. Daily Scrum Meeting
• O que você fez ontem?
• O que você fará de hoje
para amanhã?
• Há algum impedimento
em seu caminho?
15
minutos

79. Taskboard

80. Acompanhamento

81. Sprint Burndown

82. Sprint Review

83. Scrum Retrospective

84. Revisando...

85. Scrum of Scrums

86. Mude alguma coisa => Saiba como foi => Aprenda com isso
=> Mude alguma coisa novamente. Falando de um modo
geral, você quer o ciclo de feedback o mais rápido possível,
Scrum + XP e ciclos feedbackfeedback
para que seja possa adaptar o processo rapidamente.
Em Scrum, a iteração básica de um
de é o sprint. Há
mais, porém, especialmente se você combinar com o XP
(eXtreme Programm ing):
Quando feito corretamente, Scrum + XP lhe oferece vários
ciclos de feedback extremamente valiosos.

87. Kanban

88. O Kanban é baseado numa idéia muito simples. As
atividades em andamento devem ser limitadas. Algo
novo só deve ser iniciado quando uma peça de
trabalho existente é liberada ou quando uma função
automática inicia isso.

89. O princípio do Kanban é que você inicia com o que
estiver fazendo agora.

90. Como Funciona?

91. Visualize o fluxo de trabalho
Divida o trabalho em partes,
escreva cada item em um cartão e
coloque na parede
Use colunas nomeadas para
ilustrar onde cada item está no
fluxo de trabalho

92. Limite o trabalho em progresso (WIP
- work in progress)
Associe limites explícitos para quantos itens podem
estar em progresso em cada estado do fluxo de
trabalho

93. Acompanhe o tempo de execução da
tarefa
Tempo médio para completar um item, algumas vezes
chamado de “Lead Time”
Otimize o processo para tornar o tempo de execução o
menor e mais previsível possível.

96. Referências
Lean Software Development: An Agile Toolkit, Mary Poppendieck e Tom Poppendieck, 2003, Addison-
Wesley Professional
Agile Project Management with Scrum, Ken Schwaber, 2004, Microsoft Professional
The Enterprise and Scrum, Ken Schwaber, 2007, Microsoft Press
Kanban e Scrum - obtendo o melhor de ambos, Henrik Kniberg e Mattias Skarin, 2009, C3 Media Inc.
Kanban: Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia, David Anderson,
2011, Blue Hole Press
Agile Estimating and Planning, Mike Cohn, 2005, Prentice Hall
User Stories Applied: For Agile Software Development, Mike Cohn, 2004, Addison-Wesley
Professional
Extreme Programming Explained: Embrace Change (2nd Edition), Kent Beck, 2004, Addison-Wesley
Professional
Test Driven Development, Kent Beck, 2002, Addison-Wesley Professional
Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, 1999, Addison-Wesley
Professional

97. Obrigado!
Eric Cavalcanti
ecavalcanti@gmail.com
@ericoc