本文主要涵盖的内容如下：

• 敏捷Scrum模式概貌
• Scrum Team的组成与角色分工
• 团队的日常活动

敏捷Scrum模式概貌

开发管理的痛点

• 开发过程的各个环节的明确边际，造成信息传递链条过长，沟通成本以及问题反馈效率低。现行的多数团队，其沟通方式多数是链式传递的，从产品->架构->开发->测试这样一个过程。然后就是每个人都希望做完自己规定的职责后可以当甩手掌柜，最后结果是下游环节在出现问题的时候把责任习惯性推给上游环节。测试不管大局，拼命找开发的所谓的“漏洞”，而开发则去说架构没有设计好，架构则找产品茬说产品啥YY需求。这样最明显的特征就是测试似乎绩效很好，但是产品质量依然一塌糊涂。这里引出一个公司管理的一个很现实的问题，在小团队规模开发模式下，以个人还是以团队的方式考核KPI和事?
• 新技术的引入(微服务、容器化)，不再适应大军团作战，而是需要匹配的灵活的端到端团队。在一个分层比较多的组织里面，最难做到的是管理水平化，往往在团队外增加“保姆式”的组织或监控流程。这样团队除了日常的工作，还要疲于应付那些水平管理所带来的沟通、会议等。这样整个团队都在疲于加班，但是事情依然无法按时完成。
• 客户的需求变化已经不再局限于整体产品购买，而是倾向于业务快速迭代，大军团作战已经难以快速交付、快速变更。如何配合客户的业务变更成为传统大型产品销售型企业最大的挑战。因为一个客户的产品已经难以复制性再交付给下一个客户了。在这样的市场条件下，如何将系统更大程度的拆解与灵活组装考验架构设计能力，也同样考验开发组织形式的变更能力。

敏捷开发不是个新鲜事物，但是随着微服务、容器化等新技术理念的推出，敏捷开发找到了更合适的切合点而已。

什么是Scrum敏捷开发

几个值得思考的问题：

• 团队对于需求范围是否有自主性?
• 开发范围是否是根据时间倒排?
• 是流程管控开发人员，还是人主导流程?

在有市场交付压力的团队中，最容易遇到的问题就是倒排时间。因为交付内容与交付日期已经先确定了，然后当遇到开发瓶颈的时候，第一个想到的就是给团队增加人手。但是别忘了一个经典的说法，一个女人生一个孩子需要9个月，那么9个女人是否可以一个就生出一个孩子呢?答案是显而易见的。另外一个说法就是，如果所有的需求都是高优先级的，那么所有的需求都是低优先级的。

具体什么是Scrum敏捷开发，大家可以参考一下这本书：<<Successding with Agile Software Development with Scrum>>

不过还是跟大家强调一点，流程是死的，人是活动，需要根据团队情况进行变通。

区别

现在已经不流行敏捷开发，而是流程DevOps了。其实可以这样说，不以敏捷开发为基础的DevOps都是耍流氓。

Scrum不是等同DevOps，也不等同与现在更流行的SRE的概念。(具体SRE是什么，大家可以搜索一下)。DevOps和SRE将运维管理引入到开发团队中，将运维情况与开发形成一个闭环，是开发更能有效的考虑实际使用情况。个人理解，其三者的关系如下图：

"scrum vs devops vs sre"

困境

虽然很多时候，大家都觉得敏捷开发， DevOps等理念都很好，但是就是很难去实行，最大的借口就是原来需要做的事情太多。但是这个时候，无论是团队还是管理者，需要停下脚步，做下思考，因为你遇到的情况很可能与下面这个图类似(来自互联网)：

"hard work"

公司形态与Scrum模式

不同的公司业务形态是否Scrum的方式都一样呢?我的理解是核心是相通的，方式是灵活适配的。主要分为两种主要形态：

• 自运营或服务形式提供
• B2B模式的产品开发

自运营/服务模式Scrum流程概貌

参考下图：

"operation mode"

在自运营的场景下，市场人员和产品的策略管理者(SPM)来探讨大的产品方向，然后业务分析师(BSA)做相应的规划，然后各个子产品Owner，俗称Product Owner(PO)根据这些输入制定各自产品的Backlog，然后规划各自产品的迭代。这里引出一个问题，怎么将抽象的需求或者业务需求拆解到各个子产品中呢?一般的做法是顶层有对应的架构师(俗称首席架构师)，他来规划产品的边界，与大的需求的拆分。但是这样的人比较难找，因为他既要懂得业务，还要设计整体体系的架构，还要能分解需求边界等等。如果你遇到这样的人，千万不错过。

