敏捷开发生态系统系列之一：序言及需求管理生态（客户价值导向-可工作软件-响应变化）

所谓生态系统，就是指互相依赖方能生存的一系列生物。生态系统常常不是单向依赖的，而是互相依赖互相促进。

敏捷开发中的实践也是如此。典型地，当一个实践很难实施时，一定不要认为简单的制度可以保证其实施，而是要思考是什么导致了它的失败。比如每日立会，如果发现大家都不按时开会甚至不开会，马上要做的不是要求大家按时开会+开会迟到给大家买水果+统计每月按时比例+……而是要想一想为什么这些人不按时来，他们一定觉得这个会议不是很重要，会上讲的东西听的东西不能帮助自己的工作，反而耽误时间。进而就能发现会议开不好的根本问题。

敏捷开发中需求管理生态大致如下（请配合插图，黑体字即插图中的元素）：

客户价值导向是敏捷开发需求管理的主要思想。

敏捷开发相信密切与客户协作比编写详尽的文档更能弄清楚客户的需求；而利用阶段性的可工作软件外加邀请客户参与评审会，比让客户评审需求文档更容易让客户正确地补充需求和验收产品。

由于相信变化后的软件一定比变化前的对客户更有价值，所以敏捷崇尚响应变化。提供可工作产品来引导客户变化，可保证客户更能正确翔实地描述变化；而迭代交付则使得重要的、必要的变化可以提前交付，而不是像瀑布模型一样最后才发生。

通过需求优先级排序和迭代交付，首先可保证重要的需求一定可以交付到客户手中；其次可以保证重要的变更来临时，可以放弃尚未开发的次要需求作为交换；再次可以保证产品负责人（PO）会优先分析重要的需求，不会让它们在模糊状态进入开发。

只有最高优先级的需求才会进入下一迭代，因此很少有变更比它们更重要，而且这些需求也被较深入地分析过，产品负责人就有信心承诺迭代期内无变更，以换取团队承诺，进而保持交付以可持续的步调发生。

拥抱变化是一种由客户协作、优先级排序、可工作软件等各种实践支撑下的、主动的可控过程，而不是被动地“被变化拥抱”，“迭代期内无变更”和“拥抱变化”的对立统一，必须建立在这些实践的基础上。

客户价值导向-可工作软件-响应变化这三条是需求管理生态的核心内容。下面从一个问题的分析来看需求管理生态的工作原理。

“为何客户在评审会上不置可否，只说让我们继续开发一些功能后再说？”

这是一种很常见的场景，简单粗暴的处理方法包括：

1. 若评审会上没有意见，就表明认可了功能。

2. 评审会结束后必须书面验收已经完成的功能。

3. ……

不过这些仅仅是粗暴地执行Scrum的实践，而没有获得Scrum的精神。

仔细分析一下，客户这样做的原因很多，其中一些我们不容易控制，另外一些则相反：

1. 客户送来的代表是个“小角色”，无法替客户决策。

2. 我们的软件在客户眼中不是一个“可工作的”软件，因此他不能或不想太早下结论。

3. ……

针对1这类“不可控”问题，在实际环境中其实都有各种解决方法，只是作用大小而已。比如将每次的评审功能抄送给对方的负责人以引起重视；让功能的最终使用者参与评审等等，具体情况具体分析，这里就不多说了。

针对2这类“可控”问题，可做的就很多了。

什么是可工作软件？在研发人员眼中，可工作软件很容易等同于可运行的软件，“它能跑在我们的测试服务器上，我们还有自动化脚本能自动运行和测试其功能……”但在客户和用户眼中，可工作软件是那种他们现在就可以拿回去用的软件。比如一个Word软件，如果能编辑但是不能分段；能插入标题但是字体一样大；能插入图片但暂时只是一个链接需要双击才能打开……这三样功能都是至关重要的功能，但把它们临时凑在一起的软件，并不能让用户真正使用起来。还不如做一个“暂时只能编辑，不过可以分段、缩进，适合写简单的无复杂格式的文本，比如私人邮件（现在Outlook中还有个选项是用Word编辑邮件）”，看到这样一个软件，尽管客户不会接受这就是他们最终得到的产品，但是却可以理解在这样的场景中，这个软件到底好不好用，如果要改进改进哪里等等。

或许为了制造这个软件，我们一定程度上打破了优先级排序（“插入标题”比“缩进”要来得重要），但却使得“可交付”和“客户评审”成为现实。其实从这个角度看，我们反而在以客户价值驱动的方式生产着软件，也就是说“可运行软件”要从“客户价值驱动”的角度来定义。

好了，要解决这个问题答案就出来了：我们多半会把Product Backlog划分为若干故事群，每个故事群大致可以完整交付；我们提前让客户参与制定故事群开发的排序工作，这样客户就知道什么时候将发布什么功能，以及自己来评审什么功能；在完整地看到一组功能后，客户更容易得出“这一切是否可行”的结论；如果他们愿意，还可以提前部署上试用一下……

个人感觉在应用敏捷实践时，虽然不能迷信其普适性，但也千万别在遇到挫折的时候马上否定，或将问题归结为文化和公司环境；作为开发和管理人员，我们极有可能少或多做了什么事情。

有读者在图中的右侧可能看到了“迭代期内不变更-团队承诺”这条很重要的生态线，将在以后的“计划跟踪”中提到。

敏捷开发生态系统系列之二：敏捷生态系统-计划跟踪 I（跨职能团队-共同估算-每日立会-同行压力）

