Scrum的简介和使用体验

主要思想

介绍Scrum之前，我们先说说敏捷开发。近十年里，大大小小的互联网公司为了快速占据市场，各种互联网产品喷薄式出现。如果项目开发还是走传统的瀑布模型，市场就很容易被其他公司瓜分。快，就成为一个项目成功的新指标，于是大家纷纷投向敏捷开发的怀抱。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 百度百科

然而，敏捷开发只是一种指导思想。目前主流的具体落地方案有Scrum和XP（本文不涉及），基于以上两种方案，大部分项目组会根据自身情况，汲取它们的可取之处，形成了具备自身特色的敏捷开发。以下根据作者的经历，介绍基于Scrum的敏捷开发和经验。

Scrum的英文字面意思是橄榄球运动的一个专业术语，表示“并列争球”的动作。意味着在这种模式下，开发团队如同运动员，必须富有激情地争夺完成任务，而不是被动的接受上司分配的任务；必须持续沟通，尽早暴露潜在的风险。

基于这样的设定，Scrum必定是一个高效的团队协作方式。

核心内容

参与人员

人员	作用
产品/项目负责人（Product Owner）	整个项目的利益关系者，代表着甲方/客户的利益。
流程管理员（Scrum Master）	负责每次的迭代/冲刺过程，有效推进迭代的进程。
开发团队（Scrum Team）	负责执行迭代的开发，测试和报告，一个高效的Scrum团队人员配置一般3 - 10人。

主要图表

• 产品Backlog（Product Backlog）：代表整个产品未来的规划，是个远期目标。
• 冲刺Backlog（SprintBacklog）：代表着每次冲刺的规划，每个小块代表着一个故事卡（User Story）。
• 燃尽图（Burn-down Chart)：代表着每次冲刺的完成效率。

以上图表通过Jira等项目与事务跟踪工具录入并使用。

重要活动

• Sprint计划会议（Sprint Planning Meeting）：Sprint初始，Product Owner会根据需求整理成一个个具体的故事卡（User Story），初步形成一个Sprint Backlog。随后开展一个Sprint Planning Meeting，目的是对Story进行讲解和评审，让开发团队有一个初步的概念并估算Story Point，最后根据优先级和分数综合评定并且重新整理成这次Sprint的Backlog。
• 任务拆分（Task Break Down）：确定Backlog之后，开发团队需要进行细分。通过抢夺的方式进行分配，开发就可以主动给自己合理规划这次Sprint的工作量，同时记录每个Story完成所需要的时间，这个分数和时间比就可以反映出每个开发人员的工作效率。
• 每日站会（Daily Scrum Meeting）：Sprint期间，每天用较短的时间（10分钟以内）进行近一天工作的陈述：昨天完成了什么；今天要做什么；有没有阻碍等。Scrum Master可以从中协商，解决团队遇到的问题。
• Sprint评审会议（Sprint Review Meeting）：Sprint结束前，开发团队给Product Owner一个演示，讲解当前Sprint的内容/功能，以确保开发结果是符合预期的。
• Sprint回顾会议（Sprint Retrospective Meeting）：Sprint结束后，大家开一个短会，抛出Sprint中遇到的难题和提出对团队有用的建议，最后一同商讨应对措施。

Story Point 的概念和估算方法

故事点（Story Point） 的出现，是为了用一个新的衡量单位替代“人天”。由于团队中，每个开发对同一个任务的看法，实现方式，经验都不尽相同，所以基于“每个人的工作效率不一样”的大前提，“人天”这种偏向时间的计量单位显得不准确。

但是对于同一个任务，大家总会有些观点是一样的。比如跑三公里路，搬五桶水。这些事情总会有一些共性，总能达成一致。类比到开发任务，根据团队人员的经验，总能抽象得到一个一致认可的分数。在Scrum里面，这个分数通过斐波纳奇数列标识的一种扑克具象化。分别有1，2，3，5，8，13，21……等分数值，这样做的好处是可以屏蔽直接使用时间单位所造成的主观差异。另外如果需要知道开发人员的效率，我们可以使用数据分析手段在故事点单位和时间单位之间建立换算关系，帮助掌控项目进度。

回到例子中，假设项目初期，对于跑三公里路，团队最后给出了3分，抢到任务的开发给出了5小时的时间需求，那么以后在对相同/类似的问题，3分就是一个标准，几乎不可能出现比3分高的评估，但是通常会出现偏离5小时的时间需求的情况，因为可能开发换了其他人:)

团队运作2~3个Sprint下来，会初步形成一个团队的总分数和总时间趋势表。后面就根据项目自身情况，制定下次Sprint的饱和度以分数还是以时间为界限。

经验之谈

• 不足/难点

1. 对于目标/期望不够清晰的项目，初期Scrum Master比较难以把控。
2. Daily Scrum在实施初期阶段会让团队感受比较大的压力，由于需要占用一定的工作时间，部分人员会存在不解的情绪。
3. 对于核心团队成员的技术水平，协作水平有较高要求，不适合临时的团队。
4. 初期会暴露非常多的问题，如果组织对于变化的接受度不高，会有很大的组织性冲击。

• 优点

1. 大部分的开发都有一个特点——不喜欢面对面沟通。Daily Scrum Meeting可以很好地解决沟通不足给项目带来的消极影响。
2. 在高强度的开发中，Sprint Retrospective Meeting带来的意见发表时间，作者认为是一个很好的压力释放方式。
3. 通过对Backlog的观察，团队可以对整体项目有一个宏观的概览。
4. 通过抢任务的方式，可以合理规划自己的时间。

小结

本文旨在介绍Agile中Scrum的主要概念和一些作者在团队中的使用Scrum的感受。读者可结合自身项目中情况，选取合理部分，优化团队中的不足。

Wechat: