用数字沟通？（was: CMMI下的Scrum, 如何操作？）

[Jeff Xiong]

http://www.infoq.com/cn/articles/rising-agile-spirit-numbers

今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我不相信。如果不能的话Rick不是仍然要加班吗？

===== 引用 =====

"当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"

"这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是…"

"但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。

===== 引用完 =====

一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"

2008/7/28 Jacky Li <very...@gmail.com>:
> InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>

--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/

[Anchuan Qian]

要求精确的数字，确实很扯淡。

但是，明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆的做所谓都决策。当然，也明显是把责任推卸给了开发人员。

项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。

2008/8/15 Jeff Xiong <gigi...@gmail.com>

[起步停车]

还没来得及看 Jeff Xiong给的链接， 先说几句我们的实际情况：

在我们实际的项目开发过程中， 可以说我们积攒了无数个项目的信息（包括计划，任务，时间估算，规模估算，各类文档， 以及他们说需要的估算时间和实际
时间， 还有代码行数....., 可以说要啥有啥）。

可是， 我们在不断的重复着"昨天的故事"，用历史积累的数据来考量现在的项目......， 美其名曰： 用数据说话.....

开发人员极度痛苦ing......， 对这些数据很不屑.....

"如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。"， 相当的认同钱安川的这句话。

好了， 回去看这个链接的文章, 在发言。

On 8月15日, 上午10时44分, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> 要求精确的数字，确实很扯淡。
>
> 但是，明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆的做所谓都决策。当然，也明显是把责任推卸给了开发人员。
>
> 项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。
>

> 2008/8/15 Jeff Xiong <gigix1...@gmail.com>
>
>
>
> >http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>
> > 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我-不相信。如果不能的话Rick不是仍然要加班吗？

>
> > ===== 引用 =====
>
> > "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>

> > "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."

>
> > "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> > ===== 引用完 =====
>

> > 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地-说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"
>
> > 2008/7/28 Jacky Li <veryfa...@gmail.com>:

> > > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > --
> > Jeff Xiong
> > Software Journeyman -http://gigix.thoughtworkers.org
> > Open Source Contributor -http://fluorida.googlecode.com/

> > Technical Evangelist -http://www.infoq.com/cn/- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[鼠标]

文章也没看。

只为最后期限说两句，这个东西太搞了，我越来越搞不清楚这个最后期限的作用是什么了。当你人员一定、机器设备一定、开发方式一定、构件一定、需求一定（当然这个是幻想，不过先假设他一定）的情况下，一个软件最后做完的大概时间也就定下来了。如果真的做到了可度量，唯一能做的就是算，时间大概要占多少，能不能接受，不能接受，那就更改配置，人员啦、机器设备啦、开发方式啦等等，更改完了还是得算。先不说算不算的准，我觉得这是一个正常的思路。可是碰到的好多事情是最后期限完全是一厢情愿定下来的。假设你能估到是3个月，很好，那就给你一个月。定下来了，到时候没完成，也不会怎么样，公司等这帮人磨合成今天这样不容易，还真能做不成就开咯？那这群人白白忍受的这段时间的压力，以及挫折感和失败感又会对下一次工作能造成多少正面影响吗？

我越来越觉得有些问题根本就是伪问题。敏捷方法与最后期限貌似没有任何直接关系，一个把质量和用户价值看得很重的方法，是只能缩短未来的进度，而眼前的进度，那还得看人员素质。过程能帮的忙，还是有限。甚至有时候，看起来还是在拖后腿。

2008/8/15 起步停车 <tol...@163.com>

[起步停车]

我的理解：文章的意思是， 即使不能满足最后的期限，也需要Rick用数字来说出他的理由。所以，文章强调了开发人员用业务人员的语言（尽量用数字）进
行沟通， 即使你在最后的期限不能完成任务， 也要用数字语言告诉他，我在你强调的时间内不能完成，理由是"1，.....2，.......
3......"

总结了文章的几点：
1，业务人员或者管理者喜欢明确的方式，因为它往往基于数字，而不是个人的情感。数字是无可争辩的， 不带有个人情感。
这样就使得他们对问题影响的理解会更加清晰和简单。
2，团队成员的态度和行为，非常个人化，这容易导致误解。
3，开发人员要学会用业务人员的语言来同他们交流， 用数据来说话，而且这样很容易地获得证明，支持和被理解。
4，建议开发人员尝试有效利用数字，不仅仅用它来进行计算而且是作为一种语言，这将能提高你的工程能力。比如估算，用数字说话， 有利于我们不断的改进
估算。

我也发现了这个问题， 领导一般都要数据， 或者他喜欢问："你怎么证明？。。。。"，"证据呢？ 你确定？。。。"，"先试验一下， 给我个报告，看
看生产率提高了多少？......."

On 8月15日, 上午8时25分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>

> 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我-不相信。如果不能的话Rick不是仍然要加班吗？

>
> ===== 引用 =====
>
> "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>

> "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."

>
> "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> ===== 引用完 =====
>

> 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地-说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"
>
> 2008/7/28 Jacky Li <veryfa...@gmail.com>:

>
> > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> --
> Jeff Xiong

[Liang Qiao]

我不认为领导会以"数据说话"来草草做出决定。

因为，本来"管理或决策"这个东西就不是可量化的，如果可量化的话，这个世界就可以量化了。

主要的问题：可能是沟通问题。

1、做为项目开发团队的成员，团队至少要有一个人可能用业务语言和其他项目干系人沟通。
2、频繁沟通。让项目干系人知道项目的真正进展（他们所关心的方面），你不能到无法完成目标的最后时刻才告诉他。
3、高质量的沟通。沟通不是啰嗦一大堆，却没有目标，只是让他们知道项目的情况，而是有目标的沟通，并得到有益的反馈。

2008/8/15 起步停车 <tol...@163.com>

[徐毅]

文中似乎业务人员和客户是站在和开发团队对立的一面，或至少并不在同一个团队，好像这不太合适吧。如果他们能组成一个multi-functional的团队，集合业务人员和开发人员，然后带着客户一块合作，应该能改善这样的处境吧。


--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Practioner
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[Jeff Xiong]

这叫站着说话不腰疼……你是家深圳公司，你客户是辽宁电信和德意志电信，你带着客户一块合作？

2008/8/15 徐毅 <kave...@gmail.com>:

--
Jeff Xiong

[徐毅]

2008/8/15 Jeff Xiong <gigi...@gmail.com>

这叫站着说话不腰疼……你是家深圳公司，你客户是辽宁电信和德意志电信，你带着客户一块合作？

我是说如果。远程的状况下，也总能找到解决方案的，远程会议，网真系统，都可以有帮助。我只记得敏捷宣言的一条customer collaboration over contract negotiation，此处很明显双方的沟通是基于合同的，业务人员过来说，客户需要xxx，什么时间前要做完。如果能够提高客户参与度，当然会有改进。

[起步停车]

是的，领导们只是拿数据作为决策依据， 肯定不是管理或者决策的全部。 领导们会通过各种数据（内部的或者外部的）， 根据外部的市场环境，客户需求，
和企业实际情况做相关的决策。

但是， 无疑，翔实、准确的数据会对企业的决策产生更好支持。 管理层是很需要这些数据的， 比如好多的报表，数据分析报告， 一些商业智能系
统...., 都是以数据的形式对企业的领导层在做决策时产生直接的影响。

我觉的这个文章的重点是用"用数字沟通"，认为同业务人员高质量的沟通要用数字来说话（即有数据才能算"高质量"）。所以， Rick或来打算找
Fred要一些Whatsis的数据，来和Sam沟通。

On 8月15日, 下午3时19分, "Liang Qiao" <sagittatius.q...@gmail.com> wrote:
> 我不认为领导会以"数据说话"来草草做出决定。
>
> 因为，本来"管理或决策"这个东西就不是可量化的，如果可量化的话，这个世界就可以量化了。
>
> 主要的问题：可能是沟通问题。
>
> 1、做为项目开发团队的成员，团队至少要有一个人可能用业务语言和其他项目干系人沟通。
> 2、频繁沟通。让项目干系人知道项目的真正进展（他们所关心的方面），你不能到无法完成目标的最后时刻才告诉他。
> 3、高质量的沟通。沟通不是啰嗦一大堆，却没有目标，只是让他们知道项目的情况，而是有目标的沟通，并得到有益的反馈。
>
> 2008/8/15 起步停车 <tol...@163.com>
>
>
>
> > 我的理解：文章的意思是， 即使不能满足最后的期限，也需要Rick用数字来说出他的理由。所以，文章强调了开发人员用业务人员的语言（尽量用数字）进
> > 行沟通， 即使你在最后的期限不能完成任务， 也要用数字语言告诉他，我在你强调的时间内不能完成，理由是"1，.....2，.......
> > 3......"
>
> > 总结了文章的几点：
> > 1，业务人员或者管理者喜欢明确的方式，因为它往往基于数字，而不是个人的情感。数字是无可争辩的， 不带有个人情感。
> > 这样就使得他们对问题影响的理解会更加清晰和简单。
> > 2，团队成员的态度和行为，非常个人化，这容易导致误解。
> > 3，开发人员要学会用业务人员的语言来同他们交流， 用数据来说话，而且这样很容易地获得证明，支持和被理解。
> > 4，建议开发人员尝试有效利用数字，不仅仅用它来进行计算而且是作为一种语言，这将能提高你的工程能力。比如估算，用数字说话， 有利于我们不断的改进
> > 估算。
>
> > 我也发现了这个问题， 领导一般都要数据， 或者他喜欢问："你怎么证明？。。。。"，"证据呢？ 你确定？。。。"，"先试验一下， 给我个报告，看
> > 看生产率提高了多少？......."
>
> > On 8月15日, 上午8时25分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> > >http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>

> > 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我--不相信。如果不能的话Rick不是仍然要加班吗？

>
> > > ===== 引用 =====
>
> > > "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>
> > > "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."
>
> > > "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> > > ===== 引用完 =====
>

> > 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地--说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"

>
> > > 2008/7/28 Jacky Li <veryfa...@gmail.com>:
>
> > > > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > > --
> > > Jeff Xiong
> > > Software Journeyman -http://gigix.thoughtworkers.org
> > > Open Source Contributor -http://fluorida.googlecode.com/

[Liang Qiao]

Agree。

但只能说：数据沟通是沟通中的一种而已是，而且只能所有论据中的一个论据而已，不是唯一的一个。

2008/8/15 起步停车 <tol...@163.com>

[Anchuan Qian]

沟通非常重要，但是这个词太广了。而且，Nice的客户并不多，所以更多的时候团队和客户的利益是相互冲突的。

相对准确的项目数据对计划、决策非常重要。特别是老板，每日每夜都是在不停的算帐。

2008/8/15 Liang Qiao <sagittat...@gmail.com>

[泰稳@InfoQ China]

这儿的"数字"是不是可以理解为一种可估算的标准，有"数字"可依不是件坏事情，不论是对业务人员还是开发人员。开发人员可以用数字衡量项目的进展，业
务人员可以通过数字和客户进行沟通，只是正如文中所言，这个"数字"要尽可能一致。不同意Anchuan这儿说的"明显是将责任推卸给了开发人员"，这
只能是说各利益相关方希望能找到一个大家都认可的标准来沟通。

"一味追求数据"肯定是不正确的，但是说是数据让项目不停地偏离真实的轨道有失偏颇，任何一个目标的达成都不能是沿着预定轨迹到达的；我反而认为数据可
以让项目的进展不那么偏离真实的轨道（因为它可以让项目成员更准确地了解项目的进展），运用的好的话，它可以让项目进展围绕真实的轨道震荡，直到完成项
目。

On Aug 15, 10:44 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> 要求精确的数字，确实很扯淡。
>
> 但是，明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆的做所谓都决策。当然，也明显是把责任推卸给了开发人员。
>
> 项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。
>

> 2008/8/15 Jeff Xiong <gigix1...@gmail.com>

>
> >http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>
> > 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我不相信。如果不能的话Rick不是仍然要加班吗？
>
> > ===== 引用 =====
>
> > "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>

> > "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."

>
> > "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> > ===== 引用完 =====
>
> > 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"
>

> > 2008/7/28 Jacky Li <veryfa...@gmail.com>:

> > > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > --
> > Jeff Xiong

[泰稳@InfoQ China]

比较奇怪的一点是"眼前的进度，那还得看人员素质"，仅靠"人员素质"能解决问题吗？"素质"是不是也分高低，也要通过某个东西来进行衡量？比如同一项
任务，你用3小时完成，他用4小时完成。单纯地说这个人态度好，素质高，好像站不住脚。

developerWorks上有篇文章"访谈: Scott Ambler 谈敏捷开发http://www.ibm.com/
developerworks/cn/podcast/dwi/cm-int041007txt.html"提到的几点很有意思：
developerWorks：现在，有些人将迭代等同于无计划，您认为这种看法正确么？
Ambler：不，完全不是这样的。我们所做的是及时的计划。所以我们将进行一小部分的预先计划，这是由于您必须确定您的主要里程碑以及对其他团队的主
要依赖关系。但是，我们只进行及时的计划。我们也是自我组织的团队。开发人员都是十分聪明的人，他们知道如何完成他们的工作，也知道如何组织他们的工
作。他们不需要管理人员制定详细的 Gantt 图表，您知道，开发人员会忽略掉这些事情。他们在被允许的情况下完成正确的工作。

developerWorks：那么关于没有测量的说法，您又是如何看的呢？
Ambler：这种说法并不恰当。平心而论，许多敏捷著作并没有关注小型的共处一地的团队。但是实际情况是，Eclipse 项目就是一个敏捷的项目，
全世界有数百位开发人员工作于一个复杂的系统。并且他们一直以来都能够按期完成他们的阶段目标，您知道，它被认为是计算历史上最成功的项目之一。

这里面的"及时的计划""主要里程碑以及对其他团队的主要依赖关系"，以及"能够按期完成他们的阶段目标"等词语，里面都包含"数字"的含义。

[起步停车]

嗯，同意，我也觉得就是对项目规模的一个估算。 如果开发人员说按照业务人员的最后期限交付不了的话，你需要充足的理由，或者说需要提供充足的论据支持
你的论点（不能按时交付）。 很显然，开发人员直接说"完不成"这样的话，肯定是没有说服力的。

所以，项目开始的估算还是必要的，在外包的时候，做为发包方，需要对自己即将招标的项目进行估算，估算成本， 估算规模。有了这个估算（肯定是数字来体
现了），他心里就有底了。接包方也会有个估算，最直接的就是想明白一个事实，基于要投标的项目， 它的规模，我自己的人工成本，能赚钱吗？。这些都需要
数字来体现， 如果只用"差不多"，"应该可以"，"我觉得行"显然不能让人接受。

估算我知道2种，有功能点估算（资料显示， 日韩比较流行），代码行估算( 很不靠谱，虽然一直在用这个， 但这个简单)。

对于敏捷公司/团队， 如何做整个项目的估算？ 比如如何参与这种外包竞争？

On 8月16日, 上午7时26分, 泰稳@InfoQ China <taiwen....@gmail.com> wrote:
> 这儿的"数字"是不是可以理解为一种可估算的标准，有"数字"可依不是件坏事情，不论是对业务人员还是开发人员。开发人员可以用数字衡量项目的进展，业
> 务人员可以通过数字和客户进行沟通，只是正如文中所言，这个"数字"要尽可能一致。不同意Anchuan这儿说的"明显是将责任推卸给了开发人员"，这
> 只能是说各利益相关方希望能找到一个大家都认可的标准来沟通。
>
> "一味追求数据"肯定是不正确的，但是说是数据让项目不停地偏离真实的轨道有失偏颇，任何一个目标的达成都不能是沿着预定轨迹到达的；我反而认为数据可
> 以让项目的进展不那么偏离真实的轨道（因为它可以让项目成员更准确地了解项目的进展），运用的好的话，它可以让项目进展围绕真实的轨道震荡，直到完成项
> 目。
>
> On Aug 15, 10:44 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
>
>
>
> > 要求精确的数字，确实很扯淡。
>
> > 但是，明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆的做所谓都决策。当然，也明显是把责任推卸给了开发人员。
>
> > 项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。
>
> > 2008/8/15 Jeff Xiong <gigix1...@gmail.com>
>
> > >http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>

> > > 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我-不相信。如果不能的话Rick不是仍然要加班吗？

>
> > > ===== 引用 =====
>
> > > "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>
> > > "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."
>
> > > "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> > > ===== 引用完 =====
>

> > > 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地-说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"

>
> > > 2008/7/28 Jacky Li <veryfa...@gmail.com>:
> > > > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > > --
> > > Jeff Xiong
> > > Software Journeyman -http://gigix.thoughtworkers.org
> > > Open Source Contributor -http://fluorida.googlecode.com/

[Anchuan Qian]

数字"要尽可能一致。不同意Anchuan这儿说的"明显是将责任推卸给了开发人员"

我的这句话是对应文章中的： "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。

 要数据可以，先要弄明白是什么数据？是代码行吗？是人月吗？这些估算单位，很不够准确。