如果说需求管理中尚有一些团队无法控制的因素导致实施困难，计划与跟踪过程总归就没有问题了吧？其实不然，笔者见过领导很放权的全团（很多是因为领导根本管不过来了），但在团队内部仍然存在很大的问题，一般最为突出的，就是每日立会开得毫无生机。这不完全是因为文化差异问题，而是生态系统出了问题。

敏捷开发中的计划跟踪生态大致如此（黑体字即图片中的元素）：

跨职能团队的整体思路是“每个人可以做每个工作”。好处是消除了资源分配的瓶颈和造成队员无法互助的分工壁垒。

任务应该先估算后分配给个人，以便整个团队（或至少其中的某个小组）都对其保持兴趣，才可能进行真正的共同估算。

共同估算（一般采用扑克牌估算）中人们利用整个团队的智慧充分讨论和确认任务的实现目标和方法，因此PO会统一管理/讲解需求，以防止个体理解差异。共同估算是共同跟进的基础，在每日立会中人们之所以关注别人的进展，就是因为人们关心自己曾经参与的估算结果是否正确，方案是否可行。

共同估算和每日立会产生了同行压力，即每个人都希望以好于或至少持平于团队估算的结果完成任务，从而产生了受激励的个体。

共同估算和每日立会还防止个体失误，前者通过统一了大家对同一个需求的理解和其实现方法的理解，后者则防止了工作中出现需求镀金、蛮干等问题，从而产生更好的技能和设计。

作为自组织团队，敏捷团队并非简单地因为“领导让我们自我管理”而受到激励，而是在跨职能团队、共同估算、个体交互、同行压力这些实践的配合下才产生了受激励的个体和更好的技能和设计，从而产生更好的工作效率。

跨职能团队-共同估算-每日立会-同行压力是这个生态系统的主线之一。

如果从每日立会的例子看，要解决每日立会问题并不难，可以简单地：

1. 由Scrum Master监督必须召开每日立会

2. 统计每日立会的执行情况

3. 设立按时完成奖和迟到罚款箱

4. ……

这些方法有很多公司都用过，笔者早期知道这些方法时，还真的以为这样就可以了呢，直到后来听说沉闷的每日立会越来越多，才知道存在深层问题。

从生态系统的角度怎样看待呢？

第一个要怀疑的是是否进行了共同估算。如果大家都对别人的任务不了解，也从来没有参与其中（，那么自然就像听天书一样听别人讲；而如果别人对自己的任务不了解，那么即使遇到困难，告诉他们又有何用？（除了表明自己笨……）最终就形成了沉闷的每日立会。

但如果继续分析下去，共同估算的根源又在跨职能团队。这里之所以只把“先估算后分配”当作一个小跳板，是因为不能简单地认为“因为大家不知道会分给谁，所以不得不一起估算”，大家迟早会形成习惯性分工的，所有人都会知道哪个任务其实肯定分给别人。只有“每个人都能做每个任务”的跨职能团队才能解决这个问题。

建立跨职能团队是个难题，个人感觉不可能强制三四个人无缘无故地就跨职能了，他们私下里都会自动形成强分工体系的。一个好的方法是利用师徒制度和松结对编程建立稳固的团队关系，责权利统一远远易于改变团队文化。

尽管计划跟踪整体上是团队内部的事情，但是却可能在计划的时候被强制多做事情，而在跟踪途中又被加入变更而时间点不变。怎样处理这些问题呢？这就是计划跟踪生态系统的另一条生态线，将在下一篇文章中描述。

敏捷开发生态系统系列之三：计划跟踪II（需求优先级排序-迭代期内无变更-团队承诺）

产品负责人PO与团队的互动一直是一个难题。典型的问题在于：敏捷开发倡导“迭代期内无变更”以换取“团队承诺”，而实际上产品负责人却会不断地来提变更，打乱开发计划了。我们应该怎么办呢？产品负责人说“敏捷就是拥抱变化，我现在来提变化了，你们却关门了。”团队说“如果你总是变，下次我们怎么给你承诺。”

敏捷开发中的计划跟踪生态II大致如此（黑体字即图片中的元素）：

产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。

产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。

团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。

产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行压力（与其他团队及与自己的过去相比），并进而产生受激励的个体。

作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

需求优先级排序-迭代期内无变更-团队承诺是这个生态的主线之一。

让我们重新看一下前面变与不变的例子。

简单粗暴的方法包括“一个强制性的变更或不变更制度”。即在高层领导的支持下（如果他们不支持，大家就放弃敏捷开发，你们说怎么办就怎么办，但别再提敏捷开发了！），团队坚持每个迭代都不变更。这个听起来很简单，但实际操作是有难度的。毕竟变更经常来自客户，团队怕产品负责人，所以搬出高层领导；产品负责人怕高层领导，会搬出客户。

另一种细腻一点的方法是制定一个“何为需求变更何为需求细化”的指南。毕竟有时候提前想的是一件事情，但具体做的时候才发现应该做成另外一个样子。难道大家真的应该二话不说先把错误的东西做出来，到下一个迭代再变更？这不是纯粹和自己较劲么。所以兴许我们不会把任务扔掉，但是却可以把任务的描述改动一下，作为“细化”来接受。这种指南有其现实意义，但万勿当作法律条文来办，因为很快就会发现有处于模糊状态的东西会引发争议。

其实终极解决方案，是顺着图中的线条向下看：团队承诺-迭代期内无变更-需求优先级排序。最后一个才是重点。

