阅读材料来源：Martin Fowler:
Tips：这是比较高度概括的版本，详细剖析过程，在文章的最后~
软件开发的主要难点在于，想要达到高质量的开发结果以及高效率的开发过程同时成立。
高质量的开发结果：软件质量好坏的衡量方法主要在于用户是否满意。
高效率的开发过程：有一个较为有条的开发流程，来保证开发的完成率和高效性。
二者不能同时成立的主要原因：
用户需求的变化性过大，固定的开发流程阻碍用户需求变化的满足，从而两者看起来矛盾。
（用户需求的变化性过大的原因：
1.PM与用户的沟通不充分，即便沟通充分了，用户有时候也不知道自己的需求到底是什么，什么功能是最重要的；
2.用户的需求本身随着软件开发过程是在不断地变化的。）
各种开发的比较：
code and fix：开发自由，一片混乱，以牺牲软件的完成率为代价；
高质量：不一定；高效率：不是；
计划驱动开发：貌似井井有条，但从本质上违背了软件的评价标准，以一个模糊的、不准确的、过时的用户需求作为软件开发目标，即便井井有条也没有意义；
高质量：一般不是；高效率：好像是；
敏捷开发：不过度地苛求软件的步骤规范，通过自适应地寻找适应于具体情况的开发过程；不一开始就限定用户的需求，通过快速迭代来不断获取用户的需求，因此用户的需求，既由程序员根据实际迭代过程来确立，又由公司的远瞻性的目标影响。
所以敏捷开发的步骤既可以较为有条，使开发效率较高。又可以更准确地把握客户的需求，从而使开发结果——软件的质量更高。
高质量：基本可以；高效率：基本可以；
也就衍生出了敏捷开发的两个特点，自适应和以人为本。
自适应主要包括用户需求的适应，和开发过程的适应；
用户需求的适应：是用户需求在不断地迭代（开发--用户反馈+程序员观察--再开发）中确定化，以及需求本身变化的适应。保证了开发方向的正确性，保证了开发结果的高质量。
开发过程的适应：是开发过程中通过队员的不断磨合，具体的环境，最新的用户需求，来不断改善开发的过程。保证了开发过程高效和完成率。
以人为本主要包括以用户为本，以程序员为本。
以用户为本：用户的满意是软件开发的目标。要不断了解用户的需求，主要利用保证用户需求的适应性；
以程序员为本：程序员可以接触到最真实、最具体的用户反馈，而管理层往往都是脱离实际来做决定的。同时，程序员由于接触过于具体，而导致目光较短；而管理层往往可以做出更有远见的决定。因此，要打破以管理层目标为开发目标的局面，要使程序员的决定和管理层的决定处于同等地位，这样才能扬长避短，使软件开发做得更好。
其实自适应与以人为本不是相互独立的，二者相互配合才能做好软件开发，也是敏捷开发的实质。例如，要做好用户需求的自适应，就要以用户为中心，提高程序员的决策分量，也就是以人为本。要做到以用户为中心，就要用自适应的方式来不断地修正用户的需求，真正地做到以用户为中心。
Agile development的分类
其实分类很多，因为它是自适应的，所以方法并不是一成不变，应该有机地、视情况地进行选择。
How to Start Agile development?
选一个风险程度较小的项目，但是不能低于你无所谓的程度，进行实践。并不断地体会，反思，调整。理论结合实践。
如果有经验者的指导会更好。
软件工程课就是这样一种平台，So Lucky~
My ideas:
什么是用户的需求：
其实用户的需求首先用户也不是很清楚，要通过不断地迭代，不仅仅要通过单纯用户做出的反馈来获取，更重要的是，程序员要有敏锐的观察力，观察用户究竟需要什么。也许这个功能，原先用户并没有要求，但是在观察中发现，用户其实很需要，做出产品后，用户也很惊讶，哦，我原来想要这个功能。其实很多的IT公司的创新，都源于对用户行为的观察。
适应的高效性：
人体本身就有很多反馈机制，所以使得人体是一个独立而又统一的系统。有很强的适应性。人的强大，每个人都可以理解。机器学习，也是一种适应的过程，是一种人类适应性的计算机应用。敏捷开发非常强调适应性，从这一角度看，是非常科学而自然的。
敏捷开发难点：对程序员的要求很高
敏捷开发，在迭代过程中。每次要基于上一次的开发进行修改。那么，每一次设计都要考虑到易于修改性，这对程序员的设计能力，挑战非常大。
在开发过程中，程序员有权利控制开发的目标，这使得每个程序员都要有一定的经验和能力做出较为正确的判断，才能使得最终目标的正确性。
敏捷开发的其他应用场景：
其实在生活中，很多合同的死板，使用户的权益不能良好的保障。用户在提要求的初期，可能没有对事物的全面认识，从而使得合同目标的偏差。而服务者因为要一味地履行合同条款，完全不理会合同目标的正确与否。最后服务者辛苦，用户不满意。其实这一过程，应该是服务者与用户不断地交流，互相信任的过程，才能做到最好的合作。
感想：
这次看Martin Fowler的博客，觉得很神奇。方法的提出过程，让我觉得自己平时应该多思考，多质疑，多些创新思维。
会在团队项目中，不断地继续阅读，不断地实践，思考。
较详细分析过程：
软件工程的特点
对于软件开发，与其他工程类的项目（特别是土木工程类）最大的区别在于，没有一个具体地，成功率很高的可遵循的规章制度（执行步骤）。纵观各大IT公司，可以发现IT业的成功主要在于科技的创新，软件的开发重点在于灵活地进行创新，从而使客户满意，而不是像盖楼一样保证可以建出一个大楼。同一类软件，它的用户满意度，也就是软件好坏的重要评价标准，有很大的差距。而同一类大楼，例如写字楼，用户的满意度很大程度上与这个楼是否建的好没什么关系。所以，盖楼可以有很详尽的规范步骤，而软件开发需要灵活地进行创新，而规范步骤是这种创新最大的阻碍。
软件开发的主要方式：
最早的软件开发是一种code and fix的模式，这完全就是一种混乱的状态，既不能保证成功率，也不能保证客户的满意度，开发成功与否可能有很大的运气成分。之后，软件开发效仿工程类项目，产生了计划驱动方法，这就出现了让很多人头疼的文档，花很大气力去完成，之后几乎没有什么效用。分析其中最主要的原因，就在于软件的灵活性无法被拘泥在一尘不变的步骤中。之后就出现了，在散漫和严苛制度的中间态，敏捷开发。之所以敏捷开发较好，主要在于它既可以减少风险，减少混乱，又可以较大限度地保持灵活性，提高软件的质量。
敏捷开发主要有两个特点，用适应性来保证软件的灵活创新，用以人为本来减少风险与混乱，这两者共同保证软件的质量。
适应性： 包括需求的自适应，开发过程的自适应。
需求的自适应：对于现今互联网、大数据时代，事物的变化速度是非常快的，甚至几个月前的软件需求已经不能符合现在的需求，要在较短的时间内快速应对变化，这在任何一个产业中都是非常难的。软件开发要做到这些，要找到一种很好的方法，来预见人们的需求。靠程序设计者们去苦思冥想显然是不可能的，一个最直接的方法，就是用实践来检验软件，让用户们进行使用，根据使用的结果来判断需要做哪些改变。传统的发布软件的方式，几乎没有可能让用户使用后进行改变，因为它到用户的手中时，已经开发完了。所以，敏捷开发用快速地迭代，先开发出原型，在用户反馈以后，做出修改进行迭代，以较小的代价来快速的改变。
开发过程的自适应：要保证开发过程的井井有条，就要以一定的规范制度。如果制度是固定的，那么就不能很好地适应不同环境以及变化。但也不能没有制度，一切事物都完全地混乱下去，很低效。如果在开发过程中，通过程序员、用户（需求）、管理层以及他们自身不断地进行磨合，来决定较好的规范制度，就既高效又灵活了。
以人为本：我觉得这里的以人为本主要包括以用户为本和以程序员为本。
以用户为本：传统的软件开发主要是以项目书的目标为本，达到了文档的目标，okay，不管用户是否满意，软件开发就视为成功。但这样，很不易于软件开发的发展，软件的好坏应该由用户的满意度来决定，而非是否达到了一个目标，而用户目标的制定，往往由于PM（应该是吧，不确定）和用户沟通不够充分，而导致目标的不清晰，更别说用户想要更换目标了。而敏捷开发，通过迭代过程中多个版本，不断地获取用户的需求，双方共同确立软件开发目标，从而使软件开发出现双赢的良好结局。这是一种软件开发的理想状态。
以程序员为本：在大多数行业中，每个职员对于一个公司，机构只是一个产业链上的螺丝钉，他没有自己的思想，只要按照公司的要求进行正常运转就好。而软件开发的要求，首先确立时就是模糊的，再加上又要不断地变化。要定义软件的要求是什么，显然不实际。那么，程序员因为没有要求就每天无所事事了吗？首先，敏捷开发要把程序员团队当做一个有机的整体，他们是有创造力，有思想的人，而非工具。每位程序员要有高度的自律来保证，做好最好地软件；每位程序员要有高度的自主选择权，不能是公司的机器人，要将自己对于软件发展最好的看法与见解结合到公司的目标中去，公司的目标与程序员的选择是同等重要的。往往公司的目标是缺乏脱离实际，但有一定的远见性；而真正接触到工程的程序员的目标是真实具体的，但又一方面容易迷失远见。所以二者的结合将是软件的质量有很好的保障。