【编者按】这是一个来自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,这使它们能够创建一个可预测的发布周期。并因此而创建越来越多令人印象深刻的功能和产品。
需要明确的是,敏捷方法不是良方,有能力的人、勤奋、专注和自律造就优秀的软件开发。