微软煞费苦心推出Bing。但一看便知不能成功，微软依旧不具备网络时代的思维模式。

 

 首先，微软企图绕过Google庞大的内容基础，在智能上下功夫。从策略上说，Google做的是关键词与内容的相似匹配，是Match Maker; Bing 做的是决策分析， 属于 Decision Maker。Bing 能替我做决定吗？这意味着更多的猜测和过滤。也许在一些常用内容或者热点话题上，它的确能做到。比如说搜酒店信息，但是这些内容门户网站和垂直网站做得更好，搜索引擎只要能帮我找到这些网站即可，它不需要直接去做这方面的内容。搜索引擎的职责是无论多冷僻的话题，在多冷门的站点上，它能替我翻出来，它不应该决定内容或提供内容。微软的模式，更像是在做自己的百科全书。

 

 搜索引擎已经成为网络的起点。网络的开放性要求搜索引擎必须做到公正。百度式的做法在公开竞争的市场上绝对是自寻死路。Bing 既要做搜索，又兼任整合自身门户、社区、即时通讯等网络资源的任务，那么它的公正性就值得怀疑了。Google 先出搜索，再出邮箱，地图等等其他服务，而且几乎不屏蔽竞争对手的内容。而微软在软件上一贯利用连带优势，这点放在网络上，可能反而成为负担。

 

  Bing 这次大打营销战，只是图个热闹。其实以微软的江湖地位做搜索引擎，当然会吸引用户尝试，媒体肯定会主动报道。Google 靠广告发家，但Google本身几乎不做广告。我用Google就是因为朋友推荐。网络时代，好的工具自然传播。不要说Google用户的忠诚度高，如果新搜素引擎真比Google更快内容更丰富，转换门庭的人立刻就有。对于操作系统或者办公软件，用户要考虑通用性和对过去的兼容。所以对他们做广告很有必要，用户一旦先入为主，就不容易掉头了。而改用搜索引擎的成本有多少呢？输入地址栏而已。

 

  Bing 的可取之处，对搜索结果做更好的整理，这应该是搜索引擎的一个发展方向。搜一个普通些的词，Google都能给出10页以上的结果，但是究竟有多少人会看到三页以上？与其花功夫显示那么多内容，不如把比如说前5页的返回结果做更好的分类和整理，对用户来说更有意义。

在一个sprint周期内，通常会用burndown chart 来显示进度。这时候，会把故事再拆分成一个个子任务，分配给每个成员。任务包括设计界面，准备表结构和后台数据等等。熟悉燃尽图的人知道，表中每格代表该任务在当前剩余的工作时间。例如 “准备查询界面”

-- 3 小时。随着开发前进，剩余时间应逐渐减少，在sprint到期前应该为零。

 

任务：（Day 1 剩余需要开发时间）；（Day2 剩余需要开发时间）…

“准备查询界面”: 3;2;1

Scrum Master 的职责之一，就是注意燃尽图中某个正在工作，剩余却不发生变化的任务。要么是成员低估了工作量，或者是遇到了某个难点；要么是他在做和任务无关的工作。

标准敏捷教程要求每个任务要细分到半天内，如果粒度太粗则说明考虑还不周到。我通常对成员做一点让步，如果该任务不在短期内（1到3天）执行，允许放大粒度到8小时。

 

在燃尽图中，每个成员的汇总栏下，可以看到该人每个工作日的剩余工作量（用小时计算）。如  成员X: 44;40;35;30;20;15

 

如果某天的工作量超过剩余的工作时间，Scrum Master 就要提醒该成员注意，是否需要帮助等等。

 

在汇总栏下增加一行，用前一天的工作任务减当天的工作任务，则得到当天的完成工作量。

成员X: 44;40;35;30;28;18；0

完成量：_; 4 ; 5 ; 5  ;2; 10；18

 

上面的例子显示，成员X第一天完成了4小时工作量，第二天5小时，第三天5小时，第四天突然下降到2小时，但接下来上升到10小时，而最后一天达到惊人的18小时。

 

这是可能的。因为开发工作不会完全平稳前进，有时候遇到一个难点，而一旦攻克则能加倍前进。这些完成工作量的数据其实在燃尽图上就能体现。

 

现在的问题是，用燃尽图除了能展示开发进度外，能不能预测任务的完成？

 

我们知道，燃尽图中每个任务的所需时间也是成员自己估算的。这个估算建立在成员对任务难度的理解和对自己能力认识的基础上，也建立在每天充分工作的基础上。事实上，没有人能够8小时1分钟不拉地工作，总要收个邮件开个会打个电话发个短信什么的。假如能全神贯注6小时做开发，就已经非常不错了。燃尽图表格中的所需开发时间，也被称之为理想工作时间，即在完全不受干扰情况下所需要的时间。

 

