プロジェクトマネジメントプリンシプル

「プロジェクトマネジメント プリンシプル - 変革の時代を生き抜くための人と組織の挑戦　[原書名：The Principles of Project Management]」を読み始めた。
今まで敬遠していたPMBOKの概念が支障なく理解できる。

プロジェクトマネージャがその権限を振るえる組織、チームビルディング、コンフリクトマネジメント、調達管理。
プロジェクトと言う形態が工学として知識体系化されたきっかけは、航空宇宙科学のプロジェクトから始まったのか、とか。
プロジェクトチーム形成や人的資源管理は、まさにプロジェクトファシリテーションそのものだな、とか。
「変化を抱擁する」をフレーズとしたXPは、まさにプロジェクトの特徴をおさえているな、とか。

内容は少し古いけど、エッセンスは詰まってます。

モデリングとプログラミングの観点の違い

要求開発の記事を読みながら思ったことをメモ。
＃あくまでもメモ書きであり、ロジカルでない。

モデリングとプログラミングは、根底から考え方が違うと思う。
モデリングできたからと言って、プログラムがすぐにできるわけではないし、モデルだけではシステムは動かない。
でも、モデリングで分析し尽さないと、思想のないプログラムが増殖し、それらのプログラムはすぐにスパゲティになる。
モデリングとプログラミングは相互に補完する関係にある。

モデリング技法には、OOAやDOA、他にも色々あるけど、基本は、エンティティを中心にその関係を考える。
一方、プログラミングは、基本はやはり手続きを考える。

構造化分析とは異なり、モデリングという概念が出てきたのは、DOAからだと思う。
DOAはモデルからデータと処理を区別して、データだけを取り出し、その関係をまとめる手法。
DOAはエンティティという入れ物が最初にありき。

DOAでもT字型ERでは、エンティティをリソースとイベントという2種類に分けて考える。
リソースは、マスタ系Tbl。例えば、顧客・商品など。
イベントは、トランザクション系Tbl。例えば、注文・在庫など。

リソースの関係からイベントが生じるという発想の元に、リソース間の関係にビジネスルールの制約を課す。
この手法によってER図が生まれる。
羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))、渡辺さんの本(業務別データベース設計のためのデータモデリング入門, 業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題)が詳しい。

OOAは、UMLという技法とセットで現れて数年前に流行した(ように思う)。
UMLにある各種のダイアグラムのうち、モデリングで最も重要な技法は、クラス図と状態遷移図だと思う。

ビジネス分析において、OOAもDOAと同じようにエンティティをまず洗い出すのが重要。
そのエンティティは概念モデルに現れて、その概念モデルはクラス図で表現する。

概念モデルはER図のように、クラス同士の関連に動詞を書き込んで、トランザクションを表現する。
つまり、DOAにおけるリソースとイベントが自然に現れる。
児玉さん(UMLモデリングの本質)は、リソースとイベントの関係を「もの-こと-もの」パターンと呼んでいた。

状態遷移図は、概念モデルで現れた一つのオブジェクトに注目し、そのオブジェクトの状態の動的な遷移を表現する。
仕様を理解できているかどうかは、状態遷移図を正確に書けているか、にかかっているように思う。

例えば、小売Webシステムならば、商品は販売中・カート・注文中・配送中・在庫無しなど色んな状態が各タイミングで変わる。
特に、排他制御が絡んだ在庫チェック、注文取消しの業務がとても難しい。

又、組込システムならば、缶ジュースの自動販売機の状態遷移の例が情報処理試験に良く出てくる。
自動販売機の状態も、販売中・販売完了など色々あるけれど、「缶ジュースが詰まってボタンが押せない」とか「在庫切れで販売できない」など色んなパターンも考えると、どんどん複雑になる。

モデリングが難しいのは、二つあると思う。
一つは、エンティティを洗い出すのが難しいこと。
例えば、概念モデルに現れたエンティティで漏れがない、という事を説明するのは難しい。

また、ビジネスルールを理解し切れていないと、エンティティを最初からすぐに導き出せない。
だから、羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))では、最初はトランザクションに注目し、そこからエンティティを洗い出す手法を勧めている。
このやり方が最も自然なように思う。

