• 云筑集采研发团队的Scrum敏捷实践总结

Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。目前结合材料中心项目组实际实践情况，特整理以下“本地化、接地气”的Scrum 敏捷实践流程，内容仅供参考，可结合各组具体情况进行调整以规范成适合自己项目组的敏捷开发流程。

1 Scrum核心流程

我们所有的动作都应该按照上述流程进行流转，这个过程是不能变化的，定制化的流程可在每个大环节进行适当调整和变更。另外交付时间从过往经验看，2周一个迭代周期是最合适的时间段，周期太长显得冗余且易走回老路，周期太短Scrum框架约束的必需流程无法正常完成。

2 理想是美好的，现实是骨感的

以上流程理想情况下团队人员固定且团队能够完全自驱，不需要太多外部的资源介入，团队内部就能够完成当前迭代所有工作。但是实际情况却不是这样的，尤其是组织架构都是由单一职能团队构成的，一次迭代可能涉及到多团队协作。这种情况下，可能每个团队每个人都处于不同的迭代中，这样就加大了团队间的沟通成本，可能PO或者SM大部分时间都在各种沟通、协调会议中。除此之外，团队中的成员可能会随时切换TA的状态，以便快速进入当前需要处理的迭代中来，这样也会让成员注意力不那么集中，不能全身心地投入到这次“冲刺”中来。更极端的情况每次迭代人员结构都在变化，新进的同学又要花时间适应目前的迭代状态，熟悉各个环节和流程。这个时候就可能出现以下情况：需求被压缩工时估算可能会稍超出预期Scrum中一些流程可能会被忽略甚至被迫移除（如需求评审、任务拆解、需求评审压缩成一个）测试介入时间点依旧是整个迭代完成后，而不是有产出时就可以介入了（因为测试可能身处其他迭代）如果成员时常变动，会让后面来的同学又需要花时间了解前期迭代的需求，加大了进入当前迭代的成本团队面对这样的问题，最终可能会妥协，因为完成需求才是头等大事。这样就出现了传统模式和敏捷模式并行，这个时候就可以各自取舍，有针对性的应用敏捷开发的实践方法，并且持续尝试进行改进，形成符合目前团队状态的本地化的敏捷开发模式。

3 再谈三个必要角色

PO（Product Owner，产品负责人）

PO是整个产品的第一负责人，他不仅需要规划每一次迭代的任务，还需要展望产品的未来，这样才能保证团队是在 “做正确的事”，而不会走偏。因此PO在整个产品生命周期中，都会看到他的身影，他无处不在！因此经过落地实践，除了常规PO需要完成工作外，还需要关注以下事项：

• 能够简洁、清楚地表述产品待办列表
• 需要简述每个待办事项所带来的价值（最好是讨论后大家公认的价值）

• 对待办事项进行打分（建议采用百分制）。这里不建议使用类似紧急、普通的词汇来给待办事项进行排序。

  SM（Scrum Master，敏捷专家/项目经理）

  如果说PO是带兵打仗的“李团长”，那么SM就是“二营长”。SM可以不是TL角色，但他是一个“战术参谋”， 他的角色主要是引导团队理解Scrum理论，并践行这些规则，帮助团队最大化创造团队价值。从落地情况来看，可以让团队部分核心成员轮流担任SM角色，这样能够让每个核心成员都有足够的参与感，事后可以对这次角色互换进行总结，并将好的CASE传授给下一位小伙伴，达到共同提升的目的。SM需要以各种方式服务我们的PO以及团队，主要需要关注以下事项：

• 尽可能保证团队每个成员都能理解目标、范围和产品域（保证让团队成员理解前，自己需要事先理解这些产品待办列表）

• 按照当前步骤引导即将触发的Scrum事件（如每日站会、验收会、总结会等）
• 作为沟通枢纽，自驱团队内部的沟通以及跨职能团的协作沟通要随时关注迭代中的产出项，是否符合预期，有无困难等，如果发现问题，需要及时和PO沟通，以便指定相关应对计划

