O documento discute os processos de engenharia de software tradicionais e ágeis. Ele explica que o método waterfall não funcionou bem para o desenvolvimento de software, já que software é diferente de produtos físicos e requisitos mudam com frequência. Em contraste, métodos ágeis como Scrum e XP enfatizam desenvolvimento iterativo com feedback constante do cliente. O documento também descreve alguns princípios e práticas desses métodos ágeis.

1. 1
Engenharia de Software e Sistemas
Cap. 2 - Processos
Prof. Dr. Thiago Mendes e Prof. Dr. Cleber Lira
thiagosouto@ifba.edu.br, cleberlira@ifba.edu.br
1
Licença CC-BY; créditos para Marco Tulio Valente. Engenharia de Software Moderna: Princípios e Práticas para Desenvolvimento de Software com
Produtividade, 2020 https://engsoftmoderna.info, @engsoftmoderna.

2. Engenharia Tradicional
2
● Civil, mecânica, elétrica, aviação, automobilística, etc
● Projeto com duas características:
○ Planejamento detalhado (big upfront design)
○ Sequencial
● Isto é: Waterfall
○ Há milhares de anos

3. Natural que ES começasse usando Waterfall
3

4. No entanto: Waterfall não funcionou com software!
4

5. Software é diferente
5
● Engenharia de Software ≠ Engenharia Tradicional
● Software ≠ (carro, ponte, casa, avião, celular, etc)
● Software ≠ (produtos físicos)
● Software é abstrato e "adaptável"

6. Dificuldade 1: Requisitos
6
● Clientes não sabem o que querem (em um software)
○ Funcionalidades são "infinitas" (difícil prever)
○ Mundo muda!
● Não dá mais para ficar 1 ano levantando requisitos, 1 ano
projetando, 1 ano implementando, etc
● Quando o software ficar pronto,
ele estará obsoleto!

7. Dificuldade 2: Documentações Detalhadas
7
● Verbosas e pouco úteis
● Na prática, desconsideradas durante implementação
● Plan-and-document não funcionou com software

8. Manifesto Ágil (2001)
8

9. Ideia central: desenvolvimento iterativo
9
Waterfall
Ágil

10. Desenvolvimento iterativo
10
● Suponha um sistema imenso, complexo etc
● Qual o menor "incremento de sistema" eu consigo
implementar em 15 dias e validar com o usuário?
● Validar é muito importante!
● Cliente não sabe o que quer!

11. Reforçando: ágil = iterativo
11

12. Outros pontos importantes (1)
12
● Menor ênfase em documentação
● Menor ênfase em big upfront design
● Envolvimento constante do cliente (product owner)

13. Outros pontos importantes (2)
13
● Novas práticas de programação
○ Testes, refactoring, integração contínua, etc

14. Métodos Ágeis
14

15. Métodos Ágeis
15
● Dão mais consistência às ideias ágeis
○ Definem um processo, mesmo que leve
○ Workflow, eventos, papeis, práticas, princípios etc

16. Métodos Ágeis que Vamos Estudar
16
● Extreme Programming (XP)
● Scrum
● Kanban

17. Antes de começar
17
● Nenhum processo é uma bala-de-prata
● Processo ajuda a não cometer certos "grandes erros"
● Processos não são adotados 100% igual ao manual
○ Bom senso é importante
○ Experimentação é importante

18. Software é um esporte em equipe (daí a importância de
processos)
18
Luis André Barroso, brasileiro que é atualmente VP de
Engenharia do Google (vídeo ~1.5 min)
https://youtu.be/S7A6SYI_nbc

19. Extreme Programming (XP)
19

20. Extreme Programming
20
Kent Beck
1999 2004

21. XP = Valores + Princípios + Práticas
21

22. Valores
22
● Comunicação
● Simplicidade
● Feedback
● Coragem
● Respeito
● Qualidade de Vida (semana 40 hrs)

23. Valores ou "cultura" são fundamentais em software!
23

24. XP = Valores + Princípios + Práticas
24

25. Princípios
25
● Economicidade
● Melhorias Contínuas
● Falhas Acontecem
● Baby Steps
● Responsabilidade Pessoal

26. XP = Valores + Princípios + Práticas
26

27. 27
Iremos estudar em Scrum Testes e TDD = Cap. 8

28. Pair Programming
28

