敏捷的特点

• 按一定周期进行迭代发布，通常是2-4周一个迭代。用最短的时间交付有用的价值。
• 跨职能、多角色组成的团队，通常是5-10人组成。角色有：sm（销售人员）、po（产品或业务负责人）、team（开发、测试、UI）

原则

• scrum • 会议：计划会、站会、评审会 • 流程：backlog、 增量开发、迭代发布、交付
• 看板原则 • 可视化 • 流动 •在制品限制

由PO给开发团队描述这些用户故事。过程中根据PO的功能描述，团队成员提出自己的疑问，在相互的反馈沟通中达成共识。最后给每个用户故事指派一个主要负责人，并对这个故事进行估算，将前后端的工作量进行统计，得出一个故事点。这个故事就结束了，进入下一个故事的讨论 （故事点：它们用来度量规模和复杂度，表达‘用完成任务所需时间来表示难度。故事点数是需要实现一个故事所付出时间的相对度量）

po职责

1. 迭代前：迭代计划会上，讲述用户故事、决定故事优先级（是否删除部分）
2. 迭代中：
3. 针对优先级事项，研发人员遇到不懂的与其及时沟通；
4. 每日站会上，遇到抛出的问题，会后与开发人员一同做讨论决定；
5. PO将下个迭代需要进行的需求进行拆分，以用户故事的方式进行描述，创建在backlog中。PO与UI会就这些故事开始讨论，PO描述故事所要达成的功能（出简单原型图），从而再让UI出高保真原型图。在UI出图后，与UI进行沟通调整，将反馈的修改意见进行优化调整，将原型图与相关的故事关联。
6. 功能确认后，测试人员或者PO需要开始编写这个迭代各个功能点的测试用例。当在活跃冲刺看板中卡片流动到了“验证测试“时，PO和UI可以针对故事进行多方面测试，有功能的、样式的。一旦发现问题，若与开发人员确定是bug，则将相关的子任务打回给开发人员，然后创建缺陷，随即关联该故事或子任务。
7. （比如这个迭代的功能均属于1.0版本发布的，PO可以在猪齿鱼测试管理找到0.9版本的用例，将其克隆一份到1.0版本，再针对新增的功能在1.0下创建新的用例，对于变更的功能找到之前的用例，在此基础上进行修改。最后，继续测试计划，指派测试人员。）
8. 迭代后期:
9. 第一个迭代po做增量测试 ——》 所有成员进行针对测试用例进行全量测试、bug修复
10. Ps:开发人员也参与测试，是交叉测试-回归测试。猪齿鱼测试管理，支持在每个用例的步骤创建bug，并可以直接关联到当前冲刺。 （回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。）

敏捷开发模式中的四种会议： 计划会，每日站会，回顾会，评审会