你的燈亮著嗎?

在我
CODER會起到監督與反馈的的作用.

请不要曲解我的意思，我是说
1.如果一个东西具有不可操作性，那么就无法通过可操作性的方法进行解决。
例如你无法用平面几何的定理去证明一幅水墨画如何勾勒才是最好的最漂亮的，最写意的。
2.软件开发是一个可操作性与不可操作性混合的杂合体。软件开发中即需要有人去画水墨画，也需要有人去证明平面几何定理。
因此整个软件开发的头等大事就是要区分清楚，哪些东西是具有可操作性的，哪些东西是不具有可操作性的。确定边界而后才能谈论方法。

应该让OOD负责对工时的估计，原因有两点：
1.OOD的经验通常比OOP要多，有利于科学安排。
2.OOP不应该把时间浪费在事务性的表格上。
3.如果完全让OOP自己算自己的工作量，怎么确保公平？
但是具体工作中，OOD应当与OOP作沟通，OOD那里的粒度再细，总不如OOP吧？
具体的看法如下：
OOD：负责制定进度安排(根据他自己的经验)并向上汇报，将OOP从具体事务性工作中解放出来。
OOP：主要是coding，但是对于任何进度变化，有责任向OOD反映，当然，最终还是由OOD决定。

感觉和我们的公司有点类似,OOD根据历史数据和现有任务复杂度估计工时,分派任务,OOP执行任务,任务完成后汇报实际工时,QA或PM统计数据，评估差异，分析原因，处理后更新历史数据库。
这里强调的是：
OOD评估时的粒度已经细化到了类，他并不是完全凭自己的经验，而是根据类的复杂度和历史数据来进行评估；
OOP需要反馈实际所用工时；
QA或PM 需要分析估计数字和反馈数据，分析原因，而不是单纯就决定是谁的责任。并且不断更新历史数据，确立新的能力基线。
这是一个不断改进提高的过程。

ziyi
要是我最近的估算有问题呢？让你最近估算，并不是说我就放手不管，我还是要对你的估算作出判断。在分配工作的时候，我不会不先估算一下，但是我的估算只是一个参考值，你自己必须对最近的工作负全则。单纯依靠一个人肯定不行，而不分轻重依靠一些人也不行。对于估算工时这个事情，关键还是那些具体的编程者提供的数据。分析和管理人员的作用是把他们提供的数据汇总，进行分析看看那些不合理那些合理。这体现的是对那些第一线的人的尊重，能做到这一点的公司不是很多，特别是在中国。

是啊，你的出发点是好的，这样可以给予程序员更多的自由。可是出发点有所不同，比如我们公司，目的和你所说的并不一致。OOD不想干，然后推给程序员，并且我们公司是台资的，OOD都在台湾，联系起来就靠电话。还有如果依靠程序员来预估工时的话，那可是要多填两张表格的，所以我们不会觉得是为我们着想。
关于这些东西，我也有和公司同事讨论过
我的想法应该说源于FDD，FDD可以解决我们公司的许多矛盾。我现在也一直在比较。进度管控我觉得我们公司可以遵照FDD，因为我们公司的规格是细粒度的，因该说相当的细。

至少从你现在提供的信息看来你们还不存在实施FDD的基础，特别是你们还不能做到主程序员制度。
而如果你觉得多填两张表格就是一件那么大的事情，我感觉是你们的文档系统有问题，而不是要你们估算最近的工时有问题。而这个估算在我看来是很简单的，OOD把工作分为小的块，然后那些负责这些块实现的人提出一个完成的时间，这就和派工单没有什么差别。如果你们的组织需要动用很多文档来做这个工作，只能说明你的方法太重了，实施FDD是根本不可能的。

你说的对，我们无法实施fdd.我们的分工太明确，其实fdd中有一点是相当重要的，就是ooa/ood/oop隔离的壁垒被打破，好像其他敏捷方法也是如此。
两张表格当然不是大事。我也不是那个意思。我当时也是和头讨论这个问题，可是我说服不了头，主要还是台北要求。不过有一点我不明白，为什么你一定要OOP来负责工时呢，难道你为OOP好。不过在fdd中这是不合适的。
我们的作业系统:ood立案---〉ood委托派工---〉oop收到邮件，说明需要接件（接件前首先要预估工时，然后才能迁出此案，也就是说要你在迁出的时候已经确认工时）。这就是我们公司的一种原始的管理方式，没有灵活性可言。比较一下fdd，根据概念模型建立特征表，根据特征表制定计划，根据特征进行设计，根据特征进行构造。在计划这步就基本已经确定特征的完成时间了，不过这里主要是特征集的完成时间。但是到了设计这一步就完全确定下来了，因为文档已经产生。不过设计更象是在规划，因为是由特征小组（开发人员）参与完成的。