敏捷产品开发模型5个阶段之概念：愿景，战略和策略

敏捷产品开发模型

引言

敏捷开发通常分为五个主要阶段，每个阶段都有其独特的内容和注意事项：
1. 概念阶段：在这个阶段，团队确定项目的愿景和目标。关键活动包括需求收集、用户故事创建和优先级排序。产出主要是产品待办列表PBL。
2. 计划阶段：团队制定详细的项目计划，包括迭代计划和发布计划。关键活动包括确定迭代目标、分配任务和资源。产出主要是迭代计划和任务列表SBL。
3. 设计和开发阶段：团队开始实际的开发工作，设计系统架构并编写代码。关键活动包括编码、单元测试和代码评审。产出主要是可工作的软件增量。
4. 测试阶段：团队对开发的功能进行全面测试，确保软件的质量和稳定性。关键活动包括集成测试、系统测试和用户验收测试。产出主要是通过测试的可工作软件。
5. 部署和维护阶段：团队将软件部署到生产环境，并进行后续的维护和支持。关键活动包括部署、监控和故障排除。产出主要是稳定运行的生产软件。

敏捷产品概念阶段工件：先构建: 产品愿景(Product Vision)，再制定 用户画像(Persona)，编制用户故事(User Story)，绘制用户故事地图(User Story Mapping)，

找到 最小可行产品(MVP)，制定产品待办列表(Product Backlog)。

一、敏捷产品计划：愿景，战略和策略

参考: https://www.javacodegeeks.com/2013/04/agile-product-planning-vision-strategy-and-tactics.html

在敏捷环境中，产品计划与在传统环境中一样重要。 不幸的是，一些产品负责人过于关注产品细节和战术水平，以致于其他计划方面都被忽略了。 但是，如果我们还没有考虑产品策略，那么编写正确的用户案例和创建正确的用户界面设计就很困难。 如果我们对要实现的目标没有愿景，那么选择正确的策略就很困难。

计划层次
敏捷产品计划包括三个级别：愿景，产品战略和战术。 愿景是总体目标，产品策略是实现愿景的途径，
策略是其中的步骤，如下图所示：

随着我们从构想过渡到策略，详细程度会提高：尽管构想通常是由简短的陈述所捕获，但该战略传达了不同的方面，包括目标市场或细分市场，产品价格和渠道以及产品的独特卖点（USP）。 该策略通过使用例如用户故事，设计草图，场景和情节提要等描述产品细节来进一步发展策略，如下图所示：

 

愿景 Vision

产品规划始于创建愿景：指导人们的总体目标。 我自己公司的一个示例愿景是：“在不增加员工人数的情况下发展Pichler Consulting。” 这个愿景听起来可能并不令人兴奋，但对我和我的团队都非常有帮助：它指导了我们的工作并集中了我们的努力。 请注意，示例愿景未提及特定的产品或服务。 而是陈述了业务目标。 产品策略中记录了如何实现目标。

产品战略 Strategy

产品策略是实现愿景的选择途径。 没有战略，就很难对产品细节做出正确的决定：产品应具有的功能，设计和非功能特性。 制定策略还可以防止我迷失在细节上。

我发现捕获目标群体，解决的需求，产品的关键功能以及产品策略中所需的业务收益很有帮助。 但是您可能需要添加产品价格，渠道，主要竞争对手和其他重要的业务模型元素，以更全面地描述您的策略。

由于该战略是实现愿景的途径，因此可能证明是错误的。 创建新产品时尤其如此。 改变策略也被称为支点 。 例如，我发展Pichler Consulting的策略是开发电子学习课程。 如果我发现该课程不太可能成功，则可以更改策略并改写新书。 尽管该策略可能被证明是错误的，但愿景仍应有效。

产品战术 Tactics

