Pour le processus de développement que j'ai impliqué jusqu'à présent, la plupart ont des équipes de membre SINGLE, ou parfois deux.processus de développement logiciel super léger
Nous avons utilisé python + django pour le développement majeur, le processus de développement est en fait très rapide, et nous avons des revues de code, des discussions de modèles de conception et des refactoring constants.
Bien que la taille de l'équipe soit petite, je pense qu'il y a quelques processus de développement/meilleures pratiques qui pourraient être appliquées. Par exemple, utiliser svn serait certainement mieux que la sauvegarde de copie régulière.
J'ai lu quelques articles & livres sur Agile, XP & intégration continue, je pense qu'ils sont gentils, mais encore trop lourds pour ce cas (équipe de 1 ou 2, et codage rapide). Par exemple, à mon humble avis, avec un beau design, et un développement itératif + refactoring, le TDD PEUT être une exagération, ou au moins le surcoût ne surpasse pas les avantages. Et ainsi est la programmation de la paire. Le test automatisé est une bonne idée, mais il ne semble pas techniquement réalisable pour chaque projet.
nos pratiques actuelles sont:
svn + étape + révision du Code
Je me demande s'il y a des processus de développement/meilleures pratiques ciblées spécifiquement sur ces équipes de super-lumière?
L'utilisation d'une certaine forme de contrôle de révision de code source est obligatoire (même pour une personne travaillant seule) –
Le seul cas où je peux voir que TDD est trop rapide est dans des projets rapides que vous devez réaliser en une heure ou de simples prototypes. Les projets à développeur unique peuvent bénéficier de TDD tout autant que les projets d'équipe plus importants. TDD est sur la conception de logiciels, et n'a vraiment rien à voir avec la taille de l'équipe. –
salut jeff, merci pour votre commentaire. Je dois admettre que je n'ai jamais réellement implémenté TDD. Et les raisons pour lesquelles je ne les utilise pas sont les suivantes: 1. les exigences des utilisateurs changent continuellement, ce qui a brisé les tests de régression de l'ensemble de test précédent. 2. étant donné que l'on utilise un motif de conception agréable lors du refactoring, les bogues qui pourraient être réellement attrapés lors de la dernière version sont en réalité très limités. TDD semble être une sorte de gaspillage. Donc je pense que TDD n'est utilisé que si le projet est assez grand et supposé être transféré entre différents développeurs. –