TiDDを実践して気づいたことpart8~事象にユニークなIDを採番するとコミュニケーションが促進される
チケット駆動開発を運用して、チームとして仕事がスムーズに進むようになったという記事を見つけたのでメモ。
【元ネタ】
チケットの書き方(我流) - 地平線に行く
紙やExcelによる管理が残っている工程: プログラマの思索
事象にユニークなIDを採番する最大の利点は、コミュニケーションを促進してくれることだ。
チケット駆動開発を運用していると、あのバグはXXのチケットです、今はタスクYYをやっています、チケットZZをコミットしたから検証お願いします、などのコミュニケーションがあちこちでかわされる。
プロジェクト内部の作業は全てチケットを起票して開始されるので、プロジェクト内部で発生した事象は全てチケットを経由するから、メンバーの認識は必ず一致する。
作業履歴や変更理由はチケットを見れば分かるから、作業の不明点を質問するレベル上がる。
事象にユニークなIDが振られていないと、事象の発生日や発生事由などを最初から逐一説明しないといけないので、お互いのメンバーの認識もずれやすい。
Excelで管理していた時は、障害報告票の番号をユニークにするために、わざわざ採番用のExcelシートから発行して、起票していたりしていた。
あるいは、リリースするビルドモジュールのタグをExcelのシートから採取して、ユニークなリリース番号を作る運用をしたこともあった。
いずれにしても、ユニークな番号を採取するために、Excelの場合はかなり苦労していたわけだ。
だが、ソフトウェア開発の全ての作業にユニークなIDを振って作業しているだろうか?
チケット駆動開発をやっているなら、チケットが障害も要望も作業も全て記載されているから、タスクにはIDが付いているだろう。
しかし、テストケースや仕様、要件にIDは振られているだろうか?
設計書を書いているメンバーは多いだろうが、仕様にIDを振っているか?
要件定義書を書いているなら、要件IDを振っているか?
要件IDを振っているからこそ、テストケースと要件を紐づけて要件カバレッジを行うこともできる。
要件IDがあれば、要件から仕様、ソース、ビルドモジュールまでのトレーサビリティも可能になる。
ソフトウェア開発の全ての成果物にIDを振る事は結構重要だと思う。
ユニークなIDがあるからこそ、成果物の質もコミュニケーションの質も上がるはず。
| 固定リンク
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
コメント