Flexagile 弹性敏捷框架

适用

Flexagile是一种弹性敏捷框架，不同于Scrum必须跑迭代Sprint，不同于SAFe适用于100人的大型团队跑多产品线开发，也不同于XP、kanban等适合小团队使用。

Flexagile适用于20~99人的开发团队。如果您的项目是多独立功能需求并行开发，甚至多小产品项目并行运作，我们推荐您使用Flexagile。

优势

确保最高优先级的项目或功能需求优先开发

在业内常见的软件开发过程中，我们时常见到各个功能团队(Feature Team)分别各持一份需求优先级列表。功能团队根据当前的优先级分配好人力资源，对项目而言，项目初期需要投入较多人力，后期功能迭代渐缓对人员配置需求降低。在来不及做人员调整的情况下，产品经理要么为了满足饱和运作让团队迭代一些低优先级的功能，要么减缓团队运作的步伐。
这就是为什么公司不同项目团队，有的累死累活，有的度假休闲~

在Flexagile中，我们把所有的需求放在一起做优先级混合排序，产品需求会被拆分成多个分阶段的小产品需求。

在定期召开的全体计划大会上，每个项目团队如同在一起开每日站会（Daily Stand-up Meeting），团队如同个体，会从ToDo列（统一排序的需求列表）领取最高优先级的下一项需求。以确保团队把精力一致地集中在优先级最高的需求上。

强烈的主人翁意识（Ownership）

任何一个组织至少要由两个人组成，其中一个人负责发出指令，通常把这个发出指令的人称为管理者。在传统模式中管理者相对固定，通常称为管理层，而在Flexagile中，管理者与被管理者之间形成一种动态管理关系，发出指令者可以是业务流程中的任何一个角色，只要这个角色认为有必要，角色与角色之间其实是一种互为管理的关系，传统模式的单向管理线条在Flexagile中变为了双向管理线条。

Flexagile就是把积极性和主动性调动到工作中，让大家自主选择项目和需求，选择团队成员，并对项目进行评估和计划。充分发挥每个人的主观能动性和全局意识观。

消除因项目经理个人判断失误引起的资源浪费

很多公司的项目计划方式是项目经理依据自身的经验，利用甘特图对需求做出估算来调度人力资源。但由于项目经理的自身局限性，如没有技术背景，对开发人员技能不熟悉，对项目技术理解不够深等，易导致项目安排不合理，人力资源出现浪费。

而Flexagile是通过其定义的全体计划大会来优化项目安排的合理度和资源调配的自由度，需求任务根据团队的情况“按需”认领，而不是“分配”。

增强团队成员与公司规划图（Roadmap）的连结

公司的规划通常会随着市场的变化、用户的反馈和内部资源的调整做出相应变更。根据全体计划大会和自身项目计划输出反馈，公司会对规划相应地做出必要调整。

管理者可以及时得到项目的风险状况和变更动态。团队成员也会跳出自身项目局限，从而看到公司战略全貌和相关的高层级项目计划。

跨团队交流

每一个项目团队不再是一个个孤岛(Silos)，而是一汪人员不断交替变化的活水。团队成员在上一个项目进行的过程中有好的实践和经验，将会自然的传递给下一个合作团队。这对构建共同文化和共同学习有很大的帮助和作用。

自主

在Flexagile的敏捷框架体系下，一个项目组会被切分为多个小的功能团队（Feature Team）。每个功能团队负责整个项目的一个小个功能的完整端到端实现（包括前端、后端、数据库，开发、测试、CI、CD）。

Tips: 千万不要用前端团队、后端团队这种方式来割裂不同的组，在一个团队中需要能有需求功能完整交付的所有技能。

自主选择需求

大的项目被切分成多个小的需求功能，由不同的团队独立开发实现。

每个功能团队会在一个全体计划会议上自主地领取自己喜欢或擅长的功能来作为项目开发，这有利于项目代码的共享和消除人员变动对项目的影响，团队自主性大大提升了团队成员的积极性。

当然，如果你的团队在同时并行多个项目，可以把项目当做功能来进行自主选择。

自主组建团队

根据大家选择的目标功能的大小和可并行度来调整功能团队最终的大小和人员构成（一般推荐2~9人，包括各种职能的成员，基础支撑如负责自动化环境的团队成员可以跨团队支撑多个功能团队）。

自主安排计划

团队自主安排计划并不意味着团队可以随心所欲。团队成员在结对进行需求分析后，共同讨论产出项目计划，而不是由项目经理或技术领导拍脑袋给出时间计划。在项目计划过程中，团队成员会识别项目风险并相应调整项目计划。毕竟最了解项目本身的是团队，而不是项目经理。

自主应用敏捷框架

每个功能团队可根据自己团队的人数或项目的性质，来决定各个团队将应用哪套敏捷框架。

• 2人团队，可以选择XP（极限编程），坐在一起结对编程；
• 3~7人团队，可以选择Scrum的周期性迭代；
• 方便部署的web项目，会更期望使用SAFe的发布列车(Release Train)和Facebook的Dark Deploy技术来实现已完成或不完全完成的功能的短频快发布。

实践

Flexagile最重要的环节就是PI Planning（我们内部叫“拍卖会”）。PI Planning源自SAFe框架的全体计划会议，不过在Flexagile中演变得更灵活，更有趣，也更加轻量~（SAFe中定义了一场2天的会议）

PI Planning分两场会议，第一场是有产品经理主导的产品介绍会，第二场则是令人兴奋的项目拍卖会（Pick-up Time）。

产品介绍会（Feature Introduction）

产品介绍会一般一个月召开一次，会议时长半小时到一小时，邀请全员参与。产品经理会在会议上介绍未来两个月我们规划图（Roadmap）上会有什么新的项目。

Flexagile的重点在于把项目分阶段切小，所以Roadmap上的每个项目尽量不超过一个月。如果您所在的团队是多个团队维护一个大项目，应当把项目按照功能（Feature）来拆分成多个小项目。

项目拍卖会（Pick-up Time）

项目拍卖会在产品介绍随后一周内举行，会邀请所有接下来一个月内项目即将结束的团队成员参加，当然产品经理和一些基础支撑部门比如自动化的童鞋也会收到邀请。

1. 待拍品介绍（General Introduction）

首先按项目优先级陈列本次拍卖会的待拍项目，并强调每个项目的期望完成时间(ETA)或Deadline。

接下来询问大家对产品经理之前的介绍是否还有疑问，和询问产品经理对项目有什么补充。

最后由开发团队Leader简单介绍项目的技术方案，可能用到的技术栈等（我们鼓励团队中不同语言的开发人员跨职能争取项目），并给每个项目赋上预设资源配比，如：2 Dev + 1 QA。

2. 拍卖环节（Picking Time）

接下来就像拍卖会一样，按项目优先顺序叫拍。

“下一个是GSuite Add-on项目，我们期望有2位开发同学和1位QA同学，有哪位开发和QA想加入？请举手！”

刷刷刷！！眼力要好，谁先举手，谁中标！

中标后，可以在项目列表上标记上项目预开始时间（ETD）（根据中标人员手头项目最早结束的时间计算），方便接下来的需求排期讨论。

Tips: 必须等一个拍品中标（人选满额），才能进行下一个拍品的拍卖。如果碰到大家都不愿意出手的拍品，那么就请发挥你管理者的权利，宏观调控一把吧~

3. 需求拆分（Team Break-out）

本环节30分钟时间，让所有中标新组的团队聚成多个讨论区，讨论如何拆分需求和项目阶段，如果会议室不够大或担心讨论相互影响，可以预定隔壁会议室让大家享用包间！

如果拿到的项目连产品经理都还没有完整清晰的需求分析，那么请和产品经理一起讨论出需求轮廓，并按拆分好的需求功能、CI、CD任务（测试自动化同学可给予建议）、回归测试阶段等，进行阶段划分和计划排期。

讨论结束后，项目团队派一个代表按顺序向全员展示自己团队的讨论结果。其他团队和技术经理可以给予建议或意见。

4. 计划排期（Plan Refinement）

本环节15分钟的时间，让各团队继续分组讨论，并做出计划。目的是产出：

• 根据经理和其他组的意见调整自己的需求拆分和阶段划分
• 排周计划或迭代(Sprint)计划，并设立里程碑
• 识别出项目风险
• 给出第一个可工作版本（working software）的时间

讨论回来后，同样的，每个项目团队轮流展示自己的讨论结果，并把自己的项目计划摆放到一个统一的计划板上。并标注出第一个可工作版本（working software）的时间节点和其他里程碑的位置。

