L'agile pour l'architecture et la construction

Aujourd'hui, les constructeurs doivent produire plus en un temps toujours plus restreint. Ils doivent également travailler pour des utilisateurs plus regardants sur la qualité. Les produits doivent correspondre à leurs attentes pour avoir une valeur réelle. Adopter les méthodes agiles aux projets physiques (hardware) permet d’en améliorer la qualité, mais aussi de gagner du temps. L'industrie du logiciel a déjà réalisé sa transition méthodologique et nous devons nous en inspirer pour révolutionner notre approche de la conception d'objets physiques.

Les méthodes agiles, du software au hardware

Les méthodes agiles sont utilisées dans l’industrie du logicielpar les développeurs depuis la fin des années 1990. Aujourd'hui, ce sont les méthodes de management de projets les plus populaires pour le développement de logiciel. Les méthodes agiles diffèrent de la méthode utilisée par le passé et dite "en cascade" ; où le projet était réalisé par étapes successives jusqu'à son état final.

Avec l'Agilité, le but est d'arriver le plus vite possible à une version simple mais fonctionnelle du produit, qui peut être testée par les utilisateurs. Ce développement itération après itération est important pour obtenir le plus tôt possible des retours de la part des utilisateurs et pouvoir continuellement améliorer le projet.

Cela permet également de détecter les problèmes et régler rapidement les blocages. La popularité des méthodes agiles dans la production d'objets physiques est au même point où en était l'industrie software au début des années 1990. Certains précurseurs utilisent déjà ces méthodes, tandis qu’elle sont toujours méconnues pour d’autres.

Les auteurs du manifeste agile à sa création.

Le manifeste agile de 2001

Le manifeste agile de 2001 a été écrit par plusieurs personnalités de l'industrie software après deux jours de réunion. Ce manifeste pour le software est basé sur 4 valeurs principales et 12 articles. La manifeste nous montre l'intérêt d'échanger avec les gens et favoriser les interactions en travaillant avec l'utilisateur et l’importance de réaliser un minimum viable product (produit minimum viable). Il pointe également certains éléments qui habituellement sont des obstacles. Par exemple le fait de suivre un plan à long terme, de se focaliser sur la négociation du contrat, de se concentrer plus sur les process que sur les individus ou encore de devoir réaliser un grand travail administratif avant même de pouvoir entamer la première action.

On peut dire que l'agilité rend possible l'adaptation aux changements. Adapter cet état d'esprit au hardware ouvre une perspective intéressante. Favoriser la flexibilité et les individus rend les équipes plus productives, efficace et leur travail plus agréable.

La manifeste Agile pour le hardware de 2008

Joe Justice, un Scrum master américain, est à l’origine du manifeste agile pour le Hardware en 2008. Ce manifeste adapte le premier manifeste agile aux besoins spécifiques du hardware  et notamment à la difficulté plus grande de faire des changements lorsque le processus de fabrication du produit ou du bâtiment est avancé. Pour permettre de faire des changements même tardifs et en réduire les coûts il propose quatre principes:

• La modularité
• Le choix d’outils de production qui permettent la flexibilité
• L’utilisation d’un nombre réduit de matériaux
• La recherche d’un design minimaliste

L’utilisation de maquettes et de prototypes est déterminant dans cette méthode de conception.  Cela permet de tester constamment le produit. Pour travailler ainsi, il est recommandé de suivre  plusieurs principes.

La modularité, un concept connu en architecture

• Découper le projet en modules

Il faut dans un premier temps modulariser le projet. Le découper en plusieurs modules permet de réduire les risques. On évite ainsi de revoir tout le projet si une seule partie ne fonctionne pas . Il est important que chaque module soit indépendant pour que des équipes différentes et indépendantes puissent itérer dessus. Pour que l’assemblage final soit possible, il faut néanmoins définir clairement les jonctions ou interfaces.

• Définir clairement les interfaces

Les interfaces ou connections entre modules doivent donc être définies en amont pour permettre leurs autonomies de conception. Il s’agit en fait de la transposition d’un concept connu dans le logiciel qui est le contrat d’interface, et permet aux utilisateurs d’une API (Application Programming Interface) de prévoir leur développement même avant qu’elle ne soit fonctionnelle.

• Tester l’intégration des modules fréquemment

Des tests d’intégration des différents modules doivent être si possible en continue. Si possible ils  devraient même pouvoir être automatisés. Ceci avec pour but de détecter au plus tôt les problèmes d’intégrations et de pouvoir ainsi corriger en amont les modules et réduire le risque de l’assemblage.

La réalité augmentée comme moyen de tester un produit en continu

• Définir et tester les critères d’acceptances à chaque étapes

Pour améliorer constamment le produit, il faut également tester le produit en fonction de critères d’acceptances. Joe Justice propose d’utiliser la méthode du test driven development ou développement orienté par les tests. Dans cette méthode il s’agit d’écrire en avance les critères minimums pour que le produit soit valide. A toutes les étapes de la conception il faut vérifier que le produit passe les tests. Ainsi, pour une voiture comme dans le cas de Wikispeed, il s’agit de faire des crash tests très en amont pour contrôler la résistance de l’habitacle. Il propose également de profiter des  nouveaux capteurs issus de l'internet des objets pour analyser les projets en temps réel. Dans le cas du bâtiment, on peut imaginer tester à chaque étape de conception les performances thermiques du bâtiment. Cela permettrait de contrôler que des choix faits en amont sur le design n’auront pas d’impact sur les performances techniques souvent mesurées trop tard.

• Fournir à chaque itération un produit qui “marche” ou que l’on peut évaluer

Un point  important du “manifeste Agile pour le Hardware” est d’avoir à la fin de chaque sprint un produit qui “marche”. C’est à dire d’obtenir un prototype physique en état de marche, ou virtuel que l’on peut tout de même évaluer. L’utilisation de moyens techniques tels que la réalité augmenté facilite ce travail de prototypage et d’itération en réduisant les coûts.

• Travailler en équipes pluridisciplinaires

Enfin au sein des équipes, la communication et le travail collectif doivent être mis en avant. Il faut créer un état d’esprit, qui permette aux acteurs de proposer des solutions innovantes aux problèmes qui se présentent à eux. Les équipes doivent être multidisciplinaires et les membres sont tour à tour mentor ou apprenant. Les équipes agiles valorisent la communication  entre les membres pour créer une émulation. Tous les membres de l’équipe peuvent aider et donner leur avis même quand ils ne sont pas des spécialistes “officiel” du sujet.

Ce qu’il faut retenir du manifeste agile pour le Hardware

Le manifeste agile de 2001 a été adapté pour les projets hardware par Joe Justice à l’occasion du projet Wikispeed. Cet ancien développeur spécialiste du Scrum a édicté 4 principes et plusieurs stratégies qui visent à accélérer le processus de conception et faciliter les itérations.

Ces principes sont complémentaires et sont basés sur la modularité, un choix des outils de production favorisant la flexibilité, l’utilisation d’un nombre réduit de matériaux. L’objectif est de tester constamment le projet (grâce au test driven development), et d’obtenir un produit fonctionnel à la fin de chaque cycle d’itération, où les modules améliorés sont intégrés au fur et à mesure. La technologie et notamment la réalité virtuelle peuvent vous aider dans ce processus d’itération afin de recueillir les avis des utilisateurs.

Le travail d’équipe est au centre de cette approche. Ce sont les capacités des acteurs à communiquer à toutes les étapes du projets et l’émulation au sein de l’équipe qui vont permettre l’agilité.