事象にユニークなIDを採番する利点
RedmineやTestLinkなどのツールを駆使してプロジェクト運営すると、チケット、バグ、テストケース、要件などSW開発に関する事象にユニークなIDが振られるのに気付く。
すると、チーム内でこんな会話があって、お互いに事象を認識して共有しやすくなっているだろう。
今日は、チケットxxとyyのいずれを最優先で行うか?
今、チケットzzの作業状態はどうなっている?
このSVNリビジョンrrの修正理由は、チケットIDがxxにある仕様から来たんだね。
今、あのバグxxのステータスはどうなっている?
テストケースは何番まで実施した?
そのテストケースyyは、要件IDがxxから作りました。
要件IDがxxをテストするテストケースが漏れていますね。
その仕様は、要件ID xxから来ているから、勝手に修正してはいけないね。
過去を思い出そう。
Excelでバグ管理していた時、きちんとしたワークフローを踏んだ開発チームでは、バグ管理IDを振るための特別なExcelシートがあった。
そのExcelシートで、バグ管理IDをユニークに作り、それから障害報告票を作成し始める。
そんなワークフローにした理由は、IDを振ることで、バグの症状や原因、状況を最初から説明する必要がなくなるからだ。
IDが振られていなければ、MM月dd日に見つけたバグですが、とか、機能AのボタンBのバグでYYYとか、などのように、事象を逐一説明しなければならない。
1日でバグが10件以上も多発した場合、チーム内で上記のコミュニケーションを取るのは至難の業だ。
同様の事は、チケット駆動開発におけるチケットIDでも同様。
君が担当している機能Aの仕様変更はどうなった?という質問をしたい時、仕様変更の中身を説明しないといけない。
納期が迫ってタスクがどんどん溜まっていく時、タスクを説明するだけでかなりの労力をすり減らすだろう。
事象にユニークなIDを振ることで、互いのコミュニケーションのロスが減る。
だが、更なる利点は、変更管理がやりやすくなることだ。
チケット駆動開発では、チケット無しのソース変更を認めないルール(チケット・ファースト)があるので、ソースのリビジョンには必ずチケットIDが振られている。
つまり、ソースの修正理由をチケットに追記することができる。
だから、過去のバグ修正やパッチを追跡できるインフラが自然に整う。
更に、バグ管理IDと失敗したテストケースID、更には要件IDが紐づいていれば、最終的に、ソースの修正理由を要件IDまで辿ることができる。
最近気付いたことは、要件IDを振られた要件定義書を作らずにSW開発を始めているプロジェクトが殆どであることだ。
すると、受入テストで使うテストケースを作る時に、そのテストケースは要件に基づいた業務フローで作られているのか?という保証をするのが非常に難しくなる。
受入テストは要件定義のテスト工程であるから、テストの元ネタとなる要件として揃っていなければ、テストケースのレビューもできない。
IDを振るという行為には、事象をユニークに定めるという基本動作が含まれている。
そこから、IDに重複がなく漏れもないということを自然に考えるようになる。
つまり、要件や仕様がダブりなく漏れもないようにMECEで考えることを自然に行っているはず。
IDを振る行為には、コミュニケーションロスをなくすだけでなく、変更管理を容易にするだけでなく、IT技術者としての基本動作も含まれているような気がするのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
コメント