Adobe团队开发：增量开发那么好，何乐而不为？

注：因为时间关系没有翻译完，而且采取的是意译，不通畅的地方请参照文末提供的原文链接，谢谢。

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