Redmineを使って気付いたことpart6~チケットの発生源
Redmineでチケット駆動開発を始めて、チケットの発生源について考えてみた。
以下ラフなメモ書き。
【1】チケット駆動開発では、タスクをチケットに起票してから作業を始める。
イテレーションに含まれるチケットは限界があるから、1イテレーションで実現できる機能は限定される。
しかし、1イテレーションに入り切らないぐらい膨大なタスクが発生する時がある。
そうなってしまうと、もはやチケット駆動開発だろうがアジャイル開発だろうが、タスクは発散しがちでプロジェクトは壊れた飛行機のようにふらついているだろう。
そうならないために、プロジェクトリーダーは、チケットの発生源をいつも気にする必要がある。
チケットの発生源はタスクの発生源であるから、タスクを増やさないためには何を処方したらよいか、というリスク管理につながる。
【2】チケットの発生源は、SW開発の工程によって異なる。
例えば、動くプログラムも無い状況で開発し始めた場合、殆どのチケットは要件定義書に基づいた機能の新規実装であり、おそらくスケジュールに引かれたWBSから作られるだろう。
この場合のチケットのトラッカー(種類)は、新規実装とか、エンハンスメントとか呼ばれるものに相当するだろう。
発生源は、要件。
つまり、ウォーターフォール型の開発に似ている。
あるいは、動くプログラムが殆ど出来上がり、結合テストからシステムテストに至るまでの工程では、TestLinkによるNGのテストケースがRedmineチケットの発生源になる。
つまり、テストしたらNGでバグが出たら、チケットをバグ報告票として起票して管理する。
この場合は、まさにバグ管理システムとしてRedmineを使っているだろう。
発生源は、テストケース。
更に、1次開発のリリース後、システムが本番運用されると、パスワードを忘れた、とか、あの業務をこの画面でやると動作がおかしい、などの問合せが顧客から来る。
すると、それぞれの問合せに対して、チケットへ起票して、一時的な対策を施したり、根本原因を調査して是正対策を行うなどの処置が必要になってくる。
発生源は、インシデント。
現在の自分の環境では、TestLinkからRedmineへの連携はスムーズのため、バグチケットの発生源がTestLinkのどのテストケースなのか、は追跡できる仕掛けになっている。
これによって、「ソース→SVNリビジョン→Redmineチケット→TestLinkテストケース」まで追跡できるから、その発生源の付近に他にどれだけのチケットがあるか、とか、発生源を解決する別の対処方法を更にチケットへ起票する、などの対策を取れる。
【3】チケットの発生源とトラッカー(チケットの種類)は密接に関係する。
要件、テストケース、インシデントの発生源に対し、それぞれのトラッカーがマッピングされて、それぞれのチケットは特有のステータスの遷移で制御される。
おそらく、発生源がテストケースの場合は追跡のインフラを作るのは簡単。
何故なら、テストNGによるバグ解決フローは、バグ管理システムの基本フローそのものだから。
むしろ難しいのは、要件管理とインシデント管理。
XPのタスクカードがチケットであるならば、要件管理は結局、XPのストーリーカードは構成管理インフラのどの機能へ配置されるべきか、という問題に辿り着く。
TestLinkの要件管理機能が使えるならば、「ソース→SVNリビジョン→Redmineチケット→TestLinkテストケース→TestLink要件」まで追跡可能で、要件カバレッジという新しい観点でシステムの品質をチェック可能になる。
インシデント管理は、チケットの状態遷移が異なるため、どのようなワークフローで制御すべきか、という問題に辿り着く。
更に、インシデントから抜本的対策が必要だと意思決定した場合、新たな変更要求が生まれ、そこから2次開発につながっていくだろう。
つまり、インシデント→変更要求→新規実装のような流れ。
従って、親チケットはインシデント又は変更要求、子チケットは複数の新規実装、のようなチケットの親子関係が発生する。
子チケットにある全ての新規実装のチケットが完了して初めて、親チケットの変更要求は終了になるなどの制約条件が更に発生する。
上記の例のように、チケットの発生源は多岐に渡る。
チケットからその発生源へ追跡できる環境があれば、チケットに書かれた作業の根本的な対策は何か?を担当者自身が考えるきっかけになりうる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想(2022.02.18)
「Redmine」カテゴリの記事
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
- RedmineJapanで参考になった講演資料を読み直す(2022.03.06)
「TestLink」カテゴリの記事
- TestRailの感想(2021.06.23)
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
コメント