Flexagile 弹性敏捷 - 实践篇

R/产品介绍会（Feature Introduction）

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

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

R/项目拍卖会（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）

若项目计划不满足产品经理的需求或团队信心度过低，则尝试以下两种方式调整计划并设置一个跟进会议进行后续项目计划调整的讨论：

1. 增加人力资源，但可能影响被抽调资源的项目进度

2. 产品经理是否可以把需求拆分成两个或多个阶段进行交付

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

最后根据团队计划的初步结果，得出项目规划图，并以此为依据更新产品年度规划。

（本图仅展示已评估部分）

黄色代表正在运行的项目

蓝色代表拍卖会当天（红线）中标的项目

R/开放式回顾会（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）的方式进行问题分析、场景重现和解决方案选定。

最后，每个团队派一个代表把自己团队的讨论结果展现给大家。好的经验分享可以让大家共同借鉴；棘手或难以解决的问题的可以共同讨论，以寻求更优的解决方案。

R/其他流程

上面介绍了在 Flexagile 框架中开始的 PI Planning 流程及最后的开放式回顾会议，该框架的灵活之处还在于在每个项目的运作过程中，团队可以根据自身实际情况，自由选择不同的敏捷框架，如 Scrum、Kanban 或 XP 等。

R/待续

在 Flexagile 的体系下，我们不仅提供给大家框架性的流程，而且在实践中我们还总结了其对应的文化实践，更完美地打造你的敏捷团队。在下一期，我们将会推出《Flexagile 弹性敏捷文化篇》，尽请期待！