Engenharia de Software Moderna

​

Cap. 2 - Processos

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info

1

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Engenharia Tradicional

• 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

​

​

2

Natural que ES começasse usando Waterfall

3

No entanto: Waterfall não funcionou com software!

4

Software é diferente

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

​

5

Dificuldade 1: Requisitos

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

​

​

6

Dificuldade 2: Documentações Detalhadas

• Verbosas e pouco úteis
• Na prática, desconsideradas durante implementação
• Plan-and-document não funcionou com software

​

​

​

7

Manifesto Ágil (2001)

8

Ideia central: desenvolvimento iterativo

9

Waterfall

Ágil

Desenvolvimento iterativo

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

10

Reforçando: ágil = iterativo

11

Outros pontos importantes (1)

• Menor ênfase em documentação
• Menor ênfase em big upfront design
• Envolvimento constante do cliente

12

Outros pontos importantes (2)

• Novas práticas de programação
• Testes, refactoring, integração contínua, etc

13

Métodos Ágeis

14

Agilidade = aprendizado + geração de valor contínuos

​

15

16

Devs

Clientes

aprendizado

valor

(resolver problemas

usando software)

Métodos Ágeis que Vamos Estudar

• Extreme Programming (XP)
• Scrum
• Kanban

17

Extreme Programming (XP)

18

Extreme Programming

19

Kent Beck

1999

2004

XP = Valores + Princípios + Práticas

20

Valores

• Comunicação
• Simplicidade
• Feedback
• Coragem
• Respeito
• Qualidade do Ambiente de Trabalho

21

Valores ou cultura são fundamentais em software!

22

XP = Valores + Princípios + Práticas

23

Princípios

• Viabilidade econômica
• Melhorias Contínuas
• Falhas Acontecem
• Baby Steps
• Responsabilidade

​

24

XP = Valores + Princípios + Práticas

25

26

Iremos estudar em Scrum

Testes e TDD = Cap. 8

CI = Cap. 10

Pair Programming

27

Exercício

• Quais as vantagens de pair programming?
• E a principal desvantagem?

28

Mob Programming

• Time inteiro trabalhando na mesma tarefa de programação
• Qual o principal “caso de uso” de mob programming?

​

29

https://www.chrislucian.com/2019/09/mob-programming-financial-benefits.html

Alternativas a Pair Programming

30

Pull Requests + Revisão de Código (assíncrona)

31

AI Pairing (via auto-complete)

32

https://code.visualstudio.com/docs/copilot/ai-powered-suggestions

AI Pairing (via revisão de código)

33

jobs:

….

- name: Automatic PR Review

uses: anthropics/claude-code-action@beta

with:

anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

timeout_minutes: "60"

direct_prompt: |

Please review this pull request and provide comprehensive feedback.

​

Focus on:

- Code quality and best practices

- Potential bugs or issues

- Performance considerations

- Security implications

- Test coverage

- Documentation updates if needed

Executado automaticamente sempre que um novo PR for aberto em um repositório

Contratos de Software

• Contratos de software podem ser de dois tipos:
• Escopo Fechado
• Escopo Aberto (defendidos por XP)

34

Contratos com Escopo Fechado

• Cliente: requisitos ("fecha escopo")
• Empresa: preço + prazo

35

Contratos com Escopo Aberto

• A empresa CONTRATADA fornecerá [x] programadores para desenvolver um sistema [y] para a empresa CONTRATANTE, ao custo de [z] reais por mês.
• Este contrato será renovado a cada mês, a não ser que uma das partes decida cancelá-lo.

36

Contratos com Escopo Aberto

• Exige maturidade e acompanhamento do cliente
• Vantagens:
• Privilegia qualidade
• Não vai ser enganado ("entregar por entregar")
• Pode mudar de fornecedor

37

Exercícios sobre XP

​

38

1. Por que XP é um método voltado apenas para projetos de software?

​

​

​

39

Scrum

​

40

Scrum

• Proposto por Jeffrey Sutherland e Ken Schwaber

41

OOPSLA 1995

Scrum

• Scrum é uma indústria: livros, consultoria, certificações, etc

42

