UEDC-自适应的敏捷学习笔记

一. 敏捷与Scrum起步

1.1 敏捷起源

相比于瀑布模型的“一次把事情做完，统计交付”，敏捷方法是多次把事情做完的一种增量交付过程。敏捷方法有自己的特点。拥抱变化，适应变化但发布周期里一般不接受需求变化。期待变化，对市场需求和市场趋势变化灵活响应。用户的反馈，即能不能为用户带来价值。团队文化和氛围建立使得开发团队更有效率。唯快不破，轻文档且频繁发布。承诺导向，按承诺交付需求。

敏捷方法的基本原理是项目开发中的细节无法完全提前想明白，世界变化太快，价值的高低会不断变化，不确定性太多，用户自己都不知道自己想要什么。因此我们不大可能在一开始就能面面俱到全部想清楚，敏捷方法是一个渐进明晰的过程，保持开放透明，更高效沟通。

敏捷方法工作方式：小块东西，有规律的组装。按需求和功能拆分5-9人小团队，2-4周时间增量交付需求。

1.2 敏捷宣言

互联网项目管理的核心是透明及适应和调整。

敏捷宣言：

1. 个体与交互重于过程和工具
2. 可用的软件重于完备的文档
3. 客户协作重于合同谈判
4. 响应变化重于遵循计划

敏捷方法十二原则：

• 原则一：尽早的，持续的交付有价值的软件来让客户满意
• 原则二：即时到了开发后期，仍然欢迎改变需求，敏捷用变化来为客户创造竞争优势
• 原则三：经常性地交付可以工作的软件，交付的间隔可以从几个星期
  到几个月，交付的时间间隔越短越好
• 原则四：在整个项目开发期间，业务人员和开发人员必须天天都在一
  起工作
• 原则五：围绕被激励起来的个体来构建项目。给他们提供所需的环境
  和支持，并且信任他们能够完成工作
• 原则六：在团队内部，最具有效果并且富有效率的传达信息的方法，
  就是面对面的交谈
• 原则七：工作的软件是首要的进度度量标准
• 原则八：敏捷过程提倡可持续的开发速度。责任人、开发者和用户应
  该能够保持一个长期的、恒定的开发速度
• 原则九：不断地关注优秀的技能和好的设计会增强敏捷能力
• 原则十：简单 —— 使未完成的工作最大化的艺术 —— 是根本的
• 原则十一：最好的构架、需求和设计出自于自组织的团队
• 原则十二：每隔一定时间，团队会在如何才能更有效地工作方面进行反
  省，然后相应地对自己的行为进行调整

1.3 Scrum流程

Scrum流程中有几个重要的角色。首先是产品负责人。TA决定产品的范围/使命/路线图，定义产品功能，接受和拒绝产品，管理Backlog，决定团队方向，排列需求优先级，决定发布日期和验收标准。其次是Scrum Master，TA负责引入Scrum价值观和实践，确保Scrum流程贯彻，帮助，支持，引导团队，而不是管理和控制，帮助提高生产率，为团队排除障碍，协调对外的沟通，保证团队不受干扰。最后是团队，由5-9人全职成员组成。跨职能：开发，测试，UED。团队负责根据需求进行任务拆分和估算。

1.3.1 Sprint计划会

计划会理解需求，决定这次迭代做什么。参与人有团队，Scrum Master，Product Owner。议程：讨论产品Backlog中高优先级项，团队挑选部分为该Sprint目标并做估算（含概要设计）。做任务拆分需要两轮，第一轮分解估算：Epic分解为故事，排列优先级，估算（故事点）；第二轮分解估算：故事分解为任务，理清依赖关系，并估算（理想时间）。

1.3.2 每日站会

10-15分钟时间回答三个问题：昨天干了什么，今天要做什么，遇到什么问题。站会时更新白板：Sprint Backlog，Sprint（TODO，InProgress，Test），DONE。

1.3.3 Sprint评审会

向PO和干系人展示产品，只展示100%完成的部分，收集来自干系人的反馈意见。

1.3.4 回顾会

持续评估，并改进和优化流程，在开放的氛围中解决问题。进行总结：质量，成本，效率，经验，最佳实践。以期在下一次迭代中做的更好。最后完成文档归档工作。

1.4 物件

1.4.1 Product Backlog

