チケット駆動開発の適用範囲part5~どの工程をカバーするのかという質問
チケット駆動開発を実践していると話すと、チケット駆動開発ではどの工程をカバーしているのですか、という質問をよく受ける。
考えたことをラフなメモ書き。
【1】「チケット駆動開発ではどの工程をカバーしているのですか」という質問は、マネージャやリーダーからよく聞かれる。
彼らの意図としては、ウォーターフォール型開発において、チケット駆動開発がどの工程にうまくはまるのか、どんな利点があるのか、を知りたがっているようだ。
特に、開発工程のタスク管理やテスト工程の障害管理以外に、要件定義や設計の工程でも使えるのか、という疑問があるらしい。
僕は、チケット駆動開発は特定の工程をサポートするわけではなく、プロジェクト管理全般をサポートしている、と回答するようにしている。
チケット駆動開発は本来、ソフトウェア開発のタスク管理をチケット管理に置き換えることで、プロジェクト管理をマネージャのようなベテランだけでなく、1年目の開発者でも体験できるような仕組みだと思っている。
ソース管理やビルド管理とチケット管理が連携することによって、チケットを起点としてソース修正からモジュールのビルド、リリースに至るまで、一括管理できる利点がある。
つまり、チケット駆動開発は、ソフトウェア開発のインフラに相当する側面がある。
【2】チケット駆動開発を開発者の観点で見ると、ToDoリストの管理に近い。
例えば、Redmineのチケット管理もそうだし、GitHubやBitbucketのIssue管理も同様だろう。
すると、ソースという成果物をソース管理のリポジトリで管理する時に、チケットに仕様変更や要望、障害報告を書いておけば、チケットが起点となってソースが修正されてブラッシュアップされていく。
つまり、チケットとソースが連携することによって、成果物と仕様変更を一括管理できる。
ここから「No Ticket, No Commit」という運用ルールが生まれている。
開発者の観点におけるチケット管理の運用においては、設計だけの工程、開発だけの工程、テストだけの工程はありえない。
一つのチケットで、どのような仕様で確定したのか、どのように修正したのか、リリース後のユーザの評価はどうなのか、という履歴が全て残る。
その意味では、チケット駆動開発はすべての工程をサポートしている。
【3】チケット駆動開発を管理者の観点で見ると、プロジェクト管理として使いたい要望が多い。
マネージャやリーダーとしては、進捗管理、品質管理、課題管理をRedmineのようなチケット管理ツールで、プロジェクトに関わる全てのアクティビティを管理したいのだ。
そうすれば、Redmineのチケットを常に監視することによって、プロジェクトがどんな状況にあるのか、をリアルタイムに把握することができる。
彼ら管理者としては、チケット管理ツールの進捗管理機能を強化して欲しいという要望が多い。
例えば、Redmineの最新版2.3においては、ガントチャートにMS ProjectのFS関係(先行・後行く)やイナズマ線を表示する機能が追加されている。
Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog
上記の記事には「イナズマ線描画機能は 伊藤忠テクノソリューションズ株式会社 (CTC) 様のご協力により実現しました」という文言が記載されていて、大手SIの管理者がRedmineのガントチャートをもっと強化して欲しい要望を持っていた事実を示していると思う。
管理者としては、工数管理もチケット管理で代用したいものだ。
「チケット無しの作業は不可」(No Ticket, No Work)を運用しているならば、チケットに必ず予定工数と実績工数が記録されるので、後から集計可能になる。
そうすれば、EVMの仕組みを使って、CPIという開発ペースを計算して総コストを予測することも可能になる。
管理者の観点では、チケット駆動開発はメトリクス収集ツールという側面がある。
管理能力の優れたマネージャは、単なるプロジェクト運営だけでなく、プロジェクト終了後にメトリクスをきちんとまとめておいて、そのノウハウを他のプロジェクトへ適用したり、自分の研究材料に使ったりしている。
つまり、できるマネージャはきちんとPDCAサイクルを回していて、特にCheck、Actionの部分が優れている。
【4】チケット駆動開発の弱点はいくつかある。
まず、チケット集計というビューが弱い事実があると思うが、個人的には、RedmineのようなRailsアプリならば、不足した機能はRubyで実装すれば良いという問題に置き換えられると思っている。
プロジェクト管理の問題をプログラミングの問題にすり替えることによって、もっと色んな手法が試されるべきだと思う。
また、チケット駆動開発のロールは管理者・開発者・報告者という障害管理ツールの名残りがあるために、Scrumのようにユーザを巻き込んで、開発チームとユーザ、プロジェクトマネージャのバランスを保つ仕掛けは実装されていない弱点がある。
でも、顧客自身に仕様追加や障害報告をチケット登録するような運用ができるならば、チケット上で顧客と開発チームが相互対話する環境が整うので、顧客を巻き込んだ開発スタイルは可能のはずだ。
ITILのようなインシデント管理・問題管理・変更管理プロセスに当てはめれば、多分うまくいく部分があると思う。
それから、チケット駆動開発はアーキテクチャ設計やテスト管理には有効ではない。
テスト管理にはTestLinkなどのようなテスト管理ツールが必要だろうと思っている。
アーキテクチャ設計は、プロジェクト管理とは別のスキルが必要だ。
最近アジャイル開発がソフトウェア開発で有効と思われている理由の一つは、ソフトウェアのアーキテクチャ設計で絶対のベストプラクティスが存在しないために、その時代の技術を使って試行錯誤しながら作っていかざるを得ない事実があると思う。
つまり、アーキテクチャ設計ないしソフトウェア工学が分野として不十分ないし弱いために、アジャイルという開発プロセスでその弱さを代用している面があると思う。
その辺りはもう少し考えてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(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)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント