关于敏捷开发的几点想法
11061151 庞梦劼
关于敏捷开发
敏捷开发是一种一人为核心、迭代、循序渐进的开发方法。在敏捷开发中，项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。
敏捷软件开发宣言摘要如下：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷型方法的特点
敏捷型方法是“适应性”而非“预见性”。 传统的工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等）有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的工作提供支持。
关于适应性与预见性
在实际实施项目的过程中，需求是一直在变化的。这并不是之前的需求分析做的好做的透彻就能避免的。即使你能把所有的需求都固定下来，并不意味着你的开发就是一帆风顺了，你可能仍然会在昏暗之中。在当今的经济形势下，决定并推动软件系统功能特性的商业因素飞快地变化着。现在一组很好的功能六个月以后可能就不那么好了。商业世界并不会因你的系统的需求固定下来了而停止不动，商业世界的许多变化是完全不可预测的。
一般来说，预见性在软件开发中是不可能的。那么，我们如何对付一个不可预测的世界呢？
“迭代式”（iterative〕开发方法是一种很好的方法，因为它提供了一个诚实的反馈机制来不断准确地告诉我们在开发中的情形处境。虽然迭代式开发也可用于可见性环境，但它基本上还是用作“适应性”（adaptive〕过程，因为适应性过程能及时地对付需求变更。需求变更使得长期计划是不稳定的，一个稳定的计划只能是短期的，这通常是一个“迭代周期”（iteration）。迭代式开发能让每个迭代周期为下面的开发计划提供一个坚实的基础。
关于“以人为本”
实施一个适应性过程并不容易，特别是它要求一组高效的开发人员。高效既体现在高素质的个体，也体现在有能让团队协调一致的工作方式。这里有一个有趣的和谐：并非只是适应性过程需要强的团队，多数优秀的开发人员也愿意采用适应性过程。
传统方法中将人看成是一种资源，他们具有不同的角色。个体是不重要的，只有角色才是重要的。敏捷型方法的一个重要特征就是否认参与软件开发的人员是可替代的部件这种观点。如果你期望你的开发人员是可互替的编程插件，则你不会去试着把他们看成是不同的个体。这会降低士气，并使优秀的人才跳到一个能发挥其个性特长的地方，最后你倒是得到你所需要的：可互替的编程插件。
敏捷型过程中“以人为本”的理念可以有不同的表现，这会导致不同的效果，而并非所有结果都是完全一致的。实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程。通常软件开发的的过程是由管理人员决定的，因此这样的过程经常受到抵制，特别是如果管理人员已脱离实际的开发活动很长时间了。而接受一个过程需要一种“自愿致力” （commitment），这样大家就能以积极的态度参与进来。
另一点是开发人员必须有权作技术方面的所有决定。极限编程非常强调这一点。 在前期计划中，它就说明只有开发人员才能估算干一件工作所需的时间。
写在最后
相比较于传统的边写边改开发方式，敏捷开发是一项新型的软件开发方式，它提供了一个新的思想，也提供了解决不可预见性的一个方法。但是在提高效率的同时也提出了一项新的挑战。
我认为，敏捷开发一项重要的关键是交流。用户与开发者的交流、管理者与程序员的交流、程序员之间的交流等等。但是对于我们东方人来说，我们比较内敛含蓄，开发者能否充分交流，管理者能否用于承担各种责任关系到敏捷开发能否成功。在敏捷开发过程中，程序员绝对不能一个人在战斗，不管你是架构师还是初级程序员。你需要的是大家一同完成项目进度，完成自己的职责，尽可能的找出迭代方法。这才是敏捷开发中需要的好程序员。