O que você faz quando há uma solicitação de última hora para excluir um recurso de um release?

Há um recurso que já passou no teste de aceitação, tanto internamente quanto pelo cliente. É um recurso totalmente funcional. No entanto, agora há uma solicitação para excluir esse recurso de um próximo lançamento. Segundo o cliente, esse recurso deve ser removido porque os usuários não foram treinados sobre como usá-lo.

Qual é o melhor curso de ação para lidar com essa situação? Devemos projetar software antecipando que um recurso possa ser excluído no último minuto usando as definições de configuração? Existem soluções dependentes do contexto que podem ser mais corretas em algumas situações do que em outras?

1. Remova a documentação para o recurso;
2. Desabilite a interface para o recurso (oculte itens de menu ou remova uma opção de um comando do console).

Tudo o resto é muito perigoso.

Meu empregador anterior vende algum software que habilita recursos diferentes com base na licença específica envolvida. Portanto, a capacidade de ativar / desativar recursos em tempo de execução foi projetada. Geralmente, as pessoas chamam isso de "desenvolvimento orientado a recursos" ( artigo da Wikipedia , livro decente sobre o assunto ). Requer muitos testes para encontrar bugs que podem ser causados ​​pela ativação e desativação de recursos. Como a maioria das pessoas no escritório gera uma chave de licença para todos os recursos, os recursos limitados tendem a ser pouco exercitados (e em mais de uma ocasião, não testados até que um cliente ligue para o suporte técnico).

Para sua "correção" de última hora, a solução mais rápida será ocultar os comandos de menu / tecla de atalho / botão que ativam esse recurso. Isto irá introduzir outros erros . Seja direto com seus clientes e gerentes de projeto.

Eu nunca escreveria um código de modo que os recursos sejam ativados ou desativados - a menos que esse requisito tenha sido estabelecido com antecedência.

A remoção ou desativação de um recurso é uma alteração na especificação e, como qualquer outra alteração na especificação, requer tempo para implementar e verificar. Você precisa perguntar por que o recurso será excluído - ele ainda é muito problemático para ser lançado? O cliente não deseja esse recurso? Existe algum motivo comercial para adiar o recurso?

Particularmente, no caso em que o recurso é considerado "buggy demais" para ser lançado, é preciso ter cuidado com o recurso "buggy" ou com o lançamento como um todo que ainda não está pronto para lançamento e esse recurso em particular é exatamente aquele em que os problemas aparecem mais; nesse caso, desabilitar esse recurso não ajudará muito ...

Respondemos às solicitações de última hora discutindo a importância da mudança para o cliente. Fazer alterações importantes imediatamente antes da implementação invalida toda a fase de teste e aceitação. Por isso, movemos a solicitação de alteração para uma versão posterior ou a data de implantação para que a alteração de última hora possa ser testada corretamente (clientes geralmente escolhem passar a alteração para a próxima versão quando descobrem que a alternativa é mudar a data de lançamento :-))

A funcionalidade opcional é a melhor (imho) ativada / desativada via configuração. Como você mencionou, isso deve ser projetado desde o início.

Eu tive que fazer isso no passado, às vezes com recursos que entraram em produção e acabaram sendo um desastre. Eu fiz todo o seguinte.

1) Altere a configuração para desativar o recurso. Funciona onde é configurável 2) Desative / remova todas as entidades da interface do usuário que acionam o recurso. 3) Desative o código no recurso para que ele não faça nada (mas pareça funcionar). Teve que fazer isso onde não tivemos acesso ao código do shell da GUI.

Para saber se você deve projetar a capacidade de ativar ou desativar os recursos, eu veria a imagem ampliada e como você adiciona recursos atualmente. Não é um grande passo transformar recursos em módulos que são descobertos dinamicamente na pior das hipóteses. Eu gosto de modular, então eu tendem a seguir esse caminho.

Às vezes, você pode tornar um recurso inacessível como solução alternativa de curto prazo, mais facilmente do que realmente removê-lo. Verifique se é aceitável ter artefatos visíveis (por exemplo, botões visíveis mas desativados e opções de menu).

Você deve tornar um recurso facilmente comutável apenas se for um requisito que os usuários / administradores possam ativar / desativar o recurso.

Se é fácil o suficiente para você não se importar em fazer isso antecipadamente, provavelmente é igualmente fácil fazê-lo quando você sabe que é necessário e um pouco mais fácil retirá-lo.

Se você não pode desativar o recurso sem risco significativo de introduzir novos bugs, diga isso às pessoas. Caso contrário, você estará basicamente se voluntariando para ser o bode expiatório quando ocorrerem problemas inevitáveis, mesmo que o problema real seja o que resultou nessa mudança de requisitos de última hora.

Com base nas suas edições, acho que esse foi um recurso bastante essencial. Removê-lo pode causar impacto em outras partes do sistema. Realmente, o cliente não deve esperar poder solicitar alterações fundamentais no sistema sem incorrer em custos. Os custos nesse caso são para você de alguma forma desabilitar isso (talvez apenas comentando enormes faixas de código) e testando novamente para garantir que nada foi quebrado.

A maneira mais simples de "desativar" um recurso como esse seria remover / comentar os pontos de entrada no nível mais alto. Por exemplo: se o único ponto de entrada para o recurso for um botão na interface do usuário, basta comentar a linha que cria o botão. Se houver vários pontos de entrada, talvez você precise ir mais fundo para desativá-lo.

Depende muito se for perigosamente danificado / quebrado / indesejado

Se ele não puder fazer nada inseguro e o excluir apenas por motivos de facilidade de uso, falta de documentos de treinamento ou porque está quebrado, normalmente apenas removemos o ponto de entrada desse recurso da interface do usuário e deixamos todo o resto no lugar.

Se for perigosamente incorreto, fazemos isso e adicionamos exceções explícitas na lógica de negócios principal, para que não possa ser executada.

O pior é que o recurso não é desejado (alterações regulatórias tornam o conceito ilegal, por exemplo) e todas as referências ao recurso precisam ser removidas completamente.

À medida que você desce a lista, o potencial de erro aumenta. dependendo da sua situação, a primeira ou as duas primeiras opções podem ser executadas rapidamente; a terceira quase nunca é.

Quanto ao design nos comutadores de recursos, a menos que o cliente queira que eu não siga essa direção até que ele demonstre um histórico de fazer esse tipo de escolha tarde demais.

Minha suposição é que a gerência vendeu esse recurso como um complemento pago e que, no último minuto, o cliente disse que não deseja pagar pelo complemento (provavelmente percebendo que não vale a pena).

Em vista disso, a gerência estragou tudo.

Eu trabalhei com vários sistemas em que o acesso a recursos era direcionado por configurações de segurança. Isso torna esse tipo de recurso desativador relativamente trivial. Apenas não ative o recurso para nenhum grupo de segurança. A menos que o recurso tenha sido ativado para todos, o teste com ele desativado será realizado.

Outros recursos que podem ser desabilitados facilmente estão vinculados aos valores do código. Eles geralmente lidam com um caso específico de algo como um produto, cliente ou qualquer outra coisa. A desativação desses recursos pode ser feita não ativando os valores de código relacionados.

Como outros observaram, alguns recursos têm pontos de entrada de interface do usuário específicos que podem ser removidos. (Os casos acima podem ser casos especiais disso.). A remoção do (s) ponto (s) de entrada deve permitir que você envie o recurso sem ativar o acesso. Geralmente, é a maneira menos arriscada de lidar com esse caso.

Se os recursos forem desenvolvidos em ramificações de recursos, você poderá remover a mesclagem da ramificação de recursos e testar novamente. Isso deve ser mais simples do que outros métodos de desativar o código. Criar um patch de remoção de recurso simplificará a reativação do recurso posteriormente. Isso fornece um equivalente aproximado de um ramo de recurso.