Backlog类似传统的系统需求，涵盖整个系统的需求并按优先级排序。PO负责准备和维护，新需求可以任意时间添加进来。每个需求组成部分包含：需求，验收标准（怎样才算做完了以及要注意的细节），估算（故事点），优先级排列（每个Sprint开始时调整优先级，可以是绝对数值）。

1.4.2 Sprint Backlog

是Product Backlog子集，包含一个Sprint要完成的工作，它有效避免导致整个产品推迟或失败的问题出现。Sprint实施的中间阶段一般不能改变，但在有必要的情况下Team可以更改内容

1.4.3 燃尽图

燃尽图有助于预测问题，有助于生产力评价，有助于对个人或总体的任务进行跟踪。

二. 敏捷应用

2.1 第一部分

敏捷宣言可以解读为一种透明化，适应变化，快速反馈，够用即可和团队成员充分信任的流程。而项目管理服务的目的是关注团队的痛点和项目的痛点。做一个团队需要的工作模式，解决痛点，驱动流程和组织的优化

Scrum价值观和基础：

• 诚实
• 开放
• 勇气
• 尊重
• 专注
• 信任
• 授权

2.1.1 Scrum角色

Product Owner负责定义产品的范围/使命/路线图，定义产品功能，接受或拒绝产品，负责产品backlog，排列优先级，每个sprint根据需要调整功能列表和优先级，决定团队的方向（不是团队如何达到目标，也不是团队的工作速度），PO不做任务估算。

Scrum Master负责引入Scrum价值观和实践，确保Scrum流程的贯彻，帮助，支持，引导，而不是管理，控制。帮助提高团队生产率，排除团队的障碍，协调沟通并保护团队不受外部干扰。

互联网开发过程需要产品，交互，视觉，Scrum Team，开发，测试和运维协作完成。

2.1.2 产品需求列表

产品需求列表定义为一系列按优先顺序排列的，预期的产品功能列表。它具有以下属性：

1. 详略得当：渐进明细，文档够用就好
2. 按优先级排序：唯一优先级，从优先级最高的开始开发
3. 估算过：用故事点或者时间
4. 统一的：一个产品多个团队或多个产品多个团队同样适用
5. 够用就好：适合自己的并逐渐演进的
6. 定期梳理

2.1.3 需求描述：用户故事

格式为：作为XXX，我想要XXX，这样我可以XXX。必须满足INVEST原则：

1. 独立的 Independent
2. 可协商 Negotiable
3. 有价值 Valuable
4. 可估算 Estimatable
5. 可测试 Testable

2.1.4 规划估算

要进行估算必须理解两个要素：团队每个迭代的产能和每个需求的估计工作量。可以用故事点或者时间。规划后发现做不完怎么办？可以使用项目铁三角进行评估，然后优先完成20%价值最大的需求。一次上线对应一个版本。

2.2 第二部分

2.2.1 Sprint

Sprint迭代冲刺有几个特点。首先它是以时间盒形式组织的，每个Sprint中的需求强制排定优先级，在整个开发期间展示进度，避免不必要的完美主义，增强可预测性，促进结束。采用尽可能短的迭代，短有很多好处：容易做计划和承诺，反馈和调整的次数多，投入产出比更高，产出的错误更少，更快的恢复和重新开始。但短也有坏处，如果需求拆分的不好，可能会让用户体验变差，开发团队可能需要重复修改，直观上会觉得是一种浪费。在Sprint开发期间，我们要冻结需求来控制变更，开始之后尽可能不允许有任何变更对冲刺产生影响。这就要求我们启动迭代开发之前要澄清需求：需求是否澄清清楚？还是一时没想清楚的冲动？需求的变更还要考虑经济性：变更后会产生什么后果？能不能等到下一个版本？实际开发中完全冻结很难，因此一方面我们要留好时间应对，另一方面需求一定要准备充分。

2.2.2 Daily Scrum

即每日站会。它的作用在于同事间互相的压力，促进团队协作并关注在少数事情上。团队每天在站会上做出承诺，提出阻碍的问题，这也是一种探针：每日站会中出现的问题往往也会出现在日常项目实施过程中。

有时候站会也会出现一些常见问题，比如没什么可说的，其他人说的内容我不关心和时间太长等等。要组织大家都喜欢的每日站会，就要找到团队关心的点，并在合适的时间引入，站会主要回答好3个问题：昨天干了什么，今天想干什么，有什么问题

2.2.3 Sprint Planning

