ワークフロー

Topikaは、カスタマイズ可能でビジネスルールに沿った柔軟なワークフローを持っています:
  • 各トピックは、システムが生成する一意な識別番号を持っています

  • 監査機能 – トピックに対する各操作は履歴が取られます

  • 一度登録されたレコード（トピック）のディスカッション履歴は、編集／削除することはできません

  • トピックは、常に一人の担当者が割り当てられます

  • トピックは、解決／対応するまでクローズされません

  • クローズされたトピックを編集するには再オープンしなければなりません

  • 各トピックのステータスは、トピックがワークフローを流れる間に自動的に設定されます
    OPEN – RESOLVED - CLOSED

    • 例えば、次のような順番でステータスが遷移します
    1. テスト担当者が新規のバグを登録（OPEN）し、開発者が修正するために割り当てられます

    2. 開発者がバグを解決し、そのバグのステータスが解決（RESOLVED）に変わります

    3. Topika システムは、バグが解決（RESOLVED）されると、自動的に担当者を最初に登録（OPEN）した人（通常はテスト担当者）に変更をします。この状態でのバグのステータスは、完了（CLOSED）ではなく、解決／確認待ち（RESOLVED）となっています。このステータスは、“OPEN”だが “ACTIVE（活性）”では無い事を表します。これは、バグの登録者（この例ではテスト担当者）に正しく修正されているかテストし、思惑通りの修正となっているかを確認する機会を与えます。もし、修正内容に納得がいかなければ、当該バグを差し戻し（REACTIVE）します。そうすると、 Topikaシステムは、解決（RESOLVED）した開発者を自動的に担当者として割り当てます

    4. バグの修正内容が確認され、バグの登録者が修正内容を受け入れた場合、そのバグのプロセスは、終了し、ステータスを“CLOSED”に変更します。バグは、その登録者か管理者によってクローズされます

    5. もし、後日、そのバグの修正が完全ではなかった場合、そのバグは、再度オープンされます

Topika は、登録されたトピックを一旦、マネージャーに割り当て、マネージャーが各担当者に振り分けるといった、異なる形式のワークフローも設定可能です。
すべてのトピックをプロジェクトマネージャー経由とするセットアップを行った場合、“新規登録時の割り当てを行う”権限をマネージャーのみに有効にする必要があります。そうすることで、システムは常に新規登録されたトピックをマネージャーに割り当てるようになります。マネージャーは、担当者に割り当てるために“レコードの対応済み設定”権限も持ちます。マネージャーのみが“担当変更”できる様になっている事を確認してください。
次の理由により、トピックの新規登録者は、“他のメンバーへ担当者を設定する権利”を持つべきではありません:
もし、トピックの登録者が“他のメンバーへ再割り当て”する権限を持っていると、システムは、対応済みにする権利を持つすべてのメンバーリストを表示し、登録者はその中から担当者を選択しなければならなくなります。逆に“担当者を設定する権利”を持っていなければ、システムが自動的に“担当者を設定する権利”を持ったメンバーに割り当てます。

Topikaのワークフローは、以下の図の様に構成されています:
work_flow

実業務でのワークフロー適用例）
  1. Ａさんがプロジェクトαでバグを見つけました。Ａさんは、バグ票（トピック）を登録（OPEN）し、Ｂさんに割り当てました。Ｂさんは、メールでバグが割り当てられた事を通知されます

  2. Ｂさんは、バグを解析するのに情報が不足している事が判りました。Ｂさんは、より詳細な情報が必要である旨コメントし、Ｂさんに再割り当てしました。Ａさんは、メールでバグが再割り当てされた事を通知されます

  3. Ａさんは、要求された詳細情報を追記し、再びＢさんに割り当てました。Ｂさんは、再度、メールで通知されます

  4. Ｂさんは、バグを修正し、バグ票を解決済み（RESOLVED）とします。Topikaシステムは、自動的にＡさんに再割り当てし、メールで通知します

  5. Ａさんは、バグが解決済みとされた事を確認し、実際にプロジェクトα上の問題点が解決されている事を確認します。しかし、Ａさんは、問題点がある状況下では発生している事を発見します。そのため、バグ票を差し戻し（REACTIVE）ます。Topikaシステムは、自動的にＢさんに再割り当てし、メールで通知します

  6. Ｂさんは、問題の解決方法を思いつきますが、時間が取れないため、そのアイデアをバグ票にコメントします。さらに、Ｂさんは、このバグがプロジェクトβに起因する物と判断し、バグ票をプロジェクトβへ移動し、Ｃさんに担当者を変更します。同時にこのバグに関するメール通知先から自分を除外しました。ＡさんとＣさんは、それぞれ二つのメール通知を受け取ります。一つは、バグ票の移動に関して、もう一つはバグ票の担当者変更についてです

  7. その後、Ｃさんは、バグを修正し、バグ票を解決済み（RESOLVED）とします。Topikaシステムは、自動的にＡさんに再割り当てし、メールで通知します

  8. Ａさんは、最終的なテストを行い、修正が正しく行われた事を確認します。Ａさんは、バグ票をクローズ（CLOSE）します。Ｃさんは、クローズされた事をメールで通知されます

  9. 以降、いつでも、まただれでも、今回の修正が完全でなかった事を発見した時点でバグ票を再オープン（REOPEN）する事ができます。Topikaシステムは、再オープンしたユーザーの初期値設定からリストを作成し担当者を選択できるようにします。“再オープン”の仕組みは、“新規登録”と同じです

上記で説明した基本的な動作に加えて、トピックの保守は、“権限”と“プロジェクト設定”によって運用されます。
プロジェクト選択リストは、重要なナビゲーションツールです。プロジェクト選択リストは、Topikaページの上方の機能選択タブの上にあります。ドロップダウンリストには、現在のユーザーがアクセスできる全てのプロジェクト名が含まれます。このプロジェクト名の選択により、一覧表示などにおける即時的なフィルター機能が実現されます。