敏捷开发读后感
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。毫无疑问，敏捷开发方法正在大举进军今天的企业，但是通往敏捷的道路却是崎岖的。它更像是一条多车道的高速公路，各种类型的司机们都在选择各自适合的路线向目的地进发。
软件开发背景介绍
软件开发的发展经历了从无、到繁重、再到敏捷的过程。与我们刚开始学编程的时候一样，早期多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改”。设计过程充斥着短期的、即时的决定，而无完整的规划。 这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典 型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。
软件行业中最初的一场运动是要改变这种情况，而引入了“正规方法”的概念。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他 工程领域的实践 － 因此我把它们称为工程方法。工程方法已存在了很长时间了，但是没有取得令人瞩目的成功，因为它有做太多的事情需要做，从而延缓整个开发进程。
敏捷型方法的发展是对这些工程方法的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。敏捷型与工程型方法有一些显著的区别，通常只要求尽可能少的文档，认为最根本的文档应该是源码。但是，我认为文档减少仅仅是个表象。
敏捷型方法的适应性
敏捷型方法是“适应性”而非“预见性”。 工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划， 然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等） 有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。一般来说预见性是不可能的。那么，我们如何对付一个不可预测的世界呢？最重要，也是最困难的是要随时知道我们在开发中的情形处境，这需要一个诚实的反馈机制来不断准确地告诉我们。这种机制的关键之点是“迭代式”开发方法。迭代式开发的要点是经常不断地生产出最终系统的工作版本，这些版本逐步地实现系统所需的功能。它们虽然功能不全，但已实现的功能必须忠实于最终系统的要求，它们必须是经过全面整合和测试的产品。满足用户不断变化的需求是软件开发的长期无法解决的难题之一，经典的瀑布模式在一个迭代周期内表现优异，但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时，都能交付用户一个可用的、可部署的系统，用户使用并体验该系统并反馈意见，在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时地处理需求变化和用户反馈。
敏捷型方法把人放在第一位
敏捷型方法是“面向人”的而非“面向过程”的。 工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的工作提供支持。实施一个适应性过程并不容易，特别是它要求一组高效的开发人员。高效既体现在高素质的个体，也体现在有能让团队协调一致的工作方式。但技术人员并不能包打天下，他们需要应用系统的需求引导。这导致了适应性过程 的另一个重要方面：他们需要与应用领域的业务专家非常紧密的联系。这种联系的紧密度超过了一般项目中业务人员的介入程度。如果开发人员和业务人员只有偶尔的沟通，那么敏捷型过程是不可能存在的。他们需要不断地获取业务方面的专门知识。此外，这种沟通不是由管理层来处理的，而是每个开发人员需要做的事。因为开发人员在他们的行业里是有能力的专业人员，因此他们能够与其他行业的专业人员同等地在一起工作。
自适应过程
适应性不仅是指在一个开发项目中如何频繁地修改软件以适应不断的需求变更，还有过程本身随着时间推移变化。一个项目在开始时用一个适应性过程，但随着时间的推移，开发团队会发现什么方式对他们的工作最好，然后改变过程以适应之。自适应的第一步是经常对过程进行总结检讨。这样，如果开始时使用的过程有问题的话，随着项目的进行，该过程会得以逐步的完善， 以使其能更好地适合开发团队。
敏捷开发的至理名言
（这是我在网上淘到的一篇文章，看起来觉得很有道理，先收藏在此再慢慢体会。）
1、完整地干完一件事后在开始另一件事：用厨房比喻来说就是：“先上这道菜，再开始做下一道”。软件开发的最大问题就是同时开始几件事情，这将不可避免的造成某些工作被废弃，从而造成浪费。专注于一件事；完整地实现其功能；运行测试；编写文档；签入所有，把这当做一项工作完成，然后再开始下一件事。
2、不要破坏构建：非常明显，但必须被包含在任何软件开发建议清单中。程序员在签入之前采取所有合适的预防措施进行测试，则永远不会破坏构建。如果构建被破坏，通常是因为有人偷懒了。
3、在用例需要之前，不要实现程序：当你实现一个特定的类，你应该在脑海中有一个特定的用例，同时应该只实现用例需要的方法。你可以考虑该类潜在的功能，写入注释之中，但直到用例真正需要时，才应去实现它。
4、在用例需要之前，不要添加数据成员：同上一条，不过这是从类的数据成员角度考虑的。似乎显而易见地，“客户”记录需要“送货地址”，但直到有用例明确需要送货地址，才应该实现它。
5、不要害怕做决定，不要害怕改变先前的决定：敏捷开发是关于相应变化和快速相应的。开发初期，你没有完整的信息。你应该尽可能的推迟决策，直到你必须做出决策的时候。没有信息，无法支持你的决定，相反，在有效信息的基础上做出最佳决定。有了新的信息，不要害怕改变先前的决定。（某些“恐龙”称之为摇摆不定，但我称之为响应变化的环境）
6、持续学习如何改善质量：这项工作永不会结束，因此你应经常留意可以改善的事情，并收集质量问题被确认和处理的案例。
7、度量、度量、度量：敏捷开发帮助处理未来不确定性问题，但对于过去应没有不确定性。测试应持续运行，每次运行的性能表现应被度量和记录。
8、为人而设计，而不是系统：开发者常常因技术而使设计误入歧途。绝不要忘记设计的最终目标，那就是帮助人们完成工作。
9、测试是产品的一部分：很多开发者和经理认为产品就是交付给客户的东西，而其它所有东西都不那么重要。测试应被认为是产品实实在在的一个部分，值得在设计时仔细考虑，甚至，在很多情况下，和产品一起交付给客户。（后半部分有争议，但是内建测试作为软件交付的一部分仅仅占用无关紧要的空间，却在必要时提供显而易见的好处，这种方式应该被考虑。）
10、在代码之前编写测试：测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测试用例被发现的。想想看，编码之前，通过这些用例，可以节约多少时间。但是，为用例1编写测试，然后编码，然后再开始用例2。
11、消除浪费：坦率的说，这是另一个必须包含在任何开发原则清单中的陈词滥调，因为它太重要了。发现浪费并消除它，这项工作没有尽头。消除任何不能增加客户价值的东西。如果你不能确认客户价值，那很可能你并不需要它。
12、建立对构建破坏立即响应的文化：要明白当构建被破坏，会影响项目中的每一个人，因此，最重要的是确认核心代码被构建并合理测试。我曾见过有些团队放任失败测试持续数月，因为那是其它人的工作。每个人都痛苦，但没人采取行动。想反，必须形成共识，那就是小工作能为团队获得大的回报。
13、所有团队成员应理解客户需要：大型的复杂项目定然被分解为独立的团队，进而被分派给开发人员。但是，不应在此范围内做的是，失去关注最终项目真正用户的期望和目标。
14、把相关定义放在一起：组织代码以使高度相关的事情在一起，或在一个类中。这是标准面向对象设计封装原则。理想情况下，所有的类外的代码不需要知道内部工作细节。一些开发者乐于将细节扩散到多个文件中以便按不同方式组织，如所有相同的数据类型放在一起，或者按字母顺序组织。例如，在他们要用的不同包中，将所有常量放在一个类里，这增加了不必要的程序复杂性。指导原则应该是按相关性分组从而隐藏复杂性。
15、始终在签入之前运行测试：这条准则帮助你满足“不要破坏构建”准则。
16、过早的优化时万恶之源：引用高德纳被证实的话：代码应编写良好以避免微观层面的浪费，但独立方法层次以外的优化应等待整个程序基于真实的最终用户使用情景的压力测试的进行。仅仅基于对代码的静态理解，直觉地判断对整体性能什么是重要的，结论几乎总是错误的。相反，度量整个系统的行为，辨别1%真正影响性能的代码，并专注于此。
17、减少积压未完成的编码任务：当开发人员开始一个用例，会发生成本，跟已修改却未完成和测试的代码相关联。留着未完成的变化几天或几个星期会累积成巨大的重做风险。考虑每个估算需要一天的三个任务，同时开始这三个任务，并在3天内同时进行，意味着9个单位的累计成本。但是顺序进行每个任务，完成一个再开始下一个，意味着只有3个单位的成本。这个不是直觉，直觉告诉我们，在工作完成之前，我们不妨同时做三件事情。但软件不像物理构造。短小，快速和完整的工作不仅减少认知的负担，而且减少未完成工作与他人未完成工作之间冲突的可能。
18、不要过度强调代码的通用性：这就是著名的“YAGNI-你不会需要它”。当编写一个特定类的时候，程序员总喜欢认为该类可能用于其它用途。如果现在的用例需要这些用途，这很好，但是，程序员经常考虑未被提及的用途，或者那些实际上永远不需要的。（这常常让我联想到经典的周六现场滑稽短剧，关于某产品既是地板蜡，也是糕点上的甜食。）
19、两行代码能行，就不要用三行：有人阅读时，简洁的代码总能获得回报。但不要将代码压缩到难以阅读。更小的，编写良好的代码比之冗长的，编写华丽的代码更容易维护，也更容易发现错误。始终尽可能简化，但别过分。
20、不要用行数来度量代码：完成特定任务所需的代码行数，不同的程序员之间和编码风格之间差异很大。代码行数不能告诉你代码完成和质量的些许东西。代码质量可以相差200倍，这足以抵消代码行数的作用。应该统计功能用例的数目。
21、持续地重新设计和重构：谨慎地使用这条准则，因为有些代码脆弱而难以改变，但通常你不应害怕更改代码以符合实际使用情况。一个数据成员过去可能是整数，但是当一个用例要求它是一个浮点数时不要害怕去改变它。
22、删除死代码：涉及到大量不能很好理解的代码是，有个倾向是不自找麻烦。一个例子就是往类中增加新的方法去替换另一个，开发人员常常会留下旧的方法以防万一。必须努力检查方法是否必须，如果没有证据表明它是必须的，那就删除它。最糟糕的就是注释掉大量的代码，并把它留在那儿。注释掉的代码应在测试通过后尽快删除，当然应在签入之前。因此，某个时候你发现一些东西可能并不需要，付出小小的努力去验证并消除此代码能让代码基线更易维护。
23、不要发明新语言：程序员喜爱使用文本文件配置在运行时驱动功能。没有配置文件能够不编译而改变程序的行为。XML的出现推动了无休止的专门定制“脚本语言”的浪潮，以使功能能被最终用户定制而不需要编译。这种推理的缺陷在于，离开某个特定实施的环境，操作行为几乎从来没能很好地精确定义，同时，那些脚本语言只对那些对问题领域代码的内部运行有深入了解的人有用。因此，不具备详尽内部知识的真实最终用户永远不可能知道预料复杂的命令组合的效果需要什么。脚本语言有用，也不能被消除，但是设计者必须采取非常非常保守的态度，尽可能使用现有的语言，避免新的发明。
24、在你准备实现并测试前，别做设计：你应该有行进的总体思路和对系统架构的概览，但是，直到开发迭代允许设计被实现和测试前，不要做详细设计，不要编写功能实现的详细说明。详细设计应当只涉及到处理目前的用例。软件开发中最大的浪费源于将时间花在设计那些不需要，或者因为某些错误的设计假定而需要重新设计的事情之上。
25、设计是可塑的：不像物理制造，软件可以很容易地获得显著改变。事实上，有大量证据证明软件本身比描述软件的设计说明书更容易改变。此外，软件比说明书更有效地传达设计。因此，你应该把时间用于直接实现设计，让客户能看见设计的细节。如果你犯错并改变设计，改变软件比改变规格更容易。但最重要的是，客户看到代码运行后，你关于客户想要什么的信息大为完善。
26、花时间编写发现和报告异常情况的代码中的问题的完整描述：程序员往往很懒惰，抛出粗浅描述错误的异常。认为他们永远是唯一会看到这个问题的人，并且他们从含糊的描述会记得这个问题的意思。但实际上，在客户支持环境，不准确或者不完整的错误报告比其它原因浪费更多的时间。编写每个错误消息，就好像你正向某个正好走进房间并且没有此代码经验的人解释状况。客户和客户支持团队毕竟没有此代码的经验。
我的启发
据我所知，许多企业有选择地部分采用了最适合他们的敏捷方式，而不是全盘敏捷化。根据某个网站的调查显示，Scrum成为所有敏捷技术中最受欢迎的，选择Scrum方法的高达41％；其次是极限编程（XP），占到15％。另有14％的被调查者选择了混合使用Scrum和XP，13％的人使用自定义或其他类型的混合敏捷方法。Crystal和动态系统开发方法都只有3％以下的使用者。但是众所周知，没有一种方法可以涵盖一切，你所遵循的过程必须适应你所在的环境。Scrum是不够的，XP也是不够的，敏捷建模同样是不够的。他们都只涉及整体过程中的部分。所以，开发团队可以把用到的各种方法进行最佳组合，并重新对其改造以适应自己的需要。而敏捷开发方式往往能给企业和用户带来以下好处:
1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线，然后沿着直线不断往前走。然而当项目到达终点时，用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑，每走完一步再调整并为下一步确定方向，直到真正的终点。
2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等，甚至使用测试驱动开发，即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。
3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。
4. 丰厚的投资回报率。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。
5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
很显然我现在还没有能力去驾驭敏捷型开发，多数时候我仍然采用边写边改的方法。我一直试图用一些正规方法去改善我的编程，但是经常因为事情会变得非常复杂而放弃。但是无论如何我认为引入一些纪律约束肯定会比一片混乱要好，而敏捷型途径的主要优点就在于它比工程方法的步骤要少得多，遵循简单过程总归要比遵循繁琐过程更容易一些，所以我觉得敏捷开发很值得一试。作为一个新生事物，敏捷方法还是太年轻，可能会遭到业内人士的怀疑，也可能存在各种各样的问题，比方说敏捷方法能不能用于大的项目，敏捷方法的边界条件有在哪里。但是我们并不能因为这些去阻碍它的发展，我相信通过更多人的实践，敏捷方法有很大可能会引领软件开发的潮流。