那又怎么估算？把需求分解成一张张的Story，然后一张张按照理想天评估？问题还是单位，理想天怎么说？一对Pair在没有任何干扰的情况下工作8个小时。那又拿哪一对Pair作为标准呢？一个团队每个人技术和对项目的了解情况都不一样，工作激情更不一样？那也许有人说要取平均水平的Pair 作为估算。

就算理想天的单位问题解决了，最重要的部分，每张Story大小又如何评估呢？由团队中的一个技术leader评估？还是民主的方式让整个团队技术人员一起评估？先得掂量一下自己的Team。然后评估吧，评估有一个非常重要都前提，就是在Story要写的合适。

只有在上面的假设条件都成立了，那么我们就开始评估吧。我们Team使用：1、2、4、8、16的数字，技术人员一起评估，喊123，然后每个人给出数字，如果有不一致，就互相说服对方，如果无法说服对方，就取平均值。当然，我现在是做产品，没有太多进度的压力（PM扛着呢），所以大家不会有太大的偏见，相对比较客观。在我们眼力，这些数据只是项目经理用来管理，评估和计划时使用的。就是这样，我个人感觉估算的准确度差不多是80%左右。

明显，这个80%的前提大家对技术和业务都熟悉，并且有丰富的开发经验，而且评估的时候不带个人情绪。

而且，我这里的评估只是在迭代或发布计划的时候做的。只是2周-4个月左右的计划。如果再远，误差就会更大。

所谓的评估模型，一般是招标报价和财务预算的时候使用，适合专业的评估部门采用，也只能算是一个工具。我见过一帮人评估了好几天，把100百万不到的项目评估成了1000万。

2008/8/16 泰稳@InfoQ China <taiwe...@gmail.com>

[起步停车]

hehe......

Qian， 我这些天也一直在琢磨估算这件事情。 确实是比较难啊。

但是就像你举例的， 在敏捷里面也一直在估算， 在度量。80%的准确率还是建立在对开发技术，业务需求，团队个人有着丰富的开发经验的基础上建立的。
我们在开发中这个问题也很突出，原来用代码行估算， 给我估算1000行代码的量， 结果， 常常在3000左右才能完成， 也就是这个代码行估算非常
不靠谱（也许我们的估算技术有问题）。

注意到了你最后提到的项目估算的案例， 这有几种情况，1，在项目大体估算准确下（假设70--80%）， 项目确实是大概需要1000万， 而原来的
预算100万是不准确的，我们可以否定它。1000万是科学的。2， 项目确实100万，最好被人为的估算出1000万， 这里面可能还有牵扯的其他问
题， 国企的项目很容易出这问题，：-）。

从客户方的角度来说， 他非常需要这种专业的评估， 用以保护他的利益， 因为他需要知道项目的大概估算， 完成日期等......， 这个和开发模式
无关。

现在很想知道敏捷公司如何应对这种情况的估算： 假设我是国内的一家前10名的大型钢铁公司， 我想提升我的企业信息化水平，包括财务，生产（烧结，炼
铁， 炼钢，线材生产，特种钢材）， 库存， 客户管理， 国际贸易....全套的ERP系统，项目投资领导说3年内能拿出5000万，作为敏捷公司，
怎么参与这种项目的竞争？之所以这么问，就是想知道敏捷里面的"客户合作重于合同谈判"如何在这种投资较高， 风险较大， 项目规模也比较大的情况
下， 如何稳定住客户， 让他们相信敏捷？

On 8月17日, 下午9时22分, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> > 数字"要尽可能一致。不同意Anchuan这儿说的"明显是将责任推卸给了开发人员"
>

> 我的这句话是对应文章中的：*"但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。-"Sam转身走开了。
> *

>
> 要数据可以，先要弄明白是什么数据？是代码行吗？是人月吗？这些估算单位，很不够准确。
>

> 那又怎么估算？把需求分解成一张张的Story，然后一张张按照理想天评估？问题还是单位，理想天怎么说？一对Pair在没有任何干扰的情况下工作8个小时。那-又拿哪一对Pair作为标准呢？一个团队每个人技术和对项目的了解情况都不一样，工作激情更不一样？那也许有人说要取平均水平的Pair
> 作为估算。
>
> 就算理想天的单位问题解决了，最重要的部分，每张Story大小又如何评估呢？由团队中的一个技术leader评估？还是民主的方式让整个团队技术人员一起评估-？先得掂量一下自己的Team。然后评估吧，评估有一个非常重要都前提，就是在Story要写的合适。
>
> 只有在上面的假设条件都成立了，那么我们就开始评估吧。我们Team使用：1、2、4、8、16的数字，技术人员一起评估，喊123，然后每个人给出数字，如果-有不一致，就互相说服对方，如果无法说服对方，就取平均值。当然，我现在是做产品，没有太多进度的压力（PM扛着呢），所以大家不会有太大的偏见，相对比较客观-。在我们眼力，这些数据只是项目经理用来管理，评估和计划时使用的。就是这样，我个人感觉估算的准确度差不多是80%左右。

>
> 明显，这个80%的前提大家对技术和业务都熟悉，并且有丰富的开发经验，而且评估的时候不带个人情绪。
>
> 而且，我这里的评估只是在迭代或发布计划的时候做的。只是2周-4个月左右的计划。如果再远，误差就会更大。
>

> 所谓的评估模型，一般是招标报价和财务预算的时候使用，适合专业的评估部门采用，也只能算是一个工具。我见过一帮人评估了好几天，把100百万不到的项目评估成-了1000万。
>
> 2008/8/16 泰稳@InfoQ China <taiwen....@gmail.com>

>
>
>
> > 这儿的"数字"是不是可以理解为一种可估算的标准，有"数字"可依不是件坏事情，不论是对业务人员还是开发人员。开发人员可以用数字衡量项目的进展，业
> > 务人员可以通过数字和客户进行沟通，只是正如文中所言，这个"数字"要尽可能一致。不同意Anchuan这儿说的"明显是将责任推卸给了开发人员"，这
> > 只能是说各利益相关方希望能找到一个大家都认可的标准来沟通。
>
> > "一味追求数据"肯定是不正确的，但是说是数据让项目不停地偏离真实的轨道有失偏颇，任何一个目标的达成都不能是沿着预定轨迹到达的；我反而认为数据可
> > 以让项目的进展不那么偏离真实的轨道（因为它可以让项目成员更准确地了解项目的进展），运用的好的话，它可以让项目进展围绕真实的轨道震荡，直到完成项
> > 目。
>
> > On Aug 15, 10:44 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> > > 要求精确的数字，确实很扯淡。
>
> > > 但是，明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆的做所谓都决策。当然，也明显是把责任推卸给了开发人员。
>
> > > 项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。
>
> > > 2008/8/15 Jeff Xiong <gigix1...@gmail.com>
>
> > > >http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>

> > 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我-不相信。如果不能的话Rick不是仍然要加班吗？

>
> > > > ===== 引用 =====
>
> > > > "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>
> > > > "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."
>
> > > > "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> > > > ===== 引用完 =====
>

> > 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地-说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"

>
> > > > 2008/7/28 Jacky Li <veryfa...@gmail.com>:
> > > > > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > > > --
> > > > Jeff Xiong
> > > > Software Journeyman -http://gigix.thoughtworkers.org
> > > > Open Source Contributor -http://fluorida.googlecode.com/

[Jeff Xiong]

这个的关键在于，做服务，不做工程。

2008/8/18 起步停车 <tol...@163.com>:

> 现在很想知道敏捷公司如何应对这种情况的估算： 假设我是国内的一家前10名的大型钢铁公司， 我想提升我的企业信息化水平，包括财务，生产（烧结，炼
> 铁， 炼钢，线材生产，特种钢材）， 库存， 客户管理， 国际贸易....全套的ERP系统，项目投资领导说3年内能拿出5000万，作为敏捷公司，
> 怎么参与这种项目的竞争？之所以这么问，就是想知道敏捷里面的"客户合作重于合同谈判"如何在这种投资较高， 风险较大， 项目规模也比较大的情况
> 下， 如何稳定住客户， 让他们相信敏捷？

--
Jeff Xiong

[Gmark]

说的太对了.
像我们这种啥活都得接的公司可以洗洗睡了.

[起步停车]

比较深奥啊， Jeff， 通俗一点呗？！能不能后面在加上些譬如， such as， 或者for example，之类的例子？ ：-）

On 8月18日, 上午11时51分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 这个的关键在于，做服务，不做工程。
>
> 2008/8/18 起步停车 <tol...@163.com>:
>
> > 现在很想知道敏捷公司如何应对这种情况的估算： 假设我是国内的一家前10名的大型钢铁公司， 我想提升我的企业信息化水平，包括财务，生产（烧结，炼
> > 铁， 炼钢，线材生产，特种钢材）， 库存， 客户管理， 国际贸易....全套的ERP系统，项目投资领导说3年内能拿出5000万，作为敏捷公司，
> > 怎么参与这种项目的竞争？之所以这么问，就是想知道敏捷里面的"客户合作重于合同谈判"如何在这种投资较高， 风险较大， 项目规模也比较大的情况
> > 下， 如何稳定住客户， 让他们相信敏捷？
>
> --
> Jeff Xiong

[Anchuan Qian]

而且，敏捷最成熟的是解决软件开发的问题，如何提高质量，优先交付更有价值的功能，等等

关于项目评估、预算，特别是招标报价这一块，在敏捷中没有可行的解决办法。

我最后提到的例子，最想说明的是，评估模型是一个工具，如果没有大量的项目数据和经验，评估模型是无法发挥作用的。所以，才会把100万不到的项目评估成了1000多万。这还不如找个有经验的人来拍拍脑袋。

2008/8/18 Jeff Xiong <gigi...@gmail.com>

[鼠标]

看了一下这文章，觉得其实用数据沟通更清晰，本应该是一个常识。这没什么好说的。
只不过问题最后就回到量化上来了。
有些东西比较好量化，比如一个实践产生的作用。一些东西就比较难量化，比如我们就一直苦恼我们的计划会议，似乎做计划纸牌游戏没有一次准过。而且反思的时候也不知道如何去反思。作了好几个迭代了，评估的价值似乎都没有展现出来。

@泰稳
其实我说的人员素质不是指个体，而是指团队整体。我觉得当过程上暂时能做的改进都已经做了的情况下，那么这个迭代中的生产率就应该取决于团队成员技术水平素质了。当然这个的量化就更难。

2008/8/18 Anchuan Qian <qiana...@gmail.com>

[起步停车]

现在我越发糊涂了，这里有个衔接的问题， 也就是我可以继续用传统的办法参与项目招投标的竞争，做各种估算......， 然后应用敏捷开发方法？ 又
如何跟客户解释或者贯彻“客户合作......> 谈判....”这个理念？ 当然，我对敏捷的理解有限，任何方法都要其适应的边界和局限性，难道敏捷
不适合这些工程性的项目？ Jeff提到， 只做服务， 不做工程...， 那么应用敏捷方法的公司或者项目团队他们在企业信息化工程（先假设是这个项
目）中应该扮演什么角色？ 服务，又从那里切入呢？ 难道是当项目团队陷入泥淖，敏捷团队才出来，说，我们最适合解决陷入复杂恶劣开发困境的难题，我来
处理这个.....？

[Jeff Xiong]

一个很简单的道理：只做最有价值的事情，你才能赚到更多的钱。然而这世界上又有很多不那么有价值的事情，如果这些事情不做好的话那么有价值的事情做了也没有意义。

所以，答案就显而易见了。

2008/8/18 起步停车 <tol...@163.com>:

> 现在我越发糊涂了，这里有个衔接的问题， 也就是我可以继续用传统的办法参与项目招投标的竞争，做各种估算......， 然后应用敏捷开发方法？ 又
> 如何跟客户解释或者贯彻"客户合作......> 谈判...."这个理念？ 当然，我对敏捷的理解有限，任何方法都要其适应的边界和局限性，难道敏捷
> 不适合这些工程性的项目？ Jeff提到， 只做服务， 不做工程...， 那么应用敏捷方法的公司或者项目团队他们在企业信息化工程（先假设是这个项
> 目）中应该扮演什么角色？ 服务，又从那里切入呢？ 难道是当项目团队陷入泥淖，敏捷团队才出来，说，我们最适合解决陷入复杂恶劣开发困境的难题，我来
> 处理这个.....？
>
>

--
Jeff Xiong

[起步停车]

汗ing......俺太笨了。

更不懂了.....


On 8月18日, 下午5时35分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 一个很简单的道理：只做最有价值的事情，你才能赚到更多的钱。然而这世界上又有很多不那么有价值的事情，如果这些事情不做好的话那么有价值的事情做了也没有意义-。

>
> 所以，答案就显而易见了。
>
> 2008/8/18 起步停车 <tol...@163.com>:
>
> > 现在我越发糊涂了，这里有个衔接的问题， 也就是我可以继续用传统的办法参与项目招投标的竞争，做各种估算......， 然后应用敏捷开发方法？ 又
> > 如何跟客户解释或者贯彻"客户合作......> 谈判...."这个理念？ 当然，我对敏捷的理解有限，任何方法都要其适应的边界和局限性，难道敏捷
> > 不适合这些工程性的项目？ Jeff提到， 只做服务， 不做工程...， 那么应用敏捷方法的公司或者项目团队他们在企业信息化工程（先假设是这个项
> > 目）中应该扮演什么角色？ 服务，又从那里切入呢？ 难道是当项目团队陷入泥淖，敏捷团队才出来，说，我们最适合解决陷入复杂恶劣开发困境的难题，我来
> > 处理这个.....？
>
> --
> Jeff Xiong

[Liang Qiao]

>>难道是当项目团队陷入泥淖，敏捷团队才出来，说，我们最适合解决陷入复杂恶劣开发困境的难题，我来处理这个.....？

没人说敏捷是专门解决陷入复杂恶劣开发困境的难题的，但敏捷可能是预防这个难题出现的。


以下纯粹是个人想法：（无论如何，公司总有个平均生产力，要不老总们怎么在年终计划他们下一年KPI呀，或类似的事情）

不要把招投标的事情与合同签署后的事情一起讨论。
因为：这个和敏捷不敏捷没有太多关系，无论是否敏捷开发，对自己公司的生产力总是有个评估的（如果这个也做不到，无话可说了.....老板自己定吧），别把宝抵在这次使用敏捷方法上）

我以前做过的事情是：

对于一般性招投标（正规，非内定）的估算：

由做工程的人（几个，至少一个）参与招投标全过程，（当然也不是随便拉一个人就去参与投标），根据他（们）的经验（对比曾经做的类似的项目）大体估算一 下，再根据市场小组人员对客户的"掌握"情况，综合出三个数或区间，最理想的合理估算，最坏的合理估算，以及正常的合理成本。此时，工程人员的事情就做完 了。

至于公司是否决定拿这个项目，那就不是工程人员的事情啦，公司还要思考：对手的情况与报价、本公司的资源是否充足、本公司中该工程与其它工程的优先级是什么、公司内的人员是否都闲着（还是要养活这么多人嘀）等等。

ＰＳ：这个估算当然根据项目有不同的数量级单位。

对与合同签署后的估算：

那就没什么好说的啦，有Ｎ多种方法（想用哪个用哪个，想试哪个试哪个）。

估算就是估算，准了就不叫估算了，那叫预算（其它行业有相应的预算标准哦，很厚很厚的手册。而且当你了解其它行业的预算时，你会发现个人经验还是非常重要的哦）。

至于人为放大或减少估算问题：

我想：很多公司用这个估算来考核团队或个人。

如果是这种情况的话，就没谱啦。。。。
假如我估5000行，而我做了100行。那么团队或个体这次会得到什么？下次估算又会得到什么？
假如我估500行，而我做了10000行。那么团队或个体这次估算会得到什么？下次估算会得到什么？

有些问题不是某个开发方法解决的，不要治标不治本。

我可能离题太远啦，打住。

2008/8/18 起步停车 <tol...@163.com>

[Wenyan Yin]

我是这样理解的：最有价值的事情=敏捷开发、项目中实际价值最大的部分等；不那么有价值的事情=项目招标、做各种估算等

2008/8/18 起步停车 <tol...@163.com>

[rocket]

有一本叫做敏捷估计与规划的书，里面有一些如果针对于敏捷方法进行数字量化的估计方法。通过这些方法，开发能够给出的一个项目情况就是一个实实在在的数
字了（也许这个数字不够精确，但是已经可以支持决策了）。

