revisitando as práticas de engenharia Ágil

Revisitando as práticas de engenharia ágil

Danilo Sato@dtsato

Danilo Sato@dtsato - www.dtsato.com

Desenvolvedor, Arquiteto, Coach, DevOps, Treinador

Agile virou mainstream

Fonte: VersionOne State of Agile (2012)Referência: http://www.versionone.com/state-of-agile-survey-results/

Fonte: VersionOne State of Agile (2012)Referência: http://www.versionone.com/state-of-agile-survey-results/

Scrum + Kanban = 72% ~ 75%

Fonte: VersionOne State of Agile (2012)Referência: http://www.versionone.com/state-of-agile-survey-results/

Scrum + Kanban = 72% ~ 75%

4% “Não Sei” ?!

Fonte: VersionOne State of Agile (2012)Referência: http://www.versionone.com/state-of-agile-survey-results/

Scrum + Kanban = 72% ~ 75%

XP = 2% ~ 7%

Práticas gerenciais

práticas de engenharia

Práticas gerenciais

práticas de engenharia

Práticas gerenciais

práticas de engenharia

http://www.flickr.com/photos/donnieray/9436653177

3 pilares

Gerir um negócio sustentável

Liderar e promover a excelência de

software e revolucionar a indústria de TI

Gerir um negócio sustentável

Liderar e promover a excelência de

software e revolucionar a indústria de TI

Advogar apaixonadamente em favor de justiça social e econômica

Gerir um negócio sustentável

falta de práticas de

engenharia é uma barreira

não atingimos o potencial de

agile

opotencial de

agile

opotencial de

agile

Leak!

Vazar!

por que falarde práticas?

http://www.dtsato.com/blog/2007/08/14/chega-de-processos/

princípios

vs.

práticas

princípios

vs.

práticas

princípios

vs.

práticas

Valores + Princípios

práticas

práticas

“O que você faz quando está sob pressão"

-- Corey Haines

Programação Extrema (XP)

Programação Extrema (XP)

Práticas deEngenharia

práticas

• dependentes

práticas

• dependentes• complementares

práticas

Entrega contínuacolaboração

testes automatizados design

originadas em XP

Entrega contínuacolaboração

testes automatizados design

TDD

testes automatizados

originadas em XP

Entrega contínuacolaboração

testes automatizados design

TDD

testes automatizados

design incremental

refatoraçãometáfora

linguagem ubíquaTDD

originadas em XP

Entrega contínuacolaboração

testes automatizados design

TDD

testes automatizados

design incremental

refatoraçãometáfora

linguagem ubíquaTDD

propriedade coletiva de código

standards de código

programação pareada

gerenciar dívida técnica

desenvolvimento no trunkoriginadas em XP

Entrega contínuacolaboração

testes automatizados design

TDD

testes automatizados

design incremental

refatoraçãometáfora

linguagem ubíquaTDD

desenvolvimento no trunk

integração contínua

pipeline de implantação

implantação automatizada

infraestrutura como código

propriedade coletiva de código

standards de código

programação pareada

gerenciar dívida técnica

desenvolvimento no trunkoriginadas em XP

testes automatizados

http://www.flickr.com/photos/dancoulter/21042744

Exploratório

Ponta a Ponta

Aplicação/Componentes

Integração

Unitários

cobertura por

teste / tempo de execução

feedbackrápido

Testes Automatizados

Testes Automatizados

• Comportamentos:

Testes Automatizados

• Comportamentos:

• O time possui uma clara estratégia de testes

Testes Automatizados

• Comportamentos:

• O time possui uma clara estratégia de testes

• Testes funcionais seguem user journeys e não por história

Testes Automatizados

• Comportamentos:

• O time possui uma clara estratégia de testes

• Testes funcionais seguem user journeys e não por história

• Testes reproduzem bug no nível certo antes de corrigí-lo

Testes Automatizados

• Comportamentos:

• O time possui uma clara estratégia de testes

• Testes funcionais seguem user journeys e não por história

• Testes reproduzem bug no nível certo antes de corrigí-lo

• Tempo necessário para realizar testes manuais reduzido

Testes Automatizados

• Comportamentos:

• O time possui uma clara estratégia de testes

• Testes funcionais seguem user journeys e não por história

• Testes reproduzem bug no nível certo antes de corrigí-lo

• Tempo necessário para realizar testes manuais reduzido

• Problemas são encontrados rapidamente, perto do momento onde são introduzidos

TDD

TDD

• Comportamentos:

TDD

• Comportamentos:

• Testes atuam como documentação executável do código

TDD

• Comportamentos:

• Testes atuam como documentação executável do código

• Bom design OO: comportamento bem encapsulado e clara dependência entre classes

TDD

• Comportamentos:

• Testes atuam como documentação executável do código

• Bom design OO: comportamento bem encapsulado e clara dependência entre classes

• Testes unitários executam rapidamente: 1000s em poucos segundos

TDD

• Comportamentos:

• Testes atuam como documentação executável do código

• Bom design OO: comportamento bem encapsulado e clara dependência entre classes

• Testes unitários executam rapidamente: 1000s em poucos segundos

• Uso justo de mocks: mocks não duplicam comportamento do código

Design

Código==Design

Código==

Estrutura

Organização

FlexibilidadeTestabilidade

Legibilidade

Coesão

Acoplamento

Dependências

Design

BOM reduz ocusto da mudança

Design

Design

Hipótese da stamina do Design

Func

iona

lidad

es

Tempo

Func

iona

lidad

es

Tempo

Sem Design

Func

iona

lidad

es

Tempo

Bom Design

Sem Design

Func

iona

lidad

es

Tempo

Bom Design

Sem DesignOnde o design

se paga

ZeroDesign

DesignÁgil

Up-frontDesign

Design “ativo”

Design “passivo”

Design ágil == Design evolutivo

Design ágil == Design evolutivo

Design Ágil

Design Ágil

• Comportamentos:

Design Ágil

• Comportamentos:

• Código é fácil de ser testado

Design Ágil

• Comportamentos:

• Código é fácil de ser testado

• Quando mudanças são necessárias, refatoração acontece antes para que a mudança seja simples

Design Ágil

• Comportamentos:

• Código é fácil de ser testado

• Quando mudanças são necessárias, refatoração acontece antes para que a mudança seja simples

• Time reconhece a diferença entre complexidade essencial e acidental

Design Ágil

• Comportamentos:

• Código é fácil de ser testado

• Quando mudanças são necessárias, refatoração acontece antes para que a mudança seja simples

• Time reconhece a diferença entre complexidade essencial e acidental

• Gerenciamento de dívida técnica para reduzir complexidade acidental

Refatoração

Refatoração

• Comportamentos:

Refatoração

• Comportamentos:

• Desenvolvedores familiarizados com refatorações automatizadas na IDE

Refatoração

• Comportamentos:

• Desenvolvedores familiarizados com refatorações automatizadas na IDE

• Refatoração acontece quando os testes estão passando

Refatoração

• Comportamentos:

• Desenvolvedores familiarizados com refatorações automatizadas na IDE

• Refatoração acontece quando os testes estão passando

• Refatorações são pequenas e incrementais

Refatoração

• Comportamentos:

• Desenvolvedores familiarizados com refatorações automatizadas na IDE

• Refatoração acontece quando os testes estão passando

• Refatorações são pequenas e incrementais

• Código de teste também é refatorado

Refatoração

• Comportamentos:

• Desenvolvedores familiarizados com refatorações automatizadas na IDE

• Refatoração acontece quando os testes estão passando

• Refatorações são pequenas e incrementais

• Código de teste também é refatorado

• Desenvolvedores sabem dividir refatorações grandes em pedaços menores

Linguagem Ubíqua

• Metáfora:

• Nem sempre é necessária

• Difícil de encontrar

• Domain-Driven Design

• Objetivo é melhorar comunicação com especialistas de domínio

https://github.com/npryce/code-words

Linguagem Ubíqua

Linguagem Ubíqua

• Comportamentos:

Linguagem Ubíqua

• Comportamentos:

• Código de produção e de testes usam terminologia uniforme, alinhada com o domínio

Linguagem Ubíqua

• Comportamentos:

• Código de produção e de testes usam terminologia uniforme, alinhada com o domínio

• Conceitos em um domínio possuem sentido claro dentro de um Contexto Delimitado

Linguagem Ubíqua

• Comportamentos:

• Código de produção e de testes usam terminologia uniforme, alinhada com o domínio

• Conceitos em um domínio possuem sentido claro dentro de um Contexto Delimitado

• Conceitos são bem entendidos por toda a equipe (desenvolvedores, analistas, QAs, clientes, gerentes, etc.)

colaboração

http://www.flickr.com/photos/johncarleton/5355691631

http://www.flickr.com/photos/johncarleton/5355691631

Programação Pareada

• Benefícios:

• Foco

• Revisão de código constante

• Resultado é maior que a soma das partes

Programação Pareada

Programação Pareada

• Comportamentos:

Programação Pareada

• Comportamentos:

• Ao parear, papéis de navegador e piloto rotacionam frequentemente

Programação Pareada

• Comportamentos:

• Ao parear, papéis de navegador e piloto rotacionam frequentemente

• Ambos desenvolvedores trabalham na mesma máquina: 2 monitores, 2 mouses, 2 teclados

Programação Pareada

• Comportamentos:

• Ao parear, papéis de navegador e piloto rotacionam frequentemente

• Ambos desenvolvedores trabalham na mesma máquina: 2 monitores, 2 mouses, 2 teclados

• Pareamento entre papéis também acontece

Programação Pareada

• Comportamentos:

• Ao parear, papéis de navegador e piloto rotacionam frequentemente

• Ambos desenvolvedores trabalham na mesma máquina: 2 monitores, 2 mouses, 2 teclados

• Pareamento entre papéis também acontece

• Pareamento oportunista: quando não faz sentido parear, não pareia

Standards de Código

Standards de Código

• Comportamentos:

Standards de Código

• Comportamentos:

• Equipe segue estilo de código comum

Standards de Código

• Comportamentos:

• Equipe segue estilo de código comum

• Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado

Standards de Código

• Comportamentos:

• Equipe segue estilo de código comum

• Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado

• “TODO”s são corrigidos constantemente

Standards de Código

• Comportamentos:

• Equipe segue estilo de código comum

• Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado

• “TODO”s são corrigidos constantemente

• Padrões de estilo da equipe são mais importantes que estilo pessoal

Standards de Código

• Comportamentos:

• Equipe segue estilo de código comum

• Desenvolvedores criam “TODO”s quando encontram algo que precisa ser investigado

• “TODO”s são corrigidos constantemente

• Padrões de estilo da equipe são mais importantes que estilo pessoal

• Código de teste também segue padrões de estilo

Propriedade Coletivade Código

Propriedade Coletivade Código

• Comportamentos:

Propriedade Coletivade Código

• Comportamentos:

• Não existe silos de conhecimento na equipe

Propriedade Coletivade Código

• Comportamentos:

• Não existe silos de conhecimento na equipe

• Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também

Propriedade Coletivade Código

• Comportamentos:

• Não existe silos de conhecimento na equipe

• Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também

• Rotação de pares ajuda a disseminar conhecimento

Propriedade Coletivade Código

• Comportamentos:

• Não existe silos de conhecimento na equipe

• Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também

• Rotação de pares ajuda a disseminar conhecimento

• Desenvolvedores consertam o build independente de quem quebrou

Propriedade Coletivade Código

• Comportamentos:

• Não existe silos de conhecimento na equipe

• Conhecimento do código em modelo “T”: especialização é OK, mas precisa ter conhecimento amplo também

• Rotação de pares ajuda a disseminar conhecimento

• Desenvolvedores consertam o build independente de quem quebrou

• Desenvolvedores procuram trabalhar em áreas diferentes para aprimorar conhecimento

entrega contínua

A “Última Milha”

QA + integração

QA centralizado

release + operação

IT operações

cliente

desenvolvimento

análise + design

teste + showcase

iteração 0 1 2 3 4

Time “Ágil”

AGILE 101

cliente

time deentrega

fluxo constante de entrega em produção

ENTREGA CONTÍNUA

Servidor Central

DesenvolveMáquina Local

Servidor Central

Desenvolve

Build

Máquina Local

Servidor Central

Desenvolve

Build

Máquina Local

Servidor Central

Desenvolve

Build

pull

Máquina Local

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

push

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

Buildpush

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

Buildpush

✔Pronto!

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

Buildpush

