目录：

敏捷开发智慧敏捷系列之一：序言

敏捷开发智慧敏捷系列之二：写不写文档？

敏捷开发智慧敏捷系列之三：做不做架构设计？

敏捷开发智慧敏捷系列之四：每日立会开多久？

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

敏捷开发智慧敏捷系列之六：之一～之五的小结

敏捷开发智慧敏捷系列之一：序言

本文将解决各种敏捷中需要辩证思考的问题，包括：写文档还是不写文档？拥抱变更还是迭代期内无变更？持续交付的产品因为不完整被客户鄙视怎么办？做架构设计还是不做？突出进度忽略了质量怎么办？我们不用文档就能开发但客户偏偏要文档怎么办？自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办？……

缘起

敏捷开发中一直有几个根本问题无法回答：什么是敏捷？怎样知道我是否敏捷了？应该怎样推行敏捷？敏捷的未来会怎样？……

开始业界还有压力，因为这些问题如此难以回答。后来这些问题问得多了，大家也就释然了：“这些都是没有答案的问题。”

身为投身业界较早的一员，感觉草草收场太有点对不起那些心中一直有疑问的后来者了，那种感觉就像黑暗中侥幸躲过一块拌脚的石头，总是想停下来把它除掉。

最近在看一些业界之外的东西，才知道这些问题在很久以前就解决了。答案非常真切，能令接触敏捷很久的我一看就知道问题已经结束了。

不过，这个答案相当不容易用语言描述，憋了很久还是没能写出来，现在和最近的将来都心里明白但写不出来。

本系列不是直接描述这些根本问题的答案的，而是最近在微博、博客上又看到一些关于敏捷实践的纷争，而心里很清楚纷争的原因，所以特写此系列帮助后来者辨析一些概念，建立一些基本的思考方法。

兴许写几篇这个系列，就能帮我把那个系列写出来了呢。

题解

一直以来都有数据与信息的辨析。就是说数据是死的，要从中分析得到信息，才能对人有所帮助。

实际上完整的层次结构是：数据，信息，知识，智慧。这个是在《冬吴相对论》的很早一期中顺带提及的，但对我们推广敏捷很有帮助。

数据，基本上接近客观事实，不只是指数字，也指那些真实发生的所有事情，对应各种真实的敏捷案例。

信息，指从实际事情中提炼出来的有意义的实践，对应我们看到的各种用户故事、自动化测试、测试驱动等敏捷实践。

知识，指这些有意义的实践被文字化描述，广为传播。

智慧，指这些广为传播的实践的背后，所蕴含的真正道理。

数据与信息，都是受到“因缘”约束的。因是内因，缘是外部条件。

（这个案例不是敏捷开发的，但很直观）“在一家数字电视企业，人们大规模地做了软件仿真代替真实硬件，来防止太多环节的硬件捣乱”，这整句话就是数据，而“软件仿真”就是从中提出的信息。若把它写下来传播，就成了知识。

但是是不是哪里都适用呢？不是。

当时的内因，在于这家企业的研发团队很强（是我个人从事一线研发9年中经历过最强的），能够完成这一系列仿真，这个是追求卓越工作的内因；而外部环境中，从前到后硬件环节多达10层有余，客观上导致了不仿真是开发不下去的。

像这种实践，就存在很大的因缘成分，一旦离开因缘，很难重现。

敏捷开发中的多数实践要好得多，因为之所以被抽取出来，就是多少存在共性和可推广性。但这并不表明其可以无限超越因缘限制。

在敏捷开发中大家都很崇拜案例，因为案例是真实的，表明这件事情真正发生过。所以每当一方能指出“某某公司就是使用XX方法，从而才能……的”的时候，都会感觉非常立刻找到了答案，无需多说。

但是案例背后的问题在于：案例太真实了，以至于它们有的只能在一个地方发生，有的甚至只能发生一次。

智慧敏捷

而智慧，则是超越因缘的。（之后我们会看到其实“妙智慧”就是“般若”才真正超越因缘）

那个团队为什么使用软件仿真？因为追求卓越工作？因为要克服硬件限制？当然不是。

一家企业不会无缘无故追求卓越（尤其是这种内部技术层面的），而要克服硬件限制，加班加点多测试几次也能通过。

早在开始，团队并没有尝试软件仿真绕过硬件，也在以普通的妥协和加班来换取硬件大发慈悲，直到遇到一个最不讲理的硬件：IC卡。这东西连个显示界面都没有，不能单步运行，不能显示中间状态，就傻乎乎地以极低的速度执行极少数业务命令，其他一切无视。这是第一次被逼无奈，放弃加班加点或多和IC卡开发者沟通之类的笨方法，开始用仿真卡代替真实卡。

