Méthodologies du cycle de vie des logiciels pour les équipes individuelles [fermé]

Je suis en train de construire un système logiciel pour mon projet de master et je cherchais des conseils sur des méthodologies particulières qui conviendraient à une "équipe d'un seul homme" ...

Je gagne ma vie en tant que "pistolet logiciel à louer" pour un seul homme qui travaille principalement à domicile, donc je meurs d'envie d'entendre ce que les autres ont à dire à ce sujet.

Voici quelques éléments que j'ai trouvés importants:

• Comme le dit Denis, le contrôle des sources est vital - mais SVN n'est pas la seule option. J'utilise principalement Perforce, et git est une bonne alternative. J'aime un modèle de développement "principal"; cela me permet de faire des expériences dans les branches de code, de les fusionner dans la ligne principale quand elles fonctionnent et de les jeter si elles ne le font pas.
• J'utilise un carnet de notes et un programme de suivi des tâches. Actuellement, j'utilise Redmine pour ce dernier; avant cela, j'ai utilisé Fogbugz. J'aime aussi Redmine car il a un très bon wiki intégré, que je peux utiliser pour des notes persistantes et des liens vers des sites importants.
• Il est également essentiel de suivre ce que je fais et de me fixer des limites raisonnables afin que j'en fasse assez sans m'épuiser - voir ci-dessous.

Mes autres techniques ont évolué au fil des années, et je les ajuste en fonction du projet et du client. Les gens me paient pour le code de travail, pas pour duper avec le processus, alors j'essaie de garder le processus léger et hors du visage de mes clients. Mais je trouve que certaines techniques Agiles fonctionnent très bien pour moi:

• Un de mes clients actuels a tendance à me laisser de grandes fonctionnalités à implémenter et ne me bogue pas tant qu'ils ne sont pas terminés. Je trouve donc que travailler sur ceux dans les sprints Scrum est super. Je suppose que cela peut fonctionner pour un projet de maîtrise, sauf si votre conseiller de recherche est un monstre de contrôle.
• Mon autre client actuel a tendance à avoir plus d'urgences du type "arrête de travailler sur ceci et corrige ce". J'ai essayé de faire ça avec Scrum et j'ai abandonné après un sprint. Je fais donc cela en utilisant Kanban, et cela fonctionne beaucoup mieux.

L'autre problème de travailler par vous-même est que vous n'avez personne pour vous dire quoi faire ou quand, ou si vous en faites assez, ou quand arrêter de travailler parce que vous en avez fait assez - vous devez donc faire cela pour vous. Personnellement, je préfère Scrum parce que je peux garder une trace de mes progrès par rapport à mes objectifs de sprint. Pour les projets Kanban, je peux simplement suivre le temps que je consacre, mais je n'aime pas cela ainsi que quelque chose de plus axé sur les objectifs.

Certains de mes amis ne jurent que par Pomodoro pour les garder concentrés sur les tâches et suivre l'efficacité personnelle, et je pense à l'essayer.

J'ai également un processus formel de diffusion de code à mes clients pour m'assurer que ce qu'ils obtiennent est "correct", mais cela dépasse probablement la portée de ce que vous demandez.

Utilisez SVN ci-dessus, version tout. Pour le suivi, le bloc-notes fera pour les projets plus simples, si nécessaire, vous avez de nombreuses applications gratuites de suivi des tâches / bogues (Redmine est cool). Agile / XP / Intégration Continue / autres serait à mon avis un peu exagéré.

Mis à part le processus logiciel personnel , je n'ai pas trouvé grand-chose sur les modèles de processus formels conçus pour être utilisés par un seul développeur. La PSP est assez lourde sur la documentation et la paperasse (dans sa forme brute, de toute façon), sans beaucoup à dire pour des techniques particulières sur l'exécution du travail (à la place, la PSP se concentre sur la collecte de données pour trouver des domaines à améliorer), mais c'est un début point pour développer un processus personnel que vous pouvez utiliser sur des projets de petite à moyenne taille.

Je pense que le meilleur plan d'action serait de simplement suivre certaines des meilleures pratiques largement acceptées (en fonction de vos besoins et du projet) et largement acceptées à partir d'un certain nombre de modèles de processus. Jetez un coup d'œil aux méthodes de suivi du travail effectué / du travail restant, de la gestion des exigences, du contrôle de version, des tests (en particulier des tests unitaires et d'acceptation), de l'intégration continue, des normes de codage, vous n'en aurez pas besoin, etc. Si ce n'est pas le cas, je vous suggère de lire Code Complete et The Pragmatic Programmer et de pratiquer leurs conseils.

La plus grande chose à propos du travail individuel est que, à part les restrictions imposées à vous par des forces extérieures, tout dépend de vous. Vous n'avez pas besoin d'accueillir quelqu'un d'autre travaillant à vos côtés, il est donc plus facile de choisir des techniques qui vous permettent de travailler de la manière la plus efficace possible. Au fil des ans, vous avez probablement compris comment vous travaillez le mieux, ce serait donc un bon point de départ. Ensuite, appliquez les "meilleures pratiques" connues pour améliorer vos capacités et vos techniques.

Le gars pose des questions sur des méthodologies spécifiques et les gens répondent "utiliser un logiciel X / Y". Ce n'est PAS une question d'outils, en fait il existe de nombreuses méthodologies et il semble qu'il n'y ait pas encore de rapport de validation pour elles: Agile, Itératif, Spirale, Waterfall, XP, V-Model, TDD.