Comment tirer le meilleur parti de MotioCI en soutenant des pratiques éprouvées
MotioCI a intégré des plug-ins pour la création de rapports Cognos Analytics. Vous verrouillez le rapport sur lequel vous travaillez. Ensuite, lorsque vous avez terminé votre session d'édition, vous l'archivez et incluez un commentaire pour enregistrer ce que vous avez fait. Vous pouvez inclure dans le commentaire une référence à un ticket dans un système externe de suivi des défauts ou de demande de modification.
Vous pouvez trouver des détails supplémentaires sur la façon de configurer la connexion entre MotioCI et votre système de billetterie tiers dans le MotioCI Guide de l'administrateur sous Utilisation MotioCI avec des systèmes de billetterie tiers. Un mot clé (corrige, ferme) avec le numéro du ticket fermera le ticket. Ou, en utilisant un mot-clé comme plus le numéro de billet écrira le commentaire d'enregistrement dans le système de billetterie et laissera le billet ouvert.
L'utilisation d'un système de tickets - comme Atlassian® JIRA, Microsoft Windows™ Trac ou bien d'autres - facilite la gestion de projet en suivant des tâches spécifiques, des problèmes et leur résolution. Les tickets fournissent un moyen de communication entre les auteurs ou les développeurs de rapports et les utilisateurs finaux, l'équipe de test et les autres parties prenantes. Un système de billetterie fournit également une méthode pour suivre les défauts et s'assurer qu'ils sont traités avant de promouvoir un rapport en production.
Flux de travail typique pour le développement de rapports
Pour être clair, l'intégration de MotioCI avec un système de billetterie n'est pas le seul moyen pour votre équipe d'interagir avec le système de billetterie. En règle générale, comme illustré dans le diagramme de workflow ci-joint, le processus de développement de rapports dans un environnement Cognos Analytics avec MotioCI peut être quelque chose comme ça : 
- Arriéré. Un nouveau ticket est créé. Un analyste métier documente les exigences métier pour un nouveau rapport et le saisit directement dans le système de ticket en créant un ticket. Il place le billet dans le arriéré Etat.
- Développement. Les tickets de backlog peuvent être classés par ordre de priorité de différentes manières, mais en fin de compte, le ticket sera attribué à un développeur de rapports et étiqueté avec son nom. L'état du ticket peut être changé en in_dev. Elle créera un nouveau rapport. Au fur et à mesure qu'elle développe le rapport dans Cognos Analytics, elle enregistrera ses modifications et référencera le ticket dans le commentaire d'enregistrement, par exemple « Nouveau rapport créé ; version initiale; page d'invite ajoutée et requêtes de support, réf #592". Ou, "Requête de faits ajoutée et tableau croisé ; filtres et mise en forme, réf #592.” (Dans MotioCI, le numéro de hashtag devient un lien hypertexte directement vers le ticket.) Elle peut consulter le rapport, apporter des modifications et le réenregistrer avec la référence du ticket plusieurs fois sur une période de plusieurs jours.
- Développement terminé. Une fois que le développeur de rapports a terminé le rapport et l'a testé, il note dans le ticket du système de ticket qu'il est prêt à être testé par QA et change d'état de in_Dev à prêt_pour_QA. Cet état est un drapeau pour le MotioCI Administrateur ou rôle responsable de la promotion des rapports Cognos, que le rapport est prêt à migrer vers l'environnement QA pour les tests.
- Promotion à QA. L'administrateur promeut le rapport et passe à l'état dans_QA. Cet état permet à l'équipe d'assurance qualité de savoir que le rapport est prêt à être testé.
- Essai. L'équipe d'assurance qualité teste le rapport par rapport aux exigences de l'entreprise. Le rapport réussit ou échoue aux tests. Si le rapport échoue au test d'assurance qualité, le ticket est marqué avec le en développement état, en retournant au développeur du rapport pour les correctifs.
- Test réussi. Si le rapport est accepté, l'équipe d'assurance qualité indique à l'administrateur qu'elle est prête à passer en production en l'étiquetant prêt pour la production Etat.
- Promotion à la production. Une fois que le rapport est prêt pour la production, les approbations finales peuvent être obtenues et la publication programmée, peut-être regroupée avec d'autres rapports terminés. L'administrateur promeut le rapport dans l'environnement de production Cognos. Il place le billet dans OK indiquant que le développement et les tests sont terminés et qu'il a été mis en production. Cela ferme le ticket.
Gestion du processus d'élaboration du rapport
Ce processus de gestion des tickets implique et des pratiques éprouvées dictent que :
- Chaque nouveau rapport doit avoir un ticket avec les exigences commerciales pour la conception du rapport.
- Chaque défaut doit avoir un ticket pour enregistrer tout bogue ou problème avec un rapport.
- Chaque fois qu'un rapport est édité, le MotioCI le commentaire d'enregistrement doit inclure le numéro de billet qui a été adressé.
- Chaque rapport promu de Dev à QA doit avoir un ticket associé permettant à un administrateur de confirmer que le développement est terminé et qu'il est prêt à être déplacé vers l'environnement QA.
- Chaque rapport promu de QA à Production doit avoir un ticket avec un historique indiquant que le développement est terminé, qu'il a passé QA, qu'il a reçu toutes les approbations de gestion requises et qu'il a été promu.
- Chaque rapport dans l'environnement de production doit avoir un digital trace écrite de la conception aux tests en passant par la résolution, l'approbation et la promotion.
Ce dernier point est un favori des auditeurs pour valider. Elle pourrait demander : "Pouvez-vous me montrer comment vous confirmez que tous les rapports de l'environnement de production ont adhéré à votre processus documenté de billetterie et d'approbation ?" Une façon de répondre à l'auditeur peut être de fournir une liste de tous les rapports qui ont été migrés et de lui demander de parcourir les tickets pour en rechercher un qui n'est pas conforme à votre processus.
Alternativement, et plus idéalement, vous pouvez fournir une liste de rapports qui ne ne sauraient respecter le processus de développement et de billetterie que vous avez défini. C'est là que ce rapport sera utile : "Rapports promus sans tickets”. Il s'agit d'un rapport d'exception d'une liste de rapports qui ont ne sauraient adhéré aux meilleures pratiques d'avoir chaque changement de rapport lié à un ticket. C'est l'un des rares rapports que vous souhaitez vider. Il n'aura aucun enregistrement si tous les rapports qui ont été promus sont associés à un ticket. En d'autres termes, un rapport n'apparaîtra dans la liste que s'il se trouve dans l'environnement de production et que le rapport qui a été promu n'a pas fait référence à un numéro de ticket dans le commentaire. 
Processus avec avantages
Quels sont les avantages du processus, ou pourquoi devriez-vous le faire dans votre organisation ?
- Amélioration de la collaboration d'équipe : le système de billetterie peut en fait réunir des personnes dans des rôles qui ne communiquent pas normalement. Les auteurs de rapports et les utilisateurs finaux, ou le chef de projet et l'équipe d'assurance qualité, par exemple. Le ticket trail fournit un lieu commun pour communiquer sur une ressource partagée, le rapport en cours de développement.
- Coûts réduits:
- Les défauts détectés et corrigés plus tôt coûtent beaucoup moins cher que s'ils échappaient à la production.
- Efficacité améliorée - les auteurs de rapports travaillent toujours à partir d'un ticket qui est un énoncé de travail bien défini.
- Temps réduit grâce à l'automatisation des processus manuels
- Documentation améliorée : ce processus devient une base de connaissances auto-documentée des défauts et de la manière dont ils ont été résolus.
- Prévisions et analyses améliorées : vous pouvez désormais suivre les indicateurs de performance clés et les comparer aux accords de niveau de service. La plupart des systèmes de billetterie fournissent ces types d'analyses.
- Assistance interne améliorée : votre équipe d'assistance, d'autres développeurs de rapports (et même votre futur vous-même !) peuvent rechercher comment des défauts similaires ont été traités par le passé. Cette base de connaissances partagée peut conduire à une résolution rapide des défauts.
- Amélioration de la satisfaction des utilisateurs finaux : grâce à un accès direct aux développeurs via le système de tickets, les utilisateurs peuvent s'attendre à une résolution rapide des défauts et surveiller la progression d'un rapport demandé via le système.
Conclusion
Il s'agit d'un exemple des riches avantages de suivre des pratiques éprouvées et de la valeur de suivre des processus bien définis. De plus, le nouveau MotioCI rapport, "Rapports promus sans tickets" peut être d'une grande aide pour répondre aux questions d'un auditeur ou simplement pour contrôler en interne le respect des normes de l'entreprise.
