Você sabe qual é a capacidade do seu time de tecnologia? Como você determina as capacidades dele? Em que você presta atenção?

Quando me fizeram essas perguntas recentemente, minha primeira resposta foi “o teste do Joel (The Joel Test), claro!”. Afinal, ele é curto, fácil de entender e vai rapidamente ao X da questão: pode o seu time entregar um produto confiável?

Bem, o teste do Joel já tem 12 anos. Apesar de os princípios por trás das perguntas continuarem relevantes, alguns pontos específicos já evoluíram. O patamar em que um time de tecnologia deve operar subiu, assim como subiu o nível do que seria o patamar ideal.

Então, para responder como determinar a capacidade de um time de tecnologia hoje, eu escrevi alguns pensamentos logo abaixo.

Então você diz que pode entregar?

Um time de tecnologia é tão bom quanto sua capacidade de, progressivamente, entregar um produto. No que isso leva?

Primeiro, vamos falar sobre programação de software. A forma mais rápida de entender as qualidades do seu time é provavelmente olhando para as práticas dele. Há, é claro, o básico:

• Todas as peças do código estão (inclusive a base de dados e o código de infraestrutura) fazendo uso de algum controle de versão?
• Eles escrevem testes de integração/unitários/funcionais para o código?
• Os deploys e builds estão totalmente automatizados?
• Eles praticam integração contínua?
• Todo o código do produto está sendo revisado, tanto via pareamento quanto por uma revisão formal do código?

Uma vez que o básico estiver sendo feito, a próxima coisa a se considerar é o quanto os processos de desenvolvimento podem estar restringindo o trabalho do time. Em outra palavras, há algum passo do processo de build/entrega que auxilia o time a se manter “na linha” e ajuda a manter a base de código limpa? Algumas questões para serem feitas:

• Eles estão medindo a cobertura do código[1]? Ele é medido em todas as camadas, incluindo frontend, middleware e base de dados? Eles estão parando os builds se a medida cair abaixo de um certo percentual?

• Eles estão realizando análise de código em todas as checagens? Quais implicações existem para os builds se surgir alguma questão? (ex.: o build para se surgirem alertas do compilador, se o estilo do código for violado, se a complexidade de uma função exceder certos níveis etc.).

• Eles estão realizando testes de desempenho/carga/estresse como parte do fluxo de desenvolvimento? E quanto a testes de invasão?

Mas, espere, ainda há mais. Note que qualifiquei “habilidade de entregar” com “progressivamente”. Isso foi intencional porque o time deve manter o custo das mudanças baixo e constante. Em outras palavras, desenvolver rapidamente às custas de uma perda do lado técnico, sem se preocupar jamais com ele, não costuma ser uma estratégia muito sustentável.

Para isso, você deve procurar pela cultura de desenvolvimento e por sinais de bom direcionamento da base de código.

• Com qual frequência é feito “refactoring”?
• Há uma comissão de resolução de problemas técnicos prioritários e mais visíveis?
• O processo de desenvolvimento permite explicitamente que haja tempo para lidar com problemas técnicos?

No que diz respeito à cultura desse time, pode haver alguns defeitos:

• Os defeitos estão sendo priorizados apropriadamente (ex.: dando tanta importância para a correção de bugs quanto para os novos recursos)?
• Há uma análise formal das prováveis causas (5 porquês) que é realizada para cada defeito encontrado?
• Há um sistema automatizado de monitoramento de defeitos que alerta o time proativamente?

E, finalmente, precisamos considerar como o software está sendo de fato entregue aos clientes.

• O time está praticando a entrega contínuo? E deployment contínuo?
• Cada feedback negativo ou positivo está sendo registrado?
• Há monitoramento automático? Como é o processo de escalonamento?
• Há um sistema para remediar problemas (tal qual rebalanceamento de servidores, rollbacks automatizados etc.) em uso?

Por favor, perceba que as perguntas acima não são exaustivas. Tenho certeza absoluta de que há outras coisas muito importantes para se prestar atenção. Na verdade, se você tiver outras ideias eu adoraria ouvi-las.

Alta tecnologia

Ser capaz de entregar um grande produto é crucial para qualquer time de tecnologia. De qualquer maneira, para alguns, isso talvez não seja o suficiente. Dependendo da área de negócios em que você estiver, talvez seja necessário um conhecimento mais aprofundado em uma área em particular, o que eu chamaria de “alta tecnologia”.

Com “alta tecnologia” eu quero dizer o tipo de habilidade que não é encontrada normalmente “no jardim” dos desenvolvedores da sua empresa (mesmo entre os grandes). Isso inclui especialistas em semântica, aprendizado de máquina, NLP (programação neuro-linguística, na sigla em inglês), processamento de sinais, e assim por diante. Alguns ainda acrescentariam as habilidades necessárias para otimização de desempenho ou escalonabilidade extrema no mesmo caldeirão.

Novamente, não é qualquer time que precisa de tais especializações, mas alguns necessitam. E, para esses times, essas capacidades adicionais certamente precisam de um destaque.

Referências

http://www.joelonsoftware.com/articles/fog0000000043.

http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html

http://www.slideshare.net/noahsussman/continuous-improvement-16013422