有几种原因会导致迭代期内变更，一种是发现了紧急的需求，一种是发现了更重要的需求，另外一种是发现需求和以前想的不一样。

第一种在MoSCoW中提到过，可以通过优先级分级的方法来容纳之；另外事先商定只有比如70%的时间可用，也可提供额外时间来处理，这里不多说了。

另外两种，则都是与优先级排序工作不到位有关的变更。

1. “来了更重要的需求”其实等同于“我们之前在做不重要的需求”。

尽管人们难以准确预测哪些需求真的最重要，但当我们从众多需求中挑选了极其有限的自然也是极其重要的需求放在迭代中，却能在短短的一个月内跳出一个更重要的需求（这个需求多半不在已知的“众多需求”中），就应该意识到之前的需求收集和排序工作肯定出了问题。原因或许是我们挑选了不称职的产品负责人，或产品负责人采用了错误的需求分析方法，或产品负责人工作在极端苛刻的环境中（比如客户拒绝透露需求）等等。这些问题看似可怕，但一旦摆上台面，解决它们比不知道原因地解决“迭代期内到底变更还是不变更”要容易得多。因为事关细节和具体环境，以后会有博文解决（部分已经计划在《火星人敏捷开发手册》的章节中）。

2. “需求和以前想的不一样”听起来是一种无法避免的问题，但其实我们有很多工作可做。

尽管人们难以准确预测所有需求的实际内容，但却可以就部分内容做深入了解。具体实践包括：

在纵观大局的同时，产品负责人应时刻注意最重要的需求是否弄清楚了，应多就这些问题与客户探讨，防止被迫讲不清楚的需求发放给团队的情况。

应建立故事群的概念（在之一中有提到），即当零散的需求极难与客户沟通和获得反馈的时候，应就一组故事与客户反馈。这样不容易遗漏故事，也不容易对故事的排序疑惑，因为故事之间有可比性和依赖性。客户可能很难决定“一周节目单”重要还是“地区访问码”重要，但是却很容易判断“一周节目单”比“当月节目单”重要。

在具体工作时，团队不应该彻底放弃对优先级排序工作的思考，而是应该配合产品负责人做好这个工作，尤其是团队中高层次的对业务有所了解的人。

与之相对应的，是产品负责人也不应该彻底放弃对计划工作的思考，这就是下一篇将描述的开发团队自己估算-PO挑战估算-同行压力的生态线。

敏捷开发生态系统系列之四：计划跟踪II（自组织团队-开发团队自己估算-PO挑战估算-同行压力）

在实际开发环境中，产品负责人常常和开发组存在潜在的利益对立。前者往往希望在更短的时间开发出更多的功能，而后者的绩效则多数来自于计划按时率/缺陷率这些会因“更短-更多”而下降的数据，于是两者的隔阂从此开始。

敏捷开发中的计划跟踪生态II大致如此（黑体字即图片中的元素）：

产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。

产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。

团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。

产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行压力（与其他团队及与自己的过去相比），并进而产生受激励的个体。

作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

自组织团队-开发团队自己估算-PO挑战估算-同行压力是这个生态的主线之一。

让我们重新看一下前面产品负责人与团队矛盾的例子。

简单粗暴的解决办法无外乎此：

1. 规定产品负责人完全不得干预估算

2. 规定无论接受了任何挑战（质询），团队最终对估算结果拥有决定权

这些看起来都是很好很符合Scrum思想的制度，但是执行起来却早晚出问题。 我们假设在项目开发环境中，产品负责人是一个销售/售前*（或者拥有与其相似的绩效机制的人），他的绩效来自于合同额+客户满意度，从合同额中提取X%作为奖金；而开发团队的绩效来自于与计划相比的按时完成率+缺陷率。这个结构已经确定了两者的心法将背道而驰，无论任何研发方法论都不可能统一两者的思维。很快前者就会祭出客户来打破公司制度，而高层捍卫Scrum的决心远远低于捍卫销售额的决心，制度很快名存实亡。

怎么办？从“自组织团队”的根基下手。

笔者正在筹备一个“自组织团队系列”，其中第一篇已经处于草稿状态（截至2011-08-16）。这一篇的名字叫“用中医理论管理团队”。由于限于医学技术，中医始终不知道“细菌”“病毒”这些外部因素的存在，而只知道生病是人体自身存在了问题，比如“肝火上升致邪气入侵”，因此类似针灸这种完全没有任何药物的治疗方法也非常有效。对于一个敏捷团队，要理顺产品负责人和团队的关系，首要的就是调理好团队的利益。

在敏捷外包工程之二：人员结构中提到过三个公司，一个将项目额的10%给予团队作为奖金，一个将研发成本计入产品部门的成本，一个将实施成本计入销售人员的销售成本，从而很大程度上统一了产品负责人和团队的认识。这三个团队及其他类似团队的做法可归纳为两条：

1. 将研发成本计入销售成本。

此举将保证产品负责人（有时是一个团队）将非常在意客户是否真的需要某个功能，而不是本着越多越好、盲目讨好客户的原则办事。

2. 将项目收入下放到研发团队

此举将保证研发团队正视“盈利”这一开发人员很少在意但却是公司立足之本的元素。

做好这两条后，一个自组织团队的雏形就出现了。现在公司高层不用天天做仲裁了，双方会很平心静气地坐下来思考问题，查找关键解决方案。

这两点做得最好的是网络游戏团队，笔者去过很多家游戏开发公司，其中多数都拥有几个乃至几十个游戏研发团队，每个团队内部拥有产品负责人（策划团队）和开发团队。他们都高度自治，除了影响投资和收益的重大里程碑评审，领导几乎不过问细节，比如他们是用什么开发方法，最近在做什么等等。因为他们的核心内部机制就一个：赚钱大家分。不赚钱的功能不会有人提出来，赚钱的功能也不会有人偷懒不做。

在项目开发中这一点可能有点困难，不过在敏捷外包系列中可以看出其实还是有很多实际工作可做的。

完成自组织团队的初步建设后，开发人员自己估算和PO挑战估算就完全变成另外一个样子，而产生的同行压力也与之前截然不同。人们会：

1. 团队尽可能缩短估算，尝试最快的实现方法--------因为没有人考核“按时完成率”，完成早了多了来自客户的奖金也多。

2. “偷懒的人”将不复存在，因为他不但挡在自己的财路上，还挡在团队的财路上----------所以领导不用安装摄像头和屏幕监视软件了。

3. 赶工期的PO也不复存在，我见过一个PO很担心地问团队是否真的能完成，因为一旦延期客户会很失望，大家都遭殃。

4. ……

本篇的内容大量涉及了非研发部门的制度问题，比如为销售设置奖金机制，在实施起来会很有难度，需要公司层面的配合；从另外一个角度看，收益也是明显的。

笔者除了做过研发管理之外，还曾经任外企中国公司的部门经理和副总经理，同时管理过市场/销售/支持等非研发部门。本文的案例虽然是引自别的公司，但在理顺自己管理的部门的时候都有尝试使用，取得了显著效果。在这个过程中逐渐悟到如果不能在整个公司层面理顺关系，妄谈敏捷开发几乎是不可能的。

读者可能注意到本文所使用的图形中框的底色不同，其实自下而上它们被分为团队/客户（棕色）-计划实践（蓝色）-跟踪实践（紫色）-收益（绿色）-目标（金色）几个层次，但缺少“配套制度”这类研发外的生物，“持续集成”“MoSCoW”这些生物也没有位置。

未来本系列（也或许是其他系列）中将将包含一篇或几篇“敏捷成熟度模型”的文章，会将它们纳入其中。这个成熟度模型不是为了评估使用，而是为了弄清楚自己的团队还有哪些活动没有做，它们的目的和价值是什么，是否由于缺失它们而造成了一些困难，从而判断自己的敏捷开发还可以做哪些改进。

敏捷开发生态系统之五：关于敏捷生态系统的一次聊天记录（敏捷估算，同行压力，估算扑克）

本文是2009年刚刚提出敏捷生态系统的时候参与一个MSN讨论组时的对话，当时的想法与现在相比尚缺少系统性，但由于有问有答，也包含了本系列所没有包含的一些信息，仅供参考。

删除了部分无关的对话。

“敏捷生态--Srcum敏捷开发”--msn群讨论

2009-08-25 13:52

谷雨霖 说:时间差不多了 今天我们的主题是“敏捷生态” 有幸请到的是我的老朋友，敏捷专家陈勇先生

M群-项目管理 说:【系统提示】AlexQin将昵称更改为AlexQin-QC-深圳

不胜人生一场醉-N/A-海南 说:鼓 掌

dearChloe-PM-深圳 说:专家好

Yong CHEN 说:大家好

M群-项目管理 说:

谷雨霖 说:陈勇先生在9.12的敏捷中国大会有专题发言

他的介绍：

TechExcel中国区咨询总监，具有13年软件研发、管理和咨询的从业经验，拥有多年敏捷开发、CMMI、度量与基准比对等多种软件过程管理咨询和培训经验。他结合企业中大规模团队的管理需求，成功导入并实施了面向100人左右大团队的最佳研发管理实践，融合了敏捷开发实践和CMMI体系。其以敏捷开发为主要内容提供过咨询/培训/专题演讲的企业包括Thomson CR / 广州从兴 / 金山软件 / 盛大网络等企业。他还在2007/2008年度中国过程改进大会及2009年中国软件技术大会上进行了《敏捷开发中的度量》、《从交付保证看敏捷开发的价值》等敏捷主题演讲。

litao 说:陈老师好

Yong CHEN 说:我是昨天刚来的，很高兴认识大家。 现在就正式开始了

谷雨霖 说:下面，我把时间交给陈老师。13：00听陈老师讲述

susan-pm-湖北 说:鼓掌

xiyeqing99@hotmail.com 说:(Y)

谷雨霖 说:余下时间，提问交流 xiyeqing99@hotmail.com改签名

Yong CHEN 说:关于敏捷生态，是去年逐渐意识到的一个问题。

M群-项目管理 说:【系统提示】AlexQin-QC-深圳将昵称更改为AlexQin(21)-QC-深圳

Yong CHEN 说:在做CMMI咨询的时候，一直希望能把CMMI一点一点实施下去，而非一次到位。这样对企业的压力小，还能用已经取得的成就，去鼓舞和支持剩下的工作。但是一直没有成功，因为大家也知道，国内做CMMi都是阶段式的，直接一级完全没有做连续式的，也就是说重点做某些价值最高的过程域，以后再说其他的。但在国外，基本上则是一半一半。当然原因也很明显：政府给的补助，是针对阶段式的。所以后来逐渐转向敏捷以后，也是很想在新的领域引入连续式在一家南方的公司咨询的时候，我发现他们有诸多的限制，无法整体实现敏捷。对了备注一下：这里指的敏捷是Scrum，也就是偏管理的分支，重点内容是需求管理/项目计划/项目跟踪

Yong CHEN 说:大家比较熟悉的TDD/结对编程/重构等属于关注技术的XP分支

TonyAquarian_IT Consulting_北京 说:--- 系统提示: 您的联系人 aquarian - 庸人自扰已使用MSNShell 提供的加密对话功能，该功能需要双方都安装MSNShell( http://z.xiaoi.com/rmsnshell-download-6zt818.hi5i.cn%2Fmsnshell) 以提升聊天信息的安全性，防止来自网络的偷窥行为 ---

Yong CHEN 说:他们的限制主要在于：

1. 团队内部有相当明确的分工，大家看到需求就知道是谁的

2. 一直是项目经理说了算

当然既然要敏捷，那么2是一定要破除的，一定要让大家自己估算自己的任务，这样才能实现承诺，进而激励工作效率

但是1我当时就想将就一下，毕竟长期而言人们的专业分工已经很难破除了

培训之后他们就用上Scrum了，过了2个多月，他们进行了两轮迭代，我满怀希望地前去做二次指导

结果发现：他们开计划会议的时候，几乎同时只有1个人在做自己的估算，别人都在聊天，直到换任务（负责人也相应地换了）

这里就出现了一个问题。我们互动一下，谁知道这种“自己估算自己的任务”的方式有什么不好的地方？

M群-项目管理 说:【系统提示】aba21st@126.com将昵称更改为trriger-SQA-上海

北京-QM-李晋James Li 说:没啥不好啊。

susan-pm-湖北 说:缺少和其他成员之间的沟通？

北京-QM-李晋James Li 说:自己估算，自己最熟悉自己能完成多少东西。

谷雨霖 说:先听

Yong CHEN 说:比项目经理或更高的领导直接指定时间，显然有其优越性。

谷雨霖 说:不要打断

liu.chsh@hotmail.com 说:“自己估算自己的任务”，成员往往多估计

Yong CHEN 说:呵呵我就是想互动一下，大家插两句 打断正常

谷雨霖 说:ok;) 依照过去打断很难收回的，哈哈

Yong CHEN 说:1. 缺少沟通 2. 往往多估 哈没事，我来控制。

liu.chsh@hotmail.com 说:我认为还是互动比较好，老谷来控制

Yong CHEN 说:为什么会多估呢……

litao 说:也有可能为了冒进少估把

liu.chsh@hotmail.com 说:没有共识，成员不能看到全面，有时也会少估计

北京-QM-李晋James Li 说:能否delphi一下

Yong CHEN 说:当然有很多原因：怕完不成；怕忙（偷懒）

北京-QM-李晋James Li 说:说明一下估算的原因？

Yong CHEN 说:恩，这样很多问题就冒出来了，我们可以看到：敏捷要求团队尽量弥合分工，尝试一起做估算。

liu.chsh@hotmail.com 说:多估：主要是想骗PM 少估：主要是不全面

Yong CHEN 说:好的，剩下的问题：为何要估算？ 简单的原因是：需要一个数字，知道多少天多久

dearChloe-PM-深圳 说:排计划呀

xiyeqing99@hotmail.com 说:pm这么好糊弄啊

Yong CHEN 说:复杂的原因可以分为两种：R问题和D问题

liu.chsh@hotmail.com 说:虽然不好，但是他们还是想这么做

北京-QM-李晋James Li 说:我们的主要问题是怎么估 story point

Yong CHEN 说:一个PM或高级领导是容易糊弄的，下面我们马上会发现有一些人是不能糊弄的：同行，队员，伙伴

liu.chsh@hotmail.com 说:做WBS，评价自己多年的经验

Yong CHEN 说:这是敏捷计划的精髓。Scrum计划尝试解决R问题和D问题

liu.chsh@hotmail.com 说:在影响整体进度的情况下，参考一下 资深 成员

Yong CHEN 说:所谓R问题就是：这个需求说的是什么？实现到何种程度？标准如何？0缺陷吗？等等

这个是需求问题

在Scrum计划会议的上半截，Product Owner要给大家统一讲解需求，有问题的人随时提问。

剩下的事情是：谁会有问题？当然是任务的负责人。而我这个客户由于前面说的原因，提问的人就一个人

自然也只有他彻底明白了任务的需求，而其他人事不关己，高高挂起。

有时其他人也听到了一些有有疑惑的东西，但既然负责人都说明白了，我还要问什么呢……也就不问了，就埋下了隐患

计划的第二个问题，是D问题（设计问题）：这个需求用什么方法实现最好？有没有现成的代码可以复用？完全复用，还是需要改动一下，还是改动也没用因为留有后遗症？

很可惜，D问题不是那么好解决的。

比如如果我是一个高手，来了一个新手，我想知道他怎样实现“排行榜”功能，怎么办？

当然我可以让他说说他打算干什么，可惜程序员都不擅长言谈:D

Yong CHEN 说:计划会议上也难以让他把整个实现思路讲一遍

这时候，就需要用别的方法了，那就是“CRC32”校验

不知道大家了解CRC32校验不

dearChloe-PM-深圳 说:

不了解

Yong CHEN 说:要想了解一个文件（或某短信息）是否是完整无损的，最简单的方法是把文件存两份（或发送两份），比较一下有无差别。

(R)(L)China_Iverson(R)(L) 说:程序员都不擅长言谈？至少能说清楚吧

Yong CHEN 说:但这样实在太费空间时间了，所以科学家们发明了一种方法：

