ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかけるのではないか？という記事を見つけたのでメモ。

【元ネタ】
構成管理手段が作業手順を定義している ? tune web

InfoQ: 分散バージョン管理システムの詳細なガイド

(引用開始)
構成管理ツールと言うのは単に機能を提供するだけではなくて、ソフトウェアの手順を暗黙的に決めてしまいます。
逆に考えると、新しいツールを使うときは新しいやり方を最大限活かせるように作業手順を作りなおさないとダメでしょうね。
(引用終了)

BTS、SCM(バージョン管理)、CI(ビルド管理）という3種の神器は、ソフトウェア開発に何をもたらしたのか？

アジャイル開発、派生開発、ソフトウェア製品ファミリー開発のいずれも、高度な構成管理技術を要求する。
高度な構成管理のインフラがなければ、いくらアジャイルを唱えた所で、絵に描いた餅に過ぎない。
高度な構成管理のインフラがなければ、オリジナルの製品から移植したり、大幅な機能を追加したり、複数の似たような製品を短期間に作り出したりするのは、規模が大きくなるほどいずれ困難になる。

アジャイル開発の最大の特徴である頻繁なリリースを実現するには、優れた構成管理技術が前提条件にある。
技術力がなければ、アジャイル開発も派生開発も製品ファミリー開発も安定して開発できない。
アジャイル開発は運用しづらいと思ってしまうのは、単に開発チームの技術力が低いという事実を指摘しているだけだ。

BTS、SCM(バージョン管理)、CI(ビルド管理）のツール群は最終的にはソフトウェア構成管理を形成し、それがソフトウェア開発の作業手順やワークフロー、開発プロセス全体に制約をかけている。
古いツール、従来の成功体験に基づく開発プロセスでは、ソフトウェア開発に進歩はない。
PDCAサイクルを早く回すには、プログラミングと言う最も基本的な作業の品質をもっと上げるべき。

BTS、SCM、CIという3種の神器と密接に絡むチケット駆動開発は、ソフトウェア開発の開発プロセスの制約条件を研究するのにとてもよい環境のように思う。