qualité des livraisons dans un cycle de développement

Bonjour à tous,

Je travaille au sein d'une équipe AMOA dans le secteur public dans un projet de conversion d'application , notre MOE qui est en relation directe avec le prestataire de conversion procède à des livraisons sans réelle planification , la veille on reçoit un mail avec le lien vers la version livrée de l'application en mentionnant le numéro de la version mise en ligne , or pour l'élaboration d'une stratégie de test et surtout d'une stratégie de TNR , on aurait besoin de plus de détails pour chaque livraison , des infos de base comme la date de la livraison, son numéro de version, mais surtout d'un listing des bugs corrigés , et / ou des fonctionnalités intégrées , des mentions spécifiques (modifications, correction , évolution ... )

Selon vos expériences respectives , quel est le formalisme de vos livraisons (tableau descriptif , mail récapitulatif ...?)

Pourriez vous me donner des modèles ou des exemples ?en somme de la matière pour que je puisse formuler une demande officielle de mise en place d'un vrai processus de livraison selon une démarche qualité .

Merci beaucoup

En termes de contenu des livraisons, on livre normalement toujours des "Release Notes". Concernant leur forme c'est assez variable mais on y trouve normalement une description (ou à minima une référence) vers l'ensemble des évolutions et des corrections de bugs majeurs. La correction de bugs mineures me semblent tout de même appréciable.

Après il faut distinguer les anomalies "privées" et "publiques". Et là s'entame la définition du cycle de vie de l'application. Théoriquement, l'équipe de développement produit N versions, puis elle "livre" N versions à l'équipe de test et finalement génère UNE release.

La couche supérieure ne voit jamais les anomalies "privées". Ainsi l'équipe de développement peut détecter un problème, le corriger et ne jamais vous en avertir. De même que pendant vos phases de tests, vous pouvez détecter un problème existant mais ne pas le communiquer "publiquement".

La Release Note étant un asset de la "release", il ne devrait pas théoriquement faire mention de ces corrections. Excepté qu'il peut être voulu politiquement de communiquer sur des anomalies corrigées sur des versions précédentes afin de rassurer/informer les utilisateurs qui auraient pu trouver le bug mais ne pas le signaler.

Je pense que la solution idéale étant d'avoir un accès à leur système de gestion des tâches (Task Tracker : JIRA, Mantis, etc.). Quit à utiliser un second projet ou un système de filtrage s'ils veulent vous masquer des informations. Ces systèmes pouvant d'ailleurs générer des "Release Notes".


Au delà de tout cela, je souhaiterai signaler quelques petits trucs. L'équipe AMOA est censée définir le contenu ET le moment de la livraison et non l'équipe de développement !
Ce qui permet d'ailleurs d'anticiper sur les impacts de la stratégie de tests.

Tout d'abord merci pour votre réponse ,

Effectivement , je pense que c'est aussi à la AMOA de définir le moment de la livraison ce qui permet de gérer les planning dans le plan projet , par contre comment la définition du contenu peut elle être gérée par la AMOA ? je veux bien qu'on me donne plus de précisions s'il vous plait .

Merci encore

Cela dépend de votre méthode de travail :

• RUP (ou classique) : l'équipe de développement implémente la spécification que vous avez fourni.
• Scrum : il y a une revue de backlog en fin du sprint précédent pour terminer le contenu de la prochaine livraison.
• Kanban : c'est un poil plus complexe car il s'agit uniquement de prioriser des tâches. Les tâches sont prises dans l'ordre par l'équipe de développement en fonction des compétences de chaque personne. Il est donc primordiale que les tâches sont simples et courtes pour s'assurer qu'elles sont produites dans un ordre proche de celui dans lequel les tâches ont été prises. La release est déclenchée quand le donneur d'ordre le souhaite. En général, c'est un mix entre l'ancienneté de la précédente release, la densité de la release en cours et enfin sa stabilité.

Bref, il s'agit de fournir l'ensemble des fonctionnalités souhaitées (corrections de bugs incluses).

Bonjour ,

Effectivement nous travaillons bien en RUP , le périmètre fonctionnel est défini lors de l'allotissement des travaux de conversion de l'application native.

Pour chaque lot x , les fonctionnalités souhaitées sont bien définies par contre les N livraisons itératives mise en ligne par la MOE (issues du prestataire) ne mentionnent pas avec exactitude quels sont les fonctionnalités du lot x implémentées dans la version N de la livraison.

En tout les cas, j'ai bien intégré tout ce que vous m'avez expliqué dans une ébauche traitant des pistes d'amélioration éventuelles du processus de livraison.


Merci encore :mrgreen: