一张图带你了解敏捷开发Scrum
最近我公司在全力推行敏捷开发Scrum，感觉效率提升很大，所以简单分享下敏捷开发Scrum。
图中体现了SCRUM框架，包括3个角色、3个工件、5个活动、5个价值，下面一一说明。
对应重点图右上角：
Product Owner：简称PO， 产品负责人， 负责维护产品订单的人，代表利益相关者的利益。
Scrum Master：简称SM，可以理解为Scrum主管，为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
Scrum Team: 开发团队Team，由负责自我管理开发产品的人组成的跨职能团队。
对应重点图右下角：
Product Backlog：按照优先级排序的高层需求。
Sprint Backlog：要在冲刺中完成的任务的清单。
Burndown Chart：燃尽图，在冲刺长度上显示所有剩余工作时间逐日递减的图，因整体上总是递减而得名。
分享下我们的任务清单白板：
对应重点图的左下边：
Sprint: 冲刺Sprint，一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。
Sprint Planning Meeting：计划会，在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
Daily Scrum Meeting：每日站会，团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
Sprint Review：Sprint评审会议，在冲刺结束前给产品负责人演示并接受评价的会议。
Retrospective：Sprint回顾会议，在冲刺结束后召开的关于自我持续改进的会议。
分享下我们Sprint回顾会议画的心情曲线：
分享下我们Sprint Planning Meeting上的纸牌：
专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。
勇气：我们需要勇气去迎接各种挑战。
公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。
承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。
尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。
Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产
品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求
。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交
潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
开发者们经历了很多项目，无论敏捷与否，往往都能顺利的完成项目开发。在这众多项目中，我们经历过很多软件开发模式，每种模式都有其华丽的学术名称，瀑布、原型、迭代、螺旋、敏捷，还有放羊式的。而其实这些模式最大的区别，不在于成果，而在于达成目标的过程的难易程度。
打个比方，每个人从家里到公司上班，可以选择多种方式，比如开车，电动车或自行车。无论哪种方式，我们最终都会在规定的上班时间抵达公司。区别在于，开车可能最快，但是要忍受高峰期堵车。电动车灵巧方便，但是要注意安全。自行车最慢，但是强身健体。而使用哪种方式上班，取决于当天的路况和我的心情。
所谓的项目管理或者软件开发模式，我认为最大的目的不在于将软件开发完成，而是如何让团队以一种更健康和轻松的方式达成目标。而评价什么方式是健康而轻松的唯一标准，就是加班的次数。
所以，请去掉敏捷华丽的外衣：
1.站会一定要简短，时间一定要固定。
2.迭代计划会之前，核心人员参与分析和计划，做好充足的准备，会上，其他人倾听和提问即可。
3.去掉任何的信息化系统，使用白板。
4.请延长评审周期，不要太过频繁，实在苦不堪言。
5.若做不到团队扁平化，有官僚倾向，那就别敏捷了，换其他一种方式。
6.敏捷中会议的种类很多，开会不是程序员该干的事情。适当删减，以及无需每次都全员参与，把时间还给程序员。
7.不要为了敏捷而敏捷，这只是个方法论，不是放之四海而皆准。
以下是重点：
所谓的项目管理或者软件开发模式，我认为最大的目的不在于将软件开发完成，而是如何让团队以一种更健康和轻松的方式达成目标。而评价什么方式是健康而轻松的唯一标准，就是加班的次数。