De temps en temps (lire: à peu près tous les jours) je trouve une nouvelle idée, je démarre un nouveau projet dans mon éditeur / IDE préféré, je commence à coder et le lendemain je le supprime et je commence quelque chose de nouveau. Je programme depuis environ six ans maintenant et au cours de ces six années, je n'ai vraiment terminé qu'un très petit projet (un widget Dashboard pour Pastebin.com). Bien que cela puisse être idéal pour apprendre le codage, je veux vraiment terminer quelque chose.
Que dois-je faire avant, pendant et après le codage? Quelles sont les bonnes ressources qui m'apprennent à organiser de tels projets individuels?
Si c'est important, je veux faire du développement web ou Mac.
project-management
à droite
la source
la source
Réponses:
Je pense que le vrai problème, à long terme, est la motivation plutôt que l'organisation.
Trouvez des utilisateurs et parlez-leur. Considérez votre projet comme une sorte de cadeau (ou de produit vendable) à ces personnes. (Quelqu'un pour faire rebondir des idées est également formidable, même s'il ne développe pas réellement de code avec vous.)
Avoir cette motivation sociale va être beaucoup plus puissant pour garder le projet intéressant à long terme que la simple curiosité personnelle.
Votre objectif doit être de petits morceaux de petites fonctionnalités utiles. Mettez-le sur SourceForge ou GitHub, et traitez le projet comme quelque chose qui a besoin d'une chance de survie même si vous êtes soudainement frappé par un météore.
Cela conduit à plus de versions (ce qui signifie plus de commentaires et d'enthousiasme de la part des utilisateurs) et également une plus grande probabilité qu'une autre personne décide de contribuer au projet.
Choisissez un objectif d'apprentissage spécifique pour vous. Quelle technologie ou technique le projet vous aide-t-il à apprendre? S'il s'avère que la technique ne convient pas à la zone à problème, serez-vous suffisamment intéressé pour au moins terminer la version 1.0 avant de la mettre de côté?
Des exemples de tels objectifs incluent l'écriture d'analyseurs, des protocoles réseau, des aspects de l'IA de jeu, des cadres d'apprentissage ou des boîtes à outils, un nouveau langage, etc.
Le pire des cas signifie manquer les trois, où vous effectuez à plusieurs reprises une "réécriture massive" d'un outil jamais publié impliquant du code que vous ne trouvez pas intéressant pour des personnes dont vous n'êtes pas sûr d'exister.
la source
Lorsque vous avez une idée pour un nouveau projet tout en travaillant sur un projet, notez-la simplement sur une liste d'idées de projet. Revenez ensuite au projet en cours. Si le projet en vaut la peine, ne vous laissez pas distraire par un nouveau projet. Utilisez les étapes suivantes uniquement s'il s'agit d'une idée exceptionnelle.
Avant de commencer notre projet, planifiez-le. Que va-t-il faire? Sera-ce difficile à faire? Quels sont les connus et les inconnus? Qu'est-ce qui risque de mal tourner? Combien de temps cela prendra-t-il? [Vous pouvez maintenant décider d'aller de l'avant ou de vous arrêter maintenant.] Gardez votre plan. [Si vous travaillez sur un projet, mettez de côté le nouveau projet et poursuivez avec l'autre projet original.]
Lorsque vous démarrez votre projet, configurez-le en tant que projet distinct dans votre IDE. (Vous n'avez donc pas besoin de le supprimer pour démarrer votre prochain projet.) Archivez-le dans un logiciel de contrôle de version en tant que nouveau projet. (Vous pouvez maintenant le supprimer si vous trouvez qu'il gêne un autre projet.) Enregistrez votre projet chaque fois que vous le faites correctement. (Vous pouvez maintenant revenir en arrière si vous vous trompez.)
Suivez les problèmes qui surviennent dans votre projet. Cela peut être fait avec quelques fichiers texte avec le projet. Des fichiers tels que TODO, Changelog, README (peuvent inclure des bogues et des problèmes connus) peuvent être appropriés.
Lorsque vous obtenez votre code de travail, étiquetez-le dans votre contrôle de version. Si cela vaut la peine d'être partagé, faites-le.
Revenez à votre plan et voyez à quel point vous avez réussi. Faites vous-même un document sur les leçons apprises. Qu'avez-vous appris, avez-vous bien évalué? Quels problèmes avez-vous ratés? Quels problèmes avez-vous surestimés? Tout ce que vous jugez important.
Lorsque vous abandonnez un projet, suivez le processus des leçons apprises. Ajoutez une note expliquant pourquoi vous avez abandonné le projet.
Passez en revue vos leçons apprises une fois par mois environ. Au fil du temps, vous pouvez augmenter l'intervalle entre les avis.
la source
Voici un lien vers " Faire de l'Agilité en équipe d'un ". C'est une lecture intéressante!
En outre, vous voudrez peut-être examiner pourquoi les disciplines de développement de logiciels que nous faisons "au travail" sont importantes. Sont-ils importants uniquement s'il y a 10 personnes dans l'équipe? Non, ils sont importants car ils vous aident à réfléchir à votre projet.
Qui est votre public cible? (Si c'est vous, alors génial - mais rappelez-vous pour quoi vous vouliez à l'origine l'application)
Si vous faites une interface utilisateur, pensez aux besoins de votre public, puis faites des maquettes avant de vous lancer dans le développement de l'interface utilisateur.
Si vous examinez votre logique métier, essayez TDD ou BDD. Réfléchissez à la façon dont vous souhaitez que votre application fonctionne avant de l'attaquer. Envisagez de l'envelopper dans un harnais tel que Fitnesse ou similaire. Si vous souhaitez tester votre application, le point de départ le plus simple est au début .
la source
Compte tenu de votre commentaire, arrêtez de supprimer vos projets!
Je ne garde généralement pas les projets que je ne développe pas activement (ou je prévois de développer activement dans un avenir proche) sur mon ordinateur, mais les fichiers source existent dans un référentiel SVN et tout (y compris les fichiers de configuration IDE) est sauvegardé sur un disque dur externe. Cela ne répond pas à votre questiStop de supprimer votre travail et de vous concentrer sur votre motivation.
Si vous recherchez un référentiel hébergé, regardez Google Code, SourceForge, GitHub et BitBucket. Téléchargez vos fichiers, conservez-les quelque part et, lorsque vous avez un intérêt renouvelé, abaissez-les. Bien que vous puissiez les rendre privés, vous pouvez les rendre publics si vous n'avez pas honte d'eux. Peut-être que quelqu'un sera intéressé à redémarrer votre travail ou à apprendre de vos exemples (surtout si vous utilisez une bibliothèque ou un cadre intéressant).
Au fil du temps, travaillez votre motivation. Essayez de vous concentrer sur une chose à la fois. Il se peut que vous n'obteniez pas votre code à la qualité de production, mais peut-être pouvez-vous le donner à titre d'exemple de qualité, ou quelque chose que d'autres personnes peuvent regarder pour voir votre ensemble de compétences, vos connaissances ou pour en apprendre davantage sur une façon particulière de faire les choses.
la source
Tout d'abord, il y a des projets et des projets. Si vous essayez une technologie ou une bibliothèque, ou autre chose, vous créez probablement un projet dans votre IDE, découvrez si cette chose vous intéresse ou non, puis supprimez votre projet. C'est bon, tout le monde fait ça.
Un autre type de projet est de vrais logiciels / sites / etc., qui sont des affaires, où ces «projets», fichiers, programmes ne sont que des outils, et développer des choses aussi complexes nécessite de la motivation et des objectifs :
Ce que vous développez doit être nouveau . Si vous souhaitez créer simplement un autre éditeur de texte parce que vous pensez qu'une fonctionnalité que vous demandez est manquante, vous n'avez probablement pas besoin de le faire. Il existe des centaines d'outils open source, contribuez à l'un d'eux.
Même si vous créez un petit outil à usage unique comme un script, vous devez indiquer les éléments répertoriés, il serait plus facile de résoudre le problème lui-même.
Si vous êtes coincé à écrire du code (par exemple, réécrivez massivement votre code), vous n'avez probablement pas assez d'expérience pour le faire. Prenez un bon livre sur l'ingénierie logicielle, votre plate-forme (mac / web / etc), lisez le code écrit par des développeurs plus expérimentés qui font des choses similaires. Il y a beaucoup d'endroits pour le faire maintenant (github, code google, blogs de programmation, stackoverflow).
N'essayez pas de résoudre un problème très complexe (par exemple, écrire un compilateur ou un système d'exploitation) à partir de zéro, décomposez-le d'abord en tâches plus petites, le plus souvent, quelqu'un a déjà créé des bibliothèques qui vous aident à résoudre votre problème.
la source
Avez-vous envisagé de demander à un être cher ce dont il a vraiment besoin pour un outil Web, puis de le faire pour lui?
Cela devrait fournir la motivation nécessaire pour terminer et livrer, ce qui est le plus difficile. Vous bénéficiez également de l'assistance et de la maintenance de l'application si elle est utile à votre proche. Si ce n'est pas utile, vous pouvez apprendre de l'expérience ce qui peut mal se passer.
la source