De Olho no Objetivo
Alguns princípios e táticas sobre gestão de engenharia de software
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
De Olho no Objetivo
Alguns engenheiros que gerenciei anteriormente me pediram algum material sobre as mudanças que costumo fazer nos times. É difícil organizar o que acaba sendo meus desabafos frequentes sobre alguns princípios, mas vou tentar.
Esses conceitos não são novos. Eu os aprendi há mais de 10 anos durante meu tempo na ThoughtWorks. Para uma perspectiva mais ampla sobre princípios de desenvolvimento de software, recomendo o post da ThoughtWorks do Evan.
Gerenciar times de software é sobre produtividade e confiabilidade. O Agile simplificou o desenvolvimento, mas três componentes frequentemente esquecidos importam: priorização, iteração e conclusão do trabalho.
A história de outro time
Times frequentemente operam da seguinte forma:
Produto define o trabalho em cards da perspectiva de negócio/usuário, especificando o que precisa ser concluído.
Líderes de engenharia dividem cards em tarefas técnicas, analisando cards e decidindo abordagens técnicas, explicando-as em múltiplas subtarefas técnicas.
Tarefas técnicas são distribuídas entre engenheiros por responsabilidade, organizadas por expertise técnica. Se a Sara conhece uma seção do sistema, ela recebe as tarefas relacionadas.
Os resultados deterioram. Stand-ups se tornam relatórios de status sobre tarefas isoladas que ninguém entende. A visibilidade de produto desaparece. O trabalho supostamente converge no final, mas os prazos continuam deslizando.
Melhorando com princípios
Durante meu tempo na ThoughtWorks, lembro de uma reunião memorável sobre problemas não relacionados a software. Ao resumir a situação para um colega, a resposta dele ficou comigo: analisamos problemas, dividimos em pequenas peças independentes, concluímos e verificamos cada uma.
Essa simplicidade ressoou — representava resolução padrão de problemas. O insight transformou uma pergunta avassaladora em passos gerenciáveis.
Esse pensamento gerou três princípios centrais que apliquei em diversos times:
Prioridade
As prioridades devem ser claras. Mantenha um único backlog com regras de entrada/saída. Todos os itens devem ser focados em negócio ou cliente, entregáveis e independentemente verificáveis.
Foco
Não abandone trabalho. Atribua um ou mais engenheiros a um único trabalho simultaneamente. Ajude ou realoque pessoas se surgirem complicações, mas nunca abandone peças. Cycle time representa a medida de otimização — não a única, mas a que fará a maior diferença.
Conclua
Concluído significa ter um trabalho entregue e verificado por quem pediu, de preferência em produção. Times trabalham de forma colaborativa, ajudando uns aos outros com habilidades e expertise complementares.
Isso não é tudo que é necessário para o sucesso de um time, mas representa uma boa parte. Brian Guthrie capturou isso melhor:
O molho secreto do desenvolvimento de software é mudança incremental, ciclos curtos de feedback, conhecimento compartilhado e respeito mútuo.
Algumas táticas comuns
Alcançar princípios requer implementação prática. Embora não exaustivas, essas práticas ajudam os times a alcançar os princípios acima:
Mude os stand-ups. Pare de focar nas pessoas (“o que eu fiz ontem”), foque no trabalho (“o que está acontecendo com esse card”). Esses stand-ups que percorrem o quadro não são novidade.
Prioridade é da direita para a esquerda, de cima para baixo. Deixe claro que engenheiros devem priorizar concluir cards em vez de começar novos. Adote “pare de começar, comece a terminar” como mantra de seleção.
Não diga aos engenheiros o que fazer. Não crie listas de tarefas técnicas para outros. Forneça orientação em conversa quando o trabalho começa, não como listas de afazeres antecipadas. Engenheiros tomam centenas de decisões diárias — mais contexto melhora essas decisões.
Não atribua trabalho antecipadamente. Embora times façam isso por responsabilidade, isso pressiona trabalho individual sobre trabalho em equipe, tornando o sistema mais lento e reduzindo o suporte mútuo.
O trabalho deve ser compreensível pelo negócio. Não aceite cards escritos por engenheiros. Entregue trabalho que pessoas não técnicas entendam e verifiquem. Trabalhe em par nos testes e verificação.
Faça triagem de defeitos e meça o tempo gasto. Troca de contexto e distrações matam a produtividade. Estabeleça regras de urgência quando bugs surgirem.
Acompanhe cycle time e alocação de tempo. Monitore onde os times gastam tempo. Os resultados vão surpreender você.
Acho que é isso. Ou pelo menos a maior parte.