更に、エンティティをクラスから型(Type)へ抽象化するのが難しい。
アナリシスパターン―再利用可能なオブジェクトモデルは、その構造を知識レベル・操作レベルと呼んでいるが、これを理解するのは至難の技。
児玉さんの本(UMLモデリングの本質)で僕はようやく理解できるようになった。

このやり方は、ビジネスモデリングで最も重要な手法の一つだと思う。
抽象化することによって、新たなビジネスパターンが得られるし、ビジネスで最も重要な概念が何か、が分かるからだ。
例えば、児玉さんの本(UMLモデリングの本質)では、会計システムにおける勘定パターンは物流システムの在庫パターンにも使える、と指摘している。

二つ目は、エンティティ同士の関連にどこまでビジネスルールを反映できているか、すぐに分かりづらいこと。
そこで、クラス図はあくまでも抽象的な図なので、実際に検証する時は、インスタンスの関係を書いたオブジェクト図を使えばよい。
児玉さん(UMLモデリングの本質)はクラス図の検証はオブジェクト図を使うことを推奨している。

また、児玉さん(UMLモデリングの本質)は「揺さぶり」という手法で概念モデルを洗練させる手法を提案している。
つまり、概念モデルに対し、ビジネスルールが反映されているかという観点で概念モデルを揺さぶってみる、ということ。
この辺りは児玉さんの本に詳しく、モデリングで最も面白い部分。

こう書いてきて、やっぱりOOAは児玉さんの本、DOAは渡辺さんの本が一番分かりやすいと思う。
平鍋さんは、渡辺さんの本(業務別データベース設計のためのデータモデリング入門など)を「日本人が書いたアナパタ」と呼んでいた。

オブジェクト納涼祭の感想: プログラマの思索

モデリングはプログラミングに比べると歴史も浅く、その手法も統一されてない。
モデリングの一番の弱点は、プログラミングと異なり、モデルだけではシステムが動かないこと。
だから、モデルの検証作業が難しい点が弱点であるように思う。

モデリング主義者が一番やりたいのは、モデル駆動開発(MDA)。
モデルを書いたら、そのモデルから動くプログラムを自動生成する手法。
でも、MDAは未だ完成していないし、そもそも本当にMDAが実現できるのか、誰も知らない。

アドレナリンジャンキー

デマルコの新著「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」が面白いのでメモ。

【元ネタ】
ビジネス書の杜: プロジェクトマネジメントのグル「トム・デマルコ」の集大成

デマルコはソフトウェアのプロジェクト管理に関して、優れた思索を本にしている。
思い出してみれば、「ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解」も「熊とワルツを - リスクを愉しむプロジェクト管理」も「ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵」も彼が書いている。

もう一度読み直してみたい。

ソフトウェア開発チームはオーケストラに似ている

ソフトウェア開発の特徴で良い記事があったのでメモ。

【元ネタ1】
ソフトウェア開発組織はオーケストラ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェア開発で伸びる人，伸びない人【第二版】：柴田 芳樹 (Yoshiki Shibata)：So-net blog

荒井さんの本「ソフトウェア開発で伸びる人、伸びない人 【第二版】 (技評SE選書)」が紹介されていたので立ち読みしてみた。
「特別付録　音楽とソフトウェア開発」という章が面白かった。

ソフトウェア開発組織はスポーツではなくオーケストラ。
個人のスキルは前提条件であり、協調するのが大事。
一人のスキルが低いと、演奏する音楽全体の品質が落ちる。

オーケストラでは、指揮者(プロジェクトマネージャ)以外に、副指揮者(プロジェクトリーダー)、コンサートマスター(アーキテクト)の役割が必須。
管理者の仕事が3人に分かれているのに注意。
SW開発の大規模プロジェクト(数十人以上)も同様に、管理者の役割が分化されるはず。
アジャイル開発のような小規模チームでは、管理者が役割を兼務する時が多い。

