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 só 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.