Principal evento: Sprints

43

Sprint 1

Sprint 2

Sprint 3

Sprint 4

…

Sistema

Sistema

Sistema

novas

funcionalidades

15 dias

O que se faz em um sprint?

• Implementa-se algumas histórias dos usuários
• Histórias = funcionalidades do sistema
• Exemplo: fórum de perguntas e respostas

​

44

Quem escreve as histórias?

• Product Owner (PO)
• Papel obrigatório em times Scrum
• Especialista no domínio do sistema

​

45

Antes: Waterfall

46

Linguagem natural

(poderia levar anos para ficar pronto)

Stakeholders

Analista de Requisitos

Devs

consulta

escreve

implementa

Hoje: Scrum

• Durante sprint, PO explica histórias para devs
• Troca-se documentação formal/escrita por informal/verbal
• Conversas entre PO e devs

47

PO

Devs

Stakeholders

Hoje ...

Product Owner senta junto dos desenvolvedores e explica requisitos para eles

PO

Devs

Funções de um PO

• Escrever histórias dos usuários
• Explicar histórias para os devs
• Definir "testes de aceitação" de histórias
• Priorizar histórias

​

49

Backlog do Produto

• Lista de histórias do usuário
• E outros itens de trabalho importantes
• Duas características:
• Priorizada: histórias do topo têm maior prioridade
• Dinâmica: histórias podem sair e entrar…

​

​

50

Resumindo

• Iteração: sprint
• Papéis: PO e Devs
• Artefato: backlog do produto

​

​

51

Quais histórias vão entrar no próximo sprint?

• 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

​

​

52

Importante

• 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

​

​

53

Voltando ao Planejamento do Sprint

• 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

​

​

54

Exemplo: fórum de perguntas e respostas

55

Backlog do Produto

56

Histórias do Sprint

57

Backlog do Sprint

• Lista de tarefas do sprint (com responsáveis e duração)

​

58

Sprint está pronto para começar!

59

Times e Papéis de Scrum

60

Times Scrum

• Pequenos (time de basquete a um time de futebol)
• 5 a 11 membros, sendo 1 PO e 1 Scrum Master

61

Times Scrum

• Multidisciplinares: devs, designers, cientistas de dados, etc
• Times ágeis são chamados, com frequência, de squads

​

62

Scrum Master

• Especialista em Scrum: ajuda o time a adotar Scrum
• Removedor de impedimentos não-técnicos
• Exemplo: desenvolvedores não têm máquinas boas
• Pode também coletar métricas de processo
• Não é o chefe do time, mas um “líder servidor”
• Pode pertencer a mais de um time

​

63

Mais alguns eventos

64

Reuniões Diárias

• 15 minutos de duração. 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

​

65

Os eventos Scrum são às vezes chamados, por alguns times, de rituais.

Sprint termina com dois eventos:

Review e Retrospectiva

66

Revisão do Sprint

• 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

​

67

Retrospectiva

• Ú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"

​

​

68

Exercícios

1. Por que Scrum é definido como sendo um framework?

Por exemplo, veja a definição do Scrum Guide: "Scrum é um framework leve que ajuda pessoas, equipes e organizações a gerar valor por meio de soluções adaptativas para problemas complexos."

• Por que ele é considerado também um framework leve (lightweight)?

​

​

69

Mais alguns conceitos de Scrum

70

Time-box

• Eventos têm uma duração bem definida

​

​

71

72

Critérios para Conclusão de Histórias (done criteria)

• Critérios internos para considerar histórias prontas
• Exemplos:
• Testes de unidade com cobertura ≥ 75%
• Revisão de código por outro dev do time
• Atualizar documentação (se alguma API mudou)
• Teste de performance (para certas histórias)

​

​

73

Scrum Board

74

Exemplo: projeto da Mozilla (usando GitHub Projects)

75

Story Points

76

Story Points

• Usados para estimar o tamanho de histórias
• Ajudar a definir o que vai “caber” no sprint
• Uso não é obrigatório em Scrum
• Definição de story points é "empírica"

​

77

Escala de story points

• Mais comum: 1, 2, 3, 5, 8, 13, …
• Velocidade: número de story points que consegue implementar em um sprint

