敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。是一种应对快速变化的需求的一种软件开发能力。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷流程：
CP1：项目立项。（输出：PO提交立项表。）
CP2：发布计划。（在敏捷V1.2中，新增自定义过程。输出：业务目标陈述书、配置管理计划、敏捷自定义过程表、轻量级监管文档和度量数据）
CP3：迭代开发。（在敏捷V1.2中，新增关键文档更新。输出：迭代成果、产品backlog、sprint backlog、轻量级监管文档和度量数据、风险跟踪）
CP4：发布冲刺。（在敏捷V1.2中，新增放行测试和就绪审查。输出：轻量级监管文档和度量数据、放行测试报告、上线就绪审查表）
CP5：项目结项。（输出：轻量级监管文档和度量数据、项目总结报告）
CP5：维护支撑。（输出：轻量级监管文档、问题列表）
一、问题总结：
1.敏捷团队过程成熟度由质量成熟度和敏捷成熟度构成。
2.团队成熟度星级按就低原则进行评估。
3.敏捷方法认为需求是涌现式的，范围是不确定的。
4.敏捷方法在每个迭代结束的时候进行检视和调整，调整包括需求、范围、人员以及计划。
5.敏捷方法通过持续的检视和调整使得 范围、成本、时间 保持一个平衡的状态。
6.我们通过身体力行和帮助他人来揭示更好的研发开发方式。
7.每日站会的目的是检视和调整，是为了发现问题。
二、敏捷原则：
1. 我们的最高目标是，通过尽早和持续地交付有价值的研发来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变
更，帮助客户获得竞争优势。
3. 要不断交付可用的研发，周期从几周到几个月不等，且越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能
够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的研发是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持
恒久稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
三、通过敏捷方法形成的价值观：
1.个体与交互 重于 过程和工具。
2.可用的研发 重于 完备的文档。
3.客户协作 重于 合同谈判。
4.响应变化 重于 遵循计划。
以上并不代表后者毫无价值，只是更着重于前者。
四、scrum执行技巧：
(一) scrum框架
三个角色：产品负责人，scrum master，sprint团队。
六个时间箱：sprint，发布计划会议，sprint计划会议，每日站会，sprint评审会议，sprint回顾会议。
四个工件：产品backlog，发布燃尽图，sprint backlog，sprint燃尽图。
(二) sprint计划会议
(三)对项目完成的定义
团队要和产品负责人、项目干系人在完成的定义上达成一致。
对完成的定义取决于产品的质量目标：
1、整洁的代码。
2、经过了重构。
3、进行了单元测试。
4、通过构建。
5、完成了验收测试。
6、对于一些需要交付文档的产品、文档也要包括其中。
五、每日站会的注意事项
1、scrum master和团队才可以发言。
2、会前做好准备。
3、严格准守时间箱，不能迟到。
4、它是团队成员的交流，不是向scrum master和产品经理汇报。
5、它是每个人对其他队员的承诺。
6、它的目的是检视和调整，是为了发现问题。
六、评审会议
评审会议是大家对当前项目真实状况的一个了解。
明确会议记录人。
七、回顾会议
回顾会议中 scrum master 应该用好“问团队”的技巧，如何提问让大家自然而然的参与进来。
回顾会议的第一件事情就是要回顾上一次 回顾会议 的议题，看看上次的决议是否有进展。
展示任务板和燃尽图。
以上是我对近期敏捷开发的一个总结，有参考别人的文案，也有一些自己的感悟，参考敏捷开发方法并结合自己之前的工作经历，深有体会PO和SM在敏捷方法中的关键作用。如若彻底落实敏捷方法，相信项目会在以后的发展会逐渐成熟与健壮。以上如有错误或侵权，希望看到此文的笔友给予纠正。
