大数据敏捷团队的开发管理实践

内容简介：大数据敏捷团队的开发管理实践

本场Chat的内容包括：

1. Scrum的角色定义

2. Scrum会议简介

3. 实际项目中Scrum Master的定位

4. 用户故事的拆分与管理(Jira管理用户故事)

5. 非技术型Scrum Master如何应用度量指标

6. 大数据Scrum团队案例分享(借助Kanban理念动作团队)

敏捷一词已深入人心，不管你是否在用，你也一定听过或学过很多次。敏捷到底是什么，应该怎么来运用，或许每个人都有自己的理解和自己实践的方式。本文从基本概念出发，结合实践，介绍在特定环境的敏捷实践经验。

先从一张图开始对Scrum有一个大体的了解。

SCRUM中的3，3，5，5

3个角色

1. 产品负责人（Product Owner）。

2. Scrum Master。

3. Scrum团队。

3个工件

1. 产品Backlog（Product Backlog）。

2. Sprint Backlog。

3. 燃尽图（Burn-down Chart)/Product Increment。

5个会议

1. 产品Backlog梳理会议（Backlog Grooming Meeting）

2. Sprint计划会议（Sprint Planning Meeting）

3. 每日站会（Daily Stand-up Meeting）

4. Sprint评审会议（Sprint Review Meeting）

5. Sprint回顾会议（Sprint Retrospective Meeting）

5个价值

1. 承诺 – 愿意对目标做出承诺。

2. 专注– 把你的心思和能力都用到你承诺的工作上去。

3. 开放– Scrum 把项目中的一切开放给每个人看。

4. 尊重– 每个人都有他独特的背景和经验。

5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重。

SCRUM理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:

第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。 Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

备注：以上内容很基础，也是Scrum的基石。换个角度，其实也就是Scrum中的前置条件或者说是假设条件，我们在实施过程中要验证这些前置条件，有则增强，无则需建立。

Scrum 中角色定义（3个角色）

Scrum会议简介（5个会议）

1. 产品Backlog梳理会议（Backlog Grooming Meeting）

产品Backlog梳理会议从可预测性和产品愿景两个维护对产品Backlog进行。根据DoR, DEEP的原则，使用Planning Poker对Story进行评估。

2. Sprint计划会议（Sprint Planning Meeting）

Sprint计划会议从做什么，怎么做的两个维度来对Story进行拆解，根据Team的Capacity和Velocity得出当前Sprint Backlog.

3. 每日站会（Daily Stand-up Meeting）

每日站会，最重要的是观注团队成员的更新并更新自己的当天计划。注意限时和紧扣主题。

4. Sprint评审会议（Sprint Review Meeting）

Sprint评审会议可以很好的展示产品成果。通过展示，所有人员可以了解我们当前进度和产品现状，新的想法等，可以有助于产品的下一步推进。

5. Sprint回顾会议（Sprint Retrospective Meeting）

Sprint回顾会议，通过同事间的认可，可以增进团队成员间的相互了解。可以借助头脑风爆等模式，保证每个成员能在会议上发言。

实际项目中Scrum Master的定位

在ScrumMaster角色定义中，他是确保Team正确地做事 的人，从概念上讲，更偏向于一个流程的保证者。职责如下：

• 辅导团队正确应用敏捷实践。

• 引导团队建立并遵守规则。

• 保护团队不受打扰。

• 推动解决团队遇到的障碍。

• 激励团队。

然而，在实际工作中，Scrum Master可能对Team能力估计不足，也可能希望通过承诺更多的工作以得到领导的认可，结果导致Team在Sprint中承诺的东西不能完成或者加班，Scrum Master应该自我约束。同时，PO可能直接给Team成员任务，影响Team成员的工作节奏及计划。

因此Scrum Master应该引导团队建立并遵守规则，保护团队不受打扰。这需要Scrum Master具有有效沟通能力。Scrum Master此时应起到一种“衔接”的作用，包含PO、自己的老板及相关干系人。显然，PO和自己的老板的目标存在不一致性。因此，沟通艺术的重要性不言而喻。如何说服PO，使得老板满意，并且让Team开心，这是一门学问。

实际项目中，可能存在下面几种情况

1. Scrum Master由项目经理兼任。

   你可能需要同时兼顾把关质量，跟踪进度。如何平衡Scrum流程与项目进度与质量?

2. Scrum Master由Team成员兼任或轮职。

   你除了Scrum Master日常工作外，还需要完成本职工作。你将面临工作如何分配的问题。

3. Scrum Master由专职人员负责。

   有的公司 需要对项目负责 ，有的 不需要对项目负责 。如果对项目负责，在沟通过程中，特别是PO，如何做到不偏不倚。如果不对项目负责，如何让团队信任你。

