处理复杂的事情，要用框架
处理复杂的事情，如果有框架指导，就能保证最终结果的完整性、系统性及正确性。另外，通过框架，将复杂的事情切分成较小块、把工作流程标准化，从而将大问题变成一个个小问题，大大减少工作难度。
软件开发是一项复杂的活动，敏捷开发也有自己的一种框架：Scrum。
Scrum是什么？
Scrum是基于敏捷思想的开发框架，用于迭代式增量软件开发过程。 它基于经验型流程控制理论，所以Scrum框架的坚信：
- 知识源于经验
- 决策基于已知的事物
- 透明性、检视、调整是经验型流程的三大支柱
- 采用迭代增量式的方法来优化可预测性和管理风险
如下是标准的Scrum标准流程示意图：
Scrum详细介绍
我们先来看下Scrum的三种角色：Product Owner、Scrum Master、Team。Product Owner负责产品需求管理、需求优先级定义、及产品验收等；Scrum Master作为团队Scrum流程的引导者；Team负责根据需求交付产品。这三个角色分别代表业务方、实施方、及项目流程管理方。
下面我就通过讲故事来描述，各个角色参与的活动，及在活动中产出物。
总工作量
Product Owner通过各种手段收集产品需求（产品愿景、市场分析、竞品分析、用户、管理层、干系人），然后把这些需求整理成story列表，并按优先级来排序。这个排过序的列表就是Product Backlog。Product Backlog定义产品的业务需求，供产品开发团队使用。
当影响产品发展方向的因素发生改变，则Product Backlog也要进行审视，新加、更改或者删除一些story。
Product Backlog需求粒度，越接近开发日期的越细。
本迭代工作量
Scrum每一个迭代叫Sprint，一个Sprint 1周到4周不等。在一个Sprint开始时，Team和Product Owner在Sprint Planning Meeting上，挑出本Sprint能完成的若干高优先级story。这些story组成Sprint Backlog。
迭代开发
团队开始开发Sprint Backlog里面的story，每天Daily Scrum Meeting（站会），商量开发中遇到问题，看团队其他人可以帮忙或分享自己开发过程中得到的知识。在开发过程中，如果有什么业务问题，需要及时和Product Owner进行确认，确保做出来的东西是正确的。
整个开发过程用物理墙可视化。
迭代成果演示
如果一切顺利，到Sprint结尾，团队基本开发完了所有Sprint Backlog里的story。Product Owner会和团队发起Sprint Review会议，团队会演示story、回顾这个Sprint的开发情况，展示Burn Up Chart，RAIDs等。
迭代反思
如果Product Owner对于story没有什么意见，那么本次Sprint就结束了。团队如果觉得该Sprint开发过程中，存在一些问题需要改进，就可以一起进行Sprint Retrospective，在会议上反思在这一迭代中哪些做的好，哪些做的不好，有什么建议，并且产出改善团队开发的行动，并且制定Owner，在下一Sprint进行执行。在我看来Retrospective是敏捷最迷人的地方，能保证团队持续改进，提高生产效率。
整个过程和 戴明循环（PDCA）原理是一样的，都是计划、做、检验、反思并形成改进行动。
Scrum不光能用于软件开发，也能用于非软件开发的任务管理，是一个强有力的任务推动框架。
感谢框架，让我们工作变的容易。