バッハやモーツァルトもその時代の音楽楽器の技術をフルに使うことで、優れた楽曲を残した。
IT技術も、その時代に合った技術をフルに使えば、ベターなシステムが作れるはず。
しかし、IT技術は陳腐化が激しいので、システムの寿命も本来は短いのかもしれない。

【元ネタ2】
「ソフトウェアは工業製品ではない」　まつもとゆきひろ氏：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェアエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-net blog

日本のITベンダーのプロセス改善に何故、違和感を感じるのか？
彼らのプロセス改善の根底には、アートを作るのではなく、工業製品を作っているイメージがある。
ソフトウェア開発のプロセスが細分化されて、プログラミングではなくコーダになっている。

【元ネタ3】
ソフトウェアエンジニアの成長カーブ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
開発チーム（組織）の成長：柴田 芳樹 (Yoshiki Shibata)：So-net blog

ソフトウェア開発において、成長できない組織や個人は、プロセス改善できない。
ソフトウェア開発においてプロセス改善するには、プログラミング技術が時代に乗り遅れないように、常に磨かなくてはいけない。

ソフトウェアテストPRESS Vol.9にあるTestLinkの記事

ソフトウェア・テスト PRESS Vol.9にありえるえりあさんによる TestLinkによるテスト管理記事が載っていたのでメモ。

【元ネタ】

TestLink使用レポート ― ありえるえりあ

TestLinkを検証しました ― ありえるえりあ

SWテストを管理者・開発者・テスト担当者の観点から書かれていて面白かった。
TestLinkの内容は上記のBlogと殆ど同じだった。

興味深かった点を書いておく。

【1】開発チームとは別にテストチームを作った理由が書かれていた。

元々、プログラミングによる開発が一番大事で、そもそもテストチームは必要とは思えなかった。
知っているテスト担当者から愚痴ばかり聞いていたから。
しかし、開発してテストしてリリースする一連の作業で、開発者だけの場合、開発者は実装するよりもテストする作業が半分以上に増えて、肝心の開発作業が滞りがちになった。
だから、開発者がバグ修正に専念できるように、テストチームを作らざるを得なかった、と。

この理由はなるほどと思わせる。
開発チームとテストチームの2つの部隊を作らざるを得ない理由は、マネジメントの問題なのだ。

単純な単体テストレベルならば、開発者もやっているが、システムテストや受入テストのレベルになると、テストの事前条件やテストデータの作りこみに手間がかかる。
更に、テスト結果の検証作業も、システムテストや受入テストでは、とても大変になりがち。
開発の片手間でできる作業ではない。
だから、テストチームの役割は、複雑なテスト作業とその検証作業の専任になる。
特に大規模開発ほど、この傾向は強いだろう。

又、テストチームのコストについて書かれた内容も興味深かった。
いわく、テストチームそのものは開発上のコストになるが、当社はパッケージ製品の開発が主業務なので、実際のテストは回帰テストが多い。
つまり、単純になりがちなので、テスト担当者が専門でテストした方が、開発者は実装の専念しやすい、と。

ハードと違い、ソフトはどんどんバージョンアップしていく。
だから、過去のバージョンの機能がデグレせずに正常動作することを検証する必要がある。
つまり、バージョンアップするに従って、テストケースは単調増加で増えていく。

過去のバージョンのテストは結局、回帰テストになる。
機能テストのレベルならばJUnitでテストを自動化できるが、システムテストや受入テストでは、UI周りのテストを自動化する速度よりも機能追加の速度が早くて追いつかず、結局、コストが合わない時が多い。

この辺りの解決方法の一つとして、TestLinkで手動のテスト作業の管理を効率化する点があるだろう。

【2】リリース判定条件として、信頼度成長曲線を止めて、タイムボックス形式(イテレーション)へ変更した理由が書かれていた。

ハードのように、信頼度成長曲線を書いてバグの歩溜まりになったらリリースする判定条件にしても、実際はリリース後に障害が数多く発生する時は多い。
その理由は、ソフトでは、信頼度成長曲線は人為的に操作しやすいからだ。
例えば、テストするスコープを狭めれば、確かにバグは減っていくだろう。

