チケット駆動開発が進むべき道 part3~BTSを中心に構成管理・テスト管理を含めたプロジェクト管理の枠組みを作る #tidd
チケット駆動開発について考えたことをメモ。
【元ネタ】
チケット管理システム比較
[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば
チケット駆動開発が進むべき道part1~ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索
チケット駆動開発が進むべき道part2~プロジェクト管理サーバーは開発チームの資産: プログラマの思索
チケット駆動開発を開発プロセスへ理論化できるか?: プログラマの思索
アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索
今年に入ってデブサミまでの2ヶ月間、チケット駆動開発に関する講演をしてきて、講演を聞いた人から指摘された内容から新たな問題意識を持っている。
一つ目は、SEA関西の世話人の方から、「Redmineによるタスクマネジメント実践技法」はあきぴーさんとさかばさんの共著だが、二人の観点の違いがはっきり出ている。さかばさんの方は、チケット駆動の導入が直接現場にもたらす効果に焦点をあて、その適用についても「効果があれば使えばよいし、かえって大変になりそうだったら、やめておけばいい」という現実的なスタンスだが、あきぴーさんの方は、チケット駆動開発を軸にして、さらに構成管理・テスト管理とも連動した、より大きなプロジェクト管理の枠組みの構築を目指されているようだ、と言われたこと。
二つ目は、かおるんさんから、Scrumは9つの規律、かんばんは3つの規律があるがチケット駆動開発には規律はあるのですか?と質問されたこと。
前者は、さかばさんの立場は下記の記事で既に説明されている。
[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば
僕の理解では、ソフトウェア工学は正しく使わなければ欲しい結果が得られないこと、つまりコンテキスト(問題の文脈)を明確に定めなければソフトウェア工学のノウハウを適用しづらいこと、そして、チケット駆動開発は現場のソフトウェア工学ゆえにコンテキストが現場にマッチしやすい特徴がある、と認識している。
ソフトウェア開発におけるコンテキストの話は森崎さんが最近よく話されているが、僕の認識では、ソフトウェア開発の現場で現れる諸問題を明確に区別して、それぞれの問題に対して最適な解決方法を見出す話なのだろうと推測している。
そして、コンテキストの話は最終的にはパターンランゲージでより包括的にまとめることができると思う。
何故なら、パターンとはコンテキスト(問題)に対する一つの解決方法をボトムアップで吸い上げたモデルだからだ。
例えば、GoFのデザインパターンは、オブジェクト指向プログラミングにおけるコンテキストの諸問題を解決する一つのアイデアで、とても有用だ。
実際、Stateパターン、Strategyパターン、Adapterパターンなどはどのような場面で使うと有効か、そして使いすぎるとどんな副作用があるのか、まで詳しく解説してくれている。
つまり、ソフトウェア工学のコンテキストの話は、パターン(成功例)やアンチパターン(失敗例)で綺麗にまとめられるはずだと思う。
だから、僕もチケット駆動開発のプラクティスをまとめる時、パターンカタログを作って「Redmineによるタスクマネジメント実践技法」にもまとめている。
その方がパターンがどんな問題に対して有効で、そのパターンの本質は何なのか、をよりはっきりさせてくれるからだ。
SEA関西の世話人の方の話を聞いて、さかばさんの観点がよく理解できたと共に、僕がやりたいことは、チケット駆動開発をベースとして、BTSを中心とした構成管理やテスト管理を含むプロジェクト管理の枠組みが作りたいのだと改めて自覚した。
それは最終的には、プロジェクトリーダーの意思決定をサポートするプロジェクト管理サーバーの概念を明確に実現することだ。
だから、最近はRedmineと構成管理、ビルド管理ツールHudsonとの連携に興味を持っている。
そのアイデアは、チケット管理システム比較に詳しく書いた。
言いたいことは、Redmineのプロジェクト・バージョン・チケットという概念が構成管理のコードライン(trunk, branch)、タグ、リビジョンと対比でき、更にはHudsonのジョブ、ビルド番号、ビルドログと対応付けることができるということ。
その対応づけによって、チケット駆動開発に現れる諸概念をソフトウェア工学の概念で補強できるし、現場で運用される構成管理やビルド管理、リリース管理、変更管理などのプロセスが何故そのように厳格に運用すべきなのかという理由を明確に理論付けできる。
僕がRedmineでチケット駆動開発を実践して改めて痛感したことは、アジャイル開発は手抜きの開発ではないことだ。
アジャイル開発は現物主義であるがゆえに、無駄なドキュメントや無駄な作業を嫌う。
だからと言って、すべてのドキュメントや厳格なワークフロー管理が軽視されていいわけではない。
やるべきプロセスを省略すると、本番リリース後の障害によって、手痛い仕打ちを食らう。
例えば、バグ修正とバグ検証は担当者を変えずに品質チェックがそのままスルーしてしまうとか、バグ修正後のコードレビューを省いてしまうなどのプロセスがあげられる。
バグ検証や同類バグ調査、コードレビューと言うプロセスを省くと、ファウラーの言う技術的負債として必ず現れて、プロジェクトを混乱させる原因になるからだ。
チケット駆動開発の利点の一つは、厳格なワークフロー管理、開発プロセスの管理を透過的にサポートしてくれること。
バグのチケットは複数人で切り替えて成果物をお互いにチェックし合うワークフローにすればいい。
バグのチケットを起票したら、開発者は同類バグ調査を必ず行ってから修正すればいいし、テスト担当者はデグレしていないか、他の機能に影響していないかの観点も含めてテストするように運用すればいい。
つまり、チケット駆動開発によってアジャイル開発に規律や組織力を導入することができる。
しかも従来のプロセスのようなExcelを印刷して承認する時に判子を押すような無駄なワークフローを排除して、必ずチケットに作業履歴が残るような仕掛けがある。
アジャイル開発にあるコミュニケーションや人間重視という利点をそのまま生かしながら、規律や組織力を導入してスケールアップしやすくできるはずだ。
二つ目のかおるんさんの指摘はまさにその通りで、チケット駆動開発の規律は何か、という問題は僕もまだ解決出来ていない。
最終的には数学の公理体系のように、最小の個数の規律(公理)から他の規律やプラクティス(定理)が導かれるような体系をチケット駆動開発にもたらしたいと思っている。
僕の直感では、「No Tikcet, No Commit!」というたった一つの規律でチケット駆動開発の全てのプラクティスを導出できると思っている。
実際、「プロジェクト内部の作業はチケットを起票してから始める」というTicket Firstという規律も、プロジェクト内部の作業は必ず成果物が求められるので、チケット無しで成果物を作ってはならないという規律から演繹できる。
又、BTSバージョンをリリース予定バージョンに同一視することでイテレーションに対応付ける小規模リリースというプラクティスも、成果物を作るチケットをバージョンというリリース単位でグループ化し、そのバージョンを2~4週間でリリースすれば、自然にアジャイルな開発として実現できる。
更に、BTSプロジェクトをビルドモジュールに同一視することで並行開発を実現するプラクティスも、プロジェクト内部の作業を表すチケットを開発チームやコンポーネントの単位でグループ化すれば、自然にビルドモジュールとBTSプロジェクトが紐づいて、それがリリース単位になる。
チケット駆動開発の他のプラクティスも同様に、最小の個数の規律から全てのプラクティスを演繹できるはずだ。
そうすれば、最低限の規律を守ってチケット駆動開発を実践すれば、自然にアジャイル開発を運用できて、その裏では厳格なプロセスが動いているという仕組みを作れるだろう。
今後はこの辺りをもっと理論的にまとめてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「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)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント
うーん。ちょっと違いますかね。ゴールは同じで、どこまで言うかという違いですね。
- あきぴーさんは見えていることを言っている。
- 私は経験できたことを言っている(たまにはみ出す程度)。
という感じでしょうか。
それは両方があることで価値が高くなると思って、そういう立ち位置を守っています。
ただ、規律に関しては、シンプルな規律から演繹するのは困難で、「現場の」などの文脈や戦略から決まるものも出てくると思います。
投稿: さかば | 2011/03/21 22:22