On Aug 15, 8:25 am, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> http://www.infoq.com/cn/articles/rising-agile-spirit-numbers
>
> 今天看到这个文章了，说实话，不太喜欢。好吧，用数字沟通是一种好的做法。可是这个扯淡的故事它到底想表达什么呢？敏捷能帮助Rick满足Sam的最后期限？我-不相信。如果不能的话Rick不是仍然要加班吗？
>
> ===== 引用 =====
>
> "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
>
> "这不是钱的问题，Sam，"Rick争辩道，"我只是不确定要多久才能完成，但是..."
>
> "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
>
> ===== 引用完 =====
>
> 一个对集体任务所有制和每周40小时一点概念都没有的程序员，你能说他在敏捷的环境中工作吗（哪怕只是自称"新手"）？我仿佛看到几个月后Rick会满心懊恼地-说："自从搞了敏捷以后我工作更辛苦了，我压根就没感觉到什么编程的乐趣，这都是敏捷害的。"
>
> 2008/7/28 Jacky Li <veryfa...@gmail.com>:
>
> > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>

[Rockbird]

任何数据都是可以被玩弄和被误读的。

[James.Tong(鼠标)]

任何文字也是

2008/8/20 Rockbird <rockbird.li@gmail.com>

任何数据都是可以被玩弄和被误读的。

--
best regards,
James

[Rockbird]

大老板是绝对的数字崇拜的典范，经过几年的磨合，已经可以将数据语言支持大多数自己的主张……在此过程中，所花费的overhead并没有能够帮助我们提高项目的管理效率，在项目管理中手工微操作依然是一线manager的主要工作，系统的数据管理并不能帮助一线的manager。

在08-8-20，James.Tong(鼠标) <tj1...@gmail.com> 写道：

--
Thanks,

rockbird

[Jeff Xiong]

总是怀着玫瑰色美丽梦想的硕士又批评我们这些不识时务的草莽了。

http://www.infoq.com/cn/news/2008/08/numbers-communication

我以前知道一个estimation的技巧：如果你很有把握地一件事情能在时间T内完成，那么把T×4当作你汇报给manager的estimation。

用数字沟通，huh？

硕士们的玫瑰色梦想，总是被我们这些自私软弱缺乏安全感的民工搞得一团糟。我们真应该对这个世界不那么美好感到愧疚。

--
Jeff Xiong

[david]

infoQ上有篇文章是关于数字沟通的，里面说的很好；
要用对方的语言和对方沟通；

同样，用对方理解的数字和多方沟通！！

[Liang Qiao]

佩服他的"断章取义，并能加以详细分析。"

2008/8/21 Jeff Xiong <gigi...@gmail.com>

[pengfei wang]

不知道诸位冷嘲热讽的理由何在? 这样就显得很敏捷?

张旬对量化管理/沟通的分析没什么不妥。
--------------------------

管理或决策当然是可以量化的！而且，定性和定量分析结合的管理决策才更科学、更先进、更成熟。打个比方，如果您会打桥牌，就会知道每一手牌，每一次决策，都可以量化，算算外面还有几张牌，您赢得这一墩的成功概率是多少 ...

我不知道乔梁所说的"管理或者决策不是可量化的"，依据何在。

本次讨论的主题是：数字是有效沟通的要素之一但不是全部。这当然是正确的。

也就是说，问题的实质根本不是要不要沟通（所有人都知道沟通的重要性），而是如何沟通，怎么沟通，拿什么去沟通。所以，后面乔梁说了一大堆，"频繁的沟通，高质量的沟通，有目标的沟通"，我看是偏题了，没讲到点子上。

如何沟通？有数字和数据支持的沟通，当然是更高质量的沟通。这是受过科学训练的职业软件工程师应该具备的常识。
----------------------------------------------------------------------------------------------------
 

[Jeff Xiong]

是啊是啊，很妥。

"当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"

去量化分析然后拿加班奖金吧。

2008/8/21 pengfei wang <roc...@gmail.com>:

> 不知道诸位冷嘲热讽的理由何在? 这样就显得很敏捷?
> 张旬对量化管理/沟通的分析没什么不妥。
> --------------------------
> 管理或决策当然是可以量化的！而且，定性和定量分析结合的管理决策才更科学、更先进、更成熟。打个比方，如果您会打桥牌，就会知道每一手牌，每一次决策，都可以量化，算算外面还有几张牌，您赢得这一墩的成功概率是多少
> ...
>
> 我不知道乔梁所说的"管理或者决策不是可量化的"，依据何在。
>
> 本次讨论的主题是：数字是有效沟通的要素之一但不是全部。这当然是正确的。
>
> 也就是说，问题的实质根本不是要不要沟通（所有人都知道沟通的重要性），而是如何沟通，怎么沟通，拿什么去沟通。所以，后面乔梁说了一大堆，"频繁的沟通，高质量的沟通，有目标的沟通"，我看是偏题了，没讲到点子上。
>
> 如何沟通？有数字和数据支持的沟通，当然是更高质量的沟通。这是受过科学训练的职业软件工程师应该具备的常识。
> ----------------------------------------------------------------------------------------------------
>

[pengfei wang]

"当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"

-----------

Jeff你引用的那个故事里的这句话，跟量化管理/沟通没有丝毫关系. 这只不过是在说市场/开发之间的矛盾之处而已。

 

再往后看，才提到用数据说话的问题. 如果Rick能用数据告诉Sam,在月底之前无法完成Whatsis模块,那不就更有说服力,对自己有利了吗? 比总说"但是"并强调"管理决策不能量化"有用吧. 

 

 

Best,

王鹏飞

[Jeff Xiong]

噢？是吗？

所谓有意义的估计值，是指（1）偏差范围小；（2）朝正向或负向偏差的概率相当。比如我说"我在2050年前后偏差50年会死"，这不是什么有意义的估计值；我说"我在2008年之后100年内会死"，这也不是什么有意义的估计值。给出越有意义的估计值，提供越多的信息量，就意味着出现偏差的风险越大。

那么在一个事实与估计出现负向偏差（或者正向偏差，取决于你说的对象）则估计者会因此受到惩罚（加班）的环境下，估计者会采用什么样的策略来提供估计值，这种环境会对量化管理/沟通产生怎样的影响。我本来不觉得这是一个很有研究价值的主题。

2008/8/21 pengfei wang <roc...@gmail.com>:

> "当然，Rick，当然"，Sam说"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"
> -----------
> Jeff你引用的那个故事里的这句话，跟量化管理/沟通没有丝毫关系. 这只不过是在说市场/开发之间的矛盾之处而已。
>

--

[杨波]

问题在于量化也是需要成本的。与其花大力气去做稍微能精确点的数据（有多少用还不知道），还不如改变工作方式，去适应模糊的估计。

> 如何沟通？有数字和数据支持的沟通，当然是更高质量的沟通。

这是受过科学训练的职业软件工程师应该具备的常识。
另外，顺便提一下，常识这东西，实际上对每个人都是不同的。

------
   致
礼

杨波

2008/8/21 pengfei wang <roc...@gmail.com>

[Yiding He]

有道理。量化不是用来掩盖风险和推卸责任的。

2008/8/21 Jeff Xiong <gigi...@gmail.com>

--
                      致
礼！
                        yidi...@gmail.com

[Tim.Wu]

因为变化，变化.......

 

桥牌也有一样的道理，如果要求你出每张牌前在规则接受时间范围内给出精确的成功概率，相信你会和Rick回答一样的。

 

连飞船上天都能估算时间，别的问题当然不可能不行。

 

但如果孤立其它问题去一味讨论一个量化和数据好不好和可不可行，本身就是问题，尤其是忽视需求变化的客观存在。

 

有时候事实证明有些事不去做比去做好-----成本收益比。

2008/8/21 pengfei wang <roc...@gmail.com>

[Jeff Xiong]

不要误会。实际上我认为用数字沟通是一种简单有效的方式，比如说与其费半天劲跟老板解释重构有什么好处我不如告诉他重构需要3个人日不重构你将在未来3个月里损失20个人日的生产率。但是，用数字沟通或者说任何形式的沟通必须建立在一个基础上即沟通有可能改变一些事情。这也是为什么我说这是个不搭调的故事：Rick要想不加班该怎么做？我觉得如果他不是特别笨或者特别没经验的话他就不会考虑去做一个比较准确的估计来沟通。

2008/8/21 Tim. Wu <china....@gmail.com>:

> 因为变化，变化.......
>
> 桥牌也有一样的道理，如果要求你出每张牌前在规则接受时间范围内给出精确的成功概率，相信你会和Rick回答一样的。
>
> 连飞船上天都能估算时间，别的问题当然不可能不行。
>
> 但如果孤立其它问题去一味讨论一个量化和数据好不好和可不可行，本身就是问题，尤其是忽视需求变化的客观存在。
>
> 有时候事实证明有些事不去做比去做好-----成本收益比。

[Kevin Huo]

除了量化之外，现在还有哪些衡量项目进展的工具？

看了大家的评论，对敏捷团队如何评估项目进展很感兴趣。是不是大家之间互相信任，都认为彼此在全力赶进度，最后项目一定是在最短的时间内完成的？

另外，如果被服务的一方问“你们要帮助我们解决这个问题，大体需要多长时间？我们如何给你们计费？”的时候，敏捷团队应该如何回答？

 

霍泰稳|Kevin Huo: Chief Editor, InfoQ China

Tel: (+86)10-84725788 

Mobile: (+86)13811662678
E-mail: ke...@infoq.com 

MSN: fire_fut...@hotmail.com
InfoQ China: http://www.infoq.com/cn/
Enterprise Software Development Community for China

---

[pengfei wang]

未必如此.

如果我们知道某人得了癌症并且确症是晚期,结合当地的医疗水平，病人的家庭条件, 那么我们的估计结果就是明确的,比如:预后非常不好，生命存活期大概是12个月...这样，病人的家属就有这个概念和心理准备了。

同样,我们只知道说某人有个肿瘤再没别的信息, 此时的估计值,就没意义。良性的切除了预后非常好, 恶性的还要看是否扩散才能确定手术效果等等......

 

不扯远了，回到软件项目上说。

估计值的偏差程度和风险水平是由估计对象的信息的准确性和估算方法决定的, 与你的所说的"给出越有意义的估计值，提供越多的信息量"并没有内在的因果关系。Anderson在软件工程的敏捷管理书中提供了一组实际项目的参考数据: 信息量足够的项目, 估算偏差为+10%. 信息量极度缺乏的项目,估算偏差在200%甚至更多. 在那个故事中，Rick团队里的Fred对Whatsis是很了解的并且有在多个项目中应用Whatsis的经验. 这就为Rick有可能为Sam提供较为准确的估计数据奠定了基础。

 

另一个是估计方法的问题. 这直接影响到估计结果的精确程度。我本人用FDD多年，我总结过一套"风险-人日"的参考值以及确定风险系数的方法, 我用的效果很好。XP中怎么估算，也应该有相应的方法. 为了让估算值尽量保险, 一般会为估算结果加上一个缓冲值, 也就是所谓的偏差.
 

至于公司环境和商业上的因素, 本身并不影响估算结果的准确性, 但会影响人们如何对待估算结果。

 

On 8/21/08, Jeff Xiong <gigi...@gmail.com> wrote:

[Tim.Wu]

1. 能不能存活期不要用"大概"呢?

 

2. FDD中的复杂度加权因子一样是主观判断的，而主观判断的失误对估计的结果影响小吗？

 

2008/8/21 pengfei wang <roc...@gmail.com>

[pengfei wang]

问题是做什么不需要成本呢

开发过程中，如果能得到较准确的数据, 对项目管理当然是很有用的 
 

"模糊的估计"这个概念...

如果对模糊数学和模糊逻辑有所了解的话，就知道模糊的目的是为了信息更准确,在点的左右各加上了一个带概率的缓冲区间. 模糊的目的是为了准确，而不是为不估算作为推托之辞.

--
Best,

王鹏飞

[pengfei wang]

1. 是估算, 估算就是有误差, 明白么?

 根据您的经验, 哪个医生会跟病人家属说: 这个是肝癌晚期, 8月12号会病逝. 有吗?

2. 你概念错误。复杂度就是复杂度,没有加权. 风险系数才是几个因子的加权结果.每个因子的概率是是从项目经验和历史数据积累中得到的，不是随便拍脑袋的"模糊的估计".

 

[Jeff Xiong]

这个很难说的。如果病人家属能平静对待，告诉他一个更准确的日期有助于他安排后事。

所以你也承认了。听数据的人怎么对待这个数据，会直接影响给数据的人怎么说这个数据。一个倡导用数据沟通的环境，首先必须是一个给出估算数据出现误差时估算者不会因此受到惩罚的环境。

2008/8/21 pengfei wang <roc...@gmail.com>:

> 1. 是估算, 估算就是有误差, 明白么?
> 根据您的经验, 哪个医生会跟病人家属说: 这个是肝癌晚期, 8月12号会病逝. 有吗?

--

[徐毅]

唯手熟尔。卖油翁并没有使用任何紧密的尺具去度量每一次他倒油的距离、高度、偏差如何，无非是通过观察油入瓮的情况如有无偏差、有无泄漏，并不断地调整其方向、高度、水平，再继续观察而已。你要让他说出最完美的倒油动作在什么高度距离几分几毫，他恐怕不见得能说出啥东西。

--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Practioner
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[pengfei wang]

呵呵，对病人生存期这个问题，您可以问问做医生的朋友, 如果真有人这么说，那只是神棍不是医生.

 

第2点你说的没错, 我一直都承认环境和商业因素的影响, 管理模式/文化氛围本身就是组织和制度层面应该解决的问题。我强调的是，在信息充分的条件下，一个可接受的估算值还是能得到的, 不要以成本,模糊等等为托词.

 

 

On 8/21/08, Jeff Xiong <gigi...@gmail.com> wrote:

Best,

王鹏飞

[pengfei wang]

如果他开了个卖油的作坊, 或者甚至扩大生产办了一个厂, 那就该总结方法了吧, 不是每个人都象他那么手熟.

[徐毅]

2008/8/21 pengfei wang <roc...@gmail.com>

如果他开了个卖油的作坊, 或者甚至扩大生产办了一个厂, 那就该总结方法了吧, 不是每个人都象他那么手熟.

当然要总结方法，但方法不见得就一定是用一个精密的仪器来度量。如果要让一切可度量，最好的方法就是用机器来打油，可重复而且可信赖，每一次的操作误差不会超过某个预设的值。

如果你要让这样的一个学徒给出一个估计值，那么它要么来自学徒所操作的机器的特性参数，要么来自于学徒按照自己技术熟练程度给出的一个_不可靠_的参考值。

[杨波]

既然你也说了做任何事都需要成本，那么我认为我去做一个精确的估算值的成本收益比（远）不如我凭直觉（少量时间）做出判断。
"如果能得到较准确的数据"，前提是"能得到"，得到你想要的准确程度，会有多少成本搭进去，麻烦也考虑一下。
我不知道软件开发这种极难抽丝剥茧的东西，你是怎么用模糊数学和模糊逻辑抽象出来的。但不管怎样，面对信息极度不全面的环境，还能够计算出准确的未来，估计只有科幻小说中才能做得到了。
另外，个人性格不好，虽然信息不足时我也会给出估算值，但如果会因此弄得我加班甚至还视之为工作不努力的话，我会以无法估算作为"推脱之辞"的。

[起步停车]

俺和你被引用了！ 呵呵， 这说明沟通不充分....

你说的“项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。 ” 到现在我还是
非常赞同的。

现在我们也在不断改进估算手段， 丢弃了原来的代码行数估算方法， 打算引入功能点估算法， 为以后的外包业务做准备。不管怎样， 这些数据都要搞
的， 但也只能作为一个参考值，不能完全相信他， 这个之上还有自己的判断和经验。

On 8月21日, 上午10时00分, "Liang Qiao" <sagittatius.q...@gmail.com> wrote:
> 佩服他的"断章取义，并能加以详细分析。"
>

> 2008/8/21 Jeff Xiong <gigix1...@gmail.com>

> > Technical Evangelist -http://www.infoq.com/cn/- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[pengfei wang]

On 8/21/08, 杨波 <yab...@gmail.com> wrote:

既然你也说了做任何事都需要成本，那么我认为我去做一个精确的估算值的成本收益比（远）不如我凭直觉（少量时间）做出判断。

   估算不是无原则的精确. 不确定性越多, 误差就越大，缓冲资源就该设置的越大. 我搞不懂为啥一提到这个就用成本来做挡箭牌.

 

"如果能得到较准确的数据"，前提是"能得到"，得到你想要的准确程度，会有多少成本搭进去，麻烦也考虑一下。

   需求收集要不要成本? 估算需要的素材不也正是需求的素材吗? 

   比如60个人月的项目, 团队在搜集/分析需求后用一个星期对需求进 行风险识别,得到一个工期的估算值,这成本就高到了不能接受的程度吗?
 

我不知道软件开发这种极难抽丝剥茧的东西，你是怎么用模糊数学和模糊逻辑抽象出来的。但不管怎样，面对信息极度不全面的环境，还能够计算出准确的未来，估计只有科幻小说中才能做得到了。

    我提模糊逻辑的概念是在阐述怎么降低信息不足情况下估算结果的奉贤, 真正需要使用模糊的原因是为了结果更准确，而不是推托或者拍脑袋的"模糊的估计".

另外，个人性格不好，虽然信息不足时我也会给出估算值，但如果会因此弄得我加班甚至还视之为工作不努力的话，我会以无法估算作为"推脱之辞"的。

谁说估算就要加班, 这是什么逻辑呢?

   我说的是"信息量不足情况下所得到的估算值, 就需要更大的缓冲区去吸收不确定性."  

------
   致
礼

杨波


 

--
Best,

王鹏飞

[Liang Qiao]

1、俺不挑战"量化管理"，也没有理由挑战"量化管理"。
2、俺想说的是：俺也用"量化分析"，但只是根据分析结果和经验做决策。
3、俺不知道"受过科学训练的职业软件工程师"的定义是什么，很可能俺不是，不过不是也没有关系，参加奥运会的运动员还有不穿跑鞋的呢。
4、俺也没说过"其它方法不灵"，俺也没说俺比谁敏捷，俺只是想说："用脑去沟通，不是数字本身，只是形式。"
5、俺的逻辑学可能不太好，别挑剔，凑合看吧。

:)

PS: OpenParty 有一些不收费的讨论，可以让大家面对面的沟通，比用这方式沟通好。

2008/8/21 pengfei wang <roc...@gmail.com>

[Liang Qiao]

如果公司用这个估算来考核个人和团队，忘记它吧。

2008/8/21 pengfei wang <roc...@gmail.com>

[杨波]

一条一条的对拆没什么意思了。你说的是数字是有价值的，是很有价值的；我说的是数字是有价值的，但没有大到以数字为准的地步。
既然做项目总要面对变化，那么可能的话，应该减小精确数字对项目的影响。

[pengfei wang]

恩, 我意思是说, 在项目管理中引入量化的手段是有价值的。估算是可以做的, 估算的结果准确程度依赖我们对项目信息的掌握的情况。其实风险识别,估算工作量的作用不仅在于给领导一个数字, 在确定需求优先顺序,开发计划等方面也有作用。

--
Best,

王鹏飞

[徐毅]

2008/8/21 pengfei wang <roc...@gmail.com>

On 8/21/08, 杨波 <yab...@gmail.com> wrote:

既然你也说了做任何事都需要成本，那么我认为我去做一个精确的估算值的成本收益比（远）不如我凭直觉（少量时间）做出判断。

   估算不是无原则的精确. 不确定性越多, 误差就越大，缓冲资源就该设置的越大. 我搞不懂为啥一提到这个就用成本来做挡箭牌.

看到这里，我突然有个疑问，就是：
- 大家需要估算的目的是什么，估算的精度要求有多高？

问这个问题的原因是，我突然想到，估算其实是为了对未来做出预测以预先准备应对方案。但是太过于强调up-front的做出对未来的精确判断，我觉得并不好。更重要的是快速地给出当前最好的估计，并提高在后期对环境变化的响应速度，即根据那些影响估算结果的因素的变化情况及时地调整已经不正确的估算值。

[Tim.Wu]

2008/8/21 pengfei wang <roc...@gmail.com>

On 8/21/08, 杨波 <yab...@gmail.com> wrote:

既然你也说了做任何事都需要成本，那么我认为我去做一个精确的估算值的成本收益比（远）不如我凭直觉（少量时间）做出判断。

   估算不是无原则的精确. 不确定性越多, 误差就越大，缓冲资源就该设置的越大. 我搞不懂为啥一提到这个就用成本来做挡箭牌.

 如果要说挡箭牌，我觉得"需求变化"可能是更好的挡箭牌:)

"如果能得到较准确的数据"，前提是"能得到"，得到你想要的准确程度，会有多少成本搭进去，麻烦也考虑一下。

   需求收集要不要成本? 估算需要的素材不也正是需求的素材吗? 

   比如60个人月的项目, 团队在搜集/分析需求后用一个星期对需求进 行风险识别,得到一个工期的估算值,这成本就高到了不能接受的程度吗?
 这种程度的成本肯定不高，而如果这个估算结果可接受和可用，绝对值得。不过，我知道的某些传统的方法，尤其为了让估计更客观，包括收集历史量化数据等工作，视乎不是这个级别的成本代价。

 

我不知道软件开发这种极难抽丝剥茧的东西，你是怎么用模糊数学和模糊逻辑抽象出来的。但不管怎样，面对信息极度不全面的环境，还能够计算出准确的未来，估计只有科幻小说中才能做得到了。

    我提模糊逻辑的概念是在阐述怎么降低信息不足情况下估算结果的奉贤, 真正需要使用模糊的原因是为了结果更准确，而不是推托或者拍脑袋的"模糊的估计". 

  对于你FDD的指正，先要多谢:) 我提问的关于修正因子的给出过程，虽不是你说的"模糊的估计"，但仍有主观因素。并非完全的历史数据的数学演算过程。对吧？其实我要的结论，也就是你自己所说的"误差"。

 

当然，我也不是说有"误差"就不好，更不反对"更准确比模糊好"，相反我很同意。但为什么有时候我们不对长远未来做那么精确的估算，原因上面提到了。敏捷也不是反对估算啊，我们一样收集和估算能实现多少用户故事。

 

   至于结合多种实践，达成最适合自己的方法，当然更好了。没那么矛盾的。

 

另外，个人性格不好，虽然信息不足时我也会给出估算值，但如果会因此弄得我加班甚至还视之为工作不努力的话，我会以无法估算作为"推脱之辞"的。

谁说估算就要加班, 这是什么逻辑呢?

   我说的是"信息量不足情况下所得到的估算值, 就需要更大的缓冲区去吸收不确定性."  
这个，杨说的好像好似个体情况，还不至于到"估算就要加班"的结论吧。：）

 

 

我又读了读我们讨论的那篇文章，如jeff说的，没有人认为数字沟通不好。:) 

引两句文中市场部门的原句吧

"如果我们能在这个月底前交给他，他愿意支付一笔额外的费用。我知道这对你来说有压力，但你总是能够搞定这种棘手的事情。"

"你们开发人员总是这样，什么时候你们才会说'没问题'？听着，如果你愿意周末加班，应该是有奖金的。"

"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"

------
   致
礼

杨波


 

[Tim.Wu]

呵呵，我和你在两个不同的圈里转着呢。

 

不知你有否空再读读那篇文章，其实这儿沟通的问题真的不是"引入量化的手段对项目管理的作用":)Rick即使做了量化工作，他的敏捷之路的结局还是很令人担忧的。

2008/8/21 pengfei wang <roc...@gmail.com>

[lihxa2005]

 

 我昨天下班后看中国和立陶宛的篮球比赛,我看了一眼比分,就知道已经没戏了,不过如果项目管理,仅仅看一眼数字,就能知道有戏还是没戏,我觉得就太武断了,而且也很少见的.

 

 

--

lihongxi

2008/8/21 pengfei wang <roc...@gmail.com>

---

伊利：有梦想，就有下一次飞翔。期待刘翔王者归来。

[Jacky Li]

唔~~怎么能单靠比分就判断有没有戏？牛x的人可以35秒13分。

2008/8/21 lihxa2005 <lihx...@126.com>

--
Jacky Li

InfoQ China Agile Lead Editor: www.infoq.com/cn
+86 138 1045 9095

[ozzzz...@gmail.com]

桥牌我大学的时候玩过几下，水平一般，马马虎虎了。要说桥牌里面有数字，可以算概率，于是就说是决策是基于数字的，这个是典型的初级入门牌手的说法。本
身桥牌这个事情，如果我们不考虑对家之外的事情，我们完全可以按照概率做决策，可以有条不紊的叫牌，可以有条不紊的出牌。问题在于最简单的情况下，我们
还有对手存在，他们会采取各种对抗手段破坏你们的信息沟通。而同时，叫牌和出牌所代表的意思不可能是单一的，而即使是对于概率的解释也是不同的。而很多
时候，作为一个牌手还要考虑对手的信心和心情以及喜欢的搭配和打牌方式。
而进一步，如果我们考虑队式赛和对式赛，还有很多策略。而同时由于牌手的比赛级别跟自己的协定体系会有很大的不同，造成你很难完全按照一个数字来继续进
行决策。比如当时我们最早使用了弱开叫体系，而我们队的同伴则是弱二盖一系统加弱5阻击叫系统，造成很大人对我们这个组合很难应付。我们这些系统在当时
国外用的人也不是很大，所以资料很少，对手总是需要很多时间研究我们的约定卡，同时比赛中基本上每每都要求提示。而我们由于使用的系统过于让他们陌生，
所以有时候我们会用很多比较模糊的说法做提示，而最终对手也不明白所以然。这种情况下很多时候我们解释错了对手也没有发现。而由于每每都要做解释，所以
我们的牌打得很慢，而为了赶上进度，对方往往会在打牌的时候思考不够——绝大多数情况下是总是希望以大概率取胜，而恰恰桥牌不是个概率游戏。