产品策略描述了产品详细信息：产品功能，用户交互和用户界面设计。 捕获这些方面的好技术是史诗和现成的故事 ，场景， 设计草图和模型 ， 约束故事和冲刺目标 。 最好以增量方式交付新产品功能，以便我们可以从收集到的反馈中学习。 例如，我使用博客文章来为我的电子学习课程创建材料。 这使我可以从收到的反馈中学习，并验证我的策略和产品详细信息。

 

敏捷产品计划工具：

我更喜欢使用下图所示的敏捷产品计划工具：

对于新产品或创新产品，我采用了产品愿景委员会和业务模型画布 。 前者可以帮助我把握自己的愿景和产品策略的关键要素； 后者帮助我描述了价格和渠道等其他方面。 要捕获细节，我使用Product Canvas 。 画布使我可以处理角色，史诗，场景和情节提要，设计草图和模型，约束故事，冲刺目标和现成的故事。

对于增量产品更新，我喜欢采用面向目标或基于主题的产品路线图 ，以捕获产品策略。 我通常使用传统的产品积压来描述产品详细信息。

总结

创造成功的产品需要的不仅仅是对产品细节的关注。确保你有一个共同的愿景，并选择一个指导你实现愿景的战略。利用早期反馈来验证你是否走在正确的道路上，你的战略是否有效。让产品战略帮助您决定产品的外观和功能。

 

（一）产品愿景(Product Vision)和战略如何构建

明确产品愿景就是明确商业目的，一方面可以帮助团队统一思想，同时也可以确认问题域范围。

产品负责人（product owner），可以利用由 Pichler (2016) 设计的产品愿景板（product vision board）工具来帮助构建产品愿景和战略。
该工具共含有五个栏目：位于上方的栏目（愿景）用于表达产品愿景；位于下方的四个栏目（目标群体、需求、产品、商业目标）则用于描述产品战略

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

　　 

（二）用户画像 (Persona)

 在有了大致的产品愿景之后，第二步就是确认产品的用户画像。 用户画像是一种勾画目标用户、了解用户诉求与设计方向的有效工具。

 

（三）用户故事（user story）

 用户故事（user story）是个用来确定用户和描述用户需求的基本呈现单位。一个好的用户故事包括三个要素：

1.用户角色（Who）：谁要使用这个功能；
2.活动（What）：需要完成什么样的功能；
3.商业价值（Why）：为什么需要这个功能，这个功能带来什么样的价值。

 3C原则

用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

卡片（Card）
用户故事一般写在小的计记事卡片上。卡片上可能会写故事的简短描述，工作量估算等。
交谈（Conversation）
用于在计划或估算时引发关于故事细节的对话。
确认（Confirmation）
将细节以验收测试的方式来确认故事完整性和正确性。

 

INVEST原则

好的用户故事除了格式规范，要素完整外，还应该遵循INVEST原则：Idependent（独立的）、Negotiable（可协商的）、Valuable（有价值的）、Estimatable（可估算的）、Small（小的）、Testable（可测试的）。

 

故事的优先级 MoSCoW法则

摩斯科(MoSCoW)是一种优先级划分的技术，它按照四个优先级划分需求：必须具备（M-Must have）、应该具备（S-Should have）、可以具备（C-Could have）、不会具备（W-Won’t have）｛暂缓(won’t have this time,WHT)、不必(won’t have ever,WHE)｝。

Must Have 必须有的
Should Have 可能有的
Could Have 可以有的
Won’t have 不会有

P.S.：  不会有（Won’t have）, 包括两个子项。这次不会有的(Won’t have this time,WHT) ，永远不会有的(won’t have ever,WHE)。

（四）用户故事地图（User Story Mapping）

用户故事地图（User Story Mapping）是 Jeff Patton 在《用户故事地图》一书中提出的。他所提出的用户故事地图的方法主要用于解决敏捷需求分析过程中的问题。

 

 用户故事地图可以解决以下问题：

