Scrum(Practice)

最新推荐文章于 2021-04-24 10:20:28 发布

weixin_33709219

最新推荐文章于 2021-04-24 10:20:28 发布

阅读量229

点赞数

原文链接：https://my.oschina.net/igooglezm/blog/841632

版权

2019独角兽企业重金招聘Python工程师标准>>>

【敏捷宣言】

  个体及交互>流程与工具
  可用的软件>冗长的文档
  客户协作>合同谈判
  响应变化>遵循计划

【敏捷实践】

1.Scrum不是万能药，要在时机成熟时推行。
2.限制Scrum团队的规模，建立Scrum团队之间的协作机制。5-9人
3.产品经理和研发工程师要拥抱scrum带来的变化。
4.量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度。
5.高效的sprint计划会的要素：预先梳理需求、合适的任务粒度、随机认领任务、运营调研任务、任务评估。
6.流水化安排开发环节与测试环节。
7.版本发布基本按照sprint周期。
8.Scrum需要配备合适的工程实践，例如，单元测试、代码审核、持续集成、项目管理工具。

【敏捷支柱】

迭代开发
增量交付(Definition of Done: DoD，"完成"的定义)
自组织团队
高优先级的需求驱动

【敏捷定义】

敏捷不是方法，而是思想，框架，目的在于“消灭一起工作效率瓶颈”，是在“不断变化”“不可预测”的环境中高效、（低耗）、（迅速）地完成“既定目标”。

【方法论的框架】
【一种迭代的流程】
【现有实践的集合】
【改善沟通的一种方式】
【最大化生产力的一种方式】

对敏捷的理解和实践：Scrum是Sprint的反复。

首先，Scrum整体上是由连续的开发区间 - Sprint构成。Sprint开始前，召开Sprint规划会议。此时，利害关系者在一起决定该Sprint做些什么。
产品研发的Sprint的建议长度2到4周，偏重实现客户需求的项目型sprint，根据实践总结，sprint长度一般可长可短。
计划会议（Sprint Planning Meeting）中，一旦决定了Sprint的实施内容，也就开始了一个Sprint。
Sprint中，每天召开Daily Scrum Meeting以确认每天的进度。利用Daily Scrum和Sprint两个不同长度的Time-box进行作业。
Sprint结束时，召开Sprint评审会议，审核成果物。
最后，在下一个Sprint开始之前召开回顾会（Sprint Retrospective Meeting)，讨论在下个Sprint团队应该改善的地方。

项目结束前，反复进行这样的工作。这，就是Scrum。

对Scrum框架的熟悉，是实施敏捷scrum的第一步。根据一般公司的敏捷实践，可以归纳为：三个角色，五个会议，三个产出物，两个过程控制物，五个价值。

【三个角色】

敏捷项目管理中，角色分为三种，Product Owner、Scrum Master、开发团队-开发人员and架构师。
为了便于理解，把敏捷研发过程隐喻为我们在拍电影。用电影角色来形象化定义敏捷中的角色。

【Product Owner】

故事作者 - 从业务角度驱动项目。

1.确定产品的功能，拆分用户故事story。
2.根据市场价值，客户需求确定功能优先级。(according to 投资回报率ROI)
3.决定版本发布的日期和发布内容。
4.每个Sprint，根据需要调整功能和优先级（原则上每个Sprint开始前调整，实际中在sprint实施过程中，也有可能
调整功能和优先级）。
5.接受或拒绝接受开发团队的工作成果。
6.Product Owner参与Scrum planning。
7.为产品的profitability of the product 产品盈利能力和ROI负责。（包括市场价值，客户满意，开发成本）
其中，投资回报率（ROI）。

在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。Product Owner在确定优先级排列的时候，是根据投资回报率ROI来确定。

【Scrum Master】

导演 - Team的领导和推进者。

