【写在最前：文章的很多观点是S老师讲授并且我觉得能引发我许久不动的大脑的一点零星火花的内容。在S老师上课之前，R老师曾就敏捷开发提出了诸多质疑，敏捷真的是拥抱变化的么？开发人员真的欢迎变化么？敏捷的方法真的如书中所说是高效、高质、高适应的么，是不是过度的吹捧？。。。。。。这一系列的反问，结合自己实习的经历，令我也很纠结。但是，曾有人说，存在就是合理，敏捷方法如今的应用远远不止“存在”的状态，而是一种真正的流行，公司、书籍、众多的会议活动，似乎都说明了这的确是一个值得推荐的方法。】
哲学上说，世界观指导方法论。在IT世界，每一种软件过程方法也有自己的价值观，以及与之对应的领域内的原则和实践活动。软件过程是将一个大的任务进行有序的分割，分割所遵循的最高，最抽象的规则，便是价值观，它解释了你为什么如此分割或者说它给了你进行这样分割的一个充分的理由。
在传统的软件方法中，项目的成功归结为：on time & on budget，即按时完成，符合预算，并且所有特性和功能都符合原先的设计规格。如果不符合其一，便被认定为不太成功或者不成功的项目。传统的软件开发方法似乎就是“计划驱动开发”，并且最后由原先计划去评审最后的产物。
而敏捷对于成功的定义最重要的标准在于：为客户创造价值，所有软件开发实践都应该以提升项目收益为首要目标。由此，对于变更，这个显然会破坏计划的活动来说，敏捷方法从价值观上有着更积极的态度。从这个层次上说，敏捷方法是拥抱变更的，特别是能够为客户带来更多收益的变更（通常市场部门或其他所做的变更不是无理由的，变更的初衷都是能够提升收益）。
Kent Beck在描述极限编程时说它是”一种软件开发哲学，一组实践，一套互补原则“，敏捷软件开发是一种思考软件开发的方法，真正要学习的人需要从价值观、原则以及实践三个层次上去学习。实践是天天做的事，你可能不知道为什么这样做，但是这是有价值的，实践是明确的、客观的、让价值观清晰可见的。但是，只懂实践的人缺少一个整体的概念，缺少什么时候该做什么事的判断能力。原则是在价值观和实践之间架起桥梁，在具体领域中给予指导方针。
应当说，价值观是普适的，而实践是具体的，理论上来说，可以以价值观之名做任何事情。这不禁让我联想起”没有银弹“。Brooks早在1986年便说”没有任何一种单纯的技术或管理上的进展，能够独立的承诺十年内使生产率、可靠性或者简洁性获得数量及上的进步，软件开发在根本上就是困难的“。任何的价值观不管如何普适，都应当从实践中来，到实践中去。而实践的方法偏偏很难做到普适，它是如此具体，或者在我看来，根本不存在这样普适的方法。前文曾经提到，价值观是教你应当在什么时机做什么工作，而能够这样的正确的价值观又需要大量的实践来支撑，不可能每个人都拥有。个人（或者说少部分精英）的能力与判断力似乎成为了项目成功的特别重要的因素（有很多例子佐证），似乎什么方法并不重要，而是领头人或者项目的决策者能否正确做出什么时间该做什么的决策。那么对于普通IT者个人来说，学习敏捷的意义何在呢？难道仅仅是具体实践的学习？不知原因的埋头实干却不知为何如此？我们真的能成为敏捷的专家么？想到这里，我的思维似乎进入了一个怪圈。
【后记：S老师最后问了个问题：你觉得在软件开发中是人更重要，还是过程（方法）更重要（没有说某方不重要），我们几乎都选择了人。但是，S老师对我们说，如果你们工作了很长时间，或许结论不会如此单一。对于还未真正进入工业界的我来说，目前对敏捷的学习，在于它提出了一个新的软件开发的思路，它鼓励我们去迸发出新的指导软件开发的思想火花，创建IT世界的诸子百家时代，并且我们了解了一些好的实践，虽然它不适用于所有场景。敏捷开发作为一种轻量级，减少管理和过程的负担的开发方法，作为一种选择方式，似乎更适合企业或者商业化而非个人。思想未免过于浅薄，仅以此篇记录目前所思所学。不知待回头看，是否会笑掉大牙。。。】
586
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
