Edited at

チケットの状態遷移 - 担当者とステータスを「いつ」「誰が」変えるのか

More than 1 year has passed since last update.


この文書について

BacklogやRedmine,JIRAなど

IssueTrackingSystem(ITS)を使って複数人数でタスクを進める際のルールの一例を紹介します。

ITSを使っていると、


  • 「1つのチケットがなかなか終わらない」

  • 「終わったと思っていたチケットが再オープンされる」

などの問題が起きることがあり、

それをどうやって回避するか、がこの文書の焦点となります。

(チケット管理のルールなので、対象となるITSの種類は問いません。)


チケットが終わらない原因

自分がこれまでに見てきた「終わらない/再オープンされるチケット」では


  • 「成果物・完了条件」の認識があっていない

  • 作業担当者が独断でチケットをクローズしている

という症状がよく見られます。

その原因としては、


  • 作業開始前の成果物・完了条件の「認識合わせ」

  • 依頼者による「確認」

が足りていないことが多く、上記の実施が対処策となります。

以降ではその対処策を具体化するにあたり、


  • チケットは何を表現しているのか

  • チケットの状態遷移


    • タスクの発生から完了がどのようにチケットで表現されるのか



  • チケットの担当者とステータスをいつどのように変えるのか

を説明します。


チケットは何を表現しているのか

チケットは以下のような情報を持ちます。


  • 目的


    • 目的に至ったことを示す具体的な完了条件がある



  • 期限

  • 担当者


    • 担当者は途中で変わることもある



  • 状態


    • 着手していない、途中、終わった



「1つのチケット = 1つのタスク = 小さなプロジェクト」

であると著者は考えています。


チケットの状態遷移

プロジェクトが 見積もり -> 発注 -> 着手 -> 納品 -> 検収 -> 完了 とフェーズが進むように、チケットでは状態が変わります。

大抵のITSにおいては以下の4状態がデフォルト設定になっていることが多いです。

新規 -> 処理中 <-> 処理済み -> 完了

自分の携わるプロジェクトでは以下のような意味で捉えています。


  • 新規


    • タスクが作られ、未着手



  • 処理中


    • 担当者がアサインされ、作業中



  • 処理済み


    • 担当者の作業が終わり、目的に至ったかの確認中



  • 完了


    • 目的が果たされたことが確認され、タスクは終わった



「処理済み」 を 「完了」 にするのは、プロジェクトにおける検収と同様です。

なので、チケットを完了にするのはタスクを依頼した人となります。


チケットの担当者とステータスをいつどのように変えるのか

作業担当者のタスク習熟度に応じてチケットを作る人が変わります。

最初のうちは依頼者が作り、習熟してきたら作業担当者に作ってもらうようにします。


依頼者が作るケース

依頼者がチケットを作り、完了条件をチケットに明記します。

TicketStateTrasition1.png

作業担当者が意識することは以下となります


  • 着手時


    • チケットの状態を「処理中」にする



  • 成果物ができたとき


    • チケットの状態を「処理済み」にする

    • チケットの担当者を「依頼者」にする



経験が浅い場合、完了条件の定義が困難のため、

まずはタスクの実施だけに専念してもらいます。


作業担当者が作るケース

依頼者がチケットを作っていると、どうしても

「依頼者のチケット作成スピードの限界」 = 「チームの作業スピードの限界」

になります。

なので、作業担当者がタスクに慣れてきたら、

依頼者が作業者にタスクを伝え、チケットは作業者が作ります。

TicketStateTrasition2.png


この他の起票ルール

テストフェーズにおいて、テスターとエンジニアがバグチケットをやりとりする場合のルールは以下にあります。

https://github.com/nave-m/ticket-template/tree/master/rules/test