【原创】2009年8月25日老谷"项目管理MSN群"专题—敏捷生态

  12:29:29: 今天我们的主题是“敏捷生态”
  12:29:45: 有幸请到的是我的老朋友,敏捷专家陈勇先生
  12:29:46: 【系统提示】AlexQin将昵称更改为AlexQin-QC-深圳
  12:29:57: [不胜人生一场醉-N/A-海南] 鼓 掌
  12:29:59: [dearChloe-PM-深圳] 专家好
  12:29:59: [Yong CHEN] 大家好
  12:30:00: 【系统提示】cui将昵称更改为cui6548_pl_shanghai
  12:30:08: 陈勇先生在9.12的敏捷中国大会有专题发言
  12:30:13: 他的介绍:
  12:30:15: TechExcel中国区咨询总监,具有13年软件研发、管理和咨询的从业经验,拥有多年敏捷开发、CMMI、度量与基准比对等多种软件过程管理咨询和培训经验。他结合企业中大规模团队的管理需求,成功导入并实施了面向100人左右大团队的最佳研发管理实践,融合了敏捷开发实践和CMMI体系。其以敏捷开发为主要内容提供过咨询/培训/专题演讲的企业包括Thomson CR / 广州从兴 / 金山软件 / 盛大网络等企业。他还在2007/2008年度中国过程改进大会及2009年中国软件技术大会上进行了《敏捷开发中的度量》、《从交付保证看敏捷开发的价值》等敏捷主题演讲。
  12:30:17: [kursk200(一点红)-PM-上海] 陈老师好
  12:30:34: [Yong CHEN] 我是昨天刚来的,很高兴认识大家。
  12:30:54: [Yong CHEN] 现在就正式开始了
  12:30:58: 下面,我把时间交给陈老师。13:00听陈老师讲述
  12:31:03: [susan-pm-湖北] 鼓掌
  12:31:04: [[email protected]] (Y)
  12:31:06: 余下时间,提问交流
  12:31:25: [email protected]改签名
  12:31:28: [Yong CHEN] 关于敏捷生态,是去年逐渐意识到的一个问题。
  12:31:32: 【系统提示】AlexQin-QC-深圳将昵称更改为AlexQin(21)-QC-深圳
  12:31:59: [Yong CHEN] 在做CMMI咨询的时候,一直希望能把CMMI一点一点实施下去,而非一次到位。
  12:32:18: [Yong CHEN] 这样对企业的压力小,还能用已经取得的成就,去鼓舞和支持剩下的工作。
  12:32:39: [Yong CHEN] 但是一直没有成功,因为大家也知道,国内做CMMi都是阶段式的,直接一级
  12:33:12: [Yong CHEN] 完全没有做连续式的,也就是说重点做某些价值最高的过程域,以后再说其他的。
  12:33:35: [Yong CHEN] 但在国外,基本上则是一半一半。当然原因也很明显:政府给的补助,是针对阶段式的。
  12:34:00: [Yong CHEN] 所以后来逐渐转向敏捷以后,也是很想在新的领域引入连续式
  12:34:23: [Yong CHEN] 在一家南方的公司咨询的时候,我发现他们有诸多的限制,无法整体实现敏捷。
  12:34:53: [Yong CHEN] 对了备注一下:这里指的敏捷是Scrum,也就是偏管理的分支,重点内容是需求管理/项目计划/项目跟踪
  12:34:55: [北京-QM-李晋James Li] 兄弟们,我刚才死机了。
  12:35:01: [chinamath(海茶)-Sr.SE-北京] 报到
  12:35:10: 【系统提示】镜子将昵称更改为镜子-教师-广州
  12:35:27: [Yong CHEN] 大家比较熟悉的TDD/结对编程/重构等属于关注技术的XP分支
  12:35:33: [TonyAquarian_IT Consulting_北京] --- 系统提示: 您的联系人 aquarian - 庸人自扰已使用MSNShell 提供的加密对话功能,该功能需要双方都安装MSNShell(   http://z.xiaoi.com/r?msnshell-download-6zt818.hi5i.cn%2Fmsnshell)  以提升聊天信息的安全性,防止来自网络的偷窥行为 ---
  12:35:38: [Yong CHEN] 他们的限制主要在于:
  12:36:06: [Yong CHEN] 1. 团队内部有相当明确的分工,大家看到需求就知道是谁的
  12:36:16: [Yong CHEN] 2. 一直是项目经理说了算
  12:37:02: [Yong CHEN] 当然既然要敏捷,那么2是一定要破除的,一定要让大家自己估算自己的任务,这样才能实现承诺,进而激励工作效率
  12:37:25: [Yong CHEN] 但是1我当时就想将就一下,毕竟长期而言人们的专业分工已经很难破除了
  12:38:25: [Yong CHEN] 培训之后他们就用上Scrum了,过了2个多月,他们进行了两轮迭代,我满怀希望地前去做二次指导
  12:39:10: [Yong CHEN] 结果发现:他们开计划会议的时候,几乎同时只有1个人在做自己的估算,别人都在聊天,直到换任务(负责人也相应地换了)
  12:39:55: [Yong CHEN] 这里就出现了一个问题。我们互动一下,谁知道这种“自己估算自己的任务”的方式有什么不好的地方?
  12:40:00: 【系统提示】[email protected]将昵称更改为trriger-SQA-上海
  12:40:21: [北京-QM-李晋James Li] 没啥不好啊。
  12:40:28: [susan-pm-湖北] 缺少和其他成员之间的沟通?
  12:40:33: 先听
  12:40:33: [北京-QM-李晋James Li] 自己估算,自己最熟悉自己能完成多少东西。
  12:40:41: [Yong CHEN] 比项目经理或更高的领导直接指定时间,显然有其优越性。
  12:40:43: 不要打断
  12:40:59: [[email protected]] “自己估算自己的任务”,成员往往多估计
  12:41:08: [Yong CHEN] 呵呵我就是想互动一下,大家插两句
  12:41:15: [Yong CHEN] 打断正常
  12:41:16: ok;)
  12:41:29: 依照过去打断很难收回的,哈哈
  12:41:42: [Yong CHEN] 1. 缺少沟通 2. 往往多估
  12:41:50: [Yong CHEN] 哈没事,我来控制。
  12:41:53: [[email protected]] 我认为还是互动比较好,老谷来控制
  12:42:01: [Yong CHEN] 为什么会多估呢……
  12:42:20: [kursk200(一点红)-PM-上海] 也有可能为了冒进少估把
  12:42:21: [[email protected]] 没有共识,成员不能看到全面,有时也会少估计
  12:42:22: [北京-QM-李晋James Li] 能否delphi一下
  12:42:23: [Yong CHEN] 当然有很多原因:怕完不成;怕忙(偷懒)
  12:42:30: [北京-QM-李晋James Li] 说明一下估算的原因?
  12:43:05: [Yong CHEN] 恩,这样很多问题就冒出来了,我们可以看到:敏捷要求团队尽量弥合分工,尝试一起做估算。
  12:43:05: [[email protected]] 多估:主要是想骗PM
