一、敏捷宣言的价值观
个体和互动 高于 流程和工具——采用每日站会的互动沟通替代所有成员每日维护项目需求进度表，然后项目经理来查看需求开发进展及风险的方式。
工作的软件 高于 详尽的文档——通过需求梳理会，梳理出产品待办事项及优先级，然后每个迭代交付一个增量，这个增量是一个最小可工作产品，然后邀请客户进行迭代评审，观看实物，提出意见，更快矫正开发团队理解与客户需求之间的偏差，再详尽的设计文档也不如可视的产品直观。
客户合作 高于 合同谈判——通过邀请客户参与迭代评审、迭代回顾的方式，来找到彼此更加融洽的合作模式，比双方通过设想各种不如意场景，然后设计流程或者签订商务合同，制定苛刻的上下游准入准出或者罚则，会更加达成双赢。
响应变化 高于 遵循计划——开发团队和客户的共同使命，是为公司创造利润，通过scrum的方式，每个短周期的迭代交付一个增量，当客户需求发生变化时，可以及时调整未开发的product backlog、比较轻松地响应客户的需求变化。如果采用传统瀑布式，可能需要在比较后期才能识别到变更需求，再执行一套比较严格的变更程序，整体响应速度及变更成本会比较高
二、敏捷原则
我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。——通过PO对产品待办列表中的优先级排序，团队选取最高优先级的部分放入下一个迭代
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。——以客户满意为目标，迭代过程中如果客户提出需求变更，可以由PO判断并更新产品待办列表，当前迭代开发中的需求暂停。并在下个迭代中选取变更后的需求进行开发。如果客户要求变更后的需求在当前迭代交付，由团队自己决定是否接受。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。——目前根据不同条线的系统特性，有的团队迭代周期是四周，有的团队迭代周期是双周。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。——通过每日站会互相了解进展，业务人员和开发人员尽量在同个场地工作，方便交流
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。——激发个体斗志，通过内刊公众号等及时宣传项目成果，激发团队的斗志。迭代回顾会关注成员提出的所需的环境和支援，并按承诺提供支持
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。——同个团队的人员在同一片区域工作
可工作的软件是进度的首要度量标准。——DoD明确交付标准是可工作的软件，而非半成品
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。——严格按照迭代待办事项进行，拒绝需求加塞，让团队保持稳定的节奏。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。——在迭代回顾会中引导技术及设计方面的回顾，引导团队追求技术卓越和良好设计
以简洁为本，它是极力减少不必要工作量的艺术。——通过每日站会、迭代评审及迭代回顾，实现工作成果的及时同步及确认，减少不必要的工作量。
最好的架构、需求和设计出自自组织团队。——scrum的团队是自组织团队，由团队自行组织完成架构、需求和设计，团队自己为自己的工作成果负责，有利于提高交付质量。
团队定期地反思如何能提高成效，并依此调整自身的行为表现。——每个迭代组织召开迭代回顾会，引导团队泛起如何提高成效。
