Comment concilier normalisation et créativité ?

Chaque équipe projet est constituée de membres dotée d’expériences, de parcours et de modes de pensée différents. La phase de définition du projet peut tirer parti des spécificités de chacun pour aboutir à des projets innovants et performants. En revanche, la phase d’implémentation, nécessite une réalisation homogène garante de la capacité de maintenir et de faire évoluer aisément le produit.

Une dichotomie importante entre ces deux phases doit être atténuée, une fois les meilleurs choix effectués et indépendamment de l’approche méthodologique (cascade, cycle en V, itérations courtes / agiles, …). Lorsque l’ensemble des choix et règles applicables sont définis, ils doivent être référencés, explicités, compris, maitrisés, appliqués puis contrôlés.

Guider l’équipe projet dans la réalisation sans restreindre les objectifs fonctionnels est donc un véritable challenge !

Il est d’autant plus difficile à relever que l’équipe projet est une entité vivante: outre les changements de membres qui peuvent s’opérer la topologie même de l’équipe est sujettes à variation dans le temps. Le produit quand à lui est à même de nécessiter des évolutions – parfois même majeures – à tout moment. Il est donc très important de pouvoir transmettre de manière succincte et efficace les savoirs et savoirs-faires nécessaires à l’enrichissement du produit dans le respect des règles de fabrication en vigueur.

Des guides de développement traditionnels coûteux, non pérennes et sous-utilisés

Traditionnellement, lors du démarrage d’un projet, on rédige des documents de type « dossier d’architecture » ou « guide du développeur ». L’objectif principal de ces guides est d’accompagner les membres de l’équipe à suivre les règles de nommage, les notations, et les bonnes pratiques de développement dans la continuité des lignes architecturales définies.

Ainsi, en amont de projet, quelques jours sont dédiés à la rédaction d’un document (souvent volumineux), tentant de lister exhaustivement les règles et recommandations à appliquer. Or ces guides ne peuvent que très difficilement êtres exhaustifs dès leur première version, et d’autant plus dans un contexte d’itérations courtes au fil desquelles les exigences sont susceptibles de variées fortement.

L’équipe de développement prend rapidement connaissance de documents partiels, et commence à produire. Au mieux elle consultera fugitivement ces documents lors de la mise en œuvre de nouveaux éléments. Très rapidement ces lectures laisseront place à celle des fichiers de code source qui serviront dès lors de références. Au fil du temps le risque est grand de voir le nombre de règles transgressées, ou même souvent involontairement modifiées d’altération en altérations. Et la fréquence de ces comportements est souvent alignée sur le pourcentage de complétude des guides …

Enrichir, adapter, compléter les guides.

Comme nous l’avons vu précédemment il est à la fois nécessaire d’ajouter de nouvelles règles éventuellement manquantes mais également de les ajuster ou même de les changer totalement en cas de changements importants des objectifs à atteindre ou de modification d’exigences tardives. Les documents traditionnels peuvent laisser place à des solutions de gestion de contenus collaboratives de type wiki voir même des blogs. Ils constituent une alternative très intéressante du fait de leurs capacités d’enrichissement du contenu en continue. De plus les équipes sont davantage impliquées : elles ne « subissent » plus des ensembles de règles à respecter mais sont conviées à les élaborer et à les compléter de façon participative.

Enfin de nombreuses informations auparavant échangées lors de discussions informelles, avant intégration dans de nouvelles versions des documents de références peuvent également être pérennisées par le biais des mécanismes de notes, de commentaires ou de discussion et ainsi automatiser au maximum la production.

