23.敏捷优秀实践 - 产品开发流程

敏捷产品开发模式是持续的产品开发模式，不断迭代循环，持续打磨产品，整个循环过程分为五大步骤，如图所示。

（1）创意漏斗——无论是ToB产品还是ToC产品，首先都会对众多创意进行过滤，确定高优先级、高价值的产品方向。如果涉及多个业务线，还需要规划在有限的可承担的成本和人力投入下，各业务线业务需求的投入百分比，进行组合管理。

（2）探索分析——利用同理心，站在用户的角度探索用户，挖掘用户的痛点和需求，考虑用户体验，构思解决方案，并对其进行验证。

（3）产品规划——将需求条目化，并从用户角度对条目进行描述（用户故事），按场景组织用户故事，规划最小可行产品（Minimum Viable Product，MVP）及多个迭代的发布计划。

（4）迭代交付——以迭代的方式进行细粒度的迭代规划、开发、验证、用户体验测试，以及按业务需要正式上线。

（5）运营&体验优化——运营推广，监控生产环境的实际运行效果，分析运营数据，根据用户反馈优化用户体验，持续打磨产品。

一.创意漏斗（Idea Funnel）

（1）目的：过滤创意，确定战略方向，进行组合管理；

（2）角色：业务部门利益相关者、业务代表、产品负责人；

（3）时间：进行周期性会议讨论和决策，如每周或每两周一次；

（4）输入：点子、用户需求、运维反馈、运营数据、业务部门战略规划；

（5）输出：战略主题、产品组合看板、BRD。

1.战略主题（Strategy Themes）

从全局视角来看，在梳理创意、过滤创意的过程中，通常会聚焦产品的战略方向，即战略主题，如财务产品平台化和积木化、移动办公智能化、招聘系统移动化、学习平台SaaS化和移动化等。

这些战略主题区分不同的业务目标，提供业务背景，影响产品组合策略。其决定了在整体业务单元的开发成本投入下，每个产品方向所占的投资比例。同时，它也提供了对产品愿景的洞察力，影响如何将战略主题分解成最小可行产品（MVP），如招聘MVP1——移动端招聘基本流程管理、招聘MVP2——移动端面试、京英MVP1——移动端视频课学习、京英MVP2——移动端PPT学习等。

战略主题通常来源于业务部门的年度战略规划，并随着业务的发展和市场环境的变化不断调整。

而从微观角度来看，日常提出的产品创意需要符合战略主题，而偏离战略主题的创意需要过滤掉，因为战略主题的ROI在确定之初已经表明是高价值、高优先级的。

2.产品组合看板（Product Portfolio Kanban）

在对战略主题进行管理的时候，通常会采用看板的方式对战略主题进行进一步的全局可视化管理，包括战略主题和其对应的MVP状态。产品组合看板示例如图所示。

二.探索分析（Discovery）

（1）目的：价值探索，确保开发有价值的需求；

（2）角色：业务代表、真实用户、产品负责人、开发团队、Scrum Master；

（3）时间：1～2周；

（4）输入：BRD；

（5）输出：产品愿景、产品路线图、产品特性清单（FeatureList）。

1.现场观察（Observation/Shadowing/ContextualInquiry）

参与人员：产品负责人。

观察用户如何与环境交互。捕获用户的引用、行为和其他反映他们经验的笔记。通过观察用户，我们会得到一些新的线索，了解用户的想法和感受，以及他们真正需要什么。

产品负责人不是听参与者说他是如何使用产品的，而是花费数小时、一整天或者更长的时间，进行实际观察，产生丰富、深入和准确的洞察结果，帮助理解参与者的上下文、行为、动机及真实行动，并且对参与者的潜在需要进行深度洞察。

产品负责人通常作为旁观者，假装不在现场来跟随观察，或者主动地交流。

2.深度访谈（Engagement/Depth Interviews）

参与人员：产品负责人、真实用户、业务代表。