29. Estudo com Engenheiros da Microsoft (2008)
29
● Vantagens:
○ Redução de bugs
○ Código de melhor qualidade
○ Disseminação de conhecimento
○ Aprendizado com os pares
● Desvantagem:
○ Custo

30. (2) Ambiente de Trabalho
30
Ambiente de trabalho Cartazes para "visualizar trabalho"
em andamento

31. Contratos com Escopo Aberto
31
● Escopo fechado
○ Cliente define requisitos ("fecha escopo")
○ Empresa desenvolvedora: preço + prazo
● Escopo aberto
○ Escopo definido a cada iteração
○ Pagamento por homem/hora
○ Contrato renovado a cada iteração

32. Contratos com Escopo Aberto
32
● Exige maturidade e acompanhamento do cliente
● Vantagens:
○ Privilegia qualidade
○ Não vai ser "enganado" ("entregar por entregar")
○ Pode mudar de fornecedor

33. Scrum
33

34. Scrum
34
● Proposto por Jeffrey Sutherland e Ken Schwaber
(OOPSLA 1995)

35. Scrum
35
● Scrum é uma indústria: livros, consultoria, certificações,
marketing

36. Scrum vs XP
36
● Scrum não é apenas para projetos de software
○ Logo, não define práticas de programação, como XP
● Scrum define um "processo" mais rígido que XP
○ Eventos, papéis e artefatos bem claros

37. Principal evento: Sprints
37
● Como em qualquer método ágil, desenvolvimento é
dividido em sprints (iterações)
● Duração de um sprint: até 1 mês, normalmente 15 dias
sprint

38. O que se faz em um sprint?
38
● Implementa-se algumas histórias dos usuários
● Histórias = funcionalidades (ou features) do sistema
● Exemplo: fórum de perguntas e respostas
Bem simples, deve caber em um post-it

39. Quem escreve as histórias?
39
● Product Owner (PO)
● Membro (papel) obrigatório em times Scrum
● Especialista no domínio do sistema

40. Antes (Waterfall)
40
Linguagem natural
(poderia levar anos para ficar pronto)
Stakeholders
Analista de
Requisitos
Devs
Observação: stakeholders são os clientes do sistema e
qualquer outra parte interessada ou afetada por ele.
Exemplo: departamento jurídico é interessado no módulo de
contratos de um sistema

41. Hoje (Scrum)
41
PO Devs
Stakeholders
● Durante sprint, PO explica histórias (requisitos) para devs
● Troca-se documentação formal e escrita por
documentação verbal e informal
● Conversas entre PO e Devs

42. Funções de um PO
42
● Escrever histórias dos usuários
● Explicar histórias para os devs, durante o sprint
● Definir "testes de aceitação" de histórias
● Priorizar histórias
● Manter o backlog do produto

43. Backlog do Produto
43
● Lista de histórias do usuário, que foram escritas pelo PO
● Duas características:
○ Priorizada: histórias do topo têm maior prioridade
○ Dinâmica: histórias podem sair e entrar, à medida que
o sistema evolui

44. Resumindo
44
● Sprint (evento)
● PO e Devs (papeis)
● Backlog do produto (artefato)

45. Quais histórias vão entrar no próximo sprint?
45
● Essa decisão é tomada no início do sprint
● Em uma reunião chamada de planejamento do sprint
● PO propõe histórias que gostaria de ver implementadas
● Devs decidem se têm velocidade para implementá-las

46. Importante
46
● Em um time scrum, todos têm o mesmo nível hierárquico
● PO não é o "chefe" dos Devs
● Devs têm autonomia para dizer que não vão conseguir
implementar tudo que o PO quer em um único sprint

47. Voltando ao Planejamento do Sprint
47
● 1a parte da reunião:
○ Definem-se as histórias do sprint
● 2a parte da reunião:
○ Histórias são quebradas em tarefas
○ Tarefas são alocadas a devs

48. Exemplo:
48
● História: Postar Perguntas
● Tarefas:
○ Projetar e testar a interface Web, incluindo layout, CSS templates, etc.
○ Instalar banco de dados, projetar e criar tabelas.
○ Implementar a camada de acesso a dados.
○ Implementar camada de controle, com operações para cadastrar, remover e
atualizar perguntas.
○ Implementar interface Web.

49. Backlog do Sprint
49
● Lista de tarefas do sprint, com responsáveis e duração
estimada

50. Sprint está pronto para começar!
50

51. Scrum: Conceitos Complementares
51

52. Times Scrum
52
● Pequenos, do tamanho de "duas pizzas"
● 5 a 11 membros
○ 1 PO
○ 3 a 9 desenvolvedores
○ 1 Scrum Master

53. Scrum Master
53
● Especialista em Scrum do time
○ Ajudar o time a seguir Scrum e seus eventos
● Removedor de "impedimentos" não-técnicos
○ Exemplo: desenvolvedores não têm máquinas boas
● Não é o chefe do time
● Pode pertencer a mais de um time

54. Tipos de Product Owner
54
● Sistema acadêmico
● Cliente/contratante: Pró-reitoria de Graduação
● #1: desenv. interno ⇨ PO: funcionário da prograd
● #2: desenv. terceirizado ⇨ PO: funcionário da prograd
● #3: compra produto ⇨ PO: "proxy" do cliente
○ Vendas, marketing, etc
● PO: próximo do problema

55. Mais alguns eventos
55

56. Reuniões Diárias
56
● 15 minutos de duração; em pé. Cada participante diz:
○ o que ele fez ontem
○ o que pretende fazer hoje
○ e se está tendo alguma dificuldade
● Objetivos:
○ Melhorar comunicação
○ Antecipar problemas

57. Sprint termina com dois eventos:
Review e Retrospectiva
57

58. Revisão do Sprint
58
● Time mostra o resultado do sprint para PO e stakeholders
● Implementação das histórias pode ser:
○ Aprovada
○ Aprovada parcialmente
○ Reprovada
● Nos dois últimos casos, história volta
para o backlog do produto

59. Retrospectiva
59
● Último evento do sprint
● Time se reúne para decidir o que melhorar
○ O que deu certo?
○ Onde precisamos melhorar?
● Modelo mental: melhorias constantes
● Não é para "lavar a roupa suja"

60. Resumo em 1 slide
60
fonte: https://www.scrum.org/resources/scrum-framework-reduce-risk-and-deliver-value-sooner

61. Mais alguns conceitos de Scrum
61

62. Time-box
62
● Atividades têm uma duração bem definida

63. Critérios para Conclusão de Histórias (done criteria)
63
● Importante: considerar qualidade externa e interna
● Qualidade externa:
○ Testes de aceitação (caixa preta ou funcionais)
○ Testes não-funcionais (ex.: desempenho, usabilidade)
● Qualidade interna:
○ Testes de unidade
○ Revisão de código

64. Mais alguns artefatos de Scrum
64

65. Scrum Board
65

66. Scrum Board
66

67. Exemplo: projeto da Mozilla (usando GitHub Projects)
67