但能否知道实际上将要花费的时间呢？

 

我的改进是继续增加一行，计算完成工作量的平均值。继续上面的例子：第一天是4小时，第二天为4.5, 第三天4.7，第四天4，第五天后平均速度是5.2小时，最后平均速度为7.3

 

成员X: 44;40;35;30;28;18；0

完成量：_; 4 ; 5 ; 5  ;2; 10；18

平均速度：4; 45; 4.7; 4; 5.2；7.3

 

现在，我知道成员X本周解决任务的平均速度为7.3。 如果数据持续几周，平均值会更加准确。但这又有什么意义呢？

 

开发速度本身并没有意义。如果Y的速度为2.5，并不意味着X的能力一定比Y强。因为X和Y对任务估算的尺度很可能不同。

 

但是下一次sprint计划时，在X给出他的任务估算后，我可以大致估算出他的完成时间。假设工作量为35小时，那么他应该在5个工作日后完工。（当然，前提是，X处理的问题是类似的）

 

这个方法有助于考察某些特别乐观或者悲观的程序员，避免被他估算的数字吓倒，但是我又不想深入细节和他讨论为什么这个任务要那么多（少）的时间。所以，最好用他以往的表现来提醒双方。

 

注意：

 

只有在完成故事的前提下，平均速度才是有帮助的。也就是说，在上面例子中，前几天计算的平均速度毫无意义。有时候最后1小时的任务要拖几天才能完成，各种各样的隐藏任务都在最后冒了出来。不完成完整的故事，计算结果就完全是误导！

 

对任务的时间估算是看个人的，对故事的时间估算是看团队的。Sprint注重完成故事，而不是任务。不要过于强调个人完成任务的速度，而使得团队的整体遭到破坏。

 

做时间估算是项目经理非常重要的一个任务。项目前期，在老板眼里，这是项目经理最主要的职责了。

 

通常说估算，有估代码行的，估输入输出参数个数，估界面元素的。等等。有个别专家估的，有大家估算平均的。不过这些估的都是开发工作量，要得出开发时间，还有考虑开发团队的工作能力、效率和到位情况。

 

Scrum 方法，首先是把需求分解为故事点。故事点可以理解为功能点，这似乎和过去的一样。注意，故事点是面向业务的，由需求人员来做这个工作。每一个故事点能实现一个可验收的业务需求。

 

既然是可检验，必须是对需求人员可见的。文档也好，界面也好，或者是可运行的程序。但不能是某个函数或者类。

 

故事点不是任务。

 

然后故事点要按优先级排列。故事点的划分以及优先级设置，以后专门细说。工作是业务人员来做，但他们需要引导。

 

第二步是估算工作量。选取任意一个故事，随意给一个点数。然后参照这个故事，给出其他故事的点数。

 

比如说，普通用户能够在首页查看自己的任务列表。这个故事有5个点。那么，经理（角色）能够给自己的下属设置任务，故事点有10个。就是说后一个的工作量将是前者的2倍。

 

这个相对工作量的概念是一个创新。因为它给模糊估计提供了可能。不管是估代码行数，还是界面元素，在开发前期都是很难实施的，因为开发者不可能对需求和设计了解的那么清楚，偏差会非差大。而且，开发的工作量不仅仅是代码和界面。

 

当然，这样的估计也是凭感觉估的。为什么说好呢，因为过去的方法是用不切实际的量化手段，反而不如一个整体的预估来的合理。前面说“任意”选故事，其实是选一个相对最熟悉的故事；“随意”给的点数，往往和开发单位时间相关（小时，半天，天）。

 

注意，一般对点数的估计推荐用估点卡。卡上的数字为1，2，3，5，8，13 … 点数间隔越来越大。这是因为故事越大，估算偏差就会越大。如果数字大的你无法把握，那么就该将故事继续分拆。

 

特殊点数：0. 有时候某个故事的工作量非常小，但必须记上一笔。比如故事“经理可以查看自己的任务”，它基本可以重用前面“用户可以查看自己的任务”，只要界面稍做改动。那么就添加一个点数为0的故事。

 

下一步是开始迭代开发。每个sprint周期一般可以是一周，两周，或者一个月。我偏好两周。因为sprint的准备会议和回顾都很重要。一周的话开会时间太多。而一个月则容易把开会内容忘掉。不过，进度的压力常常迫得采取一周一个sprint，因为老板急着要看结果。

 

假设这里是两周。然后按优先级从列表上选故事，看完全能完成的故事有多少个，计算累加的点数。

 

这里就得到第一次的估算时间，(总故事点数/本次sprint要完成的点数) * 2w

 

当然，这个估算是很不准的。没关系，scrum的特点就是动态自我修正，接下去就看迭代后的估算了。