先说个简单的：就是把文件所有字节加起来（溢出超过256的不要了),把这个校验和放在末尾。

收到文件后，重新计算一下文件的校验和，如果一样，“多半”表明没有错误。

CRC32比校验和厉害一些，但原理相同。

估算就是这个目的！

03年我做项目经理的时候就是这样

每天早上20分钟给大家讲讲需求和设计，然后挨个问一个问题：

你今天听了需求和设计，打算写多少代码？

他们就用手比划：2个屏幕，还是5个屏幕

如果我感觉和我想的差不多，就过；如果差别很大，就问问屏幕里边有什么

用这种方法，只要几秒钟，就能对上暗号，“多半”他没有听错想错，也不会做错。

说的太多了，有没有说的不清楚的地方？

chinamath(海茶)-Sr.SE-北京 说:这个方法好。

dearChloe-PM-深圳 说:恩

Yong CHEN 说:当年也是个编程高手，我说说曾经“杀代码”的经历，大家就知道估算的重要性了

01年，110行杀到50，第一次杀，上瘾了

还是01年，4000行杀到400行

02年，4000行杀到50行（那个程序员干了一个月了，一个下午被杀到50行）

04年，别人杀代码的记录：10万行杀到1.3万

在4000杀50那次后，我在想：怎样让这个程序员干活之前，他的项目经理就知道他要做错事呢……（当时我是EPG的)

所以在03年我又重新管理项目，实践出了上面那种方法。

好了，R问题和D问题都解决了，剩下的是：刚才说过，任务都有一个负责人，别人怎么才能替他关心他的R和D问题呢？

在那个客户那里，采取了两次步骤

前几个迭代，小组长（手底下有3/4个人）和那个人一起打牌（计划扑克，不知道大家了解不？）

我闪屏就是有问题啦，呵呵

也就是让小组长和手下具体负责人一起计划

后几个迭代：先把任务分配到小组（3/4个人）不指定具体负责人，先估算，再分配。

这样大家不确定是否是自己的事情，不敢怠慢，都会用心得提问需求问题，用心地讨论实现方法

讨论过程中很快发现，有些需求没有想到，有些方法是错误的

比如有个程序员低估了任务，因为他说有个库拿过来就能用，另外一个程序员就告诉他：那个库很难用，自己试过，还不如重新写一个。等等。

当然，大家用计划扑克的方法，如果大家数字相同，不会讨论直接通过，有人太多或者太少，才会讨论。

这样大大节约了时间，又达到了目的。

好了说了这么多，回到主题：敏捷生态

通过刚才的例子，我们会发现敏捷这里就直接说Scrum把：是一个经过实践总结出来的方法

他们当年也一定遇到过类似的问题，所以才说：尽量不分工，而是建立跨职能团队，“所有人干所有事”，才能取得良好的计划效果

如果把跨职能团队去掉，仍然开计划会，仍然有PO，仍然让大家自己估算自己的任务，效果就很差了。

这就如一个生态系统，各个部分是联动的，不能轻易去掉其中一个。

哦对了解释一下另外一个问题：如果有3个人一起估算，这时候就会产生“同行压力”，没有人想证明自己是“笨蛋”，所以他们不会故意高估任务，因为自己的同事（技术背景/职位相同）在和自己一起估算

dearChloe-PM-深圳 说:

那怎么办呢？

Yong CHEN 说:

别人说2天能完，自己偏说4天，显然有问题。要知道这个工作还没有分配，未必是自己的工作。

这种同行压力效果比领导压力好，因为领导不懂，很容易糊弄，呵呵。

什么怎么办？如何对待生态系统？

dearChloe-PM-深圳 说:

我是说，因为同行压力，大家会不会都少估呢？

Yong CHEN 说:

了解了生态系统，就会知道：要上敏捷，尽量完整地接受敏捷，而不要卡在中间，效果不会很好的。

谷雨霖 说:嗯

Yong CHEN 说:不会的，无论高估还是低估，都要给大家解释原因。

dearChloe-PM-深圳 说:恩

Yong CHEN 说:敏捷中计划扑克的玩法是这样的：

(R)(L)China_Iverson(R)(L) 说:我觉得应该不会少估吧，因为有可能是自己会开发的

Yong CHEN 说:

1. 讲解需求和提问，直到没有问题

2. 几个人一起扣着出牌

3. 翻牌，最多的和最少的PK，除非他们差别很小

4. 大家听他们两位PK（一般一位会“占理”一些），回到2

5. 中间有任何对需求的分歧，PO解释（有时候PO也解释不清楚，这个需求显然还太模糊）

在这个过程里边，人们显然不愿意故意高估或低估（PK中很难给大家一个满意的答案的）

而寻求真是结果的愿望会占据上风。

(R)(L)China_Iverson(R)(L) 说:估算的时候是是不公开的吗？就是说扣着牌的？

Yong CHEN 说:对，先扣着出牌，然后一起亮牌

susan-pm-湖北 说:是怕从众吗

Yong CHEN 说:对啊

xiyeqing99@hotmail.com 说:这方法好？

(R)(L)China_Iverson(R)(L) 说:就像评委打分一样？

xiyeqing99@hotmail.com 说:Yong CHEN大哥 怎么被你想到的啊

Yong CHEN 说:这其实就是Delphi的变形，Delphi也是匿名的，但是太慢了。晕，不是我想到的

谷雨霖 说:对 delphi增强版