进行风险卡片展示的时候，描述风险后可以询问是否有谁可以解决或减轻这个风险（如果其他团队有过类似情况，或管理者有更多资源或对接其他部门解决，可以给予帮助）。

最后询问产品经理对每个团队的计划和整体计划是否满意。如果觉得计划有问题，或时间严重超出预期，则宣告失败，进入计划调整环节。

5. 信心度投票（Confidence Vote）

在第二轮每个团队的成果展示后，会进行一次信心度投票，参与项目讨论的团队成员和产品经理，及任何了解项目并期望投票的人都可以在当场比出1~5分的手势✋，如果分数普遍在4分5分，则通过！

若个别低分，可以阐述下低分的理由，来分析是不是有什么没考虑到的隐患。

如果分数普遍偏低，则宣告失败，进入计划调整环节。

6. 计划调整（Plan Adjustment）

若项目排期计划不满足产品经理的需求或团队信心度过低，则尝试以下两种方式调整计划：

1. 增加人手资源，但可能会减缓被抽掉资源的项目进度
2. 产品经理是否可以把需求拆分成两个或多个阶段进行交付

并且需要进行一个跟进会议继续讨论项目计划。

7. 更新产品规划图（Roadmap）

最后根据大家计划的初步结果，更新产品的年度规划图。

开放式回顾会（Open-Spacing Retrospective）

基于Flexagile的敏捷框架，团队会拆分成数个功能团队，并且在进入下一个功能开发的时候，重组新的功能团队。因此，我们在回顾会议上也有新的调整，我们称之为开放式回顾会议。

开放式回顾会议引用开放式空间讨论技术（Open-Spacing Skills），让不同团队之间的实践和问题可以共享，也让大家自由地加入感兴趣的话题参与讨论。

1. 头脑风暴（Brainstorm）

在开放式回顾会中也有PI（Good Practice & Need Improve），回顾会议先让大家各自分别写下关于这两块的内容，每人写不超过3张卡片，计时3分钟时间。

实践分享（Good Practice）

在传统的回顾会议中，大家的讨论重心在值得改进的地方。功能团队的成员流动性大，并且每个团队的流程模式和应用的敏捷框架不一样，我们认为更重要的是让团队相互分享最佳实践，碰到问题的有效解决方案，值得借鉴的理论知识。

改进发现（Need Improve）

这块于传统的回顾会议一样，大家可以用Start, Stop, Keep或是五星图模式(Start, Stop, Keep, More, Less)分类等回顾会议工具。但在Flexagile中，拆分的团队又不断重组，很难像以前一样保留一个很大的改进待办文档（Improvement Backlog），所以我们通常期望把问题讨论的结果总结成可以近期执行的步骤方案，并形成物理看板的卡片在每日站会（Daily Stand-up Meeting）中进行追踪。

2. 相互分享（Present to Each Other）

当大家都列出了自己的卡片之后，可以进行团队分组讨论。使用GROW（Goal, Reality, Options, Way Forward）的方式进行问题分析、场景重现和解决方案选定。

最后，每个团队派一个代表把自己团队的卡片结论展现给大家。好的经验分享可以让大家共同借鉴；分享遇到的问题，可以寻求其他团队对于解决方案的建议。

其他流程

上面介绍了在Flexagile框架中开始的PI Planning的流程及最后的开放式回顾会议，而期间的流程形式及会议，依赖于团队拿到项目后自由选择运用的敏捷框架，可能是Scrum、Kanban或XP等。

文化

我们知道，Scrum敏捷框架有定义其3355（3个角色、3个工件、5个价值观和5个会议），但我们不应该只是套用流程，应同时理解其本意和精髓。

价值

We should constantly seek the way to deliver the maximum customer value in the shortest sustainable lead time while providing the highest possible quality.

—— Lean-Agile Mindset

为了交付更好的产品，我们团队的最重要的三个目标就是

1. 客户价值（Customer-Value）
2. 交付时间（Lead-Time）
3. 质量（Quality）

整个团队应该始终权衡这三个目标以对当前的项目、任务做出合理的优先级判断及调整。

目标共享（Shared Goals/Vision）

围绕上面的三个目标，可以在团队内进行OKR分解到个人目标。并且所有人的个人目标是相互共享的。

再把具有相同或类似目标不同职能的人圈在一起，讨论是否对同一目标能有什么相互的帮助和产出，以促进合作并减少资源浪费。

