Je suis un grand défenseur des méthodes agiles lorsque vous travaillez sur des équipes et / ou de grands projets.
Cependant, je trouve que, pour des projets plus petits, lorsque vous travaillez en solo, je démarre habituellement les tests d'unité d'écriture de projet, documentant de manière approfondie, refactoring. Au fil du temps, je m'arrête parce que j'ai envie de perdre du temps. Je trouve que le cow-boy codant avec un spin agile (tester souvent, écrire un code lisible humain) fonctionne souvent extrêmement bien pour moi sur de petits projets solo que je ne m'attends pas à ce que les autres devraient travailler avec.
Les autres personnes partagent-elles mon sentiment? Ou pensez-vous que l'on ne devrait jamais s'en tenir à leurs armes à feu (obtenir? Cowboys)?
La vraie question: y a-t-il des méthodologies agiles particulièrement adaptées à un projet solo? (autre que ma méthode "Agile Cowboy" ci-dessus)
5 Réponses :
Le processus de codage et agile de cow-boy n'est pas le même.
Comme pour les petits projets personnels, bien sûr, il y a beaucoup de choses qui seraient surchargées. Développement agile, itérations courtes, examen de code fréquent et code auto-documentant est la voie à suivre.
Je vais admettre que je suis coupable de longues itérations lorsque je passe dans ce mode. Je m'attrape habituellement avant qu'il ne soit trop tard.
Je pense que votre "test souvent, écrire un code lisible par l'homme" La proposition est une approche parfaitement appropriée pour faire de bons logiciels sur une équipe solo pour de petits projets.
Bien que cela doive être un peu flexible, laissant des morceaux d'agile est totalement fou. Si vous ne refactez pas le refacteur, vous lancez simplement toutes les conceptions de la fenêtre. Si vous ne testez pas, vous ne pouvez pas refroidir correctement. Agile est comme une roue où une pratique permet souvent de briser la chaîne la chaîne et tout tombe - alors agile est blâmé.
Je ne suis pas d'accord avec votre affirmation selon laquelle "laisser des morceaux d'agile est totalement fou". En fait, je pense en fait que ce genre de vision est préjudiciable à une certaine mesure. Chaque organisation et projet aura des besoins spécifiques et il est important d'évaluer ce que les outils et les techniques vous aident à y arriver. Heureusement, le refactoring est l'un des plus faciles à choisir (ce qui peut être pourquoi vous pensez que c'est stupide de le mettre de côté), de sorte que la plupart des projets agiles prennent effectivement du temps pour une sorte d'efforts de refactorisation périodique.
Vous voudrez peut-être consulter le Solo Programmation des travaux de contournement XP . Programmeur en carton est un pour une raison quelconque que j'ai trouvé particulièrement amusant. Vous pourriez peut-être coder avec un skeet Jon en carton à côté de vous?
Je sens des opportunités d'affaires merveilleuses ici. Qui sera le premier à obtenir une offre exclusive avec Jon? ;)
NE PAS FROGET The Caoutch Caoutle Ducking: C2.com/cgi/wiki?Rubberducking
J'avais l'habitude de parler au chien, en fait, je trouve donc une validité dans cela.
@Pavel: J'ai déjà cloné Jon Skeet. En 18 ans, Skeetsoft sera une force imparable.
Je travaille actuellement en solo sur un projet ASP.NET (pas un petit cependant). J'utilise beaucoup TDD, et je trouve que cela ne prend pas le temps de développer à l'aide de TDD, je gagne en fait du temps.
Ceci est principalement parce que la suite de tests d'unité le rend très rapide pour tester et déboguer le système. Par exemple. Lorsqu'une fonctionnalité ne fonctionne pas comme prévu, il est beaucoup plus rapide de joindre le débogueur au processus de Nunit, qu'il ne consiste pas à démarrer le serveur Web dans le mode de débogage, de naviguer sur la bonne page (passant d'abord l'écran de connexion), etc. Donc, en n'ayant pas les tests de l'unité, je passerais beaucoup à tester et à déboguer plus longtemps.
et les tests de l'unité m'aident également à créer un système bien conçu, car cela me force à créer un design plus lâchement couplé.
Je dirais que le nombre de personnes travaillant sur le projet n'est pas le seul facteur à considérer. Je pense que la raison pour laquelle vous trouvez l'agile complète (documentation, refactoring, tests unitaires .......... celles-ci ne sont probablement pas vraiment agiles ils ont été autour depuis longtemps TEMPS) Pour que le gaspillage du temps, c'est parce que les projets solo ont tendance à être de petits projets.
Pour des projets plus importants qui couvrent plus d'une demi-année, je m'attendrais vraiment à ce que le processus approprié vous aidait vraiment à vous-même. Vous pouvez visiter un code que vous écrivez 5 mois plus tôt. Sans documentation, c'est la même chose que le travail des autres. Sans tests, vous avez aussi peur de le changer en tant que changement de code des autres.