控制进度的问题

管理是一门软科学，控制是管理工作的核心之一，而软件开发管理和其它的项目管理相比又有相当大的特殊性，进度不确定性比较大。所以软件开发项目的进度控制应该是相当具有复杂性的问题。
我的观点有以下几点：
1、进度控制有精度的问题，任何过于精细的控制方法都是高成本的。适可而止！所以进度一般都是估算值。（除非项目还没开始或已经结束）
2、进度控制和项目风险密切相关，有时候风险控制的好，才能保证进度。
3、项目目标要明确或基本明确，否则进度控制就是空谈。最好每人每段时间的目标都要基本明确。
4、不同的项目管理阶层可以对进度有不同的算法，只是数字要自己保证是大致正确的就行。
5、很多时候还是要通过交流来保证每个级别上的进度控制。

你说的这个就是《敏捷软件开发》里面说的方言的含义。这个方式当然是最有效的，而形成这样的一个方言语音需要长久的积累。作为一个新人，无论你采取什么方式，想去学习这个语言都会很困难，以至于不可能，这是因为这个方言完全是建立在共同体验的基础上的。那么问题就来了，你是耐心等待一个方言的形成；还是定义好大家各自的语言，然后在慢慢等待方言来替代？我想没有人会傻乎乎的在那里干等的。而同时请注意，这个确定各自语言的过程，也是方言形成的过程，因为在这个过程中也是一个建立共同体验的过程。
而问题还有另外一个方面，不是在所有方面都需要确定一个完整的语言，更不是在所有方面都需要一个特定的语言去表示。其实也就是你只需要在关键的地方，建立一个普遍遵守的语言表达的契约。
而关于进度这个事情，其实很多人都没有考虑到一个背景。那就是绝大多数时候，都是技术人员在向其他人员解释进度究竟到达什么地方了，而不是其他人本质自己收集的数据，建立自己的进度指标。也就是说不管你怎么搞，数据的采集和分发，都是技术人员的事情。而数据的解释，你要么选择在前面一次解释清楚，随后仅仅是小规模的维护。要么就是选择，遇到问题再解释，一直修修补补的方式。究竟什么策略有效，我想大家自己可以根据自己的实际操作得到答案。

我觉得这里的讨论也存在词汇歧义。如果O老能把自己考虑的,比较成型的东西写出来,讨论应该会更有的放矢一些。大家都是按照自己的背景在说,会有各自不同的方向。然而方向可能并不那么重要,重要的是能够坚持一个方向,在一点上把问题和解决方法细化.

其实不用，我只是简单解释一下方言、语言的含义，很多事情就明了了。
所谓方言，就是大家有共同的经历之后，在一个词汇字面本身没有的含义的基础上，存在了基于共同体验的含义。比如你跟你妈妈说“那一夜我没睡着”，同你和你老婆说“那一夜我很快乐”，同你儿子说“那一夜我没有看到你”，这里的《那一夜》显然都是基于各自不同的共同体验，具有很多的含义的，并且由于对象的不同所指的东西也不同，这个就是方言。
而如果你们几个对一个词汇都有了类似的认识，并且产生了比较明确的约束，意义也很统一，那么就形成了语言。比如你在一个施工队里面说：“谁也别到拐角那里去。”你并没有明确究竟是哪个拐角，但是大家都知道你说的是哪里，这个就是你们自己的语言。
其实你看看我们讨论的这个过程，可以看出一个方言建立的过程是多么困难，而一个语言建立的是比较简单。这就是我说的问题的一个注解。

我觉得现在注重交流已经和敏捷一样快成了一种没有啥好味道的老生常谈了。

所谓的方言,就是特殊环境下缩略用语吧.如果能够把全部的内容说全,就不需要解释了. 比如  管理咨询公司说"项目"和 软件公司说"项目",铁定不同. 但是 管理咨询项目,和软件开发项目,这样的完整的说法,不明白的人就少很多了.

还不是缩略语那么简单，方言的意义是不明确的，含义也是在演化的。缩略语更加类似于语言。
而很多时候，有些东西用明确的语言来描述是很困难的，语言和方言就是来填补这个空白的。

汗...楼主是个eva中毒者...

我大致看了一下这个帖，我觉得这个话题应该围绕release plan来考虑。
在制定release plan的时候因该考虑三个因素：目标，资源，时间。

FDD只是目标这方面，也就是要做什么。而资源（在软件开发上主要就是你团队里面的人）和时间这两点上往往不是很靠谱，我所知道大部分团队的做法无非就是让专人估计一下要多久，再乘上一个保险系数，叫来认为足够多的人，然后大家挽起袖子开干。要知道这样的水平离真正的量化管理的水平还差得远。

oz6如果有空还请进一步描述一下你的FDD,这样大家可以用来作为讨论的基础。

在我看来,FDD的有效性来源于, 需求和程序结构的对应统一.

我不这么认为，架构是架构，功能是功能。加入一个新功能往往需要重构，但是一对一的对应关系是不应该存在的。往往这里就是UML真正发挥作用的地方。如果一个项目的UML表述很清晰，一个新加入的功能往往可以很轻易的找到其和结构的关系，也很容易看清楚是否有重构的需要。