五问《移山之道》中的软件开发

1， NABC真的适用于所有的所有项目意义的分析么?

这个问题源于我们小组自身的感受。本次团队项目的提案过程中我们使用了NABC (Need, Approach, Benefit, Competitor)的分析方法。我们小组的开发项目是基于声音控制的一款手机游戏，不得不承认，尽管我们觉得我们的想法很刺激，但是运用NABC的方法加以分析后，总觉得不”给力”。到底是方案不给力呢，还是NABC不给力呢，还是我们没有把方法用对（我们不给力）?　个人感觉NABC似乎更使用于功能性软件(software with a dedicated functionality), 而并不太使用于游戏。因为总体来说，不同游戏间的区别相对于功能性软件来说更小，那么他们的NABC似乎就不是评价他们最重要的指标了。

2，算法设计性任务如果进行WBS, 如何写成较固定的Work Item?
这个问题来源我自己的经历。我负责团队项目中声音识别算法的部分。我发现这个部分很难在真正开始设计前进行breakdown。因为你很难知道你最后要使用哪一种方法？会有多少工作量。

3，DEV要不要TEST自己的代码? 还是一直专注于写?让专门的TEST来做?

4，对于一个已经有一定规模的软件，增加功能重要还是精简功能重要?

《移山之道》的最后一章，讲“发布阶段和之后”，提到如果一个模块如果不能实现预期的设计需求，就要视状况砍掉。除此之外，用户/场景分析,迭代式开发等方法强调的都是不断地”增加”，就像微软的大多数软件，体积庞大，功能复杂 ，保住了大多数的用户，但是也造成了大量的浪费。

5，大企业文化 下的开发风格 vs小团队/个人的开发风格?

读《移山之道》，尽管只是在软件开发这一主题上，但能感觉到里面充斥着企业文化（微软），与个人意志（作者）的交织。但就这本书而言，我认为前者胜于后者。从某种程度上说，这本书可以叫做《软件开发在微软》。既然如此，他的方法真的适用于别的团队，特别是更小一个的团队，做更小一点的项目的开发么?

by Qifan

转载于:https://www.cnblogs.com/southseven/archive/2011/10/10/2205496.html