直接与用户互动并采访他们，更深入地了解他们的信念和价值观。常常用一个主题来引导，让受访者讲故事，设身处地地说出看法，以便探索受访者潜在的问题、疑问、感知和理解，验证受访者所说的内容及其含义。

建议深度访谈的地点选择用户周围的场所，或者氛围轻松的咖啡馆等地，而不是参与人员的办公区域。

在访谈前，需要提前准备好访谈问题，涉及如下五个方面：

（1）身份——用户的基本身份特征，如姓名、性别、教育程度等；

（2）需求——有关用户的业务活动、业务场景、业务流程、需求和痛点等；

（3）触点——能通过什么方式找到用户，或者用户交互的触达点；

（4）情感——用户的价值观是什么，对业务的偏好是什么；

（5）能力——用户对产品或服务的买单能力、技术能力、业务能力等。

3.沉浸式体验（Immersion/Becoming the User）

参与人员：产品负责人。

参与人员走出办公室，让自己沉浸在用户的体验中，代替办公室里的头脑风暴、猜想和假设分析。参与人员要找到（或在必要时创建）让自己沉浸在特定环境中的方法，获取关于用户体验的一手资料，并发现用户未想过的问题及没有描述清楚的事情。

当参与人员在理论上不能成为用户的时候，需要使用道具模拟用户，例如，穿上老人衣服，并且坐上轮椅来体验老人或者残疾人的生活；穿上工作服模拟工作场景等。

4.产品愿景（Product Vision）

参与人员：产品负责人、业务代表。

愿景能够指明我们要去哪里，以及到达目的地后会是什么情形。产品愿景是产品未来将呈现的情景，是对解决方案未来状态的描述。它反映了客户和利益相关者的需求，以及为满足这些需求而需要实现的功能。愿景描述了市场、客户群和用户需求，它为新功能、非功能性需求（NFR）和其他工作设置了边界和上下文。

愿景可以在产品探索初期简明扼要并重点突出地勾画出产品的范围和差异化价值，可以使得各方能够在短时间内达成共识，并激励所有产品开发人员不断向前迈进。随着探索的深入及后续产品的迭代，可以根据反馈不断更新愿景。

通常采用电梯演讲（Elevator Pitch）的格式描述愿景，具体如下：

为了［目标用户］，他们的［需要和机会］，这个［产品名称］，是一个［产品类型］，它可以［关键优点，使用理由］，而不像［同类竞争者］，我们的产品［差异化声明］。

新京英平台SaaS化的愿景示例如下：

为了不同规模和组织结构的B端员工，他们需要方便快捷地学习职业发展和工作所需的知识和技能，这个新京英SaaS平台，是一个ToB的线上线下一体化学习管理平台，它可以服务大、中、小企业的线上和线下课程管理，而不像云课堂、睿泰、知学云、平安知鸟等，我们的产品支持各种规模层级的企业组织架构和学习顾问及HRBP等的线上和线下学习管理，同时支持移动端、PC端等，能够为B端员工提供更好的用户体验。

5.利益相关者地图（Stakeholder Map）

参与人员：产品负责人、业务代表、开发团队、ScrumMaster、项目经理。

在观察、访谈、体验之后，可以使用利益相关者地图，从全局角度分析和理解涉及的所有利益相关者及他们之间的关系，更好地发现影响其他利益相关者的方式，以便更好地理解业务上下文，达成业务目标。

可以使用便笺条记录角色、姓名、职责、目标、期望、交付物等，如图所示。

资料来源：https://uxdict.io/design-thinking-stakeholder-maps-6a68b0577064。

6.价值主张画布（Value Proposition Canvas）

参与人员：产品负责人、业务代表、开发团队、ScrumMaster、项目经理。

在审视产品要解决的问题的价值时，可以使用价值主张画布强化BRD和愿景，使产品和服务与用户需求相契合，与业务方要创造的价值相统一，降低失败的风险。

