Scrum实践

写在前面

       团队之前以做项目为主，一般项目周期不超过3个月，大家习惯了瀑布式（waterfall）的项目管理方式。如今要做产品，希望能够提高工作效率，适应互联网时代的节奏、适应用户需求的变更。于是乎，推荐敏捷开发方法的Scrum给整个团队。

一、为什么使用敏捷开发方法

       敏捷管理是相对于传统的瀑布模型提出的，传统的瀑布开发模式如下图1所示：

图1、瀑布模型

       瀑布开发模式的项目周期往往比较长，难以适应需求的变化，当项目开发完成后，最后交付成果往往不是产品经理或是客户真正想要的，最后只能重新从项目的需求开始返工，浪费整个项目周期。
       而敏捷开发流程是这样的：

图2、敏捷开发模型

每一个迭代的开发周期很短，一般为2-4周，它将瀑布开发过程切分为多个短的迭代式的增量开发过程。每一个迭代结束，都会产生最终可用的产品，如果需求有变化，可以在下一个迭代周期进行开发，基本不会出现最终交付产品是用户无法接受的情况，即使要浪费时间的话，最多就是一个迭代周期的时间。

二、Scrum方法

       Scrum是敏捷开发方式的一种。Scrum强调沟通，要求团队所有人（有条件的话，甚至包括客户，随时了解客户需求、询问客户是否满意）一起工作，通过高效沟通解决问题。Scrum项目管理方法是一个持续改进的过程。
       Scrum的具体流程如下图3所示：

图3、Scrum开发流程

       产品负责人（PO）获取用户需求（User Story），生成带有优先级的产品需求列表（PBIs），在每个迭代周期开始时，会召开一个迭代计划会（Sprint Planning），从产品需求列表中挑选出本次迭代期要实现的功能，得到一个冲刺列表（Sprint Backlog）。接下来，团队会进入一个2-4周的迭代期，在迭代期内，团队会进行项目的开发、测试、文档编写等工作，需要召开每日站会（Standup Meeting），了解团队成员的工作进展及遇到的困难，在迭代期的最后，会召开项目评审会（Sprint Review）和回顾会（Sprint Retrospective）。每个迭代交付的都是可以工作的软件。Scrum使用燃尽图（Burn Down Chart）来跟踪项目的进展。

名词解释

PO：Product Owner，产品负责任/产品经理
User Story：用户故事，用以表达用户需求
PBIs：Product Backlog Items，产品需求列表/需求池
Sprint：冲刺/快跑，简单理解为一个迭代
Sprint Planning：迭代计划会
Sprint Backlog：迭代需求列表
Scrum Meeting/Standup Meeting/Daily Meeting：每日站会
Sprint Review：迭代评审会
Sprint Retrospective：迭代回顾会
SM：Scrum Master，敏捷教练，最重要的一个角色，也是敏捷团队的核心成员
Burn Down Chart：燃尽图，用于表示剩余工作量的工作图表
Scrum Team：所有相关人员都是Scrum团队的成员
Stake Holder：项目干系人/利益相关方

Scrum角色

产品负责人（PO）：负责确定项目需求，维护PBIs；
Scrum Team：整个开发和测试团队、及其他相关干系人;
Scrum Master（SM）：负责主持会议，排除团队遇到的困难以及外界的干扰，具体职责如下：

• 确保Team按照Scrum的方式运行；
• Team的教练（Coach），帮助team更好的工作；
• Process的Owner，能够在team和PO之间平衡；
• 考虑项目干系人的影响，移除项目障碍，保障项目进度。

产出物

• Product Backlog（产品功能列表）
• Sprint Backlog（Sprint冲刺列表）
• Burn Down Chart（燃尽图）

Scrum会议

• 迭代计划会：Sprint Planning，确定本次Sprint需要完成的功能需求；
• 每日站会：Standup Meeting，每日站会时间不超过15分钟，主要围绕三个问题展开，我昨天完成了什么？我今天要做什么？我遇到了什么困难？每日站会上不讨论细节问题，每个人的发言控制在2分钟以内；
• 迭代评审会：Sprint Review，项目团队将已实现的项目结果进行演示，听取利益相关方的反馈，以便在下一个Sprint进行改进；
• 迭代回顾会：Sprint Retrospective，对本次Sprint进行回顾，哪些是做的好的，哪里需要改进的，并对这些改进的点，提出改进措施，在下一个Sprint中进行实现；

三、敏捷的价值

1、快速响应变化：Scrum开发完全适应现在互联网开发提出的“小步快跑”，以轻量级的User Story作为需求进行迭代式开发，保证最重要的功能优先做；
2、项目团队的透明性：敏捷团队所有成员都能了解当前项目的进展和问题；
3、项目团队的专注：项目团队可以确保把时间放在与冲刺目标相关的事情上，不受外界干扰。

四、具体实施

       敏捷开发需要借助以下工具来实现，同时结合团队和项目的现状，制定具体的实施方案。

       1.组织结构

图4、组织结构图

              Dev Team：开发团队
              Test Team：测试团队
              Data Team：数据团队

       我们的项目比较特殊一些，相对于传统的软件项目，增加了数据团队这个组织。数据团队需要与开发团队、测试团队相配合共同完成项目。

       2. 工具使用

