TiDDを実践して気づいたことpart8～事象にユニークなIDを採番するとコミュニケーションが促進される

チケット駆動開発を運用して、チームとして仕事がスムーズに進むようになったという記事を見つけたのでメモ。

【元ネタ】
チケットの書き方（我流） - 地平線に行く

事象にユニークなIDを採番する利点: プログラマの思索

紙やExcelによる管理が残っている工程: プログラマの思索

事象にユニークなIDを採番する最大の利点は、コミュニケーションを促進してくれることだ。
チケット駆動開発を運用していると、あのバグはXXのチケットです、今はタスクYYをやっています、チケットZZをコミットしたから検証お願いします、などのコミュニケーションがあちこちでかわされる。

プロジェクト内部の作業は全てチケットを起票して開始されるので、プロジェクト内部で発生した事象は全てチケットを経由するから、メンバーの認識は必ず一致する。
作業履歴や変更理由はチケットを見れば分かるから、作業の不明点を質問するレベル上がる。

事象にユニークなIDが振られていないと、事象の発生日や発生事由などを最初から逐一説明しないといけないので、お互いのメンバーの認識もずれやすい。

Excelで管理していた時は、障害報告票の番号をユニークにするために、わざわざ採番用のExcelシートから発行して、起票していたりしていた。
あるいは、リリースするビルドモジュールのタグをExcelのシートから採取して、ユニークなリリース番号を作る運用をしたこともあった。
いずれにしても、ユニークな番号を採取するために、Excelの場合はかなり苦労していたわけだ。

だが、ソフトウェア開発の全ての作業にユニークなIDを振って作業しているだろうか？
チケット駆動開発をやっているなら、チケットが障害も要望も作業も全て記載されているから、タスクにはIDが付いているだろう。
しかし、テストケースや仕様、要件にIDは振られているだろうか？
設計書を書いているメンバーは多いだろうが、仕様にIDを振っているか？
要件定義書を書いているなら、要件IDを振っているか？

要件IDを振っているからこそ、テストケースと要件を紐づけて要件カバレッジを行うこともできる。
要件IDがあれば、要件から仕様、ソース、ビルドモジュールまでのトレーサビリティも可能になる。

ソフトウェア開発の全ての成果物にIDを振る事は結構重要だと思う。
ユニークなIDがあるからこそ、成果物の質もコミュニケーションの質も上がるはず。