1）让你更容易看清backlog的全貌。
2）为新功能筛选（grooming）和划定优先级提供了更好的工具，帮助你做出决策。
3）便于使用静默头脑风暴模式和其它协作方式来产生用户故事。
4）帮助你更好地进行迭代增量开发，同时确保早期发布可以验证整体框架的解决方案。
5）为传统的项目计划提供了一个更好的替代工具。
6）有助于激发讨论和管理项目范围。
7）允许你从多个维度进行项目规划，并确保不同的想法都可以得到采纳。

 

（五）最小可行产品(MVP)

 MVP，Minimum Viable Product，意思是指最小化可行产品，这里面有3个核心词：最小、可行、产品，最开始的解释是指最用快的方式，最少精力完成“开发——测量——认知”的反馈模型，最小化可行产品并非是用于回答产品设计和技术方面的问题，而是以验证基本的商业假设为目标。

1  验证MVP的正确性，通过主要是以下三个方面：

是否定义了市场的主要目标（有没有解决什么场景下的什么问题）；
是否定义了用户的核心行为（用户需要做什么事情，核心行为是什么）；
是否定义了产品的主要功能（产品需要提供哪些相关的功能，优先级是什么）。
当我们做好MVP 版本，也就等于是做好了这个产品全貌的一半。

2  如何保证产品的差异化

而差异化的核心就是找到我们的位置，好的定位能够让我们的产品与具有相同主张的同类产品进行间隔，从而突出我们的产品。

1. 市场定位（选择目标市场）我们要从内部和外部两个角度去探寻我们的产品的市场定位。
内部要充分评估团队现有资源，渠道，能力和产品最有可能满足好哪个细分市场的需求，要做到能够扬长避短，才能资源最大化利用。
外部要评估竞争环境，既要考虑进入该细分市场有无意义，又要考虑团队是否有进入该市场的能力和资源支撑。

2. 用户定位（研究用户群，确定目标用户，完成用户画像）
（1）通过用户研究，把握目标用户的目标，需求，需求结构，需求满足情况，为产品定位选择，品牌定位选择奠定基础。
（2）俩姐产品的适用场景，既包括目标用户是在怎样的时空环境下使用这类产品，也包括去推测该产品能延申到哪些其他场景。
（3）分析产品期望解决的实际业务问题，进行抽象和建模，梳理业务流程，业务层次。

3. 产品定位（输出差异化的产品或服务来竞争）
通过综合分析用户需求，内部资源，竞争环境，确定产品定位
确定产品的硬指标，即产品务必持续追求和改进的特性是哪些，只有将这些特性指标做好才能满足好用户的核心需求。
确定差异化策略，即在产品硬性指标做实的基础上，通过打造特殊的功能特性来体现产品的差异化，从而在用户心中能占有特别的位置。

（六）产品待办列表(Product Backlog)

 

 二、敏捷产品开发模式

参考： https://blog.51cto.com/u_15294888/4981176

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

（1）创意漏斗——无论是ToB产品还是ToC产品，首先都会对众多创意进行过滤，确定高优先级、高价值的产品方向。如果涉及多个业务线，还需要规划在有限的可承担的成本和人力投入下，各业务线业务需求的投入百分比，进行组合管理。
（2）探索分析——利用同理心，站在用户的角度探索用户，挖掘用户的痛点和需求，考虑用户体验，构思解决方案，并对其进行验证。
（3）产品规划——将需求条目化，并从用户角度对条目进行描述（用户故事），按场景组织用户故事，规划最小可行产品（Minimum Viable Product，MVP）及多个迭代的发布计划。
（4）迭代交付——以迭代的方式进行细粒度的迭代规划、开发、验证、用户体验测试，以及按业务需要正式上线。
（5）运营&体验优化——运营推广，监控生产环境的实际运行效果，分析运营数据，根据用户反馈优化用户体验，持续打磨产品。

 

（一）创意漏斗（Idea Funnel）

