为什么软件开发方法论让你觉得糟糕

首先站在一个初学者的观点(起码自己觉得自己还是个初学者)，在我们还没有进入软件开发的内部世界的时候，面对软件开发就像仰望一座大山，未曾攀登变有了些许胆怯(是否能学好？是不是非常难？为什么感觉学了蛮久还是云里雾里？)，于是乎我们又接触到了软件开发方法，一系列理论，理论上能帮助我们更加高效便捷的走进软件开发的世界，就好像在这座大山上突然出现了一条看不到终点的通天路，我们于是乎兴高采烈满怀希望的拾阶而上，或许我们会不再关系周围的风景，一个劲沿着方法论这个阶梯向上冲，或许我们在一段时间之后会感觉确实走了蛮远，感觉方法论不错，但是我们仍到不了终点，我们不曾观察我们周围的环境，而方法论这个阶梯越往上越难爬，或许是路开始模糊，或许是路开始越来越崎岖，当我们泪如雨下发现难以前行的时候，方法论这个阶梯或许就到头了，但是我们没到山顶，甚至我们自己在哪里都不清楚，我们想找一个其他的路继续向上爬，但是我们找不到，这座大山或许真正正确的攀登方式就是一手一脚的向上爬，直到我们渐渐熟悉了我们走过的每个地方，我们可以从容爬上去，也可以从容退下来。而我们沿着方法论一路不顾风景的走来，或许看起来我们登上了一个很远的位置，但是我们回顾下面，我们不敢，因为是那么陌生，我们抬头向上，却是难以继续行走，或许这个时候我们会感到软件开发方法论让我感觉糟糕。(个人看法)
因为还是个初学者还有点疲懒，所以可能有不少错误，以(后可能看见自己的萌新时期看法会发笑吧。)话不多说，继续这个话题。或许有两个方法能缓解这种感觉(为什么说缓解，不能彻底解决，因为看其他大佬写的，好像是:但软件工程的理论也不是完美的。正如《Why Software Development Methodologies Suck 》一文的作者所言，没有一个评价标准等缺陷是存在的。)第一点:我们可以先自我激励，不借助方法论而是一手一脚，一块石头一块石头的往上爬，然后感觉已经蛮远的情况，下来，再利用方法论顺着自己爬上去的那个路径走一遍，或许会融会贯通一点，哪些地方可能好走一点，或许风景好一点，或许自己会突然茅塞顿开一下，我说不出，因为还没走过。第二点:直接借助方法论向山上爬，但是放慢节奏，不急于求成，而是每走一步都想想如果没有这路，该怎么爬上来更省力气，然后分析并记住周围的风景 ，尽可能熟悉它，或许需要做到当这路消失的时候，我们还能爬上来，而不是路一旦消失我们就好像来到了一个陌生的大山。自己的看法就到这里，下面截取一下网上大佬们的一点看法。
银弹
我觉得没有银弹。开发是一个庞杂的事，不能一概而论，普适规则很难走得通。你的项目有一个大泥球么？有什么解决办法？A BIG BALL OF MUD is a casually, even haphazardly, structured system.有的。就后端来说，我们在进行查询的时候为了方便可能随手就写一个小函数进行数据库查询返回filter结果。在写任何新代码前规范好接口。不要随意写新的接口。大教堂与集市？大教堂：代码公开，但是只有特定团队能改。集市：代码完全自由。我们团队是大教堂模式。公布在github上，但只有我们团队能够修改。Worse is better?我觉得有一定道理。毕竟现在是利益至上的社会，质量的高低不是评判的唯一要素。所以我们在开发的时候，有时候会牺牲一些性能来保证功能的实用。瀑布模型划分块定期检查；按照某个模式运作；每个阶段都有每个阶段的任务，严格一个接一个执行；设定里程碑；每阶段都有文档。你的团队在开发中用了那些敏捷的思想和做法？每周5次开展scrum会议分析进度与接下来的工作。每开发出功能进行汇总。效果显著，比线上交流效率高。而且每天分析有利于持续发展。alpha和beta同样划分多个issue进行迭代。不会墨守成规，转变思维。软件工程的方法论到底有多少用处？国有国法，家有家规。软件工程的方法论就像是程序员进行开发的法典。小到个人的发展，大到企业的管理。都离不开软件工程的方法论。它对于我们每一个人的代码规范有很重要的作用，同样对于企业的管理也是不可或缺的，可以想象一个没有规范的世界是多么混乱。我可以感受到我们的项目正是在软件工程的思想下才能基本井井有条地往前进行，否则每个人各写各的会非常难以合到一起管理。但软件工程的理论也不是完美的。正如《Why Software Development Methodologies Suck 》一文的作者所言，没有一个评价标准等缺陷是存在的。

