Lidar com um projeto sem fim não corrigível

Temos um site grande (mais de 1200 horas) que possui muita dívida técnica. Isso é causado principalmente pelos seguintes motivos (comuns).

1. Vários programadores que entram e saem durante o desenvolvimento.
2. Mudança de especificações durante o desenvolvimento.
3. Inúmeras funcionalidades adicionadas (em pouco tempo).

O cliente deseja muitas novas funcionalidades, e isso basicamente se resume a trabalhar nesse projeto semanalmente por mais de 10 horas.

Devido à dívida técnica, passamos MUITO horas corrigindo ou investigando problemas, que geralmente encontram sua origem em um dos seguintes:

1. Um inseto vergonhoso e bobo que faz as pessoas chorarem
2. Um novo recurso resulta no exposto acima, porque não tínhamos previsto todos os lugares em que o novo recurso teria influência.
3. Alguns outros problemas que enfrentamos (migração de servidor fe, atualizações)

Temos problemas diariamente e tentamos seguir as coisas para interromper isso:

1. Criação de documentação técnica referente à importação, pagamento e funcionamento geral do site.
2. Faça uma reunião no início da semana - discutindo as questões ou melhorias atuais e como elas devem ser abordadas.
3. Tenha um plano de teste. Programador A teste B, B testa C e C testa A. Em seguida, nosso gerente de projeto fará alguns testes. Em relação ao impacto do recurso, o lançamos em um ambiente de preparação e deixamos o cliente verificar por si próprio.

O problema é que os problemas continuam acontecendo ... e, de alguma forma, não conseguimos entender. Novos recursos ainda causam erros, e os antigos continuam dizendo olá. De alguma forma - talvez devido ao tamanho do projeto - não conseguimos entender esse projeto.

Suponho que existem muitos programadores trabalhando em projetos maiores do que isso. É por isso que venho à minha pergunta:

O que podemos fazer ou o que você faz para evitar esses problemas em grandes projetos?

Edição secundária, informações adicionais:

1. Usamos controle de versão (SVN).
2. Temos processo de desenvolvimento DTAP.

Vou bancar o advogado do diabo, tendo visto com muita frequência como isso acontece: você não pode lidar com isso. Eu garanto que você é o único que realmente vê um problema real no sistema, ou não precisa perguntar como lidar com ele, porque a cultura da empresa seria a de eliminar erros e corrigir o código. sempre que possível, ou seja, operando como profissionais reais trabalham.

Aposto que é muito grande para começar a escrever testes de unidade, porque não havia ninguém que soubesse fazer o teste de unidade antes de você (e com sorte outras pessoas da sua equipe) e é impossível saber por onde começar, e talvez até impossível. teste porque se baseia em implementações exatas e dados concretos, por isso levaria muito tempo para extrair tudo isso para interfaces, zombarias, stubs e similares para poder testá-lo em primeiro lugar. Aposto também que você não pode simplesmente refatorar o que precisa ser refatorado porque está muito acoplado e, como não há testes, quem sabe o que será quebrado corrigindo códigos incorretos. Em suma, provavelmente se tornou muito canceroso para ser corrigido seriamente, mas é claro que não pode ser apenas cortado e recomeçado.

Você está travando uma batalha perdida, meu amigo. Ou você se queimará de frustração e, eventualmente, desistirá ou ficará louco, ou se você reclamar disso por tempo suficiente, tentando convencer os outros a entenderem os problemas, eles acharão que o único problema é você e você verá a porta.

O teste de unidade é um bom ponto de partida se você não estiver fazendo nada. No mínimo, eles o protegerão contra a adição de novos erros ao corrigir erros antigos.

O controle de fonte também ajuda, a menos que você não o esteja usando. Os recursos de culpa e registro, em particular, são maravilhosos para definir como / por que um código de buggy foi comprometido.

No final do cliente, descobri que discutir preços e atrasos (demorados) assim que alterações / recursos adicionais são solicitados funciona razoavelmente bem, assim como cobrar pelo tempo que você gasta discutindo / projetando-os. Freqüentemente, os clientes decidem que, pensando bem, podem esperar.

(Por outro lado, se você descobrir imediatamente as especificações e idéias de implementação com ele, elas normalmente o configuram para um "oh, eu pensei que tínhamos concordado que você faria isso de qualquer maneira" ou (pior, depois de vários dias de volta e adiante sobre os detalhes) "mas veja, ele já foi projetado e nós o que discutimos não parece tão difícil!".)

Por último, mas não menos importante, descobri que ser franco só leio emails uma vez por dia (ao chegar ao trabalho) e que tenho um telefone para algo mais urgente, leva a um tremendo aumento de produtividade.

Sugiro que você adicione alguns testes baseados em IC, principalmente nas áreas que quebram com mais frequência. Isso o ajudará a aumentar a qualidade à medida que o trabalho estiver sendo realizado no projeto.

