分散バージョン管理システムは、現在ガートナーの誇大広告サイクルのどこにあるのでしょうか？[閉まっている]

編集：最近のダウン投票（この時点で+ 8 / -6）を考えると、ガートナーのライフサイクルはプログラマーの観点から偏ったメトリックであることは私に明らかにされました。これは私が経営陣に提示する論文の一部であり、経営陣はガートナーの聴衆の一部です。

DVCSを与える暴露＆熱意を（誇大広告とみなさ、ことが「可能性」というか、少なくともなどの攻撃これを読んだとき）、次の質問を考える：「どのように私はDVCSsの準備ができていることを管理を説得するガートナーのハイプ・サイクルを使用することができます（または準備ができている）、それは単なる誇大広告ではありません」

DVCSsが誇大広告であるかどうかを尋ねるだけでは建設的ではありませんが、ガートナーの誇大広告サイクルは、それを尋ねるよりも客観的な手段です（この手段が偏っているとみなされても）。他の楽器を知っている場合は、ぜひとも言及してください。

編集＃2：Gartnerのライフサイクルはすべてのテクノロジーに対応しているわけではないことに同意しますが、一部の人は誇大広告と見なされるほどの話題を生み出したと考えられるため、少なくともこのツールを使用して、どんな程度でもそれを証明/反証するために。私はDVCS、BTWの擁護者です。

編集＃3：答えてくれてありがとう。バウンティは詳細と実践的なアドバイスで私の質問に答えてカレブに行きます。受け入れられた答えは、別の有用な手段を提供し、私の質問を超えて答えてくれた哲学者に送られます。

会社でDVCSの採用を支持して書いているホワイトペーパーの研究をしていて、社会的証拠の概念につまずいた。DVCS採用の社会的証拠が必ずしも貨物カルトではないことを証明したいので、5段階で技術の成熟度を説明するガートナーの誇大広告サイクルにつまずいた。

私の質問は：誇大広告サイクルの特定の段階での分散バージョン管理システム（一般的にはgit、mercurial、bazaarなど）の現在の場所の指標は何でしょうか？...（その他の（複雑ではない））つまり、DVCSの現在の期待は、a）開始、b）膨張、c）減少（幻滅）、d）増加（啓発）、またはe）安定化（成熟）、および（より重要な）理由であると言いますか？

それは難しい質問であり、主観性が関与していることは知っていますが、特定のフェーズの最も明確な議論/証拠に答え（および従来のクッキー）を付与します。

誇大広告サイクルは、特定のモノが実際に使用したり、実際の生産性の値ではなく、特定のモノが生成するニュース/バズの量を測定します。だから...その観点から、DVCSはニュースサイクルで急上昇していると言えます。十分な人々が実際にそれを使用しており、他の人々がそれを使用することを奨励しているので、技術の世界で多くの話題を得ています。採用が広まれば、何か新しいものが登場するとニュース/バズが少し消えて、人々がシステムをより完全に理解し始めると再び上昇することを期待しています。

誇大広告のサイクルを見る1つの方法は、新しい採用者の数を調べることです。テクノロジーの新規採用者の数は、誇大広告サイクルと同じ正確な曲線形状に従う傾向があります。テクノロジーが多数の新しい採用者を獲得するにつれて、特定の新しいテクノロジーの話題が急速に拡大することは理にかなっています。アーリーアダプターはイノベーションを広め、ミドルアダプターは話題を呼んでいます。

イノベーションの急速な採用中の話題は、ほとんど情報がありません。何かを知っているがそれについて知らない人がたくさんいる場合、経験豊富なユーザーとは異なる、おそらく大きな期待を抱くでしょう。それが誇大宣伝の出所です。

導入率がピークに達した後の騒ぎは落ちます...一部は、以前の非現実的な期待が報われなかったためです（おそらく、DVCSは生産性を向上させますが、すべての問題を解決するわけではありません）他の何かが急速な採用期間を経て、すべてのマインドシェアを占めています。誇大広告は気まぐれです。

しかし、ある時点で、新しいアダプターをかなり一定の割合で取得し始め、イノベーションが標準になり、新しいアダプターは、使用する必要があると既に決めたこのものの使用方法を知りたいと思っています。そして、イノベーションをめぐる話題は、人々がそれを使用している場合にできることではなく、人々が実際にそれを使用しているということです。

したがって、誇大宣伝曲線を採用して、Sカーブの採用率の横に置くと（Everett Rogersの「イノベーションの拡散」を参照）、Sカーブが変化するにつれてS曲線が最も急で谷間で誇大広告がピークになることが予想されます。イノベーションが市場の飽和状態に達すると再び上昇します。

DVCSは急速に採用されている時期であるため、おそらく誇大広告サイクルのピーク付近にいると思われます。