• 产品Backlog梳理、项目进度维护以及Sprint Backlog进度维护

  Team（Scrum Team，Scrum团队）

  “团长”和“营长”都有了，没有上前冲锋的“士兵”怎么行，Scrum团队就是在一线冲锋的“士兵”。Scrum团队中包含各种专业人员（如后端、前端、测试等各职能线成员），他们需要相互协作以在每个Sprint完成时交出潜在可发布的产品增量，需要明确的一点是，只有Scrum团队成员才能创建增量。Team应该具有以下特点：

• 团队是一个整体，应该拥有产出产品增量所需全部技能（常见产品、前后端开发、测试同学）

• 团队所有成员目标应该一致（至少身处当前迭代时的目标应该是一致的）

• 团队的每个成员都各有所长甚至有专注的领域，但是最终责任属于整个团队

  4 我们是怎么维护Backlog的

  Backlog是敏捷3355理论中3个工件中提出的，维护方式每个实践团队可能不同，但大体目的都是一致的。以下简述了材料中心管理和维护Backlog的方式，仅供参考：

  产品Backlog（Product Backlog）

  本质上是一个产品视角的需求清单，可看成是一个需求池。维护工具可以是在线文档、JIRA、TAPD等这样的工具，它有以下几点需要注意：

• 应该由产品同学负责维护，包括优先级以及增删的维护工作

• 使用用户故事的方式描述需求有助于团队成员更好地理解需求

• 每个需求都需要描述它的背景、价值

  迭代Backlog（Sprint Backlog）

  它是从产品Backlog“精挑细选”出来当前迭代周期内需要完成的内容。维护工具建议采用在线文档 的方式，它也需要注意以下几点：

• 来源于产品列表

• 它应该由团队成员共同评估，选择合适的产品Backlog中
• 放入到迭代Backlog中团队成员需要一起定义”完成“的标准

注：我们在实践过程中，Sprint Backlog除了标准基础字段外，我们还加了5W1H8C1D这一列，这样更进 一步让团队成员深入了解需求的全局。
所谓5W1H8C1D，指：

• 5W 包括 When（何时）、Where（何地）、Who（何人）、What（何事）和 Why（何因），代表需求产生的背景和功能上线后的运行环境；
• H 是指 How（如何），代表业务需求的处理逻辑。
• 8C 包括性能、成本、时间、技术、可靠性、安全性、合规性、兼容性，代表保证质量符合要求的约束条件（Constraint）。
• D 是指 Data（数据），反映了业务上线之后的效果，包括业务效果和系统效果。

  5 材料中心项目组本地化Scrum流程

  
  注：以上流程中，从开发进入后团队每日站会就可以开始进行了。

  6 Scrum中的几个会议我们是怎么开的？

  如上流程所示，整个迭代前期以及后期团队会进行各种会议，这些会议每次的主题应该明确，同时也不建议将这些会议压缩成一个。每次会议中，SM应该扮演引导角色，尤其是前期，应该积极协助PO完成每一次会议，并且每次会议都应该有所产出，而不是没有成果的一次会议。

  6.1 需求评审会会议

  发起人应该由PO主动发起，会议前产品同学整理好这次需要讨论的需求列表并且为每个需求打分。参会人员至少应该包括开发、测试，根据实际情况也可以叫上需求方。会议中产品同学应该逐个讲解每一个需求的背景、价值、预期目标，过程中干系人员可以对当前需求提出一些问题（如未理解为什么要做这个需求），这时产品同学需要耐心地回答这些问题，这个过程中或许会给出产品未想到的一些问题，可结合实际情况进行合并。会议成果应该是根据产品给出分数，确定一个当前迭代的Backlog，各方达成一致会议结束，进入下一个阶段。
  

  6.2 任务拆解会/工时、故事点估算

  需求评审会后，干系人员需要对Backlog进行简单地评估，至少要达到大概知道这个需求该怎么去消费它。会议发起人应该是由SM发起，参会人员需要包括开发、测试和产品。会议的主要内容就是通过敏捷扑克这个道具，让每个干系人出牌，然后根据出牌情况进行评估，最高和最低数值的同学需要分别讲解各自评估的理由，然后可进行二次出牌，最终可取一个平均值作为此次的结果。
  
  出牌前SM应该简述当前需求的背景以及需要达成的目标（可采用5W1H8C1D分析法），然后定义一个基准（通常采用一个完整的CRUD为3个故事点）以及一个准则（如一个需求需要多端协调时，评估时应该单独评估还是一起评估可以根据各自团队的实际情况来决定）。会议成果应该是一份Sprint Backlog，下面列出了每个需求的用户故事、价值、故事点等。
  

  6.3 设计评审会

  这个会议可以根据实际情况进行开展，如果迭代中有一些重要的需要关注的点，可以对这个点进行需求设计，然后由产品和开发同学一起评估这个设计。

  6.4 Code Review + 单元测试

  Code Review会议是我们本地化后的一个会议（这时开发人员在除了修复Bug之外就会有一些额外的时间），这个会议时间点应该是提交测试后，由SM组织所有开发人员参与的一个会议，会议主要内容就是每个人负责的一块代码逻辑的讲解，其他同学在这个过程中可以评估当前解决方案是否有待优化或者不合理的地方，另外责任人也可以抛出当时做这个需求时遇到的一些问题（有时候为了完成这个功能采用了一些其他方法，但是或许还有更优的解决办法）。
  
  在集采团队新项目的迭代过程中，单元测试是一个必选的过程，从而保障项目代码结构的健壮性，也可以为持续的重构打下基础。

  6.5 下个迭代的需求初评梳理会

  这个会议一般也是在迭代后期进行（一般是提测后上预发布之前），发起人主要是PO和SM，组织最核心的开发和测试人员（注意不是团队所有成员）简单梳理下版本需要迭代的任务。作为两个迭代之间的一个衔接，开发人员在测试阶段也可以提前调研一下下个迭代的需求，是否有一些坑可以提前排查，以便于在下个迭代的需求正式评审会议中提出来一些问题。当然，这个会议也可根据实际情况来进行选择，比如当前版本后期问题较多或者有相关变动，也可以放到当前迭代完成到下版本开始前这个时间点。

  6.6 迭代演示评审会

  这个会议可选在测试完成和迭代上线前的某个时间点，与会人员需要我们的需求提出方参与。但是如果是涉及到2C的用户，这种情况的话产品同学必须参加，TA一定程度上代表需求方。这个会议的一个目的就是要让需求方也参与到这个迭代中来，从需求文档到最终产出这个需求过程，让他们实际看到我们的产出并且也让他们有很强的参与感。

  还记得敏捷价值观中的“客户合作 胜过 合同谈判”么？

