Use o código e tenha 10% de desconto!

eXtreme Programming Práticas para o dia a dia no desenvolvimento ágil de software

Daniel Wildt, Dionatan Moura, Guilherme Lacerda, Rafael Helm
Capa

eXtreme Programming: Práticas para o dia a dia no desenvolvimento ágil de software

Prefácio

 

Prefácio por Klaus Wuestefeld

 

Poucos são os momentos na vida em que ficamos sabendo de uma ideia e dizemos, na hora: "Esta ideia vai revolucionar o mundo."

Aconteceu comigo quando vi pela primeira vez o Orkut (que descanse em paz). Caiu um raio na minha cabeça e eu disse: "Este negócio (rede social) vai revolucionar o mundo."

Antes disso, em 1999, quando eu ainda chafurdava na burocracia do CMM e do Unified Process, um estagiário da minha empresa me mandou os primeiros links sobre eXtreme Programming (XP).

A princípio me pareceu bobagem, como "Go Horse". Logo vi, porém, que Kent Beck, o autor de XP, e as pessoas discutindo a metodologia no primeiro wiki do mundo eram sérias e sabiam do que estavam falando. Eram, na verdade, os estudiosos de software mais sérios, embasados e apaixonados que eu já tinha visto.

Para entender o que foi, para mim, ver as páginas de XP no primeiro wiki do mundo, imagine dois raios simultâneos caindo na sua cabeça: senti que tanto o wiki quanto os métodos ágeis iriam revolucionar o conhecimento e o desenvolvimento de software.

Comecei a evangelizar XP pelo Brasil e palestrei em um evento de Java em Porto Alegre, em 2004. Estavam lá o Daniel e o Guilherme, coautores deste livro. Caiu um raio na cabeça deles e eles criaram o grupo XP-RS, que promoveu muitos encontros de discussão sobre o assunto.

Agora, onze anos depois, escrevem este livro, mais necessário que nunca.

Cansei de ver times tentando fazer Scrum e entregando zero software em produção, durante meses, sprint após sprint. Cansei de ver times com quadros de Kanban lindos na parede mas com tempo de entrega (lead-time) na ordem de meses.

É fácil, hoje, fazer um cursinho de final de semana qualquer, certificar-se em charlatanismo ágil de software e sair ditando regrinhas de cerimônias que a equipe de desenvolvimento deve seguir.

Modelos de gestão como Scrum ou Kanban (prefiro) são úteis para ajudar a escolher as histórias certas a desenvolver mas, no fim das contas, o que faz essas histórias sair do outro lado como software rodando sem bugs em produção é a capacidade e dedicação da equipe, usando boas práticas de artesania de software, como as deste livro.

Sugiro às equipes que ganhem fluência, que dominem XP "by the book", antes de inventar moda. O time mais ágil, que produziu o software de maior valor, no prazo mais apertado, nas condições mais politicamente adversas, do qual já participei, foi um time onde aplicávamos XP à risca. Pense muito bem antes de decidir que não precisa de determinada prática.

Quando testar recursos caros ou complicados, utilize constantes que simulem o comportamento desses recursos (com estratégias de dummy, stub, spy, fake e mock).

Não confunda a brevidade de alguns de seus itens, como essa frase, com falta de importância. Este livro é rico e conciso. Cada parágrafo, se explorado, daria outro livro. Já vi uma equipe de dezenas de programadores atrasar em meses seu projeto, por insistir em depender de ambientes de homologação complexos em vez de seguir a dica acima.

Outro exemplo: já vi uma equipe de uma empresa de software para o mercado financeiro desistir de programação em pares sem saber por que. Está num breve parágrafo deste livro o motivo:

Cuide do espaço físico, a mobília pode dificultar ficar lado a lado programando (por exemplo em mesas de canto ou em formato de ‘L’). Os programadores terão dores no corpo depois de um dia de programação em pares com pouca ergonomia. Uma dica é adaptar o espaço físico...

Por onde começar? É preciso adotar todas as práticas de uma vez?