资料来源：《价值主张设计》

每一个细分客户群体都有一个对应的价值主张。如图6-7所示为京东ME的员工打车价值主张画布。

7.人物角色（Persona）

参与人员：产品负责人、真实用户、业务代表、开发团队、Scrum Master、项目经理。

用户或业务方提出的需求往往不是用户真正的需求。为了探索用户背后的目的，也就是真正的需要，要利用同理心，走出办公室，对用户或者业务方进行观察、访谈并进行体验，之后将信息带回办公室，对用户进行建模，细分用户，讨论人物角色。

这里的人物角色实际上和价值主张画布的客户细分是一致的，不过人物角色更加细化和明确，更容易从人物角色角度进行移情和同理。

通常在纸上草拟出人物角色，如图所示。

资料来源：《精益设计：设计团队如何改善用户体验第2版》

左上角的格子中是人物角色的画像及其姓名和角色。右上角的格子中是基本的个人信息及行为信息。尽量关注那些预示着特定类型行为的信息，这些行为与我们的产品或服务有关。举例来说，有时人物的年龄与产品完全无关，但他们对特定设备的使用情况（如会不会使用iPhone）将会彻底改变用户使用产品的方式。下半部分是最重要的信息，在这里捕捉人物角色的高阶需求及实现这些需求所遇到的阻碍。切记，用户根本不需要“功能”，他们需要的是达成某种目标（不一定是具体目标，有时也会是情感目标、未曾表达的愿望等）。我们的工作目的是以最佳方式让他们实现这些目标。

京东新京英平台人物角色示例如图所示。

8.移情图/同理心地图（Empathy Map）

参与人员：产品负责人、真实用户、业务代表、开发团队、Scrum Master、项目经理。

根据人物角色，进一步同理用户，所有人基于不同角色、背景、理解、信息、假设等，共同风暴讨论人物角色的所说、所做、所想、所感，如图所示。

新京英平台同理心地图示例如图所示。

9.用户体验地图（User Experience Map）

参与人员：产品负责人、真实用户、业务代表、开发团队、Scrum Master、项目经理。

用户体验地图是一张基于人物角色的第一人称视角的图，用来了解用户与产品、服务、系统交互时的体验和关系，从全局角度定位用户场景、业务流程/旅程、体验的关键点和洞察点，从而识别出待解决的痛点或机会点。这些痛点或机会点的解决方案就构成了产品特性清单（Feature List）。

过程如下：

（1）写出端到端的用户行为流程，分成“觉察、触发、购买、使用、售后……”、“售前、售中、售后”或“服务前、服务中、服务后”等若干关键阶段。

（2）画出情感坐标，中轴线代表正常的行为流程，上方节点代表“惊喜”，下方节点代表“问题”。

（3）用报事贴写下“问题”和“惊喜”，每个报事贴写一个事项，并把“问题”和“惊喜”放到对应的行为节点上。

（4）根据“问题”和“惊喜”的数量和重要性程度，理性判断每个节点的情感高低，并连线。

（5）重构流程，找出任何“不能为用户增加价值”的环节，完全去除或替换。

（6）针对重构后的流程，将最高点推到极致，将最低点有效提升，其他节点一并考虑。

京东优惠券获取用户体验地图如图所示。

资料来源：https://yuzhouguo.com/2016/06/19/mapping-out-the-promotion-shopping-experience/。

10.产品路线图（Product Roadmap）

参与人员：产品负责人、真实用户、业务代表、开发团队、Scrum Master、项目经理。

根据用户体验地图识别的痛点或者机会点，对产品要提供的特性进行初步规划，考虑产品如何以增量和迭代的方式演进。最初这仅是初步的设想和草稿，非常粗略。这个规划需要每隔1～3月根据用户反馈及产品的发展情况持续更新。通常最近的一个里程碑是承诺的，后续的里程碑具有不确定性，代表对未来的预测。