在自运营或者以服务的形式向客户提供支持的场景下，每个子产品的PO自行规划迭代范围，自行规划上线时间。不是所有的特性都要完成才能上线。对于跑的快的团队，其实可以将某个需要别的子产品配合的特性的提前上线的，尽管这个特性还没有真正能使用。对于产品关联依赖的特性，则可以通过PO间的Scrum2Scrum协调解决。(后面讲)

B2B的Scrum流程概貌

参考下图：

"b2b mode"

在B2B的产品销售模式下，很难做到各自独立的子产品对客户发布，因为客户需要的是一个Turn Key的交钥匙模式。在这种模式下是否就不可以做到敏捷开发呢?其实也不然。

和前面的自运营模式不同的是，各个子产品不会发布到生产环境中，但是各个子产品依然可以根据自己的节奏做发布。只是需要在特定的时间，将各个子产品的组合起来做一次基线测试和联调，出一个整个产品的基线版本就好。这里需要主要的是，不用拉齐各个产品的版本节奏，而是根据时间点对不同的子产品做版本选择就好。另外集成测试团队只是在需要的时候临时组建，而不是固定的团队。切记，平时这些集成测试的人员应该在各个子产品的团队中。各个子产品间的集成测试应该在功能特性完成时就独立去做了。这个基线测试更像是集成的回归测试。

Scrum 2 Scrum

对于产品比较庞大的系统而言，一个业务流程很可能涉及多个子产品，这样就需要不同的团队的PO/SA一起做协调与沟通了。

"scrum 2 scrum"

通常是Chieft SA召集(平台类产品)或者Businss System Analyst(业务类分析师)召集。Strategy Product Manager和Release Project Manager也会参与进来。这个需要注意的是，要避免团队与团队间的人员交叉协调与沟通，因为这样会导致团队效率极其低下。团队间的沟通最好由PO/SA统一在这个会议上协调。

另外就是，对于阻碍别的团队进展的需求，应该优先解决(不一定是完成整个特性，如提供对应的接口也是一种形式)，避免团队间等待的情况发生。

这个会议更多的是对于需求范围的确定，以及团队间的协调，不讨论具体的方案细节。原理上不同的团队都是接口间的依赖，方案可以由各自团队的SA负责。

对于是否需要对每个团队的方案进行评审和把控，取决与团队情况。因为比较难有几个都对整体系统的每个模块的方案细节都清楚的。当然如果有，则可以成立Change Control Board(CCB)来做专门的架构评审。

Scrum Team的组成与角色分工

对于Scrum团队的组成，一直没有一个很好的定义，人数的多少总是争议的焦点。另外就是当遇到变化的时候，到底是给团队增加人手还是有别的好的方式呢?从实践看，对于一个团队的事情变化，负荷变重后，最好的方式重新成立一个Scrum团队接管新的任务远远比给团队增加人手的方式容易的多。毕竟新人的加入在一段时间并不能给团队产生正向的价值，因为需要沟通融合。保持Scrum团队的稳定性是首要原则。那么什么样的规模的团队比较合适呢?或许和7这个数字比较有缘吧(我家的车牌就有777 -:))，团队的规模在7个人左右的规模比较容易操作，一来沟通的成本比较低，二来无需安排特定的人员做管理类的工作。这样整个团队都会聚焦在具体的事情上。

团队的组成方式：1-1-3-2，如下图：

 

"scrum team"

这里需要注意的是，在这样的规模团队沟通不再是链式的沟通方式，而是有PO和整个团队传递需求，SA和整个团队传递技术。这里没有真正意义的管理者，团队是自管理，高度自治。

PO的职责

• 根据MRD(平台类产品可选)来分析和定义PRD并设计解决方案
• 竞品分析、外部数据收集，自我提出制定产品提升需求
• 并规划产品的Roadmap，制定版本计划
• 选定每个迭代的Scope，对团队内澄清需求
• 组织planning game, 组织产品开发中特性的Demo，组织验收每个版本的交付。组织回顾会议，总结和提升团队能力。
• (平台类)收集业务产品反馈，推动业务对于新特新的使用
• (平台类)运营产品，收集产品运行数据，支撑业务日常使用的方案支持等
• 与架构师配合，规划产品的技术改进

