Why Software Development Methodologies Suck

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

Michael Feathers给出了以下观点:

我认为，我们最终还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，要是人人都可以替代(随便找个人都能顶上)，那该有多好呀,但事实并非如些。

问题是，我们怎样才能找到有(合适)技能的开发者,IT界从未很好地定义个体生产率，从这点来看，那么，要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭，这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明，“英雄们”通常就是导致项目延期的人，依赖“英雄”往往是一开始就采取的不该采取的冒险行动，长时间工作导致人变得鲁钝，并导致低质量软件出 现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式，招聘好的人才，是一门(招聘)艺术，而非(招聘)工程。

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

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

我们的到头来的结果为什么还这么差呢,因为你忘了最重要的事情:建立一个学习能力和适应能力都很好的组织。
原文
https://www.docin.com/touch_new/preview_new.do?id=816815583