xiyeqing99@hotmail.com 说:哪位牛人想出来的啊,这么好的主意

Yong CHEN 说:http://z.xiaoi.com/rwww.planningpoker.com%2F

xiyeqing99@hotmail.com 说:哈哈

Yong CHEN 说:老外想到的,敏捷生态是我想到的

xiyeqing99@hotmail.com 说:老外确实有2把刷子啊,你也有几把刷子 呵呵

litao 说:不过还是有问题的,如果时间长了大家都可能在自己的基础上面高估的

谷雨霖 说:继续说生态，没深入说这个理念

Yong CHEN 说:对了我们公司要印刷敏捷扑克了，等15天就出来。谁要，给我发邮件，写个快递地址

谷雨霖 说:怎么叫全生态

Yong CHEN 说:cheny@cheny.com

xiyeqing99@hotmail.com 说:我要

Yong CHEN 说:写邮件

(R)(L)China_Iverson(R)(L) 说:我也要

Yong CHEN 说:好，全生态很复杂，但是局部生态是存在的。

比如Scrum在国外其实比XP热很多，原因就是他的生态系统相对简单，比较容易建立起来。

xiyeqing99@hotmail.com 说:恩 Scrum确实简单点

Yong CHEN 说:我已经画好了Scrum生态图，回头发给大家。

xiyeqing99@hotmail.com 说:上次买了本xp的书 看了一页就看不下去了

Yong CHEN 说:如果大家用了Scrum，但感觉有件事情怎么也没做好，就看看与之相连接的生物是否有纰漏。

xiyeqing99@hotmail.com 说:哦

Yong CHEN 说:但XP的生态相对复杂，关键需要一些技术方法 。

比如你想TDD和持续集成，就需要一些自动化测试工具的支持。

如果老板说：太复杂了或太贵了别买了，你先用用别的条目吧……结果生态系统就被破坏了

chinamath(海茶)-Sr.SE-北京 说:敏捷扑克太好了，请陈老师留个邮件地址。

Yong CHEN 说:cheny@cheny.com

chinamath(海茶)-Sr.SE-北京 说:OK，谢谢！

liu.chsh@hotmail.com 说:怎么给你钱

Yong CHEN 说:公司市场部给我钱，呵呵。免费的。参加敏捷大会的人手一个。

liu.chsh@hotmail.com 说:但是我不在北京，不能参加，

Yong CHEN 说:好了回到生态系统：由于Scrum只涉及需求管理/计划/跟踪（比CMMI对应内容少），所以存在整体部署的可能。如果要用Scrum，一定要用全！

liu.chsh@hotmail.com 说:外地，你们帮忙邮寄吗

Yong CHEN 说:没事，给我邮件说清楚地址收件人，快递过去。

M群-项目管理 说:

Yong CHEN 说:好了基本结束了，呵呵。

谷雨霖 说:欢迎“打鬼子”加入;)

S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:hi

Yong CHEN 说:会上我会用3～4个例子更详细地解释敏捷生态系统，但这里太慢了就不多说了：D

dearChloe-PM-深圳 说:哎，可惜

Yong CHEN 说:回头大会或许有录像。刚才是其中一个例子。

S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说://all

Yong CHEN 说:打鬼子你好，呵呵

S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:呵呵。我来晚了。

谷雨霖 说:梅总也是很优秀的专家

S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:大家都这么客气。。

susan-pm-湖北 说:欢迎

xiyeqing99@hotmail.com 说:(F)

谷雨霖 说:陈老师，你今天讲了敏捷，非常打动我。让我第一次有了推行敏捷的冲动

xiyeqing99@hotmail.com 说:哈哈陈老师的msn多少啊

litao 说:陈老师,我还有问题,如何判断所有扣牌的人都高估呢

suzerain1983@hotmail.com 说:敏捷，英文是什么？

AlexQin(21)-QC-深圳 说:Agile

susan-pm-湖北 说:agile

xiyeqing99@hotmail.com 说:对

suzerain1983@hotmail.com 说:谢谢，忘了怎么拼了

Yong CHEN 说:哈哈以前你没有推动敏捷的冲动啊，呵呵。

AlexQin(21)-QC-深圳 说:呵呵

chinamath(海茶)-Sr.SE-北京 说:实际一般怎么PK？能再讲点细节吗？

Yong CHEN 说:哦，PO有权利挑战大家的结果，如果他感觉太高或者太低。

谷雨霖 说:有冲动，但在全公司推行有阻力和顾虑

Yong CHEN 说:所以可以防止整体高估或者低估。

liu.chsh@hotmail.com 说:可以拿项目做示范

Yong CHEN 说:PK举个例子：1 2 2 5，1和5PK

1：这个很简单的啊，就调用个函数，上次小X已经编好后台了。大家：是嘛？汗～然后，二轮全部变成1

也可能是：

dearChloe-PM-深圳 说:我想问：　就凭需求，就可以做到那么细致的工作估算？

Yong CHEN 说:1： 这个……后台了。5说：但我们不只在游戏里边做排行榜，还要在网站上做，两边同步。

122问：要吗？

PO：……应该要，网站不是你们做的吧？你们先看你们做要多久，我的记下来，得告诉网站部门也要干活……（写字）

上面PK的例子是在盛大真实发生的情况，上次刚给他们做过咨询。

susan-pm-湖北 说:老师，制定产品清单的过程是谁来做，也需要一个或多个迭代过程吗

Yong CHEN 说:只凭借写出来的需求是不行的，因为写需求的人也不知道大家想知道什么，不知道什么。