我们简单分析一下以上三种情形:

第一种情形，公司可能想使用敏捷方法来改进项目开发流程。由于项目经理兼任，可能存在对Scrum不熟悉的情况，产生误用错用不能使Scrum发生功效。

第二种情形，全员Scrum Master, 可以很好的提高每一个Team成员责任心，同样存在技能不足的问题，同时也存在本职工作与Scrum Master工作难以平衡的问题。

第三种情形，对项目进度负责的情形，能很好的提高Scrum Master的责任心，在应用Scrum同时，也观注实际效果，寻求改进。但在与PO沟通需求时，对Scrum Master的沟通要求更高，如何让PO理解你对需求的某些拒绝不是为了Team少做任务呢？如果不对项目负责，就需要花更多的时间让团队接受你，考验Scrum Master拉扰团队的能力了。当然，专职Scrum Master也存在不懂业务的情况，只能照搬流程，存在判断困难，不能及时为团队发现问题，排除障碍。

用户故事的拆分与管理(Jira管理用户故事)

用户故事

在Scrum敏捷管理中有一个很重要的概念，就是用户故事(User Stories)。在敏捷开发中，用户故事作为研发团队内部或研发团队与用户沟通的重要文档，有着非常重要的作用，因此写好用户故事，对敏捷开发的沟通非常重要。本文主要讲述用户故事如何编写，并通过一个完整实例来帮助大家理解用户故事。

3C和INVEST原则

先来说说用户故事的预备知识。用户故事可以理解为描述一个角色，通过做一件事情，实现一个目标，并给出验收标准。用户故事需要满足3C原则和INVEST原则。

3C原则

• Card(卡片)

• Conversation(会话)

• Confirmation(确认)

INVEST原则

• Independent(独立的)

• Negotiable(可协商的)

• Valuable(有价值的)

• Estimable(可估算的)

• Sized Appropriately or Small(大小合适的)

• Testable(可测试的)

开始之前

编写用户故事之前，我们首先应该了解角色(Roles)与目标(Goals)，了解用户行为、目标、重要性，是我们缩写用户故事的依据。

可以通过一些基本的问题来了解用户行为，目标和价值：

• 谁将使用我们的软件？(角色)

• 为什么他们会使用我们的软件？(价值)

• 使用我们软件的这些人有什么重要特征？

编写用户故事

有了以上的预备知识，下面开始讲述如何编写用户故事。用户故事一般写在卡片上，先来看一个用户故事卡。

卡片正面：

卡片背面：

卡片上体现出来的是用户故事的四大主要模块：

• Role(角色): As a …(作为一个XXX人员，表明角色)。

• Goal(目标): I want/need …(我需要什么功能，表明目标)。

• Value(价值): So that …(有了这个功能之后，我能做什么，表明价值)。

• Acceptance Criteria(验收标准)：I’ll know this is complete when…….(当我看到XXX的时候，我就知道我要的功能完成了，这就是验收标准)。

卡片上还有一些其它部分：

• Unique #: 用户故事唯一编号。

• Title: 一句话描述故事内容。

• Assumption: 此用户故事的假设部分。任何假设都是项目风险。

• Estimate: 评估的故事点(不同形式名称和意义可能不一样，这里只讲故事点)。

一些注意事项

填写这些东西的一些注意事项：

Role(角色)

• 在开始写用户故事的时候就需要确定角色。

• 相同角色的人应该有共同的任务或权限。

Goal(目标)

• 关注用户需要什么，而不是我们的系统能提供什么。

• 清楚的描述目标。

Value(价值)

• 为什么需要这个功能？

• 用户故事产生的价值应该与业务目标紧密关联的。

Acceptance Criteria(验收标准)

• Given – 给定假设，前置条件，系统状态等。

• When – 做什么样的操作。

• Then – 得到什么样的结果。

下面来看一个完整的实例，帮助理解用户故事：

As a：客户服务代表。

I want to： 登录到系统。

so that： 我可以看到我的未完成工作任务列表。

I will know this is complete when：

我已经正确填好用户名和密码登录系统，我的未完成工作任务列表会显示出来，包含任务名称，开始时间，整体进度，完成时间信息，如下图所示(图略，请脑补，实际操作中请勿省略)。

分支情况1: 如果没有工作任务在列表中，则显示“太棒了，你的工作全都做完了。”

分支情况2: 如果我不是授权用户，则显示“你没有权限查看工作任务列表。”

从例子中可以看出，用户故事可以理解为描述一个角色，通过做一件事情，实现一个目标。如何来衡量目标的完成，验收标准(I will know this is complete when)是很重要的一部分。验收标准给评估的准确性提供保障。

管理工具：使用Jira管理用户故事

