《敏捷开发》读后感一

完成一项工程时，我们常常会有这样的感受：我们的解决方案要根据顾客的需求和现实情况的需要，不断更改。采用传统意义上的瀑布式开发，往往要花费更多的时间。最重要的原因就在于它相比于极限编程、敏捷开发，对于团队合作的重视程度不够，自由度也相对较低，导致效率偏低。

      在实际做项目时，我们应该清楚，我们做工程的目的是，满足我们的客户的一定需求。所以以人为本的思想就显得尤为重要，如果客户只是在签订合同时提出了自己的需求方向，没有对需求细化，程序员们往往会一头雾水，不知从何开始。如果自己在实现的过程中遇到一些问题，无法与用户及时交流，会大大浪费程序员的时间、精力，甚至导致无法按期交付用户使用。

      目前，我们常采用的方式是，编写代码，并进行修复，对于较小的项目而言，这样做在不是很长的时间内能够解决问题。但我们换一个思路，如果我们先实现一些用户需求的基本功能，让用户在最短的时间内，有所体验，并提出建议与意见，之后我们再来修改、优化，是不是就会让用户有更强的感官认识，促进我们更快更好地完成任务呢？比起目前编程方式，经过的漫长的测试阶段，才能保证“功能齐全”（这种功能齐全，可能还不是用户真正满意的效果），敏捷开发在时间和效果上的优势性很明显。

      现有的工程方法，希望定义一个过程，无论遇到什么问题，程序员只要按照这些步骤走，就能基本解决问题，要想实现功能优化，则需要程序员按照自己的想法减少bug。可是如果什么事情都按照给定的模版去做，软件开发还会有创新可言吗？我们需要的是一种在实际开发过程中，让自己拥有较强应变能力的原则，而非一成不变的方法与模式。这就好比如果一个公司只注重运营部的建设与发展，也许它能平稳的运行，或是在短期时间内看到较小的业绩突破。可是它的“抵抗力”不堪一击，因为它忽略了“危机处理”，一个公司只有具有针对不同困难情况（这种困难往往指的是，会让公司倒闭的大型困难），在较短时间提出有效可行的解决方案，才能保证公司不害怕任何风浪，敢于尝试更高的挑战，因为即便挑战失败，它都可以随时改变自己的经营策略，从而渡过难关。在这一过程中，因为我们没有按照常规的方式进行，也勇敢的迎接挑战，所以有可能还会有意想不到的收获，为公司的经营开辟新的领域。经营公司如此，开发软件亦然。

    软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索。

     极限编程注重用户反馈与让客户加入开发是一致的，让客户参与就是随时反馈软件是否符合客户的要求。有了反馈，开发子过程变短，迭代也就很自然出现了，快速迭代，小版本发布都让开发过程变成更多的自反馈过程，有些象更加细化的快速模型法。当然极限编程还加入了很多激励开发人员的“措施”，如结队编程。极限编程强调以下几点：

1、角色定位：极限编程把客户非常明确地加入到开发的团队中，并参与日常开发与沟通会议。

2、敏捷开发：敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期，缩短到周、日，完成一个小的功能模块，可以快速测试、并及时展现给客户，以便及时反馈。

3、追求价值：极限编程把软件开发变成自我与管理的挑战，追求沟通、简单、反馈、勇气，体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，情绪高涨，认真投入，开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。

    
     事实上，敏捷开发集成了新型开发模式的共同特点，它重点强调：

1. 以人为本，注重编程中人的自我特长发挥。

2. 强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

3. 客户与开发者的关系是协作，不是合约。开发者不是客户业务的“专家”，要适应客户的需求，是要客户合作来阐述实际的需求细节，而不是为了开发软件，把开发人员变成客户业务的专家，这是传统开发模式或行业软件开发企业的最大面临问题。

4. 设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应客户需求的不断变化，设计也要不断跟进，不断根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。

     敏捷开发避免了传统瀑布方式的弊端，主要是吸收了各种新型开发模式的“动态”特性，关注点从文档到开发者，管理方式也从工厂的流水线到团队的自我放松式的组织。

     敏捷就是“快”，快才可以适应目前社会的快节奏；要快就要发挥个人的个性思维多一些，个性思维的增多，虽然通过结队编程、代码共有、团队替补等方式减少个人对软件的影响力，但也会造成软件开发继承性的下降，因此敏捷开发是一个新的思路，但不是软件开发的终极选择。对于长时间、人数众多的大型软件应用的开发，文档的管理与衔接作用还是不可替代的。