共同愿景是组织中所有人都重视和认可的愿景。不共享愿景与没有愿景相同，甚至可能会更糟，组织中的成员目标可能与领导层决策发生冲突。共同愿景是一种有利的约束，它限制了组织中人员的行为，使他们在整体目标上保持一致。

当组织中所有人共享愿景和目标时，大家会为同一个目标做出自我调整和配合，这将更有利于团队达到进一步的自治（Autonomy）。

学习型组织（Learning Organization）

π 型人才（π Shap Talent）

如果说现代企业的人才标准是T型人才，“一专多能”型的话，那么在Flexagile敏捷模式下，人才标准则是π型人才，甚至八爪鱼型的“多专多能”。这也是对传统敏捷的跨职能（Cross-Functional）文化的一个补充。

所谓“多专”是指能够胜任不同的专业领域，所谓“多能”是指具有较强的综合能力素质，Flexagile实施的是集成化、系统化的流程管理，只有“多专多能”型人才可以在流程管理中实现一个人扮演不同角色、无缝对接、即插即用，使小团队有效的运行起来，这是Flexagile与传统项目模式中人才的最大区别。

“多专多能”型人才体现出了较强的综合能力素质，这类人才培养绝非单纯的依靠学习能力能够实现，一定要建立在个人“天赋”的基础上。“天赋”即人与生俱来的天然差异，每个人都存在着不同的“天赋”，这些“天赋”能够使人才在某些领域更容易、更快速的获得成功，塑造“多专”，成为“多能”，需要依靠每个人的“天赋”。在美国心理学家麦克利兰提出的能力素质冰山模型中，“天赋”也称为“特质”，属于冰山之下的部分，但是对于获得成功具有重要影响作用。如何能够挖掘人的“天赋”，西方心理学中提供了大量的实用工具。

虽然Flexagile中有大大小小的“圈子“（拆分的功能团队），而且圈圈相链，有了这样的决策框架，依然能够有条不紊的运行，但是这种高度分权的模式，对所有员工提出较高的要求，“多专多能”的π型人才在运用Flexagile的企业中最受欢迎。

知识共享（Knowledge Share）

知识共享有助于培养学习型分享型的企业文化。知识共享不止是团队内部的或者部门内部的，也可以是覆盖全公司范围的。

我们团队在应用Flexagile的过程中，同时会主导并联盟其他部门的团队达成一个知识分享联盟。每个团队内部都会有定期或不定期的技术分享，分享联盟将其扩散到其他团队，乃至整个公司。

当然，也可以组织其他的形式来打造公司的知识共享文化。在RingCentral，我曾推动举办过『讲师星级课』活动，旨在让大家提升汇报演讲的能力，让全体员工都主动分享自己的干货给大家，从而创造了一个全民分享的潮流。

学习社（Communities of Practice）

学习社（Communities of Practice，以下简称CoPs）是在团队中贯穿不同职能部门，不同项目组的一个灵活组织。

在Spotify的敏捷实践中，曾提出了Guild的概念，指在全公司范围内，任何职能部门的同事都可以形成一个Guild，即学习社（CoP）。

每个学习社（CoP）有一个专门的目标或领域，大家定期的分享该领域的知识、工具、方法、实践，致力于在此领域的提升。

在CoP中，任何的成员都是可以随时进入或退出的。并且连CoP也是可以进入消亡状态的。

当一个CoP宣告消亡的时候，我们会庆祝它 开庆功宴，总结并回顾我们学到了什么东西，达成了什么目标。

学习社（CoPs）是一个在公司内打造学习型组织非常好的实践！

结语

Flexagile是RingCentral内部Integration团队针对多项目管理或大型项目多团队管理实践后沉淀的敏捷框架，结合了SAFe、Scrum、KanBan、XP等敏捷方法及Spotify的敏捷实践，在团队内部沉淀的流程方法框架。

通过本文大家对Flexagile团队的文化有了更具体的了解，团队共享价值和目标，并且通过不同形式吸收知识，自我成长。这些对于团队能够使用适合自身的创新型的敏捷实践起到了不容忽视的作用。

如果你对多项目管理方法有什么想咨询，或对Flexagile有什么改进意见，欢迎在评论区留言~

Ё神

RingCentral敏捷教练

不懂技术的产品经理不是好教练！

长按二维码关注