Se tiver que escolher alguma prática pra começar, escolha o teste automatizado. Testar software manualmente, no século 21, é antiético, como um cirurgião operar sem lavar as mãos. Aprenda os conceitos, a essência da automação de teste. Não perca tempo tentando controlar telas pra fazer testes. Separe da tela todo código de negócios e teste-o diretamente.

Programação em pares junto com revezamento são práticas que encontram resistência tanto dos gestores retranqueiros quanto de alguns membros da equipe mais tímidos (respeitar) ou acomodados (incentivar) mas não dependem de mais nada para ser implementadas. Já vi pareamento e revezamento transformar uma equipe desmotivada, à beira de agressões físicas, em uma equipe de referência dentro de sua organização.

Por fim, é vital que a equipe e seu gestor, se houver, reservem um tempo em torno de um dia (projeto novo) a dois dias (projeto com legado macarrônico) por semana com autonomia para a equipe investir em melhorar continuamente sua própria produtividade, aprendendo técnicas como TDD e refatorando código. Se não houver esse tempo alocado e a equipe ficar só correndo atrás de incêndios de curto prazo, é melhor largar o livro agora porque ele só vai trazer frustração.

Se, por outro lado, houver tempo para melhoria, leve este livro como guia, torça para cair um raio na sua cabeça também e boa sorte no caminho.

Aprenda as práticas de XP, domine-as, entregue software do caralho e, aí sim, adapte-as e transcenda.

— Klaus Wuestefeld, pioneiro em eXtreme Programming no Brasil e Keynote Speaker do Agile Brazil (2010)

 

Prefácio por Alexandre Freire

 

Se eu tivesse este livro que você tem em mãos na virada do milênio, e conhecesse a Programação eXtrema na época, provavelmente hoje seria milionário, porque teria lançado com sucesso a primeira rede social do mundo.

Estava trabalhando em uma software house multinacional, baseada em Treviso, na Itália, construindo uma rede social de times de futebol de várzea para a Diadora. Mas fazíamos isso tudo usando o “melhor”, e mais difundido, processo de desenvolvimento de software, o RUP.

Isso significa que durante os 3 anos em que gastei meu suor e sangue, construindo o incrível software desta rede social, nunca tivemos nenhum usuário, além da sócia que fazia demonstrações trimestrais para os diretores da Diadora. E quando toda a diretoria mudou, e a empresa resolveu cancelar o projeto, foi fácil fazê-lo, pois não tinha sido lançado.

Para mim foi uma experiência muito frustrante, afinal com minha equipe tinha construído um software maravilhoso, uma rede social onde times de futebol de bairro poderiam criar uma página, postar fotos, conseguir “likes” de seus fãs e até organizar campeonatos. E o software funcionava que era uma beleza, ou pelo menos funcionava na minha máquina.

Era o maior projeto da empresa, que acabou indo à falência quando perdeu esse cliente.

Deparei-me com a pergunta: Será que não existe um jeito melhor de fazer software? De entregar mais valor, mais rápido, para os nossos clientes?. Comecei as estudar o que na época eram as metodologias “leves” e resolvi voltar para o Brasil e para a faculdade. No ano seguinte, participei da primeira turma do Laboratório de Programação eXtrema do IME/USP.

E aí que minha vida de desenvolvedor de software mudou. Aprender e praticar Programação eXtrema foi um marco muito importante na minha carreira, e espero que com este livro, seja um marco na sua também.

Durante muitos anos após esse primeiro encontro, pratiquei a Programação eXtrema como definida nos livros do Kent Beck. Com os erros e acertos, comecei a entender como a metodologia era completa, e como cada parte era preciosa. Também aprendi a fazer algumas coisas bem difíceis muito bem, como estimar em pontos, só para descobrir no final que não precisava realmente fazer isso!

Mas na sua jornada, recomendo que não pule essa prática no começo, a sinergia entre as práticas de XP e o fato de que seus valores e princípios suportam todo o conjunto são umas das razões pelas quais me apaixonei por essa metodologia.

Hoje em dia, a comunidade ágil é forte, tem presença marcante no Brasil, e somos ainda mais extremos. Pegamos algumas práticas e nos desafiamos levá-las ainda mais ao limite! Com as histórias de usuário e o jogo do planejamento evoluímos pra criar também o mapa de histórias. Com integração contínua partimos para fazer deploy contínuo. Com programação em par radicalizamos para fazer programação em multirão.

