Scrum软件开发用例有一个“三三四”原则，即三个角色、三个产出物、四个会议。其中，三个角色是PO、Scrum Master、Dev Team。PO：Product Owner，一般都是产品经理，负责需求分析和整理、分解验收story、维护Product backlog等。
一、scrum软件开发用例
scrum软件开发用例有一个“三三四”原则，即三个角色、三个产出物、四个会议。
三个角色：PO、Scrum Master、Dev Team
- PO：Product Owner，一般都是产品经理，负责需求分析和整理、分解验收story、维护Product backlog等（关于backlog和story会在下面有详细的描述）。
- Scrum Master：扮演推动者的角色，他要负责主持会议、协助团队内部成员解决困难、解决外部对团队内部的过分干扰、和外界的主要沟通工作等。Master可以由专门的人来担当，也可以由团队内部的成员来担当，很多团队都是由PO来同时兼任Master，笔者建议由团队内部成员轮流担当，这样能够培养团队成员的责任感，增强团队的凝聚力，并让大家更加容易理解敏捷开发的精髓。
- Dev Team：整个开发和测试团队，包括UI设计师等所有相关人员。
三个产出物：Product Backlog、Sprint Backlog、Potential Shippable Product Increment
- Product Backlog：产品需求池
- Sprint Backlog：此次需要开发的需求集合
- Potential Shippable Product Increment：可交付的结果
四个会议：Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint Retrospective
- Sprint Planning：需求评审会和迭代启动会，这个会议上，需要得出以下结论：
- 全员明确清晰的迭代目标
- 澄清所有的需求及技术实现风险
- 评估需要的工作量，以及需要投入的人员
- 确定出所有最终需要发布的功能集合及工作量，需要将Story拆解成Task，以小时为单位。
- Daily Scrum Planning：每日站会，顾名思义，就是站着开会，大家围成一个圈或者半圈，这样做有两个目的，一个是高效，另一个是可以方便团队所有人都可以看见对方。站会的目的有以下3个：
- 监督个人的承诺：确认个人是否完成昨日的目标
- 培养团队文化
- 了解项目进展：团队中每个人都应该了解其他人在做的事情，以及当前团队的进展和风险。最实际的好处就是这样可以清楚的知道别人做的事情是否对自己有影响，或者自己是否可以提供帮助等。
站会的时间，建议不超过15分钟，只描述状态和任务，不讨论技术细节，另外，每个人围绕以下3个话题来简单描述自己的进展：
- 昨天完成了什么？
- 目前有什么困难，需要帮助的？
- 今天准备做什么？
站会的时候，Scrum Master一定要注意以下问题：制止不必要的讨论、禁止小会、控制发言时间、不要跑题等，另外，站会的时候，Master需要修改燃尽图（后面会有对燃尽图的详细描述）。
- Sprint Review：迭代评审会，此次会议的主要内容是相关利益者及团队成员展现本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示结束后记录好相关反馈。很多采用敏捷开的团队都不开Review会议，其实Review会议是有一定的好处和目的的：
- 可以让团队的成果得到认可，提升团队的自我价值感
- 其他人可以了解团队在做的事情
- 可以吸引一些利益相关者的注意，并得到一些反馈
- 演示能够对团队成员造成的一定的压力，迫使团队认真完成工作
- Sprint Retrospective：迭代回顾会，会议主要是回顾此次迭代的整体情况，一定要全员参加，一起回顾此次迭代做的好的地方，以及需要改进的地方，并对这些需要改进的点，提出改进措施。
延伸阅读：
二、看板 & 燃尽图
看板一般是一个物理白板，目的是做迭代进展可视化跟踪和协作沟通。看板上需要将每个人的任务，以对应的状态（To Do/Not checked out、Doing/Checked out、Done）展示出来，一般使用便签纸。
同时要在白板上画出燃尽图，燃尽图指示的是当前剩余的工作量，是一个跟踪项目进展非常好的指示器。燃尽图上一般有2条曲线，如下图的燃尽图，灰色的直线表示的是优异剩余工作量曲线，蓝色的表示实际的剩余工作量曲线，正常情况下，蓝色的线应该在灰色的线上下浮动，并在最后一天合到同一个点上。燃尽图可以在每天站会的时候由PO更新状态。