对于User Story如何管理，我们这里介绍一下JIRA的好处。操作简单，流程定制，便捷的团队协作，及时监控。同时，提供丰富的报表，及时的通知，集成第三方插件，源代码集成等。具体可以参考JIRA中文官网： http://www.jira.cn 。

通过JIRA的Scrum Board, 我们可以建立Sprints（如下图）。在敏捷的会议中，可以更新调整故事。

非技术型ScrumMaster如何应用度量指标

如果上面四部分都很熟悉，希望下面能给带来点不一样的东西。下图是一个C#代码的度量指标，当然不限定只使用于C#。

为什么要用指标？

是否与敏捷理念背离，答案是否定的。敏捷宣言4+1句中的最后一句，明确指明右边的也是有价值的。我的理解是，右边项是手段或者载体，不是目的。比如说：我们是使用流程和 工具 帮助我们达到个体与交互。实际上我们的工作是完全离不开流程和工作的。差别就在于是被要求使用还是团队主动想去使用的问题。

如果应用这些指标，团队会接受吗？我们从指标的本质来看，如代码覆盖率(Code Coverage)和单元测试个数(Unit Test Counts), 编写单元测试是保证我们的实现和预期一致的最好保障，并且为代码的修改保驾护航。这两个指标的意义在于，我们约定单元测试的数量和代码行相关，开发人员就会想办法去减少代码行，以减少Ctrl+C和Ctrl+V的事情发生，并且思考如何用最少的代码行去实现同样的业务逻辑。我们再看系统集成测试的用例数量，同样与代码行相关。如此设计的原因源于对代码行常需要多少测试用例覆盖的经验值。同时，开发写的代码无论好与坏，是同时作用于开发自己和测试的。以减少发生开发不优化代码导致测试工作量过大的问题。其它各种指数除了保证代码的可读性以外，也有类似的意义，这里不一一列举。

大数据Scrum团队案例分享

要让敏捷得以实行，我们应该了解敏捷的3个层次，理念（敏捷核心思想），优秀实践（敏捷的经验积累）和具体应用（能够结合自身灵活应用才是真正敏捷）。 补充一下Kanban的基本理念：可视化，无固定角色，限定WIP。

实例：讲述一个大数据团队应用敏捷的过程（内容本身与大数据无关，但与团队结构相关）

下面介绍一下我们团队初期的一个情况：

1. 每个框前饼图代表成员投入百分比。

2. 代表外地核心团队成员； 代表本地核心团队成员； 代表非团队成员，主要是职能组织领导，未实际参与项目； 代表非团队成员，并且会干预来自本职能部门的领导。

3. Local的PM/Scrum Master角色由我担任。

你会发现，Local团队核心成员共 19 位，外地核心成员 8 位，非核心成员但直接会干预团队的人员共有 4 位，并且两地有 13/14 个小时时差。项目一期持续 一年零9个月 。此项目为项目集中项目之一。整个项目集有百人以上。

项目成员技能包含：ETL, C#, DB, UI, C++等。

项目所需技术包含：ETL,C#,DB, UI, JAVA，Kafka, RabbitMQ, Data Warehose, DB Model等。

由于此项目需要技术专业较强的人员，项目成立时，从各职能部门借调人员成立项目组，并且在项目组中存在头衔与项目角色不匹配的情况。任何团队在建立过程中，都是符合团队发展四个阶段的，可以从下图了解团队发展的每个阶段，对应的问题，以及应该具体的能力与解决方向的指导。这里不详述。

我们从Scrum的3355中的5个会议讲解遇到的问题以及采用过的相关策略。

站会

$\underline{团队形成期及风暴期的突出问题}$

内部问题：人多，未使用过Scrum任务板，不太了解站会规则，人员不能准时不齐，会议冲突。

外部挑战：为什么拆分成多个组？

内部问题应对：建立Scrum任务板（To do, Development, Waiting QA, QA, Done）， 制定站会规则（9:30准时开始，限时15分钟，不离主题，对于25%投入员，至少保证一人每天到场）。

外部挑战应对：坚持不拆分。原因是团队95%的站会中能够顺畅按规则更新完各自的状态，拆分团队带来的信息流失会更严重，会议总时间会增加。

$\underline{团队规范期及绩效期的突出问题}$

内部问题：白板更新不及时/不能与JIRA同步，缺少热情，有时不观注团队成员进度