On 8月21日, 上午10时11分, "pengfei wang" <roc...@gmail.com> wrote:
> 不知道诸位冷嘲热讽的理由何在? 这样就显得很敏捷?
> 张旬对量化管理/沟通的分析没什么不妥。
> --------------------------
> *管理或决策当然是可以量化的！*而且，定性和定量分析结合的管理决策才更科学、更先进、更成熟。打个比方，如果您会打桥牌，就会知道每一手牌，每一次决策，都可以量化，算算外面还有几张牌，您赢得这一墩的成功概率是多少

> ...
>
> 我不知道乔梁所说的"管理或者决策不是可量化的"，依据何在。
>
> 本次讨论的主题是：数字是有效沟通的要素之一但不是全部。这当然是正确的。
>

> 也就是说，*问题的实质根本不是要不要沟通（所有人都知道沟通的重要性），而是如何沟通，怎么沟通，拿什么去沟通*。所以，后面乔梁说了一大堆，"频繁的沟通，高质量的沟通，有目标的沟通"，我看是偏题了，没讲到点子上。

>
> 如何沟通？有数字和数据支持的沟通，当然是更高质量的沟通。这是受过科学训练的职业软件工程师应该具备的常识。
> ----------------------------------------------------------------------------------------------------
>

> On 8/21/08, Liang Qiao <sagittatius.q...@gmail.com> wrote:
>
>
>
> > 佩服他的"断章取义，并能加以详细分析。"
>

> > 2008/8/21 Jeff Xiong <gigix1...@gmail.com>

>
> >> 总是怀着玫瑰色美丽梦想的硕士又批评我们这些不识时务的草莽了。
>
> >>http://www.infoq.com/cn/news/2008/08/numbers-communication
>
> >> 我以前知道一个estimation的技巧：如果你很有把握地一件事情能在时间T内完成，那么把T×4当作你汇报给manager的estimation。
>
> >> 用数字沟通，huh？
>
> >> 硕士们的玫瑰色梦想，总是被我们这些自私软弱缺乏安全感的民工搞得一团糟。我们真应该对这个世界不那么美好感到愧疚。
>

> >> --
> >> Jeff Xiong

[糖醋鼻子]

我觉得这恰恰是“学习所有的理论基础，然后全部忘掉乱来就行了”的忠实印证。
规则和套路都是用来打破的，而打破之前你需要遵循它们。遵循是修炼，而打破是得道，缺一不可。
所以从这个层面看，数字或者量化只是为你提供了一种得道的基础，而并不是一定能解决什么问题，不然程序员这个职业就会被机器代替了。
个人感觉，数字和经验之间的区别应该用沟通，有效的沟通来化解。

On 8月22日, 上午2时00分, "ozzzzzz....@gmail.com" <ozzzzzz....@gmail.com>
wrote:

[Joseph Tseng]

"苦集灭道，无苦集灭道"， :p

"我觉得这恰恰是"学习所有的理论基础，然后全部忘掉乱来就行了"的忠实印证。规则和套路都是用来打破的，而打破之前你需要遵循它们。遵循是修炼，而打破是得道，缺一不可。"

2008/8/22 糖醋鼻子 <zhmo...@gmail.com>

[ozzzz...@gmail.com]

数字的作用在于复习，而不在于预测；数字的作用在于提高你的能力，而不是替代你的能力。
其实作为一个曾经想进军专业的牌手，我们何尝不熟悉充满数字的概率，只不过我们最终都发现这些概率仅仅是一个给你做出决策的依据而已。而更加关键的问题
在于，当你处于一种博弈的状态下，概率这个东西带来的意义会有多种不同的解读——其差异巨大到地球与织女星系那么遥远，而你必须在一个非常短的时间内作
出决策，否则就有可能被对手抓住机会要么去裁判那里告诉你在传递非法信息，要么会从你的迟疑中获取某些你不想透露的信息。而实际上，即使有时间对这多种
状况作出细致的分析，但是当你进一步考虑到比赛前面的状况和今后可能的状况，那么这些数据根本变得不可太看重。而实际上当我们遇到这样的状况的时候（实
际上从第一局开始，就会一直在这种状况下），我们会对局面有一个大概的、比较模糊的认识，然后随着局面的深入，这个认识大概会向精确的方面发展——但是
并不会完全如此，特别是当初有一段时间流行大输赢的策略，这个时候局面会变得更加模糊。实际上概率这个东西，仅仅是告诉我们，你会有几种选择，那些选择
更加保险，那么更加冒险但是收益可能会大。做为一个牌手要做的，就是在这几种不同的可能的情况下，对后面和前面的情况做出评估，并跟现在的情况加以平
衡，再考虑对手的风格，从而挑选出一个方向。
很多初学的牌手以为，在这个情况下，如果使用博弈学的数学计算，可以选择出最佳的对策。但是不要忘记，在短时间内，你不可能做出如此之多的计算；同时最
佳决策带来的后果未必就是你想要的。比如稳妥的处理，几乎会在所有的技术计算中胜出，但是当你感觉比分落后的时候（比如你前面一局判断牌型是4333或
者5332，但是出了6430的时候，你感觉你的另外一对同伴牌手，在其叫牌系统的约束下，对这些分布已经在叫牌中得到传递），这个时候你应该追赶。但
是如何追赶却又是问题，你是选择大输赢，还是选择大输赢跟稳妥相交替。而同时你还要考虑到，你的另外一对同伴牌手，实际上也知道了局面的情况，他们的选
择又会是什么。而最终还要考虑到对手，他们又会如何选择。实际少最终的决策，完全是根据感觉和直觉作出的，因为你的大脑根本负担不起这样的计算量。
那么数据是不是就一点用途都没有了呢？当然不是这样，数据可以给你在比赛结束后复盘的时候，加深你对对手和牌友的印象，从而最终提高你的直觉和感觉的能
力。实际上作为一个牌手，作出的决策都是基于感觉和直觉的，而不是基于数据的。但是当你回过头来看，数据的学习和使用，是你培养这些感觉和直觉的基础。
但是请注意，数据的作用在于复习，而不在于决策。

[糖醋鼻子]

“数字的作用在于复习”

精辟！！！

On 8月23日, 下午3时12分, "ozzzzzz....@gmail.com" <ozzzzzz....@gmail.com>
wrote:

[pipi]

阅读了SCRUM and XP from Trench这本书，下面这段话和讨论有些关系。我觉得挺不错的。

Good Scrum execution is becoming more important for teams
who want investment funding. As an Agile coach for a venture
capital group, I help with their goal of investing only in Agile
companies that execute Agile practices well. The Senior Partner
of the group is asking all portfolio companies if they know the
velocity of their teams. They have difficulty answering the
question right now. Future investment opportunities will require
that development teams understand their velocity of software
production.

Why is this so important? If the teams do not know velocity, the
Product Owner cannot create a product roadmap with credible
release dates. Without dependable release dates, the company
could fail and investors could lose their money!

On Aug 23, 5:27 pm, 糖醋鼻子 <zhmoc...@gmail.com> wrote:
> "数字的作用在于复习"
>
> 精辟！！！
>
> On 8月23日, 下午3时12分, "ozzzzzz....@gmail.com" <ozzzzzz....@gmail.com>
> wrote:
>
> > 数字的作用在于复习，而不在于预测；数字的作用在于提高你的能力，而不是替代你的能力。
> > 其实作为一个曾经想进军专业的牌手，我们何尝不熟悉充满数字的概率，只不过我们最终都发现这些概率仅仅是一个给你做出决策的依据而已。而更加关键的问题

> > 在于，当你处于一种博弈的状态下，概率这个东西带来的意义会有多种不同的解读----其差异巨大到地球与织女星系那么遥远，而你必须在一个非常短的时间内作

> > 出决策，否则就有可能被对手抓住机会要么去裁判那里告诉你在传递非法信息，要么会从你的迟疑中获取某些你不想透露的信息。而实际上，即使有时间对这多种
> > 状况作出细致的分析，但是当你进一步考虑到比赛前面的状况和今后可能的状况，那么这些数据根本变得不可太看重。而实际上当我们遇到这样的状况的时候（实

> > 际上从第一局开始，就会一直在这种状况下），我们会对局面有一个大概的、比较模糊的认识，然后随着局面的深入，这个认识大概会向精确的方面发展----但是

> > > > 我们的牌打得很慢，而为了赶上进度，对方往往会在打牌的时候思考不够----绝大多数情况下是总是希望以大概率取胜，而恰恰桥牌不是个概率游戏。