Redmineチケットのステータスのネーミング方法
チケットのステータスのネーミングは結構悩みがち。
ラフなメモ書き。
【元ネタ】
Redmineのチケットのステータスは「~待ち」にすべき - nazonoDiary
Redmineのチケットステータス - gdgdでも生きてる
Redmineチケットのステータスをデフォルトで運用すると、うまく回らない時がある。
その理由は、今誰がチケットを担当すべきか、認識が一致しないから。
以前の僕も「検証中」「検証完了」「リリース完了」というステータスを作っていた。
だが、複数のチームで運用した所、特にリーダー層から不満が出てきた。
彼らとしては、「~前」というステータス名が欲しいらしい。
例えば、「検証前」なら、開発者が修正完了したがリーダーのレビューが終わっていない状態。
「リリース前」なら、リーダーの検証が終わったので、ライブラリアンが受入環境へリリースするのを待っている状態。
似たようなステータス名のルールとして「~待ち」がある。
そのような意見が出た理由は、「~完了」「~中」だと、誰がそのチケットを持つのか、分かりにくいから。
普通は、ステータスが変わったタイミングで、チケットの担当者が変わる。
開発者からリーダー、開発者からライブラリアンへ、など。
「検証前」「リリース待ち」のステータスならば、誰がそのチケットを担当すべきかすぐに分かる。
でも「検証完了」「リリース完了」のステータスならば、そのチケットにおける自分の作業は完了しているから、と放置してしまいがち。
チケットが更新されるタイミングはチケットのステータスが変わるタイミングが多く、ステータスが変われば、担当者も変わる。
僕は、XPのペアプロみたいに、チケットもペアで作業するものと考えているので、チケットのステータスが変わるタイミングが重要と思っている。
チケットはどんどん更新されるほど、開発は回る。
一つのソース、一つのドキュメントを複数人が作ってはレビューしたり、チェックすることで品質が上がっていく。
放置されるチケットは、ゴミ箱と同じ。
チケットをワインや日本酒のように寝かせても、品質は良くなるどころか、問題がどんどんやばくなって行く。
チケットが常に最新化されて、Closeに向けて進むように、ステータス名には細心の注意を払った方がいい。
【追記】
下記の意見を見つけた。
一つのチケットの作業量が多い場合や、一つのバグ修正を本番リリースするまでに検証手順やプロジェクトのルールが複雑な場合、子チケットでステータスごとのタスクを管理する方法もある。
例えば、仕様変更の要望を開発する時、親チケットにタスクの概要を書いておき、子チケットに「設計」「開発」「テスト」「本番リリース」「稼働後検証」などの子チケットをぶらさげて、子チケットにそれぞれの開発者をアサインする。
子チケットは「新規→担当→完了」の状態遷移のみで、開発者のToDoリストに近い。
親チケットでは、完了された子チケットの工程単位に、親チケットのカテゴリで「設計」「開発」「テスト」「受入検証」「本番リリース」「稼働後検証」などの工程ないしステータスをセットする運用がある。
この運用の利点は、ステータスの追加や変更がRedmineの全プロジェクトに影響をおよぼすため、そう簡単にカスタマイズできないのに対し、カテゴリは一つのプロジェクト内部で制御できるので、各プロジェクト単位で独自のステータスを設定する運用が可能なこと。
色んな運用方法があるだろうと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
コメント