​

78

Exemplo

79

Definido pelos devs do time

Resumo em 1 slide

80

fonte: https://www.scrum.org/resources/scrum-framework-reduce-risk-and-deliver-value-sooner

Exercícios sobre Scrum

81

1. Qual a diferença entre as histórias do topo e do fundo do backlog do produto?
2. Suponha que você vai escrever um livro e pretende usar Scrum para gerenciar esse projeto.
• Qual seria o objetivo dos sprints?
• Quais os itens do backlog do produto?
• Quais os itens do backlog do sprint?
• Faria sentido ter “sprint review”? Se sim, como?
• Faria sentido ter um PO?

​

82

3. Suponha dois times, A e B, atuando em projetos diferentes, contratados por empresas distintas:

• Ambos adotam sprints de 15 dias
• Ambos possuem 5 devs
• O time A considera que sua velocidade é de 24 pontos
• Já o time B possui uma velocidade de 16 pontos

Pode-se afirmar que A é 50% mais produtivo que B? Justifique sua resposta.

​

​

83

4. Suponha um editor de textos com duas histórias:

• Abrir arquivo (H1)
• Editar arquivo (H2)

O PO priorizou, de forma bastante firme, H2 para um sprint e H1 para um sprint seguinte.

• O que faria nesse caso? Seguiria a prioridade do PO?
• Se sim, como implementaria a edição de um arquivo (H2), sem antes implementar a sua abertura (H1)?

​

​

​

84

Kanban

85

Kanban

• Origem na década de 50 no Japão
• Sistema de Produção da Toyota
• Manufatura lean, produção just-in time, etc

86

kanban = "cartão visual"

87

Kanban em Desenvolvimento de Software

88

Kanban vs Scrum

• Kanban é mais simples
• Não existem sprints
• Não é obrigatório usar papéis e eventos, incluindo:
• Scrum master
• Daily Scrum, retrospectivas, revisões
• Time define os papéis e eventos

​

89

Kanban

90

"Grandes" colunas do quadro:

Passos

1a sub-coluna:

em andamento

2a sub-coluna:

concluídas

Fluxo de trabalho (tempo)

Iremos explicar daqui a pouco o que significa WIP

Kanban

• Ideia central: sistema pull
• Membros "puxam" trabalho:
1. Escolhem uma tarefa para trabalhar
2. Concluem tarefa (movem ela para frente no quadro)
3. Voltam para o passo (a)

​

91

92

tempo

93

tempo

94

tempo

95

tempo

Exemplo 2

96

Ontem no final do dia

97

Ontem no final do dia

Hoje no final do dia

​

98

Kanban: Limites WIP

99

Limites WIP (Work in Progress)

100

Limites WIP (Work in Progress)

• Número máximo de tarefas em um passo, contando tarefas em andamento e concluídas

101

4

0

Objetivos dos Limites WIP

• 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

102

Frase comum em Kanban:

​

“pare de começar e comece a terminar”

103

Mais um exemplo: Implementação no limite

• Logo, é o momento de revisar algumas tarefas

104

WIP do Passo de Especificação

• 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

​

105

0

+1

+1

WIP de Revisão de Código

• Conta apenas tarefas na primeira coluna (em revisão)

​

106

1

Não contam para

fins de WIP

Comentários Finais sobre Kanban

• Kanban é mais simples do que Scrum
• Kanban é mais adequado para times maduros
• Talvez, começar com Scrum e depois ir para Kanban

107

Exercícios sobre Kanban

​

​

108

1. Qual é o erro que existe no seguinte quadro Kanban?

109

2. É possível voltar com o cartão em um quadro Kanban? Se sim, descreva uma situação na qual isso pode ocorrer.

3. Um dos problemas comuns em times de software é o excesso de trabalho. Como Kanban pode ajudar a resolver esse problema?

4. Um outro problema em times de software são desenvolvedores que "correm" para entregar histórias, mas sem o devido nível de qualidade. Como Kanban pode ajudar a resolver esse problema?

​

​

110

Outros Processos (não ágeis)

​

​

111

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)

​

​

​

