Tribunes

Modèle de développement open source : les apports pour l'entreprise

PublicitéLe modèle de développement open source appliqué à l'entreprise offre de nombreux avantages, comme la diminution du time-to-market et du time-to- profit, l'augmentation de la productivité, notamment par la réutilisation et l'enrichissement plutôt que par la recréation, l'amélioration des compétences et la pérennisation des solutions, même quand les auteurs ne sont plus là. Il permet aussi la maximisation des ressources et l'amélioration du processus de décision par une participation pluridisciplinaire. De nombreuses études ont montré qu'à peine le tiers des projets utilisant des méthodes traditionnelles de développement ont réussi à atteindre leurs objectifs, c'est-à-dire délivrer une solution complète fonctionnellement dans les délais et dans les budgets impartis. Parmi les facteurs influençant la réussite ou l'échec d'un projet reviennent régulièrement le manque d'implication des utilisateurs et le besoin d'objectifs métiers clairs. En outre, on constate une augmentation de la complexité des équipes : différents sites, différents fuseaux horaires, différentes organisations ainsi qu'une augmentation du rework atteignant 6 à 7 % de la charge d'un projet. La réponse apportée par l'industrie informatique a été le développement rapide, extrême et maintenant agile avec DSDM (Dynamic Systems Development Method), RUP (Rational Unified Process), Scrum ou encore XP. Ces méthodes ont rencontré un vif succès auprès des développeurs mais laissent sceptiques quant à leur productivité et à leur adéquation avec des projets de taille raisonnable. En revanche, le modèle de développement open source montre, nombreux exemples à l'appui, qu'il est possible de réaliser des projets de grande envergure. Mais ce modèle est-il applicable à l'entreprise ? Comment gérer le paradoxe entre "cultiver" des structures informelles et les gérer de façon conventionnelle ? Bien que chaque projet open source soit différent, on y retrouve un certain nombre de caractéristiques récurrentes. L'organisation est généralement hiérarchique avec peu de niveaux (utilisateurs, développeurs, développeurs principaux). L'ascension dans la hiérarchie est liée au mérite dans une culture du "faire". On constate aussi que les développeurs travaillent sur plusieurs projets avec des degrés d'engagement différents. La visibilité est un principe de base. Tout ce qui est produit, que ce soit le code ou la documentation, est public et facile d'accès. Cela implique aussi de livrer fréquemment des composants qui sont revus et testés par des pairs ou des utilisateurs. Ceux-ci sont donc fortement impliqués dans le processus de développement. À l'inverse des projets traditionnels d'envergure, le management n'est plus le seul à avoir une vision transverse et à faire le lien. Les projets n'ont plus besoin d'être divisés dans des silos opaques. Le management est orienté vers les livrables, c'est-à-dire que chacun a la liberté de s'organiser comme il le souhaite à condition qu'il tienne ses engagements de délais de livraison et de respect des normes et standards liés au projet. La dimension économique n'est généralement pas la motivation principale des projets open source. Ainsi, le développement est orienté vers la recherche de la meilleure solution - la plus intelligente, mais pas forcément la plus populaire. En revanche, la dimension pratique domine largement et selon une loi naturelle de sélection, seules les solutions utiles, utilisables et utilisées survivent. La documentation, quant à elle, est réduite au minimum, parfois à presque rien d'ailleurs... Techniquement, cela conduit à des logiciels utiles, innovants, modulaires, robustes et évolutifs qui favorisent la réutilisation, ce Saint-Graal de l'informatique que les architectures orientées services nous promettent à l'échelle de l'entreprise, voire plus. Mieux que des promesses, le modèle de développement open source prouve que l'on peut réutiliser ce qui marche, moyennant un coût largement inférieur aux référentiels, beaucoup trop éloignés des développeurs et des utilisateurs. Enfin, la dimension humaine de ce modèle apporte de nouveaux référentiels sur la motivation des équipes virtuelles divisées organisationnellement, géographiquement et culturellement et pourtant si solidaires et si efficaces. Tout le modèle ne s'applique pas à l'entreprise. Néanmoins, un certain nombre d'usages et de techniques peuvent s'avérer très efficaces. Les équipes doivent pouvoir communiquer fréquemment entre elles et avec leurs utilisateurs. Pour cela, elles ont besoin d'outils simples et faciles d'utilisation comme les messageries instantanées (Jabber), les vraies listes de diffusion avec possibilité d'archivage et de recherche (Sympa) ou les blogs (Serendipity) traçant quotidiennement la vie du projet. Des réunions physiques de quelques jours dont l'objectif est le développement intense, souvent en binôme, que l'on nomme "sprint", sont aussi l'occasion de renforcer la cohésion d'équipe. Un corollaire à cette communication est la transparence, élément essentiel, qui rend visible le projet et les développeurs au plus grand nombre. Cela signifie avoir un site de type GForge, où chacun peut consulter la feuille de route, les sources, les documents, télécharger le logiciel, questionner et commenter. Un site où chaque développeur, chaque utilisateur est visible, reconnu pour son travail en figurant dans la liste, publique, des meilleurs contributeurs. Cette transparence permet d'impliquer les utilisateurs très tôt dans le processus de développement. Non seulement ils testent le produit au fur et à mesure de sa construction, mais ils doivent aussi peser sur la construction de celui-ci. Pratiquement, il est préférable de créer, en début de projet, un groupe d'utilisateurs motivés comme "bêtatesteurs". De plus, pour les projets à fort caractère métier, il est utile de réaliser un atelier de travail entre développeurs et utilisateurs, pour définir les besoins métiers et créer l'implication. Cette implication des utilisateurs impose des livraisons fréquentes de parties de l'application et une bonne gestion de configuration. L'application doit donc être conçue de façon modulaire schématiquement autour d'un noyau et d'extensions qui sont réalisées de façon incrémentale. Les tests et l'intégration sont continus, ce qui est largement simplifié par une instrumentation et une automatisation de ces processus. Le monde libre utilise des outils comme Subversion, CruiseControl, Gump, Maven, The Grinder, et bien d'autres encore. Le modèle de staffing que propose l'open source permet d'aller vers une maximisation des ressources en utilisant les gens pour ce qu'ils savent faire le mieux et en leur donnant une certaine autonomie dans leur organisation personnelle. Ainsi, un développeur travaille pour différents projets avec des degrés d'implication différents, généralement sur des domaines où il est pertinent. Il s'engage sur des livrables et des délais. Ce modèle génère un sentiment de propriété collective beaucoup plus important que dans les modèles plus traditionnels. Attention, cependant, au "développeur pompier" ; nous sommes ici dans un modèle organisé. Les rôles sont clairs, opérationnels et parfaitement connus de tous : développeur principal, commiter, développeur, utilisateur. Les développeurs principaux continuent à participer aux vagues successives d'évolution, ce qui assure une certaine stabilité au projet. Le rôle du développeur est enrichi d'un rôle de "vérificateur" du code produit par ses pairs. Le committer, quant à lui, est un rôle opérationnel de vérification du code, de maintien de la modularité du projet et de sa cohérence. Celle-ci est maintenue par les règles et standards du projet. Les frameworks de développement, les processus de mise à jour, les normes de codage, de documentation sont autant d'exemples de contraintes qui, paradoxalement, sont des éléments essentiels de la culture du projet. Les contraintes collectives opérationnelles créent un cadre qui rassemble et qui rassure. En revanche, la méthode de développement en vigueur au sein de l'entreprise ne doit pas être abandonnée mais simplement adaptée. La standardisation de la documentation n'est pas non plus à négliger. Elle doit être opérationnelle et automatisée au maximum. En utilisant des outils tels que les wikis, les archives de listes de diffusion ou de forums, le temps passé à réaliser de la documentation est largement réduit. Bien entendu, cela ne dispense pas les développeurs de la rédaction de documents de définition de besoins ou d'architectures. Et on pourra leur déléguer la réalisation du manuel utilisateurs. Comme tout changement, la mise en place des pratiques présentées précédemment s'accompagne d'une forte volonté politique, d'autant plus que nous sommes ici dans un changement de culture : du projet à l'entreprise, de l'individu au collectif. Cette volonté se traduit par une charte qui précise l'organisation, le processus, le management et l'infrastructure. L'organisation reste simple. Un sponsor, le DSI, soutient politiquement le projet et obtient les fonds nécessaires pour son fonctionnement. Un administrateur gère l'environnement technique, met en place les environnements pour les nouveaux projets et apporte un support à l'utilisation de la plate-forme. Un manager communique les succès, le catalogue des projets et motive les équipes. De plus, les pratiques présentées précédemment doivent être accompagnées d'un certain nombre de mesures permettant leur acceptation et leur développement. Il doit exister un plan, quel que soit son nom - compensation, reconnaissance, motivation - qui valorise et récompense les projets et les contributeurs. Ce plan travaille sur les motivations des différents acteurs, généralement un besoin de reconnaissance. Une approche pragmatique telle que celle de Xavier Soler (voir CIO n° 20), qui définit seize motivations essentielles, les moyens de les détecter et de les stimuler, s'avère très utile ici. En effet, comme décrit précédemment, l'argent n'est plus le moteur principal de motivation. Dans un système fondé sur les livrables, les critères traditionnels de mesure de la productivité doivent être complétés. L'approche préconisée par Alistair Cockburn, centrée la valeur ajoutée et l'utilisation de burn charts, est particulièrement bien adaptée à la mesure de la productivité d'un projet collaboratif. Concernant les développeurs eux-mêmes, on peut s'appuyer simplement sur le code proposé, produit et accepté sur l'ensemble des projets auxquels ils contribuent. Dans l'approche globale, il est essentiel de laisser la porte ouverte aux programmes non officiels qui existent au sein de toute entreprise. Ainsi, ces programmes qui simplifient la vie ne seront plus systématiquement réécrits mais plutôt enrichis par tous. L'entreprise peut choisir de financer officiellement le développeur principal de certains programmes jugés pertinents et ainsi rendre visible l'informatique noire. La mise en place d'un tel modèle s'opère par étapes successives. D'abord en interne sur un réseau local, pour les phases de développement, ensuite selon deux axes, géographique et fonctionnel, passant du département à l'entreprise et du développement à tout le cycle. Les premières équipes projets doivent être composées de personnes motivées ayant des compétences techniques certaines, mais aussi des compétences humaines pour être capables de supporter un des revers de la visibilité : la critique. Bien entendu, les succès doivent faire l'objet de communication tant auprès des informaticiens que des utilisateurs et être capitalisés dans des business cases. L'extension à des partenaires externes, voire à des communautés, demande un certain niveau de maturité et une réflexion approfondie sur la sécurité et le patrimoine informatique de l'entreprise. Le modèle de développement open source semble donc avoir complètement intégré la vision de Peter Drucker : "Because its purpose is to create a customer, the business has two -and only two- functions: marketing and innovation. Marketing and innovation create value, all the rest are costs." (Parce que son intention est de créer du client, le business a deux -et seulement deux - fonctions : marketing et innovation. Marketing et innovation créent de la valeur, tout le reste n'est que des coûts.") Aux entreprises de tirer parti des meilleures pratiques des communautés open source. Pour en savoir plus : - Dynamic Systems Development Method : www.dsdm.org - Open source community building : http://opensource.mit.edu/papers/sturmer.pdf - Collaboration : www.gforge.com, www.collab.net et www.vasoftware.com/ - L'approche de Xavier Soler : voir CIO n° 20 et www.xavier-soler.com - L'approche d'Alistair Cockburn : http://alistair.cockburn.us/crystal/articles/evabc/earnedvalueandburncharts.htm - People and Performance, Peter F. Drucker, Harper's College Press, 1977

Article rédigé par

Jean-Yves Reynaud, Lead Technologist chez EDS France
Lead Technologist chez EDS France, Jean-Yves Reynaud a la responsabilité de la stratégie technique et de la coordination des expertises de l'entité EDS Services Applicatifs & Régions. Après une activité de directeur de projets majeurs pendant une dizaine d'années, il pilote aujourd'hui la mise en pratique de l'ingénierie d'EDS France. Par ailleurs, il anime des cercles d'experts ainsi qu'une communauté technique Open Source de plus de 600 membres.