而在这一活动被证实简单有效后，其他几个不太讲理的硬件也被仿真了，最终系统越做越顺。曾经有一年聚会的时候，得知当时的市场占有率是60%（之后不详）。

在整个过程里边真正驱动大家改变看法的，不是“追求卓越”，而是：“到底哪种方法最快呢？”刚开始答案是“蛮干”，而后来则是“巧干”。

千万不要误解“蛮干”，在很多情况下“巧干”很容易产生需求镀金和过度设计，蛮干反而最快；但也不能总是蛮干，有时候撞上南墙，还是要巧干才行。

那到底蛮干好还是巧干好？都不好，他们都属于“信息”层面的东西，受到因缘的限制。这个问题一旦这么问，就无解了。

好的问题是：“到底哪种最快？”每次问这个问题，每次答案可能都不相同，但每次答案却总是正确的，这是智慧。

本系列会帮助辨析一些常见的问题，来探讨如何智慧地使用敏捷方法。这些。问题包括：

写文档还是不写文档？拥抱变更还是迭代期内无变更？持续交付的产品因为不完整被客户鄙视怎么办？做架构设计还是不做？突出进度忽略了质量怎么办？我们不用文档就能开发但客户偏偏要文档怎么办？自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办？……

这些问题没有开头提的那些问题那么本质，但是也能反映出一些敏捷实践层面不好解决的问题，在智慧层面其实早有答案。

这些问题几乎都是本人在工作中碰到或培训/咨询中被问到的问题，若掌握了智慧层面的内容，这些问题即使被第一次问到而之前从没考虑过，也能在5分钟后让发问人满意而归。

每个人在理解了敏捷开发中的智慧后，都能做到这一点；或者反之：当事人之所以困惑良久而来发问，是因为一直没能超脱于因缘之外观察敏捷实践背后的智慧。

敏捷开发智慧敏捷系列之二：写不写文档？

缘起

“我们产品已经做完了，客户说要补上需求文档，可我们只有用户故事，这个文档应不应该写呢？”

“没有这个文档，客户能验收吗？”

“不能，客户要开课题评审会，这个是评审会材料之一。”

这个文档要不要写呢？写，为什么？不写，为什么？写怎么写？不写，怎么不写？

为什么敏捷不写文档？

先把话说绝点，敏捷就是不写文档。那为什么不写文档？

为了减少浪费。

敏捷认为所有中间产品，需求，计划，设计，测试用例……都缺少客户价值，客户最想要的价值，无疑是最后的可运行的软件。因此所有中间文档都应该省略省略再省略，直到不写。

不在对客户没有价值的东西上面浪费时间，这是敏捷不写文档的真实含义。

只是从实践上看，最浪费时间的无疑是那些无用的文档。但倘若文档是有用的，而且甚至是客户价值的重要部分，一切就变了。

怎样写这个需求文档？

就这个文档而言，它是为了验收所用，和开发没有关系（已经开发完了），和日后维护没有关系。

那怎么写？这个问题就不回答了，当然是按验收的写法写。

所以，所有文档的所有写法，在每个企业都不相同，不应该问“敏捷开发应该怎样写XX文档？”，而是应该问“应该怎样写上面那个文档？”，而若能这样发问，答案已经明确了。

“写不写文档”的常见做法

常见的文档虽然很多，但下面几个维度几乎永远存在，具体某个文档通过几个维度的分析，处理方法各不相同：

信息长期/短期有效的文档

长期有效比如竞争对手分析文档，架构设计文档，需求管理文档（用户故事），产品路线图……

长期文档适合详细描述，用语应完整（就是写Word那种写法），甚至可以动用图形和建模工具。

短期有效比如评审发现的问题，PO在计划会上讲解的内容等。

短期文档适合粗略描述，典型的就是用纸或Word凌乱地写一些关键内容，无需长期保存，月末一般就无用了。

不可/可被”可运行软件“替代的文档

上面举例的文档中，竞争对手、架构设计、用户故事、路线图都无法从代码中看出来，适合文档化。此外，一些科学计算的公式、复杂的设计也属于此列。

而界面设计、数据库表结构设计、流程图、伪码等，一旦软件做好了，更容易在可运行软件中看出，就不要着大量笔墨于此。

若感觉后者处于”没有就做不出软件，但做出软件又没用了“的尴尬境地时，应采用轻量级设计。

敏捷开发智慧敏捷系列之三：做不做架构设计？

缘起

甲：“敏捷不应该写架构设计，应该每个迭代都是相同的，才能达到自相似性（这是Ken Shweber说的）。”

乙：“如果不写架构设计，很容易返工，早晚还得重来。”

