Desenvolvimento é suporte, suporte é desenvolvimento
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Ao longo de muitos anos em desenvolvimento de software, observei um padrão persistente na indústria: empresas tipicamente estruturam o trabalho de software em fases distintas de projeto, e depois transferem os produtos finalizados para times de suporte separados. Esse modelo assume que software é estático — algo que você constrói, finaliza e usa indefinidamente.
O Ciclo de Vida Tradicional do Software
A abordagem convencional em empresas tipicamente segue estes passos:
- Alguém tem uma ideia
- A ideia é considerada boa o suficiente para receber investimento
- Um time é montado e discute a visão, definindo um plano
- O plano é executado com software sendo escrito
- O time transfere o projeto para um time de suporte
- O software está sendo usado
- O time de suporte mantém o software vivo ao longo dos anos
Problemas com Esse Modelo
A Premissa do Software Estático: Essa abordagem trata software como um produto acabado. No entanto, bugs são corrigidos por pessoas que não escreveram o código original e não possuem seu contexto, resultando em suporte ruim e defeitos adicionais.
A Premissa do Negócio Estático: Empresas assumem que suas necessidades de negócio permanecem constantes. Em vez do software se adaptar às necessidades de negócio em evolução, as organizações precisam se adaptar a pacotes de software inflexíveis, prejudicando a performance.
A Mudança DevOps
O movimento DevOps está mudando as práticas de desenvolvimento, com times agora dando suporte a aplicações durante as fases de construção. No entanto, dar suporte a produtos durante o desenvolvimento inicial difere fundamentalmente de evoluí-los e dar suporte ao longo de toda a sua existência.
Uma Abordagem Melhor: Evolução de Software
Produtos em uso ativo deveriam evoluir conforme as necessidades dos usuários mudam. Eles merecem tratamento de primeira classe onde manutenção e evolução do código avançam juntas, prevenindo acúmulo de código legado. Embora os times pós-lançamento não precisem ter o mesmo tamanho dos times de desenvolvimento inicial, eles devem manter contato com o cliente e focar na evolução do produto em vez de correções reativas.
Deveríamos parar de usar suporte como uma palavra ruim. Deveríamos começar a falar sobre evolução de software.