Entrei em contato com algum material do Patrick Hynds, MVP de segurança. Eu não o conhecia, mas o pouco que vi me deixou muito claro que ele é uma pessoa muito experiente. Gostei especificamente de 4 regras que ele coloca como as que devem guiar o processo de desenvolvimento de software. Ele as chama de “regra de uma palavra”, “regra de duas palavras”, “regra de três palavras” e “regra de quatro palavras”, e tem esses nomes porque são definidas com estas quantidades de palavras.

Elas são exatamente novidades, mas como são muito curtas e simples acabam tendo um peso juntas. Ao mesmo tempo que parecem óbvias, entendo que também podem ser um pouco polêmicas.

Bom, vamos à elas. Abaixo de cada uma coloquei a minha percepção sobre a idéia.

  1. Status
    Verifique o status com frequência. E verifique ele cedo no projeto, porque quanto mais tarde mais caro vai custar corrigir o que não foi medido antes.
    Desenvolvedores novos devem passar status no mínimo uma vez por dia. Reuniões diárias, ao estilo daily meeting do Scrum são recomendadas. Profissionais mais seniors podem passar status com uma frequência um pouco menor, mas todos, sem exceção, devem passar status obrigatoriamente, sob pena de perda de emprego. Somente depois do status obtido e conferido é que algo pode ter o status de “pronto”.
  2. Nunca adivinhe
    Nunca assuma nada. Status não serve para nada se você só anotou o que outra pessoa te disse. Você tem que conferir que o status é o que é. Se você está colhendo o status e a pessoa que deve lhe passar este status não te comprova o status, você tem o direito de assumir o status que quiser, já que a discussão está no nível do achismo.
  3. Não seja ansioso
    Desenvolva um conceito de “pronto” e se atenha a ele. Entenda que, em nenhuma situação, código concluído significa projeto terminado, por mais que você queira que signifique. Entenda também que “pronto” é um conceito binário: ou está pronto, ou não está. Não existe “pronto mas falta <coloque algo aqui – testes, documentação, etc>”.
  4. Sem especificação, sem estimativa
    Esse é muito legal, e vou tratar dele melhor em outro post. Em poucas palavras: qualquer estimativa deve ser baseada (e solicitada) com base em uma especificação que não deixe margem à dúvidas. Mas é mais que isso. Bem mais.

O primeiro e o segundo fogem bastante do conceito de times autogerenciáveis, já que claramente há alguém gerenciando o time, ou, no mínimo, colhendo status. Meu medo é só com o regime comando-controle, que é muito improdutivo, mas de resto tudo me parece justo, principalmente com times menos seniors, e com acompanhamento à distância, como no caso de terceirização ou times distribuídos.

Aqui você tem um PPT dele explicando como prevenir a falha em projetos. Bem legal, recomendo.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.