1.保证团队资源完全可被利用并且全部是高产出的。
2.保证各个角色及职责的良好协作。
3.解决团队开发中的障碍。
4.做为团队和外部的接口，屏蔽外界对团队成员的干扰。
5.保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。

从组织层面，都是Scrum Master组织，但是Scrum Master应该让团队“自组织”，仅指导他们到点开会，怎么样开会。
Daily Scrum Meetings由每个scrum“微”团队来执行。
Sprint Planning Meetings由Product Owner来执行。
Sprint Review Meetings是由团队反馈召开的信息决定，Product Owner具体实施。

【Dev Team】

演员 - 交付产品并对其质量负责。
团队可以延伸为两个角色：开发人员和架构师。
团队-开发人员

1.评估工作量（story point）
2.拆分用户故事，定义任务（设计，界面，代码，测试，文档等）
3.评估资源利用率和工作时间（在结合资源利用率情况下，评估实际完成sprint需要的时间）
4.开发产品（设计，界面，代码，测试，文档等）
5.确保质量（敏捷要求对团队成员技术能力有较高要求）
6.改进流程（每个sprint回顾会议，改进下一个sprint的流程，没错，这是团队共同的责任！）
7.向Product Owner演示产品功能。

团队-架构师

1.在sprint之前，按照Aglie Modeling的思路建立系统的架构，这个架构是和团队一起完成，并欢迎团队中每一
个人为解决方案作出贡献。
2.在sprint中，负责具体的重构（架构和关键业务逻辑）
3.在sprint中，是一个指导者和协调者，可以确保团队不会缺少某些经验或时对某些技术感到不适而简单的拒绝一
种设计方案。也可以在团队中经常出现不同的意见。还会带来激烈的争吵时来帮助团队打破僵局，重新和谐。
4.在sprint中，和PM一起从业务价值的角度解释团队用到的技术方案的选择，所做的技术方案绝不是为了体现技术
领先，而是在成熟技术和业务价值之间做平衡。
5.在sprint中，story的实现不是工作重点，但是会承担部分story的实现。

在scrum团队中，“架构师”并非一个职位，尤其不是固定某人，而是倾向于在每个团队中，都确保要有能主持和协调编写架构的人，以防止队员们各自为战，符合敏捷的自组织精神的。

那实施敏捷研发和管理的组织，其他管理层在其中的角色如何定义呢？
【管理层】制片厂老板 - 为Scrum团队搭建良好的环境。

为Scrum团队搭建良好的环境，以确保团队能够出色工作
创建结构和稳定性
必要时，也会和Scrum Master一起重组组织结构和指导原则

【客户】制片人 - 为Scrum团队提出产品需求的人。

与组织签订合同以开发产品
在内部开发产品的公司中，批准项目预算
一般是组织中的高级管理人员

【最终用户】观众。

根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。很多人都可能成为最终用户。

【五个会议】

敏捷项目管理中，五个会议把整个敏捷开发模式串联起来，每个会议都代表着敏捷的一个阶段。

Product Backlog Refinement Meeting 或者 Product Backlog Estimation Meeting 或者 Backlog Grooming Meeting 或者 User Story Meeting 需求梳理会议
Sprint Planning Meeting 计划会议1+2
Daily Scrum Meeting　每日站会
Sprint Review Meeting 评审会议
Sprint Retrospective Meeting 回顾会议

一、 Product Backlog Refinement Meeting 需求梳理会议
该会议主要是梳理story，确定产品或项目的用户故事增量。确定具体的需求，确定做或不做(优先级); 评估工作量; 确定工作完成的标准。

【会议参与人】

Product Owner 产品负责人
Scrum Master
Developer Team 团队所有成员

【会议时间】

该会议时间限制为不超过 60分钟。

【会议流程】

用户故事的讨论和增加；
估算用户故事的Point。

【会议交付物】：

最新的，经过估算的，按价值和风险排列优先级的product backlog