112

Modelo em Espiral

Proposto por Barry Boehm

Iterações: 6 a 24 meses (logo, mais que em XP ou Scrum)

​

113

Rational Unified Process (RUP)

• Proposto pela Rational, depois comprada pela IBM
• Duas características principais:
• Diagramas UML
• Ferramentas CASE

114

CASE (Computer-Aided Software Engineering)

115

Nome vem de sistemas de CAD (usados em engenharia tradicional)

Antes de concluir

• Processos não são adotados 100% igual ao manual
• Bom senso é importante
• Experimentação é importante

​

116

Veja também o FAQ do Capítulo 2

​

https://engsoftmoderna.info/faq/processos-faq.html

117

Exercícios

​

​

118

1. O seguinte slide resume métodos ágeis em três áreas: processos, excelência técnica e cultura. No entanto, em cada uma delas, existe uma característica que NÃO é compatível com os princípios de agilidade. Indique tais características.

119

2. Suponha que você trabalha em um Banco X e ficou encarregado pela implantação do PIX no mesmo. Então, sua primeira decisão foi montar um squad para ficar responsável por essa funcionalidade. Você decidiu também que esse squad deveria usar Scrum. Responda então:

(a) Quais profissionais você deve contratar ou convidar para esse squad? Qual a responsabilidade deles?

(b) Suponha que o projeto foi concluído com sucesso. Meses depois, o Banco Central baixou a seguinte regra: transferências via PIX entre 20:00 e 06:00 devem obedecer ao limite de R$ 1.000,00. Qual seria o papel de cada membro do time na implementação dessa nova regra? Descreva de forma simplificada.

​

120

3. Suponha que a UFMG pretende migrar para um novo sistema de apoio ao ensino, que irá substituir o Moodle. Ela está cogitando três estratégias:

(a) construir o novo sistema internamente, usando devs que são funcionários da universidade.

(b) terceirizar o desenvolvimento com uma agência ou fábrica de software.

(c) comprar ou assinar algum produto disponível no mercado.

Suponha que o sistema nas três alternativas será (ou foi) desenvolvido usando Scrum. Então, descreva o perfil de PO (Product Owner) mais adequado para cada uma delas.

​

121

4. Ao comentar sobre os itens dos backlogs de Scrum, demos ênfase a histórias de usuários. Porém, elas não são os únicos itens possíveis em um backlog. Por exemplo, suponha os seguintes tipos de bugs:

(a) Um bug detectado durante a implementação de uma história de um sprint.

(b) Um bug não crítico reportado por um usuário do sistema.

(c) Um bug crítico que está impactando diversos usuários do sistema.

Como esses bugs deveriam ser tratados por um time que usa Scrum?

122

5. Essa questão é semelhante à anterior, porém focando em refatorações. Suponha então os seguintes tipos de refatorações:

(a) Uma refatoração que pode ser realizada em menos de uma hora.

(b) Uma refatoração complexa que envolve mudanças no projeto e arquitetura do sistema.

Como esses tipos de refatorações deveriam ser tratados por um time que usa Scrum?

123

6. Existem quatro variáveis importantes em contratos de software:

• Escopo
• Tempo
• Custo
• Qualidade

XP argumenta que é impossível fixar todas essas quatro variáveis por meio de um contrato, pois surpresas vão acontecer durante o projeto.

Suponha então um contrato com escopo fechado. Se ocorrer uma surpresa ao longo do projeto, qual dessas variáveis tende a ser sacrificada pela empresa contratada a fim de evitar multas?

124

7. Suponha que você é o líder técnico (tech lead) de um time.

E os desenvolvedores estão reclamando que não conseguem usar certos módulos do sistema devido à documentação desatualizada da interface pública dos mesmos.

Ao investigar a questão, você descobriu que os devs, com frequência, alteram a interface dos módulos, porém não atualizam a documentação.

Supondo que o time usa Scrum, qual medida você tomaria para evitar a ocorrência desse problema?

125

8. Em Engenharia de Software, anti-patterns são padrões não recomendados para um certo problema.

Descreva então três anti-patterns de Product Owner (PO).

126

Fim

​

​

127