分布式版本控制系统目前在Gartner的炒作周期中可以放在哪里？[关闭]

编辑：考虑到最近的低票（目前为+ 8 / -6），从我的角度来看，从程序员的角度来看，Gartner的生命周期是有偏见的指标。这是我要提交给管理部门的论文的一部分，管理类型是Gartner的读者的一部分。

考虑到DVCS的曝光度和热情（“可以”视为炒作，或至少受到这样的攻击），请在阅读此问题时考虑以下问题：“我如何使用Gartner的炒作周期说服管理层DVCS已准备就绪（或为我们准备好了，而不仅仅是炒作”

仅仅问DVCS是否炒作是没有建设性的，Gartner的炒作周期是一个比问问更客观的工具（即使该工具被认为是有偏差的）。如果您知道任何其他乐器，请务必提及。

编辑2：我同意Gartner的生命周期并不适用于所有技术，但我认为它可能产生了足够的嗡嗡声，因此有些人认为它是炒作，因此，至少应通过在仪器中使用此工具来对其进行评估/思考。为了证明/反证它在任何程度上。我是BTW DVCS的拥护者。

编辑＃3：感谢您的回答。Bounty前往Caleb，提供详细和实用的建议来回答我的问题。可以接受的答案是给philosodad提供了另一种有用的工具并回答了我的问题之外。

我正在研究一份白皮书，以支持公司采用DVCS而撰写，但我偶然发现了社会证明的概念。我想证明采用DVCS的社会证据并不一定是对货物的狂热，因此我现在偶然发现了Gartner的炒作周期，该周期描述了5个阶段的技术成熟度。

我的问题是：在炒作周期的特定阶段，分布式指标控制系统（通常是指git，mercurial，bazaar等）的当前位置可以显示什么？话说，您是说目前对DVCS的期望是a）开始，b）膨胀，c）减少（幻灭），d）增加（启蒙）或e）稳定（成熟），以及（更重要的是）为什么？

我知道这是一个难题，涉及主观性，但是我将为特定阶段的最清晰论据/证据提供答案（和传统cookie）。

炒作周期衡量的是特定事物产生的新闻/嗡嗡声的数量，而不是事物的实际使用或它的实际生产率值。所以...从这个角度来说，DVCS的新闻周期已达到峰值。实际上有足够的人在使用它，并鼓励其他人使用它，它在科技界引起了很多轰动。一旦广泛采用，我希望新闻/嗡嗡声会随着新事物的出现而逐渐消失，然后随着人们开始更完全地理解系统而再次上升。

查看炒作周期的一种方法是查看新采用者的数量。新技术的采用者趋向于遵循与炒作周期相同的精确曲线形状。有道理的是，随着新技术的大量采用，新技术的嗡嗡声将迅速增长。早期采用者传播了创新，而中级采用者引起了轰动。

迅速采用创新过程中的嗡嗡声必定会引起人们的注意。如果有很多人知道某事但不知道某件事，那么他们将比有经验的用户有不同甚至更大的期望。这就是炒作的来源。

采用率达到顶峰后的嗡嗡声将会下降……部分原因是，较早的，不切实际的期望没有得到回报（DVCS可能会使您的工作效率更高，但并不能解决您的所有问题），部分原因是其他事情正在经历快速的采用期，并且占据了所有的思想份额。炒作无常。

但是在某个时候，您开始获得相当稳定的新用户采用率，创新已成为常态，新用户希望知道如何使用他们已经决定需要使用的东西。那么，围绕创新的嗡嗡声就是人们现在正在使用它而实际上在做什么，而不是如果他们正在使用它就可以做什么。

因此，如果您采用炒作曲线并将其置于采用率的S曲线旁边（请参阅Everett Rogers“创新扩散”），您会期望随着S曲线的变化，炒作将在S曲线最陡峭的地方达到最高点。方向，并随着创新达到其完全市场饱和而再次上升。

DVCS处于快速采用阶段，因此我们可能处于炒作周期的高峰附近。

