软件开发方法论

    围绕软件开发实践和方法论，总有很多教条式的口水仗。阶段式方法能够有效管理软件开发过程的风险，还是说只是风险管理中的花哨噱头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说，虽然缺乏证据判断这些论调的谬处，但有两条常用的法则能够帮助我们选择好的实践，同时，提升我们所提供软件的价值：划小开发周期以及提升反馈效率。
到了最后，我们还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别[1]。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，但如果人是可以轻易轮换的(随便找个人都能顶上)，那才是堪称理想的。
问题是，我们怎样才能找到合适技能的开发者?IT界从未很好地定义个体生产率，从这点来看，那么，要找到合适技能的开发者就是个很难解决的问题。代码行数在现在仍然是一个主流的度量方法。深陷“一行代码一个责任”泥潭，这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明，“英雄们”通常就是导致项目延期的人，依赖“英雄”往往是一开始就采取的不该采取的冒险行动，长时间工作导致人变得鲁钝，并导致低质量软件出现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式，招聘好的人才，是一门(招聘)艺术，而非(招聘)工程。
　　但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是：最终的结果通过整个生命周期里的实施达到了预期目标吗? 很难知道什么关键活动导致了项目成功和失败，很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败。
这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而，开发者掌握能帮助他们更高效地达到目标的技巧，将使他们更有动力 – 通常称之为“开发完成”，尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。
实际的软件项目是复杂的，没有规律可循，这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的，几乎不可能在脱离收集环境的情况下归纳出这些数据。
因此，不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适，反之亦然。“方法大师”的见解其实也没太大指导意义，人们在想法方面的信心，并非是有效行事可倚重的因素…当评估专家的想法，即使在有规律可循的情况下，你也一定要想清楚是否有合适时机可以引入其想法的可能性。
　　还是有一些办法帮助缩短周期的，比如当我们应用精益软件开发思想。一个很重要的方法。缩短开发周期在大型产品开发中是很重要的。如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物。
    我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。除非我们聚焦于尽可能使反馈间隔时间缩短，以便实际洞察其间关联，以及辨别原因和影响。
事实上，从想法到反馈的周期尽可能短的好处是如此明显和重要，应该把其作为商业模式中要遵循的一个重要原则。如果你纠结于要把你的产品创建成一个用户安装式的软件还是SaaS模式，软件运营服务模式，软件即服务，这时的想法会自然而然地推动你强烈考虑 SaaS模式。如果你要重建你的系统，应该考虑怎样尽快实现原型，以及模块化硬件和软件，以便你可以快速和独立地整合。3D printing技术看起来在这方面有着巨大的用武之地，因为它可以满足软件开发应用实践朝硬件系统的演进。如果你想如愿以偿地缩短周期，或多或少按多功能型团队方式运作是需要的。软件方法论，即使雇用一群牛人并让他们自我组织，也是糟糕的，因为他们时常搞得货物崇拜。
　　一个开发者掌握的技能，受限于他所掌握的方法及他偏好一种语言甚于其它语言。
我并非建议放弃在软件开发中的可行性试验，在这里的上下文中，我这么阐述是对的。恰恰相反的是，我说的是我们并没有努力去做好，做得还远远不够。