【原创】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-北京”等等
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/