現在、分散バージョン管理システムは、ガートナーの誇大宣伝サイクルのどこにありますか？
編集：最近の投票（この時点では+ 8/-6）を考えると、ガートナーのライフサイクルはプログラマーの視点。これは、私がmanagementに提出する論文の一部であり、管理タイプはガートナーの読者の一部です。
DVCSを与える exposure＆enthusiasm （「その可能性がある」とは誇大広告と見なされる、または少なくともそのように攻撃される）、について考えるこれを読んだときの次の質問： "DVCSが準備ができている（または十分に準備ができている）こと、および単に誇大広告ではないことを管理者に確信させるために、ガートナーの誇大広告サイクルをどのように使用できますか"
DVCSが誇大広告であるかどうかを尋ねるだけでは建設的ではありません。ガートナーの誇大宣伝サイクルは、単に尋ねるよりも客観的な手段です（この手段が偏っていると見なされている場合でも）。他の楽器をご存知の方は是非、その旨お伝えください。
編集＃2：私はガートナーのライフサイクルがすべてのテクノロジーに当てはまるわけではないことに同意しますが、一部の人が誇大広告と見なすのに十分なバズを生成した可能性があると思います、そのため、それを証明または反証するために、この手段を使用して、少なくとも評価または熟考する必要があります。私はDVCS、BTWの擁護者です。
編集＃3：ご回答ありがとうございます。バウンティは、詳細と実用的なアドバイスで私の質問に答えるためにカレブに行きます。受け入れられた答えは、別の有用な手段を提供し、私の質問を超えて答えるために哲学者に行きます。
会社でDVCSの採用を支持して書いているホワイトペーパーの調査を行っているところ、 社会的証拠 の概念に出くわしました。 DVCS採用の社会的証拠が必ずしも 貨物カルト ではないことを証明したいと思います。さらに調査を行ったところ、Gartnerの hype cycle に遭遇しました。
私の質問は、誇大宣伝サイクルの特定のフェーズにおける分散バージョン管理システム（git、Mercurial、Bazaarなどの一般的な意味）の現在の場所を示すものは何ですか？...その他（あまり複雑ではない）言葉、DVCSの現在の期待は、a）開始、b）インフレ、c）減少（幻滅）、d）増加（悟り）またはe）安定化（成熟）および（より重要）なぜ？
私はそれが難しい質問であり、主観が関係していることを知っていますが、特定のフェーズの最も明確な議論/証拠に答え（および従来のCookie）を与えます。
誇大宣伝のサイクルは、特定のモノの実際の使用や実際の生産性の値ではなく、特定のモノが生成するニュース/バズの量を測定します。ですから...その観点から、DVCSはニュースサイクルの急上昇を遂げていると言えます。十分な数の人々が実際にそれを使用しており、他の人々にそれを使用するように促し、テクノロジーの世界で多くの話題を呼んでいます。採用が普及すると、ニュースや話題は、何か新しいものや光沢のあるものが来ると少し薄れ、人々がシステムをより完全に理解し始めると再び増えると思います。
誇大広告のサイクルを確認する1つの方法は、新規採用者の数を確認することです。テクノロジーの新しい採用者の数は、誇大広告のサイクルと同じ正確な曲線形状に従う傾向があります。テクノロジーが多数の新しいアダプターを獲得するにつれて、特定の新しいテクノロジーに関する話題が急速に増えることは理にかなっています。アーリーアダプターはイノベーションを広め、ミドルアダプターは話題を生み出します。
イノベーションの急速な採用の間の話題は、必ずしも十分に知らされていない。何かを知っているがそれについて知らない人がたくさんいる場合、彼らは経験豊富なユーザーとは異なり、おそらくより大きな期待を抱くでしょう。だからこそ誇大広告が生まれるのです。
採用率がピークに達した後の話題は減少します...一部には以前に非現実的な期待が報われなかったため（DVCSはおそらく生産性を向上させますが、すべての問題を解決するわけではありません）、一部には他の何かが急速な採用期間を経て、すべてのマインドシェアを占めています。誇大広告は気まぐれです。
しかし、ある時点で、あなたはかなり一定の割合で新しい採用者を獲得し始め、革新は標準になり、新しい採用者は、彼らがすでに使用する必要があると決定したこのものの使用方法を知りたがっています。次に、イノベーションに関する話題は、人々がそれを使用している場合に何ができるかではなく、それを使用している今、人々が実際にそれを使って何をしているのかについてです。
したがって、誇大広告曲線を採用し、採用率のS曲線の横に配置すると（エベレットロジャースの「イノベーションの拡散」を参照）、S曲線が変化するにつれて、S曲線が最も急である場所で誇大広告がピークになると予想されます。方向性、そしてイノベーションが市場の完全な飽和に達したときに再び上昇します。
DVCSは急速に普及している時期なので、おそらく誇大宣伝サイクルのピークのあたりにいると思います。
私は誇大広告サイクルの専門家であるとは主張していませんが、いくつかの観察を提供します：
誇大宣伝のサイクルは、テクノロジー自体の特性というよりも、期待とメディアの報道の産物のようです。私の辞書によると、hypeは「贅沢または集中的な宣伝または宣伝」です。 publicityを「メディアによって誰かまたは何かに与えられた通知または注意」として定義します。 メディアは、マスコミュニケーションのさまざまなチャネルの総称です。
前の点を受け入れると、メディアが特定のテクノロジーをカバーする場合にのみ、誇大宣伝のサイクルが適用されることになります。
誇大宣伝のサイクルがすべてのテクノロジーに適用されることは、まったく明確ではありません。科学ジャーナルには、主流メディアには気づかれない進歩のレポートが満載です。メディアの報道がなければ、期待が膨らむ可能性が低くなり、幻滅の谷を避けることができます。
分散バージョン管理システムは、古いものを改良したものとして、それほど新しいものではありません。彼らを誇大宣伝のサイクルが予測するはずの種類の「新興技術」と呼ぶのは一続きです。
whereDVCSのケースの構築を始める前に、DVCSが誇大宣伝のサイクルグラフに適合している場合は、分散バージョン管理がまったく誇大宣伝のサイクルの影響を受けるケースを構築する必要があります。 「テクノロジー」としての分散バージョン管理はメディアで取り上げられますか？分散バージョン管理への期待が高まっている、または今までにあったことはありますか？ DVCS製品が期待に応えられない場合、DVCSユーザーは幻滅する可能性がありますか？
SVNがCVSの改善であったのと同じように、分散バージョン管理は既存の製品カテゴリの改善に過ぎないように思われます。 SVNの採用率をグラフ化するとしたら、誇大宣伝のサイクルのようなプロットは得られないと思います。代わりに、市場支配の高原まで着実に増加するプロットが得られ、その後、「git」などの分散システムが人気を獲得するにつれて、長いゆっくりとした減少が続きます。
誇大宣伝サイクルの答えが本当に必要な場合は、DVCSが幻滅/フラストレーションのない期間の最後に非分散バージョン管理システムでゲームに参加し、採用率が増加するにつれてエンライテンメントのスロープを登っていることをお勧めします。
あなたの主張を誇大宣伝のサイクルに頼るのではなく、分散バージョン管理の採用率とその理由に焦点を当てることをお勧めします。 DVCSが機能しているために人々がDVCSに切り替えていることを示す逸話的な証拠はたくさんあります。一方、backを非分散システムに切り替えた人ががっかりしたため、聞いたことはありません。ハードデータを取得するには、 Beanstalk などのホスティング会社に相談してみてください。また、集中システムと分散システムの相互運用性にも注意してください。 「git」はSVNで非常にうまく機能すると聞きました。一元化されたシステムは企業レルムで引き続き非常にうまく機能するため、「うまく機能する」という側面を強調すると、DVCSのリスクが減り、意思決定者にとって魅力的になります。
OPの編集に応じて更新：
ガートナーの誇大広告サイクルを使用して、DVCSの準備ができている（または十分に準備ができている）ことを管理者に納得させるにはどうすればよいですか？
ここで役立ついくつかのアプローチがあり、すべてハードデータに依存していると思います。
Googleトレンド。Googleは明らかに、ネット上の情報やユーザーが検索した情報に関する大量のデータを収集します。数日前、私は誇大広告サイクルw.r.tの証拠を探しました（しかし見つかりませんでした）。分散バージョン管理。 http://trends.google.com/ は、用語dvcsまたは分散バージョン管理の十分なデータがないことを示しています地域を米国に限定した場合（そしてdvcs世界の結果はあまり関連性がないか、役に立たないようです）。より具体的な用語を検索する方がいくらか優れていましたが、gitやMercurialなどの製品名には他の意味（who知っていましたか？） gitの結果は、バージョン管理システムに一部起因する傾向を示しています。
それをバージョン管理に固有のものにしようと、私はgitレポジトリを試しました：
もう1つ... gitを採用している場合、gitコマンドのヘルプを検索する傾向が高まるはずなので、私はgit pull（blue）、git commit（red）、およびgit rebase（gold）：
この最後のグラフは、人々がgitを採用および使用していることを示す最も良い証拠を提供しているようです。
Google検索
distributed version controlのような用語を単に検索してみて、たとえば、見つけた上位25の記事の日付に注意してください。結果をプロットします。私が見つけたトップヒットのほとんどは、2007〜2009年の範囲の日付でした。誇大宣伝のサイクルが当てはまり、ほとんどのメディア報道が3〜5年前に行われたことを示すことができる場合、それは私たちが膨らんだ期待のピークを超えたというかなり良い証拠のようです。
DVCSを使用するプロジェクトの例を収集します。
オープンソースの世界には、Linuxのようないくつかの例を含め、多くの例があります。 （Linus TorvaldsがLinux開発の管理を支援するためにgitを作成しました。）DVCSを使用する企業の例は、さらに便利です。 （管理者がテクノロジーを早く採用する以上に嫌いなことがあれば、それは時代遅れです。）誇大宣伝はまさにそれです-テクノロジーや製品についての話題。 DVCSの企業採用の証拠を見つけることができる場合、それはおそらく他の何よりも優れた「単なる誇大宣伝である」という議論に対抗するのに役立ちます。
最後のヒント：
具体的に説明してください。会社がテクノロジー全体を採用するわけではなく、特定の製品を採用します。一部の製品は常に他の製品よりも成熟度が低くなります。 2つまたは3つの有名なDVCS製品を選び、それぞれが開発プロセスにどのように適合するかを示します。マネージャーは曖昧な約束よりも具体的なアイデアを好むので、特定の用語でテクノロジーを分析すると、より快適に感じるようになります。
オールオアナッシングではありません。DVCSを使用する実際のプロジェクトには、依然として中央リポジトリがあるため、王冠の宝石のコントロールを失う恐れがあります。簡単に安心できます。
現在のシステムをあきらめる必要はありません。gitなどの一部のツールは、svnなどの既存のバージョン管理システムとうまく連携できます。したがって、何もあきらめることなく、開発プロセスにDVCSを簡単に追加できます。
最初は小規模です。プロジェクトが1つしかない小規模な会社でない限り、1つまたは複数のプロジェクトにDVCSを簡単にプロセスに組み込むことができます。 2つのプロジェクト。最初に頭にジャンプする必要はありません-つま先をディップするだけです。
つまり、抵抗のポイントを特定し、できるだけ明確に対処します。
特定のフェーズの議論/証拠
それがどのようなフェーズであろうと、それは分散型VCSであるため、テクノロジーが「10年以上」プロフェッショナルに使用されているという事実に一致するフェーズである必要があります。 TeamWare はそれ以上に存在します：下記のPDFユーザーガイドは2001年7月付けです。
Wikipediaによると、TeamWareの最大の展開は Sun 自体の内部でしたが、（いくつかの例外を除いて）ある時点でそれが唯一のVCSでした-これにより、何千人もの開発者がツールを使用しました。 TeamWareは、 Solarisオペレーティングシステム および Java システムのツリーを含む、Sunの最大のソースツリーの管理に使用されています。
ウィキペディアの記事は、TeamWareのアーキテクチュラルリーダーであったEvan AdamsからのUsenixメッセージに言及しています。
1991の春に、TeamWareプロジェクトの実装を決定しました...
TeamWareは、いくつかの一般的なライブラリから構築されたコマンドラインとGUIツールのセットです。ライブラリは、TeamWareアプリケーションによって使用されるTeamWareグループによって提供されます。より一般的な使用のために提供されていません。
TeamWareは、並行開発を促進するコード管理製品であり、SCCSの上に構築されています。ユーザーは、SCCS階層のコピー（ブライオーバー）を作成し、個人の階層を作成します。この階層では、ユーザーが変更を加えてテストします。これらの変更は、元の階層に統合（プットバック）されます。統合階層にユーザーの階層にない変更が含まれている場合、TeamWareは並行変更があったことを検出し、統合を拒否します。したがって、ユーザーは統合する前に、統合階層の変更を独自の階層に組み込む必要があります。 TeamWareには、filemergeユーティリティも含まれています。これは、ユーザーが並行変更をマージできるようにするグラフィカルな3者間差分プログラムです。 TeamWareは、ソースファイルの変更（SCCSデルタ）とファイル名の変更の両方を追跡します...
興味がある場合は、ここで詳細を確認してください。
私の回想によると、当時の中央集中型CVS/SVNにはWindowsとLinuxで実行できるという利点がありましたが、TeamWare（SCCS）はSolarisファイルシステムでロックされています（Linuxでは、ハッキングの方法を知っていれば、多かれ少なかれ実行されます）偽の「ゼロチェックサム」バグ）。
私の答え：
答えは、「インターネットTV」と「クラウドコンピューティング」の間のどこかにあると思います。「期待が膨らむピーク」の上昇の肩の上にあります（これらは両方とも、ここ数年で急速に進んでいると思います）。
誇大宣伝サイクルの性質：
私が理解しているように、誇大宣伝のサイクルの進行は、「成熟度」の客観的な測定値ではなく（それが何であれ）、特定のテクノロジーの長所と短所に関する進化する認識によって特徴付けられます。
バランスの取れた（そして独立）意見を構築するために十分に多様な一連の経験を蓄積する前に、群集のダイナミクスは（自然に）変動し、多様性、微妙さ、または分析の深さはほとんどなく、相関性の高い意見があります。
これは、「幻滅の谷」でも「期待感のピーク」でも同じです。
コミュニティがさまざまな意見を幅広く生み出すことになった場合、DVCSを導入するのが適切な場所と時期、適切でない場所と時期について詳細に分析すると、「生産性の高原」にいると推測できます。 （または、少なくとも「悟りの斜面」まで上昇）。
一方、その議論が技術の優位性（またはその他）に焦点を当てている場合、それが置かれている競争環境の落ち込みや折りたたみに関係なく、私たちは「ピークの膨らんだ期待」または「幻滅の谷」。コミュニティが炎上戦争によって収容所に分割された場合、私たちは同時に両方のフェーズにいる可能性さえあります。
:-)
これらの基準によるDVCSの評価：
これまでの談話で見た比較的浅い分析と、否定的なコメントが比較的少ないことから、私は現在「ピークの膨らんだ期待」を登っていると推定します。反対側の下り坂を準備している人もいます。
DVCSテクノロジーの成熟度（企業の観点から）を示す強力な指標は、「なぜDVCSなのか」という問いかけから、議論がシフトしたときだと思います。 「組織への利益を最大化するために、DVCSの周りのワークフローとプロセスをどのように最適に構成することができますか？」.
私が見てきたことから、私たちはまだ全員がそこにいるわけではありません。 （私たちのより洗練された同胞のいくつかは先導していますが）
意思決定における誇大宣伝サイクルの役割：
「Hype Cycle」モデルは行動バイアスのモデルであり、私たち自身の精神状態を理解するのに役立ちます。テクノロジーが他者によって宣伝されていると判断できる場合、それは私たち自身のメンタルスタンスに影響を与える可能性があり、（何らかの考え直しのリスクがあります）、それに応じて補償し、選択基準を選択する際に合理的に行動するよう強制する必要がある場合があります。
選択基準：
言うまでもなく、選択基準の選択は非常に状況に依存します。
個人的には、（一種のブレーンストーミング演習として）検討している各オプションの短い（15分）SWOT分析を（真剣に）状況のPEST分析と一緒に行い、より幅広い（技術的ではない）ことを確実にします分析の要因。
分散型VCSのSWOT
強み：
- 柔軟性-さまざまなワークフローを選択する自由度が高くなります。
- 低帯域幅/高レイテンシのネットワーク接続でのパフォーマンスの向上-分散チームおよびオフサイトワーカーに適しています。
- より高度なマージ機能により、より頻繁に分岐できます。 （これが良いことかどうかはわかりません）。
- ソースコードは、各開発者のマシンで「バックアップ」されています。 （これは、適切な障害回復計画を妨げる可能性があるため、これはかなり偽物です）
弱点：
- 柔軟性-異なるワークフローを選択する自由度が高いため、使用しているワークフローを定義して強制するために、追加の作業を行う必要があります。
- 複雑さと概念の難しさ（特にソフトウェア開発者でないチームメンバーの場合）。
機会：
- おそらく、柔軟性を利用して、ビジネスニーズにより適したワークフローを設計できますか？
脅威：
- おそらく、ワークフローの再設計に長い時間を費やして、コア製品に集中できなくなるでしょうか？
- 単純なツールでさえ必要な人や、やる気がない人がいる場合は特に、一部の人に簡単なツールを使用してもらうのは難しい場合があります。
集中型VCSのSWOT
強み：
- ビジネス組織とプロセスにインバンドの暗黙の通信チャネルを提供します。
- 可能なワークフローを（多くの場合は妥当な）サブセットに制限します。
- CIおよびその他の開発自動化ツールのセットアップを容易にします。
- （SVN固有）巨大なリポジトリをサポートします。
- （SVN固有）非常に安定しており、多くの保守的な組織で使用されています。
- トップダウンの指揮統制組織では、政治的に許容範囲が広いですか？
弱点：
- 柔軟性に欠ける。
- 低帯域幅/高遅延接続でのパフォーマンスが低く、分散チームやオフサイトワーカー（特にリポジトリが大きくなる場合）での使用が難しくなる
機会：
- おそらく、リポジトリのモノリシックな性質を使用して、開発者が製品をナビゲートし、互いのコードをさらに再利用できるようにすることができますか？
脅威：
- プロジェクトが突然非常に重要になり、他のサイトで作業している開発者を追加する必要がある場合、彼らはオフサイトでホストされている（彼らのために）SVNリポジトリを効果的に使用できますか？
- 開発者のセットが非常に大きくなり、開発者の調整が困難になった場合、単一の集中化されたリポジトリがボトルネックになりますか？ （他の方法でこれを回避できますか？）
結論：
使用するVCSは、個々の状況によって異なります。私が働いてきた多くの状況では、集中型ワークフローを備えたDVCSは問題なく機能しますが、ワークフローをサポートおよび適用するメカニズムを構築するための時間と労力を正当化する必要がありました。難しい。
結局のところ、この議論は次の質問を中心にすべきだと思います。どのワークフローが私たちのビジネスに最適ですか？使用するのに最適なツールは、その質問への答えから自然に従うべきです。