しかし、実際のソフトウェア開発は、仕様変更が任意に勃発するので、長期間スコープが固定化された状態はありえず、結局、バグはいつまで経っても収束しない時は多い。
だから、オープンソースのようにタイムボックスごとにリリースしていくのが一番現実的だ、と。

このリリース手法は、まさにアジャイル開発そのもの。
タイムボックスをイテレーションと見なせば、イテレーションというサイクルで小刻みに機能追加しながらリリースしていく開発スタイルになる。

アジャイル開発の場合、短い期間だけれどもイテレーションの間はスコープは固定されているので、品質を高めやすい利点がある。

例えば、イテレーション期間中に仕様変更が生じたら、次のイテレーションで対応するとアナウンスすればいい。
まずは目の前のイテレーションの機能を実装してリリースするのを目標とする。

又、品質とは、単に信頼性だけではない。
顧客にとっての価値とは、欲しい時に欲しい機能があることなのだから、納期も重要な制約条件だ。
品質重視でリリース時期が遅れたら、顧客のビジネスにも支障が出やすい。
だから、アジャイル開発では、スコープを制御することで、品質を保持し、納期を守るようにするのだ。

テスト工程のマネジメントは、上流工程のマネジメントよりもはるかに難易度が高い事実を改めて考える必要があると思う。

『～ It!』シリーズの本は良書

【元ネタ】
エンジニアがタイトル買い、著者買いすべき本 - {Fight the Future => じゅくのblog}

『～ It!』シリーズの本は確かに良書だ。
『～ It!』シリーズの本は3冊ある。

「 Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」は、プログラマが身に着けるべき習慣が書かれている。

「Release It! 本番用ソフトウェア製品の設計とデプロイのために」にあるノウハウは、Webシステムの環境構築やリリース作業で非常に役立つだろう。

「Manage It! 現場開発者のための達人式プロジェクトマネジメント」は、開発者のためのプロジェクト管理、特にアジャイル開発の導入に関するノウハウが書かれている。

後日、読んだ感想を書いてみる。

入門Mercurialの感想

Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。

【元ネタ】
Mercurial の利用

特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社

スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3)

ダウンロード - TortoiseHg - SourceForge.JP

「入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。
平易に書かれていてとても読みやすい。
また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。

エピローグに「あ！構成管理って楽しいんだ？！」という節がある。
MercurialはCVSやSubversionと違って、オフラインのノートPCでも共有リポジトリと関係なくバージョン管理できるおかげで、コミットがすごく楽しかった。
ついに自由を獲得できた、と思った。

そして、構成管理にまつわる問題の本質は、「構成管理が面倒」であることではなく「面倒なツールで構成管理をしていたこと」に気付いた。
そのおかげで、構成管理が楽しい！と思うようになった、とのこと。

経験談としてすごく納得できる。
僕も、TortoiseHgを使い始めて、オフラインのノートPCで簡単にバージョン管理でき、外付けHDにバックアップ代わりにミラーリングできるようになった。
更に、Redmine＋TortoiseHgでプライベートなタスク管理が簡単にできあがった。
だから、作業がすごく楽しくなった。

優れたツールが開発のあり方まで変えてしまう。
ツールがプロセスを改善する。
優れた技術力こそが、SW開発が抱える諸問題の難易度を下げて、一つずつ解決の方向へ進めさせてくれる。

Redmine -もっと手軽にプロジェクト管理!

下記の本が7月末に発売されるらしい。

著者の一人である倉貫さんはXPJUG代表であり、Rails製SNSであるSKIPの開発者でもある。
実際、SKIPのタスク管理が行われているRedmineは公開されている。
SKIPと絡めた運用プロセスが解説されるのだろう。

SKIP - 概要 - SKIP - Redmine

目次を読んでいたら、さっそく読んでみたくなってきた。。

Antリファクタリングカタログ

「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」本を読んで興味深くかつすぐに使えそうな箇所は「Antビルドファイルのリファクタリング」だった。
以下メモ書き。

【1】「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の1章に「ビジネスソフトウェアの「ラストマイル」を解決する」という章がある。
長年、継続的に機能追加されて肥大化したシステムへいかにアジャイルにリリースできるか？という「ラストマイル」問題を提示している。