Mas algumas coisas permanecem para sempre valiosas, como as Retrospectivas. A melhor técnica que conheço para uma equipe se aprimorar continuamente. É tão universal que até já usei em outros contextos que não o desenvolvimento de software.

Se você for aprender só uma das metodologias ágeis, recomendo fortemente que seja a Programação eXtrema. Mas experimente-a completa, percebendo como os princípios e valores apoiam as práticas, e que estas muitas vezes só funcionam porque dependem das outras. É uma metodologia holística, onde a sinergia conta muito, e com certeza vai melhorar a maneira como você desenvolve software.

Você tem em mãos um guia definitivo para começar sua jornada, aproveite a leitura.

— Alexandre Freire, Diretor de Produtos da Industrial Logic e Keynote do Agile Brazil 2014.

 

Prefácio por Paulo Caroli

 

Desde 2000, tenho utilizado (e abusado) de metodologias ágeis. A minha primeira sessão em uma conferência internacional foi na OOPSLA 2000, em que apresentei o resultado da minha tese de mestrado, algo sobre Orientação e Objetos e Design Patterns. Após minha apresentação, fui fazer tietagem com Kent Beck por admirá-lo nos assuntos de smalltalk e design patterns, e acabei comprando seu novo livro com o título eXtreme Programming Explained. Deu-se início um caminho sem volta – estava exposto e infectado pela primeira de muitas metodologias ágeis.

Naquela época eu morava no Vale do Silício e estava trabalhando em uma start-up bem legal. Voltei empolgado da conferencia e logo mostrei o livro para o meu gerente da época. Ele riu e disse “Extreme programming... please do not get extreme on our codebase. Be aware of our clients and deadlines”. O livro ficou no meu cubículo (naquela época até start-ups tinham cubículos), e de tempos em tempos eu o mostrava para algum colega de trabalho.

Testes unitários e solitários (somente eu os lia e usava). Integração contínua com meu próprio código (os outros desenvolvedores estavam em suas branches). E assim eram meus dias de trabalho em 2000 e 2001.

