Desenvolvedores, por favor, parem de dizer “Tudo o que precisamos fazer é …” e “Oh, isso é apenas …” e “Isso deve ser muito simples, só deveríamos ter que …” Não diga em voz alta; não diga isso em sua cabeça. Você está se enganando. Mesmo com a chance de que o que você disse seja correto em um nível técnico – mesmo que tenha sido apenas uma alteração de duas linhas – você está acreditando em uma visão errada do software.
Não sou a primeira pessoa a dizer algo assim. Na verdade, não tenho certeza se muito se alguma coisa que estou prestes a dizer é verdadeiramente original. Fred Brooks notoriamente afirma em The Mythical Man-Month que todos os desenvolvedores são otimistas. Quando li essa declaração pela primeira vez, pensei que o cara era louco. Conheci dois desenvolvedores que reclamavam que o tempo estava muito frio. Quando o tempo esquentou, o primeiro desenvolvedor reclamou do clima quente porque ele não podia estar fora para apreciá-lo. O segundo reclamou que tínhamos pulado a primavera e pousado diretamente no calor do verão. Quando, agindo como a primavera, esfriou novamente, os dois reclamaram que estava frio novamente. Se você me perguntar, os desenvolvedores podem ser muito inconstantes, até mesmo cínicos.
Mas você sabe o quê, Brooks está certo. Meus amigos que reclamam do tempo ainda falam assim: “Bem, todos os dados estão aí, certo? Tudo o que temos que fazer é …” “É, não deve ser tão ruim.” Eles ainda fazem estimativas, da minha perspectiva, como se as coisas estivessem bem 80-90% do tempo no software … Caro leitor, com que frequência tudo vai bem para você?
- [Standup segunda-feira] Eu estou trabalhando em X . Não é tão ruim; Devo fazer isso hoje ou, o mais tardar, amanhã.
- [Terça-feira standup] Yeah, então eu ainda estou trabalhando em X . Devo chegar mais tarde esta manhã.
- [Quarta-feira standup] Então eu tive todos os tipos de problemas de merda com essa merda. Eu não sei por que isso não funciona e temos coisas todas merdas e não sei por quê. De qualquer forma, estou trabalhando muito para fazer isso e espero conseguir terminar o X até o final do dia ou, o mais tardar, amanhã.
- [Quarta-feira standup] Então, isso está me matando. Eu só quero tirar um dia de folga.
- [Levantamento na sexta-feira] Ok, acho que resolvi isso. Vou tentar fazer o check-in logo depois disso.
- [Trocação na segunda-feira] Acabei de verificar depois da trocação na sexta-feira, mas quebrou a compilação e tive que revertê-lo. Acabei de fazer check-in novamente e a construção está verde. Finalmente! Tão cansado de trabalhar em X .
Eu não posso te dizer quantas vezes isso acontece.
Parece haver algo sobre os humanos que, quando pensamos em uma tarefa, só pensamos na quantidade de tempo que leva a essência da tarefa. Mesmo quando criança, eu via meu pai repetidas vezes realizando menos do que esperava em um dia, apesar de ser muito trabalhador. Para ilustrar isso, vamos supor que você tenha declarado que algo “Não deve demorar muito; é apenas uma mudança de duas linhas”. E vamos supor que você esteja correto sobre o número de linhas de código de produção que precisam ser alteradas (embora você provavelmente esteja sendo muito otimista quanto a isso). Nesse caso,
- E os testes automatizados? Você não vai precisar fazer um test-drive?
- E quanto a qualquer refatoração potencial? Será que sua alteração de duas linhas muda a intenção do código de forma que, se você estiver sendo meticuloso, realmente precise renomear algumas coisas?
- Que tal atualizar a documentação ou notas de lançamento?
- E quanto ao teste e verificação manuais?
- E se você não for a pessoa que faz isso, e alguém que menos conhece a área acabar trabalhando nisso?
- Você já tem o código-fonte atualizado em sua máquina?
- Que tal digitar uma boa mensagem de commit? Isso requer um pouco de reflexão.
- Que tal atualizar a história ou bug em seu software de rastreamento de problemas?
- E se descobrir que há uma dívida técnica que precisa ser paga na área em que você está trabalhando e sua organização tem uma política de pagamento no momento?
- Você pode configurar seu ambiente para desenvolvimento facilmente?
- O projeto tem bons testes automatizados para lhe dar confiança?
- E se você tiver que fazer alguma depuração?
- E quanto ao custo de integrar suas mudanças com qualquer outra pessoa que possa estar trabalhando na área?
- Você precisa acumular essas “duas linhas” em uma versão diferente do software?
- Você tem certeza de que pode fazer isso sem quebrar outra coisa?
- Quão rápidas são suas máquinas de construção? Você terá que vigiá-los para ter certeza de que passaram? Ou, se você não fizer integração contínua, quem vai construir com suas mudanças de forma independente para verificar e quanto tempo isso levará?
- Você iria receber uma revisão por pares, certo?
Quando você está imaginando essas duas linhas mutantes em sua mente, você está não dar uma representação precisa do custo da mudança. Algumas das perguntas acima podem não ser um problema para você ou podem custar apenas cinco minutos. Mas alguns deles podem morder você por dias. E mesmo aqueles que levam apenas cinco minutos irão somar. Todos nós precisamos lidar com isso: a quantidade de tempo que você gasta digitando o código de produção é, de longe, uma minoria do seu tempo , mesmo se você for alguém que não tenha outras responsabilidades na sua organização.
E então, você colhe o que planta. Se você afirmou que algo não vai demorar muito e depois começar a demorar, é provável que tenha pressa. E quando você se apressa, não vai escrever esses testes de unidade. E você não vai fazer uma revisão por pares. E você vai se esquecer de adicionar notas de lançamento. Em seguida, você quebrará a compilação e terá que voltar e atualizar os testes de unidade – mas você apenas os corrigirá para que passem, esquecendo-se de renomeá-los para o novo comportamento. Conclusão: quando você ou eu dizemos “não vai demorar tanto”, estamos nos preparando para uma falha de qualidade. Existem muitas, muitas atividades fora da mudança real de linhas de código que são uma parte saudável e até necessária do desenvolvimento de software.
Eu disse que pouco ou nada disso é realmente original, mas espero que você veja que é, infelizmente, muito relevante. Eu escrevi isso porque eu mesmo caí nisso várias vezes e vejo constantemente aqueles ao meu redor caindo. Meu conselho a você é que, se alguém lhe pedir um orçamento, faça o possível para dar uma boa resposta. Mas uma boa resposta, mesmo se a estimativa for pequena, não conterá palavras extras como “apenas” e “apenas” para fazer a estimativa parecer ainda menor ou para exagerar seu nível de confiança em ser pequena. Pode ser uma história de cinco pontos, mas ainda assim aconselho que você não a chame de ” apenas uma história de cinco pontos”. Aprenda a sabedoria da moderação em tais declarações. Por que fazer conjecturas desnecessárias sobre o trabalho de amanhã? Amanhã trará suas próprias preocupações …
E, se ninguém está respirando no seu pescoço por uma estimativa, não faça uma declaração sobre se será difícil ou não, pelo menos para se manter fora dessa visão faminta de desenvolvimento de software que é tão perniciosa . Pare de aplicar tantos diminutivos ao seu trabalho. O software é difícil.