微软邹欣分析Scrum开发流程的问题和经验
2012-10-09 10:56
260 查看
邹欣是工作于微软亚洲研究院的研发经理,同时也是《编程之美》和《移山之道》的作者。前不久,他在博客上总结了自己使用scrum开发流程的经验。
在对Scrum的基本概念和流程做了简单介绍之后,邹欣提出几个在实践中会遇到的问题:
各个需求和任务之间是有种种复杂的依赖关系的,除了优先级之外, 我们还要考虑相互的依赖关系。怎样在计划中表现依赖关系呢?
如果团队成员对某个任务不感兴趣, 都不认领这个任务怎么办?
有些成员的认领的任务很多, 有些成员认领的任务很少, 忙闲不均, 怎么办?
每日立会流于形式怎么办?
针对这些问题,邹欣提出几个改进方法:
定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 每个人的任务必须是明确定义的
要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要, 但是不是关键 (那是沉没成本),关键是要看我们离最后目标有多远。
有些燃尽图只是列出了任务的数目, 这种图无法展现项目的拖延, 一个任务有大有小, 它们在图表中都是一个点, 一个16小时的任务需要3 天完成, 一个2小时的任务处于种种原因也花了3天时间, 他们在图表中的表现是一样的。 在实践中, 我个人认为以时间为度量的燃尽图更有效果
邹欣接下来对于“任务完成”这件事又提出问题:
做过项目的人都知道, 当你说“任务都完成了”的时候, 那只是说, 开发人员认为该写的代码都写完了, 还有很多事情没做完。 例如写一个Windows 客户端的功能, 显示一个新闻图片加上和与它相匹配的文字 (假设这些图片/文字都可以从互联网上拿到) , 做完之后, 还有下面的事情:
验证这个功能显示在WinXP, vista, win7, win2008 server R2, win2012 server 都显示正确。 (开发人员表示自己的机器是win2008 server, UI 看起来不错, 其它平台想必也不错!)
验证这个功能的显示布局和字体在100% 到150% 的DPI 上都显示正确, 在各种色彩配置中都显示正确。
验证文字无论是中文, 英文, 阿拉伯文都能正确显示 (联合国五种工作语言我们得支持吧? )
验证程序效能上没有问题
……
谁来做这第三步半呢? 程序员写完功能的时候, 我们感觉好像项目完成了 80%, 殊不知后面的20% 往往要花费80% 的时间, Sprint/Scrum 没有明确表明到底 何人/何时/何种优先级 来完成这个20% 的任务。
对于测试人员的职责问题,邹欣提出:
测试人员在一个冲刺中怎么工作呢? 有敏捷专家建议测试人员可以担负起 Product Owner 的部分责任,同时掌握 Acceptance Test 流程, 对产品的最终质量负责。 但是测试人员的开发技术能力在团队中并不占优 (在有些中国公司中甚至是最弱的一环),他们在大家都要 “烧光”所有任务的压力下,能担当起 Product Owner 这一责任么?
上面这两个问题,邹欣并没有给出明确的答案。
邹欣认为:ScrumMaster是Scrum实施是否能够成功的关键。
我听到有些团队也实施Scrum, 但是他们随机挑一个成员来做 ScrumMaster, 好像 ScrumMaster就是招呼大家开开会, 记录每个人的进度而已。这种方法失败的可能性很大。 一个好的ScrumMaster 能在两种语境 (描述软件项目的商业语境,描述实现细节的技术语境) 自如地翻译和切换,事实上是一个强有力的PM,如果团队还要求她做全职的开发工作,这样的人就更难找了。
不过邹欣认为Scrum也没有那么特别,它和质量控制理论的模型,比如经典的戴明环PDCA没什么区别,在6西格玛理论中也可以看到相似的流程——DMAIC(Define,
Measure, Analyze, Improve, Control),与渐进交付的流程(Evolutionary Delivery)也很类似。
对于Scrum团队,邹欣指出:自我管理、自组织、跨职能,这三点要求看似简单,实际上很难做到。
自我管理:
以前领导布置了任务,我们实现就可以了,现在要自己挑选任务;每次sprint 结束之后,还要总结不足,提出改进,并且自己要实施这些改进。“自我管理”不等于“没有管理”。
自组织:
以前做好自己的事情就好了,安心下班。现在每个人要联合起来对项目负责,有人工作落后了还要帮助他改进,项目缺少某类资源还要自己顶上去。
跨职能:
以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责,自己搞定spec, 和别人沟通, 同时自己搞定测试。
他强调:
如果你的团队很弱, 那么强行把Scrum (或者其它高级方法)套在上面也没有用, 也许还会适得其反,往往需要多次Sprint 才能让Scrum 走上正轨。换句话说, 如果你的团队已经是这么厉害 (self-managing, self-organizing, cross-functional)的一帮人, 那么用不用Scrum 都能写好软件!
最后,邹欣总结了一些实践者的经验教训:
ScrumMaster 不是一个官,而是一个没有行政权力的沟通者,就像微软的PM 那样。她同时还要在团队中做具体的工作。直接把原来的 “经理”变成 ScrumMaster 大多行不通。
在一些公司中,不少项目需要很多暗箱操作和政治角力才能搞定, Scrum 会把这些矛盾都摆到明处。这有好处,也有风险。
在复杂的项目里,要让一线团队成员做决定。
创业公司的团队其实经常是运行在 Scrum 的模式中 (只不过大家太忙,没功夫论证到底多么Scrum)。
在Scrum 计划阶段的估计不是一个“合同”, 领导们不要把它当成一个合同。估计总是不准的。 坚持短期的Sprint,即使不准的估计也不会有大的损害。
不要和管理层谈 “流程”, 他们只关心 “结果”。
在大型团队,复杂项目中,Scrum 并没有非常完美的答案,Scrum 的创始人也承认这一点。 (我曾看到30多人挤在会议室里搞 Daily Scrum,一叹! )
在结尾时,邹欣提出:
Scrum不是 “银弹”,不能解决软件开发的所有问题,至于具体项目进度如何跟踪, 如何管理测试工作,如何管理复杂项目, 还要靠战斗在一线的团队成员见招拆招,想出合适的办法。
原文: http://www.infoq.com/cn/news/2012/10/ms-manager-analyze-scrum
在对Scrum的基本概念和流程做了简单介绍之后,邹欣提出几个在实践中会遇到的问题:
各个需求和任务之间是有种种复杂的依赖关系的,除了优先级之外, 我们还要考虑相互的依赖关系。怎样在计划中表现依赖关系呢?
如果团队成员对某个任务不感兴趣, 都不认领这个任务怎么办?
有些成员的认领的任务很多, 有些成员认领的任务很少, 忙闲不均, 怎么办?
每日立会流于形式怎么办?
针对这些问题,邹欣提出几个改进方法:
定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 每个人的任务必须是明确定义的
要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要, 但是不是关键 (那是沉没成本),关键是要看我们离最后目标有多远。
有些燃尽图只是列出了任务的数目, 这种图无法展现项目的拖延, 一个任务有大有小, 它们在图表中都是一个点, 一个16小时的任务需要3 天完成, 一个2小时的任务处于种种原因也花了3天时间, 他们在图表中的表现是一样的。 在实践中, 我个人认为以时间为度量的燃尽图更有效果
邹欣接下来对于“任务完成”这件事又提出问题:
做过项目的人都知道, 当你说“任务都完成了”的时候, 那只是说, 开发人员认为该写的代码都写完了, 还有很多事情没做完。 例如写一个Windows 客户端的功能, 显示一个新闻图片加上和与它相匹配的文字 (假设这些图片/文字都可以从互联网上拿到) , 做完之后, 还有下面的事情:
验证这个功能显示在WinXP, vista, win7, win2008 server R2, win2012 server 都显示正确。 (开发人员表示自己的机器是win2008 server, UI 看起来不错, 其它平台想必也不错!)
验证这个功能的显示布局和字体在100% 到150% 的DPI 上都显示正确, 在各种色彩配置中都显示正确。
验证文字无论是中文, 英文, 阿拉伯文都能正确显示 (联合国五种工作语言我们得支持吧? )
验证程序效能上没有问题
……
谁来做这第三步半呢? 程序员写完功能的时候, 我们感觉好像项目完成了 80%, 殊不知后面的20% 往往要花费80% 的时间, Sprint/Scrum 没有明确表明到底 何人/何时/何种优先级 来完成这个20% 的任务。
对于测试人员的职责问题,邹欣提出:
测试人员在一个冲刺中怎么工作呢? 有敏捷专家建议测试人员可以担负起 Product Owner 的部分责任,同时掌握 Acceptance Test 流程, 对产品的最终质量负责。 但是测试人员的开发技术能力在团队中并不占优 (在有些中国公司中甚至是最弱的一环),他们在大家都要 “烧光”所有任务的压力下,能担当起 Product Owner 这一责任么?
上面这两个问题,邹欣并没有给出明确的答案。
邹欣认为:ScrumMaster是Scrum实施是否能够成功的关键。
我听到有些团队也实施Scrum, 但是他们随机挑一个成员来做 ScrumMaster, 好像 ScrumMaster就是招呼大家开开会, 记录每个人的进度而已。这种方法失败的可能性很大。 一个好的ScrumMaster 能在两种语境 (描述软件项目的商业语境,描述实现细节的技术语境) 自如地翻译和切换,事实上是一个强有力的PM,如果团队还要求她做全职的开发工作,这样的人就更难找了。
不过邹欣认为Scrum也没有那么特别,它和质量控制理论的模型,比如经典的戴明环PDCA没什么区别,在6西格玛理论中也可以看到相似的流程——DMAIC(Define,
Measure, Analyze, Improve, Control),与渐进交付的流程(Evolutionary Delivery)也很类似。
对于Scrum团队,邹欣指出:自我管理、自组织、跨职能,这三点要求看似简单,实际上很难做到。
自我管理:
以前领导布置了任务,我们实现就可以了,现在要自己挑选任务;每次sprint 结束之后,还要总结不足,提出改进,并且自己要实施这些改进。“自我管理”不等于“没有管理”。
自组织:
以前做好自己的事情就好了,安心下班。现在每个人要联合起来对项目负责,有人工作落后了还要帮助他改进,项目缺少某类资源还要自己顶上去。
跨职能:
以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责,自己搞定spec, 和别人沟通, 同时自己搞定测试。
他强调:
如果你的团队很弱, 那么强行把Scrum (或者其它高级方法)套在上面也没有用, 也许还会适得其反,往往需要多次Sprint 才能让Scrum 走上正轨。换句话说, 如果你的团队已经是这么厉害 (self-managing, self-organizing, cross-functional)的一帮人, 那么用不用Scrum 都能写好软件!
最后,邹欣总结了一些实践者的经验教训:
ScrumMaster 不是一个官,而是一个没有行政权力的沟通者,就像微软的PM 那样。她同时还要在团队中做具体的工作。直接把原来的 “经理”变成 ScrumMaster 大多行不通。
在一些公司中,不少项目需要很多暗箱操作和政治角力才能搞定, Scrum 会把这些矛盾都摆到明处。这有好处,也有风险。
在复杂的项目里,要让一线团队成员做决定。
创业公司的团队其实经常是运行在 Scrum 的模式中 (只不过大家太忙,没功夫论证到底多么Scrum)。
在Scrum 计划阶段的估计不是一个“合同”, 领导们不要把它当成一个合同。估计总是不准的。 坚持短期的Sprint,即使不准的估计也不会有大的损害。
不要和管理层谈 “流程”, 他们只关心 “结果”。
在大型团队,复杂项目中,Scrum 并没有非常完美的答案,Scrum 的创始人也承认这一点。 (我曾看到30多人挤在会议室里搞 Daily Scrum,一叹! )
在结尾时,邹欣提出:
Scrum不是 “银弹”,不能解决软件开发的所有问题,至于具体项目进度如何跟踪, 如何管理测试工作,如何管理复杂项目, 还要靠战斗在一线的团队成员见招拆招,想出合适的办法。
原文: http://www.infoq.com/cn/news/2012/10/ms-manager-analyze-scrum
相关文章推荐
- 微软邹欣分析Scrum开发流程的问题和经验
- 敏捷中Scrum开发流程的问题和经验
- Android开发-数据存储SharedPreferences工具类、Set<String>保存问题、源码分析
- iOS 开发中你是否遇到这些经验问题
- ArcgisEngien开发空间分析失败问题
- 安卓开发之常见死机问题--log分析
- 手机网上商城-项目经验总结(一)-项目开发流程
- asp.net Forms表单验证 使用经验及验证流程分析
- OpenGL 在Win7(32)上配置开发环境流程及注意问题
- Android开发: 在Android虚拟设备中使用SDCard及问题分析
- 短视频 | 问答开源项目解读之整体代码流程和问题分析
- 微信小程序开发常见问题分析
- iOS开发经验分享:UITableViewCell复用问题
- Exynos4412 中断驱动开发(二)—— 中断处理流程分析
- (原创)小问题的反思 qa的问题?开发的问题?流程问题?
- 游戏运营全过程剖析,游戏开发,游戏运营,游戏推广问题分析
- iOS 开发中你是否遇到这些经验问题(二)
- android开发环境遇到adt无法启动的问题分析及解决方法
- 网站开发流程和解决的问题
- Linux开发中常见段错误问题原因分析