少估:主要是不全面
  12:43:15: [Yong CHEN] 好的,剩下的问题:为何要估算?
  12:43:26: [Yong CHEN] 简单的原因是:需要一个数字,知道多少天多久
  12:43:27: [dearChloe-PM-深圳] 排计划呀
  12:43:31: [[email protected]] pm这么好糊弄啊
  12:43:49: [Yong CHEN] 复杂的原因可以分为两种:R问题和D问题
  12:43:50: [[email protected]] 虽然不好,但是他们还是想这么做
  12:43:58: [北京-QM-李晋James Li] 我们的主要问题是怎么估
  12:44:11: [北京-QM-李晋James Li] story point
  12:44:30: [Yong CHEN] 一个PM或高级领导是容易糊弄的,下面我们马上会发现有一些人是不能糊弄的:同行,队员,伙伴
  12:44:33: [[email protected]] 做WBS,评价自己多年的经验
  12:45:02: [Yong CHEN] 这是敏捷计划的精髓。Scrum计划尝试解决R问题和D问题
  12:45:22: [[email protected]] 在影响整体进度的情况下,参考一下 资深 成员
  12:45:26: [Yong CHEN] 所谓R问题就是:这个需求说的是什么?实现到何种程度?标准如何?0缺陷吗?等等
  12:45:37: [Yong CHEN] 这个是需求问题
  12:46:03: [Yong CHEN] 在Scrum计划会议的上半截,Product Owner要给大家统一讲解需求,有问题的人随时提问。
  12:46:35: [Yong CHEN] 剩下的事情是:谁会有问题?当然是任务的负责人。而我这个客户由于前面说的原因,提问的人就一个人
  12:46:54: [Yong CHEN] 自然也只有他彻底明白了任务的需求,而其他人事不关己,高高挂起。
  12:47:45: [Yong CHEN] 有时其他人也听到了一些有有疑惑的东西,但既然负责人都说明白了,我还要问什么呢……也就不问了,就埋下了隐患
  12:48:44: [Yong CHEN] 计划的第二个问题,是D问题(设计问题):这个需求用什么方法实现最好?有没有现成的代码可以复用?完全复用,还是需要改动一下,还是改动也没用因为留有后遗症?
  12:48:58: [Yong CHEN] 很可惜,D问题不是那么好解决的。
  12:49:24: [Yong CHEN] 比如如果我是一个高手,来了一个新手,我想知道他怎样实现“排行榜”功能,怎么办?
  12:49:44: [Yong CHEN] 当然我可以让他说说他打算干什么,可惜程序员都不擅长言谈:D
  12:49:45: 【群内动态】 谷雨霖 在 2009/08/25 12:49 发了一个新帖 "老谷'项目管理MSN群'专题讨间:每周二中午12:30(8月25日敏捷生态)". 点击以下链接查看: (accept)http://g.xiaoi.com/a/fys5r8nerWf4ec
  12:50:02: [Yong CHEN] 计划会议上也难以让他把整个实现思路讲一遍
  12:50:26: [Yong CHEN] 这时候,就需要用别的方法了,那就是“CRC32”校验
  12:50:40: [Yong CHEN] 不知道大家了解CRC32校验不
  12:50:57: [dearChloe-PM-深圳] 不了解
  12:51:18: [Yong CHEN] 要想了解一个文件(或某短信息)是否是完整无损的,最简单的方法是把文件存两份(或发送两份),比较一下有无差别。
  12:51:20: [(R)(L)China_Iverson(R)(L)] 程序员都不擅长言谈?至少能说清楚吧
  12:51:40: [Yong CHEN] 但这样实在太费空间时间了,所以科学家们发明了一种方法:
  12:52:11: [Yong CHEN] 先说个简单的:就是把文件所有字节加起来(溢出超过256的不要了),把这个校验和放在末尾。
  12:52:33: [Yong CHEN] 收到文件后,重新计算一下文件的校验和,如果一样,“多半”表明没有错误。
  12:52:49: [Yong CHEN] CRC32比校验和厉害一些,但原理相同。
  12:53:06: [Yong CHEN] 估算就是这个目的!
  12:53:42: [Yong CHEN] 03年我做项目经理的时候就是这样
  12:53:58: [Yong CHEN] 每天早上20分钟给大家讲讲需求和设计,然后挨个问一个问题:
  12:54:09: [Yong CHEN] 你今天听了需求和设计,打算写多少代码?
  12:54:22: [Yong CHEN] 他们就用手比划:2个屏幕,还是5个屏幕
  12:54:49: [Yong CHEN] 如果我感觉和我想的差不多,就过;如果差别很大,就问问屏幕里边有什么
  12:55:28: [Yong CHEN] 用这种方法,只要几秒钟,就能对上暗号,“多半”他没有听错想错,也不会做错。
  12:55:41: [Yong CHEN] 说的太多了,有没有说的不清楚的地方?
  12:55:47: [chinamath(海茶)-Sr.SE-北京] 这个方法好。
  12:55:52: [dearChloe-PM-深圳] 恩
  12:56:28: [Yong CHEN] 当年也是个编程高手,我说说曾经“杀代码”的经历,大家就知道估算的重要性了
  12:56:56: [Yong CHEN] 01年,110行杀到50,第一次杀,上瘾了
  12:57:19: [Yong CHEN] 还是01年,4000行杀到400行
  12:57:42: [Yong CHEN] 02年,4000行杀到50行(那个程序员干了一个月了,一个下午被杀到50行)
  12:58:03: [Yong CHEN] 04年,别人杀代码的记录:10万行杀到1.3万
  12:58:42: [Yong CHEN] 在4000杀50那次后,我在想:怎样让这个程序员干活之前,他的项目经理就知道他要做错事呢……(当时我是EPG的)
  12:59:17: [Yong CHEN] 所以在03年我又重新管理项目,实践出了上面那种方法。
  13:00:03: [Yong CHEN] 好了,R问题和D问题都解决了,剩下的是:刚才说过,任务都有一个负责人,别人怎么才能替他关心他的R和D问题呢?
  13:00:32: [Yong CHEN] 在那个客户那里,采取了两次步骤
  13:01:08: [Yong CHEN] 前几个迭代,小组长(手底下有3/4个人)和那个人一起打牌(计划扑克,不知道大家了解不?)
  13:01:16: [Yong CHEN] 我闪屏就是有问题啦,呵呵
  13:01:36: [Yong CHEN] 也就是让小组长和手下具体负责人一起计划
  13:02:03: [Yong CHEN] 后几个迭代:先把任务分配到小组(3/4个人)不指定具体负责人,先估算,再分配。
  13:02:38: [Yong CHEN] 这样大家不确定是否是自己的事情,不敢怠慢,都会用心得提问需求问题,用心地讨论实现方法
  13:02:52: [Yong CHEN] 讨论过程中很快发现,有些需求没有想到,有些方法是错误的
  13:03:24: [Yong CHEN] 比如有个程序员低估了任务,因为他说有个库拿过来就能用,另外一个程序员就告诉他:那个库很难用,自己试过,还不如重新写一个。等等。
  13:03:56: [Yong CHEN] 当然,大家用计划扑克的方法,如果大家数字相同,不会讨论直接通过,有人太多或者太少,才会讨论。
  13:04:07: [Yong CHEN] 这样大大节约了时间,又达到了目的。
  13:04:23: [Yong CHEN] 好了说了这么多,回到主题:敏捷生态
  13:05:06: [Yong CHEN] 通过刚才的例子,我们会发现敏捷这里就直接说Scrum把:是一个经过实践总结出来的方法
  13:05:45: [Yong CHEN] 他们当年也一定遇到过类似的问题,所以才说:尽量不分工,而是建立跨职能团队,“所有人干所有事”,才能取得良好的计划效果
  13:06:18: [Yong CHEN] 如果把跨职能团队去掉,仍然开计划会,仍然有PO,仍然让大家自己估算自己的任务,效果就很差了。
  13:06:43: [Yong CHEN] 这就如一个生态系统,各个部分是联动的,不能轻易去掉其中一个。
  13:07:50: [Yong CHEN] 哦对了解释一下另外一个问题:如果有3个人一起估算,这时候就会产生“同行压力”,没有人想证明自己是“笨蛋”,所以他们不会故意高估任务,因为自己的同事(技术背景/职位相同)在和自己一起估算
  13:08:12: [dearChloe-PM-深圳] 那怎么办呢?
  13:08:26: [Yong CHEN] 别人说2天能完,自己偏说4天,显然有问题。要知道这个工作还没有分配,未必是自己的工作。
  13:08:58: [Yong CHEN] 这种同行压力效果比领导压力好,因为领导不懂,很容易糊弄,呵呵。
  13:09:06: [Yong CHEN] 什么怎么办?如何对待生态系统?
  13:09:43: [dearChloe-PM-深圳] 我是说,因为同行压力,大家会不会都少估呢?
  13:10:01: [Yong CHEN] 了解了生态系统,就会知道:要上敏捷,尽量完整地接受敏捷,而不要卡在中间,效果不会很好的。
  13:10:14: 嗯
  13:10:16: [Yong CHEN] 不会的,无论高估还是低估,都要给大家解释原因。
  13:10:22: [dearChloe-PM-深圳] 恩
  13:10:36: [Yong CHEN] 敏捷中计划扑克的玩法是这样的:
  13:10:37: [(R)(L)China_Iverson(R)(L)] 我觉得应该不会少估吧,因为有可能是自己会开发的
  13:10:43: [Yong CHEN] 1. 讲解需求和提问,直到没有问题
  13:11:02: [Yong CHEN] 2. 几个人一起扣着出牌
  13:11:16: [Yong CHEN] 3. 翻牌,最多的和最少的PK,除非他们差别很小
  13:11:42: [Yong CHEN] 4. 大家听他们两位PK(一般一位会“占理”一些),回到2
  13:12:06: [Yong CHEN] 5. 中间有任何对需求的分歧,PO解释(有时候PO也解释不清楚,这个需求显然还太模糊)
  13:12:55: [Yong CHEN] 在这个过程里边,人们显然不愿意故意高估或低估(PK中很难给大家一个满意的答案的)
  13:13:08: [Yong CHEN] 而寻求真是结果的愿望会占据上风。
  13:13:14: [(R)(L)China_Iverson(R)(L)] 估算的时候是是不公开的吗?
  13:13:25: [(R)(L)China_Iverson(R)(L)] 就是说扣着牌的?
  13:13:33: [Yong CHEN] 对,先扣着出牌,然后一起亮牌
  13:13:53: [susan-pm-湖北] 是怕从众吗
  13:14:05: [Yong CHEN] 对啊
  13:14:06: [[email protected]] 这方法好?
  13:14:08: [(R)(L)China_Iverson(R)(L)] 就像评委打分一样?
  13:14:21: [[email protected]] Yong CHEN大哥 怎么被你想到的啊
  13:14:25: [Yong CHEN] 这其实就是Delphi的变形,Delphi也是匿名的,但是太慢了。
  13:14:31: [Yong CHEN] 晕,不是我想到的
  13:14:40: 对 delphi增强版
  13:14:42: [[email protected]] 哪位牛人想出来的啊
  13:14:47: [[email protected]] 这么好的主意
  13:14:48: [Yong CHEN] http://z.xiaoi.com/r?www.planningpoker.com%2F
  13:14:49: [[email protected]] 哈哈
  13:14:55: [Yong CHEN] 老外想到的
  13:15:09: [Yong CHEN] 敏捷生态是我想到的
  13:15:16: [[email protected]] 老外确实有2把刷子啊
  13:15:24: [[email protected]] 你也有几把刷子 呵呵
  13:15:32: [kursk200(一点红)-PM-上海] 不过还是有问题的,如果时间长了大家都可能在自己的基础上面高估的
  13:15:36: 继续说生态,没深入说这个理念
   13:15:47: 怎么叫全生态
  13:16:19: [Yong CHEN] 好,全生态很复杂,但是局部生态是存在的。
  13:16:43: [Yong CHEN] 比如Scrum在国外其实比XP热很多,原因就是他的生态系统相对简单,比较容易建立起来。
  13:17:00: [[email protected]] 恩 Scrum确实简单点
  13:17:05: [Yong CHEN] 我已经画好了Scrum生态图,回头发给大家。
  13:17:15: [[email protected]] 上次买了本xp的书 看了一页就看不下去了
  13:17:39: [Yong CHEN] 如果大家用了Scrum,但感觉有件事情怎么也没做好,就看看与之相连接的生物是否有纰漏。
  13:17:51: [[email protected]] 哦
  13:18:05: [Yong CHEN] 但XP的生态相对复杂,关键需要一些技术方法 。
  13:18:19: [Yong CHEN] 比如你想TDD和持续集成,就需要一些自动化测试工具的支持。
  13:18:45: [Yong CHEN] 如果老板说:太复杂了或太贵了别买了,你先用用别的条目吧……结果生态系统就被破坏了
  13:20:09: [Yong CHEN] 参加敏捷大会的人手一个。
  13:21:09: [Yong CHEN] 好了回到生态系统:由于Scrum只涉及需求管理/计划/跟踪(比CMMI对应内容少),所以存在整体部署的可能。如果要用Scrum,一定要用全!
  13:22:17: [Yong CHEN] 会上我会用3~4个例子更详细地解释敏捷生态系统,但这里太慢了就不多说了:D
  13:22:27: [dearChloe-PM-深圳] 哎,可惜
  13:23:03: [Yong CHEN] 回头大会或许有录像。
  13:23:03: [Yong CHEN] 刚才是其中一个例子。
  13:24:04: [susan-pm-湖北] 欢迎
  13:24:25: 陈老师,你今天讲了敏捷,非常打动我。让我第一次有了推行敏捷的冲动
  13:25:01: [kursk200(一点红)-PM-上海] 陈老师,我还有问题,如何判断所有扣牌的人都高估呢?
  13:25:15: [[email protected]] 敏捷,英文是什么?
  13:25:24: [AlexQin(21)-QC-深圳] Agile
  13:25:30: [susan-pm-湖北] agile?
  13:25:44: [[email protected]] 对
  13:25:55: [[email protected]] 谢谢,忘了怎么拼了
  13:26:02: [Yong CHEN] 哈哈以前你没有推动敏捷的冲动啊,呵呵。
  13:26:04: [AlexQin(21)-QC-深圳] 呵呵
  13:26:19: [chinamath(海茶)-Sr.SE-北京] 实际一般怎么PK?能再讲点细节吗?
  13:26:24: [Yong CHEN] 哦,PO有权利挑战大家的结果,如果他感觉太高或者太低。
  13:26:27: 有冲动,但在全公司推行有阻力和顾虑
  13:26:34: [Yong CHEN] 所以可以防止整体高估或者低估。
  13:26:54: [[email protected]] 可以拿项目做示范
  13:26:56: [Yong CHEN] PK举个例子:1 2 2 5,1和5PK
  13:27:48: [Yong CHEN] 1:这个很简单的啊,就调用个函数,上次小X已经编好后台了。大家:是嘛?汗~然后,二轮全部变成1
  13:27:51: [Yong CHEN] 也可能是:
  13:28:15: [dearChloe-PM-深圳] 我想问: 就凭需求,就可以做到那么细致的工作估算?
  13:28:20: [Yong CHEN] 1: 这个……后台了。5说:但我们不只在游戏里边做排行榜,还要在网站上做,两边同步。
  13:28:27: [Yong CHEN] 122问:要吗?
  13:29:03: [Yong CHEN] PO:……应该要,网站不是你们做的吧?你们先看你们做要多久,我的记下来,得告诉网站部门也要干活……(写字)
  13:29:25: [Yong CHEN] 上面PK的例子是在盛大真实发生的情况,上次刚给他们做过咨询。
  13:29:50: [susan-pm-湖北] 老师,制定产品清单的过程是谁来做,也需要一个或多个迭代过程吗
  13:29:51: [Yong CHEN] 只凭借写出来的需求是不行的,因为写需求的人也不知道大家想知道什么,不知道什么。
  13:29:55: [ddv731731-SSE-上海] 是SDG,还是SDO
  13:29:57: [[email protected]] 开会讨论前,让所有成员都自己准备一下,注意一定要后分工,不要讨论前分配工作,不然他们就只管自己的估算了
  13:29:59: [北京-QM-李晋James Li] 今天公司网络不好。
  13:30:14: [北京-QM-李晋James Li] 精彩的部分煤看到。
  13:30:15: [北京-QM-李晋James Li] 没看到。
  13:30:22: [Yong CHEN] 所以一般需求可以写简单点,但讲解的时候多讲点(说话速度比打字快多啦),并且跟着大家的提问讲。
  13:30:26: [chinamath(海茶)-Sr.SE-北京] 是不是还得有个记录?否则PK那么多,谁能全记住。
  13:30:38: [Yong CHEN] 当然,讲完后,根据大家的提问,把需求补充一下。
  13:31:03: [Yong CHEN] liu: 对,讨论前要看的,特别是比较大的需求。
  13:31:22: [Yong CHEN] SE: 对,有个会议秘书,打字高手(轮流的),记录一个草稿纸。
  13:31:28: [北京-QM-李晋James Li] 陈老师,重构在什么时候做。
  13:31:49: [北京-QM-李晋James Li] 作为一个backlog吗?
  13:31:54: [Yong CHEN] 我本人的草稿纸现在264页,从去年7.15到现在。
  13:32:18: [susan-pm-湖北] 老师,制定产品清单的过程是谁来做,也需要一个或多个迭代过程吗
  13:32:27: [Yong CHEN] 用简单条目化的文字把PK中发现的问题记录下来,发送给大家。
  13:32:53: [Yong CHEN] Li: 重构经常作为Backlog的一项做。
  13:33:30: [Yong CHEN] Susan:是PO在做,他任何时候都可以碰Product Backlog,每个迭代需求都在变多。
  13:34:05: [Yong CHEN] 说说重构。重构是个很危险的工作,如果用敏捷,一定要有一个高级的设计人员,否则以后全重构了。
  13:34:13: [北京-QM-李晋James Li] 是啊。
  13:34:25: [北京-QM-李晋James Li] 另外重构的point也很难估算。
  13:34:28: [Yong CHEN] 所以敏捷原则中有一个,就是要有优秀的设计。
  13:34:32: [[email protected]] 重构是个很危险的工作?
  13:34:49: [[email protected]] 怎么会呢
  13:34:49: [北京-QM-李晋James Li] 还有Springt0与其他sprintx有啥区别
  13:34:50: [Yong CHEN] 恩,Point不好算,当然重构的任务多了,可以参考以前的。
  13:35:19: [Yong CHEN] Xiyeqing:因为有些代码编的很烂,不好改动。
  13:35:30: 重构必须要系统级的工程师才能碰,特别是对产品开发
  13:35:30: [北京-QM-李晋James Li] 好像sprint0就是专门确定架构的。
  13:35:37: [S(F)m(F)a(F)l(F)t-梅春  - 打鬼子-] msn抽风?
  13:35:38: [Yong CHEN] Sprint0常常指那个做整体计划的Sprint
  13:35:44: [[email protected]] 是呀 我就是看的重构这本书
  13:35:59: [[email protected]] 觉得越是烂的代码才越是要重构
  13:36:07: [[email protected]] 否则以后完全没法维护的
  13:36:16: [[email protected]] 等于要重新写一个
  13:36:39: [[email protected]] 所以我现在review他们代码的时候 写的烂的我都要他们改掉的
  13:36:40: [Yong CHEN] 其实很少有公司实行纯粹的迭代开发,那系统架构肯定崩溃。还是要有一系列的Sprint0(而不是1次!)来重新整理一下思路。
  13:37:09: [北京-QM-李晋James Li] 哦?这个思路挺好的。
  13:37:10: 时间差不多了,陈老师,你看延长到13:50?别太多打扰了
  13:37:18: [Yong CHEN] 012340123401234,这样规划,当然不一定是四次。
  13:37:46: [Yong CHEN] 恩,重构是必需的,但是“避免重构”也是必需的。高手写的代码,即使需求变化了,也不太需要改动太多。
  13:38:13: [Yong CHEN] 新手的能气死,只能重写。要在计划时就发现这一点,每天做代码评审,而非最后发现不好才重构。
  13:38:29: [[email protected]] 恩
  13:38:29: [Yong CHEN] 好的,我这边还有个PPT晚上要交工,呵呵。
  13:38:43: [[email protected]] 重构确实需要一次一小步的
  13:39:07: [[email protected]] 一旦都写完了 已经好久了 往往没人肯再花时间去重构了
  13:39:16: [Yong CHEN] 我们公司也在用Scrum,但是我们每半年左右就有一次Release,集中消除BUG,确定下一步方向,等等。
  13:39:23: [Yong CHEN] 是。
  13:39:54: [[email protected]] 是。 是回答了哪个问题?
  13:39:54: [Yong CHEN] Xiyeqing:我03年半天进行一次代码审查,中午就的看看大家的代码,免得晚上集成不了抓瞎。
  13:40:07: [Yong CHEN] 回答你的“往往没人肯……”
  13:40:12: [[email protected]] 啊。。。半天就进行一次代码审查乐了啊
  13:40:24: [[email protected]] 那频率很高了哦
  13:40:31: [[email protected]] 呵呵 看来你是个很认真负责的pm啊
  13:40:31: [Yong CHEN] 总归有站起来走走的时间,就去看看别人的代码,非正式的。
  13:40:38: [[email protected]] 怪不得混的这么好啊
  13:40:41: [[email protected]] 呵呵
  13:40:45: [Yong CHEN] 每人每天写100行左右C++,半天50行,2屏幕多点。5分钟看完。
  13:41:15: [[email protected]] 他们知道你一直要看 肯定没人敢偷懒
  13:41:23: [[email protected]] 现在我就发现很多人喜欢偷懒
  13:41:30: [[email protected]] 不管了 他就不帮你做东西
  13:41:33: [Yong CHEN] 偷懒不好,到老了就后悔了。
  13:41:41: [[email protected]] 呵呵
  13:42:02: [[email protected]] 其实他们不肯做工作 想学点别的
  13:42:08: [Yong CHEN] 好,基本结束。还有什么集中的问题没有?
  13:42:12: [dearChloe-PM-深圳]  学啥?
  13:42:17: [[email protected]] 但是上班时间不可能一直让你看别的啊
  13:43:02: [chinamath(海茶)-Sr.SE-北京] 谢谢陈老师,今天讲的非常好!
  13:43:06: [[email protected]] 他们自己看书
  13:43:13: 好了
  13:43:25: [Yong CHEN] 看代码别太认真,看全局不看细节。差代码全体换成*我也能看出是坏代码。
  13:43:31: [[email protected]] (F)
  13:43:32: 非常感谢陈老师的介绍,非常生动易懂。
  13:43:33: [Yong CHEN] 因为结构就不对,呵呵。
  13:43:49: [Yong CHEN] 也谢谢这么多人陪着我,呵呵。
  13:43:57: [[email protected]] (L)
  13:44:04: 大家再有问题发给我,回头再进一步交流。
  13:44:08: [dearChloe-PM-深圳] 其实面向对象的编程,结构对,基本就不会有什么大问题了
  13:44:09: [北京-QM-李晋James Li] 感谢陈老师的精彩讲述。
  13:44:10: [kursk200(一点红)-PM-上海] 感谢老师
  13:44:11: [Yong CHEN] 好的谢谢大家。
  13:44:11: [dearChloe-PM-深圳] 谢谢陈老师
  13:44:17: 可以在某期地面沙龙的一个主题还是敏捷
  13:44:24: [[email protected]] 谢谢陈老师
  13:44:27: [[email protected]] 老谷,陈老师提到的扑克大家都很感兴趣,但是可能老师不方便留MSN,
  13:44:38: 再次感谢!!鼓掌
  13:44:39: [Yong CHEN] 啊我的MSN大家看不到?
  13:44:47: [北京-QM-李晋James Li] 看不到。
  13:44:58: [[email protected]] 是否可以在你这里报名,然后你统一给老师
  13:44:59: [北京-QM-李晋James Li] 啊?
  13:45:01: [[email protected]] 就是麻烦你了
  13:45:04: 要扑克牌的可以给陈老师发邮件,也可以统一发给我
  13:47:30: 规范签名
  13:47:30: 请大家将自己的签名统一下,格式“itpub id加常用名-职位-地点”。例如,“小西-Editor-北京”,“chinamathman-PM-北京”等等

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/3433/viewspace-613146/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/3433/viewspace-613146/

你可能感兴趣的:(【原创】2009年8月25日老谷"项目管理MSN群"专题—敏捷生态)