L’allure rapide que le processus de développement logiciel peut avoir dans le monde agile peut conduire à des décisions de design pour le moins discutables. Se concentrer sur quelques user stories particulières le temps d’un sprint, peut conduire à négliger des points plus fondamentaux de design général, points qui pourraient venir hanter plus tard l’ensemble du projet
Les architectes et les développeurs logiciel ont besoin de travailler sur des aspects de design qui ne font pas faire nécessairement l’objet d’une user story spécifique ou d’un sprint individuel.Depuis l’adoption des méthodes agiles pour le développement logiciel, les architectes et les développeurs se battent pour faire rentrer les bonnes pratiques du design dans le cadre stricte et souvent inapproprié de ces méthodes. Scrum par exemple, pour ne citer qu’une seule de ces méthodes, avec sa véritable obsession de livrer une nouvelle release à la fin de chaque sprint, montre une tendance d’obliger les concepteurs à se focaliser sur des points de détails plutôt fonctionnels, démarche qui pourraient sembler en contradiction avec la vision cohérente de l’ensemble de l’architecture logiciel.
Les architectes et les développeurs logiciel sont souvent confrontés à des situations où il faut faire machine arrière et travailler sur des concepts holistiques, tout en supportant les squads qui sont activement en train d’avancer sur des fonctionnalités qui, d’un point de vue de design, ne peuvent pas être isolées de l’ensemble et adressées individuellement. Pour des nombreux architectes et développeurs, le processus de développement logiciel ressemble à l’effort de conception d’un moteur, alors que la transmission, les roues, le volant, etc. sont conçus parallèlement et évoluent simultanément.
Pour pallier à ces problèmes, les apologètes des méthodes agiles sont venu avec l’idée de sprint zéro, un sprint préliminaire dédié exclusivement à la conception de l’architecture, au développement du socle technique et de la fondation des classes, au choix et à la qualification des frameworks et des outils, etc. Mais le sprint zéro s’avère très insuffisant pour des projets complexes et, par conséquent, il n’est pas très utile. En plus, le concept de sprint zéro montre que les apologètes des méthodes agiles qui l’ont inventé ne connaissent rien au métier d’architectes et développeur logiciel car ils assument que le besoin de design est un besoin de type one-time, au début du projet. Ce qui est complétement en décalage avec la pratique professionnelle qui montre clairement que, loin d’être une activité discrète, le design logiciel est un processus pour le moins tout aussi continu que celui de développement du produit.
On doit donc accepter l’idée que les activités de design et de redesign, de refactoring, etc. peuvent faire l’objet de chaque sprint, à tout moment, et pas seulement du sprint zéro. Mais alors que doit faire le squad pendant que l’architecte de l’équipe est en train d’effectuer du refactoring et du redesign ? Car on ne peut pas continuer la construction de la cathédrale pendant qu’on s’attaque à ses fondation, n’est pas ?
Eh bien, la solution qui est proposé c’est d’arrêter l’évolution des sprints réguliers et de rentrer là dans une sous-itération, ayant ses propres sprints, son propre back-log et cycle de vie. Et une fois cette sous-itération terminée, on peut continuer le flux principal qu’on vient de mettre au congélateur.
Et comme cette manière de procéder ne me paraît pas raisonnable, j’en conclus personnellement que l’activité de développement logiciel n’est pas compatible avec les méthodes agiles et qu’on doit laisser faire le bon vieux waterfall. Ceci pour la bonne raison que le développement logiciel est une activité de création et la création ne peut pas être agile car elle est inquantifiable . En effet, à l’instar d’un architecte dans le domaine civile, ou d’un artiste d’un tout autre domaine, l’architecte logiciel effectue un travail créatif qui ne peut pas rentrer dans des sprints.
Ce qui ne signifie pas que certaines activités qui peuvent s’apparenter à du développement logiciel ne se prêteraient pas à de l’agile. Si on considère par exemple le devops et notamment l’IAC (Infrastructure as Code) où tout est scripting, on voit bien que ce domaine s’adapte très bien aux méthodes agiles. Car pour qu’un processus soit scriptable, il est nécessairement répétable et connu d’avance, complétement reproductible à tout moment par une séquence d’actions, toujours les mêmes, pouvant même être effectuées manuellement. Et pour éviter de les répéter manuellement, on fait des scripts.
Pour ne plus parler du bug fixin,g où il s’agit de corriger les anomalies constatées par les testeurs, ou de l’ops, le domaine qui consiste à provisionner de l’infrastructure, à installer des machines physiques ou virtuelles, à tirer de câbles, à configurer des volumes et des réseaux, à créer des utilisateurs, etc.
Ce qui me conduit à la conclusion finale conformément à laquelle, dans l’industrie du logiciel il y a des domaines et des sous-domaines divers et variés, qu’il ne faut pas tout mélanger et que les mêmes méthodes ne peuvent pas ‘appliquer à tous ces domaines et sous-domaines, comme on essaye souvent de le faire lorsqu’on manque d’expérience, de recul et de perspective.