私は誇大広告のサイクルの専門家であると主張していませんが、いくつかの観察を提供します：

1. 誇大広告のサイクルは、テクノロジー自体の特徴というよりも、期待とメディア報道の産物のようです。私の辞書によると、誇大広告は「過激または集中的な宣伝または宣伝」だという。それは「メディアによって誰かまたは何かに与えられた通知または注意」として宣伝を定義します。メディアは、マスコミュニケーションのさまざまなチャネルの総称です。

2. 前の点を受け入れた場合、誇大宣伝サイクルは、メディアが特定のテクノロジーをカバーしている場合にのみ適用されることになります。

3. 誇大広告のサイクルがすべてのテクノロジーに適用されるかどうかは、まったく明らかではありません。科学雑誌には、主流メディアが決して気付かないような進歩の報告がたくさんあります。メディアによる報道がなければ、期待が膨らむ可能性は低くなり、幻滅の谷は回避できます。

4. 分散バージョン管理システムは、古いものを改良したものほど新しいアイデアではありません。誇大広告のサイクルが予測すると思われる種類の「新興技術」と呼ぶのは一筋縄ではいきません。

あなたがのためにケースの構築を開始する前にどこハイプ・サイクルグラフ上のDVCSのフィット感を、あなたは、分散型バージョン管理は、すべてのハイプ・サイクルの対象となる場合を構築する必要があります。「テクノロジー」としての分散バージョン管理はメディアで取り上げられますか？分散バージョン管理に対する期待が膨らんでいる、または今までにありますか？DVCS製品が期待どおりに機能しない場合、DVCSユーザーは幻滅する可能性がありますか？

SVNがCVSの改善であったように、分散バージョン管理は既存の製品カテゴリの改善に過ぎないと私には思えます。SVNの採用率をグラフ化する場合、誇大広告サイクルのように見えるプロットが表示されるとは思いません。代わりに、市場支配のプラトーまで着実に増加するプロットを取得し、「git」のような分散システムが人気を得るにつれて長くゆっくりと低下します。

誇大広告の答えが本当に必要な場合、DVCSは幻滅/欲求不満の最期に非分散バージョン管理システムでゲームに参加し、採用率が上がるにつれて啓発の勾配を登っていることをお勧めします。

あなたの議論を誇大広告サイクルに頼るのではなく、分散バージョン管理の採用率とその理由に注目することをお勧めします。DVCSが機能しているために人々がDVCSに切り替えているという逸話的な証拠がたくさんあります。一方で、私は誰の切り替えを聞いたことがないバック彼らは失望したので、非分散型システムへ。いくつかのハードデータを取得するには、Beanstalkなどのホスティング会社と話してみてください。また、集中システムと分散システム間の相互運用性にも注意してください。「git」はSVNで非常にうまく機能すると聞きました。集中化されたシステムは引き続き企業の分野で非常によく機能するため、「との相性が良い」ことを強調します。

OPの編集に応じて更新します。

ガートナーの誇大広告サイクルを使用して、DVCSの準備ができている（または準備ができている）ことを経営者に納得させるにはどうすればよいですか？

ここで役立つ可能性のあるアプローチはいくつかあり、すべてがハードデータに依存していると思います。

Googleトレンド。Googleは明らかに、ネット上にあるものと人々が検索するものに関する大量のデータを収集します。数日前、私は分散バージョン管理に関する誇大宣伝サイクルの証拠を探しました（しかし、見つけることができませんでした）。http://trends.google.com/は、地域を米国に限定すると、dvcsまたは分散バージョン管理という用語に十分なデータがないと述べています（そして、世界のdvcsの結果はあまり関連性がなく、役に立たないようです）。より具体的な用語を検索する方が多少優れていましたが、gitやmercurialなどの製品名には他の意味があるので（誰が知っていましたか？）複雑です。gitの結果 バージョン管理システムが原因の可能性がある傾向を示しています。

それをバージョン管理に特化させようとして、gitリポジトリを試しました：

もう1つ...人々がgitを採用している場合、gitコマンドのヘルプを検索する傾向が高まるはずだと考えて、git pull（青）、git commit（赤）、git rebase（金）を試しました。

その最後のグラフは、人々がgitを採用し使用しているという最高の証拠を提供しているようです。

Google検索。

分散バージョン管理などの用語を単に検索してみて、たとえば上位25件の記事の日付をメモしてください。結果をプロットします。私が見つけたトップヒットのほとんどは、2007年から2009年の範囲の日付でした。誇大広告のサイクルが当てはまり、3〜5年前にメディア報道のほとんどが行われたことを示すことができれば、膨らんだ期待のピークを超えたかなり良い証拠のようです。

DVCSを使用するプロジェクトの例を収集します。

