为什么软件开发方法论让你觉得糟糕?观后感
文章开篇就提出了一个问题:我们怎样才能找到合适的开发者?并指出用代码行数的标准来度量一个程序员是否优秀是不合理的。这个观点我是认同的,就像打一千行HelloWorld和打十万行HelloWorld的效果是一样的,度量工作小时自然也不是一个好的标准,随着工作时间的增长,人的专注度和精准度是会大幅下降的,自然开发不出什么好的软件。
为什么IT业的技能很难被掌握和度量?
掌握技能有两个基本条件:一个环境足够规律以便可预测;有机会通过长时间实践来学习掌握这些规律。
但事实是软件项目往往是没有规律及可预测环境的。
软件的开发本就是一个漫长的过程,在开发的过程中也无规律可循,只能按照要求进行开发,只有在开发结束后才能去判断其是否符合预期,如果出现问题也无法确定是其中的哪个环节出现了问题,也无法总结出什么有用的结论,因为它无规律可循。
文中作者认为:
从想法到反馈的周期尽可能短的好处是如此明显和重要,应该把其作为商业模式中要遵循的一个重要原则。
这个说法只能说利弊共存,它的好处确实明显,比如可以尽早实施下去,尽快的做出试用版,出现问题或者不理想地方可以及时改正。
但缺点也是同样的明显,当一款软件被快速的开发出来后,程序员的惰性会被放大,专注度会下降。因为去改进一个已经完成的半成品总是没有去开发一个新的软件的动力高的。
作者在文章尾段写道:
软件方法论,即使雇用一群牛人并让他们自我组织,也是糟糕。
因为你忘了最重要的事情:建立一个学习能力和适应能力都很好的组织。
但很多时候并非是忘记,而是不得不进行妥协。环境是在改变的,人也是在改变的就像作者在文章开头提到的,把代码行数和工作时间当成标准是不可取的,但也表明了 并没有一个好的标准一样。想建立一个学习能力和适应能力都很好的组织也是一件难事,更何况我们也没有一个标准,什么样的组织能算作学习能力和适应能力都很好的组织呢?