敏捷12项原则
原则1：我们的首要任务是通过尽早和持续地交付有价值的软件来满足客户
客户满意
原则2：欢迎对需求提出变更，即使在项目开发后期也不例外，敏捷过程要善于利用需求变更，帮助客户获得竞争优势
接收变化
原则3：要经常交付可用的软件，周期从几周到几个月不等，且越短越好
频繁交付
原则4：项目实施过程中，业务人员与开发人员必须始终通力合作
一起工作
原则5：要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
提供环境和支持
原则6：团队内部和各团队之间，最有效的沟通方法是面对面沟通
面对面沟通
原则7：可工作的人间是衡量进度的首要指标
衡量指标
原则8：敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持稳定恒久的进展速度
可持续步调
子主题
原则11：最佳的架构、需求和设计出自自组织团队
自组织团队
原则12：团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为
定期反思
敏捷产品创新方法的关键要素
产品待办列表
1、产品待办列表包含系统的需求，其中的产品待办项按照优先级进行排序
2、产品负责人负责对产品待办列表进行优先级排序
3、一个产品待办项时团队在一次冲刺迭代周期中要完成的最小工作单元
Scrum
1、Scrum是最常用的敏捷框架。团队以scrum为框架，在一些列固定周期的迭代中开发产品，并以固定的节奏开发软件
冲刺（sprint）
1、冲刺是指完成特定任务，由开发阶段进入评审环节的一个时间段
2、冲刺时一段设定的事件（通常不超过30天），在此期间，必须完成特定任务，并为评审最好准备
3、在sprint过程中，待办列表会不断得到解决，从而可以实现产品的增量开发或增强
4、每个sprint都以一个计划会议开始，在这个会议上，产品负责人和开发团队就sprint将要完成的事情达成一致，冲刺的持续时间由团队决定。冲刺开始后，团队接管工作。在sprint结束时，团队向产品负责人展示其完成的工作，产品负责人及项目相关方使用sprint会议中确定的标准来接收或拒绝工作。
评审（demo）
1、在每个冲刺完成时，项目相关方（如客户或公司管理层）将对该冲刺中交付的产品（增量）和/或特性进行评审
2、这需要展示“产品”到目前为止的情况<br>
3、目标时确认成果，并开启下一个冲刺
回顾会
sprint回顾会议旨在识别并记录从上一次冲刺中吸取的“经验训”，并在每次sprint结束时举行，团队以持续改进为目标评估其绩效，他们问自己
1、哪些工作进展顺利及为什么
2、哪些工作进展不顺利及为什么
3、如何处理进展不顺利的工作，并为冲刺规划提供依据
产品负责人
1、必须是唯一在产品待办列表优先级和需求问题上代客户利益并拥有最终决策权的人
2、必须随时向团队提供，尤其是在sprint规划会议期间
3、冲刺开始后，不应管理团队，也不应再提出变更
4、必须平衡相关方之间互相竞争的利益
敏捷教练
1、是团队和产品负责人的促进者
2、通过以下方式协助团队和负责人
清除两者之间的障碍
激发团队创造力，并给团队授权提升团队生产力改善工程工具和实践
实时更新团队进展信息，确保各方都被知会
敏捷团队
1、由7（±2）成员组成
2、由跨职能组成且自组织实现冲刺目标
3、自主选择实现目标方法并对目标负责
4、scrum团队每天召开一次会议，目的是汇总信息
已完成的成果
尚未完成的成果
下一步要做的工作
敏捷产品创新方法优缺点
优势
1、在很难提供业务需求文件或很难对项目进行量化时，就可以用敏捷方法
2、可以在大量变化中进行前瞻性开发和快速编码、测试，可快速对其进行纠正
3、通过定期会议经常性地更新工作进展，敏捷的本质都是迭代，需要通过客户的持续反馈进行开发
4、由于冲刺周期短、反馈及时，团队更容易应对变化
5、每日站会可评估个人生产率，从而提高成员生产率，也可提前识别问题然后迅速解决
6、它可以与任何技术/程序语言一起使用，尤其对web2.0或新媒体项目特别有用
7、在流程和管理上投入的费用非常少，可以更快、更省地交付成果
局限性
1、敏捷scrum是导致范围蔓延的主要原因，除非有明确的截至日期，否则相关方会不断要求团队交付新功能
2、如果对任务定义不明确，就无法准确估算项目成本和时间
3、如果团队成员没有全力以赴，就无法结束项目，甚至导致项目失败<br>
4、只适用于快速变化的小型项目
5、需要有经验的团队成员
6、敏捷教练需信任团队，但不能对团队成员进行严格的控制
7、开发流程中，任一团队成员的缺席都会对项目开发产生较大的负面影响。除非测试团队能够在每次冲刺后进行回归测试，否则项目质量管理很难落实和量化
