一、敏捷开发的原则
开发的最高目标是通过尽早和持续地交付有价值的软件来满足客户。
即使在项目开发的后期，仍然欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
在项目过程中，业务人员要和开发人员每天在一起;
要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
团队内部和各个团队之间，最有效的方法是面对面的沟通。
可工作的软件是衡量进度的首要指标。
敏捷过程提倡可持续的开发。项目方、开发方人员和用户应该能够保持恒久、稳定的进展速度。
对技术卓越和好的设计的持续关注有助于增强敏捷性。
尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自自组织团队。
团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为。
二、scrum敏捷流程
1. 需求规划
po会将利益相关者们的需求以及自身想法转化为具体的用户故事，接着进行需求规划：与利益相关者了解需求价值，放弃伪需求和无价值需求，将价值需求放入product backlog（需求池）；和敏捷团队沟通需求规模（实现难度与时长），以需求的价值和规模做为判断依据，对需求池内容进行优先级排序；必要时，还会将需求拆解为多个子需求，单个子需求具备能在一次sprint迭代中实现的可能性。
通常项目早期，或者并非卓越超群的团队，对于需求的判断多是不准确的；更多的是在需求池内相对的比较选择，快速产出投入市场，在反馈中得到验证与矫正，并在此过程中提升团队能力，这也正是敏捷的价值所在。
2. sprint计划会议（sprint planning meeting）
每次迭代一般都是从计划会议开始，为确保开发质量与效率，通常会根据团队的开发速度，将需求池内容制定到迭代计划中，一次迭代大概解决4~6个需求（视具体情况而定）；计划会议针对本次迭代范围，进行需求评审，并将一个需求拆解为多个任务，明确每个任务的目标和验收标准，以及任务估算排期，产出一份sprint backlog（任务列表）。
这里值得一提的是需求规划和需求评审的区别，前者由po主导，涉及商业、市场、运营，更像是范围层“做什么，不做什么”；后者由pm主导，涉及业务逻辑、产品架构、产品设计、功能实现、用户体验设计，更像是结构层“如何构建，如何连接”。
比如po提出一个用户故事，孩子的多个家长都可以实时收到孩子的学习情况，需求规划会对该需求价值、规模进行评判：其投资回报率及产品当前阶段，现在是否要实现这个需求。
pm根据这个需求细化，是通过push通知、短信通知、弹窗通知还是信息提示？包含学习时长、测试成绩、能力分析模型、老师评价等哪些功能?需求评审会对这些实现需求基于用户体验、技术层面进行评判：其实现方式、可行性、疑难点、潜在风险，如何去落地实现这些需求或者部分需求。
3. 每日站会（daily scrum meeting）
项目进入开发阶段，设计、开发、测试按照计划展开工作。
每天早上展开一个15分钟的站会来跟进项目进度，每个人都说说自己昨天的任务及完成度、今天的待办任务，确保迭代计划的正常进行；遇到了什么问题及背后原因，是否会影响其他关联任务或其他成员，以及是否需要帮助，确保及时规避风险。
每日 scrum 站会增进团队间的交流沟通、发现开发过程中需要移除的障碍、促进快速决策、提高团队的认知程度，这是一个进行检视与适应的关键会议。
4. 需求变更
需求变更是在所难免的，要“响应变化高于遵循计划”；若发生紧急变更，从开发成本进行考量，是在本次完成还是将部分任务延后到下一次迭代，以确保本次迭代能如期交付；若发生重大变更，需要进行团队会议讨论pg电子试玩平台的解决方案。
随着时间变化，问题发现、需求新解、任务完成，会对sprint backlog进行不断地调整修改。
5. 测试验收
对已完成开发的功能进行可用性、易用性、体验度、还原度等一系列测试验收，发布通过测试的部分、修复未通过部分；注意敏捷开发中的测试并非完成本次迭代所有开发任务才测试，而是完成一个测试一个，及时地发现问题解决问题。
6. sprint评审会议（sprint review meeting）
在迭代快结束时举行sprint评审会议 ，敏捷团队演示这次迭代完成的工作（demo演示），讨论当前sprint backlog情况、做的好的地方、遇到什么问题及如何解决的，并解答相关问题；然后po、利益相关者、敏捷团队一起探讨接下来可能要做的事情，评审市场变化或竞品新动向将会对造成什么影响；这并不是一个单纯进度汇报会议，目的是为了获取反馈并促进及时调整。
7.sprint回顾会议（sprint retrospective meeting）
每次迭代结束后需要进行一次回顾会议，复盘所遇问题、成本偏差、协作过程，提炼做得好的和需要改进的地方，并制定改进计划；这个时候po还会根据收集到的用户反馈、上线数据，大家一起探讨优化方案，大致规划下一个sprint，以便成员们提前准备。
个人需要做的是将本次迭代经验总结，积极地向成员们分享你所学到的知识及方法技巧，沉淀为团队知识库、方法论，复用到日后的迭代中去。