Flexagile 弹性敏捷三部曲之上篇：理论篇
适用性
相信大家在项目运作过程中，一定碰到过多产品线同步开发、多项目并行的场景。我根据在RingCentral的团队运作经验，整理了此篇文章供大家参考、学习交流。
在RingCentral，我所负责的开发团队因致力于各类丰富应用平台的产品集成，团队面临着多产品同步并行的挑战。在实际的开发过程中，曾应用经典的敏捷开发模式，仍然遇到了很多挑战。我和团队经过多种尝试与实践，沉淀出一套方法，并将其命名为Flexagile，是团队一个重要进步的里程碑。
Flexagile不同于Scrum必须跑迭代，不同于SAFe适用于百人的大型团队，也不同于XP、kanban等适合小团队。其适用于多项目，多产品线的并行开发。
优势
确保最高优先级的项目优先开发
在业内常见的软件开发过程中，我们时常见到各个功能团队(Feature Team)分别各持一份需求优先级列表。功能团队根据当前的优先级分配好人力资源，对项目而言，项目初期需要投入较多人力，后期功能迭代渐缓对人员配置需求降低。在来不及做人员调整的情况下，产品经理要么为了满足饱和运作让团队迭代一些低优先级的功能，要么减缓团队运作的步伐。这就是为什么公司不同项目团队，有的累死累活，有的度假休闲。
在Flexagile中，我们把所有的需求放在一起做优先级混合排序，产品需求会被拆分成多个分阶段的小产品需求。在定期召开的全体计划大会上，多个项目团队聚在一起从统一排序的需求优先级列表按照优先级顺序领取需求， 以确保团队把精力一致地集中在优先级最高的需求上。
建立强烈的主人翁意识（Ownership）
任何一个组织至少要由两个人组成，其中一个人负责发出指令，通常把这个发出指令的人称为管理者。在传统模式中管理者相对固定，通常称为管理层，而在Flexagile中，任何团队成员都有机会成为管理者，彼此之间形成一种动态管理关系，传统模式的单向管理在Flexagile中变为了双向管理。
Flexagile就是把积极性和主动性调动到工作中，让大家自主选择项目和需求，选择团队成员，并对项目进行评估和计划。充分发挥每个人的主观能动性和全局意识观。
有效降低因项目经理个人判断失误引起的资源浪费
很多公司的项目计划方式是项目经理依据自身的经验，利用甘特图对需求做出估算来调度人力资源。但由于项目经理的自身局限性，如没有技术背景，对开发人员技能不熟悉，对项目技术理解不够深等，易导致项目安排不合理，人力资源出现浪费。
而Flexagile是通过其定义的全体计划大会来优化项目安排的合理度和资源调配的自由度，需求任务根据团队的情况“按需”认领，而不是“分配”。
增强团队成员与公司规划（Roadmap）的连结
公司的规划通常会随着市场的变化、用户的反馈和内部资源的调整做出相应变更。根据全体计划大会和自身项目计划输出反馈，公司会对规划相应地做出必要调整。
管理者可以及时得到项目的风险状况和变更动态。团队成员也会跳出自身项目局限，从而看到公司战略全貌和相关的高层级项目计划。
促进跨团队交流
每一个项目团队不再是一个个孤岛(Silos)，而是一汪人员不断交替变化的活水。团队成员在上一个项目进行的过程中有好的实践和经验，将会自然地传递给下一个合作团队。这对构建共同文化和共同学习有很大的帮助和作用。
自主
在Flexagile的敏捷框架体系下，一个项目组会被切分为多个功能团队（Feature Team）。每个功能团队负责项目功能完整的端到端实现（包括前端、后端、数据库，开发、测试、CI、CD）。
Tips: 不建议用前端团队、后端团队的方式割裂不同的组，在一个团队中需要有需求功能完整交付的所有技能。
图源：Ethan Huang CST敏捷培训师的CSM培训课程教义
自主选择需求
每个功能团队会在全体计划会议上自主选取相应的功能，这有利于项目代码的共享和消除人员变动对项目的影响，团队自主性大大提升了团队成员的积极性。
当然，如果你的团队在同时并行多个项目，可以把项目当做功能来进行自主选择。
自主组建团队
根据大家选择的目标功能的大小和可并行度来调整功能团队最终的大小和人员构成（一般推荐2~9人，包括各种职能的成员，基础支撑如负责自动化环境的团队成员可以跨团队支撑多个功能团队）。
自主安排计划
团队自主安排计划并不意味着团队可以随心所欲。团队成员在结对进行需求分析后，共同讨论产出项目计划，项目经理或技术经理在计划过程中充分授权。在项目计划过程中，团队成员会识别项目风险并相应调整项目计划。毕竟最了解项目本身的是团队，而不是项目经理。
自主应用敏捷框架
每个功能团队可根据自己团队的人数和项目的性质，决定团队采用与之匹配的敏捷框架。如：
- 2人团队，可以选择XP（极限编程），坐在一起结对编程；
- 3~7人团队，可以选择Scrum的周期性迭代；
- 方便部署的web项目，会更期望使用SAFe的发布列车(Release Train)和Facebook的Dark Deploy技术来实现已完成或不完全完成的功能的短频快发布。
Flexagile 弹性敏捷三部曲之中篇：实践篇
上一篇《理论篇》我们提到了Flexagile适合于什么样的团队和项目，并向大家展示了其优势和特色的弹性部分，本篇我们会详细介绍在RingCentral如何应用Flexagile的流程及相关会议。
Flexagile最重要的环节就是PI Planning（我们内部称之“拍卖会”）。PI Planning源自SAFe框架的全体计划会议，在Flexagile中演变得更灵活，更有趣，也更加轻量。（SAFe中定义了一场2天的会议）
PI Planning分两场会议，第一场是由产品经理主导的产品介绍会，第二场则是令人兴奋的项目拍卖会（Pick-up Time）。
（RingCentral Integration团队某次PI Planning现场）
产品介绍会（Feature Introduction）
产品介绍会一般一个月召开一次，会议时长半小时到一小时，邀请全员参与。产品经理会在会议上介绍未来两个月我们规划图（Roadmap）上会有什么新的项目。
Flexagile的重点在于把项目分阶段切小，所以Roadmap上的每个项目尽量不超过本团队一个月的工作量。如果您所在的团队是多个团队维护一个大项目，应当把项目按照功能（Feature）拆分成多个小项目。
项目拍卖会（Pick-up Time）
为了使团队气氛更加活跃，我们把项目任务分发会议打造成了一个产品拍卖会。项目拍卖会在产品介绍会随后一周内举行，会邀请所有未来一个月内项目即将结束的团队成员参加，产品经理和相关的基础支撑部门比如测试自动化团队成员也会收到邀请。ScrumMaster会主持拍卖现场并保证竞拍的公平性。
1. 待拍品介绍（General Introduction）
首先按项目优先级陈列本次拍卖会的待拍项目，并列出每个项目的期望完成时间(ETA)或Deadline。
ScrumMaster询问参会人员对产品经理之前的介绍是否存在疑问，并询问产品经理对项目是否有补充。
最后由开发团队Leader简要介绍项目的技术方案以及可能用到的技术栈等（我们鼓励团队中不同编程语言的开发人员跨职能领取项目），并为每个项目设定合理的资源配比，如：2 Dev + 1 QA。
2. 拍卖环节（Picking Time）
像拍卖会一样，会议依据项目优先级进行项目成员招募：
“下一个是 XXX 项目，我们期望有2位开发同学和1位QA同学，有哪位开发和QA想加入？请举手！”
注意观察，先举手的团队成员将被选定为项目成员。
中标后，根据中标成员所在当前项目的最早结束时间在项目列表上标记项目预计开始时间（ETD: Estimate Time of Departure），方便后续的需求计划讨论。
Tips: 下一个项目拍卖必须等当前项目中标（人选满额）后方能继续。如果碰到不分先后同时举手的成员，可以让他们各自阐述为什么认为自己比较适合。如果碰到大家都不主动领取的项目，则需要发挥管理者的权利进行宏观调控，直接指派成员。
3. 需求拆分（Requirements Break-out）
本环节预设30分钟，依据项目新组建的团队聚成多个讨论组，讨论需求拆分和项目阶段划分，如果会议室不够大或担心讨论相互影响，可以预定隔壁会议室让大家享用包间！
某些紧急项目，产品经理还未来得及进行完整清晰的需求分析，项目团队将和产品经理一起讨论并进行需求功能以及CI、CI任务的拆分（测试自动化同学可给予建议），回归测试阶段等的具体安排。
讨论结束后，项目团队派一个代表按顺序向全员展示团队的讨论结果，其他团队和技术经理可以给予建议或意见。
4. 项目计划（Plan Refinement）
本环节预设15分钟，各团队基于展示反馈继续分组讨论，并做出具体的计划：
- 根据经理和其他小组的反馈调整自己的需求拆分和阶段划分
- 产出周计划或迭代(Sprint)计划，并设立里程碑
- 识别出项目风险，形成风险卡片
- 提供可工作软件（working software）的最早交付时间
分组讨论结束后，每个项目团队轮流展示自己的讨论结果，并把项目计划张贴在一个统一的计划板上，并标注出最早可工作软件（working software）的交付时间节点和其他里程碑。
风险卡片展示环节，团队代表描述风险并询问与会人员是否有碰到类似的情况及更好的风险应对策略，以便团队可以高效的利用整个团队的资源。
（团队成员展示计划讨论结果，并询问大家的意见）
ScrumMaster将询问产品经理对各团队的计划及整体计划是否满意。如果产品经理认为计划有问题如时间严重超出预期，则宣告失败，进入计划调整环节。
5. 信心度投票（Confidence Vote）
在每个团队的成果展示后，会进行一次针对该团队计划的全员信心度投票，采用1~5分的手势✋投票，如果绝大多数（可以设定一定的百分比例）在4分及以上，则通过！
若出现低分（1-2分），则邀请投票成员阐述理由，分析是否有未预见到的风险。 如果分数普遍偏低（均值低于3分），则宣告失败，进入计划调整环节。
6. 计划调整（Plan Adjustment）
若项目计划不满足产品经理的需求或团队信心度过低，则尝试以下两种方式调整计划并设置一个跟进会议进行后续项目计划调整的讨论：
- 增加人力资源，但可能影响被抽调资源的项目进度
- 产品经理是否可以把需求拆分成两个或多个阶段进行交付
7. 更新产品规划图（Roadmap）
最后根据团队计划的初步结果，得出项目规划图，并以此为依据更新产品年度规划。
（本图仅展示已评估部分）
黄色代表正在运行的项目
蓝色代表拍卖会当天（红线）中标的项目
开放式回顾会（Open-Spacing Retrospective）
基于Flexagile的敏捷框架，团队会拆分成数个功能团队（Feature Team），并且在进入下一个功能开发时重组新的功能团队。因此我们在回顾会议上也随之进行调整，我们称之为开放式回顾会议。
开放式回顾会议应用开放式空间讨论技术（Open-Spacing Skills），使不同团队之间的实践和问题得以共享，而且团队成员可以自由加入感兴趣的话题参与讨论。
1. 头脑风暴（Brainstorm）
在开放式回顾会中也有PI（Good Practice & Need Improve），回顾会议先让大家各自写下关于这两部分的内容，每人不超过3张卡片，计时3分钟。
♥ 最佳实践分享（Good Practice）
在传统的回顾会议中，讨论的重心在需要改进的地方。功能团队的成员流动性大，且每个团队的流程模式和应用的敏捷框架不同，我们认为更重要的是让团队相互分享最佳实践，遇到问题的有效解决方案以及值得借鉴的知识与经验。
♥ 改进优化提升（Need to 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等。
Flexagile 弹性敏捷三部曲之下篇：文化篇
我们知道，Scrum敏捷框架有定义其3355（3个角色、3个工件、5个价值观和5个会议），但我们不应该只是套用流程，应同时理解其本意和精髓。
我们在前两篇《理论篇》和《实践篇》中完整地介绍了Flexagile框架，在本篇中，我们将介绍Flexagile应用过程相关的团队文化建设。
价值
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
为了交付更好的产品，我们团队最重要的三个目标是：
- 客户价值（Customer-Value）
- 交付时间（Lead-Time）
- 质量（Quality）
整个团队应该始终权衡这三个目标以对当前的项目、任务做出合理的优先级判断及调整。
目标共享（Shared Goals/Vision）
围绕上面的三个目标，我们在团队内使用OKR方法进行目标分解会议，将公司及团队目标分解到个人目标，并且所有人的个人目标是透明的。
具有相同或类似目标的不同职能的团队成员聚集在一起，就同一目标是否能通过交流互助产出更优的实现方案，以促进合作并减少资源浪费。
共同愿景是组织中所有人都重视和认可的愿景。不共享愿景与没有愿景相同，甚至可能会更糟，组织中的成员目标可能与领导层决策发生冲突。共同愿景是一种有利的约束，它限制了组织中人员的行为，使他们在整体目标上保持一致。
当组织中所有人共享愿景和目标时，大家会为同一个目标做出自我调整和配合，这将更有利于团队达到进一步的自治（Autonomy）。
学习型组织（Learning Organization）
1. π 型人才（π Shape Talent）
如果说现代企业的人才标准是T型人才，“一专多能”型的话，那么在Flexagile敏捷模式下，人才标准则是π型人才，甚至八爪鱼型的“多专多能”。这也是对传统敏捷的跨职能（Cross-Functional）文化的一个补充。
所谓“多专”是指能够胜任不同的专业领域，所谓“多能”是指具有较强的综合能力素质，Flexagile实施的是集成化、系统化的流程管理，只有“多专多能”型人才可以在流程管理中实现一个人扮演不同角色、无缝对接、即插即用，使小团队有效的运行起来，这是Flexagile与传统项目模式中人才的最大区别。
虽然应用敏捷的过程中有大大小小的“圈子“（拆分的功能团队），而且圈圈相链，在Flexagile的决策框架下，团队依然能够有条不紊的运行，这种高度分权的模式对所有员工提出较高的要求，而具备“多专多能”的π型人才在运用Flexagile的团队中最受欢迎。
2. 知识共享（Knowledge Share）
知识共享有助于培养学习型分享型的企业文化。知识共享不止是团队内部的或者部门内部的，也可以是覆盖全公司范围的。
我们团队在应用Flexagile的过程中，同时会主导并联盟其他部门的团队达成一个知识分享联盟。每个团队内部都会有定期或不定期的技术分享，分享联盟将其扩散到其他团队，乃至整个公司。
当然，也可以组织其他的形式来打造公司的知识共享文化。在RingCentral，我曾推动举办过『讲师星级课』活动，旨在让大家提升汇报演讲的能力，让全体员工都主动分享自己的干货给大家，从而创造了一个全民分享的潮流。
3.学习社（Communities of Practice）
学习社（Communities of Practice，以下简称CoPs）是在团队中贯穿不同职能部门，不同项目组的一个灵活组织。
图片来源：Spotify敏捷实践
纵向是项目团队(Feature Team)
Chapter是职能部门
Guild就是一个学习社
在Spotify的敏捷实践中，曾提出了Guild的概念，指在全公司范围内，任何职能部门的同事都可以形成一个Guild，即学习社（CoP）。
每个学习社（CoP）有一个专门的目标或领域，大家定期的分享该领域的知识、工具、方法、实践，致力于在此领域的提升。
在CoP中，任何成员都可以随时进入或退出，甚至连CoP也可以随时消亡。
图片来源：SAFe官方网站
CoPs的生命周期
当一个CoP宣告消亡时，我们会庆祝它并总结回顾我们学到了什么，达成了什么目标。学习社（CoPs）是一个在公司内打造学习型组织非常好的实践！
结语
Flexagile是RingCentral内部Integration团队针对多项目管理或大型项目多团队管理的一种敏捷实践，结合了SAFe、Scrum、KanBan、XP等敏捷方法及Spotify的敏捷实践，在团队内部沉淀的流程方法框架。
通过本篇大家对Flexagile团队的文化有了更具体的了解，团队共享价值和目标，并且通过不同形式吸收知识，自我成长。这些对于团队能够使用适合自身的创新型的敏捷实践起到了不容忽视的作用。
如果你对多项目管理方法有什么想咨询，或对Flexagile有什么改进意见，欢迎在评论区留言~
本文作者：
Esone邱沼懿
铃盛RingCentral敏捷教练，认证的CSM
网名：Ё神
个人签名：不懂技术的产品经理不是好教练！
