2020-10-22

推荐阅读:Why Software Development Methodologies Suck

围绕软件开发实践和方法论,总有很多教条式的口水仗。阶段式(phase-gate)方法能够有效管理软件开发过程的风险,还是说只是风险管理中的花哨噱头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说,虽然缺乏证据判断这些论调的谬处,但有两条常用的法则能够帮助我们选择好的实践,同时,提升我们所提供软件的价值:划小开发周期以及提升反馈效率。
Michael Feathers给出了以下观点:
我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实并非如些。

问题是,我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭,这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁钝,并导致低质量软件出 现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式,招聘好的人才,是一门(招聘)艺术,而非(招聘)工程。
  心理学家至少对这个问题进行了研究:为什么IT业的技能很难被掌握和度量?Daniel Kahneman说(Thinking Fast and Slow),掌握技能有两个基本条件:一个环境足够规律以便可预测;有机会通过长时间实践来学习掌握这些规律。
  但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是:最终的结果通过整个生命周期里的实施达到了预期目标吗? 很难知道什么关键活动导致了项目成功和失败,很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败(在人工智能领域,这叫作信度分配问题)。
  这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而,开发者掌握能帮助他们更高效地达到目标的技巧,将使他们更有动力 – 通常称之为“开发完成”,尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。
  实际的软件项目是复杂的,没有规律可循,这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的,几乎不可能在脱离收集环境的情况下归纳出这些数据。
  软件方法论,即使雇用一群牛人并让他们自我组织,也是糟糕的,因为他们时常搞得“cargo-cult”(货物崇拜,敏捷开发里的知名小故事,形而上):我们在做stand-ups(每日站立会议),我们有优先顺序的backlog(优先待办事务),我们甚至看在老天的份上实践了continuous integration(持续集成)。
  我们的到头来的结果为什么还这么差呢?因为你忘了最重要的事情:建立一个学习能力和适应能力都很好的组织

©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页