《为什么软件开发方法论让你觉得糟糕》部分阅读

常见的软件开发过程方法有:瀑布模型、迭代增量开发、敏捷开发等。本文对以上三种加以介绍,同时还会介绍这两年火热的DevOps。
摘自英文原文:Why  Software  Development  Methodologies  Suck

围绕软件开发实践和方法论,总有很多教条式的口水仗.阶段式(phase -gate)方法能够有效管理软件开发过程的风险,还是说只是风险管理中的花哨噱头:? TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说,虽然缺乏证据判断这些论调的谬处,但有两条常用的法则能够帮助我们选择好的实践,同时,提升我们所提供软件的价值:划小开发周期以及提升反馈效率。

Michael Feathers给出了以下观点:

我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细

这事儿上。或许这是个经济

微差别。坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实井非如些。问题是,我们怎样才能找到有(合适)技能的开发者? IT 界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code)-在现在仍然是一 个主流的度量方法一深陷“一行代码一个责任”泥源,这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁钝,并导致低质量软件出现.目前还没有被普通接受的针对IT专业人才的专业要求系列标准和雇用范式,招聘好的人才,是一门(招聘)艺术,而非(招聘)工程。

心理学家至少对这个问题进行了研究:为什么IT业的技能很难被掌握和度量? Daniel Kahneman说(how you canget prototypes out as quickly as possible),以及模块化硬件和软件,以便你可以快速和独立地整合.3D printing(三维打印成型技术)技术看起来在这方面有着巨大的用武之地,因为它可以满足软件开发应用实践朝硬件系统(原型呈现)的演进。如果你想如区以偿地缩短周切,或多或少按多功能型团队(cross functional teams)方式运作是需要的。

软件方法论.即使雇用一群牛人井让他们自我组织,也是槽糕的,因为他们时常搞得“cargo-cult" (货物崇拜,敏捷开发里的知名小故事,形而上) :我们在做stand-ups (每日站立会议),我们有优先顺序的backlog (优先待办事务),我们甚至看在老天的份上实践了cont inuous integration (持续集成)。

织我们的到头来的结果为什么还这么差呢?因为你忘了最重要的事情:建立个学习能力和适应能力都很好的组织。

说说我的感受:就像那句老话说的一样,“好钢要用到刀刃上”,每个方法对每个人的作用都是不一样的,一个团队的协作也是,没有好的方法支撑,没有合适的管理模式,也是无效的,软件开发方法论也是一样,不是对每个团队都是这么有效的。实际的软件项目是很复杂的,没有规律可循,这会导致一个问题,为了证明某种技术、实践和方法论是实际有效而手机相关数据是极度困难的,几乎不可能在脱离收集环境的情况下归纳出这些数据的。失败的因素包括其中的一点就是:环境是不规律的,做出变更与理解变更带来的结果之间的反馈过程太长了。“变更”指的是广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值