eric-1001c

一段寒暄之后。。。

(19:58:23) i: 诺基亚用Scrum有多长时间了阿
(19:58:24) he: 算是用过.呵呵
(19:59:06) he: 整个公司推行这个大概也有两年的样子
(19:59:18) he: 不过具体到我这边大概是一年多
(19:59:21) i: 时间也不算短
(19:59:58) i: 那你给我说下那边的情况怎么样:D
(20:00:36) he: 其实怎么说呢...N记以前的风格都是作坊型的
(20:00:49) he: 每个产品组就是个小作坊,所以风格各异
(20:01:01) he: 有的适应Scrum就快一些,有的就有些走样
(20:01:16) i: 那你所在的小作坊怎么样
(20:01:19) i: 呵呵
(20:02:06) he: 不过不管最后是不是有些走样,还是有些好处
(20:02:20) i: 具体流程呢
(20:02:31) he: 其实主要原因是它原来还有一套标准的产品立项, 开发, 测试,
发布流程.
(20:02:41) he: 然而又要把Scrum硬套到中间去
(20:02:55) he: 这中间其实就得看执行的团队和个人权衡了
(20:02:58) i: 这样是好还是不好。
(20:03:17) he: 是这样
(20:03:56) he: 简要的来讲,原来的发布流程是: 可行性研究 -> 立项 -> 开发
-> 测试 -> 试用 -> 发布
(20:04:26) i: 使用scrum以后是。。
(20:05:08) i: 具体流程是否严格按Scrum的规则来做的呢
(20:05:37) he: 那么...想把Scrum嵌入到开发这个阶段去
(20:06:00) i: 恩
(20:06:00) he: 对外面来说原来的那套流程就不变...
(20:06:08) he: 所以有些地方就被框得很死
(20:06:24) i: 比如。。
(20:06:39) he: 如果团队只在开发这个周期做一两个迭代...那么就退化得跟原
来的流程差不多了
(20:07:05) i: 我感觉Scrum可以替代这整个流程吧。
(20:07:20) he: 嗯:)不过那不是我能改变的
(20:07:43) i: 那你个人认为流程该怎么改变才比较好
(20:07:55) i: 就拿N以前的这个为例子
(20:08:07) he: 前四个其实都可以
(20:08:24) he: 不过因为刚推行的时候大家都对Scrum没有底
(20:08:38) he: 上边也不愿意去把新东西搞得那么激进
(20:09:53) i: 可是我感觉把开发那个环节采用scrum也算是正确的吧，因为前
面的可行性研究方面如何去scrum呢
(20:10:33) he: 嗯,可行性研究的意思
(20:10:44) he: 其实就是抽两三个最精干的人
(20:10:51) he: 组成一个预研的小team
(20:11:08) i: en
(20:11:17) he: 然后在给定的时间内把PM还没有把握的功能作出demo来验证一
条路能不能走通
(20:11:23) he: 其实是满适合Scrum的
(20:11:32) he: 个人觉得:)
(20:11:38) i: 恩，有道理
(20:12:05) i: Scrum这个概念到是不仅仅拘泥于开发
(20:12:16) he: 然后这些小feature的demo就会支持之后的立项申请,才能拿到
经费
(20:12:42) i: 那现在诺基亚的scrum还是在开发环节上吗
(20:13:02) he: 是的
(20:13:21) i: 那现在是算成功呢，还是。。。
(20:13:26) he: 据我了解多数是
(20:13:45) he: 嗯,不管怎么说, 它并不像一个原来标准的样子, 作了某些妥协
(20:13:45) i: 对了，和你分享一本书
(20:13:55) he: 但我觉得还是提高了效率的:)
(20:14:16) he: 虽然,很大程度上取决于团队和个人自觉程度
(20:14:56) i: 你说，假如让你在一个下团队里去实施Scrum，你会如何做呢
(20:15:22) i:
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
今天在infoq看到这本书。
(20:15:41) he: 呵呵, 这本我有PDF
(20:16:10) i: 噢。。。
(20:16:13) i: hehe
(20:16:26) he: 不过没看完:)
(20:16:33) i: 说说你的想法，关于我刚才那个问题
(20:17:41) he: 是这样, 我以前带的团队通常都是在预研之后接手的
(20:18:08) he: 所以在这个阶段之前, 主要还是和Product Manager讨论他的需
求
(20:18:24) he: 您可以把N记的Product Manager看作一个内部客户
(20:18:30) i: 恩，那些backlog要列出来吗
(20:18:46) he: 还不到Backlog那里....
(20:18:53) i: 好，你继续，呵呵
(20:19:06) he: Product Manager会提出从他自己的角度出发最看重的需求
(20:19:26) he: 这些需求也许是很简短的表述,就像一个带场景的user story
(20:19:33) i: 恩
(20:19:47) he: 因为他不会很关心技术, 他更多的代表市场
(20:20:58) he: 所以他的需求也许是这样子的:
节点A将支持灵活的存储设备, 自动监测客户给与的存储设备数量并作出按比例
xx:xx的空间占用