这里需要再此强调的是，PO需要能够控制团队的开发节奏，屏蔽外界对于团队的干扰，同时还要展现团队的核心价值。千万不要做成传声筒的角色。

SA的职责

• 产品的技术实现架构的设计
• 指导开发成员的开发
• 指导测试成员的测试设计
• 驱动测试自动化
• 组织Design Review、Code Review、Test Design Review等
• 与PO配合，规划产品的技术改进
• (平台类)指导业务团队架构师对于产品使用的技术支持

SA是这个团队的技术的代表，需要能代表团队对外做技术的PK的功底。所以和PO的配合很重要，一个代表需求放，一个代表实现方。没有哪方比哪方重要，关键是如何用技术的方式体现业务的更高价值。SA对于开发的技术能力的提升富有不可代替的责任。

Develper的职责

• 产品的技术实现
• 负责子模块的详细设计
• 负责自动化单元测试以及集成测试的开发
• 对产品的技术持续提升提供建议
• 对测试澄清技术细节、协助测试完善测试设计
• 确保代码即时“可见”：Portal展示/Test Case Pass

最为开发，除了完成开发任务外，还需要对于业界的技术特别是开源的技术的敏感度。加入某些开源的项目，提供一些自己的代码将是十分有意义的。如果能有自己的想法，自己创建出自己的开源例子那更加完美。不过国内的开源情况，开源还是背靠公司表容易推进。

Tester的职责

• 产品的测试设计完善测试自动化工具与流程
• 驱动开发的完善与补充开发思考上遗漏
• 负责端到端的系统级测试、性能测试、稳定性测试
• 为开发定位问题提供便利
• 产品的发布执行

对于测试，这里需要多说一些。因为有些互联网公司开始推行无测试的团队。其实并不代表测试已经不重要了，而是互联网的快速变化使得对于测试人员的要求与开发一样高了，而且团队的运作已经没有办法再预留出测试的空档期了。不过这个还是要看团队的情况，如果测试能够从每个迭代就能开始做测试设计，那么测试独立性还是有必要性的。如果团队总是以开发主导，变化总是比较随意(或者叫无法拒绝变化)，或许还是开发自己测试比较合适。

另外就是测试最重要的职责是测试设计，而不是开发的帮手，更不是给开发打杂。测试最重要的价值体现是找到架构、开发上的思维漏洞而不是bug的数量。如果还是用KPI的方式考核测试对于开发的bug的数量，除了助长开发与测试的矛盾，别无益处。

开发与测试的磨合

• 沟通、沟通还是沟通。
• 开发和测试的信息来源将都来自于产品需求，而不是开发是测试的上游
• 测试的定位的转化。
• 在Scrum模式下，开发与测试的工作边界将更加模糊。
• 测试有个最主要的功能是测试点的设计而不是通过复杂的重复性工作来体现测试的价值。
• 测试应该更好的思考如何提供便利的工具。让定位问题和更加方便
• 开发则应该配合测试一起详细review测试点的设计，并从而思考开发中潜在的问题。

团队的日常活动

Planning Game

Planning Game的目的是向团队传递这个迭代的范围，确保团队每个人都有一致的目标。在一个或者两个迭代后要以发布一个版本为结果。那么每个版本都可以用一句话的方式总结出来。如果每个迭代没有一个核心的思想，则迭代范围将比较混乱，团队的工作也容易无序。定出来的范围，需要预先拆解成每个任务项，并且把任务放到gitlab issue中管理，让每次代码提交都能关联起来，便于后续的代码的审核。同时将任务写到字条上贴在自己团队的看板中。看板现在有很多电子版的管理工具，但是不用纠结这个，其实一个真实的看板更管用。(后面会讲我们和电子类的看板的不同)

"planning game"

Planning Game的经验：

• 不要一次性选择多个大的feature在一个版本中
• 选择一些小功能或改进性功能作为风险控制的缓冲
• 预留技术改进的工作项
• 以版本维度作为计划
• 一个版本中以2个开发迭代(4周)为好
• 需要做发布到生产的，预留一周做发布缓存

看板与站会

目前已经有不少电子类的工具提供看板的功能，但是实践中，使用一个真实的看板反而比较容易操作。看板虽然并不复杂，但是也有相应的书，可以参考<<Kanban in Action >>，如下图：