Linuxのような大きなものを含め、オープンソースの世界にはたくさんの例があります。（Linus Torvaldsは、Linux開発の管理を支援するためにgitを作成しました。）より有用なのは、DVCSを使用する企業の例です。（マネージャーがテクノロジーを採用するよりも嫌いなものがあれば、それは時代遅れになっています。）誇大広告はそれだけです-テクノロジーや製品に関する話題です。DVCSの企業採用の証拠を見つけることができれば、それはおそらく他の何よりも優れている「単なる誇大広告だ」という議論に対抗するのに役立つでしょう。

最後のヒント：

• 具体的に。会社はテクノロジー全体を採用するのではなく、特定の製品を採用します。一部の製品は、常に他の製品よりも成熟度が低くなります。2つまたは3つの有名なDVCS製品を選び、それぞれが開発プロセスにどのように適合するかを示します。マネージャーは漠然とした約束よりも具体的なアイデアを好むので、特定の用語で技術を分析すると、より快適に感じることができます。

• それはオールオアナッシングではありません。DVCSを使用する実際のプロジェクトには、依然として中央リポジトリがあります。そのため、クラウンジュエルの制御を失うことへの不安は容易に和らげられます。

• 現在のシステムを放棄する必要はありません。gitのような一部のツールは、svnのような既存のバージョン管理システムでうまく機能します。したがって、DVCSを開発プロセスに簡単に追加できます。

• 小さく始めます。プロジェクトが1つしかない中小企業でない限り、プロジェクトの1つまたは2つだけのプロセスにDVCSを簡単に組み込む必要があります。最初に頭に飛び乗る必要はありません-つま先を浸すだけで​​す。

要するに、抵抗のポイントを特定し、できる限り明確に対処します。

特定のフェーズの議論/証拠

どんなフェーズであっても、分散VCS TeamWareがそれ以上の期間にわたって存在しているため、技術が「10年以上」専門的に使用されているという事実に一致する必要があります。 。

Wikipediaによれば、TeamWareの最大の展開はSun自身の内部であり、いくつかの例外を除き、ある時点では使用された唯一のVCSでした。TeamWareは、SolarisオペレーティングシステムやJavaシステムを含む、Sunの最大のソースツリーの管理に使用されています。

ウィキペディアの記事では、TeamWareのアーキテクチャリーダーであるEvan AdamsからのUsenixメッセージについて言及しています。

1991年の春に、TeamWareプロジェクトの実装を決定しました...

TeamWareは、いくつかの一般的なライブラリから構築されたコマンドラインとGUIツールのセットです。ライブラリは、TeamWareグループがTeamWareアプリケーションで使用するために提供しています。より一般的な使用のために提供されていません。

TeamWareは、並行開発を促進するコード管理製品であり、SCCS上に構築されています。ユーザーはSCCS階層のコピー（ブリングオーバー）を作成し、個人の階層を作成します。この階層では、ユーザーが変更を加えてテストします。これらの変更は、元の階層に統合（プットバック）されます。統合階層に、ユーザーの階層にない変更が含まれている場合、TeamWareは並行変更があったことを検出し、統合を拒否します。したがって、ユーザーは、統合する前に、統合階層の変更を自分の階層に組み込む必要があります。TeamWareには、ユーザーが並行して変更をマージできるグラフィカルな3者間差分プログラムであるfilemergeユーティリティも含まれています。TeamWareは、ソースファイルの変更（SCCSデルタ）とファイル名の変更の両方を追跡します...

興味がある場合は、ここで詳細を確認してください。

• エヴァン・アダムスによる「老人とC」
• "Sun WorkShop TeamWareユーザーズガイドの" Oracle / Sunのサイトで- PDF ^2001年7月、HTML

^{私の回想では、当時の中央集中型CVS / SVNにはWindowsとLinuxで実行できるという利点がありましたが、TeamWare（SCCS）はSolarisファイルシステムでロックされています（Linuxでは、ハッキングの方法を知っていれば多かれ少なかれ実行されます）偽の「ゼロチェックサム」バグ）。}

私の答え：

答えは、「インターネットのテレビ」と「クラウドコンピューティング」の間にある「膨らんだ期待のピーク」の上昇肩にあると思います（これらは両方とも過去2、3年でやや急速に進んだと思いますが）。

誇大広告サイクルの性質：

私が理解しているように、誇大広告サイクルの進行は、「成熟度」（それが何であれ）の客観的な尺度ではなく、特定の技術の長所と短所についての認識の進化によって特徴付けられます。

バランスのとれた（そして独立した）意見を構築するために十分に多様な一連の経験を蓄積する前に、群集のダイナミクスは（多様性、微妙さまたは分析の深さのない高度に相関した意見で）揺れ動きます。

これは「幻滅の谷」でも「膨らんだ期待のピーク」でも同じです。

コミュニティがDVCSを展開するのが適切な時期と時期、および時期と時期を詳しく分析して、幅広い多様な意見を作成する場合、「生産性のプラトー」にあると推測できます。 （または、少なくとも「啓蒙の坂道」までの道）。

一方、談話が技術の優位性（またはそれ以外）に焦点を当てている場合、それが存在する競争的景観の落ち込みや折り目に関係なく、「ピークのどちらかにある」と推測することができます膨らんだ期待」または「幻滅の谷」。コミュニティが火炎戦争によってキャンプに分割されている場合、私たちは同時に両方の段階にいることさえできます。

:-)

これらの基準によるDVCSの評価：

これまでの談話で見た比較的浅い分析と、否定的なコメントの相対的な欠如から、「膨らんだ期待のピーク」に現在上昇していると推定します。反対側の下り坂を準備している人もいます。

DVCSテクノロジーの成熟度の強力な指標は（企業の観点から）、単に「なぜDVCSなのか？」「組織への利益を最大化するために、DVCSを中心にワークフローとプロセスを最適に構成するにはどうすればよいですか？」

私が見たものから、私たちはまだそこにすべてではありません。（より洗練された同胞の一部が先導しているが）

意思決定における誇大広告サイクルの役割：

「Hype Cycle」モデルは、行動バイアスのモデルであり、私たち自身の精神状態を理解するのに役立ちます。テクノロジーが他の人によって誇大宣伝されていると判断できる場合、それは私たち自身の精神的スタンスに影響を与える可能性があり、（二重に考えるリスクがあります）それに応じて補償し、選択基準を選択する際に合理的に行動する必要があるかもしれません。

選択基準：

言うまでもなく、選択基準の選択は非常にコンテキストに依存します。

個人的には、（一種のブレインストーミング演習として）検討している各オプションの短い（15分）SWOT分析と、（真剣に）状況のPEST分析を行い、より幅広い（非技術的）分析の要因。

分散VCSのSWOT

強み：

• 柔軟性-さまざまなワークフローを自由に選択できます。
• 低帯域幅/高遅延のネットワーク接続よりも優れたパフォーマンス-分散チームおよびオフサイトワーカーに適しています。
• より高度なマージ機能により、より頻繁に分岐できます。（これが良いことかどうかわかりません）。
• ソースコードは、各開発者のマシンで「バックアップ」されます。（適切な災害復旧計画を妨げる可能性があるため、これはかなり偽物です）

弱点：

• 柔軟性-さまざまなワークフローを自由に選択できるため、使用しているワークフローを定義し、それを実施するために追加の作業を行う必要があります。
• 複雑さと概念上の難易度（特にソフトウェア開発者以外のチームメンバー向け）。

機会：

• おそらく、柔軟性を活用して、ビジネスニーズにより適したワークフローを設計できるでしょうか？

脅威：

• おそらく、ワークフローのリエンジニアリングに非常に長い時間を費やし、コア製品に集中しなくなるでしょうか？
• 一部の人々に単純なツールでさえも使用するのは難しい場合があります。特に、彼らが必要であると信じていない、または動機付けられていない場合です。

集中型VCSのSWOT

強み：

• ビジネス組織とプロセスに帯域内の暗黙的な通信チャネルを提供します。
• 可能なワークフローを（多くの場合合理的な）サブセットに制限します。
• CIおよびその他の開発自動化ツールのセットアップを簡単にします。
• （SVN固有）巨大なリポジトリをサポートします。
• （SVN固有）非常に安定しており、多くの大規模で保守的な組織で使用されています。
• トップダウンの指揮統制組織で政治的に受け入れられますか？

弱点：

• 柔軟性がない。
• 低帯域幅/高遅延接続でのパフォーマンスの低下。分散したチームやオフサイトワーカーでの使用が難しくなります（特にリポジトリが大きくなる場合）

機会：

• おそらく、リポジトリのモノリシックな性質を使用して、開発者が製品をナビゲートし、互いのコードをさらに再利用できるようにできますか？

脅威：

• プロジェクトが突然非常に重要になり、他のサイトで作業する開発者を追加する必要がある場合、オフサイトでホストされているSVNリポジトリで効果的に作業できますか？
• 開発者のセットが非常に大きくなり、それらの調整が困難になる場合、単一の中央リポジトリがボトルネックになりますか？（他の方法でこれを回避できますか？）

結論：

どのVCSを使用するかは、個々の状況に依存します。私が働いてきた多くの状況で、集中型のワークフローを備えたDVCSはうまくいきましたが、ワークフローをサポートおよび実施するメカニズムを構築するための時間と労力を正当化する必要がありました。難しい。

最終的には、議論は私たちのビジネスに最適なワークフローは何かという質問を中心にすべきだと思います。使用するのに最適なツールは、その質問への回答から自然に従う必要があります。