Tu as raison: c'est plus eXtrem :
- il n'y a pas de "pair programmaing". Parce que je suis tout seul ou même à 2 -3 c'est chacun son projet, même si on peut donner une idée/ un conseil.
- il n'y a pas beaucoup de tests (développement IHM en C et C++)
Et tu ne parles pas non plus des réunions d'avancement, des "milestones", ...
Mais après coup, je me dis que ma lenteur est surtout liée à l'environnement :
- Pas de cahier de charges. 1) tu ne sais jamais exactement les fonctionnalités à coder, surtout les secondaires qui peuvent être importantes 2) évolutions des fonctionnalités (c.-à-d. suppression ou ajout)
- Tout seul ou à 2-3 pour tout coder, même pour faire de la R&D.
- Bonus : des vieux outils qui t'obligent à coder beaucoup en "bas niveau"
Mais je me demande si ma lenteur n'est pas liée aussi à cette méthode incrémentale Parce que si toutes les fonctionnalités été codées en 1 grosse fois avec les dépendances les plus nécessaires, cela m'éviterait de "refactoriser"/ concevoir aussi souvent (<- en fait pas vraiment, on peut ensuite "refactoriser" mais cela sera en ultra prioritaire avec un blocage du projet plus ou moins long/ ou un "fork". Mais cela arrive sur tout projet déjà conséquent)
Après la qualité du code? Difficile de la dire, c'est du cas par cas . C'est sûr, il ne sera aussi "premium", mais pas forcément mauvais, peut-être même très bon, même si certaines fonctionnalités sont insérées au pied-de-biche.
Et pour faire un parallèle avec les SC2I (ESN), je pense que le problème c'est le "turn-over" qui est important. Je pense que si les "cadres" du projet durent, même si on code les projets en mode bourrin, il y aura toujours cette vision d'ensemble.
Et enfin Matthieu Vergne (et moi aussi), on dit que plus une fonctionnalité est importante plus cela fera du code à jeter/ recoder.
Mais plus le code est gros, plus il y aura de choses à repiquer ... même si des fois, après coup, cela peut être une mauvaise idée parce qu'il ne correspond pas autant au besoin qu'on avait prévu.
Partager