XPが提示したプラクティス「継続的インテグレーション」「テスト駆動開発」は、高速・高品質な開発を可能にした。
しかし、本番環境へのデプロイ＋リリースのプロセスではその恩恵がない、と。
理由は、3つある。
一つ目は本番環境は大変高価であり、二つ目は検証が複雑で、三つ目は検証の工数が大きすぎるからだ、と。

アジャイル開発の最終目標は「バージョンのないソフトウェア」を提供することにある、と。
つまり、仕様変更の要求が発生したら、それを開発して完成したら、すぐにリリースして本番稼動できることだ、と。

この指摘は、アジャイル開発の別の問題点を示していると思う。
今僕が考えているチケット駆動開発、プロジェクト管理サーバーは、アジャイル開発のプロジェクト管理へ適用して、大幅に改善できると考えている。
上記では、大規模システムへアジャイル開発を適用した場合、開発プロセスの効率化ができたのを前提とした上で、リリース管理に問題があることを指摘している。

「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」にも書いているが、上記にあげたリリース管理の問題点は、二つの技術で大幅に改善できると思う。
一つは、ビルド作業やリリース作業の並行化。
いわゆる並行ビルド、並行リリース。
Hudsonなら、並行ビルドも簡単に操作可能。
これによって、二つ目と三つ目の問題が解決できる。

もう一つは、本番環境を仮想化して複数のテスト環境を作って、検証可能にしておくこと。
昨今ならVMWareで仮想イメージを簡単に作ることができる。
これによって、一つ目の問題も解決できる。

実際の現場ではまだ一つのアイデアに過ぎないだろうが、そのアイデアを実現する技術は既に登場していることに注意しよう。

【2】「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の10章にAntビルドファイルのリファクタリングが書かれている。
Antビルドファイルのリファクタリングは実施した経験が無かったけれど、さっそく使ってみたい技術の一つ。
Antだけでなく、MavenやRakeなどでもその発想は使えるはずだ。

【元ネタ】
2009-01-05 - yyamanoの日記

【Antリファクタリングカタログ】

【1】ターゲットの抽出
* macrodefの抽出 - コードブロックをmacrodefとして抽出する
* ターゲットの抽出 - 大きなターゲットを小さなターゲットに分割し、依存関係を定義する
* ターゲットのラッパービルドファイルへの移動 - CI用のターゲットは別ビルドファイルに移動する
* デプロイ用コードのimport先への分離 - デプロイ用のコードは別ビルドファイルに移動する
* build.xml内へのラッパースクリプトの取り込み - シェルスクリプトで定義しているパスやオプションをビルドファイルに移動する
* 明確なターゲット名の導入 - ターゲットとプロパティで異なる命名規則を使う
* ターゲット名の名詞への変更 - ターゲット名にはプロセスではなく成果物の名前を使う

【2】コメント取り込み
* descriptionによるコメントの置き換え - XMLコメントのかわりにdescription属性を使う
* taskname属性の追加 - タスクの意図を明確にし、実行状況を簡単に把握できるようにtaskname属性を使う

【3】実行処理
* 内部ターゲットの強制 - 内部ターゲットの先頭にハイフンを追加し、コマンドラインから呼べないようにする
* 出力ディレクトリの親ディレクトリへの移動 - 生成される成果物の出力先を一カ所にまとめる
* applyによるexecの置き換え - execのかわりにapplyを使う
* CI Publisherの利用 - タグ処理は独立したターゲットとして分離する

【4】プロパティや依存関係の共通化
* 宣言の導入 - if条件分岐のかわりに、プロパティとimportを使う。
* 依存によるcallの置き換え - 明示的なantcallのかわりに宣言的な依存関係を使う
* プロパティによるリテラルの置き換え - 頻繁に使うリテラル文字列をプロパティに置き換える
* filtersfileの導入 - filter要素のかわりにプロパティファイルとfiltersfile属性を使う
* プロパティファイルの導入 - プロパティ定義を外部ファイルに移動する
* 要素のantlibへの移動 - 複数のプロジェクトで使われるコードをantlib.xmlに移動し配布する
* filesetによる多数のライブラリ定義の置き換え - pathelement要素のかわりにfileset要素を使う
* 実行時プロパティの移動 - ビルドに使うプロパティと実行時に使うプロパティを分離する
* IDを用いた要素の再利用 - 重複したpathのような要素をidを使い共通化する
* プロパティのターゲット外部への移動 - ターゲット内部で定義されているプロパティをターゲットの外に移動する
* locationによるvalue属性の置き換え - パスを表現するプロパティではvalue属性のかわりにlocation属性を使う

