为何Google这类巨头会认为敏捷开发原则是废话？

3顶
1踩

2015-04-13 15:35 by 副主编 mengyidan1988 评论(11) 有7333人浏览

敏捷开发 google

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

【编者按】这是一个来自Quora的问题。Rocket程序员Jasmine Adamson在文中表达了敏捷开发原则是废话的观点，他觉得现实生活中没有什么人会推崇这些原则来工作，不过他们仍然在说其所做的是敏捷，这是非常让人沮丧的。

以下为译文：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在过去8年里，我一直工作于“Agile”开发小组，所以让我用敏捷开发原则来告诉你事实，或许你会明白为什么那些在像Google这样巨头公司工作的开发者会认为敏捷开发是废话。

1.及早并持续的交付有价值软件来满足客户需求的优先级是最高的

“我的客户一直由其他业务部门接洽，我从未见过我的客户，我不知道他们是做什么的。”这是现如今大多数公司的真实写照。

2.欢迎需求变更，即便是在开发的后期。为了客户的竞争优势

没有人愿意接受改变需求。这就是第二个敏捷原则，普遍被厌恶的一个。

3.频繁交付软件，倾向于较短时间跨度

部分公司在这方面做的很好，但是大多数团队无法很好的掌控敏捷时间的尺度。交付时间表通常是基于大的更新，而大更新不属于敏捷。

4.业务人员与开发者的绑定模式一直贯穿项目始末

开发者和业务人员一起工作是罕见的，大多数公司都会有一个中间人来促进这种关系，然后效果是不理想的。开发者需要直接对话的应该是直接使用程序的人，而不是他们的经理。现实生活中的需求往往是由几个个层次以外的人来决定，而不是直接从用户到开发者那来的。

5.激发个体的斗志，以他们为核心创建项目——大多数人都不知道这表达了什么。

这意味着低水平的员工对软件有最好的注意，并且他们积极的去解决问题。项目围绕这些欲望来构造，而这也了直接影响公司的底线。

5a.为他们提供所需的环境和支援，辅以信任，从而达成目标。

这是关于开发者的，你曾经有过这样的工作环境吗？你所需要的工具、访问权限和配件都有。或许不用多说什么了，不是吗？

6.不论团队内外，传递信息效果最好、效率也最高的方式是面对面交谈。

这句话的意思是告诉我不能用IM和邮件来交流吗？如果团队的成员分散于各地呢？我改进现有软件的最有效方法是站在某人后面看他使用。然而在大多数公司中，你做不到这样，即便你知道客户是谁。他们也是忙的无暇顾你，也有可能是其他原因。现如今的人际交往不再像从前那样。不是吗？

7.可工作的软件是进度的首要度量标准

我们所在测量的都是类似于缺陷率、工作时间等事情，几乎从来没测量过这些事项：顾客得到可工作的功能了吗？我们发布了多少个可工作的功能？这些功能是大、中还是小的？没人知道。

8.敏捷过程倡导可持续开发。负责人、开发者和用户要能够共同维持其步调稳定延续。

这意味着每个人每周都要花30个小时在开发上，还需要花10个小时管理自己和工作负载、与他人沟通等等。这样才能保证这种做法持续下去。更多公司所做的是不定时的加班，有的则是经常加班。这是不可持续的。敏捷模式很少进入这样的紧急模式，而你则是经常性的。

9.坚持不懈的追求技术卓越和良好设计，增强敏捷能力。

在我看来这是对原则1和7的正确权衡。

10.以简洁为本，极力减少不必要的工作量

坦白来讲，大多数团队并没在这上面花费足够多的时间，我们最终不仅复杂了软件，也复杂了开发习惯、复杂了代码，这减缓了维护和新开发。

11.最好的架构、需求和设计出自自组织的团队

团队是由管理层组织的，几乎没有他们自己的事。不过这只是一个企业文化的问题，并很难被克服。有时在初创公司和小公司你可以发扬这种原则并让其工作，但是在大多数大公司，还是算了吧。

12.团队定期地反思如何能提高成效，并以此调整自身的举止表现。

这更多地算是一种常见的绩效考核形式，没有我们真正想要的层面。敏捷想要的是“作为一个团队，一起坐下来看看我们做了什么，如何在下一次做的更好”。然而实际上所发生的是个人主观上的计算和测量，基于这些团队几乎得不到任何实际的改进。

所以说敏捷是废话，因为没有人会推崇这些原则来工作，不过他们仍然在说其所做的是敏捷，这是非常让人沮丧的。

敏捷方法存在很多废话，但是同样的废话也会存在于新的软件开发中，从面向对象到面向服务的体系结构等等。一个真正的敏捷方法不适用于紧急状况，更多的是为了产品创新。如果作为准备，他可以改变整个组织，Salesforce从2007年就开始使用Scrum，这使它们能够创建一个可预测的发布周期。并因此而创建越来越多令人印象深刻的功能和产品。

需要明确的是，敏捷方法不是良方，有能力的人、勤奋、专注和自律造就优秀的软件开发。

分享到：

3
顶

1
踩

评论共 11 条请登录后发表评论

11 楼 ray_linn 2015-04-20 11:17

一直觉得敏捷只适合不太复杂的项目 (Project) 不适合大项目 (Program)。在program 中，每个变更都必须被管理，因为变更之后都会牵涉到成本和报价。一张标贴、一个流程、都需要多方评估，给出价格

10 楼 ray_linn 2015-04-20 11:12

theoffspring 写道

zjumty 写道

引用

这意味着低水平的员工对软件有最好的注意

这里的低水平员工原文是" low level employees" 应该翻译为底层员工. 不是指能力水平低的员工.

意思其实就是低水平，经验欠缺者，否则也不会是底层了。

脑残....你们公司有人力地图吗？Lower Level 指的是人事经理带的人，高级程序员、程序员、架构师，这些都属于lower level，干活的人。

9 楼 theoffspring 2015-04-19 12:12

我们公司的一个项目用过scrum，最后做黄了，原因是总是让客户看到你做的中间版本，每次看完客户的需求都会变，每次都以架构师和客户吵起来为结束。

8 楼 theoffspring 2015-04-19 12:11

zjumty 写道

引用

这意味着低水平的员工对软件有最好的注意

这里的低水平员工原文是" low level employees" 应该翻译为底层员工. 不是指能力水平低的员工.

意思其实就是低水平，经验欠缺者，否则也不会是底层了。

7 楼 kadeya 2015-04-17 15:58

说实话，我没怎么看懂。

6 楼 sherryxiu 2015-04-15 13:59

各有个的优势，看你怎么用，在什么情况下使用。

5 楼 sherryxiu 2015-04-15 13:58

有些东西楼主明显较真。

4 楼 ray_linn 2015-04-14 18:00

团队是由管理层组织的，几乎没有他们自己的事 --- 明显翻译错误，要表达的意思是：团队都是管理层弄起来，从来没有自组织的。

3 楼 ray_linn 2015-04-14 17:53

我觉得除了迭代式开发之外，敏捷大部分都是小软件公司的呓语。

2 楼 wondery 2015-04-14 09:30

另一种视角，挺好。

1 楼 zjumty 2015-04-13 16:54

引用

这意味着低水平的员工对软件有最好的注意

这里的低水平员工原文是" low level employees" 应该翻译为底层员工. 不是指能力水平低的员工.

发表评论

您还没有登录,请您登录后再发表评论

3顶1踩