Como você sabe quando parar de adicionar recursos?

Há algum tempo, escrevi um script python muito pequeno que verificava periodicamente um feed xml em busca de novas entradas e alertava o usuário sobre novas entradas quando presentes. Eu escrevi isso para mim mesmo, por isso era essencialmente um programa baseado em console que qualquer pessoa confortável com uma interface de console poderia ter usado.

Depois de um tempo, decidi que poderia ser mais útil para outras pessoas e comecei a arrumar, higienizar insumos e remover bugs. Ocorreu-me que, por ter escrito o script, sabia como usá-lo com eficiência, precisão etc. Outros podem não, então comecei a adicionar uma GUI. Isso começou como um menu simples e depois expandiu-se para uma GUI mais completa, com um menu de interface e opções. Em seguida, adicionei preferências de usuário armazenadas e também armazenamento para feeds XML pesquisados ​​anteriormente para acelerar pesquisas repetidas.

Eu adicionei o log para ajudar a depurar o aplicativo, caso algo dê errado, levei o aplicativo até a mais recente base de código python estável disponível para a minha plataforma escolhida e aprimorei os recursos de diálogo.

Corrigi o bug e comentei meu código com clareza, e ainda tenho coisas que acho que podem ser feitas para melhorar o aplicativo antes de disponibilizá-lo aos testadores alfa. É muito distante do meu script original de 20 a 30 linhas. O que eu previa que levaria apenas uma ou duas horas para passar da prova de conceito para um programa de uso aceitável levou de 10 a 20 vezes isso. (Eu ainda sou um noob, e as coisas me levam muito tempo, mas ainda ....)

Como você sabe quando parar de adicionar / ajustar / consertar coisas e deixar seu bebê rastejar ao ar livre?

Quando você atinge o prazo.

Se você não tem prazo, este é o seu problema ...

Aqui está como eu trabalho:

1. Eu adiciono novos recursos / bugs no backlog do meu produto.
2. Priorizo ​​toda a lista de pendências de produtos em valor comercial e estimada (a última é opcional em caso de projeto pessoal).
3. Eu aloco tempo de trabalho para mim. A data de lançamento é o fim desse período.
4. Começo com o primeiro da lista. Eu trabalho em um recurso por vez. Para ser concluído, um recurso deve estar realmente completo, incluindo documentação (no final de um recurso, posso enviar o produto potencialmente).
5. Eu pego o próximo até que meu tempo alocado seja consumido.
6. Se o tempo for consumido quando estou criando um recurso, eu o descarto temporalmente.
7. Quando o tempo alocado é consumido, pego a versão mais recente e faço um lançamento com ela.
8. Repito o processo a partir do ponto 1.

Faça um SRS e codifique de acordo com os requisitos. Quando você atingir todos os objetivos mencionados no SRS, é hora de parar e testar seu produto.

A curto prazo, quando você tem algo que funciona de maneira confiável e não falha. Mesmo que não faça tudo o que poderia , se você trabalhasse indefinidamente. Envio como diz o ditado é um recurso . Confiabilidade e conjunto de recursos restritos oferecem a oportunidade de a funcionalidade principal ser testada por pessoas reais no mundo real, que encontrarão coisas que você nunca pensou em quebrar o código de maneiras que nunca passariam pela sua cabeça. Quanto menos recursos você tiver, neste momento, mais fácil será corrigir esses problemas iniciais. Como a funcionalidade principal funciona de maneira mais confiável, você pode começar a implementar as outras coisas "legais de ter" com o conhecimento de que seu código mais importante e central ainda funciona bem.

A longo prazo: Quando você concluir e documentar o sistema de plug-in que permitirá que seus usuários (e claro que você) implementem novos recursos de maneira rápida e fácil, se você precisar deles. Esse deve ser o último recurso que você precisa adicionar; depois, são todos os plug-ins.

Quando tiver certeza da estabilidade do seu software, vá para uma versão, embora possa haver recursos pendentes. A estabilidade é mais importante que os recursos. Obtenha o feedback, incorpore-o aos recursos existentes e decida o que deve ser entregue a seguir e quando!

Você sempre pode cuidar de um projeto para todo o sempre.

Uma regra muito boa é que você nunca deve adicionar itens que não estejam em um caso de uso aprovado. Isso garante que você não acabe com muitas coisas que seria bom ter, mas que ninguém usa. A aprovação garante que outras pessoas, além das que você concorda, sejam necessárias no seu projeto.

Depende do motivo pelo qual você está adicionando recursos. Os proprietários do projeto estão pedindo por isso? Comercial? QA? Programadores?

• Adicione os recursos que você precisa.
• Analise os recursos que são importantes.
• Ignore os recursos que é bom ter.

Concentre-se no objetivo do programa e faça com que ele seja focado. Solicitações de recursos que estendem seu objetivo devem ser cuidadosamente questionadas antes de se tornar um canivete suíço.

Não paro mais de adicionar recursos. Eu apenas tento disponibilizar o aplicativo o mais rápido possível e gravar arquivos txt, se necessário. Então eu posso decidir quando parar e quando trabalhar em algo diferente

Também ajuda que eu gosto de fazer o mínimo possível para fazer algo (sem recorrer a hackers).

Eu sugiro que você timebox. Dê uma semana para você dizer. Crie uma lista de trabalhos a serem concluídos durante essa semana e, se você tiver um recurso que não pode concluir, poderá recuperá-lo.

No final da semana, libere-o. Solte cedo, solte frequentemente.

Quando você tiver algo confiável e útil, solte. Você não precisa parar de adicionar recursos, mas se alguém estiver usando o que você tem por aí, terá uma idéia muito melhor de quais recursos são desejados. Atualmente, você está supondo.