上記のリファクタリングカタログで面白いと思ったのは、コメントをタスクの属性(description, taskname)にしてしまうこと。
もう一つは、ターゲットを処理ではなく成果物の名前にすること。

Antは宣言的であってスクリプト言語ではない特徴がある。
だからこそ、ターゲットは成果物の名前にして、コメントも宣言に取り込んでしまうようだ。

このAntリファクタリングカタログは、ファウラーのリファクタリング本(リファクタリング―プログラムの体質改善テクニック)のように、抽出とインライン化の組み合わせなどもあり、非常に有用だと思う。

最近の技術のトレンド～分散バージョン管理と関数型言語

「はじめてのGit」「key-value ストア」が読みたくて、WEB+DB PRESS Vol.50を初めて買った。
すごくイイ！

【WEB+DB PRESS Vol.50の気になる章】
特集2
ブランチもマージも簡単な分散型バージョン管理システム
はじめてのGit

特集3
Webアプリのパフォーマンス向上の一策
［旬のライブラリ大集合］key-valueストア入門

Java＋RDBの技術だけで、IT業界で一生飯は食っていけると思っていた。
でも、Webの世界では、特にGoogleの技術が世界中を席巻しているといっていい。
自分の技術が時代から少しずつ遅れてきている気がしてきた。

オブジェクト指向はもう古い。
MapReduce、レコメンドエンジン、Cookie Session Storeなどのように、リストやハッシュでデータを保持して比較計算する処理技術の方が重要になりつつある。
これは関数型言語の発想だと思う。

例えば、Rails2.0の機能の一つであるCookie Session Storeは、セッションを暗号化してクッキーに保持する。
このアーキテクチャがあれば、各クライアントの画面の状態はローカルPCのクッキーで保持するから、Webアプリをデスクトップアプリのように操作できる。
Webアプリの古くからの難問である「戻るボタン」「注文ボタンの2度押し」などにも、アプリ側で簡単に対応できるようになるだろう。

アジャイル開発では、分散バージョン管理のように、ブランチによる並行開発、そしてブランチ間の自動マージは必須の技術だ。
CVS→Subversion→Gitというバージョン管理の歴史を辿れば、仕様変更に強い特徴を持つアジャイル開発の発展と歩調を合わせて進化している。
この関係は多分偶然ではない。

特にGitは、ブランチ間のマージ機能が優れていると言われる。
だからこそ、分散バージョン管理で、複数のブランチがメインライン(trunk)とは別にたくさん作られても、精度の良いマージのおかげでブランチにもすぐに最新機能を反映できるし、ブランチで試したパッチがリリース可能な品質になったら、メインラインへマージして反映することもできる。

ソフトウェアプロダクトラインが提唱する手法では、製品ラインを中核機能やフレームワークを持つコア資産と、カスタマイズした製品ごとに複数のコードラインでブランチとして別々に管理する。
この手法の弱点は、メインラインとブランチでマージ機能が貧弱なため、ブランチがメインラインから独自発展しやすい危険性があること。
だが、分散バージョン管理の優れたマージ機能を使いこなせれば、ブランチによる並行開発は怖くなくなる。

そうなれば、突然の仕様変更や障害修正が降って来たとしても、ブランチを積極的に使って、新規開発中のメインラインと突然の対応を行うブランチの並行開発が可能になる。
この手法は、現代のアジャイル開発のプロジェクト管理では必須の技術だと思う。

XPが提唱したアジャイル開発の構成管理も、上記の技術によって、難易度が急激に下がりつつある。

最近の技術のトレンドに注意していきたい。