Il existe aussi une alternative encore largement sous employée : l’automatisation. La fabrication d’un produit est décomposable en une suite de processus répétables (et trop souvent répétés manuellement). Aujourd’hui la plupart des plateformes de développement proposent des solutions pour automatiser ces scénarios. Ainsi, Microsoft et son environnement de développement Visual Studio .NET fournissent de nombreuses solutions pour automatiser des ensembles de tâches prédictibles :

  • Le premier niveau, facilement atteignable concerne la personnalisation de l’IDE : ajout de macros pour effectuer des tâches simples mais répétitives ou modification des modèles de projets et de fichiers, en passant par la définition de « snippets » de code, c’est-à-dire de modèles de code source adaptés à un usage particulier, permettent de réduire d’éventuels excès de définition de règles. Ces adaptations sont très simples et peu couteuses à mettre en œuvre et offrent d’ors et déjà un premier niveau de solution à l’apparition de variations.
  • Un second niveau, plus complexe mais extrêmement puissant consiste à utiliser le framework de création de guides « Guidance Automation Toolkit » pour définir des guides et automatiser partiellement ou totalement des scénarios prédéfinis. Il est alors possible de tirer profit de l’ergonomie et de la productivité de la modélisation offerte par les DSL (Domain Specific Languages) graphiques, d’automatiser la structuration des développements ou encore de personnaliser totalement l’outil des développeurs pour les guider, pas à pas, aux travers d’assistants effectuant une myriades d’opérations séquentielles de façon automatisée, là où, auparavant, ils essayaient péniblement de les effectuer manuellement sans erreurs.

Microsoft fournit des exemples intéressants et directement exploitables de ces solutions d’automatisation appelées « Software Factories ». La plus complète à ce jour étant « Web Services Software Factory – Modeling Edition » qui guide le développeur dans la création de services Web en suivant les recommandations d’architectures du groupe "Patterns & Practices".

Pour guider avec un maximum d’efficacité les développeurs dans le respect des processus de fabrication, ces solutions performantes et qui offrent de bons retours sur investissement méritent donc d’être plus largement connus et mises en œuvre.

2 Responses to “Comment concilier normalisation et créativité ?”


  1. 1 plem 29/09/2008 à 10:18

    Très intéressante l’idée d’utiliser des frameworks de génération de guide et la modélisation par les DSL. La principale difficulté que j’entrevois à cette approche, qui théoriquement est très raisonnable, est que tous ces outils ont un niveau de complexité qui pour être pleinement maitrisé et rentabilisé, nécessitent vraisemblablement une pratique quotidienne durant plusieurs mois. Me trompe-je ? Cette approche me semble donc adaptée uniquement aux projets de très grande envergure. Selon moi le vrai progrès adviendra lorsque les outils de développement, les langages et les modes d’organisation projet (définition des responsabilités) auront atteint une certaine stabilité. Trop souvent encore la nouveauté pour la nouveauté et la restructuration pour la restructuration est valorisée au détriment de la qualité, de l’acquisition par les équipes projet d’un niveau d’expertise à la hauteur de la complexité des tâches qu’elles assument. Selon moi, une définition, une normalisation et la stabilisation de quelques DSL constituerait la démarche la plus prometteuse pour fiabiliser les délais de développement. Sinon, l’élaboration participative des règles, me rappelle curieusement le discours sur la démocratie participative d’une certaine madone récemment convertie au télévangélisme.

  2. 2 hboumaraf (Hassen BOUMARAF) 29/05/2009 à 13:07

    Les DSL sont vraiment pas mal, j’ai initié un projet personnel sur les DSL appliqué à SharePoint pour construire un générateur de Feature. Cet outil, en plus d’être simple a une vocation pédagogique, les nouveaux venus sur SharePoint ne connaissent pas toutes les types de features disponibles, en passant par une liste déroulante des type de Feature, cela pourra réveiller leur curiosité et les pousser à creuser le sujet
    Mon avis est que chaque entreprise de service informatique doit disposer d’un département Industrialisation. Chez SQLI, ce département serait au même titre qu’un comité CMMI.
    L’idée d’industrialiser des méthodes de développement et capitaliser dessus doit forcement passer par la production d’outils necessaire


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s




Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64 114 hits

%d blogueurs aiment cette page :