Mas eu não estava sozinho. Além de Kent Beck, outros conhecidos estavam falando e escrevendo sobre suas experiências com XP. Ward Cunningham populava a C2wiki (http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap), enquanto Martin Fowler compartilhava no seu site (http://martinfowler.com/articles/xp2000.html). Mais desenvolvedores eram infectados, e compartilhavam suas experiências. E isso se alastrou até os dias de hoje, época em que XP é ensinado em faculdades, e muitas de suas práticas são visíveis em todos departamentos de TI.

Em 2006, entrei na ThoughtWorks e trabalhei com pessoas que participaram do início deste movimento ágil. Por exemplo, ouvi as histórias do Martin sobre o primeiro projeto XP, o C3 (Chrysler Comprehensive Compensation). Vivi e ouvi relatos de experiência sobre a implantações de XP ao redor do mundo. Em 2008 e 2009 constatei que até projetos de outsourcing na Índia estavam usando XP. Bah, mas eu seguia referenciando aquele livro de 2000!

Em 2010, eu ajudei a trazer a ThoughtWorks para o Brasil, abrindo seu primeiro escritório em Porto Alegre. A escolha da cidade não foi somente pelo famoso churrasco, mas sim por admiração ao movimento de XP, e a excelente comunidade já existente. Conheci e aprendi com cada um dos autores deste livro. Daniel, Dionatan, Rafael e Guilherme estão sempre compartilhando conhecimento. Nesta obra, compartilham os valores, práticas e princípios de XP.

Com muito orgulho, informo que este livro é um resumo do que há de melhor no mundo atual de desenvolvimento de software.

Boa leitura,

— Paulo Caroli, cofundador e agile coach da Thoughtworks Brasil.

Sumário

  • 1 - Por que projetos falham?
    • 1.1 - Cliente distante
    • 1.2 - A cereja do bolo
    • 1.3 - Testes no final
    • 1.4 - Trabalho empurrado
    • 1.5 - Dívidas técnicas
    • 1.6 - Conclusão
  • 2 - Introdução a métodos ágeis
    • 2.1 - O Manifesto Ágil
    • 2.2 - Lean Software Development
    • 2.3 - Scrum
    • 2.4 - eXtreme Programming (XP)
  • 3 - Valores do eXtreme Programming
    • 3.1 - Comunicação
    • 3.2 - Feedback
    • 3.3 - Simplicidade
    • 3.4 - Coragem
    • 3.5 - Respeito
  • 4 - Papéis do eXtreme Programming
    • 4.1 - Desenvolvedor
    • 4.2 - Cliente
    • 4.3 - Coach
    • 4.4 - Testador
    • 4.5 - Cleaner
    • 4.6 - Tracker
    • 4.7 - Gerente
    • 4.8 - Outros papéis
  • 5 - Time coeso
    • 5.1 - Time multidisciplinar
    • 5.2 - Time auto-organizável
    • 5.3 - Sentando lado a lado
    • 5.4 - As reuniões de retrospectiva e a melhoria contínua
  • 6 - Cliente presente
    • 6.1 - O que fazer quando o cliente não pode estar presente?
  • 7 - Histórias de usuário
    • 7.1 - Modelo 3C
    • 7.2 - Ciclo de vida
    • 7.3 - Utilizando um modelo de escrita
    • 7.4 - Refinando com INVEST
    • 7.5 - Implementando com tarefas SMART
    • 7.6 - Personas
    • 7.7 - Story points
    • 7.8 - Escrevendo boas histórias
    • 7.9 - Catálogo de story smells
  • 8 - Testes de aceitação
    • 8.1 - Automatização
    • 8.2 - Validando com critérios de aceitação
  • 9 - Liberação frequente de pequenas entregas
    • 9.1 - Foco na qualidade é o ponto-chave
    • 9.2 - Releases tudo ou nada
  • 10 - O jogo do planejamento
    • 10.1 - Definindo o jogo e suas regras
    • 10.2 - Entendendo regras e comprometimentos
    • 10.3 - Mantendo o foco
    • 10.4 - Todo momento é um momento de aprendizado
  • 11 - Spikes de planejamento
    • 11.1 - Jogue fora o código gerado no spike
  • 12 - Projeto simples do início ao fim
    • 12.1 - MVP: produto mínimo viável
  • 13 - Metáfora de sistema
    • 13.1 - Descobrindo uma boa metáfora
  • 14 - Reunião diária em pé
    • 14.1 - Time alinhado
    • 14.2 - Troca de conhecimento
    • 14.3 - Como começar?
    • 14.4 - Erros mais comuns de uma reunião em pé
  • 15 - Posse coletiva
    • 15.1 - My precious!
  • 16 - Padrão de codificação
    • 16.1 - Pequenos projetos também se beneficiam?
    • 16.2 - Como definir?
  • 17 - Programação em par
    • 17.1 - Diversos benefícios
    • 17.2 - Um desenvolvedor pelo preço de dois?
    • 17.3 - A pressão do par
    • 17.4 - Nivelando o conhecimento
    • 17.5 - Como começar?
    • 17.6 - Dicas para aprimorar a programação em par
    • 17.7 - O ambiente de trabalho
    • 17.8 - Especificar, projetar, trabalhar, tudo em par
  • 18 - Refatoração de código para alta qualidade
    • 18.1 - Refatore impiedosamente
    • 18.2 - Bad smells de código
  • 19 - TDD: Desenvolvimento Guiado por Testes
    • 19.1 - Padrões de TDD
    • 19.2 - Show me the code
  • 20 - Integração contínua
    • 20.1 - Como potencializar os benefícios?
    • 20.2 - Ferramentas
  • 21 - Ritmo sustentável
    • 21.1 - Velocidade do time
    • 21.2 - 40 horas semanais
  • 22 - Indo além do eXtreme programming
    • 22.1 - Jogos e dinâmicas
    • 22.2 - Behaviour-Driven Development (BDD)
    • 22.3 - Domain-Driven Design (DDD)
    • 22.4 - Kanban
    • 22.5 - Estimando com planning poker
    • 22.6 - Resolvendo dívidas técnicas
    • 22.7 - Refatorando também o banco de dados
    • 22.8 - Código limpo
    • 22.9 - Entrega contínua e DevOps
    • 22.10 - Leituras sobre desenvolvimento de software
    • 22.11 - Artesanato de Software

 

Capítulo 1

Por que projetos falham?

Culpa do cliente, do gerente de projetos, dos testadores, dos analistas de negócios, do time de desenvolvimento, ou simplesmente falta de sorte? Afinal de contas, por que projetos falham, atrasam e/ou fracassam?

Os desenvolvedores acham que faltou análise; os analistas jogam a culpa no departamento comercial que vendeu o que o software não tem e, ainda por cima, com um prazo impossível de ser cumprido; a equipe de vendas aponta para o cliente dizendo que ele não sabe o que quer; e ele, por sua vez, chama seus advogados para cancelar o contrato.

É bem provável que você já tenha passado por isso, ou, pelo menos, quase passou.

Infelizmente, nós, os autores deste livro, já vimos isso acontecer algumas vezes, e normalmente os motivos são os mesmos: falta de proximidade com o cliente; trabalho empurrado goela abaixo do time; codificação a toque de caixa produzindo código sujo; tempo desperdiçado desenvolvendo o que o cliente não pediu (a famosa cereja do bolo); e o retrógado hábito de testar o software apenas na véspera da sua data de entrega.

Sendo assim, achamos importante começarmos este livro reforçando por que você não deve cometer estes erros clássicos em seus projetos, para, somente depois, entrar no conteúdo do eXtreme Programming propriamente dito. Leia com atenção e lembre-se: antes de prescrever o remédio, é necessário identificar a doença.

1.1 - Cliente distante

Cena corriqueira em times de desenvolvimento de software: o desenvolvedor recebe uma especificação para trabalhar, e, enquanto está codificando, percebe que algum detalhe passou despercebido pelo processo de análise do requisito. Isto gerou uma dúvida que o impede de prosseguir seu trabalho com segurança; ou seja, o desenvolvedor não tem certeza do que exatamente deve ser feito.

Nesses casos de incerteza, normalmente ele procura o analista ou a pessoa responsável por aquela especificação (ou pelo menos deveria fazer isso), e questiona sobre a dúvida que o impede de avançar no código com a certeza de que está fazendo o que foi pedido.

Quando isso ocorre, é esperado que o analista saiba responder os questionamentos do desenvolvedor e o conduza de volta ao caminho correto a ser seguido. O problema é que as pessoas não sabem tudo, incluindo eu, você, e todos os que nós conhecemos. É normal que, em alguns casos, o analista não consiga responder a dúvida do desenvolvedor, pelo menos, não de imediato.

Quando as dúvidas surgem e ninguém do time sabe o que fazer, a melhor decisão é falar com o cliente, seja por meio de uma reunião, telefone, skype, e-mail ou qualquer outra forma de comunicação. O necessário é falar com ele!

Entrar no ciclo tentativa/ erro/ tentativa/ erro/ ... jamais deve ser uma opção. As pessoas até podem acertar de vez em quando, mas, na média, essa atitude vai gerar retrabalho lá na frente, além de frustrar o cliente e, posteriormente, o time.

Sabemos que nem sempre ele estará disponível. Mesmo que esteja fisicamente próximo de você e de seu time, ele pode simplesmente não estar livre ou interessado em ajudar; quer dizer, não quer se envolver. Até porque já pagou uma boa grana para uma empresa fazer seu software e espera que o time de desenvolvimento saiba como fazê-lo.

Pois bem, este cenário é o que chamamos de cliente distante. Acredite, projetos com clientes distantes têm uma grande tendência a serem entregues com atraso, estourarem o orçamento, os frustrarem ao entregar funcionalidades que não atendam suas expectativas, ou todas as alternativas anteriores juntas (fracasso tremendo).

 

E qual é a solução?

 

Precisamos aproximar o cliente desde o início do projeto, deixando bem claro que, a qualquer momento, ele poderá ser acionado para tirar dúvidas, e que a cada funcionalidade, ele poderá ser chamado para realizar uma validação. Ou seja, dar seu consentimento sobre se aquele recurso ficou de acordo com o que esperava, ou indicar o que precisa ser ajustado para atendê-lo, caso o resultado não satisfaça suas expectativas.

Porém, é necessário tomar cuidado. Pedir o aceite do cliente não significa pedir para ele testar. O teste do software é responsabilidade do time de desenvolvimento e, acredite em nós, eles não gostam de testar software. E, principalmente, não ficam nada felizes quando encontram bugs nele.

Quando pedimos para ele validar ou aceitar uma funcionalidade, na verdade estamos buscando um feedback. Queremos confirmar se aquela função que acabou de sair do forno está de acordo com a sua expectativa. Estamos buscando segurança para continuar o desenvolvimento do projeto, tendo certeza de que os passos dados até agora foram realizados na direção correta.

E se o cliente odiar a funcionalidade desenvolvida, dizendo que está totalmente fora do que ele esperava? Ótimo! Nós conseguimos falhar rápido e teremos tempo para corrigir, adaptar ou até mesmo refazer o recurso, conseguindo finalmente entregar algo de valor a ele. Imagine como seria desagradável se, somente no final do projeto, nós descobríssemos que algumas (ou várias) funcionalidades não ficaram de acordo com sua expectativa? Seria terrível! E provavelmente nosso tempo já estaria esgotado.

Então, aproxime-se de seu cliente e mantenham-se próximos!

1.2 - A cereja do bolo

Você tem seus clientes e eles têm expectativas. Se algumas empresas que produzem software criassem uma confeitaria especializada em bolos, muitos clientes receberiam apenas uma receita, ensinando como fazer o maldito bolo. Digamos que isso não gera nem tanto valor, nem satisfação. Ele estava com fome, queria comer um bolo.

Outros clientes com um pouco mais de sorte receberiam uma massa, nem tão bem batida, mas que faria um belo bolo "abatumado". Depois de perder vários prazos com o mesmo cliente (o qual, por alguma magia, ainda segue comprando bolo daquele local), acontece que, eventualmente, a empresa consegue terminar o bolo, exatamente como ele pediu. Só que, lembra das suas experiências anteriores, nas quais ele não o recebeu? Então, a empresa não pode entregar só um simples bolo. É preciso entregar algo maior, algo a mais. Surpreender!

Não precisamos da cereja do bolo! Ou se você gosta de usar o PMBOK® (Project Management Body of Knowledge ─ Corpo de Conhecimento em Gerência de Projetos) como exemplo; estamos falando do Gold Plating.

Se o seu cliente solicita um relatório com as colunas A, B e C; o time deve desenvolver, com qualidade e dentro do prazo, o relatório com as colunas A, B e C. Simples assim!

Entregar um relatório com as colunas A, B, C, X e Y não faz sentido nenhum! Se ele quisesse que as colunas X e Y aparecessem no relatório, teria solicitado. Neste caso, X e Y são a tal cereja do bolo da qual estamos falando.

Vamos lembrar de algo bem importante. Nosso cliente tem uma grande expectativa: receber aquilo que ele pediu! E ele possui outras também! Quer receber o mais rápido possível, com a mais alta qualidade e o menor custo. E com o menor desperdício possível, é claro. Colocar uma cereja no bolo não vai ajudá-lo a esquecer as falhas anteriores. Nem nas próximas entregas.

 

E qual é a solução?

 

Simplicidade: maximizar o trabalho que não deve ser feito. A meta do time deve ser trabalhar com o cliente para enxugar as funcionalidades necessárias. Deve-se questionar muito sua visão de valor.

Muitos recursos sugeridos por ele não possuem um método fácil de medir o valor ou, até mesmo, o Retorno Sobre Investimento (ROI ─ Return On Investment). Uma simples classificação para entender o valor e o risco de fazermos uma determinada funcionalidade pode ser uma boa racionalização para ajudar na seleção do que precisa ser feito.

Indo nessa linha, vamos começar trabalhando naquilo que possui alto risco e valor, e descobrir rapidamente se temos algum problema. Lembra da estratégia de falhar rápido? Esse é o jogo. O mundo perfeito é trabalhar naquilo que possui alto valor e um baixo risco!

Não queremos trabalhar naquilo que possui baixo valor. O único motivo para isso está relacionado às leis, nas quais temos que seguir para a conformidade e evitar alguma multa. De resto, fuja daquilo que não tem valor claro. Foque na entrega de valor para seu cliente.

1.3 - Testes no final

Afinal, por que testamos? Aliás, é necessário realmente testar?. Ou pior: se sobrar tempo, testamos!

Essas expressões são comumente ditas por profissionais de software. Infelizmente.

Deixe-nos explicar melhor: desenvolver software é um processo produtivo, no qual executamos tarefas de investigação, design, programação, testes, entre outros. A forma como a indústria começou a desenvolver seus modelos (e independente do modelo a ser adotado) engloba essas etapas.

A questão a ser observada no processo é que a preocupação com os testes só existe no final. Além de acontecer isoladamente, não se enxerga seu verdadeiro valor, nem sua relação com a qualidade do produto.

Por esses motivos, os testes não são levados a sério. Por isso, pagamos o preço do retrabalho ao entregar funcionalidades erradas e com falhas. Isso gera desconfiança e estressa uma relação que precisa ser totalmente diferente para atingirmos o objetivo.

 

E qual é a solução?

 

Precisamos trabalhar nos recursos até eles estarem prontos de verdade; ou seja, não podemos permitir que exista dentro do time de desenvolvimento o conceito de que está pronto, só falta testar.

O teste não deve ser encarado como uma etapa à parte, como algo extra. Os processos de desenvolvimento e testes devem ser vistos como uma única etapa. Esqueça o desenvolver primeiro, testar mais tarde, e busque o desenvolver + testar. Entende a diferença? As funcionalidades não são testadas mais tarde; elas são testadas agora.

1.4 - Trabalho empurrado

Imagine a cena: o gerente de projetos avisa o time de desenvolvimento de que a empresa fechou um novo contrato e que o software deve ser entregue em uma determinada data, deixando já bem claro a todos que não existe possibilidade de não a cumprir.

O time de desenvolvimento começa a analisar os requisitos e gerar as tarefas, e logo percebe que, para cumprir a data já firmada com o cliente, que inclusive consta no contrato, será necessário produzir em uma velocidade muito acima do habitual. Ao notar isso, o nível de estresse do time é elevado, o ambiente fica tenso e os desenvolvedores programam a toque de caixa, começando a gerar um código sujo, mal estruturado e em cima de requisitos especificados de forma superficial. Como o tempo era curto, ninguém quis perder muito tempo com especificação, assim todos já foram logo metendo a mão na massa.

Esse é um claro cenário de trabalho empurrado, que gera muito caos e pouco resultado!

 

E qual é a solução?

 

Se trabalho empurrado é um problema, trabalho puxado é a solução. O ideal é que esteja à disposição do time o que for necessário para o desenvolvimento de software e que as tarefas estejam corretamente priorizadas e, se possível, dispostas em um mural contendo todas as que serão trabalhadas nos próximos dias. Desse modo, uma ou mais pessoas puxam as tarefas e trabalham nelas até o fim, nunca esquecendo de desenvolver + testar, em vez de desenvolver primeiro, testar mais tarde.

Após terminar a tarefa, o desenvolvedor vai até o mural, dá uma olhada nas próximas da fila e puxa aquela em que ele sente que consegue trabalhar. Claro que é necessário que ele faça isso com responsabilidade; ou seja, é importante que, dentro do possível, ele siga a priorização. A exceção a essa regra pode ocorrer quando a próxima tarefa da fila refere-se, por exemplo, a um módulo que ele não conhece ou a uma tecnologia com qual ele não se sente seguro. Porém, esses casos são ótimas oportunidades para trabalhar em par com outra pessoa do time e aprender algo novo, tanto em termos de negócio, quanto de tecnologia.

Nós acreditamos fortemente no trabalho puxado e sempre orientamos nossos times a trabalharem desta forma, de preferência baseados em um mural que permita gestão visual das tarefas e do progresso de trabalho, seja no meio físico ou virtual (no caso de equipes distribuídas).

Sabemos que quebrar a cultura do trabalho empurrado não é fácil, pois existe (principalmente na cabeça da maioria dos gestores) uma barreira muito forte em relação a isso. Entretanto, garantimos que vale a pena tentar. Durante o livro, vamos mostrar ferramentas e táticas que nos ajudarão nessa missão, como: time coeso, posse coletiva, liberação frequente de pequenas entregas, trabalho em pares, jogo do planejamento, e outros tópicos que ajudam a implantar a cultura de trabalho puxado.

1.5 - Dívidas técnicas

O projeto começa e o time de desenvolvimento está trabalhando com alta produtividade. Várias partes do software vão sendo construídas e todos estão felizes.

Passadas algumas semanas, a produtividade caiu um pouco e a euforia do time passou; mas o projeto ainda transcorre dentro da normalidade e eles ainda estão relativamente contentes.

Passadas mais algumas semanas, a produtividade cai drasticamente e muitos bugs começam a ser encontrados. Nesse momento, o time já está com a moral baixa, o cliente notou que o projeto não anda bem, o custo de mudança de qualquer funcionalidade é muito alto, e você não entende o motivo dessa queda; afinal de contas, o time é bom, a especificação foi bem feita, o cliente está próximo, a comunicação flui e as pessoas são comprometidas. O que está acontecendo?

É bem provável que o projeto possua uma dívida técnica grande.

O termo dívida técnica é utilizado para indicar trechos de código que foram mal escritos, ou escritos de qualquer forma, sem refatorar, sem testes automatizados e sem respeitar padrões. São as chamadas gambiarras ou bacas. Com o passar do tempo, esses trechos atrapalharão os desenvolvedores e mudanças que, teoricamente, seriam simples, passam a levar muito tempo para serem realizadas.

É provável que você já tenha deparado-se com uma funcionalidade praticamente impossível de ser evoluída, tamanha era a falta de qualidade do código. Em alguns casos, quando isso ocorre, somos obrigados a refazê-la toda, pois o código tornou-se ilegível e isso gera um grande desperdício de tempo e dinheiro.

Muitos desenvolvedores ainda consideram que qualidade do código é algo extra e que o foco é entregar software com qualidade, não necessariamente produzindo código de qualidade. Essa é uma escolha perigosa, porque, a menos que o projeto seja bem pequeno, o desenvolvedor precisará pagar a conta da dívida técnica produzida, ou simplesmente o projeto vai parar.

 

E qual é a solução?

 

São excelentes formas de evitar a dívida técnica: especificar requisitos com o formato de histórias de usuários, projeto simples, padrão de codificação, desenvolvimento guiado por testes (TDD), programação em pares, refatoração, integração contínua, boas práticas de programação e ritmo sustentável.

Mas, se você não sabe como implantar essas práticas no seu time de desenvolvimento, fique tranquilo! Estamos apenas no começo do livro e abordaremos esses assuntos mais à frente.

1.6 - Conclusão

Quando um projeto falhar, não tente encontrar um culpado, olhe para o passado e procure identificar se algum dos problemas ocorreu em seu projeto. Precisamos sempre buscar sua causa raiz. Não busque culpados, busque entender o que ocorreu e converse com seu time para tentar encontrar uma solução, um melhor caminho a ser seguido.

Reuniões de retrospectiva de projeto são ótimas oportunidades de levantar problemas e discutir soluções com seu time. Mais à frente, falaremos sobre elas.

Lembre-se: em métodos ágeis, incluindo o eXtreme Programming, devemos sempre trabalhar com a mente aberta para realizar adaptações em nosso processo de trabalho, a fim de buscar melhoria contínua. É uma busca infinita pelo fazer melhor.

Dados do produto

Número de páginas:
158
ISBN:
978-85-5519-106-0
Data publicação:
08/2015

Compartilhe!

Compartilhe no Facebook Compartilhe no Twitter