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

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

30

Programação Pareada e

Revisão de Código com IA

31

32

Junho de 2021, logo antes do ChatGPT

https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/

Pareamento com IA (via auto-complete)

33

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

Pareamento com IA (via revisão de código)

34

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

35

https://claude.com/blog/code-review

36

Síncrono

Assíncrono

Humanos

Automatizada

Contratos de Software

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

37

Contratos com Escopo Fechado

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

38

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.

39

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

40

Exercícios sobre XP

​

41

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

​

​

​

42

Scrum

​

43

Scrum

• Proposto por Jeffrey Sutherland e Ken Schwaber

44

OOPSLA 1995

Scrum

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

45

Principal evento: Sprints

46

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

​

47

Quem escreve as histórias?

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

​

48

Antes: Waterfall

49

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

50

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

​

52

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…

​

​

53

Resumindo

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

​

​

54

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

​

​

55

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

​

​

56

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

​

​

57

Exemplo: fórum de perguntas e respostas

58

Backlog do Produto

59

Histórias do Sprint

60

Backlog do Sprint

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

​

61

Relação entre backlog do sprint e modelos de IA

62

63

Algumas dessas tarefas vão virar prompts

Backlog do sprint

Sprint está pronto para começar!

64

Times e Papéis de Scrum

65

Times Scrum

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

66

Times Scrum

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

​

67

Qual o impacto de IA na organização dos times Scrum?

68

Hipótese: times menores

• Com IA, devs vão ficar mais produtivos
• Logo, algumas tarefas serão delegadas para IA

​

69

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
• Coletar métricas de processo
• Não é o chefe do time, mas um “líder servidor”
• Pode pertencer a mais de um time

​

70

Mais alguns eventos

71

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

​

72

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

Sprint termina com dois eventos:

Review e Retrospectiva

73

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

​

74

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"

​

​

75

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

​

​

76

Exercícios

2.

(a) Quais são os 2 papéis mandatórios em times Scrum?

(b) Quais são os 4 eventos mandatórios em um sprint Scrum?

(c) Quais são os 2 artefatos mandatórios em Scrum?

​

77

Mais alguns conceitos de Scrum

78

Time-box

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

​

​

79

80

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)

​

​

81

Scrum Board

82

Exemplo: projeto da Mozilla (usando GitHub Projects)

83

Story Points

84

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

​

85

Escala de story points

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

​

86

Exemplo

87

Definido pelos devs do time

Resumo em 1 slide

88

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

Exercícios sobre Scrum

89

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?

​

90

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.

​

​

91

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

​

​

​

92

Kanban

93

Kanban

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

94

kanban = "cartão visual"

95

Kanban em Desenvolvimento de Software

96

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

​

97

Kanban

98

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

​

99

100

tempo

101

tempo

102

tempo

103

tempo

Exemplo 2

104

Ontem no final do dia

105

Ontem no final do dia

Hoje no final do dia

​

106

Kanban: Limites WIP

107

Limites WIP (Work in Progress)

108

Limites WIP (Work in Progress)

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

109

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

110

Frase comum em Kanban:

​

“pare de começar e comece a terminar”

111

Mais um exemplo: Implementação no limite

• Logo, é o momento de revisar algumas tarefas

112

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

​

113

0

+1

+1

WIP de Revisão de Código

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

​

114

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

115

Exercícios sobre Kanban

​

​

116

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

117

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?

​

​

118

Antes de concluir

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

​

119

Exercícios

​

​

120

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.

121

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.

​

122

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.

​

123

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.

Descreva então outros itens de trabalho que podem fazer parte do backlog do produto.

124

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

• Escopo (requisitos)
• Tempo (prazo)
• 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?

125

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

126

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

127

Fim

​

​

128