围绕软件开发实践和方法论，总有很多教条式的口水仗。阶段式(phase-gate)方法能够有效管理软件开发过程的风险，还是说只是风险管理中的花哨噱头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说，虽然缺乏证据判断这些论调的谬处，但有两条常用的法则能够帮助我们选择好的实践，同时，提升我们所提供软件的价值：划小开发周期以及提升反馈效率。 Michael Feathers给出了以下观点：
　　我认为，到了最后，我们还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别[1]。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，但如果人是可以轻易轮换的(随便找个人都能顶上)，那才是堪称理想的。　　问题是，我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率，从这点来看，那么，要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭，这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明，“英雄们”通常就是导致项目延期的人，依赖“英雄”往往是一开始就采取的不该采取的冒险行动，长时间工作导致人变得鲁钝，并导致低质量软件出现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式，招聘好的人才，是一门(招聘)艺术，而非(招聘)工程。　　心理学家至少对这个问题进行了研究：为什么IT业的技能很难被掌握和度量Daniel Kahneman说(Thinking Fast and Slow)，掌握技能有两个基本条件：一个环境足够规律以便可预测;有机会通过长时间实践来学习掌握这些规律。　　但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是：最终的结果通过整个生命周期里的实施达到了预期目标吗? 很难知道什么关键活动导致了项目成功和失败，很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败(在人工智能领域，这叫作信度分配问题)。　　这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而，开发者掌握能帮助他们更高效地达到目标的技巧，将使他们更有动力 – 通常称之为“开发完成”，尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。　　实际的软件项目是复杂的，没有规律可循，这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的，几乎不可能在脱离收集环境的情况下归纳出这些数据。 在Laurent Bossavit的好书The Leprechauns of Software Engineering中，他抨击了软件开发的一些惯式，比如“成本变化”(或“缺陷成本”)“曲线”，这些惯式是许多其它的软件开发方法论知识基础，称开发人员生产率的变化是一个数量级(参照确定性金字塔原理)。Laurent Bossavit说明了相关依据 – 很多人依赖从计算机科学专业学生进行的非正式试验或是从无法被有效控制的项目中收集小量数据。这些研究组织的给出的论调基础往往是不健全的，数据缺乏分析，而且，最过分的是调查结果普遍远远超出了他们的适用领域[2]。　　因此，不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适，反之亦然。“方法大师”的见解其实也没太大指导意义，就像Kahneman说的，“人们在想法方面的信心，并非是有效行事可倚重的因素…当评估专家的想法，即使在有规律可循的情况下，你也一定要想清楚是否有合适时机可以引入其想法的可能性”。就像Ben Butler-Cole指出的(why software development methodologies rock)，引入一种新方法往往会带来一些影响。　　你可能会认为当我们决定怎样运作一个团队时，我们就陷入了被动。但细想一下为什么软件开发无章可循?为什么在这个环境里很难进行一些试验以及获取技能?什么实践和决定会导致成功或失败?其中的根原因就是：环境是不规律的，做出变更与理解变更带来的结果之间的反馈过程太长了。这里的“变更”一词是指广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。　　还是有一些办法帮助缩短周期的，比如当我们应用精益软件开发思想 – 一个很重要的方法。缩短开发周期在大型产品开发中是很重要的：在Bret Victor的精彩视频Inventing on Principle中提到，“如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物”。　　但对我而言就是这样的：我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。除非我们聚焦于尽可能使反馈间隔时间缩短，以便实际洞察其间关联，以及辨别原因和影响。　　事实上，从想法到反馈的周期尽可能短的好处是如此明显和重要，应该把其作为商业模式中要遵循的一个重要原则。如果你纠结于要把你的产品创建成一个用户安装式的软件还是SaaS模式(software-as-a-service，软件运营服务模式，软件即服务)，这时的想法会自然而然地推动你强烈考虑 SaaS模式(有感而发)。如果你要重建你的系统(包含硬件)，应该考虑怎样尽快实现原型(how you can get prototypes out as quickly as possible)，以及模块化硬件和软件，以便你可以快速和独立地整合。3D printing(三维打印成型技术)技术看起来在这方面有着巨大的用武之地，因为它可以满足软件开发应用实践朝硬件系统(原型呈现)的演进。如果你想如愿以偿地缩短周期，或多或少按多功能型团队(cross-functional teams)方式运作是需要的。 软件方法论，即使雇用一群牛人并让他们自我组织，也是糟糕的，因为他们时常搞得“cargo-cult”(货物崇拜，敏捷开发里的知名小故事，形而上)：我们在做stand-ups(每日站立会议)，我们有优先顺序的backlog(优先待办事务)，我们甚至看在老天的份上实践了continuous integration(持续集成)。我们的到头来的结果为什么还这么差呢?因为你忘了最重要的事情：建立一个学习能力和适应能力都很好的组织。　　1.虽然像Laurent Bossavit说的(私下交流)，“一个开发者掌握的技能，受限于他/她所掌握的方法及他/她偏好一种语言甚于其它语言”。　　2.我并非建议放弃在软件开发中的可行性试验，在这里的上下文中，我这么阐述是对的。恰恰相反的是，我说的是我们并没有努力去做好，做得还远远不够。
　　10.27~晴