Por que separar o trabalho de manutenção do trabalho de desenvolvimento?

Question

Eu trabalho em uma empresa onde a manutenção está sendo feita pela mesma equipe que traz vida a um software.

Muitas vezes, ouço sobre organizações que possuem uma equipe de manutenção separada ou um programador de manutenção. O que eu me pergunto é - o que - o raciocínio por trás disso é?

Além de abandonar o 'código antigo' para mortais menores, existe alguma?

As lições aprendidas com a manutenção de seu próprio "lixo" são de valor muito mais alto? A fixação de defeitos não está muito mais eficaz quando feitos por aqueles que os fizeram começar?

Estou perdendo algum motivo real para que seja benéfico ter uma equipe de manutenção separada?

Answer 1

O conceito que vem à mente para melhor descrever isso é "debulhando. "Este é essencialmente o custos de mudança que você associou a fazer trabalhos de manutenção e trabalho de desenvolvimento. Este é provavelmente o maior motivo para separar as responsabilidades. Outros incluem permitir que os programadores de nível júnior ou básico a oportunidade de molhar os pés e manter seus desenvolvedores mais experientes produzindo itens de maior valor.

Agora, ao mesmo tempo, acho que existe algum valor em um desenvolvedor que escreveu um aplicativo que o apoiou. Primeiro, eles encontrarão rapidamente problemas em seu código com o qual podem aprender. Segundo, eles vão pensar sobre manutenção e qualidade de código, pois eles precisam apoiá -lo.

Exemplo de surra na vida real:

Você recebeu um projeto de desenvolvimento de 1500 horas e também é responsável pela manutenção e suporte de sistemas para seus últimos 3 aplicativos. Durante este novo projeto, você é interrompido 7 vezes por semana, em média, para apoiar esses 3 aplicativos. Cada vez que você começa a trabalhar nos outros 3 aplicativos, você passa 20 minutos envolvendo sua mente em torno do problema. Depois de resolver o problema, você gasta 20 minutos colocando sua mente em volta do código que tocou pela última vez em seu novo aplicativo. Este é um custo total de 40 minutos por interrupção ou 280 minutos por semana. Isso significa que você perdeu 2,67 horas de produtividade na semana apenas ao alternar para suportar esses aplicativos.

Answer 2

Trabalho em uma equipe ágil há mais de um ano. Eu acho que realmente não importa em caso de um produto ao vivo (com isso, quero dizer clientes usando apenas as versões mais recentes). Mas diga que você tem várias versões do seu produto no mercado e precisa apoiar cada uma delas.

Veja a microestação de Bentley, por exemplo. É um aplicativo de design para 3D (arquitetura, design de plantas, rodovias de rodovias, etc.). Agora digamos que temos V8, V9, V10 no mercado. Eles têm recursos diferentes e o formato de arquivo mudou significativamente em relação às versões. Mas os projetos são tão grandes (ou os clientes são tão importantes) que você precisa suportar clientes V8 e clientes V9, além de desenvolver coisas V10. Portanto, é necessário que a empresa tenha uma equipe de manutenção (ou tempo) alocada para versões anteriores. Além disso, geralmente essas equipes são chamadas de equipes de personalização se o seu produto suportar a personalização e o cenário acima mencionado.

Answer 3

O problema é mais prático, eu acho:

• O código antigo foi escrito por pessoas não mais na empresa ou equipe;
• O código antigo foi escrito por desenvolvedores externos;

É realmente comum em muita empresa ter uma base de código que não é mais mantida pelos codificadores originais porque eles não estão mais lá. Se a base de código for grande o suficiente, alguém terá que mantê -lo atualizado para que sejam chamados de mantenedores.

Se você pode evitar esse caso, é bom para você, mas certifique -se de que seja sempre temporário.

Answer 4

Não direi que concordo com a prática, mas em muitas organizações consultores são trazidos a bordo para escrever software em esforços curtos e apressados, após os quais os projetos são entregues a programadores internos para "manter". A lógica é que você pode atrair alguém que é mais habilidoso sem treinamento e, em seguida, inclui "transferência de conhecimento" para pessoas que trabalharão para manter intacta um software.

Em resumo, na maioria das vezes é feito por razões políticas/impraticáveis.

Answer 5

Eu acho que a motivação por trás da divisão da manutenção e das equipes de desenvolvimento de recursos é manter as coisas funcionando sem problemas: se a equipe de desenvolvimento de recursos continuar tendo que parar o que está fazendo para lidar com uma correção de bugs, o projeto será interrompido. Ter uma equipe de manutenção separada liberaria o restante dos desenvolvedores para manter o projeto/produto em questão no futuro.

Answer 6

Meu primeiro trabalho foi manter alguns módulos de software, cujos desenvolvedores originais haviam mudado para algum novo projeto.

Estou supondo:

• Torna o novo desenvolvimento mais previsível, mais fácil de agendar: porque os desenvolvedores não estão sendo cancelados para corrigir algum número desconhecido em avanço de problemas de manutenção

• Oportunidade de treinar novos desenvolvedores (por exemplo, mim)

Além disso, o código que eu mantinha não era "lixo"-era o software de telecomunicações, uma rede inicial com comutação de pacotes, que havia sido implantada para clientes como Bell etc. Foi bem projetado, bem escrito, testável (suítes de automatizado casos de teste), sustentável, muitos arquivos de log, alguma documentação de design ...

... A legenda para o seu OP parece ser: "Cara, esse código fede! Eu gostaria de poder conseguir o desenvolvedor original e esfregar seu nariz: este aprenderia ele! "

Portanto, quando o código já está bem escrito, esse argumento (ensinar os desenvolvedores originais) não é aplicável.

Quando eu digo que estava fazendo "manutenção", era como um novo desenvolvimento de recursos, mas de recursos muito menores ... por exemplo, interopitar com novos dispositivos de clientes que interpretaram a especificação do protocolo de alguma maneira ligeiramente incomum.

Analisaria e diagnosticaria o problema e codificaria uma correção; e uma pessoa de controle de qualidade adicionaria um novo caso de teste correspondente ao conjunto de testes automatizado.

Answer 7

Uma vantagem que posso ver é que, em seguida, há pelo menos uma outra pessoa na organização responsável por entender o código o suficiente para corrigi -lo. Além disso, essa pessoa terá uma agenda diferente em mente e poderá revisar o código da perspectiva da manutenção, se for trazida sobre revisões de design/desenvolvimento (que ele/ela deveria ser).

Além disso, a "manutenção" pode se referir a uma série de atividades como implantação, configuração, backup etc., que definitivamente deve ser tratada por uma equipe diferente.