Esta pergunta realmente contém duas perguntas, que precisam ser abordadas separadamente:
Por que algumas equipes têm um processo de desenvolvimento rigoroso?
A resposta simples é porque, se não o fazem, erros acontecem. Erros caros. Isso vale para o desenvolvimento e também para o restante do campo de TI (administradores de sistemas, DBAs etc.).
É muito difícil para muitos desenvolvedores e profissionais de TI entenderem porque a maioria de nós já trabalhou em um dos "extremos" - grandes empresas do estilo Fortune, com pelo menos uma dúzia de desenvolvedores e processos rigorosos a seguir, ou pequenos, micro-ISVs ou até trabalhos freelancers, onde as pessoas simplesmente não estragam muito, ou o custo de um estrago é baixo.
Mas se você já viu uma empresa entre essas fases - mesmo uma empresa com uma equipe de TI brilhante e talentosa -, entenderá os perigos de não ter nenhum processo ou de ter um processo pela metade. Veja bem, a comunicação entre funcionários sofre de um problema de explosão combinatória ; Depois de atingir o nível de 6 a 10 desenvolvedores em uma única equipe, a principal causa de defeitos graves ou críticos não é a falta de talento ou conhecimento, mas a falta de comunicação.
Alice pergunta na segunda-feira de manhã e decide que não há problema em fazer uma cirurgia reconstrutiva no porta-malas, porque ninguém mais está trabalhando nessa parte. Bob chega uma hora depois, de volta de suas férias e cheio de energia e decide que ele implementará um novo recurso importante exatamente na mesma área, e por que se preocupar com um ramo, porque ninguém nunca toca nesse código? Então Alice paga essa "dívida técnica", Bob implementa seu recurso matador que está em segundo plano há 6 meses, e quando eles finalmente verificam seu código (logo antes do fechamento da sexta-feira, é claro!), Todo A equipe precisa ficar para trás e tentar lidar com o inferno de pesadelos de conflitos que continuam a viver como bugs e regressões ao longo das próximas semanas.
Alice e Bob Ambos fizeram um ótimo trabalho nas tarefas de codificação, mas ambos começaram com uma má decisão ("o que de pior pode acontecer?"). O líder da equipe ou o gerente de projetos os conduz a um post-mortem e elabora uma lista de verificação para impedir que isso aconteça novamente:
- Os check-ins devem ser diários para minimizar o impacto dos conflitos;
- Alterações que levarão significativamente mais de um dia devem ser feitas nas filiais;
- Todas as tarefas significativas (incluindo trabalhos que não são de recursos, como refatoração) devem ser adequadamente rastreadas e atribuídas no rastreador de erros.
Aposto que, para muitos de nós, esse "processo" parece apenas senso comum. É chapéu velho. Mas você sabia que muitas equipes menores não fazem isso? Uma equipe de dois homens pode nem se importar com o controle de origem. Quem se importa? Honestamente, não é necessário. Os problemas só começam a acontecer quando a equipe cresce, mas o processo não.
Obviamente, a otimização de processos é como a otimização de desempenho; segue uma curva exponencial inversa. A lista de verificação acima pode eliminar 80% dos defeitos, mas depois de implementada, você descobre que outra coisa é responsável pelos 80% restantes . Em nosso exemplo fictício, mas familiar, pode haver erros de compilação devido a diferentes ambientes de compilação, o que é devido ao fato de que não há hardware padrão e os desenvolvedores estão usando bibliotecas de código aberto que são atualizadas a cada 2 semanas.
Portanto, você tem três opções: (a) padronizar o hardware e restringir severamente o uso de bibliotecas de terceiros, o que é caro e pode prejudicar significativamente a produtividade ou (b) configurar um servidor de compilação, que requer a cooperação do grupo sysadmin e de um desenvolvedor em tempo integral para mantê-lo, ou (c) permitir que os desenvolvedores façam isso eles mesmos distribuindo uma máquina virtual padrão e instruindo os desenvolvedores a desenvolverem isso. Claramente (b) é a melhor solução a longo prazo, mas (c) possui um melhor equilíbrio a curto prazo de confiabilidade e conveniência.
O ciclo continua e continua. Todas as "políticas" que você vê geralmente foram instituídas para resolver um problema real. Como Joel Spolsky escreveu em 2000 (em um tópico completamente diferente, lembre-se, mas relevante, no entanto):
Quando você entra em um restaurante e vê uma placa que diz "Não são permitidos cães", você pode pensar que a placa é puramente proscritiva: o Sr. Restaurant não gosta de cachorros por perto, então quando ele construiu o restaurante, ele colocou a placa.
Se isso era tudo o que estava acontecendo, também haveria um sinal de "No Snakes"; afinal, ninguém gosta de cobras. E um sinal de "sem elefantes", porque eles quebram as cadeiras quando se sentam.
A verdadeira razão pela qual esse sinal existe é histórico: é um marcador histórico que indica que as pessoas costumavam tentar trazer seus cães para o restaurante.
É o mesmo na maioria das equipes de software (não direi todas): políticas como "Você precisa adicionar um caso de teste para cada correção de bug" quase sempre indicam que a equipe historicamente teve problemas com regressões. Regressões são outro daqueles problemas que são mais frequentemente causados por falhas na comunicação do que por incompetência. Desde que você entenda a política, poderá usar atalhos legítimos (por exemplo, eu tive que corrigir 6 pequenos bugs, mas todos estavam no mesmo recurso, para que eu possa escrever apenas um caso de teste para todos os 9).
Isso explica por que os processos estão lá, mas não é a história toda. A outra metade é:
Por que o processo é tão difícil de seguir?
Esta é realmente a pergunta mais simples a ser respondida: é porque a equipe (ou seu gerenciamento) está focada em resultados repetíveis e na minimização de defeitos (como acima), mas não deu atenção suficiente à otimização e automação desse processo.
Por exemplo, na pergunta original, vejo vários problemas:
O sistema de controle de revisão (CVS) é legado pelos padrões atuais. Para novos projetos, ele foi substituído quase inteiramente pelo subversion (SVN), que está rapidamente se eclipsando por sistemas distribuídos como o Mercurial (Hg). Mudar para Hg tornaria a ramificação e a fusão muito mais simples e, mesmo no meu exemplo hipotético acima, o requisito de confirmação diária se tornaria muito menos doloroso. O código nem precisa ser compilado, porque o repositório é local; - de fato, os desenvolvedores mais preguiçosos poderiam até automatizar esta etapa, se quisessem, configurando um script de logoff para confirmar automaticamente as alterações no repositório local.
Não houve tempo para automatizar o processo da Máquina Virtual. Todo o processo de obtenção, configuração e download de fontes / bibliotecas para uma máquina virtual pode ser 100% automatizado. Pode ser um processo autônomo que você executa em um servidor central em algum lugar enquanto trabalha na correção de bugs em sua máquina local (e usa apenas a VM para garantir uma compilação limpa).
Por outro lado, em uma certa escala, a solução VM por desenvolvedor começa a ficar boba e você deve ter apenas um servidor de Integração Contínua. É aí que surgem os reais benefícios da produtividade, porque (principalmente) libera os desenvolvedores individuais de terem que se preocupar com as construções. Não é necessário se preocupar em configurar máquinas virtuais limpas, porque o servidor de compilação está sempre limpo.
A redação da pergunta ("caso de teste com todas as etapas") implica que há algum teste manual em andamento. Isso, novamente, pode funcionar para equipes pequenas com uma carga de trabalho relativamente baixa, mas não faz sentido em escala maior. Os testes de regressão podem e devem ser automatizados; não há "etapas", apenas uma classe ou método adicionado ao conjunto de testes de unidade / integração.
Escusado será dizer que a mudança do Bugzilla para um novo (melhor) sistema de rastreamento de bugs tornaria essa parte da experiência muito menos dolorosa.
As empresas não são necessariamente baratas ou estúpidas só porque não resolveram esses problemas. Tudo o que sabem é que o processo atual funciona e, em alguns casos, são avessos ao risco e relutam em mudar alguma coisa. Mas, na verdade, eles só precisam se convencer dos benefícios .
Se os desenvolvedores passassem uma semana monitorando seu tempo em todas as tarefas que não são de codificação, você poderia facilmente adicioná-lo, mostrar à gerência que (por exemplo) um investimento de capital zero e 100 horas por homem em uma atualização para o Mercurial eliminar até 10 horas-homem por semana na resolução de conflitos de mesclagem, então isso é um pagamento de 10 semanas e eles certamente concordarão com isso. Mesma idéia com servidores de construção (CI) ou melhor rastreamento de erros.
Para recapitular: As equipes ainda não fizeram essas coisas porque ninguém convenceu a gerência de que é importante o suficiente para fazer hoje . Portanto, tome a iniciativa e transforme-a em uma equação de custo-benefício; descubra quanto tempo é gasto em tarefas que podem ser simplificadas / automatizadas com risco mínimo e calcule o ponto de equilíbrio e o retorno final de uma nova ferramenta ou técnica. Se eles ainda não escutarem, você já sabe quais são as opções restantes.
Se os desenvolvedores passaram uma semana rastreando seu tempo em todas as tarefas que não são de codificação, você pode adicioná-lo facilmente, mostrar o gerenciamento ... e transformá-lo em uma equação de custo-benefício, etc.
A parte acima parece valer a pena expandir ainda mais.
Eu posso confirmar que funciona. Os programadores o usaram algumas vezes em um dos projetos nos quais trabalhei e toda vez que levava às alterações desejadas.
Minha impressão geral foi que, se bem feito, esse truque pode anular quantidades bastante pesadas de ignorância e inércia da gerência.
Gostaria de observar que a empresa em que nós (desenvolvedores) tivemos que recorrer a esse tipo de abordagem DIY era muito imatura em termos de TI. Em fornecedores de software mais experientes, vi coisas assim sendo feitas principalmente pelos próprios gerentes. E, como regra, eles eram mais produtivos nisso do que nós, programadores. Muito mais produtivo.