Ao fim do sprint, mais duas reuniões acontecem: a reunião de revisão e a reu-
nião de retrospectiva. Na reunião de revisão a equipe apresenta ao Product Owner o
trabalho que foi desenvolvido durante o sprint, para que ele possa oferecer feedback, e aprovar ou não tudo o que foi produzido. Na reunião de retrospectiva os principais acontecimentos do sprint são apresentados e discute-se sobre as lições aprendidas e melhorias que podem ser aplicadas ao processo.
1.6
Excelência Técnica com XP
O método ágil Extreme Programming (em português Programação Extrema), mais
conhecida simplesmente como XP, foi criado e inicialmente divulgado por Kent Beck
nos anos 90, e é um dos métodos ágeis que melhor cobre aspectos técnicos do de-
senvolvimento de software como codificação, design e testes, veremos mais detalhes
a seguir.
Segundo o XP, durante o processo de desenvolvimento há quatro atividades bá-
sicas a serem executadas: Ouvir, Desenhar, Codificar e Testar.
É preciso ouvir porque desenvolvedores nem sempre possuem o conhecimento
14
Casa do Código
Capítulo 1. Introdução à Métodos Ágeis
de negócio necessário para se construir o software. O Planning Game é uma reu-
nião que acontece uma vez a cada iteração, em que o principal objetivo é decidir
quais funcionalidades serão desenvolvidas na iteração e aprender mais sobre elas. O
cliente escreve histórias de usuário em cartões que representam a necessidade de funcionalidade a ser desenvolvida, e explica para os desenvolvedores tudo o que for preciso para que eles possam implementá-la.
Um bom design é uma excelente ferramenta para que todos possam compreender
melhor os sistemas complexos, suas estruturas, dependências e regras de negócio. O
principal objetivo é manter o design sempre simples, evitando aumentar a comple-
xidade com a criação de funcionalidades que não sejam realmente necessárias.
Essa é a máxima do principio YAGNI (You arent gonna need it Você não vai
precisar disto) que basicamente diz que devemos fazer as coisas somente no mo-
mento em que realmente precisarmos delas: muitas vezes antecipamos o desenvolvi-
mento antes mesmo que surja a necessidade real, assumindo que um dia ela chegará,
porém, essa necessidade pode nunca chegar.
Ao manter o design simples e fazer somente aquilo que for necessário, você pou-
pará tempo, porque deixará de escrever código que não precisa e terá mais tempo
para se concentrar na qualidade do que realmente é necessário e que vai agregar va-
lor para a demanda real e atual do cliente.
Codificar é uma atividade essencial para o desenvolvimento de software, afinal
de contas, sem código não existe software algum. Nessa etapa, é extremante impor-
tante que o cliente continue acessível para que possa oferecer feedback e responder às diversas dúvidas que surgem durante o desenvolvimento.
Com XP, os testes de unidade são escritos antes do código de produção (dis-
cutiremos em detalhes mais à frente); todo o código fonte que será executado em
produção é desenvolvido em pares; a integração do código fonte é realizada frequentemente através da prática de integração contínua; e o código fonte é coletivo, ou seja, pertence a todos os membros da equipe, e deve ser escrito de acordo com os padrões definidos pelo próprio time.
Testar é uma atividade de extrema importância para garantir a qualidade do soft-
ware e não é algo opcional com XP, ao contrário, todo código deve possuir testes de unidade, e todos os testes devem ser executados com sucesso antes que uma entrega
seja feita. Quando um defeito é encontrado, cria-se um teste de unidade para asse-
gurar que esse mesmo defeito jamais volte a acontecer. No XP os testes são escritos antes do código de produção através de TDD (Test Driven Development, ou Desenvolvimento Guiado por Testes).
15
1.7. Fluxo Contínuo com Kanban
Casa do Código
Devido ao foco técnico de XP e ao foco mais gerencial do Scrum, muitas empre-
sas os combinam para obter um processo mais completo, visando um processo mais
eficiente. Estudaremos mais a frente cada uma das práticas citadas.
1.7
Fluxo Contínuo com Kanban
Figura 1.4: Kanban
Kanban é um método ágil que, diferentemente da maioria dos métodos ágeis, não
possui iterações. Ao invés disso, desacopla o planejamento, priorização, desenvol-
vimento e entrega, de forma que cada uma dessas atividades possa ter sua própria
cadência para melhor se ajustar à realidade e necessidade que o processo demanda.
Cadências são repetições que se sucedem em intervalos regulares. Este é um con-
ceito do método Kanban que determina o ritmo de um determinado tipo de evento.
Priorização, entregas, retrospectivas, e qualquer evento recorrente podem ter sua
própria cadência.
Métodos ágeis, no geral, controlam cadências através das iterações que geral-
mente duram de uma a quatro semanas. Dentro de cada iteração, realiza-se planeja-
mento, desenvolvimento, testes, revisões, retrospectivas etc. Tudo isso dentro de um período pré-definido.
Já com Kanban o processo é um fluxo contínuo e não é preciso que todo o tra-