Parece que seus problemas são mais gerais.
A questão da refatoração é tanto um sintoma quanto um possível alívio de parte do problema.
O líder de software e a equipe alocam o tempo da equipe
Da minha experiência, acho que você pode estar encontrando um problema que eu chamo, "todo mundo é um gerente de software." Gerentes de produto, gerentes de projeto e, às vezes, engenheiros e testadores de sistemas podem ser notórios por tentar microgerenciar desenvolvedores que provavelmente já possuem um gerente de software experiente. Você pode até ter alguns membros em sua equipe que acreditam que seu papel é gerenciar.
Se você for o gerente de software, faça as atribuições para a refatoração desejada ou, melhor ainda, peça à sua equipe que proponha a refatoração para sua aprovação. Para não microgerenciar, você pode ter diretrizes sobre idade / autor / tamanho / contexto de código a ser refatorado que podem ser livremente refatoradas versus precisar de aprovação. Se um membro da sua equipe quiser refatorar maciçamente quatro grandes classes de código antigo complexo que ele não escreveu e que não fazem parte do seu recurso, seu desvio de duas semanas é problema seu, então você precisa de uma chance para dizer não.
Você pode se esgueirar, mas acho que é melhor apenas construir suas estimativas cuidadosamente com tempo para análise, design, codificação, várias formas de teste (pelo menos unidade e integração), refatoração e risco, conforme julgado historicamente e por a falta de experiência ou clareza associada à tarefa. Se você tem sido muito aberto sobre o trabalho de sua equipe (ou tem membros em sua equipe que são), pode ser sábio restringir canais de comunicação para que eles passem por você e discutam recursos e resultados, não métodos.
As opções iniciais do projeto criam um ciclo vicioso para a refatoração
A manutenção de software é difícil. É duplamente difícil se outros na organização estiverem fazendo escolhas às suas custas. Isso está errado, mas não é novo. Foi abordado por Barry Boehm, que é um dos nossos grandes escritores de software, que propõe um modelo de gestão que ele descreve como Teoria W.
link
Muitas vezes, os desenvolvedores de software são pressionados a produzir sob a abordagem de gerenciamento Theory-X, que diz que os funcionários são basicamente preguiçosos e não irão atuar a menos que sejam submetidos à apresentação. Boehm resume e contrasta seu modelo proposto da seguinte forma:
"Em vez de caracterizar um gerente como um autocrata (Teoria X), um treinador (Teoria Y) ou um facilitador (Teoria Z), a Teoria W caracteriza o papel principal de um gerente como negociador entre seus diversos grupos e um empacotador de soluções de projetos com condições de vitória para todas as partes Além disso, o gestor também é um definidor de metas, um monitor de progresso em direção a metas e um ativista na busca de conflitos de projetos diários de perder ou perder, confrontando-os e transformando-os em situações ganha-ganha. "
Rápido e sujo geralmente é apenas sujo
Boehm continua a apontar a razão pela qual as coisas são tão infelizes para os desenvolvedores da equipe de manutenção.
"Criar um produto rápido e desleixado pode ser um" ganho "de curto prazo e baixo custo para o desenvolvedor de software e o cliente, mas será um" desperdício "para o usuário e o mantenedor." Observe que, no modelo de Boehm, o cliente é mais um administrador de contratos em vez de um usuário final. Na maioria das empresas, pense no gerente de produto como um substituto do cliente ou talvez na pessoa que compra o produto para sua lista de recursos.
Minha solução seria não liberar a equipe de desenvolvimento original (ou pelo menos o lead original) até que o código seja refatorado para pelo menos atender aos padrões de codificação.
Para o cliente, acho razoável contar o gerente de produto como um substituto do cliente, e o grupo de pessoas recompensadas por entregar algo rápido e sujo pode certamente ser expandido, então há um grande público para fazer as coisas da maneira errada .
A refatoração não é negociável
Por favor, não recue da sua função como gerente de software. Você deve ter autoridade e discrição para usar o tempo da sua equipe em melhorias de processo e produto. Nesse papel, talvez seja necessário negociar suas escolhas para tornar sua equipe mais profissional. No entanto, no que diz respeito ao processo, não negocie com marketing, porque na minha experiência, isso é um jogo perdido. Negocie com o gerenciamento de engenharia. Isso mostra que você tem visão. Construir uma equipe de software profissional é uma extensão do seu papel e é muito mais provável que seja vista como uma estratégia ganha-ganha.