Sprint计划会上主要回答2个问题：接下来Sprint交付的增量中要包含什么内容，以及要如何完成交付增量所需要的工作。计划会还有其他作用，比如仪式感和承诺。计划会中有可能出现团队不承诺或者少承诺的问题，这个时候要相信团队的选择和判断，让团队说明理由，通过这种方法让风险和问题透明。

如果是多团队Sprint计划会议，那么每个团队时间错开，并保持相同的节奏，比如同一天的不同时候。或者多个团队一起开，解决跨团队讨论的问题要立刻找其他团队讨论。

2.2.4 Sprint Review

Sprint总结会的作用是反馈，总结，终结和调整。要看经济性来决定是否需要召开。对于非开发团队的Sprint评审而言，一般需要进行需求评审，交互评审和视觉评审。

2.2.5 Sprint Retrospective

Sprint回顾会的目的是检视前一个Sprint中关于人，关系，过程和工具的情况如何，并找出并加以排序做得好的和潜在需要改进的主要方面，同时制定改进Scrum团队工作方式的计划。如果没人吐槽，场面很平静，那么我们的团队可能需要先建立信任感，建立安全环境；反过来如果吐槽的太多，那么我们需要对事不对人。总结会是对产品的回顾，相关改进措施要放入backlog；回顾会是对团队的回顾。

三. 996是万灵丹吗

3.1 996

996产生的问题比较多，首先是团队效率低下：摸鱼或者周六迟到早退，事情反而做的更慢，也会使得某些同学萌生退意。996产生的原因也很多，比如竞争赶工，攀比，苦肉计等等。不是所有的项目开发都要996，也有一些解法妙方，比如匿名问卷调查，比如破除迷思，比如固定、有限可预期冲刺：每季度最后一个月996或者为了某个短期目标不超过三个月，最后，合理评估人力，加人。

3.2 人总是不够

问题情景：从0开始的项目如何组建团队，项目缺乏负责人，出现人员流失等等。有以下解决方法：提升招聘速度，比如内部推荐，或者通过社招，实习和外包等手段招人。另外团队建设和团队关怀也很重要，有助于提升部门向心力。

3.3 需求总是在变

问题情景：

1. 需求评审完，甚至上线前还在不停加需求，改需求
2. 需求不清楚，不细化，开发到一半要调整
3. 市场运营临时活动
4. 老大或客户的紧急需求
5. 线上bug hotfix打乱节奏

结果就是经常推翻重做，导致心理挫折，或者经常加班加点，团队疲于奔命。且新需求可能带来更多bug。怎样来解决这个问题呢？

3.3.1 需求不够明确

首先如果需求不够明确，那么我们就要对需求与交互评审细化。

3.3.1.1 第一道防线

构筑第一道防线：核心产品组，由项目经理，产品经理和交互设计师等核心人员组成。他们的任务就是定需求，过交互，进行市场调研。

3.3.1.2 严格明确需求与交互评审

需求设计阶段，进行需求评审。可以多次进行。先进行一次小评审，产品组一致通过，没有问题。再进行大评审，全员一致通过，没有问题。参与人员：

1. 策划
2. 交互
3. 视觉
4. 开发
5. 测试
6. 运营等负责人

评审目标是确认需求的优先级，需求的价值，并初判可实现性。评审形式为集中会议，超出团队容量的需求提前砍掉，减少交互工作量。

交互设计阶段，组织交互评审，仍然是先小评审：产品组一致通过，没有问题。然后再大评审：需要确认清楚才能进行全体交互评审。产品，开发，QA一致通过，没有问题即可。

计划阶段，模块负责人依据优先级和工作量做计划并建JIRA。然后进入开发阶段，开发完毕，提测前两天进行联调。提测前两天进行冒烟测试，开发冒烟完成才能提测。测试完成后上预发布版本（上线前两天），最后，进行上线，线上若有重大问题直接回滚。上线回归验证完，上线完成。

3.3.1.3 评审会议管理小技巧

会前：确定是会议评审还是邮件评审，评审材料至少提前一天发出，便于参会人提前了解评审内容，所有关键评审员都要确认可以参加评审会议，开会前收到所有关键评审员的反馈（可选），提前思考，准备问题，能大幅降低会议时间。

