一场关于“何时发布版本”的论战
气氛太平静，投石起波澜。
昨天下午无意中在内部发起了一场关于"何时发布版本"的论战。
论战的背景是这样的：部门内部有这样的一个项目A，它的目标是开发出可被其他项目或产品复用的组件(这里就暂称之为组件吧，我们内部称这类组件为可复用资产)。这个项目已经开发了大半年了，目前处于收尾阶段，绝大部分开发工作已经完成。测试(包括压力测试等)已经测试过至少一轮了；我们的产品线近期准备复用项目A成产出的这些组件，我们希望得到这些组件的某个发布版本。
论战的导火索是我就这件事情回复的一封mail。mail的大致意思是希望项目A能采用可复用资产的方式对组件进行发布管理，尽早在内部公开发布组件版本，以利于其他计划或正在复用这些组件的项目能够尽早的集成，发现问题，反馈意见和建议。
项目A负责人就我的建议回复的mail拉开了这场论战的大幕，其mail的大致内容是："在项目A结项前，相关成果物暂不发布，不通过组织内部可复用资产的方式进行管理"。在接下来的mail中他阐述了几点理由：
(1) 项目A开发工作尚未完全结束，代码每天依旧在修改，手册、测试均未完成；
(2) 项目组人员有限，发布牵扯到开发人员的工作量，无法集中精力于开发工作；
(3) 欲复用这些组件的开发组可以从项目A的配置人员那里获取代码，配置人员发布的版本都是经过基本功能测试的，而且API接口部分已经基本稳定，可以进行研发。等项目完全结束后会加入到部门可复用资产库中的。
如果是按照传统项目的管理方式，以上理由可能无可厚非，但恰恰项目A所生产的组件并非传统项目的成果物类型，所以我针对上面的理由做了进一步的回复，大致意思如下：
(1) 就因为组件开发尚未完全结束，才应该制定阶段发布计划，不能等到最后再发布，否则一旦存在与其他项目的集成问题，修改起来就更加费力，而且还可能导致各个项目延期；另外提早内部公开发布阶段性版本才可以"扩大"组件的使用和测试范围，去"Eating your own dog food"，有利于尽早更多地发现问题；
(2) 产品发布就是开发过程的一部分，不要割裂开来；
(3) 显然项目A是有自己的版本管理的，但没有在显式的位置公开发布版本信息，这些版本对外均不可知；而且在没有外部监督的前提下，内部版本管理可能较为随意，可能后续不便于外部项目对组件问题的跟踪与管理。
(4) 由于组件的需求和设计阶段已经结束，我的建议主要针对组件实现以及之后的生命周期。
显然项目组A负责人认为项目过程中的评审比尽早发布版本后收到的反馈更为重要，于是他发出了下面Mail：“需求阶段和设计阶段的评审更重要，实现阶段和测试阶段会举行例如手册、测试方案的评审，代码评审叫你们，你们有时间参加不？”。
有些火药味儿了^_^。我的回答是："我真不知道什么样的好产品是内部坐着评审出来的，哪个好产品不是在使用后反复修改出来的。如果评审能缔造好产品，那大家就都评审好了！ "。
随后我又举了一个形象的例子，拿一个场景说明提前内部公开发布的必要性。
以微软为例，两个部门：Windows开发部门(以下简称Win)和visual studio开发部门(以下简称VS)。Wins部门正在开发WIN8，与此同时VS部门正在开发visual studio 11。下面有两种场景：第一种：WIN部门在需求、设计阶段召开了大量会议，也采纳了VS部门的建议，但就是后期迟迟不发布版本。而VS部门急着要与最新的WIN8版本集成，看是否会有集成问题。WIN部门的回复是：等吧，2012年10月WIN8发布时，你们就可以测试了。VS部门也要在10月份发布VS11，无奈VS部门只能暗中找到WIN部门的人偷偷搞到一个WIN8的beta版(例如，build 2012)，然后赶紧做集成。结果发现了大量不兼容问题。VS部门感叹：多亏提前做了，否则10月份又要被Steve Ballmer甩椅子了。第二种：WIN部门在需求、设计阶段召开了大量会议，也采纳了VS部门的建议，并且WIN部门在开发阶段就定期发布alpha1~alpha10版本，供其他各个部门的新产品集成，及时收集问题反馈，及时修正问题。10月份时，WIN8和VS11都高质量顺利上线。大家觉得哪种更好些呢？
我举的例子也有些激进(特别是场景1)，这下彻底激怒了那位兄弟。其回复说："有很多问题，很多bug的版本也可以发布？不稳定的版本发布了有何用？谁会用？"。我的回答是"Windows每个alpha版本发布后仍然可能有数千个bug。但它也要内部发布，注意是内部发布，为的是更早的与其他应用集成，发现问题"。
论战到这里，我觉得我的意思基本上算是表达清楚了，于是终止了这略有火药味儿的讨论。
我们的组织内部很少有这种带有火药味儿的激烈争论，但我个人觉得在对团队团结无损害的前提下，这类争论应该多多益善，这样才能产生思维碰撞，产生火花，促进思考，推动改进。
部门经过十几年的发展，固化下来一些目前来看并不合理的惯例，很多人(甚至也包括我自己)的思路尚停留在老路上。所以我经常用下面两句话来督促自己，让自己始终保持OPEN的心态：
(1)、忠言逆耳利於行；
(2)、向前迈出一步总比原地踏步强。也许迈出这一步后，摆在你面前的是另一番别有洞天的景色。
© 2012, bigwhite. 版权所有.
Related posts:
说的很对，A项目负责人更应该拥有一个开放的心态，他可能是害怕暴露自己的问题，会让自己的团队更加被动，其实反过来想想这些问题早一些暴露对整个产品是有好处的，产品的开发就是要接受外界的审查，有一个约束在那里，逼着把每一件事情都做好，这样不至于到最后抓瞎，其实这是对自己的部门有好处的，不要感到害怕，习惯了就好了。
内部版本，外部版本，继续集成，缩短迭代周期，不断迭代！