最大限に活用する方法 MotioCI 実証済みのプラクティスをサポートする
MotioCI Cognos Analytics レポート作成用のプラグインが統合されています。 作業中のレポートをロックします。 次に、編集セッションが完了したら、それをチェックインし、行ったことを記録するコメントを含めます。 外部の欠陥追跡システムまたは変更要求システムのチケットへの参照をコメントに含めることができます。
間の接続を設定する方法に関する追加の詳細を見つけることができます MotioCI サードパーティの発券システム MotioCI 使用中の管理者ガイド MotioCI サードパーティの発券システムを使用。 キーワード (修正、閉じる) とチケット番号を入力すると、チケットがクローズされます。 または、次のようなキーワードを使用して リファレンス さらに、チケット番号により、チェックイン コメントが発券システムに書き込まれ、チケットが開かれたままになります。
Atlassian® JIRA、Microsoft Windows™ Trac などのチケット システムを使用すると、特定のタスク、問題、およびそれらの解決策を追跡してプロジェクト管理を支援できます。 チケットは、作成者またはレポート開発者とエンド ユーザー、テスト チーム、およびその他の利害関係者の間の通信手段を提供します。 チケット発行システムは、欠陥を追跡し、レポートを本番環境にプロモートする前に確実に対処する方法も提供します。
レポート作成の一般的なワークフロー
明確にするために、の統合 MotioCI チームがチケット システムと対話する唯一の方法ではありません。 通常、添付のワークフロー図に示されているように、Cognos Analytics 環境でのレポート開発プロセスは、 MotioCI 次のようなものになるかもしれません: 
- バックログ. 新しいチケットが作成されます。 ビジネス アナリストは、新しいレポートのビジネス要件を文書化し、チケットを作成してチケット システムに直接入力します。 彼はチケットを バックログ でのみ停止させることができます。
- 開発. バックログ チケットはさまざまな方法で優先順位を付けることができますが、最終的にチケットはレポート開発者に割り当てられ、その名前でタグ付けされます。 チケットの状態は次のように変更される場合があります in_dev. 彼女は新しいレポートを作成します。 彼女は Cognos Analytics でレポートを作成するときに、変更をチェックインし、チェックイン コメントでチケットを参照します。 初期バージョン; プロンプト ページとサポート クエリを追加し、 参考文献＃592」。 または、「ファクト クエリとクロス集計を追加しました。 フィルターとフォーマット、 refs＃592」 （の MotioCI、ハッシュタグ番号は、チケットへの直接のハイパーリンクになります。)彼女は、レポートをチェックアウトし、変更を加えて、チケットのリファレンスを使用して、XNUMX 日間にわたって何度もチェックインすることができます。
- 開発完了。 レポート開発者がレポートを完成させてベンチ テストを行った後、QA によるテストの準備が整ったことをチケット システムのチケットに記録し、状態を次の状態に変更します。 in_Dev 〜へ QA の準備完了. この状態は、 MotioCI レポートをテストのために QA 環境に移行する準備ができている管理者、または Cognos レポートのプロモートを担当する役割。
- Promotion から QA へ。 管理者はレポートをプロモートし、状態を次のように変更します。 in_QA。 この状態により、QA チームはレポートをテストする準備が整ったことを知ることができます。
- テスト。 QA チームは、ビジネス要件に対してレポートをテストします。 レポートは、テストに合格するか不合格になります。 レポートが QA テストに失敗した場合、チケットには次のタグが付けられます。 開発中 状態で、修正のためにレポート開発者に戻ります。
- テスト成功。 レポートが合格した場合、QA チームは管理者に、ラベルを付けて本番環境に昇格する準備ができていることを伝えます。 製品の準備ができました でのみ停止させることができます。
- Promotion から生産. レポートの作成準備が整うと、最終的な承認を得て、他の完成したレポートとまとめてリリースのスケジュールを立てることができます。 管理者は、レポートを Cognos 本番環境にプロモートします。 彼はチケットを入れます クリックします 開発とテストが完了し、本番環境に移行したことを示す状態。 これでチケットがクローズされます。
レポート作成プロセスの管理
このチケット管理プロセスは、次のことを暗示しており、実証済みのプラクティスによって指示されています。
- すべての新しいレポートには、レポートを設計するためのビジネス要件を含むチケットが必要です。
- すべての欠陥には、バグや問題をレポートに記録するためのチケットが必要です。
- レポートが編集されるたびに、 MotioCI チェックインのコメントには、対処されたチケット番号を含める必要があります。
- 開発から QA に昇格されるすべてのレポートには、開発が完了し、QA 環境に移行する準備ができていることを管理者が確認できる関連付けられたチケットが必要です。
- QA から本番に昇格されるすべてのレポートには、開発が完了し、QA に合格し、必要なすべての管理承認を受け、昇格されたことを示す履歴を持つチケットが必要です。
- 本番環境のすべてのレポートには、 digital 構想からテスト、修正、解決、承認、プロまでの紙の証跡motion.
この最後の点は、検証する監査人のお気に入りです。 彼女は、「本番環境のすべてのレポートが文書化された発券と承認のプロセスに従っていることを確認する方法を教えてもらえますか?」と尋ねるかもしれません。 監査人に対応する XNUMX つの方法は、移行されたすべてのレポートのリストを提供し、プロセスに適合しないレポートを探すためにチケットを調べてもらうことです。
または、より理想的には、レポートのリストを提供できます。 お客様が定義した開発および発券プロセスを遵守してください。 そこで、このレポートが役に立ちます。チケットなしでプロモートされたレポート」。 これは、レポートのリストの例外レポートです。 すべてのレポートの変更をチケットに関連付けるというベスト プラクティスを順守する. これは、空にしたい数少ないレポートの XNUMX つです。 プロモートされたすべてのレポートにチケットが関連付けられている場合、レコードはありません。 つまり、レポートが本番環境にあり、プロモートされたレポートがコメントでチケット番号を参照していない場合にのみ、レポートはリストに表示されます。 
メリットのあるプロセス
このプロセスにはどのような利点がありますか、または組織でこれを行う必要がある理由は何ですか?
- チームの共同作業の改善: 発券システムは、通常はコミュニケーションをとらない役割を持つ個人を実際に集めることができます。 たとえば、作成者とエンド ユーザー、またはプロジェクト マネージャーと QA チームを報告します。 チケット トレイルは、共有リソース (開発中のレポート) についてやり取りするための共通の場所を提供します。
- コストの削減：
- 欠陥が発見され、より早く修正されると、本番環境に移行する場合よりもはるかに安価になります。
- 効率の向上 – レポートの作成者は常に、明確に定義された作業明細書であるチケットから作業しています。
- 手動プロセスの自動化による時間の短縮
- ドキュメントの改善: このプロセスは、欠陥とその解決方法に関する自己文書化されたナレッジベースになります。
- 予測と分析の改善: 主要業績評価指標を追跡し、サービス レベル アグリーメントと比較できるようになりました。 ほとんどの発券システムは、これらのタイプの分析を提供します。
- 改善された内部サポート: サポート チーム、他のレポート開発者 (そして将来のあなた自身も!) は、過去に同様の欠陥がどのように対処されたかを調べることができます。 この共有知識ベースは、欠陥の迅速な解決につながる可能性があります。
- エンドユーザーの満足度の向上: チケット システムを介して開発者に直接アクセスできるため、ユーザーは、システムを介して要求されたレポートの進行状況を監視するだけでなく、欠陥の迅速な解決を期待できます。
まとめ
これは、実証済みのプラクティスに従うことと、明確に定義されたプロセスに従うことの価値がもたらす豊かな成果の一例です。 さらに、新しい MotioCI レポート、「チケットなしで昇格されたレポート」は、監査人からの質問に対処したり、企業基準への準拠を内部で監視したりするのに非常に役立ちます。