Também fica mais claro quais áreas / funcionalidades quebram com mais frequência e, portanto, é mais fácil decidir quais partes precisam ser refatoradas ou, pelo menos, mais testes.

A adição de mais riscos de teste manual faz com que o projeto siga o caminho errado em termos de $$$ e tempo necessários por recurso adicionado.

Alguma revisão de código é boa, mas talvez isso faça parte do esquema de teste A-> B-> C-> A. (Talvez a revisão de código na outra direção?)

Deixe-me jogar uma fábula em você. Você estava passeando com uma pessoa no início da rua e chegava ao seu destino. A pessoa com quem você está andando rapidamente descobre que ele perdeu o anel em algum lugar ao longo do caminho, para que você decida voltar e procurar por ele. A pessoa com quem você está andando pára rapidamente em um poste de luz e começa a olhar freneticamente. Você diz: "Por que você está olhando para o poste quando acho que você o perdeu quando atravessamos o beco?". Ele responde: "Eu sei, mas a luz é melhor aqui".

Estive nesta situação mais de algumas vezes e notei alguns pontos em comum. Esses tipos de projetos de pesadelo de manutenção geralmente são executados em um ambiente pesado de processo, com muita supervisão e melhorias de processo impostas pela gerência. Não estou dizendo que aprimoramentos de processo são uma coisa ruim, mas, na maioria das vezes, os tipos de aprimoramentos de processo que o gerenciamento normalmente deseja implementar têm dois pontos principais.

1) Eles geralmente não perturbam a política do escritório e o equilíbrio de poder. 2) Eles conseguem criar a ilusão de controle por parte da gerência, em vez de atacar o cerne da questão.

O pensamento da gerência de "a luz é melhor aqui" geralmente diz: "Todo novo recurso deve ter uma especificação técnica detalhada" ou "Vamos ter um status por hora reunido todos os dias para discutir problemas e como superá-los".

Nenhuma dessas coisas realmente atinge o cerne das questões e elas podem apenas diminuir a produtividade, mas certamente validam a ilusão de controle por parte da gerência.

As únicas mudanças verdadeiras pelas quais você pode ajudar são aquelas que abalam as coisas. Suspeito, no entanto, que a sua monstruosidade de um site esteja provavelmente irreparável neste momento e você esteja mais à frente para re-arquitetar e reescrever. Para o futuro, no entanto, você deve ter em mente a importância da metodologia Agile, Integração Contínua, Desenvolvimento Orientado a Testes, Revisões de Código e especificações de requisitos de negócios que são reguladas sob rigorosos procedimentos de Controle de Mudanças para ajudar a minimizar a fluência do escopo sem ajustes no cronograma.

Esse tipo de mudança realmente exige uma mudança na maneira de pensar no nível gerencial e, em toda a minha experiência profissional, nunca vi isso acontecer sem algum tipo de alteração no nível de gerência intermediária. Espero que isso não seja muito desanimador, pois você deve tentar o que é certo, independentemente de estar travando uma batalha difícil, porque provavelmente encontrará forte resistência por pessoas que amam o status quo.

Estive no mesmo local há algum tempo. Não sou mais graças a duas regras simples:

• Toda semana, um ou dois dias são gastos corrigindo / reescrevendo a maioria das partes peludas do aplicativo. Sem caça de bugs, sem desenvolvimento de novos recursos.
• Ao implementar novos recursos, esforçamo-nos para acertar, mesmo quando passamos mais tempo do que o cliente espera.

O único problema é fazer com que outras pessoas os respeitem. A parte fácil surpreendentemente foi o cliente. Não posso explicar o porquê, mas de alguma forma o convencemos de que, quando trabalhamos em um recurso um pouco mais, é melhor para todos. Respeitar a primeira regra acaba sendo mais problemático, mas também achamos que isso nos ajuda muito. Garante um progresso constante à medida que diferentes partes do aplicativo estão melhorando.

Revisões de código. Testes unitários. Teste de controle de qualidade real. Processo de coleta de especificações e desenvolvimento incremental - são algumas das coisas que devem resolver a maioria dos seus problemas.

Além disso, não permita que os clientes façam ping diretamente em seus desenvolvedores - essa é geralmente a maneira mais improdutiva de resolver problemas. Contrate um bom gerente de programa que formará a interface entre seus clientes e desenvolvedores. Seu trabalho seria conhecer o produto de ponta a ponta, o status atual, as direções futuras e assim por diante. Sempre que o cliente desejar outro novo recurso, ele poderá fornecer a lista atual de itens e mostrar aos clientes o que será pago se essa nova solicitação for aceita.

O processo é ruim quando usado muito pouco ou muito. Eu acho que você está no estado anterior.

Como Deni menciona, se você puder adicionar testes de unidade ao projeto, isso ajudará você. Faça um teste que cubra uma parte do sistema que você está prestes a alterar / consertar e, portanto, quando seu código de refatoração, use esse teste como um guia para garantir que você não está quebrando nada.

Além disso, trie as partes mais quebradas do código. Tente colocar os mais afetados em uma lista de riscos e gerencie esses riscos de forma independente. Tente ter uma idéia de quanto código quebrado há na base de código, consultando onde os bugs ocorrem mais. Você pode listar a área afetada pela contagem de erros (ou problemas relatados, o que funcionar melhor para você).

A atualização e a limpeza do código levarão tempo, mas se cada desenvolvedor da equipe puder deixar o código um pouco mais limpo, foi antes de tochiná-lo, com o tempo a base de código melhorará. Se você está procurando um estilo rápido e militar, resolva-o agora, duvido que exista algo prático (ou recomendado) que possa ajudar.

Felicidades. Jas.

Escreva especificações funcionais claras; pedanticamente, para que você possa suportá-lo e revisar a funcionalidade com base nessas especificações regularmente. Quanto menos uma idéia que um desenvolvedor tiver sobre o que ele deveria estar desenvolvendo, menor a chance de haver o modo como ele deveria se desenvolver.

Antes de começar a escrever o código, faça alguns trabalhos iniciais de design; isso não precisa ser perfeito, grande ou conter UML, mas deve descrever uma solução bastante sólida para o problema que precisa ser resolvido. Até onde eu sei, quanto menos software for planejado, pior é. Discuta o design antes de começar a trabalhar nele.

Quando você começa a trabalhar em uma área do código que é claramente ruim e realmente atrapalha o seu progresso; pare de acrescentar a ela, afaste-se do problema, descubra como você pode redesenhar a arquitetura para que os obstáculos não existissem e para que ela fosse mais adaptável no futuro. Quanto mais tempo você o deixar antes de lidar com a dívida técnica, mais difícil será enfrentá-la sem uma reescrita completa. Eu diria que é uma coisa exponencial.

Projete testes que testam o comportamento e não se ajustam perfeitamente à sua arquitetura. Não está muito na moda, mas eu diria que não comece os testes até que o verdadeiro objetivo do seu código esteja claro. Especificamente, não comece o teste até saber o que realmente deseja testar; OMI, um teste mal pensado é pior do que nenhum teste. E quanto mais testes você tiver, mais difícil será alterar seu código internamente. Trate seu código de teste como faria com o código de produção; precisa ser planejado e bem escrito.

Faça análises regulares / diárias do código: trata-se mais de verificação de sanidade para garantir que o desenvolvedor não esteja indo muito longe. Use essas sessões para planejar os próximos dias de trabalho. Pode haver dias em que estes demorem 5 minutos ou 1 hora; o objetivo é manter um diálogo aberto e dar aos desenvolvedores a chance de discutir seu trabalho com outros desenvolvedores e procurar aconselhamento. Faça algumas sessões de emparelhamento em partes difíceis do código ou protótipo de idéias, mas permita que as pessoas tenham seu próprio tempo para trabalhar.

Facilite a criação e implantação do seu código. Tente manter os tempos de construção curtos. Quanto mais fácil for construir, mais será construído, mais rápido será.

Adotar padrões de codificação e aplicá-los rigidamente. Isso deve abranger tudo, desde onde um projeto deve residir no sistema de arquivos até o revestimento de uma const particular. Isso pode parecer inútil e irritante, mas bons hábitos são a pedra angular de um processo de desenvolvimento.

Fundamentalmente, não acho que o processo que você usa seja tão importante, a moda vem e vai. O que realmente importa é que você é profissional sobre como desenvolver software e é disciplinado em sua prática.

Eu começaria projetando e automatizando testes de fumaça e jogando-os no ambiente de CI. Aqueles devem ser funcionais. Quando o cliente lhe disser que algo deve funcionar mais ou menos, peça para anotá-lo, para que você possa consultá-lo mais tarde. Quando vir uma determinada solução no software, faça perguntas e, assim que receber respostas, incorpore-as na base de conhecimento e torne-as rastreáveis.

Garanta que a funcionalidade básica para casos positivos funcione. Em seguida, comece a criar testes incrementais para manipulação incorreta de dados, colocando defeitos onde for necessário. Tenha uma discussão longa e profunda sobre prioridades e informe o gerente de testes para que ele possa atribuir um tempo de teste de acordo. Não tente automatizar tudo, mas assim que alguns casos de teste fizerem sentido para serem automatizados - não hesite.

Em geral, use testes para aumentar a confiança no produto, e não como a ferramenta que aumentará instantaneamente a qualidade. Fique calmo, mas assertivo :). Talvez tente ser ágil, mas somente se você absolutamente, positivamente, contratar um PM certificado. A introdução do Agile por uma pessoa que não o conhece, provavelmente matará o projeto.