甲：“大不了重构，这是敏捷开发重要的实践。”

乙：“重构？重构的成本很高的，做几个迭代，后面重构都重构不过来了。”

甲：“架构设计写了很容易过度设计，而且在编码的时候还很容易全部推翻重来；。”

……

这个架构文档要不要写呢？写，为什么？不写，为什么？写，怎么写？不写，怎么不写？

为什么敏捷不做架构设计？

先把话说绝点，敏捷就是不写架构设计。那为什么不写架构设计？

还是为了减少浪费。

敏捷有两个理由认为写架构设计是浪费时间。

第一，业务需求是多变的。之前的架构写得再好，中间需求一变，架构还的改动，费时费力；很多需求可能是无用的，早期可能规划了，后期又会发现用不上，如果架构里边考虑了这些无用需求，就会过于庞大。

第二，架构设计很难判断是否正确、完备。这个本人也很有体会，本来以为很好的设计，到了编码的时候发现不是那么回事，这时候就得从头翻腾。评审一下如何？可惜，除了最终的软件，多数需求、架构、测试用例……都很难评审，评审半天，问题还是很多。

敏捷的这些假设，整体上非常普遍，可以说是在尝试“做好架构”而不得之后的妥协。

不在那些总是改来该去，还不知道是否可行的东西上浪费时间，是敏捷不做架构的出发点。

怎样写这个架构文档？

但是如果彻底不写架构设计，又可能返工，怎么办呢？当然是本着“最小浪费”原则来做架构设计。

下面是一些写和不写的内容：

写：相对稳定不变的，重构成本很高的，能看出对错的

不写：概念性的那不太准的，很容易扩展的，说不清对错的

具体要写什么不写什么，很大程度上要受到业务稳定性、技术的先进性、人员能力等各方面的影响。

所以，所有架构文档的所有写法，在每个企业都不相同，不应该问“敏捷开发应该怎样写架构文档？”，而是应该问“如果我的业务、技术、人员如此，应该怎样写架构文档？”，而若能这样发问，答案肯定可以自己找到了。

智慧敏捷的一个本质方法，是要去理解敏捷这样做的目的是什么，而不是敏捷应该怎样做。

倘若日后出现了先进的架构方法，或许架构就变成一种很容易做、很容易评审、很容易变动的东西，那时候就是另外一种说法了。但敏捷在架构设计这件事情上的本质目标却永远不变：减少浪费。

5分钟又到了，散会。

敏捷开发智慧敏捷系列之四：每日立会开多久？

缘起

甲：“我们每日立会会开不起来。”

乙：“嘿，我们每日立会开起来了，而且越开越长了，一开就是1个小时，净是些技术细节。”

甲：“别人等着他们讨论，那多耽误时间啊……”

乙：“我也觉得是，但是看他们交流得那么热烈，讨论的也是正事，到底应该打断还是不打断呢……”

为什么每日立会只开15分钟？

我们说绝点：每日立会只能开5分钟，而不是15分钟。

这5分钟说点什么呢？应该说必须开会才能说明白的东西。

先看两个团队，他们有什么是需要开会说明白的。

第一个团队，10个人，平时分工细致，各干各的，谁也不干扰谁。

这个团队，开会的时间肯定不短，因为所有交互问题都需要开会解决。

第二个团队，10个人，平时分成三个小组，小组内随时沟通，小组间有需要就沟通。

这个团队，开会的时间肯定短，因为三个小组长发言总结自己组的进展就可以了，会上只需要碰碰组间的沟通。

敏捷开发实际上在假设大家平时像第二个团队一样一直在互相沟通（即使不分成三个小组），但是却很少以整个团队的形式沟通整体进展，所以才创造了15分钟的周例会，当然也能顺便把忘了沟通的人链接一下。如果这个本来作为补充性质的周例会变成了组内唯一的沟通渠道，就出问题了。

所以，开会时间长，往往不是沟通充分的表现，而是沟通不充分，只能赶在会上沟通的表现。

团队应该怎样沟通？

团队应该随时就技术细节进行沟通，而不需要等待开会。而对于3～5个人的团队，组长如果除了开会居然不知道整个组的进展，那么沟通是极其不顺畅的，要解决的不是每日立会的问题，而是平时沟通的问题，比如采用师徒制度、松结对编程等（请参考其他系列博文）。

这种会议甚至在更大的规模上，也能淡化。

我们曾经试图在一个由销售、市场、支持三个部门15个人的组中间开周会，开了大约几次后就取消了，原因是我们仔细安排了位置，使得总监和三个经理一起坐在中间的大桌上，而其他队员则坐在四周。因此组间的沟通在大桌上随时就完成了（做了个4个人都能看到的大屏幕），而组内的沟通则一回脸就完成了。所以发现几乎所有的事情大家都知道差不多了，会上也只是重新说说而已，开或不开都可。

