频繁发布，尽早让大家看到有用的结果，有助于建立与相关利益方的信任。信任是一种难以定义的事物，社会学家称之为社会资本(Social Capital)。研究发现，信任是由事件驱动的，相比大规模但是偶尔发生的活动，小而频繁的表现更加能增加信任的产生。想象一个女孩刚刚与某位男士愉快地进行了第一次约会，如果男士当晚就继续发短信表示很愉快，并且第二天就打电话过来；或者，两周之后捧着一束鲜花到女孩家门口，猜猜女孩更喜欢哪种方式？

很多采用精益创业的产品团队也坚持频繁发布。这样做可以尽早获取市场反馈，以便发现问题和验证头脑中的认知假设，然后不断地调整方向。在资源耗尽之前找到一个真正可行的方案，避免进入”死亡螺旋”。

频繁发布在广告宣传中也是一种常用的手段。德国有一位著名的心理学家名叫艾宾浩斯(HermannEbbinghaus，1850-1909)，他在1885年发表了他的实验报告后，记忆研究就成了心理学中被研究最多的领域之一。下图是著名的艾宾浩斯遗忘曲线，展示了人类的记忆保留比率随着时间的推延，知识遗忘得越来越多。因此，频繁发布也有助于加强受众的记忆，保持持续的宣传效果。

要有效地频繁发布，有几个要点：

· 与近期时事焦点相关。搭车吸引眼球，并在有限时间窗内增强传播效果。

· 简单，明了。每次发布一小部分内容，控制信息的规模，方便人们理解。

· 新鲜有趣，有一定信息量。比如科普知识或者实用内容，使人们能够从中有所收获。

· 持续地吸引受众的注意力。建立合理的更新发布节奏。

（作者：Jacky Shen)

组织导入敏捷往往更加关注形式和标准化，然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。在从6个人扩张到1200人的过程中，它使用一种了新型的矩阵组织来扩展：部落、分队、分会和协会。

之前@申导 在NSN工作时，诺西的敏捷组织也有些类似这样。每个DA(开发部门，负责系统中一大领域)就是一个Tribe,大约80人左右。每个Scrum Team就是Squad, 大约5-9人，开发测试跨职能团队。横向会有一些技术领域或测试能力的Competence Center，正如Chapter，人们在跨团队之间组成相近领域的小组进行交流和协作，比如某两个团队可能都工作在同一个component上，那么其中的某几个人都是这个component的贡献者和Chapter成员。至于大部门之间，一定也少不了协作，同样需要虚拟专家团队为持续集成系统共同努力，或者对Chrous操作系统的兴趣小组，或者教练社区，这些都可以称为Guild。 这种大规模敏捷的扩展方式，也被称为”LeSS”.

借用@窦涵之 之前画的一张图。

这是矩阵组织，但也不完全是。这个和我们常用的矩阵结构是不同类型的。
大多数矩阵组织中,相似技能的人“扎堆儿”到一起形成职能部门,接着“被分配”到项 目中,并且“汇报”给职能经理。而这里的矩阵偏重于交付。鼓励团队有自己个性化的实践，自发地传染和授粉行为。但每个团队需要与整体目标对齐，避免局部优化。一致性与灵活性之间寻求平衡。

团队的约束和边界在于产品方向和策略，以及短期的迭代的目标。内部开源模型，其实就是集体代码所有制，尽量消除模块团队之间的壁垒。

大型组织内的团队需要高自治(Autonomy)与高对齐(Alignment)。

固定时间盒的release train发布模型，利用feature toogle未完成的特性。做模块解耦这样增加分别发布的灵活性。

频繁地发布与降低发布难度相辅相成。运维部门更多关注如何能帮助研发团队“自行发布”。

在人员培养上，更加着重激励，关注人们为什么不满意。鼓励团体作战，与他人协作找到更好的解决方案。

更多参考：

http://bobjiang.com/wp-content/uploads/2014/02/Scaling-Agile-at-Spotify-v7.pdf
http://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
LeSS
SAFe
http://www.scrum-breakfast.com/2013/10/scaling-scrum-safe-dad-or-less.html