TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine

「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。
チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか？

【参考】
第4回勉強会 - shinagawa.redmine

第4回shinagawa.redmine勉強会 : ATND

チケット駆動開発のアンチパターンの事例: プログラマの思索

チケット駆動開発を上手に運用するためのポイント: プログラマの思索

プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。

チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。
現場リーダーがWBSからチケットへ作業を登録する時、1～2週間のサイズのワークパッケージから、1～3人日程度のタスクまで分割しなければならないが、それができない時が多い。

例えば、タスクの分割が不十分なチケットが登録されて、実際に仕事してみると、当初の見積よりも大幅にオーバーしたりする。
あるいは、作業してみたら、仕様の不明点や設計の考慮漏れが判明したり、顧客へ確認すべき課題が出たりして、チケットを登録した時の状況から変わってしまう時もある。

でも、全ての作業があらかじめ見通せているわけではないから、あいまいなチケットを登録してしまうのは現実としてよくある。

かと言って、チケットが細かすぎると、チケットが乱発されてチームが混乱しやすい。
例えば、本番リリース直後に同一原因の障害を大量に登録してしまう。
あるいは、チケットが大量にあるために、優先度を付ける作業が雑になり、期日やリリースバージョンが未定の「今すぐ」チケットが溢れたりする。
すると、もはやチケットの重みで、開発チームの進捗が鈍くなる。
「チケットがゴミ箱」「チケットが不良在庫」になってしまうのはそんな状況。

【2】「チケットの完了条件」は、チケットの閉じ方に悩んでいる人に多い。

チケットを完了できたと思っても、マネージャがチェックしたり、設計者がレビューしてみたら、テストが不十分だったり、プログラムがコーディングルールに沿っていない、仕様書で説明不足な点がある、などの理由で差し戻しが多発する時がある。
まさに「モンスターチケット」。

また、タスクと課題、障害ではチケットの完了条件はそれぞれ異なる。
例えば、タスクの完了条件はプログラムの単体テストが終わることだが、課題は不明点が解決されるだけでなく課題をタスク化できて初めて完了になる。
つまり、ワークフローによって完了条件は大きく変わる。

かと言って、チケットの完了条件を厳しくすると、作業の途中で発覚した仕様の不明点や技術上の課題が原因で、進捗率が90％のまま停滞してしまう、とか。
「停滞したチケット」というアンチパターンがそんな状況に当てはまる。

【3】チケット駆動開発を推進すると、単なるタスクや障害だけでなく、課題やリスクも登録するようになる。
すると、どうしてもチケットが溢れて、チケットを更新して精査するだけで1日が終わってしまう。
チケット駆動でプロジェクト運営するならば、大量に湧いてくるチケットをいかに取捨選択して捌ききるか、が重要になってくる。

僕は、チケットが大量に登録されるのは良くない状況とは思わない。
むしろ、プロジェクトの現状をありのままに映し出す鏡だと思う。
例えば、デスマーチプロジェクトになれば、解決されるチケット数よりも登録されるチケット数の方が多すぎて、疲労感を感じる時が多いのではないか？
現場のプロジェクトでは、設計上の課題を解決したと思っても、技術上の課題が出たり、仕様の不明点が出たりして、次から次へと問題が出てくるものだ。

つまり、「チケットの粒度」と「チケットの完了条件」は、チケット駆動開発に由来する本質的な問題なのだと思う。

明日の第4回shinagawa.redmine勉強会 : ATNDでは、オープンディスカッションを設けて、参加者全員で「チケットの粒度」と「チケットの完了条件」について、参加者自らの経験と常識を元に、

どんな状況でどんな問題をどのように解決して「上手くいったか」
どんな状況でどんな問題を解決しようとして「失敗した」か

について議論します。
明日の勉強会をとても楽しみにしています。