✔Pronto!

Servidor Central

Desenvolve

Build

Build

pull

Máquina Local

Buildpush

✔Pronto!

Todo mundo faz

commit no trunk

todos os dias

Integração Contínua

Integração Contínua

• Comportamentos:

Integração Contínua

• Comportamentos:

• Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia

Integração Contínua

• Comportamentos:

• Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia

• Build roda testes automatizados de diversos níveis

Integração Contínua

• Comportamentos:

• Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia

• Build roda testes automatizados de diversos níveis

• Os builds estão geralmente verdes

Integração Contínua

• Comportamentos:

• Desenvolvedores fazem commit frequentemente, idealmente várias vezes por dia

• Build roda testes automatizados de diversos níveis

• Os builds estão geralmente verdes

• Desenvolvedores reagem quando o build quebra

Integração Contínua

Integração Contínua

• Comportamentos:

Integração Contínua

• Comportamentos:

• Desenvolvedores trabalham para reduzir o tempo do build

Integração Contínua

• Comportamentos:

• Desenvolvedores trabalham para reduzir o tempo do build

• Desenvolvedores sempre rodam testes antes de fazer commit para minimizar a chance de builds quebrados

Integração Contínua

• Comportamentos:

• Desenvolvedores trabalham para reduzir o tempo do build

• Desenvolvedores sempre rodam testes antes de fazer commit para minimizar a chance de builds quebrados

• Desenvolvedores não fazem commit quando o build está quebrado

Branch por Funcionalidade

Desenvolvimento no Trunk

Desenvolvimento no Trunk

Desenvolvimento no Trunk

• Comportamentos:

Desenvolvimento no Trunk

• Comportamentos:

• Commits que quebram o build são rapidamente consertados ou revertidos

Desenvolvimento no Trunk

• Comportamentos:

• Commits que quebram o build são rapidamente consertados ou revertidos

• Uso de branches é limitado: vida curta ou branch para releases

Desenvolvimento no Trunk

• Comportamentos:

• Commits que quebram o build são rapidamente consertados ou revertidos

• Uso de branches é limitado: vida curta ou branch para releases

• Desenvolvedores usam “branch por abstração” quando mudanças maiores são necessárias

Desenvolvimento no Trunk

• Comportamentos:

• Commits que quebram o build são rapidamente consertados ou revertidos

• Uso de branches é limitado: vida curta ou branch para releases

• Desenvolvedores usam “branch por abstração” quando mudanças maiores são necessárias

• Qualquer commit pode ir para produção

http://bit.ly/manage-tech-debt

ESFORÇO

DOR

ESFORÇO

DOR

Gerenciar Dívida Técnica

Gerenciar Dívida Técnica

• Comportamentos:

Gerenciar Dívida Técnica

• Comportamentos:

• Equipe cataloga e estima items relacionados à dívida técnica

Gerenciar Dívida Técnica

• Comportamentos:

• Equipe cataloga e estima items relacionados à dívida técnica

• Equipe dedica uma porcentagem de tempo em cada iteração para atacar items de dívida técnica

Gerenciar Dívida Técnica

• Comportamentos:

• Equipe cataloga e estima items relacionados à dívida técnica

• Equipe dedica uma porcentagem de tempo em cada iteração para atacar items de dívida técnica

• Dívida relacionada à arquitetura é capturada e priorizada para permitir evolução a longo prazo

Gerenciar Dívida Técnica

• Comportamentos:

• Equipe cataloga e estima items relacionados à dívida técnica

• Equipe dedica uma porcentagem de tempo em cada iteração para atacar items de dívida técnica

• Dívida relacionada à arquitetura é capturada e priorizada para permitir evolução a longo prazo

• Decisões sobre escopo levam dívida técnica em consideração

Implantação Automatizada

Implantação Automatizada

• Comportamentos:

Implantação Automatizada

• Comportamentos:

• Equipe procura automatizar passos para deploy

Implantação Automatizada

• Comportamentos:

• Equipe procura automatizar passos para deploy

• Script inclui não apenas deploy de código, mas também recursos dependentes: banco de dados, infraestrutura, filas, etc.

Implantação Automatizada

• Comportamentos:

• Equipe procura automatizar passos para deploy