会中：按照会议议程有序进行，所有comments用相应工具记录下来方便会后跟踪，保证会议高效，每个议题应控制时间。除主持人，其他人不许带电脑，整个会议最好1小时以内，不要超过2小时。若发现critical或者block级别问题，立即商议是否需要二次评审，不能得过且过，要确保充分讨论完成才能进入下一环节

会后：产品经理根据评审会上接受的建议进行更新。所有会上没有结论的议题，会后有公告，并将更新后的材料发出再次邮件确认，所有关键评审员对更新的材料进行再次审核，没有异议才算完成。执行流程确认后，可以做个简单的checklist帮助辅助确认。

3.3.2 需求频繁变更

若需求频繁变更，那么就需要建立一定的需求变更流程来约束。发起人先跟产品经理讨论，然后确认方案，进行交互稿或交互设计。然后召集各方负责人进行需求讨论。各方确认是否同意变更。如果变更多或者重大，影响工期，则需要邮件群发给开发组周知。如果变更小，JIRA跟踪即可。JIRA依照流程走：交互稿，视觉方案确认，然后交前端或相关开发。

另一种方式是需求冻结，即约定上线窗口，错过窗口要等下一次，这样形成规范让大家有计划提需求。

3.3.3 线上bug处理

线上bug的处理会带来以下问题：会占用开发和测试大量时间，并影响常规版本的开发时间和质量。所有的hotfix统一邮件报QA确认，QA或需求方发现bug建立jira，QA分析并判断是否hotfix，然后相应负责人sign-off。对hotfix设立优先级（P0:立即修复上线，P1:考虑一个周期中集中修复一堆P1bug，打包上线），考虑bug的影响范围评估严重程度。确认要hotfix的bug后，QA建立hotfix的jira记录，注意每次解决的问题单独建jira。一定要培养好clean hotfix的好习惯。尽可能少改动代码，只包含引起hotfix的一次改动，不可夹带私货，不能修复其他无关bug。如果一次hotfix要改动的代码很多，考虑做成小版本的形式，留足充分的测试时间，QA设计冒烟测试用例，开发冒烟通过后提测。hotfix来自客户报的bug，要避免引入新功能从线上分支拉入hotfix分支，然后开发，自测，然后提测。模块负责人做code review，进行bug原因分析，修复影响分析并分析漏测原因。测试通过后开发负责人发上线邮件，上线完成，线上验证。最后针对此bug周会上做总结。

3.4 如何提升产品质量

问题情景：产品质量不好，bug多。开发觉得测试是测试团队的工作。接近上线甚至上线后，才发现和需求落差大。

对此有两种解决方案。一是产品走查，由产品经理，交互和视觉在提测后，上线前进行检查：实际产品与设计稿是否有差异？是否有需求设计不合理之处？并提出：bug，需求变更或新需求。二是Bug Bash，最好在QA第二轮测试结束通过后，由产品策划，交互，视觉走查，进行Bug大扫除。

四. 实战案例：网易大数据

4.1 内部创业：从0到1

从产品背景看，网易项目有3种。技术型项目较为纯粹，团队成员主要是开发和QA。To C产品则包含产品，设计，开发，QA，市场，运营和客服等角色。To B产品则包含产品，设计，开发，QA，市场，销售，售前，售后，实施和客服。

项目管理使命就是帮助整个团队流程，沟通，协作等优化，帮助各专业角色推进相关工作，一起完成目标，专注于项目最重要的东西：团队KPI达成（产品交付，销售成果），帮助产品业务成功。项目管理有三大体系：业务全链路项目管理，教练和网易项目管理体系。

4.1.1 企业级产品业务全链路项目管理

4.1.1.1 战略管理

可以考虑设计冲刺，快速完成MVP来验证需求。战略管理一版包含如下环节：

• 市场调研
• 战略分析
• 商业模式设计
• 战略与目标选择
• 战略与目标执行

4.1.1.2 产品设计

要进行用户研究和市场研究。后者包含产品需求，市场运营需求和销售需求。市场研究会形成需求池，然后对需求池中的需求排好优先级。进行需求评审，交互设计和交互评审。两条线：视觉设计-视觉评审，技术方案设计-技术评审。产品设计最后还包含竞品调研和产品宣传。

4.1.1.3 研发

包含迭代计划会，开发（Bug的hotfix流程），冒烟，提测，测试，预发，上线和需求验证。

4.1.1.4 运营

包含客户支持，内容运营，客户运营（用户留存/增长，需求挖掘），现在还有更进一步的基于数据分析的精细运营，这种产品运营需要执行以下几个步骤：

