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

转自 http://blog.csdn.net/cheny_com/article/details/6694222

这是敏捷生态系统系列的第五篇（之一，之二，之三，之四，之五）。

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

删除了部分无关的对话。

文章末尾有谷雨霖老师的博客地址，也在CSDN。

 

“敏捷生态--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-湖北 说:
鼓掌
[e-mail] 说:
(Y)
谷雨霖 说:
余下时间，提问交流
[e-mail]改签名
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/r?msnshell-download-6zt818.hi5i.cn%2Fmsnshell) 以提升聊天信息的安全性，防止来自网络的偷窥行为 ---
Yong CHEN 说:
他们的限制主要在于：
1. 团队内部有相当明确的分工，大家看到需求就知道是谁的
2. 一直是项目经理说了算
当然既然要敏捷，那么2是一定要破除的，一定要让大家自己估算自己的任务，这样才能实现承诺，进而激励工作效率
但是1我当时就想将就一下，毕竟长期而言人们的专业分工已经很难破除了
培训之后他们就用上Scrum了，过了2个多月，他们进行了两轮迭代，我满怀希望地前去做二次指导
结果发现：他们开计划会议的时候，几乎同时只有1个人在做自己的估算，别人都在聊天，直到换任务（负责人也相应地换了）
这里就出现了一个问题。我们互动一下，谁知道这种“自己估算自己的任务”的方式有什么不好的地方？
M群-项目管理 说:
【系统提示】[e-mail]将昵称更改为trriger-SQA-上海
北京-QM-李晋James Li 说:
没啥不好啊。
susan-pm-湖北 说:
缺少和其他成员之间的沟通？
北京-QM-李晋James Li 说:
自己估算，自己最熟悉自己能完成多少东西。
谷雨霖 说:
先听
Yong CHEN 说:
比项目经理或更高的领导直接指定时间，显然有其优越性。
谷雨霖 说:
不要打断
[e-mail] 说:
“自己估算自己的任务”，成员往往多估计
Yong CHEN 说:
呵呵我就是想互动一下，大家插两句
打断正常
谷雨霖 说:
ok;)
依照过去打断很难收回的，哈哈
Yong CHEN 说:
1. 缺少沟通 2. 往往多估
哈没事，我来控制。
[e-mail] 说:
我认为还是互动比较好，老谷来控制
Yong CHEN 说:
为什么会多估呢……
litao 说:
也有可能为了冒进少估把
[e-mail] 说:
没有共识，成员不能看到全面，有时也会少估计
北京-QM-李晋James Li 说:
能否delphi一下
Yong CHEN 说:
当然有很多原因：怕完不成；怕忙（偷懒）
北京-QM-李晋James Li 说:
说明一下估算的原因？
Yong CHEN 说:
恩，这样很多问题就冒出来了，我们可以看到：敏捷要求团队尽量弥合分工，尝试一起做估算。
[e-mail] 说:
多估：主要是想骗PM
少估：主要是不全面
Yong CHEN 说:
好的，剩下的问题：为何要估算？
简单的原因是：需要一个数字，知道多少天多久
dearChloe-PM-深圳 说:
排计划呀
[e-mail] 说:
pm这么好糊弄啊
Yong CHEN 说:
复杂的原因可以分为两种：R问题和D问题
[e-mail] 说:
虽然不好，但是他们还是想这么做
北京-QM-李晋James Li 说:
我们的主要问题是怎么估
story point
Yong CHEN 说:
一个PM或高级领导是容易糊弄的，下面我们马上会发现有一些人是不能糊弄的：同行，队员，伙伴
[e-mail] 说:
做WBS，评价自己多年的经验
Yong CHEN 说:
这是敏捷计划的精髓。Scrum计划尝试解决R问题和D问题
[e-mail] 说:
在影响整体进度的情况下，参考一下 资深 成员
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 说:
对啊
[e-mail] 说:
这方法好？
(R)(L)China_Iverson(R)(L) 说:
就像评委打分一样？
[e-mail] 说:
Yong CHEN大哥 怎么被你想到的啊
Yong CHEN 说:
这其实就是Delphi的变形，Delphi也是匿名的，但是太慢了。
晕，不是我想到的
谷雨霖 说:
对 delphi增强版
[e-mail] 说:
哪位牛人想出来的啊
这么好的主意
Yong CHEN 说:
http://z.xiaoi.com/r?www.planningpoker.com%2F
[e-mail] 说:
哈哈
Yong CHEN 说:
老外想到的
敏捷生态是我想到的
[e-mail] 说:
老外确实有2把刷子啊
你也有几把刷子 呵呵
litao 说:
不过还是有问题的,如果时间长了大家都可能在自己的基础上面高估的
谷雨霖 说:
继续说生态，没深入说这个理念
Yong CHEN 说:
对了我们公司要印刷敏捷扑克了，等15天就出来。谁要，给我发邮件，写个快递地址
谷雨霖 说:
怎么叫全生态
Yong CHEN 说:
[e-mail]
[e-mail] 说:
我要
Yong CHEN 说:
写邮件
(R)(L)China_Iverson(R)(L) 说:
我也要
Yong CHEN 说:
好，全生态很复杂，但是局部生态是存在的。
比如Scrum在国外其实比XP热很多，原因就是他的生态系统相对简单，比较容易建立起来。
[e-mail] 说:
恩 Scrum确实简单点
Yong CHEN 说:
我已经画好了Scrum生态图，回头发给大家。
[e-mail] 说:
上次买了本xp的书 看了一页就看不下去了
Yong CHEN 说:
如果大家用了Scrum，但感觉有件事情怎么也没做好，就看看与之相连接的生物是否有纰漏。
[e-mail] 说:
哦
Yong CHEN 说:
但XP的生态相对复杂，关键需要一些技术方法 。
比如你想TDD和持续集成，就需要一些自动化测试工具的支持。
如果老板说：太复杂了或太贵了别买了，你先用用别的条目吧……结果生态系统就被破坏了
chinamath(海茶)-Sr.SE-北京 说:
敏捷扑克太好了，请陈老师留个邮件地址。
Yong CHEN 说:
[e-mail] 
chinamath(海茶)-Sr.SE-北京 说:
OK，谢谢！
[e-mail] 说:
怎么给你钱
Yong CHEN 说:
公司市场部给我钱，呵呵。免费的。
参加敏捷大会的人手一个。
[e-mail] 说:
但是我不在北京，不能参加，
Yong CHEN 说:
好了回到生态系统：由于Scrum只涉及需求管理/计划/跟踪（比CMMI对应内容少），所以存在整体部署的可能。如果要用Scrum，一定要用全！
[e-mail] 说:
外地，你们帮忙邮寄吗
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-湖北 说:
欢迎
[e-mail] 说:
(F)
谷雨霖 说:
陈老师，你今天讲了敏捷，非常打动我。让我第一次有了推行敏捷的冲动
[e-mail] 说:
哈哈
陈老师的msn多少啊
litao 说:
陈老师,我还有问题,如何判断所有扣牌的人都高估呢?
[e-mail] 说:
敏捷，英文是什么？
AlexQin(21)-QC-深圳 说:
Agile
susan-pm-湖北 说:
agile?
[e-mail] 说:
对
[e-mail] 说:
谢谢，忘了怎么拼了
Yong CHEN 说:
哈哈以前你没有推动敏捷的冲动啊，呵呵。
AlexQin(21)-QC-深圳 说:
呵呵
chinamath(海茶)-Sr.SE-北京 说:
实际一般怎么PK？能再讲点细节吗？
Yong CHEN 说:
哦，PO有权利挑战大家的结果，如果他感觉太高或者太低。
谷雨霖 说:
有冲动，但在全公司推行有阻力和顾虑
Yong CHEN 说:
所以可以防止整体高估或者低估。
[e-mail] 说:
可以拿项目做示范
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
[e-mail] 说:
开会讨论前，让所有成员都自己准备一下，注意一定要后分工，不要讨论前分配工作，不然他们就只管自己的估算了
北京-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 说:
所以敏捷原则中有一个，就是要有优秀的设计。
[e-mail] 说:
重构是个很危险的工作？
怎么会呢
北京-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
[e-mail] 说:
是呀 我就是看的重构这本书
觉得越是烂的代码才越是要重构
否则以后完全没法维护的
等于要重新写一个
所以我现在review他们代码的时候 写的烂的我都要他们改掉的
Yong CHEN 说:
其实很少有公司实行纯粹的迭代开发，那系统架构肯定崩溃。还是要有一系列的Sprint0（而不是1次！）来重新整理一下思路。
北京-QM-李晋James Li 说:
哦？这个思路挺好的。
谷雨霖 说:
时间差不多了，陈老师，你看延长到13：50？别太多打扰了
Yong CHEN 说:
012340123401234，这样规划，当然不一定是四次。
恩，重构是必需的，但是“避免重构”也是必需的。高手写的代码，即使需求变化了，也不太需要改动太多。
新手的能气死，只能重写。要在计划时就发现这一点，每天做代码评审，而非最后发现不好才重构。
[e-mail] 说:
恩
Yong CHEN 说:
好的，我这边还有个PPT晚上要交工，呵呵。
[e-mail] 说:
重构确实需要一次一小步的
一旦都写完了 已经好久了 往往没人肯再花时间去重构了
Yong CHEN 说:
我们公司也在用Scrum，但是我们每半年左右就有一次Release，集中消除BUG，确定下一步方向，等等。
是。
[e-mail] 说:
是。 是回答了哪个问题？
Yong CHEN 说:
Xiyeqing:我03年半天进行一次代码审查，中午就的看看大家的代码，免得晚上集成不了抓瞎。
回答你的“往往没人肯……”
[e-mail] 说:
啊。。。半天就进行一次代码审查乐了啊
那频率很高了哦
呵呵 看来你是个很认真负责的pm啊
Yong CHEN 说:
总归有站起来走走的时间，就去看看别人的代码，非正式的。
[e-mail] 说:
怪不得混的这么好啊
呵呵
Yong CHEN 说:
每人每天写100行左右C++，半天50行，2屏幕多点。5分钟看完。
[e-mail] 说:
他们知道你一直要看 肯定没人敢偷懒
现在我就发现很多人喜欢偷懒
不管了 他就不帮你做东西
Yong CHEN 说:
偷懒不好，到老了就后悔了。
[e-mail] 说:
呵呵
其实他们不肯做工作 想学点别的
Yong CHEN 说:
好，基本结束。还有什么集中的问题没有？
dearChloe-PM-深圳 说:
　学啥？
[e-mail] 说:
但是上班时间不可能一直让你看别的啊
chinamath(海茶)-Sr.SE-北京 说:
谢谢陈老师，今天讲的非常好！
[e-mail] 说:
他们自己看书
谷雨霖 说:
好了
Yong CHEN 说:
看代码别太认真，看全局不看细节。差代码全体换成*我也能看出是坏代码。
[e-mail] 说:
(F)
谷雨霖 说:
非常感谢陈老师的介绍，非常生动易懂。

谷雨霖老师的地址：http://blog.csdn.net/cabinhome