最近，CloudBees庆祝了它作为一家公司的10岁生日，我想分享一下我在办公室柜子里发现的一些笔记，这些笔记总结了我们两位创始人约翰·奥斯特豪特和约翰·格雷厄姆·卡明在成立公司之前进行的18次潜在客户访谈，就在互联网的余波中泡泡。这些当时硅谷的大小公司都在接受采访，你可以想象，所有这些公司发生的变化都是巨大的。由于收购和其他情况，有些公司已经不复存在，但下面是一些我认为值得与大家分享的怀旧轶事：•一家真正创新的多学科公司，今天被视为所有互联网公司的全球榜样，在采访时，约有33000多名员工，在采访时有280名员工-其中100人是软件工程师，显然只有3人在QA工作！•后来被EMC收购的虚拟化业务中的一家主要颠覆性公司目前有60名工程师，我目前能够调查的人数是9000名左右总的来说敏捷宣言刚刚在2001年初出版，在这些采访笔记中，我找不到任何关于通用商品术语和术语的参考比如敏捷方法、Scrum、看板、持续集成和持续交付。然而，当我仔细阅读这些笔记时，我惊讶地发现，我今天所听到的关于敏捷支持阻止者在我作为CloudBees Accelerator产品经理的角色中每天与CloudBees潜在客户合作的许多问题、顾虑和问题，在10年前就已经存在了！下面是一些我收集到的引语，大致概括了笔记的全部材料：•"我们花了数百万美元使构建更快，但我们并不满意"•"我们正努力及时发布版本，这通常是由于缓慢和不可靠的构建"•"我的软件构建需要的时间越来越长，这是由于扩展"如果你能把我的构建速度提高10倍，那将是巨大的！"与2012年的软件开发世界相比，快速地将这一点放在正确的角度上，今天我参加了一个合作伙伴的讨论，我们讨论了汽车行业的一个前景，即每晚构建8-9小时，开发人员增量构建超过2000万次，这显然会影响工程生产力，并禁止其他敏捷开发方法的有效应用基于地点在这些采访中，我们的两位创始人编制了一张图表，说明了CloudBees应该建立以实现和实现的关键优先功能和价值主张，我认为这是非常有趣的分享你：所以CloudBees的旗舰产品CloudBees Accelerator是为实现上述功能而设计和构建的—在哪里10年后的今天？•10倍的构建速度，在几乎90次的访谈中都被要求作为一个期望的功能：对于我们的绝大多数客户来说，将其完整构建时间提高10倍是当今司空见惯的事情。在过去的一周里，我们听说我们的加速系数超过了30倍，甚至超过了30倍！•支持更多平台：为了确保我们的产品尽可能与市场兼容，CloudBees Accelerator产品团队不断审查软件行业中最常用的平台，并考虑支持其他平台。在撰写本文时，CloudBees Accelerator运行在所有受支持的Windows平台上，包括RedHat、SUSE和Ubuntu在内的许多Linux发行版，以及SPARC和x86的Solaris上。总而言之，我们的自动化构建和QA通道每天都在覆盖14个主要的支持平台！•更好的依赖性跟踪：CloudBees Accelerator与其他任何软件构建解决方案的主要区别在于它能够检测、跟踪、可视化和对完整和有保证的依赖性信息作出反应，而无需任何时间开销。这也是实现构建的大规模并行化和分发的原因，而构建又实现了显著的速度提升。•调度和自助构建：这并不是CloudBees Accelerator最初设计用来实现的功能，但考虑到市场对软件构建速度问题基本解决后自动管理端到端构建测试部署工作流的能力的需求，CloudBees决定实施并引入electronic commander。鉴于CloudBees Accelerator最初计划实现的最优先功能的全面覆盖，该产品下一个需要解决的问题是什么？基于我们多年来收集的所有用户数据和知识，尤其是软件构建环境，以及软件开发最佳实践，作为CloudBees Accelerator的产品经理，这是一个非常容易回答的问题：通过彻底改变软件开发人员增量构建的方式，在一个扩展的敏捷开发方法论的背景下，优化每个软件开发人员的生产力和效率！如果您觉得上述声明有趣，并想了解更多详情，请随时联系我的drosen（a）electric-cloud.com网站. 同时，请继续收看！