（1）目的：过滤创意，确定战略方向，进行组合管理；
（2）角色：业务部门利益相关者、业务代表、产品负责人；
（3）时间：进行周期性会议讨论和决策，如每周或每两周一次；
（4）输入：点子、用户需求、运维反馈、运营数据、业务部门战略规划；
（5）处理：
（6）输出：战略主题（Strategy Themes）、产品组合看板（Product Portfolio Kanban）、商业需求文档(Business Requirement Document,BRD)。

                                            图 1：产品组合看板（Product Portfolio Kanban）

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

 

（二）探索分析（Discovery）

（1）目的：价值探索，确保开发有价值的需求，明确长期目标规划；
（2）角色：业务代表、真实用户、产品负责人、开发团队、Scrum Master；
（3）时间：1～2周；
（4）输入：BRD；
（5）处理：1.现场观察（Observation/Shadowing/ContextualInquiry）2.深度访谈（Engagement/Depth Interviews）3.沉浸式体验（Immersion/Becoming the User）
                    4.产品愿景（Product Vision）5.利益相关者地图（Stakeholder Map） 6.价值主张画布（Value Proposition Canvas）7.人物角色（Persona）8.移情图/同理心地图（Empathy Map）
                    9.用户体验地图（User Experience Map）11.快速原型（Rapid Prototyping）
（6）输出：产品愿景（Product Vision）、产品路线图（Product Roadmap）、产品特性清单（FeatureList）。

                                                           图 2：价值主张画布

                                                  图 3：京东ME员工打车价值主张画布

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

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

 

产品路线图/路标 (Product Roadmap) 规划

