Adobe团队开发:增量开发那么好,何乐而不为?
2007-12-17 11:25
120 查看
注:因为时间关系没有翻译完,而且采取的是意译,不通畅的地方请参照文末提供的原文链接,谢谢。
Adobe Photoshop团队一直尝试从传统的开发方法过度到敏捷开发上来,但直到CS3的发布,才在副总裁Dave Story的帮助下,完成这一跳跃。结果是什么?轻松的周末,较原来少1/3的Bug等。让我们来看看他们是如何做到这一点的。
如果这是一个好主意,为什么那么长时间才得以实施——这次你怎么做到的?我们从前曾经尝试了很多次,但是都以失败告终。团队里的人都没有使用增量开发过程的经历,当Adobe其他组里的人想早些看到“功能完成”里程碑时,我们就在旧有习惯和压力下又回到老方法上去了。使用旧的方法对我们来说是得心应手,所以遇到困难时,我们就习惯性地先找个能用的。
Dave Story(Adobe数字图像产品开发的副总裁)的不同之处是在SGI和Intuit时,他有过增量开发方面的成功经验,面对团队内外的问题时,他知道如何去处理。
开发CS3的方法究竟做了哪些改变?我们的改变是从一个传统的瀑布方法过度到增量开发模型。从前,我们先确定功能,在“功能完成”期限到时才开始实现它们,然后基于Alpha和Beta测试和Bug修复修改功能。但在“功能完成”时间之前要完成所有的功能是很困难的,加班到深夜或者放弃周末都是很经常的事情,所以那时候提交的程序都很恐怖。绝望地发现和修改着Bug,用于修改测试人员反馈回来的Bug的时间也所剩无几。
每个开发过程结束,我们都面临堆积如山的Bug,还需要N个不眠之夜和周末去完成它们。在功能、时间表和质量等三个变量中,公司设定时间表且没有谈判的余地。只有功能完成时,我们才能再进行精雕细琢。但是到里程碑时,质量出现问题,却又没有时间修改。到最后,你还不能削减功能,所能做的就是降低自己的生活质量,提高产品的质量,在产品出货前达到自己想要的层次。产品出门前我们从没有牺牲过产品质量,但是牺牲了我们的家庭生活。
我们也不能为了迎合时间表而减少功能,因为那个时候我们意识到自己已经陷入泥潭,功能已经被整合,它们之间相互调用,要抽取的话,就会导致更多的Bug出现。
可能我们做的最有效的事情是限制工程师的Bug数:如果谁的Bug数量超过20,不论他是谁,都必须停下实现功能的工作,去修复Bug。基本思想是,Bug数量越少,我们就可以在开发过程中越早给测试人员提交可用的Alpha版本,最后也不会遇到巨如山的Bug堆。
目标是,始终使产品保持在这样一个状态:我们能轻松地说“放下铅笔,你还有X周去修改剩下的Bug,然后交付。”里程碑基本是可测量的点,都是可接受的度量,而不是什么“所有功能”或者“冻结UI”等模糊的字眼。这样,在开发周期的后面我们还可以增加或者修改功能,如果事情不是那么着急,我们还可以砍掉几个功能。
对开发者来说日子是轻松了,但是对代码也是如此吗?通过这个开发过程,程序的质量比从前提高了很多,Bug少了很多。Bug数不像从前经常到达恐怖的极点,整个开发过程中都保持在较低的水平。另外也能完成更多外面的测试者提供的反馈,因为我们不需要那么早切换到“疯狂Bug修复模式”了。
总结一下,现在你是能修复更少的Bug,还是更多,还是差不多?你是不是需要牺牲功能才能做到这一点?有些人担心这样会意味着更少的功能。其实不是这样。当然,我们总体上有更少的Bug,半程时也少了许多(上次我检查时差不多少了1/3)。更高的质量,更多的功能,更足的睡眠,更放松的周末:何乐而不为?
原文链接:Adobe edits the development cycle
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1533944
Adobe Photoshop团队一直尝试从传统的开发方法过度到敏捷开发上来,但直到CS3的发布,才在副总裁Dave Story的帮助下,完成这一跳跃。结果是什么?轻松的周末,较原来少1/3的Bug等。让我们来看看他们是如何做到这一点的。
如果这是一个好主意,为什么那么长时间才得以实施——这次你怎么做到的?我们从前曾经尝试了很多次,但是都以失败告终。团队里的人都没有使用增量开发过程的经历,当Adobe其他组里的人想早些看到“功能完成”里程碑时,我们就在旧有习惯和压力下又回到老方法上去了。使用旧的方法对我们来说是得心应手,所以遇到困难时,我们就习惯性地先找个能用的。
Dave Story(Adobe数字图像产品开发的副总裁)的不同之处是在SGI和Intuit时,他有过增量开发方面的成功经验,面对团队内外的问题时,他知道如何去处理。
开发CS3的方法究竟做了哪些改变?我们的改变是从一个传统的瀑布方法过度到增量开发模型。从前,我们先确定功能,在“功能完成”期限到时才开始实现它们,然后基于Alpha和Beta测试和Bug修复修改功能。但在“功能完成”时间之前要完成所有的功能是很困难的,加班到深夜或者放弃周末都是很经常的事情,所以那时候提交的程序都很恐怖。绝望地发现和修改着Bug,用于修改测试人员反馈回来的Bug的时间也所剩无几。
每个开发过程结束,我们都面临堆积如山的Bug,还需要N个不眠之夜和周末去完成它们。在功能、时间表和质量等三个变量中,公司设定时间表且没有谈判的余地。只有功能完成时,我们才能再进行精雕细琢。但是到里程碑时,质量出现问题,却又没有时间修改。到最后,你还不能削减功能,所能做的就是降低自己的生活质量,提高产品的质量,在产品出货前达到自己想要的层次。产品出门前我们从没有牺牲过产品质量,但是牺牲了我们的家庭生活。
我们也不能为了迎合时间表而减少功能,因为那个时候我们意识到自己已经陷入泥潭,功能已经被整合,它们之间相互调用,要抽取的话,就会导致更多的Bug出现。
可能我们做的最有效的事情是限制工程师的Bug数:如果谁的Bug数量超过20,不论他是谁,都必须停下实现功能的工作,去修复Bug。基本思想是,Bug数量越少,我们就可以在开发过程中越早给测试人员提交可用的Alpha版本,最后也不会遇到巨如山的Bug堆。
目标是,始终使产品保持在这样一个状态:我们能轻松地说“放下铅笔,你还有X周去修改剩下的Bug,然后交付。”里程碑基本是可测量的点,都是可接受的度量,而不是什么“所有功能”或者“冻结UI”等模糊的字眼。这样,在开发周期的后面我们还可以增加或者修改功能,如果事情不是那么着急,我们还可以砍掉几个功能。
对开发者来说日子是轻松了,但是对代码也是如此吗?通过这个开发过程,程序的质量比从前提高了很多,Bug少了很多。Bug数不像从前经常到达恐怖的极点,整个开发过程中都保持在较低的水平。另外也能完成更多外面的测试者提供的反馈,因为我们不需要那么早切换到“疯狂Bug修复模式”了。
总结一下,现在你是能修复更少的Bug,还是更多,还是差不多?你是不是需要牺牲功能才能做到这一点?有些人担心这样会意味着更少的功能。其实不是这样。当然,我们总体上有更少的Bug,半程时也少了许多(上次我检查时差不多少了1/3)。更高的质量,更多的功能,更足的睡眠,更放松的周末:何乐而不为?
原文链接:Adobe edits the development cycle
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1533944
相关文章推荐
- Adobe团队开发:增量开发那么好,何乐而不为?
- 只要能够保证良好的沟通和即时的反馈,那么开发团队即使并没有采用先进的方法论,一样可以成功。
- maven进行团队开发
- 本人新书< Windows CE 7开发实战详解>出版-感谢大家一如既往的支持-感谢CSDN总裁蒋涛以及他率领的CSDN团队提供的支持!
- 敏捷开发团队绩效管理与目标管理:关于如何为团队设立外部目标
- 敏捷开发生态系统系列之三:计划跟踪II(需求优先级排序-迭代期内无变更-团队承诺)
- 团队开发站立会议
- 敏捷开发中产品负责人与团队如何协作
- CowNew开源团队新书《自己动手写开发工具》隆重上市
- 团队开发任务01 搭建Android环境
- 敏捷开发生态系统系列之四:计划跟踪II(自组织团队-开发团队自己估算-PO挑战估算-同行压力)
- 如何从一个传统开发团队转向敏捷开发团队
- 软件需求说明文档--团队开发项目
- 敏捷开发“松结对编程”实践之五:代码检查篇(大型研发团队,学习型团队,139团队,师徒制度,代码审查)
- SCRUM敏捷团队开发体会
- [SCM]源码管理 - perforce与分布式团队的开发
- Git团队协作 - 新feature的开发过程
- 敏捷开发生态系统系列之四:计划跟踪II(自组织团队-开发团队自己估算-PO挑战估算-同行压力)
- 软件团队建设和开发管理及十种需要掌握的关键技术
- 用WM framework进行MVC团队组合模式的系统开发