在《速度与激情1》中,我们看到周末的洛杉矶街头,亡命飞车大战拉开一场又一场序幕。许多年轻人带来了其经过精心改装的赛车,想尽办法,拼命在获得赛车比赛的第一,因为取得冠军也意味着赢得荣誉和财富。这部电影很好的诠释了速度的重要要性,它关系的财富,关联着生命。从另一个方面讲,我们也可以把速度看作是一种敏捷性。
IT开发行业,速度/敏捷同样也是企业、开发团队所追求的目标。在四月的软件测试专业人士大会上,Rex Black说敏捷方法已经开始加速。他的同事佛罗里达理工学院软件工程教授回答说,敏捷软件开发已经成为主流,那些还没有做敏捷的人或企业将会处理落后的位置。
15年前,有人说面向对象编辑还是一种新的方法,提供了一些了不起的东西,同时也有大量需要挑战的陷阱。现在除了嵌入式和遗留系统个,每个公司都在使用面向对象编程语言,如Java、Ruby或c#。而面向对象只能在新生课本上找到了。这并不意味着,面向对象编程(OOP)走向失败,相反它正在成为主流。而现今敏捷方法也在如法炮制。
公司规模和实施更改的阻碍影响了公司敏捷开发的方式?
在2012敏捷开发调查中,对于“你的组织否使用了敏捷开发?”这一问题的调查,有84%的回答是肯定的,另外有54%的人声称他们有计划使用scrum。Software AG公司的CMO Totev解释说,在采用敏捷时的一个重大障碍是改变。敏捷的思想是快速测试、快速发布,及快速反馈周期;但大型遗留项目、数据库项目以及保护服务的一些系统,这些都极难改变;这些额外开销使敏捷思想成为挑战。
Dave Nicolette是一位敏捷教练,他也同意此说法。他说,如果你的团队是封闭的,没有依赖他人,那么你可以快速、顺畅地进行你的工作。但一旦你有协调工作,你就不得不做更多的事先计划。这并不意味着没有在做敏捷,它只是需要更多的额外开销。
另外,Nicolette还看到的了公司规模对敏捷的影响。Nicolette同意说小型项目并不需要存档流程。如果你的公司中人有200人,只有少数软件正在开发,那么你根本就不需要什么流程。但如果你的公司有2000人,有上百个软件正在开发,还有一些现有流程和遗留代码库,那么你就不能很好地利用敏捷思想,就不能顺利进行工作。
OOP真实现状:有形式但无实质
大部分人都在探讨面向对象编程,但他们的编码也编辑所提倡实际上存在一些不同。OOP“品牌”,或所谓的“官方”品牌,有一些规则,如单一责任和依赖倒置。这些规则导致了极其紧密的功能和小于三的圈复杂度(这意味着代码具备高度测试性,而且易于修复)。但大多数人并没意味到这些规则的存在。
现在我们看看今天的敏捷团队。存在相同的一些事情:顺着墙上的卡片有“产品负责人”、“冲刺”、每日站立会议和演示日。所有这些都是敏捷的特点。不过,在大多数情况下,工作是经由经理批准的,由个人完成,根据公司标准记录,这是不可改变的。有调查显示,大部分人有可能会拥抱敏捷方法,只有43%的团队使用测试驱动开发,30%采用结对编程。
伴随着敏捷开发,我们已经经过了很长的一段路程,但有一个风险,同样也是OOP的风险:我们有一些不形式,但却缺乏实质。
把技术性敏捷实践转变为一种文化
另一位敏捷教练Jon Kern称这种风险为“人类的本性”。正如Jerry Weinberg所说越广泛的传播,得到的东西越浅显。
这不仅仅是传播、是炒作。如有着事例、冲刺和更快速的发布的项目管理这样的实践已经得到的更好的采用,而如测试驱动开发和持续集成这样的技术性实践并没有得到很好地采用。技术性实践比文化性的采用的更为广泛,这些文化如团队所有流程、多学科、自我组织的团队和持续结对。这三种形式都是敏捷的类别,但可能会把文化性实践称为敏捷的“心脏”。
现在以市场为导向的公司似乎都开始拥抱了项目管理方面的敏捷软件。而在其它方面又存在着改进的空间,这意味着存在着更大竞争优势。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
面对软件测试未来的变化
不幸,如今很多软件测试职位都 处于两难的境地。在更快开发并且发布应用的巨大压力之下,企业都会促使测试人员更新他们的技能。
-
DevOps和敏捷相结合 改进软件质量
DevOps实际上是打破了开发人员和运维人员之间的壁垒。在运维团队,你所考虑的方面可能与开发团队不同。但如果我们能更加了解相互的工作,将会更为深入得理解所需的工具和设备。
-
协作对敏捷方法的重要性
协作的意思说是一起工作,而不是单独去完成某项任务。敏捷方法强调了与跨功能团队合作的好处,大大加强了业务负责人之间的沟通。
-
敏捷扩展的九条原则
对于敏捷扩展,并没有按部就班的方法,但有了固定的原则,软件开发团队将会有据可依地创建高质量的企业软件。