変更管理の基盤は構成管理が支えている
SW開発には、たくさんの落とし穴や地雷がある。
地雷原を走り抜けてゴールにたどり着くまでに慎重に進むと、時間切れになる。
アジャイル開発をRedmine上で実践して気付いたことは、変更管理プロセスを制御できるかどうかという観点がプロジェクト管理の殆どを占めていることだ。
仕様変更、タスクの優先度など、SW開発は路線変更が多く、それを制御するのが難しい。
顧客と合意した要件で開発してリリースしても、その後に膨大な改善要望がくる時すらある。
以下メモ書き。
【1】顧客要求を安易に受けてしまう人の良いSE- @IT自分戦略研究所
スコープのずれがコスト増にすぐにつながる。
アジャイル開発の肝はスコープ管理だ。
スコープ、コスト、納期の3つのバランスのうち、スコープでしか調整しづらいのがSW開発の最大の特徴。
スコープ管理の一例としては、CCBなどの変更管理会議で変更管理プロセスを制御することがある。
つまり、仕様変更など開発対象のスコープにつながるものは全て、顧客・SIer・開発者などのステークホルダーが全て集まって合意を経ないと、変更できないようにする。
しかし、僕の経験では、人数が多い会議ほど時間がかかるだけで何も決まらない。
CCBに出るステークホルダーは、業務やシステムに詳しい人とは限らない。
全員の合意を得るのは難しい。
大規模プロジェクトになるほど、ステークホルダーが増えるので、指数関数的に変更管理プロセスの難易度は上がる。
チケット駆動開発を応用しても、運用のハードルは高いだろう。
【2】【福井信二が語る:第3回】構成管理・プロジェクト管理の原理原則 - 組み込み開発 - Tech-On!
「構成管理とは同じ成果物の状態の変化を管理すること」というフレーズにアンテナが響いた。
SW開発では、一つの成果物が設計・開発・テストの工程を経るごとに、中身も状態も変化する。
記事で紹介されているように、成果物は段階的に詳細化されていくのだ。
要件は、設計工程で、システムの一つの仕様に落ちる。
そして、その仕様はプログラムで実装されて、初めて目の前で動く。
しかし、たくさんのテストをこなすたびに、一つの仕様には、たくさんのパッチが当てられて、ソースコードはどんどん複雑になっていく。
その過程を制御するのが構成管理だ。
つまり、要件からソースコードまで一貫したトレーサビリティを保証するインフラが構成管理。
しかし、Rational製品が提供するツールは重くて実用的ではない。
チケット駆動開発では、チケットとソースコードのリビジョンを紐づける運用がある。
その運用のおかげで、チケットという仕様に紐づくソースコードの履歴を辿ることができる。
逆に、ソースコードの変更履歴からチケットの仕様を探り出すこともできる。
僕が考えているプロジェクト管理サーバーでは、
HudsonビルドNo
→SVNリビジョン
→RedmineチケットNo
→TestLinkテストケースID
→TestLink要件ID
のトレーサビリティを作れるから、リリースされたモジュールにあるパッチから、要件まで辿ることができるはず。
上記の記事にあるベースラインの概念は、Redmineのバージョン、Subversionのリリースタグ、XPのイテレーション、Scrumのスプリントに相当するように運用できると思う。
変更管理と構成管理は密接に絡んでいる。
チケット駆動開発は、二つのプロセスをコントロールしやい開発プロセスだろうと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(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)
「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)
「構成管理・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)
コメント