Não há um checklist oficial que deva ser usado por todas as equipes ágeis do mundo, porque, considerando a complexidade do desenvolvimento de software,
cada equipe é única e está resolvendo um problema dentro de um contexto único.
Por isso, cada equipe deverá descobrir o que deve fazer parte de sua definição de
pronto de acordo com seu contexto ou seja, levando em consideração a natureza do
produto, a tecnologia que está sendo utilizada, as necessidades dos usuários etc.
Alguns itens comuns são:
Código refatorado.
Código dentro dos padrões de codificação.
Código revisado ou feito em par.
Código integrado no sistema de controle de versão.
Documentação de arquitetura atualizada.
80
Casa do Código
Capítulo 4. Entregando Valor
Testes de unidade realizados.
Testes de aceitação realizados.
Testes exploratórios realizados.
Nenhum defeito conhecido pendente.
PO aceitou na história.
Manual do Usuário atualizado.
É importante que essa definição seja escrita e que fique disponível e visível para
todos. Isso evita que, por exemplo, uma história de usuário seja dada como pronta,
mas a documentação para o usuário final não tenha sido escrita ainda, e que, então, esse trabalho pendente seja empurrado de uma iteração para a outra, porém não seja
considerado nas estimativas fazendo com que um falso senso de baixa produtividade
permeie o ambiente.
Além disso, a definição também é importante para que haja um mesmo enten-
dimento do significado de pronto para todos os membros do time, e para que nada
de importante seja esquecido ou deixado de lado.
A mesma ideia pode ser aplicada para além das histórias de usuários: também
para iterações e releases. Geralmente, entende-se que uma iteração está pronta ao fim de um intervalo de tempo predefinido, mas pode ser interessante que determinadas
atividades sejam realizadas antes de se dar uma iteração como pronta, como por
exemplo fazer deploy em um servidor de homologação ou algo do tipo.
A participação do PO, na construção dessa definição é muito importante, uma
vez que ele conhece melhor do que ninguém as expectativas do cliente.
A definição de pronto não deve ser estática, ao contrário disso, é natural que, à
medida que o time for evoluindo e amadurecendo,
a definição de pronto seja alterada para atender critérios de mais e mais qualidade [59].
4.8
Integração Contínua
É natural que em um projeto de desenvolvimento de software os desenvolvedores
do time trabalhem em paralelo no desenvolvimento de funcionalidades e correções.
Muitas vezes, podem acabar por alterar os mesmos arquivos gerando conflitos, ou
até mesmo, alterar arquivos diferentes, que depois de combinadas as alterações, o
81
4.8. Integração Contínua
Casa do Código
software apresente um comportamento inadequado. De qualquer forma, de tempos
em tempos, as alterações precisarão ser integradas em uma base comum de código.
O processo de integração, geralmente, é visto por desenvolvedores como algo
custoso e demorado: as peças funcionam bem quando separadas, porém, para tentar
uni-las e fazê-las trabalhar em conjunto o cenário se torna mais complicado.
Manter o código sempre integrado e pronto para ser entregue é um grande de-
safio, e essa é uma das finalidades da integração contínua. A ideia da integração
contínua é que todos os desenvolvedores realizem integração, isso é, sincronizem o
código fonte produzido com o sistema de controle de versão, a maior quantidade de
vezes possível ao longo do dia.
É recomendado que a cada integração todos os testes de unidade sejam execu-
tados para assegurar que o build não seja quebrado e que tudo está funcionando
corretamente.
Chamamos de build (construção) o processo de gerar um pacote executável de
software. Isso inclui a compilação de código fonte e, além disso, pode-se acoplar uma série de outros processos para garantir que o pacote está em boas condições, como
análise estática de código, verificação de padrões de codificação, execução de testes automatizados, etc. Alguns exemplos de ferramentas de build são: make, Gradle,
ant, maven e BuildR.
Se o software possuir um bom nível de cobertura de testes, e os testes forem
bem escritos, essa prática pode reduzir consideravelmente o número de defeitos em
produção e garantir que o código fonte produzido para implementar novas funcio-
nalidades não fez com que algo deixasse de funcionar como deveria.
Existem diversas ferramentas, na verdade servidores de integração contínua
inclusive alguns são de uso livre e open-source que podem ajudar na integração
contínua.
É possível configurar essas ferramentas para que cada vez que algum desenvol-
vedor enviar algum novo código fonte para o sistema de controle de versão, todos
os testes sejam executados e o desenvolvedor receba uma notificação caso o build tenha sido quebrado porque, por exemplo, algum teste tenha falhado.
Muitos servidores de integração contínua também possuem extensões que per-
mitem que sejam gerados relatórios de cobertura de testes, identificação de defeitos óbvios no código (através de ferramentas de análise estática), entre outras coisas interessantes.