产品路线图的目的是提供产品的持续性，促进利益相关者的协作，帮助与外部利益相关者进行沟通、排优先级，为产品待办列表减负，有助于获得预算和通过立项，支持产品组合管理。这是一个指导性的战略文件，也是一个执行战略的计划。

产品路线图是一个高层次的视觉总结，它提供产品所需的长期视图，包括一系列在计划的时间周期内要交付的内容及相关的里程碑，如图所示。

资料来源：罗曼·皮希勒（Roman Pichler）（https://www.romanpichler.com/tools/product-roadmap/）。

产品路线图示例如图所示。

资料来源：罗曼·皮希勒（Roman Pichler）（https://www.romanpichler.com/blog/working-go-product-roadmap/）

对于多团队协作的解决方案路线图，需要可视化各系统的路线及整体解决方案的里程碑，可以参考如图所示的示意图。

11.快速原型（Rapid Prototyping）

参与人员：产品负责人、业务代表、开发团队、ScrumMaster、项目经理。

“进行原型演练的原因是做试验、创造原型的行动促使你不断问问题并且进行决策。它也给你一些可以展示和讨论的东西……原型仅仅是你的创意的具象化。”

原型演练/快速原型的核心目的是从产品、服务、系统、体验的最终用户那里获取反馈，评估创意和方案。关键点是快速失败、频繁失败、低成本失败，因为越晚失败，成本越高。在开发团队进行软件架构设计和代码编写之前，就可以验证方案的价值和可行性等。原型的特点如下：

（1）万物皆可原型；

（2）原型阅后即焚；

（3）原型点到即止；

（4）原型必须真实；

（5）真实环境测试。

原型可以是纸质原型、木质原型、物理故事板及角色扮演等，如图所示。

使用原型在用户真实环境中进行演练。例如，京东无人餐厅的原型演练，采用的就是角色扮演，团队成员在京东的食堂中扮演打菜员、结算员和就餐员工进行实际演练，如图所示。

打菜员初始化菜品和价格

结算员和就餐员工在结账台结算

三.产品规划（Product Planning）

（1）目的：从用户角度对需求条目进行描述（用户故事），规划最小可行产品（MVP）及多个迭代的发布计划；

（2）角色：业务代表、真实用户、产品负责人、开发团队、Scrum Master；

（3）时间：1周以内；

（4）输入：产品愿景、产品路线图、产品特性清单；

（5）输出：用户故事、产品待办列表、部分详细用户故事的PRD、迭代计划、发布计划。

1.用户故事（User Story）

参与人员：产品负责人。

产品负责人在编写PRD前，负责编写和维护用户故事，因为用户故事是条目化的需求，并不需要像PRD那样花费大量的时间进行详细设计。用户故事从用户的角度对功能进行描述，使用自然语言，而非专业术语。

每个用户故事都是一个小的、独立的行为，可以逐步实施，并为用户或解决方案提供一些价值。它是一个用户与系统交互的垂直纵切的功能片段，可确保每次迭代都能带来新的价值。较大的用户故事被分成较小的故事，可以在一次迭代中完成。

用户故事为业务和技术人员提供了足够的信息来理解意图。通过验收标准（Acceptance Criteria）和验收测试（AcceptanceTest），故事变得更加有价值、更具体，有助于确保做有价值的事，并且高质量地正确交付。

用户故事专注于用户价值，包括描述和验收标准，格式如下：

（1）用户故事标题。

用户故事标题是一个动宾词组。

（2）用户故事描述。

作为［用户角色］，我希望/想要［系统提供的功能］，以便/所以［我就能/实现什么业务价值或目标］。

（3）验收标准。

假设/假定（Given）上下文、前置条件，当（When）执行某些事件、行动或操作，那么（Then）获得可观察到的结果。

用户故事具有3C特征

（1）卡片（Card）——用索引卡/卡片/便笺条记录用户故事，代表用户需求，而不对需求进行详细记录。卡片上同时可记录工作量估算、优先级和验收标准。

