主题：【原创】软件工程问题系列讨论1 -- poorfat
河里一定有很多从事软件行业的高手。小的不才，在此行业里也算垂死挣扎了几年。今特此开一新贴，与大家讨论软件工程的若干问题，仅起抛砖引玉的作用。
先谈谈鄙人在大学里学的软件工程这门课。当时就只学了”个人软件过程“(PSP - personal software process)，其发明人好像是叫William Hummferry,记不清了。
只记得教授让我们每写一个程序都做好多统计，比如程序一共有几行，一共发现多少错误，都是在什么阶段发现的，每个程序一共花了多少时间，然后估算下一个程序大概会花多少时间，等等，很枯燥的。后来鄙人参加工作以后，发现现实世界满不是那么回事儿。
根据鄙人工作以来平时的观察和学习，软件的生产周期大致有这样几个阶段：
1- 计划
2- 设计
3- 实现 （也就是编程）
4- 稳定期（也就是综合测试）
5- 发布，上市
当然，软件发布以后还要提供售后服务等等。
计划阶段干些什么？鄙人认为在计划阶段主要完成这样几件事情：
- 通过用户调研，列出用户需求清单。也就是回答我们应该做什么的问题。
- 大致估算这个项目要花多长时间做
- 做一些可行性方面的调研，以备设计阶段作参考。
（我漏了什么吗？各位请指正。）
鄙人认为计划阶段的难点是第二条，就是如何估算项目要花多长时间做。当你向用户呈现你的计划的时候，用户最关心的问题之一就是，哪一天你可以发布产品。由于尚处在项目早期，还有很多不确定的因素，所以很难准确预测产品的发布日期。
大项目如此，小到单个人的小程序，也有相似情况。不知各位是否有此经历，每次上级来问我“这个程序你什么时候能做完？“我心里都没谱。不知大家平时都怎么估算自己程序的完成时间的？
欢迎大家热烈讨论，我下回继续。
本帖一共被 1 帖 引用 (帖内工具实现)
有时间我写个帖专门说说这个。
一直奇怪为何科技版没有软件工程的话题，但自己忙，不敢挖坑，就聊两句。
估算项目的时间，确实不是易事，要靠经验。
如果是项目经理来估算，有一种叫Function Point（功能点数？）的方法，就是用一套方法数一下整套软件的功能，不同的功能有不同的点数，算出总数之后，再凭借对自己团队的了解，大概可以粗略估算出整个项目的时间。
假如是程序员来估算某个任务，我会建议把这个任务打散成几部分，逐个分析，当然还是要靠经验，以及自己对该任务的了解程度，估算才比较有把握。
《Code Complete》，非常的经典，为这一方面的必读书。有兴趣的话，建议看看。
征集要求有时候也会很麻烦... 用户有很多种，有的知道自己想要什么，有的知道自己不想要什么，有的不知道自己想要什么，有的连自己不想要什么都不知道。更不要提因为种种原因用户追加/改动要求... 你跟他说了半天你以为他明白了他也以为他明白了其实你们俩都没明白。
下面这张图能更好地解释这个过程：
这个问题太大，不是一两种技术就能解决的。
搬个凳子候您大作了
我已经通读了一遍，打算再读一遍。
既真实又幽默。
不过鄙人对于用户需求分析几乎一无所知，还请各位高手补充。
我也送花，挖坑，等您的大作！
关于项目工程工期的评估，我觉得用什么方法评估是次要的，用同一方法对同类项目的评估之间的对比更有意义。
顺便说到项目经理，在国内项目经理通常只是项目联系人，不负责组建团队，在派遣任务时也都通过向部门经理提申请，由部门经理批。而对团队成员的奖惩也只有建议权。不只国外如何？
你说“关于项目工程工期的评估，我觉得用什么方法评估是次要的，用同一方法对同类项目的评估之间的对比更有意义".不知可否请你展开谈谈这个问题？
上回说到计划阶段的难点之一是估算项目时间。为了更好地解决这个问题，让我们先回答为什么要做计划。计划阶段是必不可少的吗？
不知各位如何，这几年来鄙人参与的几个项目，一般都是这样的过程：
- 一开始没人知道要干什么，但是上级说了，一定要在某月某日完成。好嘛，要做什么还没定呢，交货日期倒先给定下了。
- 可需求文档还没写完呢，我们干等着干吗呢？上级说了，不能这样干等着，先干起来。
- 好吧，就先干起来。反正文档也不全，慢吞吞随便写点吧。
- 什么，这就是需求文档？和我写的程序有很多不一样的地方嘛。开会开会，讨论一下。
- 今天几号了？什么，离交货日期就差一星期了？我才完成了三分之一！加班加班！
- 你们质保组的人不要来烦我，我忙着呢！什么什么？发现一堆错误？唉，好吧，记下来让我慢慢改。
- 交货期到了，我们按时交货! 什么，还有错误？没关系，世界上那有没错误的软件？就这样吧。
为什么会是这样的结果？鄙人认为就是计划不周造成的。
- 计划做得好，就可以据理力争，说服上级延后交货日期
- 计划做得好，就不会等到开干了还不知道应该干什么
- 计划做得好，就不会造成文档和程序不一致。
- 计划做得好，就不会沦落到要加班开夜车的地步
- 计划做得好，程序的错误就会少多了，质保组的人就不会成天来烦你
- 计划做得好，交给用户的产品错误就少，售后服务的代价就降低。
所以，为了可以少加班，为了过舒心日子，把计划定好吧。
各位软件行业的高手们，也一定有一些这样的例子吧，欢迎补充。
那么，如何比较准确的估算项目所需时间呢？对于多人参与的项目，鄙人新学了一种方法，在这里介绍给大家。这个方法叫做德尔法办法(delphi method)。具体做法是这样的：
- 把参与项目的人都召集起来开会
- 每人写下这个项目所要花的时间，并且要写下理由。注意，不准交头接耳，以免个人的观点受到他人影响，对得出准确结果不利。
- 当每个人都写完后，每个人向大家阐明自己的理由和估算的时间。其他人可反驳或支持其理由。 这时一般来讲，各人估算的值会相差很大。
- 然后重复第二步，每个人再一次写下估算的时间，并且把别人提出的理由也考虑进去。但是还是不准交头接耳。
- 重复第三步，大家交流第二次估算的时间值。这一次的时间范围就会小得多了。
- 如果感觉估算值范围还是太大，就再做第三次估算。但是一般来讲，三次就足够了。
不知我描述得是否准确，各位高手请给与批评指正。谢。
软件工程可以在系统工程版里边讨论，等时机成熟了可以再独立。呵呵……
令我羞愧的是，我所经历的软件开发项目，包括亲历开发和参与管理的，几乎全部都经历延期。
仅有的少数及时完成的软件，是在“后墙不倒”的最后期限式的管理模式下完成，没有阶段划分、没有集中的调试测试，没有配置管理，只有无休止的联调、模拟运行，这是军队中的工作方式，我想地方的程序员是很难适应这样的工作方式的。
关于工期估算，我在Tom Demarco的最后期限（The Deadline）一书的第十二章 数字人中读到：
度量每个产品的规模。
不要执著于单位-在等待客观度量的时候，先用你自己的主观单位。
从所有能得到的原始数据（可计算的软件特性）自己构造度量单位。
从已完成的项目中收集原始数据，以推导出生产力趋向。
不断完善你的度量方程式，直到它的计算结果与原始数据库中的项目工作量有最好的对应关系。
借助数据库画一条趋势线，把预期工作量作为人造度量单位值的函数显示出来。
现在针对每个要评估的项目，计算人造度量单位值，并根据每个值在趋势线上找到预期工作量值。
用生产力趋势周围的干扰水平作为映射的公差指示。
我个人认为此书值得每位对项目管理有兴趣的人一读。
关于我本人在国内作项目的经验，还可以补充：
(1)该项目用户方有n级领导，工作量在功能点计算结果基础上*n;这是可预计最坏情况，可以在乐观估计和这一估计之间报告一个值，但建议偏向悲观估计。
（2）大多数延误不在实际的系统功能开发上，而在于与运行环境的接口上，但不建议将为接口开发调整的估计耗时报告上级和用户，而是偷偷平摊到各个阶段中，否则必然被砍掉。
（3）对于为政府部门开发系统，如果该功能实现需要行政审批确认，基本不可能获得签字，但可以获得默许。对于处级单位的确认，可以以天计算反馈时间，对于局级单位，以周为单位计算反馈时间。对部级单位，含办公厅，以月为单位计算反馈时间。结论：不可能在考虑开发周期中考虑这样的反馈时间。
（4）在此类工程项目的立项报告中不要试图计算真正的工期，只要汇报理想情况下没有干扰的预计工期。