"kanban"

和电子类的看板的区别主要在于：

• 聚焦事与人，而非进度。一般的看板总是将不同的task按照进度进行粘贴，处理人写在字条上。这样容易让人忽略谁正在处理的事情，容易忽略谁的情况是最后交付的风险
• 将事情归类整理，如某个特性相关的事情都粘贴在一起，这样日常容易掌控某个特性是否能够端到端的完成，而不至于同时并行过多的特性开发，导致最后无法端到端完成。这样也容易处理在迭代末尾需要砍任务的时候比较容易

有了看板，那么日常的站会进行将比较容易，不过有些注意点如下：

• 尽可能简短(15min内)，每个人只讲完成情况和遇到的问题，不具体讨论方案
• 需要特意申明需要配合的内容
• 额外增加的内容，需要立即贴出来并由PO判断是否需要做
• 自主领取新的内容，如果有工作依赖或难度的内容，需要TL协调
• 风险需要立即提出
• 尽可能做完一个任务在领下一个任务
• 如果发现任务时间过长，需要做分析和拆解
• 如果觉得任务有难度，开发应该提出要求SA给出设计

Review Meeting

在团队的日常活动中，有各类的Review Meeting，主要目的是团队内信息的有效传递以及贡献团队的智慧。具体操作经验如下：

由各个主题的Owner自主组织，包括：Design Review, Code Review, Test Design Review, Retrospect Review

对于比较大或比较复杂的设计可以分阶段Review: 1/3->1/2->final

Review一定要有最后的完整输出

时间长度一定要控制，1个小时为宜，时间过长应该分多次

End to End Demo

团队PO的要确保对于迭代中交付物的验收，最好的方式就是组织端到端的功能特性的Demo。培养团队有意识的在每次提交代码的时候，都能快速将结果展示出来。

Demo会的一些经验：

• 目前团队对于输出的理解是否一致，是否满足PO的想法
• 不要局限在一定完整测试完，只要能端到端跑完场景即可
• 不要局限一定在版本交付前，而是每个feature为维度，时间可长可短，越早越好
• 不要局限一定要有界面，跑测试代码也是一种Demo
• 不是去挑刺，也不是去测试

同时Demo会也可以邀请一些关键任务参与，如市场人员，树立大家对于产品的信息，以及传达团队对于产品更深刻的理解。

DoD Meeting

DoD: Definition of one。DoD会议主要目的是团队对于一个迭代的输出的总结。团队这个时候可以找个轻松的环境如咖啡厅进行。

"dod"

DoD的一些经验：

- 以迭代为维度作为DoD

- 版本中的第一个迭代的DoD要为下一个迭代做好风险控制，及时调整版本范围

- 不要只关注代码是否已经完成，要同时关注自动化程度、代码质量程度(Jenkins状态， Sonar状态)，文档情况(Doc, Wiki)，测试结果，是否已经CodeReview，是否已经做了代码清理工作(如扫描ToDo)等

Retrospect Meeting

回归会主要团队的自我反省以及自我提供，主要是提供机会给团队成员思考有哪些地方做的好的，哪些需要提高的，哪些地方有遗漏等。

"retrospect"

Retrospect meeting的经验：

• 需要先回顾上一次回顾会的执行情况
• 每项内容每个成员各写3个认为是重点的内容，写在便利贴上
• 不是批斗会也不是拍马屁会
• 需要总结后制定Action Plan
• 尽可能把氛围调整在一个轻松的环境如咖啡屋
• 频率可以是两个版本一次(8-10周)

总结

"summary"

人是活的，流程是死的;没有明文禁止的，都是应该可以改变的

大家不要过于拘束学术上的定义，而是真实根据自己团队的情况进行调整，适应以及高效就是好的流程。也不是说Scrum一定能保证高效，也不是说没有Scrum就不高效，一切取决于人。就像有些大的互联网公司的核心平台团队，每个人的能力和自主性都很强，没有比散养更好的管理方式了。

另外，如果管理者愿意看到团队的自治与效率提升，则切实应该考虑如何更好的去信任团队，去辅助团队自治，而不是在去做“保姆式”管理。

【本文是51CTO专栏作者“VIPDOCKER-了哥 ”的原创文章，如需转载请通过51CTO与作者联系】

戳这里，看该作者更多好文