（2）对话（Conversation）——敏捷团队通过面对面交流来获得用户故事的细节。好的创意来源于交流，文档代替不了交流，也不能完整、准确地记录所有需求。PRD需要以用户故事为索引，同时其也是用户故事的细节补充文档，如界面原型设计等。

（3）确认（Confirmation）——用验收标准、验收测试用例来确认和记录用户故事开发的完整度和正确性。

用户故事的INVEST原则

（1）独立的（Independent）——用户故事应该尽可能独立。用户故事之间的依赖关系使规划、优先级排序和估算变得更加困难。每个用户故事代表一个对用户有意义的交互。通常来说，可以通过组合或拆分来减少故事之间的依赖性。有的时候，由多个用户故事组成的闭环的业务流程才对用户和企业来说真正有价值。

（2）可讨论的（Negotiable）——用户故事是可以协商讨论的，因为就算是耗费巨大精力详细描述的需求也避免不了误解和需求变更。所有故事的“卡片”只是故事的简短描述、占位符，它不包括细节。细节在“对话”阶段制定，带有太多细节的“卡片”实际上限制了与客户的对话。

（3）有价值的（Valuable）——每个用户故事都必须对客户（用户或购买者）来说有价值。这种价值有可能是有形的，如提现、支付等；也有可能是无形的，如搜索商品、查看商品详情页等。用户故事只要能对用户产生积极作用，触发、推动或者激励用户进一步的旅程，就都是有价值的，值得投入人力来实现。

（4）可估计的（Estimable）——开发人员需要能够估算用户故事的规模，以便对用户故事进行优先级排序和规划。存在的问题：缺乏领域知识（需要更多的对话）、故事太大（需要分解成更小的故事）、需求模糊（需要进一步细化）、技术实现有很大的不确定性（可以分解成一个技术故事探针来进行研究和实验）等。

（5）小的（Small）——好的故事应该很小，规模适合在一个迭代中完成。

（6）可测试的（Testable）——用户故事必须是可测试的，其成功通过测试可以证明开发人员正确地实现了故事，如果不能被测试，就不知道是否有效完成，同时也不能在迭代评审会议中演示完成效果。

用户故事和验收标准示例

原始的产品需求条目如下。

1）需求描述

【离职流程】在人力资源管理系统中抓取是否有福利房的信息，自动推送给行政和人力资源业务伙伴（BP），并提醒员工启动退房流程。行政节点增加“福利房”一项，若员工有有效福利房，则为必填。

2）细节详情

自动推送采用邮件发送的方式；提示员工退房的文案随后提供；行政福利房必填字段是“已退房、未退房”。

优化之后的需求条目如下。

1）用户故事标题

作为办理离职的员工，我希望将福利房交还给公司，以便在很短的时间（如10分钟）内办完离职手续。

2）用户故事描述

【离职流程】在PS中抓取是否有福利房的信息，自动推送给行政和BP，并提醒员工启动退房流程。

行政节点增加“福利房”一项，若员工有有效福利房，则为必填。

自动推送采用邮件发送的方式；提示员工退房的文案随后提供。

行政福利房必填字段是“已退房、未退房”。

3）验收标准

（1）假定员工有福利房，当启动离职流程后，员工自动收到邮件。

（2）假定员工没有福利房，当启动离职流程后，那么员工不会收到邮件。

（3）假定员工有福利房，当员工收到邮件时，那么员工看到邮件里的文案，简单明了，没有异议。

（4）假定行政节点行政福利房字段未选择，当启动离职流程后，那么期望的系统现象是……

（5）假定选择已退房，当启动离职流程后，期望的系统现象是……

（6）假定选择未退房，当启动离职流程后，期望的系统现象是……

这个用户故事和验收标准的示例表达了重点：验收标准强调的是计时用户和测试，有哪些场景、路径、测试要点，通过这些“总结性”的要点，开发人员和测试人员可以更好地理解这个需求，同时在写代码的时候可以有针对性地去写if…else…