(20:21:21) i: 对，只是个user story
(20:21:31) i: 下一步呢
(20:21:55) he: 或者当用户B的voice传输到节点C时,将自动监测其媒体类型并
做出质量和编码的变换
(20:22:27) he: 这些user story, 我们通常会在他的会议上先记下来, 整理成
一个list
(20:22:50) he: PM会给出他看重的优先级
(20:23:07) i: 客户给出优先级 ？
(20:23:38) he: 对的, 比如说, 就相当于问他: 您最希望在第一个demo day中
看到的是哪一个feature?
(20:23:43) i: 而不是我们分析需求去列出优先级，明白
(20:23:48) he: 或者您最希望推向市场卖的是哪一个
(20:23:54) i: 恩
(20:23:58) he: 是的,它首先是面向feature的
(20:24:04) he: 然后...我们不能全都答应
(20:24:27) i: 为什么
(20:24:44) i: 可以分迭代来做吧
(20:24:59) he: 我们需要与做feasibility study的team沟通,看看他所提出的
要求是不是都能实现,或者能否以可以接受的代价实现
(20:25:22) i: 噢
(20:25:48) i: 怎么又回到第一环节了
(20:25:59) he: 如果不能实现, 我们可以进一步跟他确认: 您看, 你所说的
feature是A, 但是我们觉得您更需要的可能是A+
(20:26:28) he: 或者, 您看, 在给出的开发周期内A不能全都实现, 是否可以先
实现A- ...
(20:26:58) he: 或者当前的平台对于实现A有所限制, 我们可以给您提供两个参
考: A1 或者A2
(20:27:11) he: 有的时候他或者她都会咆哮...
(20:27:13) i: 恩，应该是增量式开发，一步步完成客户的需求
(20:27:28) i: 呵呵
(20:27:30) he: 或者我们双方都在咆哮...
(20:28:17) he: 那么也许最后达成的结果可能会是我们需要在第一个demo中作
出a, 然后同时等待另外一个team的组件b的效果, 如果不行,那么backup可能是
c...
(20:28:57) he: 这个妥协后的结果通常被称为product feature backlog
(20:29:24) he: 它对于技术细节关注很少,主要关注最后能完成的feature
(20:29:34) i: 噢
(20:30:02) i: 这个时候到sprint计划会议来细分这些backlog了吧
(20:30:06) he: 客户在交货或者中间确认进度的时候看的通常都是feature
backlog
(20:30:45) he: 是的, 通常之后每个feature team都会召集起来开会
(20:30:55) he: 也就是Scrum team
(20:31:08) he: 将每个feature都分解为技术上实现的步骤
(20:31:32) i: 然后细分出来交给团队。
(20:31:35) he: Scrum Master 会将这些步骤作为一个个TASK纪录
(20:31:45) he: 不是细分出来交给团队...
(20:32:01) he: 这个时候每个团队都参与进来看自己的那部分feature backlog
了
(20:33:05) i: Scrum Master 记录那些task做什么。
(20:33:07) he: 成员王小花可能会说...我觉着吧,要实现feature A 可能我们
需要先在后段存储s上实现一个抽象层InfA
(20:33:22) he: 它需要routine A1 A2 A3来做
(20:33:31) he: 王二麻子可能反对...
(20:33:46) i: 呵呵。
(20:33:59) he: 说我觉着我们只需要服用组件B和组件C提供的服务接口InfB1和
InfC2...
(20:34:20) he: 然后给一个带路由表的配置文件...
(20:34:30) i: 那这个会议最终目标是要干什么，或者说要得到什么结果
(20:34:53) he: 最后的这些task, 就会形成一个周期内的sprint backlog
(20:35:13) he: 能力越好的团队, 所能细分出来的task越精确
(20:35:19) i: 噢，是指定backlog的过程
(20:35:27) he: 通常粒度控制在20h
(20:36:28) i: 如果需求有变的情况如何处理
(20:37:02) i: 在迭代的时候
(20:37:14) he: 嗯...我记得上次某大师来讲座的时候我们也问过
(20:37:35) i: 呵呵，怎么回答的
(20:37:45) he: 他的答案是标准做法是继续把sprint做完,然后在接下来的一个
sprint中完成变动
(20:38:11) i: 明白了。。。
(20:38:37) i: 那迭代期间你们有每日例会吧
(20:39:02) he: 是的, daily meeting
(20:39:25) i: 对了，你们是不是也这样处理需求的变化，放在下个sprint里
(20:39:47) he: 不是
(20:39:53) he: 我们的sprint 周期长达一个月..
(20:40:10) i: Scrum里规则是一个月。。。
(20:40:17) i: 那。。。
(20:40:19) he: 所以通常我们有drop一个旧的和add一个新的
(20:40:42) he: 除了通常比较简化的Not Started. On Going和Done 三个状态
之外
(20:40:56) he: 我们有Dropped和Added
(20:42:07) i: 噢，这样处理也很科学
(20:42:46) he: 呵呵:)因为有时候一个月还是太长
(20:43:00) he: 因为对于两地或者三地之间的协同开发
(20:43:06) he: 一个月可以发生的事情太多了
(20:43:23) he: 尤其是这几个地方都有时差的时候
(20:43:47) i: 不过迭代没有完成的话，也许客户不清楚自己需求的变更是好
是坏，大师那么说也有道理吧。迭代完成，让客户看了以后他再看是否变化需求。
(20:44:02) i: 我说的有没有可能 ？
(20:44:30) he: 是的:)
(20:45:06) he: 但是有时候需求确实很急...
(20:45:09) i: 具体应用具体处理吧，起码有了处理的办法。
(20:45:13) i: 恩
(20:45:19) he: 比如突然拿某移动的单
(20:45:27) he: 而该客户以需求怪异著称
(20:45:34) i: 呵呵
(20:45:38) he: 这种情况不一定非得等到下一个...
(20:45:45) i: 确实
(20:45:55) i: 拥抱变化
(20:46:29) he: 其实我觉得很依赖团队成员的
(20:46:36) he: 如果团队成员很不积极
(20:46:36) i: Scrum的规则也应该是符合实际情况的经验性方法才能发挥能
量。
(20:46:47) i: 个人敏捷性
(20:46:55) he: 那么sprint planning就会死气沉沉变成任务指派...
(20:47:09) i: Scrum里面说自我管理
(20:47:31) i: 如何调动成员的积极性来更好的团队自我管理
(20:49:18) he: 其实原来我带的team比较实际一点....
(20:49:23) he: 每个sprint都有demo...
(20:49:29) i: 那天在infoq上看了一篇文章，关于这个问题，是说团队成员的
主人翁精神不够
(20:49:38) i: 恩，你继续
(20:49:53) he: 大家通常都很期望demo day那天PM发话说: 嗯,对的,我就是想
要这个
(20:50:10) he: 如此以来...整个team就能申请预算出去大吃大喝了
(20:50:20) he: 因为整个team都比较好吃...
(20:50:23) i: 呵呵
(20:50:29) he: 成都好吃的地方很多,也不很贵
(20:50:39) i: 好吃不懒做
(20:50:58) he: 嗯,总的来说,就是得有promotion:)
(20:51:05) he: 我个人觉得
(20:51:29) i: 一些物质激励
(20:52:10) he: 呃..其实也不限于这个...物质
(20:52:28) he: 您说:)
(20:53:06) i: 比如一起出去游山玩水，放松个一两天
(20:53:19) he: 嗯
(20:54:10) i: 对了，你们用看板没有
(20:54:39) i: 是有专门的系统还是手工看板
(20:55:38) he: 哦.有一间屋专门换了玻璃板的...
(20:55:50) i: 常用吗
(20:55:53) he: 四面墙可以乱涂乱画....
(20:56:03) he: 嗯,经常:P
(20:56:08) i: 呵呵
(20:56:21) i: 我们这方面做的不太够
(20:56:25) he: 针对team里年轻人表现欲都比较强的特点
(20:56:31) he: 我们划出一面墙来
(20:56:40) he: 当月sprint完成的最好的年轻人
(20:56:46) he: 有权占有那面墙...
(20:56:53) i: 呵呵
(20:57:02) he: 只要不写的太反动...随便他怎么规划
(20:57:04) i: 涂鸦吗
(20:57:08) he: 嗯.差不多
(20:57:25) he: 对羞涩性队员的效果可能就差一些
(20:57:33) i: 挺有意思
(20:57:54) he: :)
。。。
end