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

http://www.dtsato.com


Agile virou mainstream

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

http://www.versionone.com/state-of-agile-survey-results/



Scrum + Kanban = 72% ~ 75%





4% “Não Sei” ?!





XP = 2% ~ 7%



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


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


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

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



TDD

testes automatizados

originadas em XP



TDD


design incremental

refatoraçãometáfora

linguagem ubíquaTDD

originadas em XP



TDD


design incremental



propriedade coletiva de código

standards de código

programação pareada

gerenciar dívida técnica

desenvolvimento no trunkoriginadas em XP



TDD


design incremental



desenvolvimento no trunk

integração contínua

pipeline de implantação

implantação automatizada

infraestrutura como código





desenvolvimento no trunkoriginadas em XP

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


• Comportamentos:


• Comportamentos:

• O time possui uma clara estratégia de testes


• Comportamentos:


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


• Comportamentos:



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


• Comportamentos:




• Tempo necessário para realizar testes manuais reduzido


• Comportamentos:




• Tempo necessário para realizar testes manuais reduzido

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

TDD

• Comportamentos:

TDD

• Comportamentos:

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

TDD

• Comportamentos:


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

TDD

• Comportamentos:



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

TDD

• Comportamentos:



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

• Comportamentos:

Design Ágil

• Comportamentos:

• Código é fácil de ser testado

Design Ágil

• Comportamentos:


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

Design Ágil

• Comportamentos:



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

Design Ágil

• Comportamentos:



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


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

Refatoração

• Comportamentos:



• Refatorações são pequenas e incrementais

Refatoração

• Comportamentos:




• Código de teste também é refatorado

Refatoração

• Comportamentos:




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


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

Linguagem Ubíqua

• Comportamentos:


• 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



Programação Pareada

• Benefícios:

• Foco

• Revisão de código constante

• Resultado é maior que a soma das partes


• Comportamentos:


• Comportamentos:

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


• Comportamentos:


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


• Comportamentos:



• Pareamento entre papéis também acontece


• Comportamentos:



• Pareamento entre papéis também acontece

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

Standards de Código


• Comportamentos:


• Comportamentos:

• Equipe segue estilo de código comum


• Comportamentos:


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


• Comportamentos:



• “TODO”s são corrigidos constantemente


• Comportamentos:




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


• Comportamentos:




• 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


• Comportamentos:


• Comportamentos:

• Não existe silos de conhecimento na equipe


• Comportamentos:


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


• Comportamentos:



• Rotação de pares ajuda a disseminar conhecimento


• Comportamentos:




• Desenvolvedores consertam o build independente de quem quebrou


• Comportamentos:




• 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

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!

Todo mundo faz

commit no trunk

todos os dias

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay






Integração Contínua


• Comportamentos:


• Comportamentos:

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


• Comportamentos:


• Build roda testes automatizados de diversos níveis


• Comportamentos:



• Os builds estão geralmente verdes


• Comportamentos:



• Os builds estão geralmente verdes

• Desenvolvedores reagem quando o build quebra


• Comportamentos:


• Comportamentos:

• Desenvolvedores trabalham para reduzir o tempo do build


• Comportamentos:


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


• Comportamentos:


• 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


• Comportamentos:


• Comportamentos:

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


• Comportamentos:


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


• Comportamentos:



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


• Comportamentos:



• 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

Gerenciar Dívida Técnica


• Comportamentos:


• Comportamentos:

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


• Comportamentos:


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


• Comportamentos:



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


• Comportamentos:



• 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


• Comportamentos:


• Comportamentos:

• Equipe procura automatizar passos para deploy


• Comportamentos:


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


• Comportamentos:


• 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


• Comportamentos:


• Comportamentos:


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


• Comportamentos:



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


• Comportamentos:



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

• Pouco uso de ambientes compartilhados

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






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 Unitário


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 Unitário


Testes Unitário


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

(...)

(…)


• Comportamentos:


• Comportamentos:

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


• Comportamentos:


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


• Comportamentos:



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


• Comportamentos:




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


• Comportamentos:




• 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



TDD


design incremental




integração contínua

pipeline de implantação

implantação automatizada

infraestrutura como código






quais são as suas práticas?

Danilo Sato@dtsato - www.dtsato.com

Desenvolvedor, Arquiteto, Coach, DevOps, Treinador

Obrigado!



revisitando as práticas de engenharia Ágil

Technology