我并没有声称自己是炒作周期方面的专家，但是我将提供一些观察结果：

1. 炒作周期似乎更多是期望和媒体报道的产物，而不是技术本身的特征。我的字典说炒作是“过度或密集的宣传或促销”。它把宣传定义为“媒体对某人或某物的注意或关注”。媒体是大众传播各种渠道的统称。

2. 如果您接受上一点，那么仅当媒体涵盖了给定技术时，炒作周期才适用。

3. 尚不清楚炒作周期是否适用于所有技术。科学期刊上充斥着主流媒体从未注意到的进步报告。没有媒体的报道，期望就不太可能被夸大，并且可以避免幻灭的低谷。

4. 分布式版本控制系统并不是对旧版本的改进，而是新的想法。将它们称为炒作周期应该预测的那种“新兴技术”很容易。

在您开始建立的情况下，其中 DVCS的版型上的炒作周期图，你需要建立一个分布式版本控制是受在所有的炒作周期的情况下。分布式版本控制是否作为“技术”获得媒体报道？对于分布式版本控制，现在是否存在过高的期望？当DVCS产品达不到预期效果时，DVCS用户可能会幻想破灭吗？

在我看来，分布式版本控制只是对现有产品类别的改进，就像SVN对CVS的改进一样。如果您要绘制SVN的采用率图表，我认为您不会得到看起来像炒作周期的图。取而代之的是，您会得到一个图，该图稳步增加直到市场支配地位的稳定期，然后随着“ git”之类的分布式系统的普及而缓慢缓慢下降。

如果您确实需要一个炒作周期的答案，我建议DVCS在对非分布式版本控制系统感到失望/沮丧的时候加入游戏，并随着采用率的提高而不断提高启发性。

我建议不要依赖炒作周期，而应该关注分布式版本控制的采用率及其原因。有大量传闻表明，人们之所以转向DVCS是因为它有效。另一方面，我没有听说有人因为失望而切换回非分布式系统。要获取一些硬数据，您可以尝试与Beanstalk等托管公司联系。另外，请注意集中式系统和分布式系统之间的互操作性。我听说'git'与SVN配合得很好。集中式系统在公司领域仍然可以很好地工作，因此强调“玩得很开心”

更新以响应OP的编辑：

我如何使用Gartner的炒作周期来说服管理层DVCS已准备就绪（或准备就绪）[？]

我认为有一些方法可以在这里提供帮助，并且都依赖于硬数据：

Google趋势。Google显然收集了大量有关网络上的内容以及人们搜索的内容的数据。几天前，我寻找（但找不到）有关分布式版本控制炒作周期的证据。http://trends.google.com/表示，当我将区域限制在美国时，dvcs或分布式版本控制一词的数据不足（世界范围内dvcs的结果似乎并不相关或没有帮助）。搜索更具体的术语会更好一些，但是由于诸如git和mercurial之类的产品名称具有其他含义（谁知道？）这一事实使情况变得复杂。git的结果 显示可能部分归因于版本控制系统的趋势：

为了使版本控制更具体，我尝试了git repository：

还有一个...弄清楚如果人们采用git，那么使用git命令寻求帮助的趋势应该会越来越大，我尝试了git pull（蓝色），git commit（红色）和git rebase（金黄色）：

最后一张图似乎提供了人们采用和使用git的最佳证据。

谷歌搜索。

尝试简单地搜索诸如分布式版本控制之类的术语，并记下您发现的前25条文章上的日期。绘制结果。我发现大多数热门歌曲的日期都在2007-2009年之间。如果大肆宣传，并且可以证明大多数媒体报道发生在3-5年前，那似乎是很好的证据，表明我们已经超出了虚假预期的顶峰。

收集使用DVCS的项目的示例。

开源世界中有很多示例，包括Linux之类的大型示例。（Linus Torvalds创建了git来帮助管理Linux开发。）对您来说更有用的是使用DVCS的公司示例。（如果经理们讨厌过早采用某项技术，那就太落后了。）炒作就是-对技术或产品的热议。如果您能找到公司采用DVCS的证据，那么这将有助于反驳“只是大肆宣传”的论点，也许比其他任何论点都更好。

