这是敏捷开发智慧敏捷的第六篇。（之一，之二，之三，之四，之五，之六）

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

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

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

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

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

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

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

长期文档适合详细描述，用语应完整（就是写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://cheny.blog.51cto.com/3988930/1099720）

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

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

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