• Script inclui não apenas deploy de código, mas também recursos dependentes: banco de dados, infraestrutura, filas, etc.

• É fácil subir ambientes parecidos com produção

Infraestrutura como Código

Infraestrutura como Código

• Comportamentos:

Infraestrutura como Código

• Comportamentos:

• É fácil subir ambientes parecidos com produção

Infraestrutura como Código

• Comportamentos:

• É fácil subir ambientes parecidos com produção

• Alterações de infraestrutura não precisam de tickets para equipes externas

Infraestrutura como Código

• Comportamentos:

• É fácil subir ambientes parecidos com produção

• Alterações de infraestrutura não precisam de tickets para equipes externas

• Código de infraestrutura é testado e parte da pipeline de entrega

Infraestrutura como Código

• Comportamentos:

• É fácil subir ambientes parecidos com produção

• Alterações de infraestrutura não precisam de tickets para equipes externas

• Código de infraestrutura é testado e parte da pipeline de entrega

• Pouco uso de ambientes compartilhados

Pipeline de Implantação

Pipeline de Implantação

“...(a pipeline de implantação) é a manifestação automatizada

do processo de levar o software do controle de versão para as

mãos dos usuários"

-- Jez Humble

Em Português!

http://www.grupoa.com.br/livros/engenharia-de-software-e-metodos-ageis/entrega-continua/9788582601037

Pipeline de Implantação

Serviço B

Serviço C

App A

Testes Unitário

Controle de Versão

Repositório de Artefatos

Testes de Componente

Testes Unitário

Testes de Componente

Testes Unitário

Testes de Componente

Testes de Contrato

Testes de Contrato

Deploy em Dev Smoke

Deploy emIntTeste de

Aplicação Smoke

App E

App F

Serviço D

Testes Unitário

Testes de Componente

Testes Unitário

Testes de Componente

Testes Unitário

Testes de Componente

Testes de Contrato

Deploy em Dev Smoke

Teste de Aplicação

Testes de Contrato

Deploy em Dev Smoke

Deploy emInt Smoke

Deploy emInt

Teste Ponta-a-Ponta

Ambiente de Dev

Deploy emQA Smoke

Testes de Performance UAT

Ambiente de Integração

Ambiente de QA

Deploy emProduction Smoke

COTS

Ambiente de Produção

Deploy emInt

(...)

(…)

Pipeline de Implantação

Pipeline de Implantação

• Comportamentos:

Pipeline de Implantação

• Comportamentos:

• Mudanças em produção podem ser traçadas desde o commit original

Pipeline de Implantação

• Comportamentos:

• Mudanças em produção podem ser traçadas desde o commit original

• Pipeline possui diversos estágios para diferentes níveis de teste

Pipeline de Implantação

• Comportamentos:

• Mudanças em produção podem ser traçadas desde o commit original

• Pipeline possui diversos estágios para diferentes níveis de teste

• Estágios são otimizados para maximizar feedback rápido

Pipeline de Implantação

• Comportamentos:

• Mudanças em produção podem ser traçadas desde o commit original

• Pipeline possui diversos estágios para diferentes níveis de teste

• Estágios são otimizados para maximizar feedback rápido

• Código de infraestrutura integrado com código de produção na pipeline

Pipeline de Implantação

• Comportamentos:

• Mudanças em produção podem ser traçadas desde o commit original

• Pipeline possui diversos estágios para diferentes níveis de teste

• Estágios são otimizados para maximizar feedback rápido

• Código de infraestrutura integrado com código de produção na pipeline

• Inclusão de testes pré-release (desempenho, carga, stress, …)

Resumindo...

práticas de engenharia são essenciais para

ser ágil

princípios

vs.

práticas

minhas práticas de engenharia

Entrega contínuacolaboração

testes automatizados design

TDD

testes automatizados

design incremental

refatoraçãometáfora

linguagem ubíquaTDD

desenvolvimento no trunk

integração contínua

pipeline de implantação

implantação automatizada

infraestrutura como código

propriedade coletiva de código

standards de código

programação pareada

gerenciar dívida técnica

desenvolvimento no trunk

quais são as suas práticas?

Danilo Sato@dtsato - www.dtsato.com

Desenvolvedor, Arquiteto, Coach, DevOps, Treinador

Obrigado!