68. Exemplo: GitLab (https://gitlab.com/gitlab-org/gitlab/-/boards)
68

69. Burndown chart
69

70. Estimativa de Tamanho de Histórias de Usuários
70

71. Story points
71
● Unidade (inteiro) para comparação do tamanho de
histórias. Exemplo de escala: 1, 2, 3, 5, 8, 13

72. Velocidade de um time
72
● Número de story points que o time consegue implementar
em um sprint
● Definição de story points é "empírica"

73. Kanban
73

74. Kanban
74
● Origem na década de 50 no Japão
● Sistema de Produção da Toyota
● Manufatura Lean
● Produção just-in time

75. Kanban = "cartão visual"
75

76. Kanban em Desenvolvimento de Software
76

77. Kanban vs Scrum
77
● Kanban é mais simples
● Não existem sprints
● Não é obrigatório usar papéis e eventos, incluindo:
○ Scrum master
○ Daily Scrum, Retrospectivas, Revisões
○ etc
● Time define os papéis e eventos

78. Kanban
78
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec. especificadas em implementação implementadas em revisão revisadas
"Grandes" colunas do quadro:
Passos
1a sub-coluna:
em andamento
2a sub-coluna:
concluídas
Fluxo de trabalho (tempo)

79. Kanban
79
● Ideia central: sistema pull
● Membros "puxam" trabalho:
a. Escolhem uma tarefa para trabalhar
b. Concluem tarefa (movem ela para frente no quadro)
c. Volte para o passo (a)

80. 80
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
🗅
em espec. especificadas em implementação implementadas em revisão revisadas
tempo

81. 81
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
🗅
em espec. especificadas em implementação implementadas em revisão revisadas
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec.
🗅
especificadas em implementação implementadas em revisão
tempo

82. 82
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
🗅
em espec. especificadas em implementação implementadas em revisão revisadas
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec.
🗅
especificadas em implementação implementadas em revisão
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec. especificadas
🗅 🗅 🗅 🗅
em implementação implementadas em revisão revisadas
tempo

83. 83
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec. especificadas
🗅 🗅 🗅 🗅
em implementação implementadas em revisão revisadas
tempo
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec. especificadas
🗅 🗅 🗅
em implementação
🗅
implementadas em revisão revisadas
Backlog Especificação
WIP
Implementação
WIP
Revisão de Código
WIP |
em espec. especificadas
🗅 🗅🗅
em implementação implementadas
🗅
em revisão

84. Exemplo 2
84

85. Exemplo 2: Ontem no final do dia
85
Hoje no final do dia:

86. Kanban: Limites WIP
86

87. Limites WIP (Work in Progress)
87

88. Limites WIP (Work in Progress)
88
● Número máximo de tarefas em um passo
● Contando: tarefas em andamento e concluídas
4 0

89. Objetivos dos Limites WIP
89
● Criar um fluxo de trabalho sustentável
○ Evitar que o time fique sobrecarregado de trabalho
○ WIP = "acordo" entre o time e a organização
○ Capacidade de trabalho de um time
● Evitar que o trabalho fique concentrado em um passo

90. Exemplo de violação de WIP
90
Backlog Especificação (2) Implementação (5) Validação (3)
X
X
X
X
X
X
● Esse quadro não é válido
● Existem 6 tarefas em Implementação
● Mas o WIP desse passo é 5

91. Mais um exemplo: Implementação no limite
91
Backlog Especificação (2) Implementação (5) Revisão (3)
X
X
X
X
X
● Talvez seja o momento de revisar algumas tarefas

92. WIP do Passo de Especificação
92
● Número de histórias em especificação + número de
grupos de tarefas especificadas (linhas do quadro)
● Tarefas na mesma linha = resultantes da mesma história
0 +1 +1

93. WIP de Revisão de Código
93
● Conta apenas tarefas na primeira coluna (em revisão)
1 Não contam para
fins de WIP

94. Comentários Finais sobre Kanban
94
● Kanban é mais simples do que Scrum
● Kanban é mais adequado para times mais maduros
● Talvez: começar com Scrum e depois migrar para Kanban

95. Quando não usar métodos ágeis?
95

96. Quando não vale a pena usar métodos ágeis
● Condições do mercado são estáveis e previsíveis
● Requisitos são claros no início do projeto e irão permanecer estáveis
● Clientes não estão disponíveis para colaboração frequente
● Sistema semelhante já foi feito antes; logo, já se conhece a solução
● Problemas podem ser resolvidos sequencialmente, em silos funcionais
● Clientes não conseguem testar partes do produto, antes de completo
● Mudanças no final do projeto são caras ou impossíveis
● Impacto de mudanças provisórias pode ser catastrófico
Fonte: Embracing Agile. Rigby, Sutherland & Takeuchi. Harvard Business Review, 2016

97. Outros Processos (não ágeis)
97

98. Transição de Waterfall para Ágil
● Antes da disseminação dos princípios ágeis, alguns
métodos iterativos ou evolucionários foram propostos
● Transição Waterfall (~1970) e Ágil (~2000) foi gradativa
● Exemplos:
○ Espiral (1986)
○ Rational Unified Process (RUP) (2003)
98

99. Modelo em Espiral Proposto por Barry Boehm
Iterações: 6 a 24 meses (logo,
mais que em XP ou Scrum)
99

100. Rational Unified Process (RUP)
● Proposto pela Rational, que depois comprada pela IBM
● Duas características principais:
○ Diagramas UML
○ Ferramentas CASE
100

101. CASE (Computer-Aided Software Engineering)
101
Nome vem de sistemas de CAD
(usados em engenharia tradicional)

102. Fases do RUP
102
● Inception: análise de viabilidade
● Elaboração: requisitos + arquitetura
● Construção: projeto de baixo nível + implementação
● Transição: implantação (deployment)

103. FIM
103