版本号	V1.25.10	V1.25.20	V1.25.30	V1.25.40	V2.26.10
技术研发计划	文本规范化技术【1】 深度内容识别算法： 非结构数据的(文本)模糊哈希算法【2】 超大规模关健词典扫描算法(词典匹配算法)【3】 多个正则表达式的快速扫描优化算法【4】 结构性数据(在文本中)的匹配算法【5】	产品定义 策略框架和表达范式 系统架构			基于AI的数据分类引擎
产品研发计划	《 敏感数据自查软件(单机版) 》 非结构数据的模糊哈希算法 ---》内容识别引擎 超大规模关健词典扫描算法---》 内容识别引擎 多个正则表达式的快速扫描优化算法---》 内容识别引擎 开发策略引擎	《 DLP 发现 》 《 管理平台 》		《 终端 DLP 》 融资产品原型	网络DLP、云DLP
业务目标 (创建新发布的原因)	软件著作权1个 软件1：《 敏感数据自查软件(单机版) 》 数据安全策略引擎	软件著作权2个 发明专利 >= 4 软件2：《 DLP 发现 》 软件3：《 管理平台 》		软件著作权1个 发明专利 >= 2 软件4：《 终端DLP 》
特性/用户故事 (达成目标所必需的 特性)	【 敏感数据自查软件(单机版) 】  功能： 二个演示用例(Use Case) 100 种文件类型识别 100 种语言的OCR 对象识别（文件识别：类型识别、防伪识别、加密识别、嵌套识别、压缩识别） 敏感数据监控与扫描（敏感信息检测技术： 关键字(字典)、正则表达式(标识符)、文件属性、文档指纹比对） 性能：速度、准确率 外观(UI）： 用户体验(UX):	【 DLP Manager 】 功能： 安全策略集中制定 下发“数据采集、防泄露”策略 事件监控、处置、。 事件审计、分析多维可视化 设备运维 性能：速度、准确率 外观(UI）： 用户体验(UX):  【 DLP Discovery 】 功能： 对敏感数据的监控: 对象识别（文件识别：类型识别、防伪识别、加密识别、嵌套识别、压缩识别） 敏感数据监控与扫描（敏感信息检测技术： 关键字(字典)、正则表达式(标识符)、文件属性、文档指纹比对、机器学习、图像识别(OCR)、文档标签） 与服务端通信， 上报敏感数据泄露事件 性能： 误报率（False Positive Rate）： 检测率（Detection Rate）： 速度、实时性 外观(UI）： 用户体验(UX):	【 终端 DLP 】 功能： 自身保护（进程保护、防卸载、离线告警、身份鉴别、访问控制） 数据监控（文件内容识别、 敏感数据监控与扫描、 终端应用程序运行监控、 剪切板拷贝控制） 泄露防护（外设类拷贝管控、 打印机打印管控、 流量外发管控、 应用外发管控、 屏幕截屏控制、 安全区防护） 外发管理（在线审批、 邮件告警、 截屏留存、 事件记录） 离线管控（屏幕水印、 打印水印、 隐写水印溯源、 离线文档权限控制） 文档加密(可选) 性能： 100M大文件实时识别 漏报率 误报率 离线扫描性能 外观(UI）： 用户体验(UX):	【 DLP Manager 】 功能： 报表功能（告警、日志和合规审计） 历史日志查看分析 通告（邮件、短信） 检索分析(多维度可视化敏感数据分布) 数据备份（） 权限管理（人员账号管理、组织管理、角色管理、终端信息绑定） 性能： 单台服务器管理终端数量 外观(UI）： 用户体验(UX):
人力 (资源支持)		前端1人、UX/UI设计1人、后端（Java 1人、Python 1人）	内核安全 2 人 前端1人、UX/UI设计1人、后端（Java 1人、Python1人）
度量 (决定目标是否达成的度量指标)
时间轴	2025.Q1 2025第一季度	2025.Q2 2025第二季度	2025.Q3 2025第三季度	2025.Q4 2025第四季度	2026.Q4 2026第四季度

 

 

（三）产品规划（Product Planning）

（1）目的：从用户角度对需求条目进行描述（用户故事），明确中期和短期的规划：最小可行产品（MVP）及多个迭代的发布计划；
（2）角色：业务代表、真实用户、产品负责人、开发团队、Scrum Master；
（3）时间：1周以内；
（4）输入：产品愿景、产品路线图、产品特性清单；
（5）处理：DoR和DoD
（6）输出：用户故事（User Story）、用户故事地图（User Story Map）、产品待办列表（Product Backlog）、部分详细用户故事的产品需求文档（Product Requirement Document,PRD）、迭代计划（Sprint Planning）、发布计划（Release Planning）。

P.S.
用户故事,专注于用户价值，包括描述和验收标准，格式如下：
（1）用户故事标题: 用户故事标题是一个动宾词组。
（2）用户故事描述: 作为［用户角色］，我希望/想要［系统提供的功能］，以便/所以［我就能/实现什么业务价值或目标］。
（3）验收标准AC: 假设/假定（Given）上下文、前置条件，当（When）执行某些事件、行动或操作，那么（Then）获得可观察到的结果。
用户故事为业务和技术人员提供了足够的信息来理解意图。通过验收标准（Acceptance Criteria,AC）和验收测试（AcceptanceTest,AT），故事变得更加有价值、更具体，有助于确保做有价值的事，并且高质量地正确交付。
在做计划之前，无论是迭代计划还是发布计划，敏捷团队需要明确迭代开始前用户故事准备好的定义（DoR）及迭代结束后用户故事完成的定义（DoD）

 

 

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

  

 

（四）迭代交付（Iteration Delivery）

（1）目的：
（2）角色：
（3）时间：
（4）输入：
（5）处理：1.原型验证（Prototype Validation）2.产品待办列表梳理会议  3.迭代计划会议（Sprint Planning）4.每日站立会议（Daily Scrum）5.敏捷架构（Agile Architecture）
                    6.持续交付流水线（Continuous Delivery Pipeline）7.用户体验测试（UX Testing）8.迭代评审会议（Sprint Review）9.迭代回顾会议（Sprint Retrospective）
（6）输出：

 

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

（1）目的：
（2）角色：
（3）时间：
（4）输入：
（5）处理：用户体验地图（User Experience Map）、运营监控（Operation Monitor）
（6）输出：

 

 

 

 

 

 

 

附件 A：DevOps标准:研发运营能力一体化(DevOps)能力成熟度模型