敏捷开发智慧之：定不定流程和模板？

缘起

（立项时）

甲：“你们的设计文档打算怎么写？”

乙：“到时候再说。”

甲：“应该有规范的开发流程和模板，才能写好设计文档。”

乙：“预先定义的流程和模板未必适用，敏捷开发崇尚推迟决策，只有在具体工作之前才能决定是否写，怎么写最好（maximizingtheamountofworknotdone）。”

甲：“你们组才3个人，能比组织级定义的流程和模板还好吗？”

敏捷开发定不定流程和模板？

先把话说绝点：敏捷开发不定义流程，不定义模板。为什么呢？

因为如果预先定义了流程，比如“必须写需求，需求评审过了才能写设计……先检查测试环境，测试标准定好了才能开始测试……”以及模板，则在千变万化的项目进展中，就极有可能多写了本可以不写的文档，多做了本科避免的事情，或者虽然没有“多”，但是形式却不合适。

这个道理如此简单，为什么前人却经常喜欢定流程和写模板呢？我们来看看CMMI的情况。

CMMI是最喜欢定流程和写模板的（组织过程焦点过程域OPF负责定期不定期地发现哪里有可改进的地方，而组织过程定义OPD则负责将其制定并宣贯下去），不但如此，还派出过程与产品质量保证人员PPQA检查实际情况与过程或产品标准的偏差。

CMMI这种工作方式哪里来的呢？

原来，CMMI是美国国防部的招标标准（CMMI3级及以上才能成为其供应商）。长期以来，军工、航空航天等领域保持了非常高的质量和产量（两者都远远高于我们熟悉的消费电子和互联网行业），而其首要目标，就是继承已有的成果，也就是按已有的流程和模板做。偶然有所创新，但其价值与继承已有成果不可同日而语，所以没有人会颠覆性地采用新的未经证实的流程或模板。对质量和产量的追求，驱使其整体持有保守的态度，这甚至会影响到其供应商的研发策略，比如IBM。

而另外一些行业则正好相反，比如热销的苹果手机，多年来业务不断变化的Google等。

首先这些行业有自己对质量的定义，比如不是可靠性99.9999%，而是易用性、操控性；其次其产量也不来自于标准的规模化的生产，而是来自于其创新性引发的市场反应和用户主动追逐。尽管这不影响苹果有自己的生产规程，Google也有自己的编码规范，但其价值与随时创新不可同日而语。这就引发了这些企业一致性地采用敏捷开发方法（日后会讨论“什么是敏捷开发方法”，进而会涉及“到底NASA、Boeing、Apple、Google谁在用敏捷开发方法”的问题）。

因此，不同行业基于不同价值观产生了不同的流程和模板理念，他们没有孰优孰劣之分，只有适合与不适合之分。

我的行业/项目/团队适合不适合定义流程和模板呢？

没有人比“我”更熟悉我的行业或项目了，所以这个问题不用问。

不定义流程和模板，可能会受限于团队的能力而把本可以做好的事情做差；定义流程和模板，可能会限制发挥或导致生搬硬套劳而无功。

两害相权取其轻，自然会发现答案在哪里。

或许由于项目、团队的不同，每次会得到矛盾的答案，这不稀奇也不奇怪，每次都是最好的答案就可以了。

“定不定流程和模板”的常见做法

敏捷开发过程与模板

多数企业做敏捷开发培训与咨询的目的，都是为了形成相对稳定、统一的敏捷开发过程，因此过程与模板是应该有的。否则连ScrumMaster都不知道自己要维持的秩序是什么样子的。

但是，在使用过程与模板的时候，不应该执着，而应该灵活。

动态使用的原则

不知道大家是否发现一个规律，就是每个产品都会有出现，兴起，鼎盛，衰落……这个过程，而打败他们的，往往是另外一个新兴的但却更简单的产品。究其原因，在初期由于老客户不断的要求，新产品的功能都会不断增加；增加了功能的新产品，增强了竞争力，因而也就更热卖；但产品复杂度到了一定程度，使用这个产品的门槛也就越来越高，新用户就越来越不接受这个产品了，市场反而被简单的产品所抢走。（详情参考产品之六爻：http://blog.csdn.net/cheny_com/article/details/5872882）

过程与模板也是如此，对老团队而言，在不断改进和细化；而新团队的门槛却节节攀升，最终造成在整个企业推广的时候，面临重重阻碍。

因此组织应该分层、分阶段地部署过程与模板，而ScrumMaster也要随机应变地维持秩序。

这一点对ScrumMaster的要求极高，因为”随机应变“不是被动的，就是看什么能推动就推什么，而是主动的，就是发现团队有什么问题，就知道流程和模板中哪些内容是用来解决这个问题的。

ref：http://blog.csdn.net/cheny_com/article/details/6940931