Je passe beaucoup de temps à travailler sur des projets dans lesquels je suis le seul développeur, chef de projet, concepteur, personne QT (oui, je sais… mauvais!) Et parfois même, je suis le client.

J'ai tout essayé pour planifier des projets et me gérer moi-même, du simple fait de travailler en freestyle jusqu'à la fin du projet, peu importe le temps qu'il prend, à une version individuelle de la mêlée dans laquelle je tenais une réunion d'avancement avec moi-même. -man brûle la carte tous les matins (ne plaisante pas).

Pour ceux d'entre vous qui passent beaucoup de temps à travailler seuls, quel est le meilleur moyen de s'organiser, de gérer des projets de grande envergure (pour une personne) et de maintenir une productivité aussi élevée que possible?

Garder une liste claire de vos objectifs est vital. Il est facile pour le glissement de fonctionnalités de prendre en charge un projet autogéré. L’approche "c’est quand ça marche" est également utile. Cela vous empêche de devenir un perfectionniste.

Une chose qui m’aide vraiment, c’est d’imaginer ce que dirait un autre ingénieur ou un chef de projet dans une situation donnée. Souvent, je suis capable de me «faire honte» à partir de mauvais code, ou de me remettre sur la bonne voie si le calendrier est défaillant.

Ici vous allez ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP décroît bien car il est optimal pour les petites équipes concentrées.

• Vous pouvez créer une feuille de calcul des demandes de fonctionnalités, les hiérarchiser et choisir celle qui se trouve en haut.
• définir les critères d'acceptation (à quoi ressemble fait) et les coder dans un test exécutable
• Ensuite, définir les tâches d'ingénierie à accomplir
• Écrire des tests unitaires, faire la chose la plus simple (YAGNI) et refactoriser tout le temps. L'objectif est de faire passer le test d'acceptation externe
• Timebox à chaque session. Pour une gestion efficace du temps, vous pouvez également regarder la technique de Pomodoro .
• Utiliser le contrôle de version et configurer un serveur CI / un fichier de commandes pour créer une installation ou un zip de votre logiciel
• Démo fréquemment. Acheminez les commentaires dans la feuille de calcul d'origine et redéfinissez les priorités

La seule chose que vous ne puissiez pas faire avec une équipe de deux est la programmation en binôme.

Si vous travaillez en solo. Voici les conseils:

1. Faites le moins de travail possible. Utilisez autant de bibliothèque et d'outils que possible, y compris des éléments que vous pensez pouvoir coder facilement (ne le faites pas, utilisez simplement la bibliothèque).
2. Prenez l'approche de haut en bas. Ne codez que les choses dont vous avez vraiment besoin.
3. Lorsque vous voyez un problème en termes abstraits, recherchez sur Google et utilisez des documents de recherche de la communauté universitaire qui ont déjà fait leurs preuves. Vous devez seulement coder leur algorithme.
4. Concevez votre système de manière à pouvoir changer librement les choses autant que possible. (y compris copier et coller du code d’ici à là). Le but est de vous faire gagner du temps lorsque vous réalisez que vous avez commis une erreur. Essayez de minimiser la quantité de travail que vous devez jeter lorsque vous faites une erreur. Un morceau de code qui doit être jeté (au lieu de copier-coller d’ici et là) est l’équivalence du temps que vous avez perdu à écrire ce code.
5. Ayez beaucoup de tests automatisés pour pouvoir faire régulièrement des tests de régression à chaque changement.
6. Séparez les responsabilités de votre conception (c.-à-d. Réduire le couplage). Rendre les choses aussi modulaires que possible
7. Utilisez un débogueur pour déboguer et utilisez la recherche binaire pour rechercher le défaut.
8. Refactorisez constamment votre code pour réduire le couplage (explicite) et l'exposition aux méthodes publiques (couplage implicite).
9. Rien vraiment. Ceci est juste au cas où je pourrais trouver quelque chose de nouveau: P

Révisions de code.

Celles-ci sont particulièrement utiles car vous expliquerez le code à quelqu'un qui n'a pas travaillé sur le même projet afin d'éviter toute hypothèse sur son fonctionnement.

Ils auront également l’avantage supplémentaire de partager leurs connaissances au sujet de l’entreprise. Ainsi, si une autre personne doit travailler sur le projet (en raison de personnes occupées ailleurs, de malades, de démissionnaires ou de licenciements), ils n’ont pas à repartir à zéro. .

J'ai créé ma propre version de l'agilité qui repose sur des histoires, une interaction client intense, des versions fréquentes et un développement piloté par les tests. J'utilise un wiki pour suivre des récits, impliquer le client autant que possible dans leur rédaction et le faire travailler avec moi pour hiérarchiser et organiser les versions. J'utilise TDD pour piloter la conception et la mise en œuvre. J'ai mis en place un serveur d'assurance qualité sur lequel le client peut essayer des versions fréquentes (parfois quotidiennement, à mesure que de nouvelles fonctionnalités sont développées), afin d'obtenir rapidement un retour d'information. Je vais rarement plus de 3 itérations sans une version à QA. Le client doit décider quand la version du contrôle qualité a suffisamment de fonctionnalités pour être mise en production - et si aucune autre fonctionnalité de la liste ne doit être développée.

Dans mon entreprise, notre groupe travaille tous sur le même projet, mais sur des tranches relativement indépendantes. Une chose que nous faisons beaucoup ici, c'est quand quelque chose que vous faites semble un peu délicat, ou que vous êtes à la croisée des chemins avec plus d'un moyen de mettre en œuvre quelque chose, vous prenez quelqu'un d'autre et discutez des avantages et des inconvénients avant vous continuez. Si vous attendez que votre code soit terminé pour procéder à une révision, vous avez généralement déjà pris trop de temps pour envisager des modifications architecturales majeures, même si de nombreux défauts sont certainement découverts dans les révisions de code.

De plus, je me rends compte que Test Driven Development est un petit mot à la mode saturé ces derniers temps, mais il peut être d’une grande aide pour les développeurs solo, car il fournit un contrôle de la qualité au fur et à mesure, et lorsque les tests deviennent difficiles à écrire, vous savez que vous avez probablement besoin d’une restructuration de votre. code. Cela aide également les mainteneurs ultérieurs à ne pas casser accidentellement le code de manière difficile à détecter.

Je vous suggère ce qui suit:

1. Développement piloté par les tests
2. Évitez d’utiliser «TODO: notez ici» dans votre code lorsque vous voyez quelque chose que vous ne pouvez pas faire immédiatement, et revenez-y lorsque vous avez le temps de rester sur Facebook et d’attendre que votre client rappelle.
3. Écrivez votre code car votre client l'achètera en regardant le code et pas seulement le résultat. Imaginez votre client en tant que président pour une révision du code.
4. Remplissez votre code d'assertions

J'aimerais pouvoir dire que j'ai pu pratiquer ce que je prêche 100% du temps, mais BDD semble être une bonne approche à prendre dans votre situation:

Voici un lien avec plus d'informations: http://en.wikipedia.org/wiki/Behavior_driven_development

Je suis dans un bateau très similaire. J'essaie de suivre les principes agiles (aussi bien que je les comprends) autant que possible. Je ne fais probablement pas les choses «correctement», mais j'ai eu beaucoup de succès dans mes projets en essayant de suivre les principes agiles. Il faut énormément de discipline, car il n'y a pas d'équipe pour s'assurer que vous ne commencez pas à prendre des raccourcis.

Je trouve qu'en utilisant des outils de formatage de code tels que ReSharper, il est facile de récupérer le code, du moins visuellement, pour les autres développeurs.

En termes de méthodologies réelles, il est difficile pour un développeur unique de s'en tenir à l'une ou l'autre. Je suis un consultant qui travaille généralement seul, et je trouve qu'il est plus facile pour moi-même et pour le client d'utiliser un processus agile. J'essaie généralement de faire en sorte que mes clients entrent directement leurs exigences dans un outil tel que Trac (ou je le ferai en leur nom). Cela aide non seulement les autres développeurs à identifier l'objectif du code, mais également à vous-même trois mois plus tard!

philosophie: XP / TDD + GTD

Plan général:

• interviewer les parties prenantes
• maquettes d'écran, procédures pas à pas, prototypes en papier (si nécessaire)
• remue-méninges sur les caractéristiques et les histoires (avec et sans les intervenants)
• brainstorming de cas de test (avec et sans parties prenantes)
• temps de réflexion global sur la conception / l'architecture (si nécessaire)
• Planification des itérations (avec les parties prenantes)
• itérations
• examen du processus, formation, planification de la maintenance, etc. (si nécessaire)

Toute méthodologie appropriée aidera, quel que soit le nombre de personnes participant au projet. Alors choisissez-en un à la fois et voyez comment vous pouvez appliquer et mapper votre domaine et mesurer leurs succès.

Peut-être plus intéressant est de demander quelles sont les méthodologies à ne pas jeter car il n'y a qu'une seule personne qui travaille sur le projet.

Et le principal qui me frappe est le contrôle de la source (oui, c’est un outil, mais il fait partie de votre flux de travail, donc aussi d’un processus). Les gens pourraient être tentés de laisser passer ça parce qu'ils "n'ont pas besoin de supporter plusieurs personnes pour éditer le code en même temps".

Ironiquement, je trouve qu'une solution de contrôle de version distribuée telle que GIT est préférable pour un utilisateur plutôt que SVN.

Si ce code est jetable, il pourrait être un peu délicat avec des méthodologies, mais rien d’important et je dirais que votre façon de le traiter comme un projet d’équipe avec une personne est très gentil et discipliné.

Ecrivez votre code pour le prochain gars à lire, pas vous ... soyez gentil avec lui / elle. Même le code "jeter" reste pour toujours.

Agile

les fonctionnalités, les récits et les scénarios de test sont beaucoup plus instructifs que la documentation plus formelle, et un ensemble de tests de travail est plus efficace pour démontrer comment utiliser quelque chose ou comment quelque chose fonctionne, quelle que soit la quantité d'arbres morts

Il est également plus facile de transférer du travail entre deux itérations.

En tant que consultant moi-même, je vous suggérerais de trouver le moyen d’avoir toujours au moins deux développeurs pour toute tâche.

Je suis d’accord pour devenir agile et pour laisser une trace agile d’histoires et de tests que d’autres peuvent suivre, mais je ne crois pas qu’un processus ou une méthodologie quelconque puisse rester bloqué tant que les gens travaillent en solo.

Je pense que les revues de code sont un bon début, mais j'aime bien quand c'est informel et amusant, comme faire une révision de code ou une programmation en binôme afin de s'attaquer à un problème ou à une amélioration (par exemple, changer le code hérité pour répondre aux nouvelles normes de codage ). Parfois, deux jeux d'yeux valent mieux qu'un et c'est aussi amusant. Je pense que le partage et la discussion semblent plus ouverts. Vous pourriez également avoir un déjeuner formel / informel et discuter de sessions pour parler de ce que vous avez fait individuellement ou en groupe, par exemple, mentionner un nouveau modèle que vous avez utilisé ou les nouvelles technologies: comment un problème a-t-il été résolu?