Scrum后浪之3355
团队介绍
我们是光大科技有限公司智能云计算部运维服务团队智慧教学、教务项目组，在集团“聚焦数字化能力，构建平台化光大，引领智能化未来”战略指引下，积极构建数字化、智能化、生态化的教学、培训、管理平台，用科技赋能集团数字化转型。
Scrum介绍
在《Scrum指南》中对于scrum给出了这样的定义：“Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性的交付尽可能高价值的产品”。[1]
简单说Scrum=灵活+迭代：应用迭代增量的方式，将项目范围拆分为颗粒度更小的、更加便于管理的模块，来快速响应变化，缩减进度，增进标准适用性。
Scrum框架（图片来自于网络）
从图中可以看出，Scrum框架提出了很多新的概念，我们力求把这个框架介绍到可操作的程度。从便于理解的角度，Scrum框架可以归纳为3355方法论。
Scrum3355
3个角色
Product Owner（产品负责人）
负责最大化投资回报率，通过确定产品特性，把他们翻译成一个有优先级的列表,为下一个Sprint决定在这个列表中哪些应当优先级最高，并且不断的重新调整优先级和梳理这个列表。
Scrum Master
帮助团队学习并应用Scrum来达成商业价值，这是一个服务型管理职位，确保敏捷团队之间沟通顺畅。
团队成员
负责打造PO所指定的产品，团队成员包含了所有项目所需要的专业能力如开发、测试、UI等，建议5~9人团队最佳。
3个工件
Product Backlog（产品待办清单）
-
由Product Owner负责维护，包括增删及优先级。
-
用户故事是其中一种最佳实践。
-
每项需求都需要描述其外部价值。
Sprint Backlog（迭代待办清单）
Sprint Backlog即此次冲刺周期内规划要完成的内容。
-
来源于Product Backlog。
-
由团队评估和选择Product Backlog中哪些放入Sprint Backlog。
-
团队需要一起定义“完成”的标准。
Product Increment（产品增量）
Product Increment即冲刺结束后可对外发布的产品功能增量部分。
-
需要关注其是可工作的软件功能增量。
-
需要要在Scrum Review会议上进行演示。
5个活动
Product Backlog Grooming（产品列表精化）
Product Backlog Grooming，就是把当下产品的需求清单进行整理归纳，包括排优先级、拆成粒度适中的故事卡片、估算工作量等。这个环节独立于其他的四个会议（Sprint Planning, Daily Stand Up, Sprint Review, Retrospective Meeting）之外，却是整个开发流程中最重要的输入部分。只有Grooming完成，迭代计划会议（Sprint Planning）才能开始。
Product Backlog Grooming
通常我们把整个Product Backlog Grooming会议分成下列步骤：
-
需求收集整理：Product Owner作为主要负责人，给需求排出优先级；
-
需求拆分：开发，测试，项目负责人在一起，将需求拆分成可执行的用户故事；
-
工作量估算：项目负责人将每个用户故事给团队成员做详细阐述，然后团队一起估算工作量。
Sprint Planning（迭代计划会）
在传统的瀑布项目里，项目经理会根据收集到的工作信息，绘制计划表来计划所有的工作。团队工作人员根据项目经理的计划去工作，当工作无法按时完成或者提前完成时，会去通知项目经理这个变化。但是在Scrum里，我们不再使用甘特图来计划工作，所有的计划工作都是通过一个由包括产品负责人，ScrumMaster和研发团队参与的计划会完成的，这个会议就是Sprint Planning会议。
Sprint Planning（图片来自于网络）
Sprint Planning,主要是用来规划Sprint中要做的工作，团队从Product Backlog中选择本次迭代要完成的用户故事,形成本次Sprint的Sprint Backlog。会议的形式也是多元化的，这里我分享一个我们团队用到的方法：
-
PO(产品负责人)向大家讲解整体需求，场景，或者产品目标。
-
PO逐条按照优先级进行讲解，最好能够确定用户故事的验收标准。
-
开发团队沟通讨论实现方式，以及估算工作量，领取相关的任务。
-
开发团队应尽可能的针对自己不清楚的地方向PO提出问题。
-
将产品Backlog拆分成Sprint Backlog，也就是具体的任务。Sprint Backlog至少是一周的，也可以更多。一般是1周到4周。
-
如果讨论的一个用户故事过大，需要进行拆分。
-
测试人员也要积极参与讨论和提问，思考如何写测试用例。
最终，我们会在Sprint Planning结束后输出3个相关的文档（说敏捷没有文档的都是耍流氓）迭代待办清单、迭代工作量估算、迭代目标。
Daily Stand Up（每日站会）
每日站会是一个由核心团队参加的日常会议，即：Product Owner、开发人员和Scrum Master，目的是为了让团队成员及时了解项目进展同时沟通在项目进行中遇到那些障碍。
每日站会只有两天简单的规则，第一条是每天在固定的时间召开站会；第二条是在15分钟之内每个团队成员回答下面三个问题：
??我昨天完成了什么任务？
??我今天打算做什么任务？
??我遇到了哪些障碍或困难？
根据每天站会的情况由Scrum Master更新迭代待办清单。
Sprint Review（迭代评审会）
迭代评审会是在每个迭代快要结束的时候举行的团队会议，通常用来检查在这个Sprint中团队所交付的产品。在Sprint评审会议中，Scrum团队和项目相关方共同探讨在这次冲刺阶段中所完成的工作。根据完成情况和Sprint期间产品需求的变化，所有与会人员共同决定接下来可能要做的事情。
迭代评审会议包含以下内容：
??是由项目团队向产品负责人以及主要干系人来演示所有已完成的用户故事并解答关于交付增量的问题；
??每一个用户故事要以一个可工作的系统组件来展示；
??对这个周期中没有完成的用户故事予以反思和总结，并输出总结文档；
??对于开发紧跟市场变化的产品，要及时评审市场或现在的产品使用方式所带来的接下来要做的最有价值的东西的改变。
Sprint Review（图片来自于网络）
Sprint Retrospective（迭代回顾会）
Sprint Retrospective是Scrum 开发中一个重要的会议，但也是最容易被忽略的一个环节。在这个会议上，团队根据开发过程中团队遇到的问题提出团队改进方案使下一个Sprint能更加高效的进行。每一次的迭代回顾会就是想更快的得到团队成员对于工作问题和改进点的反馈，帮助提升团队内部的工作效能。
《Agile Retrospectives》把回顾会议分成了5个阶段[5]：
-
准备阶段
主持人整理上次回顾会团队决定的改进项并收集本次迭代评审会中总结的问题。
-
数据收集
主持人收集团队成员对于这个Sprint中发现的一些问题或者一些想法，然后主持人按照开始做、停止做和继续做这三个维度进行分类。
-
产生见解
这个环节做为回顾会的核心主要强调对于什么做的好的继续加强，对于做的不好的地方，团队一起协商改进方案。
-
确定改进项
针对每个改进的点，我们要具体分析导致该问题的根本原因，然后根据根本原因提出改进措施。
-
结束会议
针对本次会议内容做总结，以及确认改进监督负责人。
5个价值观
勇气-有勇气做出承诺，履行承诺，接受别人的尊重
承诺-愿意对目标做出承诺
专注-把你的心思和能力都用到你承诺的工作上去
开放-把项目中的一切开放给每个人看
尊重-每个人都有他独特的背景和经验
参考资料
[1] Scrum指南
[2] www.jianshu.com/p/ef7c5b644046
[3] https://cloud.tencent.com/developer/article/1613274
[4] http://www.guoyf.com.cn/SAFE/iteration-review.html
[5] https://blog.csdn.net/leveldc/article/details/85037588?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
[6] https://blog.csdn.net/weixin_34150830/article/details/93191430
关注
我们
扫描二维码 ｜关注我们
作者：李鹏
原创文章，作者：EBCloud，如若转载，请注明出处：https://www.sudun.com/ask/33609.html
