Meilleure méthodologie de développement pour une seule personne?
Je passe beaucoup de temps à travailler sur des projets dont je suis le seul développeur, chef de projet, designer, personne QT (Oui, je sais ... Mauvais!), Et parfois je suis même le client.
J'ai essayé à peu près tout pour planifier des projets et me gérer, de la simple séance et du travail libre jusqu'à ce que le projet soit terminé aussi longtemps qu'il le faut, à une version de Scrum pour une seule personne dans laquelle j'ai tenu une réunion d'avancement avec moi-même sur une -man brûle le tableau tous les matins (sans blague).
Pour ceux d'entre vous qui passent beaucoup de temps à travailler seuls, quelle est la meilleure façon de s'organiser, de gérer de grands projets (pour une personne) et de maintenir la productivité aussi élevée que possible?
Il est essentiel de garder une liste claire de vos objectifs. Il est facile pour les fonctionnalités de prendre le contrôle d'un projet autogéré. L'approche TDD "c'est fait quand ça marche" est également utile. Cela vous empêche de devenir perfectionniste.
Une chose qui m'aide vraiment, c'est d'imaginer ce qu'un autre ingénieur ou un chef de projet dirait dans une situation donnée. Souvent, je suis capable de "me faire honte" à cause d'un mauvais code, ou de me remettre sur la bonne voie si le calendrier glisse.
C'est parti ... http://xp.c2.com/ExtremeProgrammingForOne.html
XP évolue bien car il est optimal pour les petites équipes focalisées.
- Vous pouvez créer une feuille de calcul des demandes de fonctionnalités, les hiérarchiser et choisir la plus élevée.
- définir les critères d'acceptation (à quoi ressemble le fait) et le coder en un test exécutable
- Définissez ensuite les tâches d'ingénierie à accomplir
- Écrivez des tests unitaires, faites la chose la plus simple (YAGNI) et refactorisez 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 consulter la technique de Pomodoro .
- Utilisez le contrôle de version et configurez un serveur CI/un fichier batch 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 pourriez pas faire dans une équipe d'un seul est la programmation par paires.
Si vous travaillez en solo. Voici les conseils:
- Faites le moins de travail de bas niveau possible. Utilisez autant de bibliothèque et d'outils que possible, y compris des choses que vous pensez pouvoir facilement coder (ne le faites pas, utilisez simplement la bibliothèque).
- Adoptez l'approche descendante. Ne codez que les choses dont vous avez vraiment besoin.
- 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à été prouvés. Il vous suffit de coder leur algorithme.
- 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 fait 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'équivalent du temps que vous avez perdu en écrivant ce code.
- Disposez de nombreux tests automatisés pour pouvoir effectuer régulièrement des tests de régression chaque fois que vous effectuez un changement
- Séparez les responsabilités de votre conception (c.-à-d. Réduire le couplage). Rendez les choses aussi modulaires que possible
- Utilisez un débogueur pour déboguer et utilisez la recherche binaire pour trouver un défaut.
- Remaniez constamment votre code pour réduire le couplage (explicite) et l'exposition aux méthodes publiques (couplage implicite).
- Rien vraiment. C'est ici juste au cas où je pourrais trouver quelque chose de nouveau: P
Revues 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 qu'il n'ait aucune de vos hypothèses sur la façon dont cela devrait fonctionner.
Ils auront également l'avantage supplémentaire de partager les connaissances au sein de l'entreprise, de sorte que lorsqu'une autre personne devra travailler sur le projet (en raison de personnes occupées ailleurs, malades, démissionnaires ou licenciés), elles n'auront pas à repartir de zéro. .
J'ai lancé ma propre version d'agile qui s'appuie sur des histoires, une forte interaction avec les clients, des versions fréquentes et un développement piloté par les tests. J'utilise un wiki pour suivre les histoires, impliquer le client autant que possible dans leur rédaction et demander au client de travailler avec moi pour hiérarchiser et organiser les versions. J'utilise TDD pour piloter la conception et l'implémentation. J'ai mis en place un serveur QA où le client peut essayer des versions fréquentes (parfois quotidiennement au fur et à mesure que de nouvelles fonctionnalités sont développées) afin que je reçoive rapidement des commentaires. Je passe rarement plus de 3 itérations sans une sortie en QA. Le client décide quand la version QA a suffisamment de fonctionnalités pour être mise en ligne - et si aucune autre fonctionnalité de la liste n'a besoin d'être développée.
Dans mon entreprise, notre groupe travaille tous sur le même projet, mais sur des tranches relativement indépendantes de celui-ci. Une chose que nous faisons beaucoup ici, c'est quand quelque chose que vous faites semble un peu difficile, ou lorsque vous êtes à la croisée des chemins avec plus d'une façon 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 de considérer que votre code est terminé pour effectuer une révision, vous avez généralement déjà investi trop de temps pour envisager des modifications architecturales majeures, bien que de nombreux défauts soient découverts dans les révisions de code.
De plus, je me rends compte que le développement piloté par les tests est un petit mot à la mode saturé récemment, mais il peut être d'une grande aide pour les développeurs solo car il fournit un contrôle de 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 propose ce qui suit:
- Développement piloté par les tests
- Utilisation courante de "TODO: notez ici" dans votre code lorsque vous voyez quelque chose que vous n'êtes pas en mesure de faire immédiatement, et revenez-y lorsque vous avez le temps de rester sur Facebook en attendant que votre client rappelle
- Écrivez votre code car votre client l'achètera en regardant le code non seulement le résultat, imaginez votre client en tant que président pour une révision du code.
- 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 à adopter dans votre situation:
Voici un lien avec plus d'informations: http://en.wikipedia.org/wiki/Behavior_driven_development
philosophie: XP/TDD + GTD
plan général:
- interviewer les parties prenantes
- maquettes d'écran, soluces, prototypes papier (si nécessaire)
- remue-méninges sur les reportages (avec et sans 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 des processus, formation, planification de la maintenance, etc. (au besoin)
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 sur mes projets en essayant de suivre des principes agiles. Il faut énormément de discipline, car il n'y a pas d'équipe pour s'assurer que vous ne commencez pas simplement à prendre des raccourcis.
Je trouve que l'utilisation d'outils de formatage de code tels que ReSharper garantit qu'au moins visuellement, le code est facile à récupérer pour les autres développeurs.
En termes de méthodologies réelles, il est difficile pour un développeur unique de s'en tenir à un en particulier. Je suis un consultant qui travaille généralement seul et je trouve qu'il est plus facile pour moi et pour le client d'utiliser un processus agile. J'essaie généralement d'amener mes clients à saisir directement leurs besoins dans un outil tel que Trac (ou je le ferai en leur nom). Cela aide non seulement les autres développeurs à identifier le but du code, mais aussi vous-même 3 mois plus tard!
Toute méthodologie appropriée sera utile - 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 méthodologies ne pas jeter car il n'y a qu'une seule personne travaillant sur le projet.
Et le plus important pour moi est le contrôle de code source (oui, c'est un outil, mais cela fait partie de votre flux de travail, donc aussi un processus). Les gens pourraient être tentés de donner cette passe car ils "n'ont pas besoin de prendre en charge plusieurs personnes pour éditer le code en même temps".
Ironiquement, je trouve qu'une solution de contrôle de version distribuée comme GIT est meilleure pour un individu que quelque chose comme SVN.
Si c'est du code à jeter, il pourrait être un peu lâche avec des méthodologies, mais quelque chose d'important et je dirais que votre façon de le traiter comme un projet d'équipe avec une seule personne est très agréable et disciplinée.
Écrivez votre code pour le prochain gars à lire, pas vous ... soyez gentil avec lui. Même le code "jetable" reste pour toujours.
Je pense que les revues de code sont un bon début, mais j'aime quand cela devient informel et amusant, comme faire une revue de code de paire ou une programmation de paire afin de résoudre un certain problème/problème ou une amélioration (par exemple, changer le code hérité pour répondre aux nouvelles normes de codage ). Parfois, deux paires d'yeux valent mieux qu'une et c'est aussi amusant, je pense que le partage et la discussion semblent plus ouverts. Vous pouvez également avoir un déjeuner formel/informel et discuter de séances pour parler de ce que vous avez fait individuellement ou en groupe, par exemple mentionner un nouveau modèle que vous avez utilisé ou de nouvelles technologies comment un problème a été résolu?
Agile
les fonctionnalités, les histoires et les cas de test sont beaucoup plus instructifs qu'une 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 que n'importe quelle quantité d'arbres morts
Il est également plus facile de transférer le travail entre les itérations.
En tant que consultant moi-même, je suggère que vous trouviez un moyen pour qu'il y ait toujours au moins deux développeurs sur n'importe quelle mission.
Je suis d'accord pour devenir agile et laisser une trace agile d'histoires et de tests que d'autres peuvent suivre, mais je ne pense pas que ni aucun autre processus ou méthodologie ne stick pendant que les gens travaillent en solo.