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

jopen 9年前

英文原文:Why do some developers at strong companies like Google consider Agile development to be nonsense?

这是一个来自 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,这使它们能够创建一个可预测的发布周期。并因此而创建越来越多令人印象深刻的功能和产品。 

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

来自: www.iteye.com