00.在生存竞争中，最适应的物种以牺牲敌人为代价最后生出，因为他们能够成功地改变自己更好地适应环境.——查尔斯.达尔文
01.信仰的飞跃、冒险进入到未知世界，这是一个认知的发现过程，有时会产生不可预期的结果。
02.敏捷方法（Agile）描述了一组交付软件的原则和实践。
03.如同志愿者，知识工人不喜欢被呼来换取。相反，他们指向被雇佣，希望参与，想知道他们处于什么位置以及他们的工作队其他人会产生什么影响。他们希望接受挑战，感觉仿佛自己的努力受到重视。者意味着命令工人的旧式方法必将被提倡信息共享和劝导的心方法所替代。
04.敏捷宣言：
*我们正在通过亲自去做以及帮助别人做来发现更好的软件开发方式。通过这项工作我们获得了价值：
*个体和交互胜过过程和工具
*可工作的软件胜过全面的文档
*同客户的协作胜过合同谈判
*对变更的响应胜过遵循计划
*换句话说，尽管右边陈述的条目也有价值，但是我们还是更强调左边陈述的价值
05.“自我超越”(self-transcendent):其含义是项目团队应该处于“为达到顶点而永不停歇寻求”的状态。有能力的项目团队能够依据管理者给出的指导原则创建自己的目标，他们能够以一个团队的方式设计出独特的解决方案从而找到解决问题的出路。
06.这被称为“产品评论”(product review)。考察可工作软件让我们能够对象的真实状态做出合适的响应。所有东西都是可见的，能够基于系哪有的产品做出决策，而不是只依据有关的文档形式的材料。
07.如果一个人给了我一份40页的文档然后告诉我去编码，我将不知道应该首先做什么。事实上，我很可能更愿意首先开始研究系统的体系结构，或者做我敢兴趣或零我兴奋的事情。这些事情很可能不是客户认为最有价值的特性。因此，现在编写文档这种资源浪费的形式中有夹杂了编码形式的浪费，这些编码是我自认为应该开始做的一些东西——但这些东西很可能不是当时应该做的正确的事。
08.为了开发出恰当的系统，客户的反馈信息是必不可少的。敏捷项目团队重视客户（或客户代表），能够学会如何让客户来做出业务决策。反过来，客户也依赖项目团队提供的重要的技术信息来做出合适的决策。优势客户在没有看到东西之前并不知道自己想要的是什么。
09.敏捷方法下的“客户协作”意味着客户已经成为开发过程的组成部分。
10.在计划驱动的环境中，所有需求都是被实现规定的，它们被分解到任务的层次并得到评估。成本和完成日期是根据这些粒度较细的任务通过自底向上的计算得到的。计算所得到的进度计划成为项目的一个基线，用于度量项目的性能。因此，严格根据计划执行任务、控制范围蔓延在计划驱动的项目非常重要，因为只有这样做才能限制或消除成本超支或进度拖延。
11.敏捷宣言12条敏捷原则：
*我们的最高优先级任务是通过尽早和连续地交付有价值的软件满足客户的需要。(客户交付价值)
*即使到了开发后期也欢迎需求变更。敏捷过程考虑到客户获得竞争优势的需要而同意变更。
*经常交付可工作软件，交付周期从几个星期到几个月不等，时间间隔越短越好。(时间盒timebox)
*业务人员和开发人员必须自始至终共同完成项目的日常工作。(业务需要)
*围绕积极的个体构建项目。给予他们所需要的支持和环境，相信他们能够完成工作。(时间盒内是自我管理)
*面对面地交谈是开发团队中最有效的信息交流方式。
尽管这条原则表面看上去只是一个常识，但是实质上意味着语言去替代某些文档。例如，开发团队成员并不编写详细的设计规约，而是共同工作并探讨和研究软件应该如何被构建思想。这病不是说敏捷项目不编写文档——他们确实编写文档。这条原则说的是文档不是主要的沟通工具。我们知道，许多项目团队所在的地理位置相隔数千英里，优势唯一的沟通方式是通过多种类型的文档，然而，还有许多项目团队成功地实现了即时消息通信、视频会议、wiki、最新的工程开发环境以及采用其他各种技术来支持有效的协作。
*可工作软件是项目进展状况的主要度量。
*敏捷过程提倡可持续的系统开发。资助方、开发方和用户应该能够维护一种不确定的、持续的步调。
*对卓越技术和良好设计的持续关注有助于提高项目的敏捷性。
*简化（尽量让可以不做或少做的工作量达到最大）也是至关重要的。
简单性是敏捷方法的“反镀金机制”。敏捷项目团队值构建客户想要的，此外不关注其他。这条非常简单的原则确保了项目团队不会去构建客户不想要的或者不用的功能。
*最佳的架构、需求和设计都源于自我管理的团队。
*在有规律的时间间隔中，项目团队要思考如何提高后面的工作效率，然后相应地调整自己的行为。
尽管每次迭代结束时可以检查和修改产品，但是这条原则讨论的是过程调节的必要性。为了确保过程工作的质量，敏捷项目团队需要回顾以前的过程。项目团队成员一起工作，共同解决过程中存在的任何挑战，并且关注长期的过程改进。