Comment éviter le glissement de fonctionnalité sur un projet solo?

J'ai donc un programme sur lequel j'ai travaillé en 2011 et tout au long de 2012, mais la dernière version était en décembre 2011 . J'ai travaillé activement dessus, mais le fluage des fonctionnalités a attiré sa tête laide et maintenant il est rempli de tonnes de fonctionnalités inachevées.

La mauvaise partie est que je mets en œuvre une fonction, un nouveau dans une chair de poule. Que puis - je faire pour fluage caractéristique d'éviter à l'avenir pour que je puisse effectivement obtenir une sortie sur au cours d' une année ?

Le projet est basé sur iOS et avait l'habitude d'avoir des versions autour de chaque mise à jour de la version iOS, mais la dernière était de retour avec 5.1 (2011). J'aimerais pouvoir récupérer ce cycle de libération stable, mais cela s'est avéré trop difficile.

D'après mon expérience, c'est plus facile si vous pouvez avoir une cadence de développement et de libération qui ne gêne pas ce que vous voulez faire. Voici comment je l'ai fait:

1. Notez les fonctionnalités et donnez-leur une note qui reflète combien vous voulez travailler dessus et combien vous pensez que cela bénéficiera à l'utilisateur (il peut être possible d'engager de vrais utilisateurs pour cela). Écrivez-les ensuite dans cet ordre.
2. Avant de vous enregistrer / pousser une fonctionnalité, assurez-vous que vous avez une version stable et déployable (pensez fortement à un système CI pour faciliter cela).

De cette façon, vous pouvez simplement pousser une version après chaque fonctionnalité si vous le souhaitez ... ou attendre un cumul qui offre la valeur que vous souhaitez qu'une version ait.

Remarque:

• Une fonctionnalité ne peut jamais avoir une priorité plus élevée que celle sur laquelle vous travaillez (ou elle le peut, mais elle ne peut pas interrompre celle sur laquelle vous travaillez). Cela peut venir ensuite mais jamais maintenant . Cela signifie que lorsque vous passez de maintenant à la suivante, vous aurez la possibilité de couper une version de version si vous le souhaitez.

La réponse est banale et souvent impossible: refusez d'ajouter des fonctionnalités supplémentaires.

Plus en profondeur, la réponse se résume vraiment à ce qui fait qu'une nouvelle fonctionnalité tombe dans la corbeille de fonctionnalités? Si nous supposons que les fonctionnalités qui rampent sont celles qui sont ajoutées à un projet malgré le fait que leur fonctionnalité n'est que tangentielle à l'utilisation prévue du projet et que les fonctionnalités rampantes sont utiles, pas superflues, la réponse est de les déplacer pour les séparer , mais des outils associés. Utilisez la philosophie Unix de construction d'outils orthogonaux et de les coller ensemble.

Du point de vue de la gestion de projet, la réponse est comparable. Décidez du temps que vous êtes prêt à consacrer à la prochaine version et fixez une date limite. Estimez les fonctionnalités et coupez suffisamment pour respecter la date limite. S'il y a des parties prenantes impliquées autres que vous, faites-leur choisir ce qui compte le plus pour elles.

Un bon aperçu de la planification peut être trouvé sur Joel on Software:

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

L'une des leçons les plus importantes du développement est de savoir quand il est temps de s'arrêter.

Ce qui se passe généralement, c'est qu'un développeur ajoute des fonctionnalités. Cela inspire à son tour plus d'idées. Donc, plus de fonctionnalités sont ajoutées. C'est, comme vous l'avez dit, l'une des façons dont un projet devient un vaporware. Le développeur ne voit jamais le projet comme «terminé», il n'est donc jamais publié.

L'habitude que vous souhaitez prendre est de cesser de penser en termes de version / version comme un projet «terminé». Considérez plutôt le développement comme un processus à long terme. Considérez les versions comme des jalons sur la voie de ce que vous espérez un jour que le programme soit. Ainsi, une version / version n'est qu'un instantané de votre situation à long terme ... un instantané qui a été bien arrondi et testé.

Ce que vous pouvez faire, sur le plan pratique, c'est vous asseoir et définir votre prochaine version. Cela n'a pas besoin d'être terriblement approfondi. Notez les 3 à 5 nouvelles fonctionnalités majeures que vous jugez essentielles pour la prochaine version. ( le nombre réel de fonctionnalités peut varier selon le type d'application, sans compter les corrections de bugs ou les modifications mineures de l'interface graphique ). Si vous venez avec d'autres idées, c'est très bien ... il suffit de prendre des notes et de les mettre en œuvre dans la version suivante. Une fois ces 3 à 5 éléments terminés, votre version est prête pour la version bêta.

Lorsque je démarre une nouvelle application, je pense généralement à la «vision» finale de l'application. C'est, pour moi, ce que je veux dans la version 3 de l'application. Avec cette référence, j'ai une idée de ce qui fera la solide version 1 - juste les bases.

Sommaire:

Il n'est pas nécessaire que chaque version soit la «vision» finale du projet. Juste un jalon vers cette vision.

Utilisez un système de contrôle de version dans lequel il est bon marché de créer une branche pour une idée, et de la garder hors de votre chemin de publication. Par exemple dans git, vous pouvez "ramper" une idée, puis la git stashretirer. Plus tard, vous pouvez revoir ces cachettes et les choisir dans l'ordre qui vous semble intéressant.

Pour des fonctionnalités plus grandes, créez une vraie branche (afin de pouvoir effectuer plusieurs validations). Exemple: lorsque j'ai voulu ajouter un support générationnel au garbage collector, j'ai créé une branche. Les cachettes capturent très bien les petites choses distrayantes. Les grandes fonctionnalités peuvent commencer sous forme de stashes, puis se transformer en branches, puis enfin fusionner lorsqu'elles sont prêtes.

Avec des stashes et des branches, vous pouvez faire le point sur vos idées, les hiérarchiser et établir une portée pour les sorties de votre projet solo, tout comme un projet d'équipe dirigée.

Regardez, quand vous avez une idée, elle doit aller quelque part , et le meilleur quelque part est le code : le repo. Les fonctionnalités rampantes valent mieux que d'oublier les bonnes idées. Mais bien sûr, si vous glissez toutes vos fonctionnalités dans la même ligne principale, cela retardera la sortie, à moins que vous ne coupiez des versions désordonnées pleines de choses à moitié faites que les utilisateurs doivent être avertis de ne pas utiliser.