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

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

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

大家也可以讨论一下度的问题,我有时间的时候,会把这个话题深入讨论下去的。
...全文
249 11 打赏 收藏 举报
写回复
11 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
fita 2005-03-14
对于如何确定软件所需要的功能,我认为简单的系统可以直接交由客户决定,象XP那样让客户参与到开发工作中可以取得很好的效果。

对于复杂的软件系统,我认为应该交给软件产品专家去设计更好,客户作为使用者,让他们详细说出所有的产品功能是不太现实的,就好像让一个想买汽车的人,让他详细说出他要买的汽车的所有功能是不太可能的,汽车功能的设计还是交给专业的设计师去做比较好。我想对于复杂的软件产品,一定要设置专门的软件产品设计师,老实说现在的所有软件公司的做法和其他行业相比实在不够专业。
  • 打赏
  • 举报
回复
fita 2005-03-14
要把握好软件开发中所谓的度,我认为首先要明确以下原则:
1)软件是工具,开发它的目的是为了用。客户以使用价值来评价一个功能
2)任何软件功能的实现都是需要成本的,客户需要为它获得的每一个功能付出成本,正像前面说的有人力成本、时间成本、风险成本等

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

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

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

后面gigix兄的那段回复我是完全认可的,这一点我们的观点和看法是一致的。
  • 打赏
  • 举报
回复
okitgo 2005-03-11
好贴! 顶一下
  • 打赏
  • 举报
回复
Fusuli 2005-03-10
我在实际操作中的方法是:
在理解所有需求的前提下,
先不计成本的列出所有能想到的功能和效果,甚至包括画蛇添足
然后根据项目实际的资源情况,砍!具体砍的原则是:第一砍不重要的功能;第二力求主要功能简单实用,能满足客户绝大部分应用即可;第三砍那些几年用不上一次的功能;第四砍软件并不能大幅度提高其工作效率的功能
最后就是讨价还价了,跟客户说明这种种功能不是我们作不了,是资金不允许我们做,要做加钱,或者在下一版升级时作。当然最后的结果往往是不加钱的前提下又给加回去几个功能,但项目在可控的范围内就达到我们的目的
  • 打赏
  • 举报
回复
gigix 2005-03-10
再分析一下qingrun的案例。用户说两个月能做,我说做不了。为什么做不了,我就得拿出细分的任务表和每个任务的估算时间,对方看了才知道,原来一定要4个月才能做。那么现在他就可以决策,要么等4个月得到一个完整的网站;要么做两个月就上线,先发布一些重要功能,以后的慢慢接着做;要么就不跟我做了,换另一个开发商去做。他会知道,4个月是我力所能及的底线,不是我在骗他的钱。如果没有细分的任务表和估算,你怎么能让他相信4个月可以两个月不可以?我相信qingrun一定也做了类似的工作,那不就是跟我说的是一回事么?
  • 打赏
  • 举报
回复
gigix 2005-03-10
简单回复一下

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

在这种情况下不管你怎么弄都是没法弄,不管你是XP还是别的什么。客户还不知道自己的项目究竟需要做什么,他连需求都还没弄清楚,不管你怎么做一定会返工。所以你应该做的两件事,第一是帮助客户充分了解自己的需求,第二是尽量降低返工的成本。这种情况下你要想办法避免返工,我认为是不现实的,因为你既不是上帝也不是客户肚子里的虫,你没法知道他究竟想要什么,自然也没法帮他决策。
  • 打赏
  • 举报
回复
saucer 2005-03-10
我也就青润说的作一番评论,因为原先的题目可以用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会慢慢准起来的

这时间估计是由开发人员完成的,不是由用户完成的
  • 打赏
  • 举报
回复
loveisbug 2005-03-09
用成本来衡量。最直观的是时间成本,隐含着的是风险带来的附加成本,其实,都是经济成本。
把增加功能所需的时间开销,大把的银子和可能带来的稳定性降低出错的可能如实详细告诉客户,再由他衡量是否在当前做此调整。
  • 打赏
  • 举报
回复
青润 2005-03-09
呵呵,思归说话了,那我就把问题的相关内容都转贴过来吧,不过,会做一些删减,不必要的内容,就不转贴了:
************************************转贴内容开始***************************************
作者:zidoing
时间: 2005-2-24 09:03:56 标题: 关于软件开发中度的把握。

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

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

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

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

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

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


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

Archie 写道:

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


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

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

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

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


先砍

砍到不能再砍 就开始干

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

回复:
作者:flyingbug
楼上这招虽然很弱,确很实用
就看你们的市场人员是否能顶住压力了:)
************************************转贴内容结束***************************************
  • 打赏
  • 举报
回复
saucer 2005-03-08
javaeye慢的不行,根本连不上,能把问题转贴过来么?
  • 打赏
  • 举报
回复
相关推荐
发帖
研发管理
加入

1242

社区成员

软件工程/管理 管理版
社区管理员
  • 研发管理社区
申请成为版主
帖子事件
创建了帖子
2005-03-08 12:00
社区公告
暂无公告