这个会议的另外一个目的，就是给需求提出方演示当前迭代的产出是否真实符合他们的需要，是否解决了他们的问题，如果和预期不符，可根据实际情况评估后是否需要当前迭代修复。

6.7 迭代回顾总结会

这是一个迭代完成后的复盘会议，这个会议建议是必须要开的，它是帮助团队持续改进的关键。主要有SM发起，与会人员是当前迭代的测试、开发、产品等人员（干系人）。以下是材料中心总结会的流程，可供参考：

（1）暖场活动

可找一个与当前迭代相关或者不相关的话题，每个与会人员思考1-2分钟，然后用一句话阐述观点。整个过程建议不要超过10分钟，太长容易导致话题走偏，其目的主要是让大家开口说话，让大家状态快速切入到当前会议中来。

（2）项目关键信息回顾

简单回顾当前迭代的需求内容，以下材料中心某次迭代关键信息：

（3）Good & Need to Improve

会议中由SM为每人发两张不同颜色的贴纸，与会人员在不同颜色的贴纸上写下当前迭代做的好的与需要改善的地方（一定要写下来），然后各自发言说出来，并由SM誊抄到白板上（主要是让大家都能看清楚）。然后团队投票找出1-2个（贪多嚼不烂）做的好的与需要改善的点，在下一环节中使用5W分析法找出问题根本原因。以下是材料中心迭代总结会后的成果，供大家参考：

（4）找出问题

针对需要改善的点可以使用5W分析法找出问题的根本原因，以上述Need to Improve第一点为例，我们使用5W分析法来找出问题原因：

• 为什么数据修复了两轮？
• 答：因为迭代上线后产品发现材料中心依旧存在商品名称有小数的情况。
• 为什么？
• 答：因为修复数据的时候少考虑了小数的情况，只考虑了纯数字以及纯字母的商品名称数据。
• 为什么漏考虑了小数部分？
• 答：因为做需求梳理的时候其他小伙伴贴了SQL语句，然后就使用此SQL语句进行待修复数据的查询动作。
• 为什么？
• 答：因为以为贴出的SQL是包含了下表所有列出的数据，遗漏了下方罗列的EXCEL列表，同时对查询出来的数据没有仔细核对。

