源自javaeye的一个讨论：关于软件开发中度的把握

[青润]

帖子连接如下:
http://forum.javaeye.com/viewtopic.php?t=10948
那边告诉我还要等待76个小时才能回复,我只好放弃回复来这里说两句话了.
这里我暂时不想评论这个度的问题,因为这个度,实在是不好用精炼的文字说明清楚.
我想评论的是gigix的一句话：“照XP的建议，划出足够细的用户故事，让用户排列优先级，始终只实现优先级最高的故事。”

我对这句话有个人看法。我的看法如下：
完全的理论等于空话！
让用户排列优先级，部分用户业务功能是可以做到的，但是，大部分是用户无法做到的。只有一种可能性可以让用户来按照xp的这个所谓建议进行操作，那就是，用户方有对软件技术和工程经验足够丰富的人员，否则，这种话就是空话。
我年前曾经给美国的一个公司做过一个电子商务网站的规划，对方认为这个东西很简单，一个美国的程序员一个月就足够了。而且，说这句话的朋友，还是一个曾经在国外几家大公司做过高级程序员的华人，目前在国内开了公司。
我见对方并不认可我的看法，因为我认为这至少需要两个高级程序员做两个月才能完成。于是，我做了一份详细的功能列表和说明的文档，把前台和后台的功能一一作了列举，最后，他看了我的文档以后，终于无话可说了，也认可了我的说法。
这里面工程经验是非常重要的，上面这个例子就是拿电子商务网站来作的说明，那个朋友本人并没有做过电子商务网站，所以，他就按照自己看到的网站的前端情况来估计整个工程的工作量，却忽略了后台所需要的大量的功能实现。
于是，就出现了上面的看法。

大家也可以讨论一下度的问题，我有时间的时候，会把这个话题深入讨论下去的。

[saucer]

javaeye慢的不行，根本连不上，能把问题转贴过来么？

[青润]

呵呵,思归说话了,那我就把问题的相关内容都转贴过来吧,不过,会做一些删减,不必要的内容,就不转贴了:
************************************转贴内容开始***************************************
作者：zidoing
时间: 2005-2-24 09:03:56 标题: 关于软件开发中度的把握。

--------------------------------------------------------------------------------

在软件的开发过程中总是倾向于加入更多的功能，实现更多美妙的想法，而这往往又是使项目失败的一个很重要的因素。开发中的这个度该如何把握呢？

回复：
作者：凤舞凰扬
你的团队是否有足够的能力，你的团队是否有足够的时间，你的团队是否有足够的辅助资源（比如金钱、环境等）。

回复：
作者：gigix
照XP的建议，划出足够细的用户故事，让用户排列优先级，始终只实现优先级最高的故事。

回复：
作者：age0
如何控制这个度，主要还是由系统整体基础架构的能力来衡量的，如果新增功能在基础架构的设计范围之内就可以放心增加，但是如果超出了原来的设计范围就必须很审慎，其实道理和建筑差不多。

回复：
作者：Archie
zidoing 写道:
在软件的开发过程中总是倾向于加入更多的功能，实现更多美妙的想法，而这往往又是使项目失败的一个很重要的因素。开发中的这个度该如何把握呢？


更多的功能和更美妙的想法，如果是用户提出来的，你就给他估算一下要用多少成本，是否做由用户决定。如果是程序员提出来的，也要先和用户沟通，做不做也是用户说了算。

Archie 写道:

更多的功能和更美妙的想法，如果是用户提出来的，你就给他估算一下要用多少成本，是否做由用户决定。如果是程序员提出来的，也要先和用户沟通，做不做也是用户说了算。


这种老套的说法以后就不必说了，差不多每一本和需求或软件工程相关的书籍都会有这种套话。

基本上，一个项目的真正需求只有到了beta测试阶段才会得到完整的补充，因为beta阶段之前的需求都是由高层用户代表确定下来的，因此并不能全面反映最终用户的实际需求，而只有到了beta测试阶段才会有最终用户参与进来试用以及评估，这个阶段的需求大多数是要求补充更具体更实用的功能，如果系统整体框架设计的比较完善，这种需求就很容易满足并且可以得到相当高的用户评介，但是如果框架设计的不周详，这种需求就有可能对系统造成不利影响。而这也是为什么XP一直要强调现场用户、持续集成以及小型发布（Small Release）的重要原因之一。

回复：
作者：notyy
这个度由这个软件的主设计师把握就行了，呵呵，独裁一下

回复：
作者：winterwolf

zidoing

在软件的开发过程中总是倾向于加入更多的功能，实现更多美妙的想法，而这往往又是使项目失败的一个很重要的因素。开发中的这个度该如何把握呢？

先砍

砍到不能再砍 就开始干

然后一个版本接一个版本的升级

回复：
作者：flyingbug
楼上这招虽然很弱，确很实用
就看你们的市场人员是否能顶住压力了：）
************************************转贴内容结束***************************************

[loveisbug]

用成本来衡量。最直观的是时间成本，隐含着的是风险带来的附加成本，其实，都是经济成本。
把增加功能所需的时间开销，大把的银子和可能带来的稳定性降低出错的可能如实详细告诉客户，再由他衡量是否在当前做此调整。

[saucer]

我也就青润说的作一番评论，因为原先的题目可以用Steve McConnell写的一书<<快速开发>>中提到的Software Trade-off Triangle (Cost, Schedule, Product)来理解

其实gigix说的XP中优先级，一般是这么做的，开发人员(注意，是开发人员)根据自己的理解对每个user story打个cost分，然后根据往常经验，开发队伍在一个说好的fixed timeboxed iteration (譬如2-4个星期内) 可以完成多少个单元，由用户决定下一个 iteration应该实现哪几个user stories。譬如说，我们总共有4个user stories，其cost分别为10，4，6，6单元，而根据经验，开发对伍能在讲好的开发周期4个星期内完成16个单元，那么用户可以根据这些故事的business value以及所需的cost来决定下一个周期内到底是实现第1，3个故事，还是第1，4个故事，还是第2，3，4个故事呢。因为是iteration制，而且项目会记录每个iteration能完成的user story以及相关的cost，一开始时estimate也许不是很准，但随着开发的进行，track，feedback，以后的estimate会慢慢准起来的

这时间估计是由开发人员完成的，不是由用户完成的

[gigix]

简单回复一下

“那个朋友本人并没有做过电子商务网站，所以，他就按照自己看到的网站的前端情况来估计整个工程的工作量，却忽略了后台所需要的大量的功能实现。”

在这种情况下不管你怎么弄都是没法弄，不管你是XP还是别的什么。客户还不知道自己的项目究竟需要做什么，他连需求都还没弄清楚，不管你怎么做一定会返工。所以你应该做的两件事，第一是帮助客户充分了解自己的需求，第二是尽量降低返工的成本。这种情况下你要想办法避免返工，我认为是不现实的，因为你既不是上帝也不是客户肚子里的虫，你没法知道他究竟想要什么，自然也没法帮他决策。

[gigix]

再分析一下qingrun的案例。用户说两个月能做，我说做不了。为什么做不了，我就得拿出细分的任务表和每个任务的估算时间，对方看了才知道，原来一定要4个月才能做。那么现在他就可以决策，要么等4个月得到一个完整的网站；要么做两个月就上线，先发布一些重要功能，以后的慢慢接着做；要么就不跟我做了，换另一个开发商去做。他会知道，4个月是我力所能及的底线，不是我在骗他的钱。如果没有细分的任务表和估算，你怎么能让他相信4个月可以两个月不可以？我相信qingrun一定也做了类似的工作，那不就是跟我说的是一回事么？

[Fusuli]

我在实际操作中的方法是：
在理解所有需求的前提下，
先不计成本的列出所有能想到的功能和效果，甚至包括画蛇添足
然后根据项目实际的资源情况，砍！具体砍的原则是：第一砍不重要的功能；第二力求主要功能简单实用，能满足客户绝大部分应用即可；第三砍那些几年用不上一次的功能；第四砍软件并不能大幅度提高其工作效率的功能
最后就是讨价还价了，跟客户说明这种种功能不是我们作不了，是资金不允许我们做，要做加钱，或者在下一版升级时作。当然最后的结果往往是不加钱的前提下又给加回去几个功能，但项目在可控的范围内就达到我们的目的

[okitgo]

好贴! 顶一下

[青润]

我举的那个例子中实际上有一些背景条件，gigix兄好像没有考虑到。
现在的电子商务网站已经很多了。任何一个客户如果想自己做一个，都会去先看看别人的情况，看看别人的是如何做的。
这种情况下,用户是知道自己要的是个什么样的产品的,只是,用户方所欠缺的是这些产品背后需要哪些功能来提供支持,所以,我那份文档就是达到了这个目的.

应该说,我是可以很明白他要做的是什么的.或者说,他想要的是什么,因为我看到了对方所要求照抄的那个电子商务网站的功能和情况,加上我多年对这个方向的经验.

后面gigix兄的那段回复我是完全认可的，这一点我们的观点和看法是一致的。

[fita]

要把握好软件开发中所谓的度，我认为首先要明确以下原则：
1)软件是工具，开发它的目的是为了用。客户以使用价值来评价一个功能
2)任何软件功能的实现都是需要成本的，客户需要为它获得的每一个功能付出成本,正像前面说的有人力成本、时间成本、风险成本等

软件产品的功能确定实际上可以看作一个投资的过程，一个功能的使用价值减去它的开发成本，就是它可以获得的投资利润，投资利润越高的，就应该先做，而利润为负的就不要做。基于投资的原则去定义产品就一定不会错。

[fita]

对于如何确定软件所需要的功能，我认为简单的系统可以直接交由客户决定，象XP那样让客户参与到开发工作中可以取得很好的效果。

对于复杂的软件系统，我认为应该交给软件产品专家去设计更好，客户作为使用者，让他们详细说出所有的产品功能是不太现实的，就好像让一个想买汽车的人，让他详细说出他要买的汽车的所有功能是不太可能的，汽车功能的设计还是交给专业的设计师去做比较好。我想对于复杂的软件产品，一定要设置专门的软件产品设计师，老实说现在的所有软件公司的做法和其他行业相比实在不够专业。