ddv731731-SSE-上海 说:是SDG,还是SDO

liu.chsh@hotmail.com 说:开会讨论前，让所有成员都自己准备一下，注意一定要后分工，不要讨论前分配工作，不然他们就只管自己的估算了

北京-QM-李晋James Li 说:今天公司网络不好。精彩的部分煤看到。没看到。

Yong CHEN 说:所以一般需求可以写简单点，但讲解的时候多讲点（说话速度比打字快多啦），并且跟着大家的提问讲。

北京-QM-李晋James Li 说:陈老师，放出msn吧。

chinamath(海茶)-Sr.SE-北京 说:是不是还得有个记录？否则PK那么多，谁能全记住。

Yong CHEN 说:当然，讲完后，根据大家的提问，把需求补充一下。

liu: 对，讨论前要看的，特别是比较大的需求。

SE: 对，有个会议秘书，打字高手（轮流的），记录一个草稿纸。

北京-QM-李晋James Li 说:陈老师，重构在什么时候做。作为一个backlog吗？

Yong CHEN 说:我本人的草稿纸现在264页，从去年7.15到现在。

susan-pm-湖北 说:老师，制定产品清单的过程是谁来做，也需要一个或多个迭代过程吗

Yong CHEN 说:用简单条目化的文字把PK中发现的问题记录下来，发送给大家。

Li: 重构经常作为Backlog的一项做。

Susan：是PO在做，他任何时候都可以碰Product Backlog，每个迭代需求都在变多。

说说重构。重构是个很危险的工作，如果用敏捷，一定要有一个高级的设计人员，否则以后全重构了。

北京-QM-李晋James Li 说:是啊。另外重构的point也很难估算。

Yong CHEN 说:所以敏捷原则中有一个，就是要有优秀的设计。

xiyeqing99@hotmail.com 说:重构是个很危险的工作？怎么会呢

北京-QM-李晋James Li 说:还有Springt0与其他sprintx有啥区别

Yong CHEN 说:恩，Point不好算，当然重构的任务多了，可以参考以前的。

Xiyeqing:因为有些代码编的很烂，不好改动。

北京-QM-李晋James Li 说:好像sprint0就是专门确定架构的。

谷雨霖 说:重构必须要系统级的工程师才能碰，特别是对产品开发

S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:msn抽风？

Yong CHEN 说:Sprint0常常指那个做整体计划的Sprint

xiyeqing99@hotmail.com 说:是呀 我就是看的重构这本书,觉得越是烂的代码才越是要重构,否则以后完全没法维护的,等于要重新写一个,所以我现在review他们代码的时候 写的烂的我都要他们改掉的

Yong CHEN 说:其实很少有公司实行纯粹的迭代开发，那系统架构肯定崩溃。还是要有一系列的Sprint0（而不是1次！）来重新整理一下思路。

北京-QM-李晋James Li 说:哦？这个思路挺好的。

谷雨霖 说:时间差不多了，陈老师，你看延长到13：50？别太多打扰了

Yong CHEN 说:012340123401234，这样规划，当然不一定是四次。恩，重构是必需的，但是“避免重构”也是必需的。高手写的代码，即使需求变化了，也不太需要改动太多。新手的能气死，只能重写。要在计划时就发现这一点，每天做代码评审，而非最后发现不好才重构。

xiyeqing99@hotmail.com 说:恩

Yong CHEN 说:好的，我这边还有个PPT晚上要交工，呵呵。

xiyeqing99@hotmail.com 说:重构确实需要一次一小步的,一旦都写完了 已经好久了 往往没人肯再花时间去重构了

Yong CHEN 说:我们公司也在用Scrum，但是我们每半年左右就有一次Release，集中消除BUG，确定下一步方向，等等。是。

xiyeqing99@hotmail.com 说:是。 是回答了哪个问题？

Yong CHEN 说:Xiyeqing:我03年半天进行一次代码审查，中午就的看看大家的代码，免得晚上集成不了抓瞎。回答你的“往往没人肯……”

xiyeqing99@hotmail.com 说:啊。。。半天就进行一次代码审查乐了啊,那频率很高了哦,呵呵 看来你是个很认真负责的pm啊

Yong CHEN 说:总归有站起来走走的时间，就去看看别人的代码，非正式的。

xiyeqing99@hotmail.com 说:怪不得混的这么好啊 呵呵

Yong CHEN 说:每人每天写100行左右C++，半天50行，2屏幕多点。5分钟看完。

xiyeqing99@hotmail.com 说:他们知道你一直要看 肯定没人敢偷懒 现在我就发现很多人喜欢偷懒 不管了 他就不帮你做东西

Yong CHEN 说:偷懒不好，到老了就后悔了。

xiyeqing99@hotmail.com 说:呵呵 其实他们不肯做工作 想学点别的

Yong CHEN 说:好，基本结束。还有什么集中的问题没有？

dearChloe-PM-深圳 说:学啥？

xiyeqing99@hotmail.com 说:但是上班时间不可能一直让你看别的啊

chinamath(海茶)-Sr.SE-北京 说:谢谢陈老师，今天讲的非常好！

xiyeqing99@hotmail.com 说:他们自己看书

谷雨霖 说:好了

Yong CHEN 说:看代码别太认真，看全局不看细节。差代码全体换成*我也能看出是坏代码。

xiyeqing99@hotmail.com 说:(F)

谷雨霖 说:非常感谢陈老师的介绍，非常生动易懂。

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》