"La collaboration agile facilite les projets logiciels dans l’industrie automobile"[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. ...
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. |