难以预测的研发型项目里你用什么隐喻？

隐喻描述软件项目，代码大全2介绍了这种方法。这个方法不知道起源何处，不过的确在我们软件工程师的生活中处处可见。

难以预测的研发型项目

我一个朋友就跟我说过，他的老板太急了，好的软件就像种庄稼一样，要耐心的等它长出来，需要时间，需要呵护。他是个总是挑战自己不熟悉领域的人，总是试图完全自己做而不依赖于其他开源软件的研发人才。所以他的情况比较特别。看上去是每次做一点的种庄稼的隐喻，其实也包含了不少 写作隐喻的特点，扔掉重写。

代码大全中描述写作隐喻的这种方式就是代价高昂。而看天吃饭，小步尝试的种地做法，又让老板对进度无法预期而忍无可忍。所以，可想而知，采用这种方式的研发人员背负着很大的精神压力，即便做成了，也在大多数情况下招致抱怨。

至少在我看来，分析使用新技术开发的风险和成本，未胜先预败。然后将系统切分成不同的部分，考虑到自己的能力，团队的资源，选择一些模块完全研发，其他的重用已有的技术，哪怕将来对那些部分进行重构。有一个相似的例子，GitLab刚开始基于gitolite做权限管理，但是随着软件的不断成熟，团队能力的提僧，它们从5.0开始用自己实现的gitlab shell替代了gitolite，这次重构使得系统不再使用两个权限管理机制，代码大大简化，消除了很多隐患。

而如果要将系统切成不同的部分，也就意味这从较高的层面去架构这个系统，用分层的方式，不断的拆分出各施其职的子系统和模块。因此架构设计是必须经历的，只有这样，我们才能得到一个系统架构图，用不同的颜色标出难易度，然后选择整个团队力所能及的模块自己创新，而将暂时照顾不到的部分选择基于其他软件二次开发。

我的朋友也是反对Scrum的。他认为每个sprint都要出成果，问题是研发就是难以预测的，怎么能保证按时交付？做一般的项目可以这样。研发是科学和艺术的结合。

但是没办法，现实点，企业运作付出成本就要回报，风险需要可控，进度也不能超出预期太多。很多时候还是一个方法学的问题，比如：

1. 用前面我的方法，定架构，就像搭建房屋一样（这是第四个隐喻），只做力所能及的自主研发，重用其他的模块。

2. 用正确的User story来引导整个产品的功能，的确会比工程师做到哪算哪儿要好。

3. 在软件开发的技术目标上，用牡蛎养殖的隐喻还是不错的，不要设计太高的目标。很多著名的软件都有其发展历程，从很挫的童年开始，逐渐成熟。经过若干次大的重构，比如Oracle。如果能够静心，经过时间的考验，不断的演化。软件就像一个生物，会进化的。

4. 开发过程中，经常容易遇到突发情况，想改变story的优先级，突然想到要新加一个任务。所有这些，都需要和团队认真商量，不能搞个人的自由主义。这其实是很多天才程序员的通病，过于骄傲，不会合作。

这样的话，sprint plan的计划比较接近团队的能力，sprint review的时候也就不会出现太多的不靠谱。这并不是说就一定不会出问题，有可能有些story在review时会被product owner拒绝，但是这就是下个sprint要吸取教训的地方：是计划不合理，还是某个技术债务导致。

经过做了上述努力，让事情的不可控因素减少，但是如果真是团队完全不熟悉的领域，牡蛎养殖是比较好的做法。在这种情况下，房屋建筑这种隐喻只能用来做粗粒度的架构，因为这是完全陌生的领域，做的太仔细意义并不大，反而会导致成本的浪费。就像隐喻四--建造房屋那样，把结构性支撑规划清楚，日后再决定用木地板还是地毯。

简短来说，我总是同时使用生长和建筑两个隐喻。