在写我最近的一篇关于我现在对连续一切的思考的文章时，我意识到有一些缺失的背景——我自己20多年来在软件实践中发生的革命的兔子洞里的个人旅程送货。It从可怕的抵抗到有限的适应，到激进。看回到今天，作为一个团队的一员来到这里，通过一个连续的视角系统地重新思考我们业务中的每一个功能和流程——这不仅仅是为了我们自己的利益，而是因为我们正在构建一个软件系统，为持续经济中的其他所有业务提供动力。但在这一过程中，这并不那么清楚。如果你想知道一个人如何从根本上改变他们的思想，那就阅读吧开。先，几句名言，定下基调……"亲爱的，在这里我们必须尽可能快地跑，只是为了原地踏步。如果你想去任何地方，你必须以两倍的速度运行。"―刘易斯·卡罗尔，《爱丽丝梦游仙境》中的"软件交付是一种不断改进的练习，我们的研究表明，最好的一年比一年好，而那些没有改进的人会越来越落后。"―妮可·福斯格伦，加速：科学精益软件和DevOps：建立和扩展高性能的技术组织"但我不想和疯子混在一起，"爱丽丝说，"哦，你不能不这样，"猫说："我们都疯了。我疯了。你疯了。""你怎么知道我疯了？"爱丽丝说，"你一定要去，"猫说，"否则你就不会来这里了。"―刘易斯·卡罗尔，《爱丽丝梦游仙境》中"很多已经实现的都是仿造的敏捷人员，他们遵循一些常见的实践，却未能解决更广泛的组织文化和流程。"―妮可·福斯格伦，加速：精益软件和DevOps的科学：建立和扩展高性能的技术组织我的旅程上的里程碑1997/8。我是微软新成立的在线运营团队的23岁新人。我已经在旧金山湾区创业公司工作了5年，从事各种商业运营和现场工程工作——所以雷德蒙德的人认为我知道数字和在线的工作原理（更不用说我以前的公司从事多媒体工具和电信/企业级软件，每隔几个月发布一次功能，耗时12-18个月）我每周都会接到新的任务来处理我们的网络运营混乱。这一次我被派到华盛顿州的Bothell，与微软发布过程的专家会面，该软件是在CD母盘公司印刷的，并通过像Egghead这样的零售商分发的CD上发布的。我被告知要和她合作，调整他们长达数月的难以置信的复杂过程，以适应我们需要做的在线发布。她走了进来，把一个3英寸厚的活页夹丢在桌子上。我的直觉是这不是简单的编辑。我在微软之前的公司门户网站（Portal）上市后离开了微软，因为我有能力为自己的东西播种。我开了一家艺术网站公司，Artloop。我筹集了370万美元的首轮融资。我雇佣了项目经理和内容人员，但我把开发外包了，因为在网络公司歇斯底里的旧金山，雇用工程师几乎是不可能的。由于开发站点的外观和性能都像$*，所以网站的大爆炸式发布被延迟了！&%&#*@. 因为与我的开发外包公司的合同条款，我不能悄悄地让开发网站上线和迭代。到它推出的时候，B2C崩溃已经发生，我拼命地试图出售一个B2B支点，以提高B系列，以保持灯亮。具有讽刺意味的是，实际的产品理念是创建一个实时的、众包的、有机的、迭代式增长的丰富艺术知识的数据库，它可以从小处着手，逐渐接近质量和全面性。我有没有把我的网站交付方式的愚蠢与内容传播方式的深刻真理联系起来？当然不是。哦，到2001年底，我又一次破产了，失业的时机已经成熟，要去犯一些新的错误。2003年。我是一家由风险投资支持的企业日志管理软件公司的新晋29岁产品管理副总裁，我以前是专业服务副总裁。我很高兴能负责路线图！我的董事会是一群销售人员，他们想知道我们的日志管理系统打算在什么时候报告用户行为和性能指标，并发现错误消息，这将完全转变为SIEM，因为他们听说ArcSight的销售正在腾飞。我的企业客户包括Bank One和Lehman Brothers（注意到目前为止，有一种模式是惊人地消亡或默默地吸收品牌名称吗？）需求路线图——他们何时能得到我们销售人员承诺的所有功能。然后我那些讨厌项目管理和管理的失控工程师发现了这种"敏捷"的东西？不！不！！！！！我们将致力于董事会希望实现的目标，这将在9个月内实现，我保证！2005那个支点的效果不太好。我们的4.0完整的前端重建和全新的实时关联引擎已经晚了一年，而且还在继续。我们没有为客户提供任何有意义的东西超过我们的记忆。所有这些敏捷的冲刺导致了一个不可能爱或销售的内部预览后，又一个星期五演示一个又一个星期五演示。当建造没有失败的时候，我在同年3月跳槽，成为当时12人的A系列Splunk的首席产品开发人员，目前仍处于隐形模式。有一个主要的分支已经好几个星期没能编译了，至少有12个关于什么特性需要在一个可行的测试版中出现的想法。这里的9位首席工程师听说了这个消息！*&@!#(@! 敏捷也是。该死！没关系。我要写一个60页的1.0 MRD，并建立一个路线图，让他们遵守。他们对路线图嗤之以鼻，但我们确实设法在大约4个月内发布了一个有一定可行性的1.0测试版，供公众下载有意思。有意思，纯粹是事后诸葛亮，我意识到用户开始喜欢Splunk本身是因为他们要么是系统管理员支持，要么是为各种新兴网站和服务开发的开发者。不断变化、以新的、有趣的方式中断的服务，以及各种神秘的错误，以便针对日益分散的面向服务和web2.0架构进行调试。我们的客户和我一样，都在应对新兴的连续模式。我们发布1.1，1.2，2.0，似乎每6-8周发布一次。我们有很多免费用户和一些付费用户。越来越多的反馈来自于支持案例、论坛帖子、帮助客户安装和使用该产品的当面会议。我得到了一个更普通的头衔：产品管理和支持副总裁，因为我们有真正的企业客户，并且与一家更保守的公司进行了B轮融资。我有支持工程师，但我的pm没有一个是最后一个。工程师们时不时地嘲笑和忽视我的路线图和mrd，但当我一次给他们带来一个问题，并附上他们的故事和请求时，他们会倾听。嗯。我能自动管理这些不连续的积压问题吗？让我们看看是什么可用。工程正在使用运行在我们服务器机房的Linux服务器上的Jira来跟踪他们的积压工作，并且仍然在谈论敏捷。但它对PM过程一无所知。我研究了一些PM需求和当前的路线图跟踪工具。它们都在窗户上运行。他们有一些很好的想法来自动化众所周知的实用主义营销"有效的需求"框架的基本原理，以跟踪增强请求、其他市场数据点、客户呼叫报告并将其传递到市场中问题。我们的最暴躁的联合创始人和首席架构师也是我们的IT人员。他告诉我不可能，不，他怎么在开一个窗户。你为什么不能用我们已经在运行的Jira设备？（早在Jira成为SaaS之前）所以我开始学习如何定制Jira来做我的PM工作。不断地思考如何通过门户网站来支持提交的所有邮件Salesforce.com网站的支持模块）输入到Jira的产品管理过程中。我记录了一些要求，并聘请了一家咨询公司来定制我想要的Jira它。分开，我也拥有文档。所有这些小版本都要求对每个现有主题进行检查，以确定它应该如何更改。支持人员不断地寻找新的解决方案来解决我们没有预料到的问题，也没有随着情况的出现而设计。工程师们开始在他们的个人公司博客账户上记录技术信息，当软件发生变化时，他们不必费心回去修改。通过当时的机器人类工具更新完整的手册是不可能的。知识库最终会成为手册的三角洲，比手册本身还要大！每个人都告诉我要把文档做成wiki。这不是灵丹妙药，因为我们的客户没有立即升级，需要从一些次要甚至是主要版本中找到文档。我怎样才能有正式的每软件版本的手册，它的结构是由许多参与者（如wiki）实时更新的？好 啊。我去找负责我们网站的阿什利谈谈如何做到这一点。我们开始定义，他开始构建一个定制的文档平台，可以像wiki一样在markup live中编辑，但我们可以同时为不同软件版本的文档实时编辑。我们开始使用它，并试图让全公司的员工在做出更改或发现问题时编辑实时文档。有一些是这样的。它至少能让我们的文档作者少一点疯了。再说文档和项目管理需求过程，今年我意识到还有一个与软件交付的持续革命相关的主要线索——我们的自助服务，免费的发行模式。与我以前参与过的纯自上而下的企业销售模式公司不同，客户必须弄清楚如何使用我们的软件，并保持足够长的参与度来完成这项工作