Scrum sprint plan中规模估算的做法调查
克强
1，假设1个user story point需1个理想人天， Velocity为理想人天数/实际人天数，常见的范围是50%~80%。
sprint估算时，估算可用人天数 * Velocity 得到 user story points数量。
2，选择最小的工作单元为1个User stroy point，velocity为user story points数量/理想人天数，再考虑资源
利用率，可能是75%左右。sprint估算时，估算可用人天数 * 资源利用率 * Velocity 得到 user story points数
量。
3，选择最小的工作单元为1个User stroy point，velocity为user story points数量/实际人天数，不再考虑资
源利用率。sprint估算时，估算可用人天数 * Velocity 得到 user story points数量。
4, 采用use case point作为规模，Velocity为use case points数量/实际人天数，不再考虑资源利用率。
sprint估算时，估算可用人天数 * Velocity 得到 use case points数量。
还有没有别的做法？
调查：
1，所在团队实际用了哪种做法？
2，你倾向于采用哪种做法？
姜志辉
我们团队第二种情况使用的情况可能居多一些。不过有一些出入：
1、受Joel的影响，我们采用的基本单位为人.时，不是人.天，我们基本估算团队的有效工作时间为5小时/每天
2、除了资源利用率，会把在这个阶段的一些风险考虑进去，我们叫缓冲时间。比如十一的假期等等。这个你可能考虑到Velocity里了，但我还是把他单独提出来，因为不同的时间段缓冲时间是不一样的。
3、一般我们会在一开始做两个小而价值比较高的user story试试看，然后重新估算
基本上可以看出来，我们的估算受Joel的影响比较大。
姜志辉
1、我在接国内项目的一些经历显示，多数情况下，如果一个项目时长是一年，那么在接这个项目之前，我们大概要花费一个月左右的时间来和用户反复的沟通
(这里是一个概数，举一个例子，没有这种时间比)，沟通的内容包括需求／大概的实现方案／周期／费用等。这个不是开发团队可以掌握的，甲方在这个位置是
有要求的，他们需要看到一个合适的方案，我们估切叫他“可行性分析报告”吧，这个在中国的北方尤其明显。(可能地域不一样，结果不一样。但北方的大多数
企业一定会有这个过程，我们无法越过)。在这种情况下，我会把所得的需求通过Use Case来整理。如果对应Cockburn的五个级别，我们整理的
级别主要对应于风筝级和用户目标级。这个时候整理的需求，到了实施时会发生变动，此时整理成Use Case是为了方便整体上的概览。另外，是因为
Use Case用户比较容易接受(好多兄弟会有反对意见，我以前也有心理障碍，不过多数用户在这里真的有“正规度”的要求，因为他们有一个评审的流
程，这应该是国内软件工程相对落后的一部分，但不是我们一两个开发团队可以掌控的)。
2、等那个“可行性分析”的阶段过了之后，我们会采用User stroy的方式。很多时间我们将之前整理的Use case进行优先等级的整理，然后
找到业务价值比较高的用例进行分解，整理成User Story。这种方式团队比较容易接受，而且有利于我们的迭代。(之前我们是将风筝级的Use
Case细化为用户目标级，后来发现不如用User Story有效，团队可能把注意力更早的集中到实现上，而不是开会)
3、将两个比较重要的User Story放置在迭代中后，我们会将User Story分解成任务(现在团队采用Excel的人.时工作卡，这种工作
卡会利用Excel的宏自动转化成backlog)完成冲刺。
所以我们团队在开发过程中采用了Use Case、User Story、Task（多数情况下是sprint backlog）。在这里我们没有对需
求进行跟踪(说明一点，我们并不把这些东西当作工件，只是用来使团队聚焦的一种手段，所以我们并不维护这些制品，之前邮件组有一个关于这方面的讨论)，
不同的情况下，用不同的整理方法会有不同的效果。在此我认为这些都是方法，具体用哪个取决于不同的环境和湿度。
想起宫本的一句话：“不应该盲目的使用某一种固定的方法，太多和不足都是有问题的，注意实效才致关重要”
这是我在一些项目(尤其是北方的一些大型企业)中的使用情况，只是个人的工作方法，只代表个人的一些见解，把他当作案例说出来，和大家一起讨论。共同交
流。请各位批评批正。(不用考虑措辞，就事论事。但我不希望看到毫无建设性的冷嘲和热讽)
On 10月2日, 上午9时12分, 姜志辉 <ibags...@gmail.com> wrote:
> h1,克强。
> 我们团队第二种情况使用的情况可能居多一些。不过有一些出入：
> 1、受Joel的影响，我们采用的基本单位为人.时，不是人.天，我们基本估算团队的有效工作时间为5小时/每天
> 2、除了资源利用率，会把在这个阶段的一些风险考虑进去，我们叫缓冲时间。比如十一的假期等等。这个你可能考虑到Velocity里了，但我还是把他单独提出来，因为不同的时间段缓冲时间是不一样的。
> 3、一般我们会在一开始做两个小而价值比较高的user story试试看，然后重新估算
> 基本上可以看出来，我们的估算受Joel的影响比较大。
>
> 2009/10/2 克强 <zhangkeqi...@gmail.com>
Xu Yi
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
Xu Yi
张克强
Daniel Teng
Xu Yi
User Story是无单位的.
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
姜志辉
Thanks
我刚刚查阅了一下资料。story point确实是无单位的。这里找到了一个摘录：
"Next we take the stories that the customer selected and break them
down into tasks.A task is much smaller than a story.It is a unit of
work on the order of four to 10 man-hours is size."
他只说了大小约是4到10人时，确并没有指定单位是多少。我又查阅了一些相关资料，都没有指明单位，只是说大约多少人时
而Joel的任务划分是人.时为单位的，但没有说是故事点，只说是任务。
On 10月5日, 下午5时09分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/5 Daniel Teng <tengzhe...@gmail.com>
>
>
>
> > User Story是无单位的.
>
> 哈哈，犯了和我一样的错误嘛~ 无单位的是story point，而不是user story。
>
> > On 10月5日, 上午6时33分, 张克强 <zhangkeqi...@gmail.com> wrote:
> > > unitless作何解？
> > > 是 "无单位"？
>
> 是的。user story用于评估user
> story的相对大小（bigness），它并无一个可用于度量的单位值。时间或是长度单位，例如"小时"和"米"，乃是全世界同一的度量。
>
> 一定程度上可以说story
> point最终会达到具有一定的单位效用。当某产品开发大团队（包括若干scrum团队）保持团队稳定，以及开发足够长时间后达到velocity稳定时，可以-借由建立一定程度上story
> point向"成本"、"时间"等度量的映射，使其成为"虚单位"。
>
> 例如，平均下来大团队（5个人/scrum团队 *
> 5个scrum团队）每个sprint（4周）能完成50个point，那么可以将一个point等同为一个时间范围，1 point = 40~70h
> (假设scrum团队的capacity为可用时间的80%到50%之间，5*5*140/50 和5*5*80/50)。
>
> 同样，也可以将point和费用、收入联系在一起。假设上述25人大团队的每月总费用是12.5万元。那么可以认为一个point的成本是2500元，需要的时-候，可以通过计算某个user
> story的可能性收入，并与其成本做比较进行决策。
>
> 但问题在于，对于不同的组织或是产品大团队，其成本因素以及开发效率都不同，这也造成其每个point的相对应时间、成本虚单位不同。而且形成稳定的point-虚单位，需要维持point的相对大小一致很长时间，一年两年甚至更长时间。
张克强
的范围的限制，说"这个sprint做32个story points"是常见的做法，在这个语境下，story point就是单位。 user
story point不是一个像"Function point"一样在全球有完全一样尺度的单位，每个团队的story point都有各自的尺
度，无法横向比较，但可以纵向比较，将point和时间、价值单位联系起来, 是story point数量统计的目的。
提议不再讨论story point单位的问题, 或者开新贴。
把讨论集中在sprint plan的估算实践上，就做过的或是见过的实际做法上。
--
-----------------
张克强
blog: http://hi.baidu.com/hespr
-----------------
On 10月5日, 下午5时09分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/5 Daniel Teng <tengzhe...@gmail.com>
>
>
>
Xu Yi
HI，Xu Yi：
Thanks
我刚刚查阅了一下资料。story point确实是无单位的。这里找到了一个摘录：
"Next we take the stories that the customer selected and break them
down into tasks.A task is much smaller than a story.It is a unit of
work on the order of four to 10 man-hours is size."
他只说了大小约是4到10人时，确并没有指定单位是多少。我又查阅了一些相关资料，都没有指明单位，只是说大约多少人时
而Joel的任务划分是人.时为单位的，但没有说是故事点，只说是任务。
Xu Yi
提议不再讨论story point单位的问题, 或者开新贴。
把讨论集中在sprint plan的估算实践上，就做过的或是见过的实际做法上。
Xu Yi
张克强
能否说说你们是如何做的？或者你见过的可取做法?
On 10月6日, 上午10时19分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/6 张克强 <zhangkeqi...@gmail.com>
张克强
看看前几个sprint完成的user story point数量，或采用平均数，或上个sprint的story points数量，或根据情
况在以前基础上略作调整，这样就不必管velocity的计算了。前提是团队人员工作量投入变化小，人员稳定。
张克强
分解user story到任务(Task)，计算这些任务的总人时，再与sprint可以提供的工作量和资源利用率 匹配
即：sprint可以提供的工作量 * 资源利用率 约等于 所选user story对应任务的总人时
Joel所说的Task( a unit of work....)在不同的user story里所需的人时是不是一样的？
Xu Yi
姜志辉
姜志辉
应该说，原则来自于bob，方法来自于joel。每次迭代完后，团队在反思讨论会有一些改动意见，然后就加进来，有些改动对我们不错，有些改动发现有问
题就再改回来。总体上变动不大。
On 10月7日, 上午2时39分, 姜志辉 <ibags...@gmail.com> wrote:
> 是的，这里用EXCEL的好处有三点：
> 1、EXCEL可以直接计算总人时，一旦有变动，会在实际栏里记录，这样会有一个比较，而且计算是自动的。每次迭代后，估算的误差一目了然，如下：
> 故事 任务 估算值 实际值 误差 ...
> A A1 2 4 2
> A2 3 2 -1
> .. ...
> 5 6 1
> 2、通过EXCEL的图表功能直接产生燃烧图(我自己对应燃烧图产生的图，不纯)
> 3、通过EXCEL的宏功能直接产生backlog(又是我自己的对应backlog产生的冲刺任务，不纯)，然后打印出来，贴到白板上
>
> 2009/10/6 张克强 <zhangkeqi...@gmail.com>
张克强
（原文见http://blog.vsharing.com/agiledo/A969391.html
http://blog.vsharing.com/agiledo/A969385.html）
1,记录前面几个sprint的实际的可以利用的资源（以人天为单位） 和 实现功能的IMD（Ideal Man Day），计算 资源利用率：实际
完成功能的IMD / 实际可利用的资源。 资源利用率可以取多个sprint的平均值，也可取上个sprint的单点值。
2,即将开始的Sprint内可以利用的资源是可以首先计算的，乘以资源利用率 ，得到 本sprint的IMD
3, 按功能的优先级，本次Sprint要达到的目标，选择优先级最高的功能，分解为实现任务，并评估如何实现，不断评审优先级最高的一些功能，直至
Team不能承诺完成为止，也即是所选功能的累积IMD达到了 本sprint的IMD。
这里面 “实现功能的IMD” 的理解有点小弯弯的，我试谈谈我的理解：
1，如果某个sprint计划时 选择了50IMD的功能，sprint结束时正好做完计划所选功能，那么实现功能的IMD就是50。
2，如果某个sprint计划时 选择了50IMD的功能，sprint结束时没有做完，那么考察没有做完的功能还要多少个IMD，假设是5，那么实现
功能的IMD就是50-5 = 45。
3，如果某个sprint计划时 选择了50IMD的功能，sprint结束时做完了，并从backlog中又挑了一些功能做完了，考察这些功能要多少
IMD，假设是5，那么实现功能的IMD就是50+5 = 55。
实现功能的IMD的计算与实际投入多少人天是无关的。
请Andy指正。
我的问题：实践中 功能分解到任务的大小一般是什么样的数量级？1~3 IMD or 4~10人时？ 前面姜志辉show的例子是2~6人时。
--
-----------------------------
blog:http://hi.baidu.com/hespr 高效过程研究
张克强
On 10月6日, 下午5时11分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/6 张克强 <zhangkeqi...@gmail.com>
>
Xu Yi
张克强
工作量？
或者不考虑投入工作量，直接以一个sprint能完成多少个story point来表达？
On 10月10日, 下午10时57分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/10 张克强 <zhangkeqi...@gmail.com>
Xu Yi
team过去的velocity是如何计算的？ 考虑投入工作量吗？ 是不是 sprint完成的story point数 除于 sprint投入的
工作量？
或者不考虑投入工作量，直接以一个sprint能完成多少个story point来表达？
Vincent Lee
Xu Yi
（9+12+5+16+10）/5=10.4这么算误差太大了，应该是每次迭代之后，用完成的任务点数处以实际投入的人日数。
Vincent Lee
Xu Yi
每次迭代能投入的人日数受很多因素影响，你那种算法得不出什么有意义的结果！
你真的喜欢你的"velocity"?
Vincent Lee
Xu Yi
Vincent Lee
如果之前说过的话麻烦您再重发一遍。
而且我指出了你的这个算法的问题：
Liu Jun
看不出你所说的算法在何处减小了误差。
Vincent Lee
但是每个sprint能够实际投入的人日数是无法确定的，比如下一个sprint新增了人手，可用资源增加了，
所以这个平均story point没有意义。
而我说的算法是“用完成的任务点数除以实际投入的人日数”，假设前5个sprint分别完成9、12、5、16、10个story point，实际投入的人日数分别为20、20、25、25、20，（9+12+5+16+10）/（20+20+25+25+20）=0.47，利用这个数值以及下一个sprint的可用资源（比如是25），就可以算出下一个sprint可以完成的工作量：0.47*25=11.75
进一步的，由于可以乐观的认为团队熟练程度在提高，可以调高速度为0.5，于是预计可以完成0.5*25=12.5的工作量。
Vincent Lee
其中关键就是point值等于1的那些原子story不要有太大误差，
然后其他story以原子story为参照，比如point值为2的必须是原子story工作量的2倍，以此类推。
Xu Yi
当然还有个前提就是，每次做计划时对story point的评估要按照一致的标准，
其中关键就是point值等于1的那些原子story不要有太大误差，
然后其他story以原子story为参照，比如point值为2的必须是原子story工作量的2倍，以此类推。
Vincent Lee
Vincent Lee
Xu Yi
Vincent Lee
你的velocity的定义是什么，是每个sprint可以完成的工作量，对吧？
可是不同user story的工作量有数倍的差距，你算出每个sprint的平均story个数跟工作量没有任何换算关系，算它干什么用呢？
Vincent Lee
如果拿坐车来比喻的话，一个story比作一站地，一个sprint比作一段路程，
你那个公式算出的是平均每段路程有几站地远，而不是车速。
除非是理想情况的每站间隔相同并且每段路程的站数也相同，这个值才等价于速度。
但是理想情况基本没有，真正有意义的是每小时走几公里、每个人日可以完成多少story point。
Jun Liu
Vincent Lee
先把story按优先级降序排列，
然后用velocity乘以估计的可用人日数，得到可以完成的story point数N，
然后从story列表里从高到低选取story作为本次sprint开发的内容，直到选取的story的合计point数达到了N。
over！
Xu Yi
这不是很明显的问题吗？
你的velocity的定义是什么，是每个sprint可以完成的工作量，对吧？
可是不同user story的工作量有数倍的差距，你算出每个sprint的平均story个数跟工作量没有任何换算关系，算它干什么用呢？
Vincent Lee
你觉得我说的前一个问题是否存在呢？
================================
（9+12+5+16+10）/5=10.4，
但是每个sprint能够实际投入的人日数是无法确定的，比如下一个sprint新增了人手，可用资源增加了，
所以这个平均story point没有意义。
而我说的算法是“用完成的任务点数除以实际投入的人日数”，假设前5个sprint分别完成9、12、5、16、10个story point，实际投入的人日数分别为20、20、25、25、20，（9+12+5+16+10）/（20+20+25+25+20）=0.47，利用这个数值以及下一个sprint的可用资源（比如是25），就可以算出下一个sprint可以完成的工作量：0.47*25=11.75
进一步的，由于可以乐观的认为团队熟练程度在提高，可以调高速度为0.5，于是预计可以完成0.5*25=12.5的工作量。
Xu Yi
哦，“sprint的平均story个数” 是个误会，我道歉！
你觉得我说的前一个问题是否存在呢？
Vincent Lee
2009/10/13 Xu Yi <kave...@gmail.com>
一旦这些story个头偏大或偏小，part 2详细估计很可能发现工作量太大无法完成或工作量太少不够做，然后怎么办呢？
Jun Liu
张克强
同样，commitment后的估算能有多靠谱？ 也是个问号？
为便于叙述，把根据sprint历史数据得到的估算，称为 历史数据估算，把commitment之后的估算 称为 承诺估算。
历史数据是以前的定量情况，包括但不限于资源利用率、sprint可以完成的story point数量、每个story point平均所需的【实
际】/【理想】人时（或工时）数、每个use case point平均所需的【实际】/【理想】人时（或工时）数，等等。
（在第一次发帖时，我并没有把承诺估算看作是估算，我看成了承诺的达成和调整）
（在Xu Yu的帖子中，提到了"过去的平均velocity只是作为参考而已","team过去的velocity也可以用来粗略估计team在当前
sprint可能完成哪些feature",更强调“具体的commitment是依赖于sprint planning part 2估计出来的
hour-based capacity和effort来决定做哪些feature的。”）
在我所见到的实践中，“猪”们（scrum中意思，绝无其它意思）的承诺都基于历史数据估算，就算是第一个sprint的估算，也参考了非敏捷生命周期
的数据。承诺估算虽然会调整些，但幅度都在25%以内，多数情况下幅度小于5%。
历史数据估算在sprint plan时看起来是不可少的。（有没有真的不做的？）
而承诺估算很难单独应用，我所见的“猪”们没有单独这样估算过。
我的看法：把历史数据估算的结果（包括微调）作为承诺来达成，不失为一种可行的做法，尤其适合引入scrum不久的团队和有新人的团队。
--
-----------------------------
blog:http://hi.baidu.com/hespr 高效过程研究
张克强
承诺估算是要分解到任务再累加的，而我上贴中“承诺估算虽然会调整些，但幅度都在25%以内，多数情况下幅度小于5%”就说错了。
上句话应当改为“基于历史数据估算得到的承诺虽然会调整些，但幅度都在25%以内，多数情况下幅度小于5%”。
如果承诺估算中在sprint刚开始时把story分成2~8人时的任务，这样的颗粒度我没有在scrum中经历过，我在瀑布生命周期的阶段估算中经历
过。而在瀑布生命周期中的回忆是痛苦的回忆。
请教经历过的朋友，在scrum sprint plan时开展2~8人时颗粒度的承诺估算有什么注意点，有什么有效实践？
Xu Yi
阿捷：那具体怎么做呢？大家一起做计划，岂不是很乱？
敏捷圣贤：首先，你们要先定下来Sprint的目标，即作为一个团队，你们要完成什么，然后再决定完成多少。
阿捷：我们当前没有任何历史参考数据，怎么知道完成多少呢？
敏捷圣贤：事先计算出在一个Sprint内，团队的可能工作时间。譬如，在未来三周内，一个5人小组，每人每周工作40小时，那么总的工作时间=5×40×3=600小时。
阿捷：理想情况是这样的，但肯定会有人休假的。
敏捷圣贤：对，所以你要将总的工作时间扣除任何预期的非工作时间。譬如，有一个人要休一个礼拜的年假，还有人要看牙，需要占用3天，这样算起来是600-5x8-3x8=536小时。
阿捷：还有，即使每人每天工作8小时，但也不是会真的有8小时工作在项目上，还要参加各种Tea Talk、培训、Team Building等活动。
敏捷圣贤：如果每天8小时，你们大概会有几小时工作在项目上？
阿捷：平均差不多6小时吧。
敏捷圣贤：你得把每天花在参加会议、谈话、处理邮件、上网等时间都除去。
阿捷：那估计5小时。
敏捷圣贤：我们把它用百分比表示，5/8，那么就是60%左右，然后用这个“负荷指标”（Load Factor）乘以总的工作时间小时数，你就得到了536×小时。
阿捷：嗯，这种估算很实际。
敏捷圣贤：然后从产品Backlog中，按照优先级从高到低，选择出你们认为能在322小时内完成的条目，作为你们当前Sprint的Backlog。注意：选择的Sprint Backlog Item一定要强内聚、松耦合，这样你们才能不受或者少受外界的干扰，目标明确。
阿捷：那个“负荷指标” 60%应该是变动吧？我们刚做一个项目，跟项目做了一段时间相比，肯定是不一样的。再譬如我有新员工加入时，他的效率肯定是要比老员工低的。
敏捷圣贤：对。你已经很好地理解了负荷指标，你可以利用它把Sprint计划得很准确。当你遇到低的“负荷指标”时，要试着找出根本原因，这会使你门的Sprint更有效率。
阿捷：下一步是不是该做任务细化？进行估算？
敏捷圣贤：不完全对，任务细化之外，还有一个非常重要的部分：对于每个细化后的任务，都需要一个非常明确“完成”（Done）的定义。这一点非常重要，必须保证每一个人的理解是正确的、一致的。
阿捷：嗯，否则每个人的估算就会千差万别。
敏捷圣贤：对！估算时，可以用“计划扑克牌”来估算完成时间。你知道怎么用计划扑克牌吗？
阿捷：不知道，我想我可以去查一下。
敏捷圣贤：嗯，你们应该尝试一下这个东西。
阿捷：还有什么值得注意的？
敏捷圣贤：做Sprint任务细化时，一个最佳实践就是把每个任务控制在2～16 小时之间。任务太细，会涉及更多的微观管理，太粗，估算就会不准确。
阿捷：OK！在这一点上，Scrum跟其他项目规划方法是一样的。
敏捷圣贤：下一步，就是让大家自己认领任务，而不是指派！这一点非常关键，一定要记住啊？
阿捷：为什么要认领？指派会更有效率，而且还能根据每个人的特长，让每个人做他擅长的事情。
敏捷圣贤：首先，每个人认领任务后，实际上就是对整个团队有了一个承诺，更能保证按计划完成。其次，让每个人选择自己愿意做的事情，这样才会更有主动性，毕竟“做自己有兴趣的事情，才会真的做好”。这样，不仅满足了个人发展的需要，还可以达到快速的知识共享、团队技能的整体提高。
Jeff Xiong
2009/11/1 Xu Yi <kave...@gmail.com>:
> 最近在看一本挺搞的书，不晓得很多人的做法是否来自这里。。。
>
> 新浪文化读书 > 商场小说 > 敏捷无敌 > 第5章 成长的烦恼（5）
> - http://vip.book.sina.com.cn/book/chapter_98731_65356.html
>
--
Jeff Xiong
Software Journeyman - http://gigix.agilechina.net
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
Xu Yi
我认为所谓专业人士，其一大特征就是能分辨小说与专业著作的区别。比如建筑师下班时看看小说没啥问题，不过要是他从高第密码里面学建筑技术，不知道有几位敢买他设计的房子？
--
Jeff Xiong
答案是，这是个伪问题
会被小说影响的“专业人士”他就不是专业人士
2009/11/1 Xu Yi <kave...@gmail.com>:
--
Xu Yi
这个问题的实质是“一本小说能对其主题所指的专业产生什么样的影响”
答案是，这是个伪问题
会被小说影响的“专业人士”他就不是专业人士
一点都没错啊，问题是这个世界有太多人这样做了。看看那些拿着爱情小说去寻找自己理想爱情的痴情女子。
Steven Mak
我相信重要的還是獨立思考的能力去分辦是非。
On Nov 1, 5:09 pm, Jeff Xiong <gigix1...@gmail.com> wrote:
> 这个问题的实质是"一本小说能对其主题所指的专业产生什么样的影响"
>
> 答案是，这是个伪问题
>
> 会被小说影响的"专业人士"他就不是专业人士
>
> 2009/11/1 Xu Yi <kaverj...@gmail.com>:
>
>
>
> > 2009/11/1 Jeff Xiong <gigix1...@gmail.com>
Xiaoming Wang
Many thanks!
Best Regards
Xiaoming Wang
http://Aaladdin.com -- Agile organization transition framework
http://blog.aaladdin.com -- Professional project management
Mobile：+86 13910608900
LinkedIn Profile: http://www.linkedin.com/in/wangxiaoming
克强
可否做做介绍？
Steven Mak
說，就是由提出 ToC 的Eliyahu M. Goldratt 所寫，ToC 圈子中就當它是聖經一樣。
http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884270610
http://en.wikipedia.org/wiki/The_Goal_%28novel%29