敏捷宣言的诞生： 

　　2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

      个体和互动   高于 流程和工具 　　工作的软件  高于 详尽的文档 　　客户合作     高于 合同谈判 　　响应变化     高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷开发的12条准则: 

准则1：Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 

　　我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。  准则2：Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  　　欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。  准则3：Deliver working software frequently, from a couple of weeks to a couple of mouths, with a preference for the shorter timescale.  　　要不断交付可用的软件，周期从几周到几个月不等，且越短越好。  准则4：Business people and developers must work together daily throughout the project.  　　项目过程中，业务人员与开发人员必须在一起工作。  准则5：Build projects around motivated individuals. Give them the environment and support they need, and  trust them to get the job done.   　　要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。  准则6：The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.  　　无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。  准则7：Working software is the primary measure of progress.  　　可用的软件是衡量进度的主要指标。  准则8：Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  　　敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。  准则9：Continuous attention to technical excellence and good design enhances agility.  　　对技术的精益求精以及对设计的不断完善将提升敏捷性。  准则10：Simplicity -- the art of maximizing the amount of work not done -- is essential.  　　要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。  准则11：The best architectures, requirements, and designs emerge from self-organizing teams.   　　最佳的架构、需求和设计出自于自组织的团队。  准则12：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.   　　团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

 

在会议上每个团队成员回答三个问题（During the meeting, each team member answers three questions）

1. 昨天你完成了那些工作?（What have you done since yesterday?）

2. 今天天你打算做什么?（What are you planning to do today?）

3. 完成你的目标是否存在障碍?（Do you have any problems that would prevent you from accomplishing your goal?）

会议准时举行（The meeting starts precisely on time.）

任何人都可以参加,但只有团队内部人员发言（All are welcome, but normally only the core roles speak.）

会议时长限制为15分钟（The meeting is timeboxed to 15 minutes.）

会议时间地点应该固定（The meeting should happen at the same location and same time every day）

 

评审会议（Sprint Review Meeting）

　　评审会议在每个迭代结束后举行，在会议上团队演示此次迭代中完成了那些工作，一般会有相关的DEMO演示。

　　这个会议演示的内容应该是启动会议上确定的那些内容

回顾会议（Sprint Retrospective Meeting）

　　冲刺回顾会议一般限时为3个小时（The sprint retrospective meeting is timeboxed to 3 hours.）

　　仅团队成员参加，产品经理和ScrumMaster，产品经理选择性参加（It is attended only by the team, the scrum master and the product owner. The product owner is optional.）。

　　会议上团队中每个成员需要回答两个问题（Start the meeting by having all team members answer two questions）：

　　1. 此次冲刺中那些地方做得好?（What went well during the sprint?）

　　2. 下个迭代中那些地方可以改进? （What could be improved in the next sprint?）

　　scrum master记录每个成员的答案

　　团队为这些改进意见评定优先级（

　　scrum master在回顾会议中不允许给出答案，但要鼓励成员自己找到较好的办法

　　这些改进工作可以添加至下个迭代中，作为一个非功能性工作，回顾会议最不担心的就是变化