印象最深刻的是老师上课讲过的关于就业的那些事,菜鸟在刚刚入职时总会对公司沿用的系统持有怀疑态度,于是一鼓作气推到沿用旧的体系,自己重做自己理想的系统,此系统也会被后人义重样的方式推翻,可我们仔细比较两者,却发现其中新事物却并不一定有旧事物好用。其实反观在我们学到的软件方法论依然也是同样的道理。我们或许会对前辈们留下的方法论抱有很大敌意,觉得他可能是限制我们学习与创作的一道枷锁,可是他的本意并不如此,可能仅仅只是为了给与遇到相似困境的我们一点启示。而时代日新月异,我们遭遇着的环境确实有着这样那样的不同,所以方法论给予我们的帮助或许也会不同,久而久之我们带上了有色眼镜,可是这难道能否定阶段式(phase-gale)方法能够有效管理软件开发过程的风险的作用?
Michael Feathers给出了以下观点:我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实并非如些。问题是,我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。代码行数现在仍然是一个主流的度量方法-深陷”一行代码一个责任”泥潭,这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动一经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁纯,并导致低质量软件出现。
实际的软件项目是复杂的,没有规律可循,这会导致另一个问题-为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的,几乎不可能在脱离收集环境的情况下归纳出这些数据。当我们接触软件开发工作时,我们会发现开发环境是不可控制的,开发环境的不可控制会让我们遇到非常多的问题,这样会使我们的软件开发难以进行,而方法论的方向是让整个开发过程变得可控,事实证明,这是无法实现的,软件开发方法论的出发点是好的,但是完全可控的无法实现,这就需要我们正确对待处理方法论,让他成为我们的工具而不是障碍。