内部问题应对：引入一分钟项目经理，增加物理Burn Up Chart(以任务数算）

产品Backlog梳理会议（Backlog Grooming Meeting）

$\underline{团队形成期及风暴期的突出问题}$

内部问题：个人估算、以时间为单位，User Story按人员的职能拆分（DB,UI，API,Backend,QA等），个人仅观自已相关开发模块的业务介绍，存在谁负责创建User Story之争等

外部问题：技术依赖外部架构，需求与外部有依赖

内部问题应对：同一职能的成员估算，保证同一职能的成员对业务熟悉，由BA负责创建业务User Story, 技术负责人创建技术相关User Story. 其它保留现状不变

外部问题应对：技术负责人与公司相关架构人，通用技术标准提前沟通学习，使技术符合整个项目规范。需求提前至少一个Sprint与上下游安排好相到依赖的工作，准备。

$\underline{团队规范期及绩效期的突出问题}$

内部问题：UI, API,DB等难以同步开发，不同职能的成员对业务不熟悉，本地开发团队对需求的问题不能得到及时有效的响应，团队成员参与度不高。

外部问题：需求依赖，技术依赖模糊，交付时间不能很好承诺。

内部问题应对：以业务模块划分User Story, UI/API/DB作为同一业务模块的子任务，所有成员统一估算，转换为难易度估算。成立本地开发团队的PO。使用电子工具的同时，使用Post-It, 实时建立物理白板所需要的User story。

外部问题应对：建立Scrum of Scrum会议，项目集Planning event。

Sprint计划会议（Sprint Planning Meeting）

$\underline{团队形成期及风暴期的突出问题}$

内部问题：远程会议，花费很多时间去重复一些理念、流程的看法，设计成员偶尔参加会议，语言障碍，会议效率低

外部问题：项目集其他项目组临时加需求，项目组之间Sprint起止时间不一致导致需求Sprint内变更

内部问题应对：从项目5个价值观出发，建立信任。增加设计Review会议。

外部问题应对：通过增加与上下游沟通，尽量减少类似需求变更发生。保证每个组Scrum Master等负责沟通的成员清楚各自组的Sprint起止时间。

$\underline{团队规范期及绩效期的突出问题}$

内部问题：技术架构设计进度慢，观注新需求开发，Bug解决不及时，Ownership不强，团队成员参与度不高。

外部问题：对项目团队的Sprint完成比有疑问。

内部问题应对：建立专门任务在Sprint并找到负责人跟进，Bug按优先级排进Sprint作为承诺之一。使用Backlog Grooming建立的Post-IT, 团队成员根据讨论实时拆分子任务，并记录Task到所属User story。

外部问题应对：引进Agile Coach,观注并改进问题

Sprint评审会议（Sprint Review Meeting）

问题：由于两地团队，未设定固定的评审会议，UI设计师对UI要求很严格，总是不能通过审查。

问题应对：前置评审会议，UI设计师在会议中发现问题及时沟通。时间在Sprint结束前两天，保证反馈的问题及时修复。

Sprint回顾会议（Sprint Retrospective Meeting）

$\underline{团队形成期及风暴期的突出问题}$

问题：形式单—，不能持续，发言人不积极，会议1.5小时，零食文化。

问题应对：尝试不同方法开回顾会议。

$\underline{团队规范期及绩效期的突出问题}$

问题：同样存在形式单一的问题，不能持续的问题。

问题应对：引入Silent Brain Storm, 缩减会议时间到一小时，取消零食。

其他核心会议

周会1：每周一早上，Local核心成员与外地核心讲中文成员，更新上周核心问题跟进及核心问题讲解，全中文会议。在引入Agile Coach后，认为此会议非必要，属于浪费。但这个会议会持续下去，根据我的实践，这类会议在两地团队非常有必要。

周会2：每周三晚上，Local核心成员与外地核心成员，更新自上次会议核心问题跟进及核心问题讲解，全英文会议。在项目成员重组后取消。持续时间，一年。

项目集Planning Event:所有PO, Scrum Master, 及项目成员一天的计划会议。后由PO,Scrum Master, Tech Lead负责讲解每个Team的计划及依赖，风险。在一天的不同会议中达成一致。

系统架构设计Review会议：持续半年。项目前期需要保持核心架构能相到了解。

UI设计Review会议：后期加入，两周一次，在UI设计完后，由设计成员介绍给Local团队。以保证问题和理解的一致性。仅会议仅发生在有新UI设计时候。

结束

经过一年零九个月的风风雨雨，项目才队渐渐变的成熟，其中经历过各种理论的理解之争。最终，我们从Scrum, Kanban的基本理念出发，得以让团队进行稳定和绩效期。再次预览一下项目组现在的成员结构，继续二期的开发工作。

致谢

感谢GitChat提供平台, 感谢打赏并看坚持看到最后的朋友, 感谢Linty的推荐. 同时也感谢Glen的培训,手稿来自培训。

实录： 《Dragon：大数据敏捷团队开发管理实战解析》

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 敏捷团队实践
• 电商团队云原生实践
• 前端团队代码规范最佳实践
• 研发团队资源成本优化实践
• 小团队微服务落地实践
• 聊聊SwiftLint在团队的实践

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。