因此，应理解每日立会、计划会、评审会、反思会这些会议，都只是沟通过程的仪式化的补充，若沟通本身不畅，而只是指望这些会议完成沟通，肯定会陷入两难的境地。

“每日立会”的常见做法

1～4人团队

这个规模的团队，优先使用139团队结构和松结对编程方法，即由师傅（小组长）密切地与徒弟们沟通。这会涉及到沟通管理、时间管理、过度沟通、有效生产率等问题，在链接的系列博客中有所详述，都不是问题。

这个规模的团队应该不开立会，而是更密切的交流方式。它的运行方式更像XP，而非Scrum。

5～9人团队

这个规模的团队，优先划分为2～3个小组，每个团队仍按松结对编程方法运行。

由于人多了，组间难以沟通，所以开个立会是必要的，主要目的是组间进度沟通，因此不会发生技术沟通（这是组内的事情），所以也不可能超时。

小组长应把握好应该如何与对方组沟通、沟通什么的问题。

更大型的团队

更大型的团队，则推荐组长+小组长参与开超级立会，组员不参加。

这类会议也是进度沟通会，所以不会涉及技术沟通。

为何不让Scrum Master们开个会议？因为专职的Scrum Master不负责技术、进度、质量这些事情，真正对这些熟悉的，是团队组长和核心骨干。

后面两种会议，很像是“Scrum of XPs”，而不是“Scrum of Scrums”，前者的沟通性更强。

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

缘起

（立项时）

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

乙：“到时候再说。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷开发过程与模板

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

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

动态使用的原则

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

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

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

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

敏捷开发智慧敏捷系列之六：之一～之五的小结

写多了，才发现前几篇文章中有几篇都落下个章节，就是除了“看着办”之外的一些常见做法，这里总结一下。

所谓常见做法，就是为了防止“看着办”看走了眼，而提前可以参考的方法，可以作为起点，但未必真的正好合适，更很难永远合适，所以不是终点。

为了阅读方便，在原文中也添加了，这里仅做归纳。

“写不写文档”的常见做法

常见的文档虽然很多，但下面几个维度几乎永远存在，具体某个文档通过几个维度的分析，处理方法各不相同：

信息长期/短期有效的文档

长期有效比如竞争对手分析文档，架构设计文档，需求管理文档（用户故事），产品路线图……

长期文档适合详细描述，用语应完整（就是写Word那种写法），甚至可以动用图形和建模工具。

短期有效比如评审发现的问题，PO在计划会上讲解的内容等。

短期文档适合粗略描述，典型的就是用纸或Word凌乱地写一些关键内容，无需长期保存，月末一般就无用了。

不可/可被”可运行软件“替代的文档

上面举例的文档中，竞争对手、架构设计、用户故事、路线图都无法从代码中看出来，适合文档化。此外，一些科学计算的公式、复杂的设计也属于此列。

而界面设计、数据库表结构设计、流程图、伪码等，一旦软件做好了，更容易在可运行软件中看出，就不要着大量笔墨于此。

若感觉后者处于”没有就做不出软件，但做出软件又没用了“的尴尬境地时，应采用轻量级设计。

“写不写架构设计”的一般做法

之三原文中已经写了，就不多说了。

“每日立会”的常见做法

1～4人团队

这个规模的团队，优先使用139团队结构和松结对编程方法，即由师傅（小组长）密切地与徒弟们沟通。这会涉及到沟通管理、时间管理、过度沟通、有效生产率等问题，在链接的系列博客中有所详述，都不是问题。

这个规模的团队应该不开立会，而是更密切的交流方式。它的运行方式更像XP，而非Scrum。

5～9人团队

这个规模的团队，优先划分为2～3个小组，每个团队仍按松结对编程方法运行。

由于人多了，组间难以沟通，所以开个立会是必要的，主要目的是组间进度沟通，因此不会发生技术沟通（这是组内的事情），所以也不可能超时。

小组长应把握好应该如何与对方组沟通、沟通什么的问题。

更大型的团队

更大型的团队，则推荐组长+小组长参与开超级立会，组员不参加。

这类会议也是进度沟通会，所以不会涉及技术沟通。

为何不让Scrum Master们开个会议？因为专职的Scrum Master不负责技术、进度、质量这些事情，真正对这些熟悉的，是团队组长和核心骨干。

后面两种会议，很像是“Scrum of XPs”，而不是“Scrum of Scrums”，前者的沟通性更强。

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

敏捷开发过程与模板

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

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

动态使用的原则

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

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

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

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