2.产品待办列表（Product Backlog）

参与人员：产品负责人。

产品负责人在细化PRD之前，要创建和维护产品待办列表。产品待办列表需要符合DEEP原则。

3.DoR和DoD

参与人员：产品负责人、业务代表、开发团队、ScrumMaster、项目经理。

在做计划之前，无论是迭代计划还是发布计划，敏捷团队需要明确迭代开始前的DoR及迭代结束后的DoD，如图所示。

（1）准备好的定义（DoR）——敏捷团队在进行迭代开发之前需要准备好的定义。DoR可使团队在没有依赖和障碍的前提下，在迭代开始后全力冲刺，高效交付高价值的潜在可发布的产品增量。好的DoR能够使团队事半功倍。

（2）完成的定义（DoD）——在迭代结束的时候，团队已经完成的产品增量或者用户故事。每个团队成员必须对完成工作意味着什么有相同的理解以确保透明化，同时这影响了工作的深入程度及工作量。DoD适用于产品待办列表中的所有用户故事。

针对未来1～2个迭代用户故事DoR的例子

1）需求

● 产品待办列表已经排序；

● 用户故事按三段式描述；

● 验收标准按场景、业务规则、成功路径或失败路径等测试要点编写。

2）交互

● 业务流程图已完成；

● 低保真线框图已完成；

● 场景、业务流程逻辑清晰；

● 视觉设计和切图完成。

3）架构

● 相关的架构已经确定；

● 所需的技术调研、研究、概念验证等已完成；

● 相关业务用户故事所需的架构或框架的代码已完成。

针对一个迭代结束时DoD的例子

1）设计

● 设计评审完成。

2）代码

● 每天下班前必须签入（Check In）当天编写的代码；

● 当天的代码必须在当天或者第2天邀请同伴进行代码评审；

● 代码重构完成；

● 代码符合编码规范；

● 代码已合并团队最新代码并提交至主干；

● 静态代码扫描出的错误已经修复，新增代码扫描出的警告已经修复。

3）文档

● 最终用户文档已更新；

● 最新接口文档已经自动更新到Wiki。

4）测试

● 完成单元测试（Unit Test）；

● 单元测试自动化脚本已经接入持续集成服务器，并且每天至少执行2次；

● 完成集成测试（Integration Test）；

● 无论是前后端的接口，还是与其他系统集成的接口，集成测试自动化脚本已经接入持续集成服务器，并且每天至少执行1次；

● 完成回归测试（Regression Test）；

● 完成平台测试（Platform Test）；

● 完成安全测试（Security Test）；

● 完成性能测试（Performance Test）；

● 完成压力测试（Load Test）；

● 完成用户验收测试（User Acceptance Test）。

5）缺陷

● 零已知缺陷；

● 零线上P0级缺陷（最高级别缺陷）。

6）验收

● 产品负责人已经验收每一个完成的用户故事；

● 产品负责人按照用户旅程验收用户体验。

4.用户故事地图（User Story Map）

参与人员：产品负责人、业务代表、开发团队、ScrumMaster、项目经理。

细节内容，请见前文。

5.发布计划（Release Planning）

参与人员：产品负责人、业务代表、开发团队、ScrumMaster、项目经理。

在进行迭代开发之前，通常进行阶段性中期交付，即发布计划，有所规划，而不仅仅关注未来一个迭代（1～2周）的交付。发布计划会议示意图如图所示。

发布计划会议的目的是制订敏捷团队与组织内的其他部门能够理解和沟通的计划和目标。发布计划会议需要回答以下两个问题：

①我们如何以最佳方式将愿景转化为成功的产品？

②我们怎样才能达到甚至超越客户的满意度和投资回报？

发布计划确定发布目标、具有最高优先级的产品待办事项、重大风险和发布所包含的全部特性和功能。

