[TRIBUNE by Christian Mies, ELEKTROBIT] La société Elektrobit, spécialisée dans les solutions matérielles et logicielles pour les marchés de l'automobile, et le constructeur Ford ont travaillé ensemble sur l’élaboration d’un projet mondial d’info-divertissement. Cette collaboration reposait sur les principes de développement agile. Dans ce cadre, Elektrobit a pu identifier sept lignes directrices pouvant également s’appliquer à d’autres projets. Explications de Christian Mies, Head of Automotive Software Consulting chez Elektrobit. ...
.jpg)
Au fur et à mesure que les cycles d’innovation s’accélèrent et que la complexité augmente, les méthodes agiles sont de plus en plus utilisées pour les projets logiciels dans l’industrie automobile. Pour que la collaboration agile fonctionne réellement, un certain nombre de conditions préalables doivent être remplies. La première condition préalable est une compréhension commune des principes sur lesquels repose la collaboration. Notre expérience montre que cela va bien au-delà de l’utilisation de méthodes telles que Scrum ou Kanban qui décrivent un état d’esprit de base. La deuxième condition préalable obligatoire est une forte relation de confiance mutuelle entre le client et le fournisseur. Dans de nombreux cas, cela nécessite une collaboration à long terme et des projets mis en œuvre avec succès. Nous prenons comme référence notre collaboration avec Ford comme référence, devenue depuis 2007 un partenariat stratégique à long terme, réparti sur trois continents. Dans le projet d’info-divertissement, des procédures spécifiques ont été dérivées des principes théoriques énoncés, par exemple, dans le « Manifeste Agile ».
Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser les individus et leurs interactions plus que les processus et les outils, des logiciels opérationnels plus qu’une documentation exhaustive, la collaboration avec les clients plus que la négociation contractuelle, l’adaptation au changement plus que le suivi d’un plan. Certes nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers (http://agilemanifesto.org/iso/en/manifesto.html).
Dans le détail, sept lignes directrices ont soutenu à la fois la communication interne de l’équipe et la coordination avec le client :
- Livrer le plus rapidement possible. Les versions Nightly Build permettent au client de visualiser l’état actuel du produit et d’envoyer directement des commentaires. Un système réel présente les fonctionnalités et les concepts mieux que les billets et les spécifications. Leur développement implique un travail supplémentaire et ils laissent souvent la place à l’interprétation.
- Intégrité. Comme tout bon artisan, chaque membre de l’équipe doit viser des résultats de haute qualité. Une approche qui a fait ses preuves est la programmation en binôme : un développeur écrit le code, tandis que l’autre se concentre sur la conception. Les tests permanents qui sont automatisés dans toute la mesure du possible constituent un autre aspect obligatoire. Dans le développement piloté par les tests, les développeurs écrivent d’abord le test, puis l’algorithme proprement dit.
- Décider aussi tard que possible et donc rester capable d’agir. Il ne s’agit pas de reporter les décisions, mais de les prendre au bon moment. Les décisions, par exemple, concernant l’architecture du système ou l’interface utilisateur, qui sont prises trop tôt, créent des dépendances et peuvent nécessiter des corrections coûteuses et longues. Il est logique de commencer le projet sur la base d’hypothèses fondées et de prendre les décisions nécessaires juste à temps. Cela permet une correction ultérieure des besoins, si nécessaire.
- Éliminer rapidement les déchets. Les fragments de code obsolètes ou les composants inutiles doivent être rapidement éliminés. Y a-t-il des éléments ou des activités qui n’ont pas de valeur ajoutée ? Il faut éviter de travailler sur des fonctionnalités inutiles, des exigences excessives ou la « programmation à l’avance ». Les chefs de projet sont confrontés aux questions suivantes. Une utilisation ultérieure ou une réutilisation sont-elles possibles ? Un détour supposé promet-il des résultats plus rapides ou plus fiables à long terme ?
- Responsabiliser l’équipe. L’objectif est une équipe auto-organisée, motivée et efficace. La planification détaillée est laissée à l’équipe, sur la base d’outils tels que les tableaux Kanban. Des paramètres tels que les tâches effectuées par itération, la période de correction des erreurs ou les taux de retour sont utilisés pour assurer le succès du projet. Pour les tâches simples, la devise est « push, don’t pull » (à flux poussé, et pas à flux tiré). C’est l’équipe elle-même qui décide qui travaille sur quelle tâche. Le responsable du produit (product owner) fixe des priorités globales.
- Réfléchir à intervalles réguliers. Les commentaires et les idées de l’équipe contribuent de manière significative à la qualité du produit et à l’efficacité du processus. Plus précisément, Elektrobit a abandonné la méthode Scrum à un stade ultérieur du projet. En raison de l’accent mis sur la correction des erreurs, par exemple, la planification de Sprints de deux semaines n’était plus possible et exigeait des efforts inutiles. L’équipe du projet a opté pour la méthode Kanban. L’accent sur l’optimisation du débit l’a rendue plus adaptée à la situation spécifique du projet.
- Voir l’ensemble. Chaque membre de l’équipe est encouragé à sortir des sentiers battus et à assumer la responsabilité pour l’ensemble du produit. Par exemple, le débogage – quelle que soit la personne qui a causé l’erreur – devrait toujours être effectué dans l’ensemble du système et ne devrait pas se limiter à l’étendue du travail du membre de l’équipe. Par conséquent, les tests ne se limitent pas à l’environnement de développement. Ils ont également lieu dans le véhicule.
