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

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

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

时间: 2024-10-14 20:44:27

为何Google这类巨头会认为敏捷开发原则是废话?的相关文章

敏捷开发-原则 模式与实践(1)

敏捷开发-原则 模式与实践 这的确是一本关于开发者的好书,对于我们开发者.研究人员,它提出了一个开发的全新的价值观(对我来说),甚至人生都有启发.需要认真阅读. 书中总结了敏捷开发的实例,确确实实更够感觉到对于项目的完成大有裨益,有种相读恨晚的感觉.想想自己之前的开发状态,想想自己导师安排公司项目的情况,就是低效率,就是小儿科,就是书上批评讽刺的那样,这正是开发者十几年开发智慧的结晶,前人的经验,前人的智慧,激发了我的阅读的快感,我获取知识的兴奋感,激发了我的成就感. 阅读前两天(结合思维导图)

敏捷开发原则

尽可能早地提供宝贵的软件,不断满足客户需求 敏捷流程欢迎需求的变化,并利用这一变化来提高用户的竞争优势 经常发布可用的软件,发布间隔可以从几周到几个月,可以长或短 商业人士和开发人员应在项目开发过程中每天合作 为了项目核心人才,充分支持他们的信任 面对面沟通永远是团队内外沟通最有效的沟通方式 可用的软件是项目进展的关键指标 敏捷流程应该能够持续维持发展.领导,团队和用户应该能够继续合作 只有继续关注技术和设计,才能越来越敏捷 保持简单 - 尽可能简化工作的技能非常重要 只有自我管理的团队才能创造

敏捷开发原则-SRP(单一职责原则)

SRP(Single Responsibility Principle): 定义:就一个类而言,应该仅有一个引起它变化的原因.(类,接口,方法等,都应该使用该原则) 如果一个类承担了过多的职责,那么引起该类变化的原因也会随之变多. 例如: 一个图形类中包含了draw() 绘画功能和 area(), setWidth(), setHeight() 等图形自身的属性. 这样的话 如果图形属性的计算方式发生改变,则这个类就要做出对应的修改.同样的,如果图形的绘画功能做出改变 那么这个类也要同步的做出修

浅谈敏捷软件开发与传统软件工程的对比与敏捷开发产生的原因

引言 在"计算机程序的蛮荒时代",人们对于程序的设计.编写是随想随写.灵活变化的.正如我们初学各种编程语言时那样,似乎把程序写对也不是什么很难的事情.然而,这种程序设计模式或许适用于几百行至几千行的小程序,而当我们面对更大的软件规模.更多的代码行数以及更复杂的人员架构时,这种随想随写的程序开发模式似乎不再适用,于是使人们遇到了「软件危机」,进而促使了软件工程这样一门学科的产生. 在我上一门程序设计的课程的时候,老师讲过,当我们学习各种语言.算法和数据结构时,我们学习的是怎样进行&quo

敏捷开发的26条至理名言 快速迭代式开发使用方法总结

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动. 本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显

利用敏捷开发的原则开发自己的大学生校园博客系统

  敏捷开发原则 我们的做法 1 尽早并持续交付有价值的软件以满足顾客需求 软件暂时未完成,但目前已经交付某些文档,可以通过文档与用户进行交互. 2 欢迎需求的变化,并利用这种变化来提高用户的竞争优势 不时向同学询问或自我思考看自己所要做的能否使大学生满意. 3 经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 由于我们的项目是要求在一个月内进行交付,所以我们并没有进行软件的交付,但是我们每周都会交一些设计文档,对项目及完成进度进行说明. 4 业务人员和开发人员在项目开发过程中应该每天共

杨学明老师推出全新课程--《敏捷开发&IPD和敏捷开发结合的实践》

课时:13小时(2天) 敏捷开发&IPD和敏捷开发结合的实践 讲  师:杨学明 [课程背景] 集成产品开发(IPD).集成能力成熟度模型(CMMI).敏捷开发(Agile Development)是当前国内外企业产品研发管理的最常用的3种模式.随着创新环境的快速发展,许多企业都会面临这样的问题:如何快速响应市场的变化?如何推出更有竞争力的产品?如何在竞争中脱颖而出?……是大部分研发型企业普遍面临的核心问题.另外,软件项目在产品开发中位置越来越重要,逐渐占领主导地位,这时传统的IPD流程和CMMI

敏捷开发与XP实践

北京电子科技学院(BESTI) 实  验  报  告 课程: Java        班级:1352          姓名:黄伟业         学号:20135215 成绩:               指导教师:娄嘉鹏    实验日期:2015.6.2 实验密级:         预习程度:             实验时间:15:30~18:00 仪器组次:37         必修/选修:选修       实验序号:(三) 实验名称:敏捷开发与XP实践 实验目的: 1.XP基础 2.

20135231 JAVA实验报告三:敏捷开发与XP实践

---恢复内容开始--- JAVA实验报告三:敏捷开发与XP实践 20135231 何佳 实验内容 1. XP基础 2. XP核心实践 3. 相关工具 实验要求 1.没有Linux基础的同学建议先学习<Linux基础入门(新版)><Vim编辑器> 课程 2.完成实验.撰写实验报告,实验报告以博客方式发表在博客园,注意实验报告重点是运行结果,遇到的问题(工具查找,安装,使用,程序的编辑,调试,运行等).解决办法(空洞的方法如“查网络”.“问同学”.“看书”等一律得0分)以及分析(从中