至此，问题根本问题就找到了，就是开发人员不细心，忽略了产品需求下面罗列的资料导致问题的出现。至此就可以进行下一步了，讨论对策。（5）讨论对策就上问题，最终大家讨论了两个解决办法：

• 关键需求可根据实际情况拉上所有干系人开一个设计评审会
• 需求罗列出的附件资源都是有价值的，应该需要被关注

  6.8 每日站会

  每日站会也是建议必须进行的会议，从我们目前实践来看，开发介入后开始每日站会是一个比较好的切入时间点。每日站会主要目的是对昨日总结以及今天需要做的工作的规划，并且更新我们的Sprint待办列表。当然，如果有碰到什么问题，也需要在每日站会中指出来，然后私下讨论解决方案，如果个人解决不了，需要由SM/TL协助解决。
  
  TIPS：站会时，SM可以引导成员站在最前面，面向所有成员进行陈述。陈述时只需要说明做了什么、即将要做什么，碰到什么问题或阻碍，不必深入细节，有问题可以会后进行讨论。整个站会持续时间建议在10分钟左右。
  

  7 不要忘了“完成”的定义

  “完成”的定义在一定程度上表示了一种“承诺”，这个”完成“的定义最直观地可以看成达到了这个故事点预期目标，但是在多团队协作时，这个定义应该由他们共同制定，当然也可以根据实际情况调整它的定义，比如测试完成或者做了Code Review亦或是上线后一段时间内没有问题。但是一旦给出了一个故事点“完成”的定义，那么我们的团队成员都应该遵守这个定义。另外要确定是否达到这个标准，需要有产品和需求方（用户）共同来确定（这也是需求演示会的一个目的）。如果待办事项未达到完成的定义，这个时候我们应该重新斟酌是否还应该花时间继续完成它，如果不能，则应该从当前迭代发布计划中剔除，并将待办事项重新放回产品待办列表。

  8 记得重新评估你的故事点

  故事点的统计可以知道当前团队作战的效率，但是前期（尤其是刚开始的几次迭代中）故事点可能预估不准确，后面迭代中参考之前故事点的话就可能有误差。这个时候我们组加了一个小的步骤，就是在下一次迭代任务拆解完成后，再回头看上一次迭代中的故事点是否估算合理（同时可以结合这次实际迭代中的情况），然后重新估算上次迭代的故事点，这时估算出的故事点就近乎接近真实的故事点数了。重新计算出上次迭代中总共完成的故事点数后，这样几次迭代下来，这个值就能大概趋于相等，只要团队的人数不发生大变化，这就相当于当前团队的作战效率了。以后的迭代中就可以按照这个基准，如果某次迭代中估算出来的故事点数大大超出了我们这个预期作战效率，我们就可以考虑剔除当前迭代中一些价值较低的需求，从而趋近这个预期作战效率，让团队处于一种健康的迭代状态。
  

  9 简单总结一下

  这次迭代后的敏捷践行小结中，并没有太多提到3355里面的一些专业术语，但是在我们整个践行过程中，或多或少得到了体现，这也是我们本地化后的产物，从当前版本迭代完成情况来看，各个关键点都达到了预期的目标。从Good & Need to Improve环节中就可以看到，所有团队成员都为”敏捷迭代节奏把控好“投上了一票，说明这次实践算是不错的。但是还是有需要改善的地方，比如“早会进度更新不够高效”，产生这个问题的原因一部分是团队新同学比较多，很多还没有进行过集中的敏捷培训，导致早会中不知道该怎么做，应对这个解决办法我们在总结会中也随即提出抽时间对整个团队进行一次敏捷培训，然后再在每次的迭代中由SM主动引导团队成员。践行敏捷过程中肯定会遇到各种问题，每个团队的具体情况也各有所不用，这个时候就需要有所取舍，在传统开发模式中植入一些敏捷中的一些流程，也不乏是一种很好的践行方式，然后在每次迭代中进行适当调整，最终形成具有团队本地特色的敏捷流程！