TiDDを実践して気づいたことpart8~事象にユニークなIDを採番するとコミュニケーションが促進される
チケット駆動開発を運用して、チームとして仕事がスムーズに進むようになったという記事を見つけたのでメモ。
【元ネタ】
チケットの書き方(我流) - 地平線に行く
紙やExcelによる管理が残っている工程: プログラマの思索
事象にユニークなIDを採番する最大の利点は、コミュニケーションを促進してくれることだ。
チケット駆動開発を運用していると、あのバグはXXのチケットです、今はタスクYYをやっています、チケットZZをコミットしたから検証お願いします、などのコミュニケーションがあちこちでかわされる。
プロジェクト内部の作業は全てチケットを起票して開始されるので、プロジェクト内部で発生した事象は全てチケットを経由するから、メンバーの認識は必ず一致する。
作業履歴や変更理由はチケットを見れば分かるから、作業の不明点を質問するレベル上がる。
事象にユニークなIDが振られていないと、事象の発生日や発生事由などを最初から逐一説明しないといけないので、お互いのメンバーの認識もずれやすい。
Excelで管理していた時は、障害報告票の番号をユニークにするために、わざわざ採番用のExcelシートから発行して、起票していたりしていた。
あるいは、リリースするビルドモジュールのタグをExcelのシートから採取して、ユニークなリリース番号を作る運用をしたこともあった。
いずれにしても、ユニークな番号を採取するために、Excelの場合はかなり苦労していたわけだ。
だが、ソフトウェア開発の全ての作業にユニークなIDを振って作業しているだろうか?
チケット駆動開発をやっているなら、チケットが障害も要望も作業も全て記載されているから、タスクにはIDが付いているだろう。
しかし、テストケースや仕様、要件にIDは振られているだろうか?
設計書を書いているメンバーは多いだろうが、仕様にIDを振っているか?
要件定義書を書いているなら、要件IDを振っているか?
要件IDを振っているからこそ、テストケースと要件を紐づけて要件カバレッジを行うこともできる。
要件IDがあれば、要件から仕様、ソース、ビルドモジュールまでのトレーサビリティも可能になる。
ソフトウェア開発の全ての成果物にIDを振る事は結構重要だと思う。
ユニークなIDがあるからこそ、成果物の質もコミュニケーションの質も上がるはず。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント