Como evito o surgimento de recursos em um projeto solo?

Então, eu tenho um programa em que trabalhei em 2011 e durante todo o ano de 2012, mas o último lançamento foi em dezembro de 2011 . Eu tenho trabalhado ativamente nele, mas o recurso de arrasto atraiu sua cabeça feia e agora está cheio de toneladas de recursos inacabados.

A parte ruim é que, ao implementar um recurso, surge um novo. O que posso fazer para evitar o surgimento de recursos no futuro, para que eu possa lançar um lançamento em mais de um ano ?

O projeto é baseado no iOS e costumava ter lançamentos em torno de cada atualização de versão do iOS, mas o último estava de volta com 5.1 (2011). Eu gostaria de poder recuperar esse ciclo de liberação constante, mas provou ser muito difícil.

Na minha experiência, é mais fácil se você puder ter uma cadência de desenvolvimento e liberação que não atrapalhe o que você quer que seja feito. Aqui está como eu fiz isso:

1. Anote os recursos e dê a eles uma classificação que reflita o quanto você deseja trabalhar nele e o quanto você acha que isso beneficiará o usuário (pode ser possível envolver usuários reais para isso). Em seguida, escreva-os nessa ordem.
2. Antes de fazer o check-in / envio de um recurso, verifique se você tem uma compilação estável e implantável (considere fortemente um sistema de IC para facilitar isso).

Dessa forma, você pode simplesmente enviar um release após cada recurso, se desejar ... ou aguardar um rollup que ofereça o valor que você deseja que um release tenha.

Nota:

• Um recurso nunca pode ter uma prioridade mais alta do que a que você está trabalhando (ou pode, mas não pode interromper a que você está trabalhando). Pode vir a seguir, mas nunca agora . Isso significa que, quando você passar de agora para o próximo, terá a oportunidade de cortar uma versão, se quiser.

A resposta é banal e frequentemente impossível: recuse-se a adicionar recursos adicionais.

Mais profundamente, a resposta realmente se resume ao que faz com que um novo recurso caia na lixeira de recurso? Se assumirmos que os recursos que fluem são aqueles adicionados a um projeto, apesar de sua funcionalidade ser tangencial apenas ao uso pretendido do projeto e que os recursos de fluência são úteis, e não supérfluos, a resposta é movê-los para separar , mas ferramentas relacionadas. Use a filosofia Unix de criar ferramentas ortogonais e colá-las.

Do ponto de vista do gerenciamento de projetos, a resposta é comparável. Decida quanto tempo você deseja dedicar ao próximo lançamento e defina um prazo. Estime os recursos e corte o suficiente para cumprir o prazo. Se houver outras partes interessadas além de você, faça com que elas escolham o que é mais importante para elas.

Uma boa visão geral sobre agendamento pode ser encontrada no Joel on Software:

http://www.joelonsoftware.com/articles/fog0000000245.html

Uma das lições mais importantes do desenvolvimento é saber quando é a hora de parar.

O que normalmente acontece é que um desenvolvedor adiciona um recurso. Isso, por sua vez, inspira mais idéias. Assim, mais recursos são adicionados. Essa é, como você disse, uma das maneiras pelas quais um projeto se torna vaporware. O desenvolvedor nunca vê o projeto como 'concluído', portanto nunca é lançado.

O hábito em que você deseja entrar é parar de pensar em termos de um lançamento / versão como um projeto 'finalizado'. Em vez disso, olhe o desenvolvimento como um processo de longo prazo. Pense nos lançamentos como marcos no caminho para o que um dia você espera que o programa seja. Assim, um release / versão é apenas um instantâneo de onde você está no processo de longo prazo ... um instantâneo que foi bem arredondado e testado.

O que você pode fazer, do lado prático, é sentar e especificar seu próximo lançamento. Não precisa ser terrivelmente completo. Anote as 3-5 novas e principais funcionalidades que você considera essenciais para a próxima versão. ( o número real de recursos pode variar dependendo do tipo de aplicativo, sem contar as correções de bugs ou pequenas alterações de interface gráfica ). Se você tiver outras idéias, tudo bem ... apenas faça anotações e implemente-as no release a seguir. Quando você concluir esses 3 a 5 itens, seu lançamento estará pronto para a versão beta.

Quando inicio um novo aplicativo, normalmente penso na 'visão' final do aplicativo. Isso, para mim, é o que eu quero na versão 3 do aplicativo. Com esse benchmark, tenho uma idéia do que tornará a versão 1 sólida - apenas o básico.

Resumo:

Cada versão não precisa ser a 'visão' finalizada do projeto. Apenas um marco para essa visão.

Use um sistema de controle de versão no qual seja barato criar uma ramificação para alguma idéia e mantenha-a fora do caminho de liberação. Por exemplo git, você pode "sugerir" alguma idéia e depois git stashafastá-la. Mais tarde, você pode revisar esses esconderijos e selecioná-los em qualquer ordem que parecer interessante.

Para recursos maiores, faça uma ramificação real (para que você possa fazer várias confirmações). Caso em questão: quando eu queria adicionar suporte geracional ao coletor de lixo, criei uma ramificação. Os esconderijos capturam muito bem as pequenas coisas que distraem. Os grandes recursos podem começar como esconderijos, transformar-se em ramificações e, finalmente, mesclar quando estiverem prontos.

Com stashes e branches, você pode fazer um balanço de suas idéias, priorizá-las e estabelecer um escopo para os lançamentos de seu projeto solo, assim como um projeto de equipe gerenciada.

Olha, quando você tem uma idéia, ela precisa ir a algum lugar , e o melhor é o código : o repositório. Recursos rastejantes são melhores do que esquecer boas idéias. Mas é claro, se você incluir todos os seus recursos na mesma linha principal, ele continuará atrasando o lançamento, a menos que você faça lançamentos desarrumados cheios de coisas pela metade que os usuários precisam ser avisados ​​para não usar.