另外，发布计划会议确立大致交付日期和工作量，团队就可以检验开发进程，并以每个迭代为基础，根据反馈和变化调整并更新发布计划。

因此，在长期规划（产品愿景、产品路线图）的指引下，我们可以应用故事地图规划短期和中期的发布计划。每个版本就是一个最小可行产品（MVP），不是所有版本都正式发布给外部最终用户，MVP的意义在于它是为验证假设而做的最小规模的实验。通常第一版MVP要跑通整个业务流程或主干的基本功能，不保证支持所有用户的所有场景，称为可行走的骨架（Walking Skeleton）。第二版MVP进一步对产品进行完善。第三版MVP进一步丰富打磨。低优先级的用户故事有可能随着产品的不断打磨而被丢弃掉。一个完整的用户故事地图示例如图所示，其分成主干及行走的骨架，每个版本都是阶段性成果，逐步演进，具体细节不用关注。

一个完整的用户故事地图示例

资料来源：改编自SteveRogalsky（http://winnipegagilist.blogspot.com）。

四.迭代交付（Iteration Delivery）

1.原型验证（Prototype Validation）

1．目的

与探索分析中的原型演练基本一致，目的是在与团队梳理Backlog之前，对交互设计进行早期低成本验证，提高用户体验。

2．角色

产品负责人、业务代表、真实用户、开发团队代表、ScrumMaster、项目经理。

3．时间

0.5天以内。

4．输入

线框图。

5．输出

更新优化的线框图。

6．做法

（1）采用纸质原型方法，PO打印线框图；

（2）面对所有参会人员，按照场景、业务流程，PO将线框图粘贴在墙上或白板上；

（3）PO手动模拟屏幕交互，并进行讲解；

（4）记录反馈，更新线框图。

2.产品待办列表梳理会议

1．目的

为下一个迭代计划会议的有效执行做准备。

2．角色

产品负责人、业务代表、开发团队、Scrum Master、项目经理。

3．时间

推荐在每个迭代的中期进行，通常占用敏捷团队5%～10%的工作时间，对于2周迭代，将会花费0.5天～1天的时间。

4．输入

最新的Product Backlog。

5．输出

经过更新的Product Backlog和PRD。

6．做法

（1）对于下个迭代待办事项，PO按优先级描述用户故事及其验收标准；

（2）团队进行澄清确认，并采用计划扑克方式进行相对估算，估算其故事点；

（3）同时，PO根据工作量可以重新更新优先级；

（4）对于团队发现的需求不合理、业务逻辑有漏洞、用户体验不好的待确认用户故事，PO在本次会议后，下一个迭代计划会议之前，和业务方进行最终的确认和设计。

3.迭代计划会议（Sprint Planning）

参见Scrum框架。

4.每日站立会议（Daily Scrum）

参见Scrum框架。

5.敏捷架构（Agile Architecture）

1．目的

对复杂的、风险大的需求进行软件架构设计。

2．角色

开发团队。

3．时间

（1）一部分时间用来为当前迭代的需求进行架构设计；

（2）另一部分时间用来为未来多个迭代提前进行架构设计。

4．输入

产品待办列表、PRD、已有架构。

5．输出

新增架构设计。

6．做法

1）前瞻性刻意架构设计（Intentional Architecture Design）

（1）对于从0到1的新系统或重大重构升级改造等，开发团队需要在前期进行整体的、前瞻性的架构设计并经过架构评审和技术验证。团队需要将非正式设计文档上传到文档工具（如Wiki工具）中。

（2）对已经存在的系统进行增量功能的开发，如果没有重大的技术变革，无须进行前期的架构设计。

（3）对于这些刻意的前期架构设计，在实现的时候，可以将架构切片与业务需求相结合，在编写业务需求代码时，编写其必须依赖的架构切片代码，让架构代码以迭代增量的方式实现。

（4）如果下一个迭代的业务需求依赖于某个前置的架构切片，可以针对该部分进行预研开发。

