敏捷开发般若敏捷系列之十三：传播敏捷十戒（一）

这是敏捷开发般若敏捷系列的第十三篇。（栏目目录）

今天翻看微博，偶然看到宗教人士编写的“传福音十戒”，深以为然，稍作修改写成传播敏捷十戒。与原文相比，实际上只改动了1/7/9三条中的个别词汇，可以说这些注意事项是通用的。

传播敏捷十戒

一：切不可不传敏捷起源及其大背景。
二：切不可只用口传。
三：切不可以真理的化身自居。
四：切不可只说不听。
五：切不可彼此攻击。
六：切不可忘了先骂自己。
七：切不可满嘴“敏捷黑话”。
八：切不可不讲道理。
九：切不可全盘否定传统开发。
十：切不可作假见证。

一：切不可不传敏捷起源及其大背景

敏捷开发不是第一种出现的开发方法，也不会是最后一种，因此一定要理解为什么它会出现在2000前后左右。2000年前后是互联网开发的高峰期，现在我们中国的所述互联网巨头都是在那段时间成立的，国外的则略早一点。互联网虽然未必是最早诞生敏捷开发的行业（实际上敏捷鼻祖应该算是日本制造业的“精益生产”），但却绝对是敏捷开发得以成长、发展和壮大的阵地。有几个特征在互联网开发中是鲜明的，也几乎只有敏捷开发才能与之适应：1. 失去了客户的概念，需求也因之模糊如果说项目型开发还能怪罪客户“需求模糊”的话，多数互联网软件则连这个借口都找不到。由于没有特定的客户，自己摸索需求、“拥抱变化”也就成为必然。只关注最重要的需求、拥抱变化使得互联网企业得以逐步摸索自己产品的实际功能。2. 没有特定的交付期，总是“越早越好”以往从来没有一种产品像互联网产品一样对尽早交付有如此的追求的。在项目模式下，或传统的生产-销售模式下（如Word，Windows，ERP），时间点不是最关键的。Word曾经跳票4年，从原定的一年完成推迟到五年，但仍然没有影响其霸主地位。但互联网行业就截然不同了，谁敢比别人晚五年推出“更好”的功能？实际上无论迟到者有多好，多数用户都会选择留在原有网站或产品上。“互联”二字使得用户群本身成为产品的一部分，而功能则退居其次。尽早获得用户群成为互联网行业成功的不二法门。3. 开发人员参与需求和设计，对工作主动性要求提高在一个大型的军工、银行项目里边（这是软件最早应用的领域），开发人员参与需求和设计的概率和数量都很低。或者说，开发人员不是项目成功的关键，即使换了另外一批程序员，只要需求和设计做得好，项目依然能成功。在这类项目中，遵从需求和设计以便保持一致性是最高价值观。但互联网软件则不然，因为没有人能完美地提前做好需求和设计工作，很多问题遗留给了一线工作人员。而且由于互联网软件的平面化，也就是开发者也往往是自己产品的用户，比如QQ、新浪，开发人员往往能更好地捕捉和定义新需求。在这类项目中，创新和快速改进是最高价值观。
所以，我们常常说的“少写中间产品（文档）”“快速迭代”“拥抱变化”“激励个体”之类的价值观，不是天然胜过其前辈，而是特定时期特定领域的产物。在应用敏捷时，虽然不应该拘泥于“国情”（很多“国情”正是我们要改变的东西，没有“符合国情”的必要），但要冷静思考实际产品或项目的需要，确认核心价值观，并选择那些与之匹配的实践。

二：切不可只用口传

敏捷开发是来自一线用于一线的方法，需要基于实践来学习和传播。这一点对开发人员和项目经理而言可能都问题不大，但对咨询师而言却是个挑战，而他们正是敏捷开发的主要传播者。本人在“完整学习”用户故事、Product Backlog、Sprint Backlog的时候，正值不做研发转作咨询的时期，最开始觉得这几个概念非常好理解，所以讲解起来也很“轻松”，差不多有一个小时就讲完了。可后来在一家公司做产品定义工作，以及在之后开发“火星人敏捷开发工具”的时候发现，情况远非如此。比如，尽管在长达三年的过程中总结出了“商业计划”是影响优先级排序的第一因素，但火星人至今仍困扰于第一次发布优先推出哪些功能的问题。实际上这个问题涉及到营业模式、营业收入组成和未来升降的趋势。为了解决这个问题，传统ERP销售和Clash of Clans这种手机游戏的收费模式都曾在我们的研究之列。到底哪个更好，有待实践证明。对于没有机会参与实际开发或管理的咨询师，也有机会实践敏捷。实际上，敏捷开发的基本思维方式并不一定限定在开发语境中。“少写中间产品（文档）”“快速迭代”“拥抱变化”“激励个体”这几个字，可以适用于很多其他场合。比如在一个销售会上，销售人员应该少谈拜访了什么客户，见到了什么人（这些全都是中间产品），而是多预测这一时期的销售情况，尤其是近期潜在的成交客户，并提出计划或寻求支持以促成销售（少说那些中间产品）；对于新的产品方案，产品经理要通过参与销售会，积极听取来自销售人员的反馈，以便做出修订乃至取舍决策，同时这种参与也会让产品经理识别新的产品需求（“快速迭代”，“拥抱变化”）；不应该为技术支持人员制定严格的制度细节来保证他们的出勤率，而是应该用制度来激励，比如对其售后活动按其客户满意度给予出勤奖励，或将提成中的一部分发给参与售前的高级支持人员，都能更好地“激励个体”……这些都是我们曾经亲自经历的与开发无关的语境中的敏捷做法。所以，实际上敏捷开发可以渗透到“骨子里”，而不是停留在口头上。（待续）