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

印象最深刻的是老师上课讲过的关于就业的那些事，菜鸟在刚刚入职时总会对公司沿用的系统持有怀疑态度，于是一鼓作气推到沿用旧的体系，自己重做自己理想的系统，此系统也会被后人义重样的方式推翻，可我们仔细比较两者，却发现其中新事物却并不一定有旧事物好用。其实反观在我们学到的软件方法论依然也是同样的道理。我们或许会对前辈们留下的方法论抱有很大敌意，觉得他可能是限制我们学习与创作的一道枷锁，可是他的本意并不如此，可能仅仅只是为了给与遇到相似困境的我们一点启示。而时代日新月异，我们遭遇着的环境确实有着这样那样的不同，所以方法论给予我们的帮助或许也会不同，久而久之我们带上了有色眼镜，可是这难道能否定阶段式(phase-gale)方法能够有效管理软件开发过程的风险的作用？

Michael Feathers给出了以下观点：我认为，我们最终还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，要是人人都可以替代（随便找个人都能顶上），那该有多好呀？但事实并非如些。问题是，我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率，从这点来看，那么，要找到合适技能的开发者就是个很难解决的问题。代码行数现在仍然是一个主流的度量方法-深陷”一行代码一个责任”泥潭，这并不是一个好的方法。而度量工作小时数则是鼓励（个人）英雄式举动一经验表明，“英雄们”通常就是导致项目延期的人，依赖“英雄”往往是一开始就采取的不该采取的冒险行动，长时间工作导致人变得鲁纯，并导致低质量软件出现。

实际的软件项目是复杂的，没有规律可循，这会导致另一个问题－为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的，几乎不可能在脱离收集环境的情况下归纳出这些数据。当我们接触软件开发工作时，我们会发现开发环境是不可控制的，开发环境的不可控制会让我们遇到非常多的问题，这样会使我们的软件开发难以进行，而方法论的方向是让整个开发过程变得可控，事实证明，这是无法实现的，软件开发方法论的出发点是好的，但是完全可控的无法实现，这就需要我们正确对待处理方法论，让他成为我们的工具而不是障碍。