最后提示：

• 请明确点。您的公司不会采用全部技术-您将采用特定产品。有些产品总是会不如其他产品成熟。选择两个或三个著名的DVCS产品，并展示每种产品如何适合您的开发过程。经理比模糊的承诺更喜欢具体的想法，因此从特定角度分析技术会使他们感到更自在。

• 这不是全有或全无。任何使用DVCS的实际项目仍将拥有一个中央存储库，因此可以很容易地避免担心失去对皇冠珠宝的控制。

• 无需放弃您当前的系统。某些工具（如git）可以与现有的版本控制系统（如svn）配合使用。因此，您可以轻松地将DVCS添加到您的开发过程中，而无需付出任何代价。

• 从小开始。除非您在一家只有一个项目的小公司中，否则将DVCS轻松整合到您的一个或两个项目的流程中应该很容易。您不必先跳头-只需踩一下脚趾即可。

简而言之，确定阻力点并尽可能清楚地解决它们。

特定阶段的论据/证据

不论处于哪个阶段，都必须与“专业技术已使用10年以上”这一事实相匹配，因为分布式VCS TeamWare的存在已不止于此：pdf以下用户指南的日期为2001年7月。

根据Wikipedia的说法，TeamWare的最大部署是在Sun本身内部，（在少数情况下除外）它是唯一使用的VCS（使成千上万的开发人员使用该工具）。TeamWare已用于管理Sun最大的源树，包括用于Solaris操作系统和Java系统的树。

Wikipedia文章引用了TeamWare的架构负责人Evan Adams的Usenix消息，其中特别指出：

1991年春季，我们决定实施TeamWare项目...

TeamWare是从几个常用库构建的一组命令行和GUI工具。这些库由TeamWare组提供，供TeamWare应用程序使用。它们未提供更一般的用途。

TeamWare是鼓励并行开发的代码管理产品，它建立在SCCS之上。用户制作SCCS层次结构的副本（转移），从而创建个人层次结构。在此层次结构中，用户进行并测试更改。然后将这些更改集成（回输）到原始层次结构中。如果集成层次结构包含不在用户层次结构中的更改，则TeamWare将检测到存在并行更改，并拒绝集成。因此，用户在集成之前必须将集成层次结构中的更改合并到自己的层次结构中。TeamWare还包括filemerge实用程序，这是一个图形化的三向差异程序，允许用户合并并行更改。TeamWare跟踪源文件更改（SCCS增量）和文件重命名...

如果您有兴趣，请在此处找到更多详细信息：

• 埃文·亚当斯（Evan Adams）的《老人与C》
• “孙厂房展示Teamware转移用户指南”在甲骨文/ Sun的网站- PDF ^2001年7月，HTML

^{据我回忆，当时的集中式CVS / SVN具有能够在Windows和Linux上运行的优势，而TeamWare（SCCS）已被锁定在Solaris文件系统中（在Linux上，它运行或多或少，如果有人知道如何破解）虚假的“零校验和”错误）。}

我的答案：

我认为答案就在“过高的期望峰”上升的肩膀上的“互联网电视”和“云计算”之间（尽管我认为这两者在过去几年中发展很快）。

炒作周期的性质：

据我了解，在整个炒作周期中的发展，其特征在于对特定技术利弊的意识不断发展，而不是客观地衡量“成熟度”（无论如何）。

在我们积累了足够丰富的经验以建立平衡（独立）的观点之前，人群动态（自然地）一直处于主导地位，具有高度相关性的观点几乎没有多样性，细微之处或分析深度。

在“幻灭的低谷”中和在“过高的期望峰值”中都是如此。

如果社区要产生广泛而多样的不同意见，并深入分析何时何地适合部署DVCS，何时何地不适合部署DVCS，那么我们可以推断出自己处于“生产力高原” （或至少在“启蒙坡度”的上方）。