• 项目管理工具（看板）：Trello - https://trello.com/， Trello可以创建私有项目，鉴于项目有些敏感的内容不宜放在Trello上，建议使用Trello + NAS相结合的方式，敏感的内容放在NAS（群晖）上，在Trello上引用NAS上的内容；

• 燃尽图工具：Excel可以画，有没有更简单易用的单独画燃尽图的工具？

       3.管理流程

       前期准备工作：梳理全部需求，包括产品需求（外部）、优化需求（内部）等，形成产品需求列表（PBIs）。
       迭代周期：2周（10个working day，4个public day），如遇紧急情况4个非工作日可能安排加班，请大家理解！
       工作流程：

       表1、迭代周期时间安排

Day	工作安排	备注
Day 1	9:30~10:30–迭代计划会；10:40~11:40–需求评审会；14:00~16:00–各组工作分解；16:30~17:30-项目计划会	Working day
Day 2–Day 5	每日站会（9：15）	Working day
Day 6–Day 7	休息日	Weekends
Day 8–Day 11	每日站会（9：15）	Working day
Day 12	14:00~15:30-迭代评审会;16:00~17:30-迭代回顾会	Working day
Day 13-Day 14	休息日	Weekends

       上表中的各种会议说明如下：
       表2、会议说明

会议	目的	参加人员	产出
迭代计划会	从产品需求列表中挑选出本次迭代期要实现的功能	PO/SM/Dev Lead/Test lead/Data Lead	冲刺列表（Sprint Backlog）
需求评审会	对本次冲刺列表中的需求进行详细讲解	PO/SM/ALL	需求问题收集（PO负责）
工作分解会	各个功能团队对本次迭代需求做工作分解	各个功能团队	各团队工作计划（Lead负责）
项目计划会	SM协调各个团队的协同/配合计划	SM/Leads	项目迭代总体计划（SM负责）
迭代评审会	工作成果展示	Leads/ALL	PO确认成果
迭代回顾会	本次迭代经验总结，下次改进	ALL	SM组织
每日站会	当天工作安排	ALL（不含PO）	不超过15分钟

五、原则与建议

       无规矩无以成方圆，我们的原则就是我们的规矩。大家都守规矩、重原则，慢慢养成良好的工作习惯，并形成一种文化，这样工作起来更加流畅、效率更高。

1. 口说无凭，写下来的东西才算数，避免口口相传，信息失真；
2. 始终坚持公开、公平、公正的原则；
3. 守时！守时！守时！绝大多数中国人都做不到，这是一种对他人的尊重、也是一种自身的教养；
4. 诚信！诚信！诚信！同样是大多数中国人都做不到，说到做到，承诺完成的任务一定保质保量按时完成；
5. 不提倡加班，但是要求今日事今日毕，绝不能因为自己的拖延而影响整个团队；
6. 偶尔的加班在所难免，经常性的加班一定是项目管理出了问题；
7. 打破一团和气，工作问题可以争吵，大胆地说出工作中存在的问题，帮助团队成长，个人与团队共同成长；
8. 实践远比理论复杂的多，实践出真知，实践中可能会遇到各种书本上找不到答案的问题，需要团队一起不断去克服；
9. 允许抱怨，欢迎吐槽，经常被抱怨和吐槽的问题，往往就是项目/团队管理中存在的实际问题；
10. 张弛有度的原则，紧张的同时也要适当放松，经常组织团队建设活动；
11. 打造一个良好的学习氛围，在不影响项目交付的情况下，经常组织各种讲座与交流，让团队每一个成员都有机会分享自己的技术、生活、爱好等相关内容，鼓励团队成员进行分享，也是对演讲能力的一种培养方式；
12. 沟通的重要性不言而喻，但是要减少或避免无效的沟通；
13. 每次会议的时间不超过一个小时，一个人的注意力很难保持那么长时间；
14. 其他好的建议，欢迎指教！

六、一些技巧

1. 关于开会：

• 每次会议都必须有记录人，记录会议内容，由会议召集人（组织者）指定；会后整理会议纪要，发送给所有与会者及相关干系人；
• 会议既要准时开始，也要准时结束，不能晚，不能拖，因为每个人都有自己的时间安排，不能打乱会议成员的工作安排。
• 会议时间不要超过一个小时；
• 尽量开短会、开小会，长会、大会尽量少，要限制次数；

2. 关于守时：

• 不管是会议也好，其他活动也罢，凡是迟到者都要受到一定的惩罚，或者给其他人买零食，或者折现（每次50元）作为团队活动经费；
• 会议或者其他活动那个开始与结束都要守时，按时开始，按时结束；
• 对于开会迟到者，除了物质惩罚之外，可以考虑把会上讨论的工作多给其安排一些（不算欺负人，只是对迟到者的另一种惩罚方式而已，）；

3. 关于放松：

• 建议在两个紧张的迭代之后进行一次轻松一点的迭代，以这种2+1的方式进行，以便缓解团队成员压力；
• 有条件的情况下，每个月组织一次聚餐，让团队成员增进了解、加深感情、缓解压力；每个季度组织一次户外活动，放松身心、锻炼身体；可由团队成员轮流组织，同时也可培养个人的组织能力；

       2020年6月23日 星期二 成稿于青岛市
       2020年6月26日 星期五 补充第六部分于北京家中