控制进度的问题

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

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

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

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

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

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

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

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

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

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

FDD 最好有color Uml搭配。
可以达到需求和程序结构相当程度对应。
我觉得如果没有强悍领域建模能力为基础，FDD也难以实行。

期待o6z的献礼

我刚出道不久.真是不知道如何控制进度