2）涌现式设计（Emergent Design）

（1）开发团队需要对当前迭代复杂或者有风险的重点功能进行概要设计，并将非正式设计文档上传到文档工具中。

（2）对于涌现出来的设计需要，在设计时，相关开发人员可以在白板前进行模型风暴，设计架构、流程图等。将讨论结果拍照并留存。

（3）不需要为当前迭代的所有需求进行设计。

3）重构（Refactoring）

（1）随着需求的演进，架构也在演进，所以代码的编写需要遵守较好的设计原则，如SOLID原则等，同时也需要对代码进行重构以演进代码。

（2）重构离不开单元测试。

6.持续交付流水线（Continuous Delivery Pipeline）

1．目的

采用自动化的方式来支持快速持续发布可靠的软件。

2．角色

开发团队。

3．时间

在提交代码的时候触发。

4．输入

新提交的代码、持续交付流水线基础设施。

5．输出

自动部署到各种环境（系统测试环境、UAT环境、类生产环境、生产环境），各种反馈（构建、单元测试、静态代码扫描、自动化测试用例结果报告等）。

6．做法

1）持续集成（CI）

（1）每天多次签入代码；

（2）每天至少触发两次CI；

（3）CI包含触发自动化的测试脚本、代码；

（4）CI包含自动部署到系统测试环境、UAT环境、生产环境。

2）持续部署

在CI基础上，自动部署到生产环境。

3）按需发布

（1）根据业务决策，发布给用户使用，代表正式上线；

（2）基于主干开发，在技术上采用特性开关，针对已经部署到生产环境中的软件，打开新增特性的开关；

（3）也可以采用特性分支进行物理隔离，将决定上线的特性分支合并到集成分支或者发布分支中，并将此特性分支删除。

7.用户体验测试（UX Testing）

1．目的

在正式上线之前，进行用户体验测试，提高用户体验。

2．角色

产品负责人、业务代表、真实用户。

3．时间

0.5天～1天。

4．输入

（1）测试任务脚本；

（2）真实用户和设备说明；

（3）可用于用户验收测试的版本。

5．输出

（1）测试记录表；

（2）用户体验优化点。

6．做法

（1）与团队一起确定测试目标和范围；

（2）确定测试任务（用户目标而不是用户界面操作描述）和维度；

（3）确定真实用户和测试环境；

（4）引导真实用户按照测试任务脚本进行测试；

（5）记录测试结果；

（6）确定用户体验优化点。

8.迭代评审会议（Sprint Review）

参见Scrum框架。

9.迭代回顾会议（Sprint Retrospective）

参见Scrum框架。

五.运营＆体验优化（Operation and UXImprovement）

1.用户体验地图（User Experience Map）

1．目的

在产品上线之后，以可视化的方式，讨论用户体验优化点。

2．角色

产品负责人、业务代表、真实用户、开发团队、ScrumMaster、项目经理。

3．时间

在每次上线之后，至少举行一次用户体验地图工作坊，时间为2小时。

4．输入

实际使用产品的体验。

5．输出

用户体验优化点。

6．做法

（1）确定参加的真实用户；

（2）引导真实用户和其他利益相关者参加用户体验地图工作坊；

2.运营监控（Operation Monitor）

1．目的

在产品上线之后，持续监控运营数据，根据反馈优化用户体验。

2．角色

产品负责人、业务代表、开发团队、Scrum Master、项目经理。

3．时间

持续监控，每周或每两周进行周期性总结处理。

4．输入

产品埋点数据、运维反馈数据。埋点工作在产品开发阶段应已经完成。

5．输出

用户体验优化点。

6．做法

1）单周/双周UX问题分析

2）运营数据分析

（1）与用户数相关的数据，如日活、周活、月活等；

（2）与用户价值和体验相关的数据，如用户旅程转化率、常用功能分布等；

（3）与业务价值相关的数据，如交易数据等。