Facteurs de réussite de la gestion par version (et "comment bien faire")

Vous serez confronté à de nombreux défis lorsque vous gérerez par version. J'ai appris au fil du temps que si vous "faites bien les choses" dans trois domaines clés de la conception, le reste se mettra en place et réduira les risques.

En fait, au lieu de les appeler des défis, appelons chacun d'entre eux un facteur de réussite.

Premier facteur de réussite

Définir clairement ce qu'est un changement acceptable de type "business as usual" ou BAU, par rapport à un "changement de type Release". Il est essentiel de définir ces deux catégories.

Si vous laissez des zones grises, les utilisateurs pousseront les changements demandés ("nous avons besoin d'une nouvelle ligne dans le formulaire d'utilisateur dès que possible") dans la liste BAU pour une action rapide.

La liste BAU va rapidement s'allonger alors que la liste de diffusion se réduit et vous vous apercevrez que vous avez sapé votre propre stratégie de diffusion.

Deuxième facteur de réussite

Mettre en place un processus adéquat. Un processus solide comportant des étapes formalisées pour planifier, programmer, contrôler et approuver les versions garantit qu'elles seront en phase avec les exigences de l'entreprise.

L'application du processus permet d'éviter que des modifications soient insérées ou retirées d'une version après sa date limite. Vous organisez peut-être les communiqués en fonction d'une application, d'une date ou d'un autre critère.

Pour accélérer la livraison, utilisez votre processus pour limiter le nombre de composants, de sorte que vos tests n'aient pas à être aussi étendus et profonds. Vos modifications seront mises en production plus rapidement.

Troisième et dernier facteur de réussite

Gérez étroitement vos changements parallèles. Cela concerne à la fois la définition des changements et le processus. Des modifications simultanées dans le cadre du BAU et de la version peuvent entraîner l'écrasement des modifications du BAU lorsque la version passe en production.

De telles erreurs peuvent être très difficiles à retracer et peuvent nuire à la qualité de la publication, voire à la stratégie elle-même. Un bon contrôle des processus et une bonne application des règles peuvent éviter de tels problèmes.

Une fois que vous aurez défini et débogué les critères de décision, établi l'application du processus et contrôlé les changements parallèles, vous serez confronté à de nombreuses autres décisions, mais vous disposerez d'une base solide pour les prendre.

Par exemple, devez-vous déployer un environnement de développement N+1 ? Vous pouvez résoudre ce genre de problèmes en répondant à des questions clés telles que :

• Combien de changements chaque version contiendra-t-elle (taille de la version) ?
• Quels types de changements seront inclus par version (impact de la version) ?
• À quelle fréquence les versions doivent-elles être appliquées à la production (fréquence des versions) ?
• Quelle est l'ampleur et quels sont les types de changements qui constitueront le volume constant des changements dans le cadre du BAU ?

Ce tableau peut vous aider à choisir les méthodes de livraison.

Par exemple, si vous intégrez les changements de faible à moyenne importance dans votre flux BAU et réservez la version trimestrielle aux améliorations majeures, vous pouvez renoncer aux processus de développement N+1 et gérer les versions par le biais de votre processus standard à la place.

C'est à vous de choisir l'approche qui vous convient le mieux. Veillez simplement à ce que chaque facteur de réussite "indispensable" soutienne votre décision.

Pour en savoir plus sur la façon dont Rev-Trac peut vous aider à mieux gérer les versions et à obtenir chaque facteur de succès correctement, n'hésitez pas à contacter notre Experts en gestion du changement SAP.