【注意事项】：
一般召开了此会议，就不用再召开Product backlog估算会议，新增的用户故事在本次会议上会同时做好估算。该会议主要对疑难功能点如果转化成用户故事的一个讨论沟通会。

Deep story:

Detailed appropriately
Emergent
Estimated
Prioritized

目前，对story有两种估算方法：
1、估算story point。
用story point故事点，是为了看生产率（也可理解为资源利用率，产出率等）是否有所提升才发明的。product backlog估算会议是根据“标准故事”估算story point，团队听完PO讲解一个故事后，就会根据进行“标准故事”比较，估算这个故事的Point。故事点point是提供给你从全局上“预估”和衡量项目的大小：每个story的point累加值。迭代完成后回顾这次迭代的完成情况：完成了多少个story ，完成了多少个point。估算了故事点的团队，就不再关心到底多久会出来，而是祈祷“反正故事点和上个月一样多，应该能顺利完成吧”这种祈祷，多数情况下是有效的，最后也能完成。Sprint内的故事点一般是差不多，sprint迭代几次后，团队的生产率逐渐提高，故事点可逐渐增加。故事点point是没有办法burn的。需要转化成工作量。工作量出来的时候：story->task sprint backlog由领取任务的人，拆分story为task，估计绝对工作量。工作量最大的意义在于提供一个可衡量的参数来考虑一个sprint中能否消化完这么多的point。工作量也是衡量个体工作效率的指标。但是敏捷前提是对个体要求有较高的工作能力的，敏捷是团队的行为，虽然敏捷也会带来一些个体工作效率提升，但只是副作用而已。
2、直接估算时间。
国内目前真正使用story point的企业很少，几乎没有。因为与其去与一个标准故事比较，讨论差别，还不如直接估算工作量。唯一遗憾的是没有办法看每个人的工作率改进。

二、Sprint Planning Meeting 计划会议
Sprint计划会议一般分为两次举行。我们简单的命名为Sprint计划会议1和Sprint计划会议2。

Sprint计划会议1： sprint目标，内容，story二次估算，bug，task的point估算。
两个目的：第一个是决定哪些故事需要在这个sprint中完成，是sprint 计划会议的一个主要活动。更具体地说，就是哪些故事需要从product backlog拷贝到sprint backlog中。第二个目的是分析该sprint backlog是本次sprint会议的第二个主要目的，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议结束，团队将会决定他们在这个sprint结果中能交付哪些东西。
补充一下，product backlog根据我们的长期实践结果，我们定义为：功能性需求、非功能性需求、bug三大部分。

【会议参与人】

Product Owner 产品负责人
Scrum Master
Developer Team 团队所有成员

【会议时间】：

该会议时间限制为不超过 60分钟。
建议在早上召开该会议。

【会议流程】：

功能性需求：由Product Owner根据估算和优先级，从Product Backlog中挑选出该sprint阶段内的backlog，在白板上提出。
非功能性需求：由团队和Product Owner共同寻找非功能性需求，在白板上提出。
bug：现场bug或其他版本发现的bug。
由Product Owner排列2,3,4阐述内容的优先级。
分析本次Sprint Backlog，对1做再次估算,对2,3point估算确认。
Product Owner把story的point累加值，得到本次sprint的point。根据历史迭代的point数，确定本次sprint内容（发布的日期和发布内容）。
scrum团队一致认可并通过该Sprint Backlog，Product Owner确定本次sprint的目标。

【会议交付物】：

sprint目标
团队成员名单
sprint backlog
确定好sprint演示日期
确定好每日立会的时间地点

【注意事项】：
1、范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队进行；
2、外部质量是系统用户可以感知的。内部质量一般指用户看不到的要素。内部质量不能当做变量而使估算时间缩减。方法：故事的范围缩减或调整故事的重要性。
3、在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。
4、Product Owner可以通过调整故事优先级和故事范围（产品负责人判断出故事A中某些方面实际并不重要，所以他把A分成两个故事A1和A2，赋给它们不同的重要级别。）来让故事进入本次sprint。
5、可利用的资源：全身投入开发的时间基础上，考虑写文档的时间，会议，技术支持