另一方面，如果讨论的重点是技术的优势（或其他方面），而不考虑其所处的竞争格局的低谷和低谷，那么我们可以推断出我们要么处于“高峰期”，要么处于“高峰期”。期望过高”或“幻灭低谷”。如果社区被火焰战争分成营地，我们甚至可能同时处于两个阶段。

:-)

根据以下标准评估DVCS：

从到目前为止我在演讲中看到的相对较浅的分析，以及相对缺乏负面评论的角度，我估计我们目前正在攀升“过高的期望峰”，并提出问题（例如此问题）有些人正在准备另一边的斜坡。

我认为（从公司的角度来看）DVCS技术成熟度的一个有力指标将是辩论不再只是问“为什么要使用DVCS？”。“如何才能最好地围绕DVCS构建我们的工作流程和流程，以最大程度地为组织带来收益？”。

从我所看到的，我们还没有全部。（尽管我们一些更老练的同胞正在引领潮流）

炒作周期在决策中的作用：

“炒作周期”模型是行为偏见的模型，它可以帮助我们了解自己的心理状态。如果我们可以确定某项技术被他人大肆宣传，那么这可能会影响我们自己的心态，并且（冒着一些三思而后行的风险）我们可能需要做出相应的补偿，并迫使我们在选择标准时表现合理。

选择标准：

不用说，选择标准选择与上下文密切相关。

我个人会（作为一种头脑风暴练习）对您正在考虑的每个选项进行一次简短的（15分钟）SWOT分析，并（认真地）对情况进行PEST分析，以确保您带来更广泛的（非技术性）分析中的因素。

分布式VCS的SWOT

优点：

• 灵活性-选择不同工作流程的更多自由。
• 低带宽/高延迟网络连接上的性能更好-分布式团队和现场工作人员的更好。
• 更复杂的合并功能，使您可以更频繁地分支。（我不确定这是好事）。
• 源代码在每个开发人员计算机上都“备份”。（这很伪造，因为它可能会干扰正确的灾难恢复计划）

弱点：

• 灵活性-因为我们有更多选择不同工作流程的自由，所以我们需要做更多的工作来定义我们正在使用的工作流程并加以实施。
• 复杂性和概念难度（尤其是对于非软件开发人员而言）。

机会：

• 也许可以利用灵活性来设计更适合业务需求的工作流程？

威胁：

• 也许我们将花费这么长时间重新设计工作流程，而将精力集中在核心产品上？
• 有些人甚至很难使用简单的工具，尤其是如果他们不认为他们是必要的或没有动力的话。

集中式VCS的SWOT

优点：

• 为业务组织和流程提供带内隐式通信渠道。
• 将可能的工作流程限制为一个子集（在许多情况下是合理的）。
• 使设置CI和其他开发自动化工具更加容易。
• （特定于SVN）支持庞大的存储库。
• （特定于SVN）非常稳定，已被许多大型保守组织使用。
• 在政治上更容易接受自上而下的指挥与控制组织？

弱点：

• 不灵活。
• 低带宽/高延迟连接上的性能较差，这使得分布式团队和异地工作人员更难以使用（尤其是在存储库变大的情况下）

机会：

• 也许我们可以使用存储库的整体性质来帮助开发人员浏览产品并更多地重用彼此的代码？

威胁：

• 如果该项目突然变得非常重要，并且我们需要引入其他在其他站点上工作的开发人员，那么他们是否可以有效地与异地托管的（为他们提供）SVN存储库一起工作？
• 如果开发人员的数量庞大到难以协调的程度，那么单个集中式存储库是否会成为瓶颈？（我们能以其他方式解决这个问题吗？）

结论：

使用哪种VCS取决于具体情况。对于我工作过的许多情况，具有集中式工作流程的DVCS可以很好地完成工作，但是我不得不证明建立支持和执行工作流程的机制所花费的时间和精力是合理的（是）困难。

最终，我认为讨论应该围绕以下问题展开：哪种工作流程最适合我们的业务？最好使用的工具应该自然而然地来自该问题的答案。