1. 确认目标
2. 确认指标
3. 数据规划
4. 数据准备（埋点）
5. 数据整理
6. 报表制作
7. 日常监控（验证需求）
8. 挖掘问题
9. 决策

4.1.1.5 市场

包含：

1. SEM
2. 广告/公关：文稿策划，媒体管理
3. 市场活动
4. 商务合作：政府协会，客户合作，合作伙伴（挑选合作伙伴，讨论合作模式，确定合作框架，签订合作战略合同，合作质量考核），渠道，品牌（品牌定位，品牌设计与包装，品牌宣传），线上运营（新媒体，流量）

4.1.1.6 销售

• 销售线索
  1. 商机挖掘（电话，拜访）
  2. 售前需求确认
  3. 解决方案设计
  4. 方案评估（需求评估，外包评估，采购评估）
  5. poc测试/试用（实施部署/试用流程）
  6. 商务谈判（方案确认报价）
  7. 项目投标选型（投标策略，标书，投标分析）
• 销售支持
  1. 销售工具包
  2. CRM
  3. 合同管理
• 实施售后

4.1.1.7 人力资源

人力资源组织架构：

1. 招聘

• 需求梳理
• JD撰写
• 发布渠道
• 面试
• 入职

2. 培育

• 学习环境打造
• 培训

3. 任职管理

• 晋升
• 岗位安排

4. 激励

• 福利
• 加薪

4.1.2 项目管理可以做什么

把团队当成一家小公司，把全局盘点清楚。深入盘点各环节，各项目组织间可以互相学习，沉淀。初创产品可了解商业化完整版图，盘点自己缺了什么。明确各环节与各角色的协作流，有助于大家团队合作，不断优化，提升。

4.2 以网易大数据为例

传统企业数据现状痛点是企业包含了很多环节，每个环节都会产生数据，但却无法将这些数据融合起来产生价值：

1. 供应链：供应链数据
2. 生产：生产数据
3. 仓储：仓储数据
4. 物流：生产数据
5. 通路：通路数据
6. 销售：销售数据

4.2.1 大数据团队背景

团队的目标是内部平台产品化与对外商业化，提供中大型传统企业大数据解决方案。网易大数据包含猛犸大数据平台和有数敏捷分析平台。猛犸大数据平台为稳定的一站式数据开发平台，覆盖数据传输，计算及作业流调度。有数敏捷分析平台是敏捷的BI数据分析平台，可创建交互式可视化报表和仪表盘，有强大的定制和扩展能力，满足个性化需求。网易还具有海量数据资产，深度加工网易19年积累的互联网大数据，提供企业智能决策解决方案。

实践经验：

1. 重要性与方向
2. 多部门协作
3. 销售业务开展
4. 产品打磨
5. 缺人与资源

4.3 业务打磨

4.3.1 目标（战略）管理

团队需要解决的问题包括：

1. 对外产品形态
2. 销售与市场策略，组织结构，
3. 老大，产品，团队技术出身，不知道如何推动业务
4. 不知道方向为何？

改进方法：

1. 引入专家
2. 主管周会，产品周会，产品站会，业务站会，月会
3. 核心成员凝聚在一起，达成共识，信息互通

流程：

1. 明确目标
2. 市场研究
3. 设计商业模式
4. 执行
5. 反馈

4.3.2 搭班子，组班委

首先进行需求梳理，人力盘点，组织架构设计，做到适才试用，建立各级管理层，给予现有成员发挥的空间。其次是招到靠谱，比自己优秀的人，除了技术，也要考虑管理与综合能力。

4.3.3 设计冲刺之需求管理

困难在于方向不可能一下子想清楚，而产品需要证明市场价值。对此采用小步迭代方式创建MVP，小迭代2-3周，快速验证需求。不一定完全实现，可以原型，仿真，包装，美观。让老大快速取得信心，争取资源。这么做的优点是时间短，只做对客户最有价值部分，反而想的清楚。快速取得反馈给老大和客户。团队容易进入奋斗模式。

4.3.4 业务驱动测试

这块的问题是测开比太低，产品质量无法保证。这块的改进方法主要有产品组走查+bug bash，超管全回归（预发布系统），人工看报表，然后过渡到日志排查系统，再过渡到自动化。业务倒逼，真实场景。