Sprint计划会议2：功能设计会议，任务拆分，工作量和point合计调整。
Sprint计划会议2以设计工作为主，产品开发团队可以为他们要实现的解决方案完成设计工作。会议结束后，团队知道如何构建当前sprint中要开发的功能。

【会议参与人】

Product Owner 产品负责人
Scrum Master
Developer Team 团队所有成员

【会议时间】：

该会议时间限制为不超过 60分钟。

【会议流程】：

从第一个backlog条目开始。
确定对于客户的需求理解正确。
围绕该bcaklog条目进行设计，并给予下列类似问题：我们需要编写什么样的接口？需要创建什么样的架构？更新哪些表？更新或编写哪些组件？
sprint backlog由领取任务的人对story进行任务拆分task，并估计实际工作量。task接受人如果对工作量没有异议，按预估时间开始工作；如果有疑问，和任务拆分人提出时间调整意见，达成一致意见后，修改工作量。详细的工作量估算出来后，如果和story point相差较大，和product owner协商调整任务或者拆分story。直到可在一个sprint内完成。

【会议交付物】：

应用设计
架构设计图和相关图表
一些任务
确保团队知道应该如何完成任务（设计）

【注意事项】

敏捷对文档是轻量级的，对架构设计，接口设计，一些重要功能的设计需要有文档输出。敏捷认为所有的中间产品，比如计划，设计，测试用例等都缺少客户价值，客户最想要的价值就是最后可运行的软件。
该会议上会延伸出一些非功能性需求，成为本次sprint的backlog。
非功能性需求超出sprint的工作量，需要再次和Product Owner沟通变更backlog。

对估算会议和sprint计划会议1,2的重要内容“story的工作量估算”进行横向串联，得出估算流程。

三、Daily Scrum Meeting　每日站会
每日站会，收集障碍；领取或分配任务；更新任务板和燃尽图。

【会议参与人】

Product Owner 产品负责人(可选)
Scrum Master
Developer Team 团队所有成员

【会议时间】：

该会议时间限制为不超过 15分钟,最好控制在10分钟以内。

【会议流程】：

一个主持者；
每天早上在同样的时间和地点
团队成员围成一圈举行一个会议
在会议上每一个团队成员轮流回答：

         “已完成”
         “计划完成”
         “正在处理”
         “问题阻碍”（非障碍backlog，是指任务开展中需要开会讨论决议的工作，需要其他同事合作或架构师的技术协助等。）
【会议交付物】：

最新的障碍backlog
最新的sprint backlog
最新的燃尽图

【注意事项】：

Scrum Master不提出问题。
不转变会议话题。
必须按时开始，迟到者不允许发言或发问。
不讨论深入细节。
不是对领导的汇报，让团队中每个人都了解你的发言。
不能单独讨论，自发的有序的进行发言。
Scrum Master不要给团队成员更新任务和燃尽图。

四、Sprint Review Meeting 评审会议
Sprint评审会议，向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更backlog条目。我们这里的最终用户一般以项目经理替代客户角色。评审会议也根据实践情况，分成了sprint末的评审和及时跟进性评审（即story的及时性验收）。
sprint末的评审

【会议参与人】

Product Owner 产品负责人
Scrum Master
Developer Team 团队所有成员

【会议时间】：

该会议时间限制为不超过 90分钟。

【会议流程】：

Scrum Master主持会议，推进会议。
Product Owner主持会议，提醒本次sprint目标，本次sprint开发的story。
开发团队展示新功能，并且让最终用户尝试新功能。
最终用户的反馈由PO记录到backlog。

【会议交付物】：

障碍backlog输入；来自团队或最终用户的反馈为product backlog输入

【注意事项】：

