主题：【原创】软件工程问题系列讨论1 -- poorfat
家园 【原创】软件工程问题系列讨论1 河里一定有很多从事软件行业的高手。小的不才，在此行业里也算垂死挣扎了几年。今特此开一新贴，与大家讨论软件工程的若干问题，仅起抛砖引玉的作用。
先谈谈鄙人在大学里学的软件工程这门课。当时就只学了”个人软件过程“(PSP - personal software process)，其发明人好像是叫William Hummferry,记不清了。
只记得教授让我们每写一个程序都做好多统计，比如程序一共有几行，一共发现多少错误，都是在什么阶段发现的，每个程序一共花了多少时间，然后估算下一个程序大概会花多少时间，等等，很枯燥的。后来鄙人参加工作以后，发现现实世界满不是那么回事儿。
根据鄙人工作以来平时的观察和学习，软件的生产周期大致有这样几个阶段：
1- 计划
2- 设计
3- 实现 （也就是编程）
4- 稳定期（也就是综合测试）
5- 发布，上市
当然，软件发布以后还要提供售后服务等等。
计划阶段干些什么？鄙人认为在计划阶段主要完成这样几件事情：
- 通过用户调研，列出用户需求清单。也就是回答我们应该做什么的问题。
- 大致估算这个项目要花多长时间做
- 做一些可行性方面的调研，以备设计阶段作参考。
（我漏了什么吗？各位请指正。）
鄙人认为计划阶段的难点是第二条，就是如何估算项目要花多长时间做。当你向用户呈现你的计划的时候，用户最关心的问题之一就是，哪一天你可以发布产品。由于尚处在项目早期，还有很多不确定的因素，所以很难准确预测产品的发布日期。
大项目如此，小到单个人的小程序，也有相似情况。不知各位是否有此经历，每次上级来问我“这个程序你什么时候能做完？“我心里都没谱。不知大家平时都怎么估算自己程序的完成时间的？
欢迎大家热烈讨论，我下回继续。
本帖一共被 1 帖 引用 (帖内工具实现)家园 【原创】2. 计划阶段的一些问题 上回说到计划阶段的难点之一是估算项目时间。为了更好地解决这个问题，让我们先回答为什么要做计划。计划阶段是必不可少的吗？
不知各位如何，这几年来鄙人参与的几个项目，一般都是这样的过程：
- 一开始没人知道要干什么，但是上级说了，一定要在某月某日完成。好嘛，要做什么还没定呢，交货日期倒先给定下了。
- 可需求文档还没写完呢，我们干等着干吗呢？上级说了，不能这样干等着，先干起来。
- 好吧，就先干起来。反正文档也不全，慢吞吞随便写点吧。
- 什么，这就是需求文档？和我写的程序有很多不一样的地方嘛。开会开会，讨论一下。
- 今天几号了？什么，离交货日期就差一星期了？我才完成了三分之一！加班加班！
- 你们质保组的人不要来烦我，我忙着呢！什么什么？发现一堆错误？唉，好吧，记下来让我慢慢改。
- 交货期到了，我们按时交货! 什么，还有错误？没关系，世界上那有没错误的软件？就这样吧。
为什么会是这样的结果？鄙人认为就是计划不周造成的。
- 计划做得好，就可以据理力争，说服上级延后交货日期
- 计划做得好，就不会等到开干了还不知道应该干什么
- 计划做得好，就不会造成文档和程序不一致。
- 计划做得好，就不会沦落到要加班开夜车的地步
- 计划做得好，程序的错误就会少多了，质保组的人就不会成天来烦你
- 计划做得好，交给用户的产品错误就少，售后服务的代价就降低。
所以，为了可以少加班，为了过舒心日子，把计划定好吧。
各位软件行业的高手们，也一定有一些这样的例子吧，欢迎补充。
那么，如何比较准确的估算项目所需时间呢？对于多人参与的项目，鄙人新学了一种方法，在这里介绍给大家。这个方法叫做德尔法办法(delphi method)。具体做法是这样的：
- 把参与项目的人都召集起来开会
- 每人写下这个项目所要花的时间，并且要写下理由。注意，不准交头接耳，以免个人的观点受到他人影响，对得出准确结果不利。
- 当每个人都写完后，每个人向大家阐明自己的理由和估算的时间。其他人可反驳或支持其理由。 这时一般来讲，各人估算的值会相差很大。
- 然后重复第二步，每个人再一次写下估算的时间，并且把别人提出的理由也考虑进去。但是还是不准交头接耳。
- 重复第三步，大家交流第二次估算的时间值。这一次的时间范围就会小得多了。
- 如果感觉估算值范围还是太大，就再做第三次估算。但是一般来讲，三次就足够了。
不知我描述得是否准确，各位高手请给与批评指正。谢。
家园 你们是做公司内部的项目吗？ 如果是外面的项目，怎么会开始都不知道要做什么呢？项目一般有多大（多少人、多久完成）？
那个delphi method算是比较实际的一种估计方法。几年前看过“功能点法”（function point)，也试过一次。感觉比较复杂，需要一段比较长的时间才能真正用得好。而且不是个人想用就能用的，得是一种公司行为。
不过我觉得delphi方法也用不着让所有参加项目的人都参加，没必要让所有的开发人员参加（主要是他们并不了解项目的整体）。我们一般是项目经理、需求分析（如果项目小，项目经理就兼了）、技术负责一起开会讨论。
家园 多数是内部项目 我们的主要问题是前期拖拖拉拉，到后期就猛加班赶进度，粗制滥造，最后上交一堆臭虫。
- 复 多数是内部项目
家园 这不是你们独有的问题，这是我们IT界共有的问题。 看看那家世界上最大的软件公司是如何“按期推出”产品就可以对我们这个行业有个本质的认识了。
前两天看微软Longhorn部一主管谈他们是如何进行该项目管理的，可惜技术部分讲的太少。说实在的，我对那么个庞然大物是如何build，如何release的是很感兴趣的。
家园 是啊，是啊，微软不延期，那是个意外 Longhorn改名叫Vista了。我就和同事开玩笑说，这样下回就不用说Longhorn第N次延期了，而是说Vista第一次延期
不过那么个大家伙，如何管理确实让人感兴趣。我想微软应该比很多软件公司做得好。水平不够，项目大了都不敢接啊。
家园 【推荐】这里有段录像,建议看看 家园 第一项任务也不轻松 征集要求有时候也会很麻烦... 用户有很多种，有的知道自己想要什么，有的知道自己不想要什么，有的不知道自己想要什么，有的连自己不想要什么都不知道。更不要提因为种种原因用户追加/改动要求... 你跟他说了半天你以为他明白了他也以为他明白了其实你们俩都没明白。
下面这张图能更好地解释这个过程：
家园 美国有个作家，叫做Steve McConnell，他写过一本书，叫做 
外链图片需谨慎，可能会被源头改《Code Complete》，非常的经典，为这一方面的必读书。有兴趣的话，建议看看。
外链图片需谨慎，可能会被源头改关键词(Tags): #Steve，#McConnell，家园 好书好书 我已经通读了一遍，打算再读一遍。
家园 这个话题对胃口 一直奇怪为何科技版没有软件工程的话题，但自己忙，不敢挖坑，就聊两句。
估算项目的时间，确实不是易事，要靠经验。
如果是项目经理来估算，有一种叫Function Point（功能点数？）的方法，就是用一套方法数一下整套软件的功能，不同的功能有不同的点数，算出总数之后，再凭借对自己团队的了解，大概可以粗略估算出整个项目的时间。
假如是程序员来估算某个任务，我会建议把这个任务打散成几部分，逐个分析，当然还是要靠经验，以及自己对该任务的了解程度，估算才比较有把握。