2022春软件工程课后作业（3.23）

Q：Why Software Development Methodologies Suck？（为什么软件开发方法论让你觉得糟糕）

初看这篇文章，由于看的是翻译过的文章，感觉较为的生涩一下子没能抓住作者想要表达的观点。后再反复阅读与回看原文，大概了解了可能想要表达的意思，在这里稍微做一些反馈。

作者在一开始抛出了三个反问句，引导我们思考，我们在软件工程这门课里面学习到的那么多方法，比如说瀑布式、增量式和敏捷开发。真的能够让我们面对日后的开发项目高枕无忧吗？答案自然是否定的，作者认为，真正重要的其实是开发者的开发能力，但“开发能力”这四个字本身就是看不见摸不着的不能被量度的object。现在主流的一些方法，比如说代码行数，工作时长都不能完完全全反映出来。相反的，这些指标正代表了某种消极因素。

既然计算机界并不能给出一些明确的定于，就应该试着去找外界的“救兵”了。而心理学家通过研究后发现，为什么IT业的技能很难被掌握和度量？是因为软件项目往往是没有规律及可预测环境，开发者耗费巨大时间精力做出来的成果，不能被定义为传统意义上的“成功”与“失败”，则他们没有办法得到积累的较为深刻的经验。

        软件项目是复杂的，没有规律可循，也会导致另一个问题 -——如何证明某种技术、实践和方法论是实际有效，几乎不可能没办法收集到脱离环境的数据，这些数据也不足以支撑上述观点。也许，我们可以从这里反推回去：环境是不规律的，做出变更与理解变更带来的结果之间的反馈过程太长了。那么，我们可以在短时间内快速开发出一个模块，在环境还没开始发生显著性变化时就对此进行期望测试，当剑刚掉下去的时候便立马展开捕捞工作，这样，“刻舟求剑”中的尴尬便不会在软件开发中上演。

在Bret Victor的精彩视频[Inventing on Principle]中提到，“如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物”。

        由此我们已经得到了结论：缩短开发周期在大型产品开发中是很重要的。同时，拥有强大开发能力的大牛固然很重要，但如果他们也陷入了教条主义的“陷阱”，结果是可想而知的。所以，建立一个学习能力和适应能力都很好的组织。是本文作者期望我们知道的。

 我并非建议放弃在软件开发中的可行性试验，在这里的上下文中，我这么阐述是对的。恰恰相反的是，我说的是我们并没有努力去做好，做得还远远不够。

                                                                                                                      ——Jez Humble

原文作者：[英] Jez Humble，第21届Jolt大奖获奖作品[《持续交付》]作者，该书被誉为2010年最重要的技术书。 

共勉❤