4.3.5 推动业务

1. 不断深入思考：没有成绩单-销售线索不足-如何提升转化找到精准需求
2. 一步步优化试错：展会-协会-SEM-电销

4.4 流程建立与管理

项目的痛点在于多版本并行且延期严重。对此我们的应对方式是缩短迭代周期，逐步改进。一次做好一件事，把时间周期明确下来，大幅缩短交付时间，最后从2周开发，2周测试改进到8天开发，7天测试。实施全流程JIRA管理，包括版本时间计划，需求管理，任务拆解，迭代计划，日常监控，产品走查，测试，预发走查，上线走查。全面使用JIRA收集过程数据。每个版本分解为story（需求）并进一步分解为task（任务）。用仪表盘管理需求，监控进度，执行流程。每日发JIRA日报，精准知道各种维度的数据统计，每个人任务数量。

4.5 创造合作氛围

进行部门融合。建立大群，文档库，知识分享学习。各种公司活动一起协作，创造合作氛围。打造品牌：网易大数据和数据科学中心。安排好座位：老大在中心并向外扩散。

业务成就：

1. 半年时间内从虚拟合作组织到形成数据科学中心
2. 明确中大型客户大数据解决方案
3. 完成业务团队组建，产品核心人物的丰满
4. 半年内拿下标杆客户，跑通全链路项目管理，验证商业模式

4.5.1 企业级内部创业心得总结

1. 战略讨论：对的方向和对的需求
2. 管理者要把整个团队，环节，流程理清，才能更好推动工作
3. 找比自己更聪明专业的人，完善团队构建
4. 遇到问题，深入思考，细化分析每个环节，逐步优化战略，产品和业务
5. 打造创业公司精神：紧迫感和快速试错
6. 业务市场敏锐度，大局观
7. 好玩最重要

五. 实战案例：网易云音乐

5.1 业务快速发展下的项目管理变革

这是一款音乐app，业务包含音乐，电台，视频和商城四大部分。特点是个性推荐，歌单，有趣的评论和极致的用户体验。然而团队在初创时也遇到过问题，例如需求无法完整交付，复杂的沟通和团队信任危机。这就分别需要任务管理流程调整，重新定义团队和增强团队信任来一一应对。

5.2 任务管理流程调整

变革前现状是以职能组为单位划分，团队规模变大后遇到很多问题：

1. 联调阶段发现任务遗漏
2. 需求方很委屈
3. 团队冲突增强
4. 强化了职能墙

仔细分析后发现，原来团队小，职能负责人还能把关所有需求。职能角色少，复杂度不高，直接由策划创建任务可行，一定程度上高效。后来为何玩不转？是因为团队变大，职能内部多了小组细分，人数翻番，且分工细化，职能角色增多，任务涉及的角色增多。

解决思路：

1. 以终为始：所有人都关注需求而非任务
2. 解放策划：找更适合的人做任务拆解
3. 引入团队参与：提高大家参与感，改变辐射状管理模式

如何引发改变：

1. 观察和记录问题
2. 与关键干系人沟通
3. 提供解决方案

变革后，项目版本由项目经理创建，由版本负责人负责。需求由策划创建，需求技术负责人负责。子任务由需求技术负责人创建，由开发负责。

如果有人不买账怎么办？这时首先要取得技术总监和职能组长关键干系人认可。然后团结支持者，取得产品团队支持，初期选取支持者做尝试，并为摇摆者解决困惑，具体定义需求技术负责人的职责。最后包围顽固者。

带来的变化：

1. 任务遗漏情况减少
2. 弱化职能墙，为组建虚拟团队提供基础
3. 提高团队的项目管理意识和能力

5.3 重新定义团队

团队应该跨职能，有完整交付需求的能力。组建业务团队相对独立，可以简化跨组沟通。团队需要相对稳定长期存在，就要考虑业务的稳定性。团队划分时应该要综合考虑组织对人员动态调配能力以及团队的独立性。

变革后组建了跨职能虚拟业务团队，建立了包含客户端，交互，视觉和算法的公共资源池。重新定义计划方式，前后端两周迭代，所有组的迭代周期对齐，客户端版本手动对齐。

开展计划会，会前进行需求和交互评审，定义优先级，开发评估工作量。会中简单陈述需求，确定需求优先级，排定需求发布安排，包括提测点，发布点和版本。会后梳理需求和版本，分解任务，确认排期。