本文是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-湖北 说:
鼓掌
[email protected] 说:
(Y)
谷雨霖 说:
余下时间,提问交流
[email protected]改签名
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群-项目管理 说:
【系统提示】 [email protected]将昵称更改为trriger-SQA-上海
北京-QM-李晋James Li 说:
没啥不好啊。
susan-pm-湖北 说:
缺少和其他成员之间的沟通?
北京-QM-李晋James Li 说:
自己估算,自己最熟悉自己能完成多少东西。
谷雨霖 说:
先听
Yong CHEN 说:
比项目经理或更高的领导直接指定时间,显然有其优越性。
谷雨霖 说:
不要打断
[email protected] 说:
“自己估算自己的任务”,成员往往多估计
Yong CHEN 说:
呵呵我就是想互动一下,大家插两句
打断正常
谷雨霖 说:
ok;)
依照过去打断很难收回的,哈哈
Yong CHEN 说:
1. 缺少沟通 2. 往往多估
哈没事,我来控制。
[email protected] 说:
我认为还是互动比较好,老谷来控制
Yong CHEN 说:
为什么会多估呢……
litao 说:
也有可能为了冒进少估把
[email protected] 说:
没有共识,成员不能看到全面,有时也会少估计
北京-QM-李晋James Li 说:
能否delphi一下
Yong CHEN 说:
当然有很多原因:怕完不成;怕忙(偷懒)
北京-QM-李晋James Li 说:
说明一下估算的原因?
Yong CHEN 说:
恩,这样很多问题就冒出来了,我们可以看到:敏捷要求团队尽量弥合分工,尝试一起做估算。
[email protected] 说:
多估:主要是想骗PM
少估:主要是不全面
Yong CHEN 说:
好的,剩下的问题:为何要估算?
简单的原因是:需要一个数字,知道多少天多久
dearChloe-PM-深圳 说:
排计划呀
[email protected] 说:
pm这么好糊弄啊
Yong CHEN 说:
复杂的原因可以分为两种:R问题和D问题
[email protected] 说:
虽然不好,但是他们还是想这么做
北京-QM-李晋James Li 说:
我们的主要问题是怎么估
story point
Yong CHEN 说:
一个PM或高级领导是容易糊弄的,下面我们马上会发现有一些人是不能糊弄的:同行,队员,伙伴
[email protected] 说:
做WBS,评价自己多年的经验
Yong CHEN 说:
这是敏捷计划的精髓。Scrum计划尝试解决R问题和D问题
[email protected] 说:
在影响整体进度的情况下,参考一下 资深 成员
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 说:
对啊
[email protected] 说:
这方法好?
(R)(L)China_Iverson(R)(L) 说:
就像评委打分一样?
[email protected] 说:
Yong CHEN大哥 怎么被你想到的啊
Yong CHEN 说:
这其实就是Delphi的变形,Delphi也是匿名的,但是太慢了。
晕,不是我想到的
谷雨霖 说:
对 delphi增强版
[email protected] 说:
哪位牛人想出来的啊
这么好的主意
Yong CHEN 说:
http://z.xiaoi.com/r?www.planningpoker.com%2F
[email protected] 说:
哈哈
Yong CHEN 说:
老外想到的
敏捷生态是我想到的
[email protected] 说:
老外确实有2把刷子啊
你也有几把刷子 呵呵
litao 说:
不过还是有问题的,如果时间长了大家都可能在自己的基础上面高估的
谷雨霖 说:
继续说生态,没深入说这个理念
Yong CHEN 说:
对了我们公司要印刷敏捷扑克了,等15天就出来。谁要,给我发邮件,写个快递地址
谷雨霖 说:
怎么叫全生态
Yong CHEN 说:
[email protected]
[email protected] 说:
我要
Yong CHEN 说:
写邮件
(R)(L)China_Iverson(R)(L) 说:
我也要
Yong CHEN 说:
好,全生态很复杂,但是局部生态是存在的。
比如Scrum在国外其实比XP热很多,原因就是他的生态系统相对简单,比较容易建立起来。
[email protected] 说:
恩 Scrum确实简单点
Yong CHEN 说:
我已经画好了Scrum生态图,回头发给大家。
[email protected] 说:
上次买了本xp的书 看了一页就看不下去了
Yong CHEN 说:
如果大家用了Scrum,但感觉有件事情怎么也没做好,就看看与之相连接的生物是否有纰漏。
[email protected] 说:

Yong CHEN 说:
但XP的生态相对复杂,关键需要一些技术方法 。
比如你想TDD和持续集成,就需要一些自动化测试工具的支持。
如果老板说:太复杂了或太贵了别买了,你先用用别的条目吧……结果生态系统就被破坏了
chinamath(海茶)-Sr.SE-北京 说:
敏捷扑克太好了,请陈老师留个邮件地址。
Yong CHEN 说:
[email protected]
chinamath(海茶)-Sr.SE-北京 说:
OK,谢谢!
[email protected] 说:
怎么给你钱
Yong CHEN 说:
公司市场部给我钱,呵呵。免费的。
参加敏捷大会的人手一个。
[email protected] 说:
但是我不在北京,不能参加,
Yong CHEN 说:
好了回到生态系统:由于Scrum只涉及需求管理/计划/跟踪(比CMMI对应内容少),所以存在整体部署的可能。如果要用Scrum,一定要用全!
[email protected] 说:
外地,你们帮忙邮寄吗
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-湖北 说:
欢迎
[email protected] 说:
(F)
谷雨霖 说:
陈老师,你今天讲了敏捷,非常打动我。让我第一次有了推行敏捷的冲动
[email protected] 说:
哈哈
陈老师的msn多少啊
litao 说:
陈老师,我还有问题,如何判断所有扣牌的人都高估呢?
[email protected] 说:
敏捷,英文是什么?
AlexQin(21)-QC-深圳 说:
Agile
susan-pm-湖北 说:
agile?
[email protected] 说:

[email protected] 说:
谢谢,忘了怎么拼了
Yong CHEN 说:
哈哈以前你没有推动敏捷的冲动啊,呵呵。
AlexQin(21)-QC-深圳 说:
呵呵
chinamath(海茶)-Sr.SE-北京 说:
实际一般怎么PK?能再讲点细节吗?
Yong CHEN 说:
哦,PO有权利挑战大家的结果,如果他感觉太高或者太低。
谷雨霖 说:
有冲动,但在全公司推行有阻力和顾虑
Yong CHEN 说:
所以可以防止整体高估或者低估。
[email protected] 说:
可以拿项目做示范
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
[email protected] 说:
开会讨论前,让所有成员都自己准备一下,注意一定要后分工,不要讨论前分配工作,不然他们就只管自己的估算了
北京-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 说:
所以敏捷原则中有一个,就是要有优秀的设计。
[email protected] 说:
重构是个很危险的工作?
怎么会呢
北京-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
[email protected] 说:
是呀 我就是看的重构这本书
觉得越是烂的代码才越是要重构
否则以后完全没法维护的
等于要重新写一个
所以我现在review他们代码的时候 写的烂的我都要他们改掉的
Yong CHEN 说:
其实很少有公司实行纯粹的迭×××发,那系统架构肯定崩溃。还是要有一系列的Sprint0(而不是1次!)来重新整理一下思路。
北京-QM-李晋James Li 说:
哦?这个思路挺好的。
谷雨霖 说:
时间差不多了,陈老师,你看延长到13:50?别太多打扰了
Yong CHEN 说:
012340123401234,这样规划,当然不一定是四次。
恩,重构是必需的,但是“避免重构”也是必需的。高手写的代码,即使需求变化了,也不太需要改动太多。
新手的能气死,只能重写。要在计划时就发现这一点,每天做代码评审,而非最后发现不好才重构。
[email protected] 说:

Yong CHEN 说:
好的,我这边还有个PPT晚上要交工,呵呵。
[email protected] 说:
重构确实需要一次一小步的
一旦都写完了 已经好久了 往往没人肯再花时间去重构了
Yong CHEN 说:
我们公司也在用Scrum,但是我们每半年左右就有一次Release,集中消除BUG,确定下一步方向,等等。
是。
[email protected] 说:
是。 是回答了哪个问题?
Yong CHEN 说:
Xiyeqing:我03年半天进行一次代码审查,中午就的看看大家的代码,免得晚上集成不了抓瞎。
回答你的“往往没人肯……”
[email protected] 说:
啊。。。半天就进行一次代码审查乐了啊
那频率很高了哦
呵呵 看来你是个很认真负责的pm啊
Yong CHEN 说:
总归有站起来走走的时间,就去看看别人的代码,非正式的。
[email protected] 说:
怪不得混的这么好啊
呵呵
Yong CHEN 说:
每人每天写100行左右C++,半天50行,2屏幕多点。5分钟看完。
[email protected] 说:
他们知道你一直要看 肯定没人敢偷懒
现在我就发现很多人喜欢偷懒
不管了 他就不帮你做东西
Yong CHEN 说:
偷懒不好,到老了就后悔了。
[email protected] 说:
呵呵
其实他们不肯做工作 想学点别的
Yong CHEN 说:
好,基本结束。还有什么集中的问题没有?
dearChloe-PM-深圳 说:
学啥?
[email protected] 说:
但是上班时间不可能一直让你看别的啊
chinamath(海茶)-Sr.SE-北京 说:
谢谢陈老师,今天讲的非常好!
[email protected] 说:
他们自己看书
谷雨霖 说:
好了
Yong CHEN 说:
看代码别太认真,看全局不看细节。差代码全体换成*我也能看出是坏代码。
[email protected] 说:
(F)
谷雨霖 说:
非常感谢陈老师的介绍,非常生动易懂。
 

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