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

31

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)

32

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

33

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

34

Síncrono

Assíncrono

Humanos

Automatizada

Contratos de Software

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

35

Contratos com Escopo Fechado

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

36

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.

37

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

38

Exercícios sobre XP

​

39

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

​

​

​

40

Scrum

​

41

Scrum

• Proposto por Jeffrey Sutherland e Ken Schwaber

42

OOPSLA 1995

Scrum

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

43

Principal evento: Sprints

44

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

​

45

Quem escreve as histórias?

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

​

46

Antes: Waterfall

47

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

48

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

​

50

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…

​

​

51

Resumindo

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

​

​

52

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

​

​

53

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

​

​

54

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

​

​

55

Exemplo: fórum de perguntas e respostas

56

Backlog do Produto

57

Histórias do Sprint

58

Backlog do Sprint

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

​

59

Sprint está pronto para começar!

60

Times e Papéis de Scrum

61

Times Scrum

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

62

Times Scrum

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

​

63

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

​

64

Mais alguns eventos

65

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

​

66

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

Sprint termina com dois eventos:

Review e Retrospectiva

67

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

​

68

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"

​

​

69

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

​

​

70

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?

​

71

Mais alguns conceitos de Scrum

72

Time-box

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

​

​

73

74

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)

​

​

75

Scrum Board

76

Exemplo: projeto da Mozilla (usando GitHub Projects)

77

Story Points

78

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

​

79

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

​

80

Exemplo

81

Definido pelos devs do time

Resumo em 1 slide

82

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

Exercícios sobre Scrum

83

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?

​

84

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.

​

​

85

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

​

​

​

86

Kanban

87

Kanban

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

88

kanban = "cartão visual"

89

Kanban em Desenvolvimento de Software

90

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

​

91

Kanban

92

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

​

93

94

tempo

95

tempo

96

tempo

97

tempo

Exemplo 2

98

Ontem no final do dia

99

Ontem no final do dia

Hoje no final do dia

​

100

Kanban: Limites WIP

101

Limites WIP (Work in Progress)

102

Limites WIP (Work in Progress)

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

103

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

104

Frase comum em Kanban:

​

pare de começar e comece a terminar

105

Mais um exemplo: Implementação no limite

• Logo, é o momento de revisar algumas tarefas

106

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

​

107

0

+1

+1

WIP de Revisão de Código

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

​

108

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

109

Exercícios sobre Kanban

​

​

110

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

111

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?

​

​

112

Antes de concluir

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

​

113

Exercícios

​

​

114

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.

115

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.

​

116

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.

​

117

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.

118

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?

119

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?

120

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

121

Fim

​

​

122