有“不适合走敏捷的项目”吗？
在今年的架构审计中，聚焦面向行业云的规划与研发，敏捷是我们的重要关注点之一。在架构审计访谈过程中，曾接触过一个项目，他们被教练下了结论——“不适合走敏捷”，那么究竟什么样的项目才适合走敏捷呢？这里有一个关键概念需要首先澄清：什么是敏捷？根据上面这一场景的上下文分析，我主观臆测一下，教练结论中的“敏捷”可能是狭义的敏捷，应特指“Scrum”。广义上的敏捷，作为一种极朴素的研发思想，对解决产品/项目研发端到端的价值交付过程中的各种问题都适用。从这个意义上，敏捷更像西游记里的如意乾坤袋，各种我们熟知的方法、工具、技术、实践，包括软件工程层面的，管理层面的，思维层面的，甚至灵性层面的，似乎都能往里装，持各种五花八门证书上岗的金光闪闪的敏捷教练们，也似乎包治百病，上到组织顶层战略设计，下至基础设施环境建设，很是抖擞神通。
话说敏捷圈多年来乱象丛生，各种概念，各种门派，各种认证，各种身价。一些概念有时候被人为的造出来就是为了待价而沽。真正的好方法从来都是在解决问题的过程中被总结出来的，是带有典型应用场景与问题语境的，理论上不存在“万能公式”式的方法（，即按照某一套方法与工具，就能够推导出产品或项目的成功），也不存在“过时”、“OUT”的方法（，只能说，这一方法对应解决的这类问题，在当下已不是制约您业务发展的核心关键问题）。
作为一名“无证执业”的方法学咨询顾问，对方法（Methodology）简单粗暴的理解就是：不管黑猫白猫抓住老鼠就是好猫，不管啥方法，不管在端到端交付过程中的哪个环节上应用，只要能够解决实际问题，就是好的、有效的方法，当然，这可能与方法本身的逻辑或模型有关，更与方法在项目中具体的落地方式与姿势有关，而这正是顾问和教练价值体现的地方。是不是姓敏捷？WHO cares？
