Différents paradigmes (contradictoires) peuvent être présent pour un même contexte :

• Méthodes agiles. Customiser le mode de fonctionnement pour chaque projet. Notion de cône d’incertitude pour expliquer que les estimations initiales sont très aléatoires. L’idée d’abaque de chiffrage est impensable
• CMMI. Formaliser les pratiques, donc les uniformiser pour tous les projets, jusqu’à faire des statistiques (des charges, mais aussi des taux de defauts, …)
• Software craftsmanship. Emphase mise sur les pratiques d’artisanat (parfois par opposition à l’ingéniérie).

On les oppose, mais dans un contexte réel, il faut plutôt chercher à la articuler, à les faire coexister.

En effet, les méthodes agiles me semblent parfois être le rêve fou de développeurs qui ont pris le pouvoir. Software craftsmanship de vieux développeurs expérimentés, pour les « techniques » par opposition aux gestionnaires, pour la créativité individuelle par rapport à l’uniformité et à la norme. CMMI de chefs de projet (et encore il y a PMBOK), PMO et ingénieurs qualité. Tous ces profils ont leur place dans un ecosysteme.

Chaque contexte se fait sa sauce. A quand un paradigme chapeau ? Voire un guide avec pour chaque aspect des alternatives avec chacune ses conditions d’application ? Et une cross-fertilization (enrichissement mutuel d’approches différentes) ?