这篇文章是在InfoQ上发表的敏捷宣言十周年系列文章的一部分。
\在解决问题中寻找模式是人的本性，我们倾向于重用已知方法。有时候这是个有用的策略，但通常我们面对的问题与之前的问题并不相同，因此我们之前的解决方法也并不是解决新问题的最适合的方法。在软件开发的世界中，我们常会发现对“唯一正确的方法”，“最佳方法”的渴望。
\有趣的是，通常我们所谓更好的方法总是从过往的知识和经验而来。也就是说，我们很少抛弃已经学会的东西，反而直接就在上面发展。现在应该到了超越这种发展思路的时候，如果还说不上创建新的信仰体系，那么至少应该建立新的发展途径。
\在过去几年中，当我思考敏捷时，我意识到自己已经超越了（依托现有知识和经验的发展途径）。
\时光倒流重回十年前，我通往“未知”（一个超越既定规则的地方）的旅程是从核心极限编程实践开始的，之后更广泛地接触敏捷文化，接着赶了精益的潮流，顺便也没错过AgileUX、DevOps、Product Discovery等等。
\换句话说，这么积累下来，我对敏捷方法的理解和观点变成了这个样子：
\
以前，我相信整洁的代码就是一切，软件企业应该把代码放在至高无上的位置上，因为这是他们真正拥有的唯一资产。而后当我参与了一些紧跟时代的成功的软件大腕儿企业，才发现他们对整洁代码的关注是如此之小。实际上，他们视代码为负担，总想尽可能快地将其摆脱。
\并非每家公司都是一个样子。一些公司极度渴求重构和TDD。而对另一些公司而言，技术和实施方案的变化是如此之快，如果他们不站在潮流的浪尖之上，无论代码有多么整洁他们都无法生存下去。一些公司纠结于决策信息的缺乏，而另一些公司则为过量的信息所窒息。一些公司深陷于失败的管理，而另一些则缺乏执行力。
\我真的很享受嘲弄地看着一些人把敏捷当作“放之四海而皆准” 的方法。有很多有着不同痛点的公司，每家公司都在不同的时间点需要不同的解决方案。没有放之四海而皆准的方法！
\毫无疑问在过去十年中，敏捷帮我解决了许多在软件产品交付期间面临的典型的挑战。然而对我而言在过去四年中，瓶颈已经从软件交付转移到挖掘适合的产品，我面临的这类挑战不能通过应用敏捷和精益完全解决。
\过去十年我们身边也已经发生了许多变化。业务性质、对分布式开发的需求、使用的工具和技术、强大的网络和移动平台的普遍性，几乎一切都发生了变化。想想我们遇到了多少变化，很应该调整一下我们的原则和方法去适应新的情况。
\几年前，我写了一篇名为\"我不是在攻击敏捷宣言原则，我在渴求改进。\"的博文。这篇博文抓住了我在工作中应用敏捷原则时曾面临的一些挑战的本质。
\我确实认为“精益创业（Lean-Startup）”社区已经解决了许多问题。我已经有几年没见到敏捷社区有多少新成果了，但当我关注精益创业社区时，我感觉到了一股清新的气息。
\在Industrial Logic，我们已经达到了非常高的精益程度，几乎去除了许多标准敏捷实践，如backlog、用户故事、迭代、规划会议、回顾、每日站立会议，在某些情况下甚至去除了TDD和结对编程。取而代之的是，目前我们已经实践了几年客户开发、有效学习（A/B测试、伪装特性，...）、持续交付和其他精益创业的概念。迄今为止，我们都爱上了它，并且在当前的情景之下确实看到了不错的效果。然而，在我们继续前进之前，需要先理清一些头绪——这正是有意思的地方。
\几年前，创业公司，尤其是社交网站和移动开发方面的创业公司??，围绕着软件开发在敏捷和精益思想之上提出了一些有意思的观点。在最近的几年里，精益创业社区已经对此进行了很好的总结。他们已经把所有有意义的敏捷和精益思想封装了起来，但与此同时，他们也提出了一个敏捷和精益的新方向。
\我相信精益创业在今后几年中将会对软件社区产生重大影响。
\下面是我对今天的敏捷生态系统的看法：
\
精益创业社区很不错。然而我同样也为在软件开发领域之外所发生的事情感到兴奋，这让我更好地理解了软件生态系统。
\例如，多年来关于软件开发我已经了解了以下内容：
\- 软件开发过程和产品中的不确定性是固有的和不可避免的。请看这一链接。\
- 对一款新软件产品来说，在软件生态系统被使用之前（甚至可能要更晚些），这一系统将不会被完全理解或了解。\
- 可预见性悖论 —— 我们在软件项目之前花在规划和估算上的时间越多并不意味着我们的预测就越精确。请看这一链接。\
- 完全地说明或测试一个交互式系统是不可能的。请看这一链接。\
- 直到你有了一个解决方案之后才会对问题有充分理解。请看这一链接。\
- 如果做某件事很痛苦，那更频繁地去做它将会缓解痛苦。\
- 更频繁地抛开代码，让整体成本保持下降。\
- 更多的时候慢下来并留意你的周围（更紧密的反馈循环），这会让你前进的更快。\
- 随着越来越接近混沌区域，软件更快速地发展。\
- 压根儿没有什么最佳实践，全都与情境有关。\
- 通常最成功的产品会膨胀起来并被自身重量压垮。\
- 改善（Kaizen —— 小幅的、逐步的、持续的改进） 只能帮你进步到某个程度。改革（Kaikaku —— 突破性改善）能帮你到达飞跃的改进。\
我能够解释一下为什么我注意到软件开发中的这些行为，但无法真正解释这些潜规则。敏捷和精益方法确实帮我解决了许多挑战。然而我仍然不能解释这些潜规则。直到我偶然发现了下面两个概念：
\- 认知复杂性：我有幸参加了Dave Snowden于2008年在爱尔兰利默里克的一个主题演讲。他让我迷上了复杂适应系统（Complex Adaptive Systems），尤其是他的Cynefin框架。他有些很棒的主意，可以让软件社区受益。许多组织知道他们需要改变，但却害怕改变。他们在寻找安全可靠的方法来进行改变。Dave用这一方法解释了核心问题以及“安全失败实验”是如何真正帮助组织应对变化的。许多组织在奋力衡量错误的指标，迫使人们去欺骗系统。Dave关于“回顾一致性或基本归因误差和弱信号侦测”的观点对解决部分上述关心的问题很帮助。我尤其喜欢他在这里的叙述。\
- 幸福感预测心理学： Daniel Gilbert的书《撞上快乐》中的轶事和研究成果征服了我。它帮助我理解了在把我们自己投射至将来（或过去）时，头脑所玩的“脑补”把戏及其局限性。我才刚刚进入这一领域，前面的路还很长。\
最后我想留下一则古老的梵文偈颂作为精神的食粮。
\\\无论檀香木被切得多细，它也不会放弃芬芳，
\
\无论一名商人多么年老，他也不会放弃收益，
\无论如何在机器中压榨甘蔗，它也不会变苦，
\无论你变得多么有学识，也不要停止学习。
关于作者
\
Naresh Jain是Industrial Logic的总监，亚洲运营及敏捷教练。从组织变革到增强开发人员生产力，Naresh帮助组织拥抱、扩展和保持本质的敏捷和精益思想。目前，Naresh投入大部分精力传播和构建Industrial Logic的eLearning平台。他当前的领导角色要求他扮演各种不同的重要角色，包括理解市场需求、按优先级排序\u0026amp;设计解决方案、协调市场\u0026amp;销售策略、亲自动手开发（编码\u0026amp;测试）和最终部署\u0026amp;管理产品服务器。
查看英文原文：Naresh Jain: Dealing with Change in an Evolving Contextual World
\感谢郭晓刚对本文的审校。
\给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
62
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