不要展示不可能发布的产品增量。
Scrum Master不要负责展示结果。
团队不要针对Product Owner展示。

及时跟进性评审：及时跟进性评审是我们针对story的验收特别良好的敏捷实践，非会议形式。Product Owner和scrum团队成员点对点沟通模式。Product Owner对story的完成情况进行需求吻合度验证。验证通过，进入测试环节，验证没通过，团队需要返工修改。

五、Sprint Retrospective Meeting 回顾会议
Sprint回顾会议也叫反思会，目的是为了吸取经验教训，改进迭代过程，重点是改进团队和组织的工作流程，Scrum 团队如何在下一个Sprint 中做得更好。

【会议参与人】

Product Owner 产品负责人
Scrum Master
Developer Team 团队所有成员

【会议时间】

该会议时间限制为不超过 90分钟。

【会议流程】：

Scrum Master 首先给大家看Sprint Backlog，总结这个Sprint。
该sprint阶段的障碍backlog（在下文中会解释什么是障碍backlog）的讨论。Sprint期间，会不断产生障碍backlog，我们是用jira中的obstacle问题类型来进行记录和跟踪。本次会议上就要对这个sprint阶段内的障碍backlog进行讨论和解决。
该sprint内工作方式，方法，过程的回顾。与会人员轮流发言，每个人都有机会发表自己的意见：发现什么是好的，什么是不好的。有哪些好的做法可以启动，哪些不好的做法不能再继续下去了。
重大事件，重大缺陷的回顾总结。目前我们的实践是在会议上对blocker和Critical的bug在各版本间进行clone，保持truck和个branches的版本稳定。（这个任务仅作为我们敏捷实施在中的过渡性流程，等敏捷实践越来越成熟，这个流程会逐渐淡化到消失）
知识分享。

【会议交付物】：
Scrum Master总结下一个sprint改进的要点。我们的实践是会议的产出由项目管理工程师在下一个sprint中进行持续跟踪和改进观察；同时对需要会后完成的改进要点，记录到障碍backlog中，进行后续改进探索。
【注意事项】：
Sprint 回顾会议通常是最容易被忽略的。实际上，在敏捷框架汇总，Sprint 回顾会议的重要性仅次于Sprint 计划会议，是第二重要的会议。回顾会议是Scrum 团队协作进步，sprint方式方法，流程改进的最好的机会。如果不开Sprint 回顾会议，不久以后你就会发现，你的团队在不断地犯着同样的错误，sprint的脚步会永远持续不前。

【三个产出物】
【Product Backlog】产品待办事项
【Sprint Backlog】冲刺待办事项
【Increment】产品增量

【两个过程控制物】
一、燃尽图
燃尽图是敏捷开发过程中的进度管理工具图。展示剩余待完成工作与时间的关系，每日立会后更新燃尽图。未完成工作（Backlog）标识在纵坐标轴上，时间标识在横坐标轴上，可以用来协助预测项目所有的工作何时能完成，剩余多少工作量。未完成的工作可以从任务个数Issure Burndown Chart和任务工作量Hour Burndown Chart两个角度去展示。

【Release燃尽图】发布燃尽图
【sprint燃尽图】冲刺燃尽图
【Person燃尽图】个人燃尽图

注意事项：

燃尽图要求对sprint内的任务状态及时更新。
对sprint内的任务的任务花费时间及时记录。
sprint内变更，要及时进行任务的归属移动。

二、障碍backlog
障碍backlog是在敏捷实施过程中产生的，一般在每日站会后更新，在回顾会议上进行讨论和改进。障碍backolg也称问题列表（Error List），也寓意终极风险行动公示板（Ultimative Risk Action Board），也可理解为传统软件开发中的风险列表。（并非是和产品或者项目本身相关的技术性难题，而是指敏捷体系实施中的不完善性，不敏捷性的地方，sprint实施过程中的任何风险。）
内容范围：（举例，不限于以下几项）