软件工程一课一得

第一单元

1.如何使用CodePen

CodePen是一个在线的代码编辑器，允许用户创建、编辑和分享前端代码。以下是使用CodePen的一些基本教程和技巧：

1. 创建和编辑代码：

   • 打开CodePen官网（https://codepen.io/），使用GitHub、Twitter或Facebook账号登录。
   • 选择“pen”来创建一个新的演示代码，可以添加HTML、CSS和JavaScript代码。
   • 添加完代码后，记得保存，并可以修改项目名。
   • 若要创建特定框架（如Vue或Flutter）的项目，可以在pen选项的下拉菜单中选择。
     

2. 分享代码：

   • 创建好pen后，直接复制当前标签页的URL即可分享，其他人点击URL即可跳转到项目。
     

3. 插入图片：

   • 将图片转为base64编码，然后替换图片的src属性值。
     

4. 创建模板：

   • 选择“pen”右侧的下拉按钮，然后选择“From Template”来新建一个模板。
   • 在“setting”中设置自动保存、实时预览、自动格式化代码等选项。
   • 在“Editor”中设置代码缩进。
   • 最后在“Template”中开启模板。

5. 编辑技巧：

   • 使用“运行”按钮来更新代码的输出，而不是自动更新的预览方式。
   • 使用Ctrl/Cmd和向上/向下箭头的组合键来增加或减少代码中的数字。
   • 将光标放在源代码中的多个点上，同时键入或编辑相同的信息，以减少复制粘贴的需要。
   • CodePen有自己的控制台，可以快速检查控制台消息而无需打开浏览器的控制台。

6. 导出代码：

   • 保存后，可以将笔（单个CodePen实体）导出为ZIP文件，其所有内容均以HTML、CSS和JS代码存储在文件中。

7. 搜索和分享：

   • 使用搜索功能查找特定的代码样例或组件。
   • 通过分享按钮将代码链接到Markdown文本中，或嵌入到其他网站。

通过这些基本教程和技巧，你可以充分利用CodePen的功能，无论是构建、测试还是发现前端代码的最佳场所。

第二单元

1.产品愿景

        

什么是产品愿景

简单来说，产品愿景是产品的核心竞争力，是产品的特色，是产品和其他竞品的不同之处。

产品愿景是在特定场景下为特定的人群提供的独一无二的特定服务。

一般来说，产品愿景应该是稳定的，但它也会随着时间的推移而做出调整。

如何描述产品愿景

电梯演讲（Elevator Pitch）是一个非常好的描述产品愿景的工具或手段，它可以在很短时间内，将产品愿景清晰地表达出来，其格式如下。

为了【目标客户】，

他们的【需要和机会】，

这个【产品名称】

是一个【产品类型】，

它可以【关键优点和使用理由】，

而不像【同类竞争者】，

我们产品的【差异化声明】。

第三单元

1.产品定义和用户场景

产品定义：

软件产品的定义：软件是一种逻辑产品，不是客观的实体，具有无形性，它是脑力劳动的结晶，它以程序和文档的形式保存在计算机存储器的磁盘和光盘介质上，通过操作计算机才能体现出它的功能和作用。

软件产品的构成：包装、源程序、相关文档（安装部署说明、帮助文档、用户手册）

软件开发过程中产生的文档
需求分析阶段：可行性研究报告、项目开发计划、软件需求说明、用户需求说明 需求分析工程师 产品部
设计阶段：概要设计说明书、详细设计说明书、数据库设计说明书 研发部
测试阶段：测试计划、测试方案、测试用例、测试报告 测试部（300人左右的软件公司测试人员15个左右，60-70个开发人员）
总结阶段：项目总结
用户阶段：安装手册、用户手册

公司组织架构：
人力资源、财务、行政、市场部、产品部、开发部、测试部、项目管理部（配置管理员、）、工程部（也叫实施、部署部、售后部，人数较多）

用户场景：

做产品经理的同学，都知道产品要瞄准对应的用户，不同用户在场景下有不同的需求，核心是场景的解释。

场景的概念比较难描述，有时感觉就是捉摸不透的词汇，是某个条件，或者某个环境，还是其他方式。

如果场景结合用户去看，或许就能清晰许多，先划分用户再看具体场景。

以用餐为例，不同用户涉及的用餐需求就有不同，用户即涉及到所谓的分层产品。

如果以自身情况出发，可以将用餐分为朋友聚餐、情侣聚餐、家庭聚餐、异地用餐等场景，可以先对比前两种情况下的需求差异。

聚餐自然涉及到用餐的完整流程，从”选店、用餐、结束“三个流程来具体说明。

朋友聚餐就是熟悉的朋友一起聚会，以我为例，一般而言，选店有两种方式：

一种就是平时收藏或者熟悉的店，因为人数有时比较多，你可能会提前预订包厢。

另一种就是查看聚会目的地附近的店铺，看品类，比如火锅、正餐等，再看评分，比如通过榜单看具体排名，通过这样的方式来选择店铺。

朋友聚餐因为都是自己熟悉的朋友或者同事，相对而言，对环境的苛求并不大，只要菜品好吃就行。

用餐是正常情况，支付时如果有代金券就买代金券，如果没有，用支付宝或微信等支付。

结束后，有时会有下一站，比如看电影、在商场逛一逛等，但这样的概率并不大。

如果是情侣聚餐的话，选店原则上你会提前选好，要求环境好、品质高等店铺，而且你会提前预订桌台。

你应该不会贸然选择一家不太熟悉的店铺，因为过去后发现如果环境、氛围等不合适，就浪费彼此的信任，尤其对未确定关系的情侣。

用餐跟朋友聚餐会有差异，有些你可能不太会买代金券或团购券，可能就是直接支付走人，毕竟优惠有时看起来似乎会略微掉价。

结束后一般会有下一站，比如看电影、逛个密室等，正常的娱乐安排会有。

上面两个不同的用户群体，虽然面对同样的用餐场景，但因为自身需求有差异，导致用餐流程的选择就有不同。

场景是需要回归到具体用户，考虑到用户当时所在的条件，不同条件下用户的选择就有不同，用户反而是最为核心的前提。

再举个例子，之前在上家公司的时候，做了一款硬件智能点餐POS，希望能做到”点餐+广告+充电“三位一体的方案，尤其后面两者，实现1+1大于2的效果。

第四单元

1.用户故事：

用户故事（user story）是从用户的角度来描述用户渴望得到的功能。

用户故事是指在软件开发和项目管理中，用日常语言或商务用语写成的句子，这个句子反应了一个用户在其工作职责范围内要达到的某个目的，以及此目的所需要的功能。

用户故事三要素

一个好的用户故事包括如下三个要素：

1. 角色，指谁要使用这个功能。
2. 活动，指需要完成什么样的功能或目标。
3. 商业价值，指为什么需要这个功能，这个功能带来什么样的价值。

第五单元

1.软件功能设计：

 功能的概要设计，是功能设计三步骤的第一步，它是对功能层的整体规划和设计。功能的概要设计是依据业务架构，对需求工程中收集到的功能需求一览进行确定、分类、规划等的工作，最终将功能需求一览转换为业务功能一览，它是后续各个设计阶段的判断设计内容、工作量等的依据。

    1．定义

        功能的概要设计，是对需求工程收集到的功能需求一览进行进一步的梳理，确定真实的功能，并对“业务功能”进行分类（活动、字典、看板和表单），最终形成业务功能一览，它奠定了后续功能设计与开发的基础。“功能”与“业务功能”已经多次出现了，那什么是功能和业务功能呢？

        （1）功能：完成同一目标的操作方法、数据结构、管理规则形成的模块就是功能。

        （2）业务功能：完成某个具体的业务目标的功能就是业务功能，如合同签订、计划编制。

        2．作用

        从软件工程上功能的全过程看，这是对需求工程收集到的需求按照功能设计标准进行的第一次设计，也是从需求工程进入到设计工程的转换点，它的作用是将需求阶段的成果用设计的标准进行梳理、分类、规划、汇总，为后面的详细设计奠定基础。功能的概要设计是粗线条的，重点是将尚未完全确定的“功能需求”确定为正式的“业务功能”。

        （1）需求分析：对需求资料进行分析，确定了必须提供的功能需求一览／需求4件套。

        （2）概要设计：对功能需求进行规划、分类等，最终确定系统要实现的业务功能一览。

        （3）详细设计：对已确定功能进行定义，给出满足业务处理的业务原型（业务4件套）。

        （4）应用设计：加入系统功能描述，给出满足客户体验的应用原型（组件4件套）。

第六单元

1.软件架构基础：

1、基本概念

本质：软件架构为软件系统提供了一个 结构、行为和属性的高级抽象

是特定领域的惯用模式，架构定义了一个词汇表和一组约束

作用：

1、软件架构是项目干系人进行交流的手段

2、软件架构是可传递和可复用的模型，通过研究软件架构可以预测软件的质量

3、软件架构使推理和控制的更改 更加简单，有主意循序渐进的原型设计，可以作为培训的基础

架构 = 软件体系结构，填平了需求分析和软件设计的鸿沟

架构设计就是需求分配，将满足需求的职责分配到组件上

2、架构发展历程

无架构阶段（汇编语言阶段）

萌芽阶段（程序架构设计）

初级阶段（统一建模语言UML）

高级阶段（4+1视图） --- 重要

软件架构的4+1视图 和UML的 4+1视图

从不同的角度来看会有不同的视图，软件架构也存在 4+1个视图可以看

包括：

单个场景下：

• 逻辑视图 --- 最终用户 --- 功能需求
• 开发视图 --- 编程人员 --- 软件管理
• 进程视图 --- 系统集成人员 --- 性能、可扩充性、吞吐量等
• 物理视图 --- 系统工程人员 --- 系统拓扑、安装、通信等

这里的4+1视图和UML的4+1视图基本是一一对应的

需求分析模型里面的 UML的包括：

用例视图 --- 最终用户 ---- 需求分析模型

• 逻辑视图：系统分析、设计人员 --- 类与对象
• 实现视图：程序员 --- 物理代码文件和组件
• 进程视图：系统集成人员 --- 线程、进程、并发
• 部署视图：系统和网络工程师 --- 软件到硬件的映射

2.微服务架构

· 微服务

提到微服务相信很多程序员都不太陌生，互联网技术经过这么多年的发展，很多技术领域为了满足日益增长的日舞，越来越多的新技术涌现出来，其中微服务就是非常重要的一个技术点。

从早期的单体架构、集群架构、分布式架构、到现在主流都是微服务架构，首先这里我们先通过几张图来看下互联网技术架构的演进。

·单体架构介绍

我们都知道互联网刚开始发展的时候，用户量是非常少的，能接触到网络的人都是极其有限的，所以这个时候的互联网的架构师是这样的，只有一个服务器，一个数据库。

· 集群架构介绍

紧接着，随着互联网的发展，用户量的增加（就是能玩的电脑的人多了），原来的这个单体的架构支撑不了这么大的用户访问量了，之前一个服务器，现在网站动不动就挂了，这个课怎么得了；大佬一咬牙，一跺脚，一个服务器不行，加多来几个服务器，就这么一不小心互联网的技术架构就变成了集群架构。

· 分布式架构介绍

本来一切都这么安静发生着，好像宇宙大和谐的样子，用户感觉网速嗖嗖的，大佬们也感觉我们的想法真牛逼，简直可以改变世界。可是没想到，突然互联网迎来了前所未有的大发展，因为多年前有以为老人在中国的南海边画了一个圈。

这个时候各位技术大佬可是坐不住了，网站总是卡死可怎么办，以为增加的服务器根本解决不了问题，之前所有的业务都在同一个服务器中，非常复杂。这个时候就开始把之前耦合在一起的业务给拆分来了，比如：订单模块、用户模块等；这样互联网的技术架构也就演变。

第七单元

1.软件业务架构设计指南

软件架构与设计系列阅读说明

软件架构通常是指软件系统的宏观结构，它涉及多个软件进程如何合作执行其任务。软件设计是指较小的结构，它处理单个软件过程的内部设计。在本系列内容阅读结束并完全理解后，读者将对软件架构和设计概念有充分的了解，并能够为给定的软件项目选择和遵循正确的模型。

推荐受众

本教程面向所有软件专业人员、架构师和高级系统设计工程师。架构团队的经理也将从本教程中受益。

先决条件

本教程没有确切的先决条件。任何软件专业人员或系统架构师或者IT专业学习及从业者都可以通过本系列文章来全面了解高质量的软件应用程序和产品是如何设计的。

概述
软件系统的体系结构描述了其主要组件、它们的关系（结构）以及它们之间的交互方式。软件架构和设计包括几个影响因素，例如业务战略、质量属性、人员动态、设计和 IT 环境。

我们可以将软件架构和设计分为两个不同的阶段：软件架构和软件设计。在架构中，非功能性决策从功能需求中转换和分离出来并做对应实现。在设计中，完成功能需求。

Software Architecture 软件架构

架构是系统的蓝图。它提供了一个抽象来管理系统的复杂性，并在组件之间建立通信和协调机制。

• 它定义了一个结构化的解决方案，以满足所有技术和运营要求，同时优化性能和安全性等常见质量属性。
• 此外，它还涉及一系列与软件开发相关的组织的重要决策，这些决策中的每一个都会对最终产品的质量、可维护性、性能和整体成功产生相当大的影响。这些决定包括：
  • Selection of structural elements and their interfaces by which the system is composed.
    选择组成系统的结构元素及其界面。
  • Behavior as specified in collaborations among those elements.
    在这些元素之间的协作中指定的行为。
  • Composition of these structural and behavioral elements into large subsystem.
    将这些结构和行为元素组合成大型子系统。
  • Architectural decisions align with business objectives.
    体系结构决策与业务目标保持一致。
  • Architectural styles guide the organization.
    架构风格指导着组织。

Software Design 软件设计

软件设计提供了一个设计计划，用于描述系统的元素、它们如何配合以及协同工作以满足系统的要求。制定设计计划的目标如下：

• To negotiate system requirements, and to set expectations with customers, marketing, and management personnel.
  与客户、营销和管理人员协商系统要求，并设定期望。
• Act as a blueprint during the development process.
  在开发过程中充当蓝图。
• Guide the implementation tasks, including detailed design, coding, integration, and testing.
  指导实施任务，包括详细设计、编码、集成和测试。

它出现在详细设计、编码、集成和测试之前，以及领域分析、需求分析和风险分析之后。

Goals of Architecture 架构目标

体系结构的主要目标是确定影响应用程序结构的要求。布局良好的体系结构可降低与构建技术解决方案相关的业务风险，并在业务和技术需求之间架起一座桥梁。

其他一些目标如下：

• Expose the structure of the system, but hide its implementation details.
  公开系统的结构，但隐藏其实现细节。
• Realize all the use-cases and scenarios.
  实现所有用例和场景。
• Try to address the requirements of various stakeholders.
  尝试满足各种利益相关者的要求。
• Handle both functional and quality requirements.
  满足功能和质量要求。
• Reduce the goal of ownership and improve the organization’s market position.
  减少所有权目标，提高组织的市场地位。
• Improve quality and functionality offered by the system.
  提高系统提供的质量和功能。
• Improve external confidence in either the organization or system.
  提高外部对组织或系统的信心。

Limitations 局限性

软件架构仍然是软件工程中的一门新兴学科。它有以下局限性

• Lack of tools and standardized ways to represent architecture.
  缺乏工具和标准化的架构表示方式。
• Lack of analysis methods to predict whether architecture will result in an implementation that meets the requirements.
  缺乏分析方法来预测架构是否会导致满足要求的实现。
• Lack of awareness of the importance of architectural design to software development.
  缺乏对架构设计对软件开发重要性的认识。
• Lack of understanding of the role of software architect and poor communication among stakeholders.
  缺乏对软件架构师角色的理解，利益相关者之间的沟通不畅。
• Lack of understanding of the design process, design experience and evaluation of design.
  缺乏对设计过程、设计经验和设计评价的理解。

第八单元

1.软件技术架构设计指南：

在当今数字化时代，技术架构的设计对于企业的成功至关重要。一个合理、高效的技术架构可以为企业提供稳定、可靠的系统基础，支持业务的快速发展和创新。本文将介绍一些关键的技术架构设计原则和指南，帮助您构建可靠、可扩展的系统。

一、明确业务需求和目标

技术架构设计的首要任务是理解业务需求和目标。只有深入了解业务的本质和要求，才能设计出切实可行的技术方案。与业务团队密切合作，了解业务流程、数据处理需求、用户行为等方面的信息，以此为基础制定技术架构方案。

二、可扩展性和弹性

当今业务环境的快速变化要求系统具备良好的可扩展性和弹性。技术架构应该能够轻松应对业务量的增长和用户规模的扩大，支持系统的水平扩展和垂直扩展。同时，应考虑系统的弹性，使系统能够适应突发的流量和负载变化，确保系统的稳定性和性能表现。

三、模块化和松耦合

模块化和松耦合是设计可维护、可扩展系统的关键。通过将系统拆分为独立的模块或服务，每个模块负责特定的功能或业务，可以实现系统的高内聚、低耦合。这种设计方式使得各模块可以独立开发、测试和部署，降低了系统的复杂性，并提高了系统的可维护性和可扩展性。

四、安全性和隐私保护

安全性和隐私保护是技术架构设计中不可或缺的考虑因素。系统应采用多层次的安全防护机制，包括身份认证、访问控制、数据加密等，确保敏感数据和业务的安全。同时，要合规处理用户的个人隐私信息，确保符合相关法规和标准，保护用户的隐私权益。

五、可靠性和容错性

可靠性和容错性是构建稳定系统的重要要素。技术架构设计应考虑故障和错误的发生，并提供相应的容错机制和恢复策略。采用分布式架构、冗余处理提高可靠性和容错性。

六、性能优化和可伸缩性

在技术架构设计中，性能优化和可伸缩性是关键的考虑因素。系统应该经过有效的性能分析和测试，针对瓶颈进行优化，提高系统的响应速度和吞吐量。同时，考虑到业务的增长和变化，设计具有可伸缩性的架构，能够按需扩展和收缩系统的资源，以适应不断变化的业务需求。

七、技术选型和开放标准

在技术架构设计中，正确选择适合业务需求的技术是至关重要的。需要评估不同技术的优劣，考虑其成熟度、稳定性、可维护性和社区支持等因素。同时，遵循开放标准和通用协议，确保系统的互操作性和可扩展性，便于与其他系统进行集成和交互。

第九单元

1.敏捷软件工程：

　敏捷是一种软件开发方法，其源于将大量工作分解为较小的部分的想法。这使产品经理，开发人员和所有利益相关者对工作有了更好的了解。　　

　　敏捷通常用于软件开发中帮助企业应对不可预测的一些因素，比如对需求无法短时间掌握等。在过去十多年内有很多实施敏捷的成功案例，其中有的公司已经显着提高了他们的IT开发团队开发效率和业绩。敏捷已经跨越多种行业，包括媒体和技术，大型企业，甚至政府被广泛采用。

　　在现实中，虽然敏捷不是所有软件开发问题的灵丹妙药。真正的关键是要知道如何根据情况合适选择瀑布与敏捷(顶层设计 vs. 摸着石头过河 )等等不同开发方法，甚至可以混合。这其中真的需要大量的经验和技巧。在敏捷软件工程，项目管理更依托对项目经理的技能，沟通，促进和协调能力，而更少强调对规划和控制（摸着石头过河 > 顶层设计）。

　　敏捷是从敏捷宣言派生的。在2001年一小群人（包括Martin Fowler、kent Beck等）聚在一起讨论他们的项目管理经验，他们认为传统的管理软件开发项目的方法频繁发生问题，由此提出了敏捷宣言，描述了四个重要点：

1. 在开发过程中通过工具实现独立开发和相互协作。
2. 程序软件要胜于复杂的文档(代码本身就是最好的文档)
3. 与客户协作商量，而不是以谈判等含有对抗意味的交流。
4. 响应变化高于执行计划(计划没有变化快)

　　当遵循敏捷方法论时，较小的工作帮助团队会变得更加灵活，在此过程中，可以帮助他们更快地交付功能并更快地响应更改。

　　这些想法已分解为采用这种方法的不同框架。常见的两种是Scrum和Kanban。

第十单元

1.scrum使用指南：

一、Scrum的认识

首先来了解一下Scrum的定义。

Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的长度是2到4周。

在Scrum中，使用产品Backlog来管理产品的需求。产品backlog按照实现的优先级进行排序，以商业价值作为排序的主要原则。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，称它为Sprint backlog。当Scrum团队完成Sprint backlog列表中的所有任务时，本次Sprint结束，进入下一个Sprint迭代周期。

Scrum有很大的价值，然而在有些公司推行Scrum却困难重重，有些人说Scrum没有什么实质性的作用，然并卵。为什么会有这样的认识呢？深入分析，原因主要有：

项目团队缺乏对敏捷的正确认识，单纯的认为敏捷就是快，就是追赶进度,就可以不受任何制度约束。大家可能听说过这样的对联，“这个功能很简单，怎么实现我不管。”横批：“明天上线”。也曾听说有些公司要开发一个新功能，因为实施了scrum，于是要求项目团队加班加点，将2周甚至3周以上的开发任务在一周内就发布上线。实施Scrum意味着项目团队“漫无天日”的加班，这导致了项目团队对敏捷有一种“恐惧”感；PO不能胜任工作，无法拆分有效的用户故事，或者用户故事拆分的不合理，无法实现迭代增量开发；Scrum对于自组织的团队要求很高，但许多同学认为自己达不到自组织的标准；Scrum倡导工作透明化，项目实时完成情况和每个人的任务认领情况通过项目看板和项目燃尽图一览无余，许多人对此不太适应；在迭代的过程中无法及时发现问题，或者发现问题，无法有效解决问题，使项目团队有一种挫败感。等等。

如果对Scrum的认识仅仅停留在“上午有个点子，下午就要实现，晚上就能上线，是不恰当的。在我看来，Scrum肯定是有价值的，Scrum的主要作用包括：

Scrum能够保证优先开发对客户具有较高价值的需求，更好的满足用户的需求；与瀑布流程下的开发方式相比较，通过实施Scrum，能够提升团队一倍的开发效率，最大限度的发挥团队的作用；Scrum能够缩短开发周期，提高项目的交付效率。

但是，实施Scrum并不意味着不受项目约束，任性而为。那么实施Scrum的正确姿势是什么呢？

二、如何实施Scrum

1. 确定PO

PO即Product owner，是一个角色，PO是管理产品待办列表的唯一责任人。当然，在有些公司PO也可能作为一个组织而存在——比如我们公司在实施Scrum中就将PO作为了一个组织。如果将PO作为一个组织运行，在这一个组织中必须选出一个Owner。

作为owner，必须具有大局观；深刻了解行业信息与走向；能够把握产品的方向，担负起产品短期以及中长期的规划与管理；能够根据公司战略要求，进行用户研究和产品功能规划，深度跟踪、分析、挖掘不断变化的需求，不断进行产品创新。

另外，如果将PO作为一个组织，在软件开发项目中，PO小组可能包括的成员有产品经理、业务方、视觉设计师、交互设计师以及架构师等。

在多数情况下，由产品经理或交互设计师担任Owner。

2. 组建team

team是产品蓝图的真正实施者，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。

team主要包括开发及测试人员，team必须能够落实PO对产品的设想。

team的规模宜小不宜大，一般5~9人较为合适。

在敏捷开发中倡导的是团队人员的“全栈”能力，但目前在大多数互联网公司可能难于落实，比如多数互联网公司前后端开发是分离的，所以在组建team团队时需要特别关注前后端开发人员投入的比例。

以我带的2017年开发的小程序为例，前端和后端人员投入的比例为2:3时，能够最大限度的提升项目的开发效率——当然，这个比例必须基于项目中前后端所承担的具体开发任务情况而定，而不是随性给出。

3. 选择Scrum Master

Scrum Master为过程负责，服务于PO和开发团队。Scrum Master要有仪式感，能够有效地、高效的组织迭代计划会、每日站立会、功能演示会、迭代回顾会等；Scrum Master必须具有高度的执行力，并保持公信力，能够帮助团队聚焦交付目标和质量目标，确保团队高效交付高质量的产品；推动团队建立高效的流程，指导团队了解敏捷价值观、原则和敏捷实践；负责培训团队其他成员，确保Scrum得到正确运用；促进团队有效的交流协作、问题管理、冲突解决，帮助团队消除一切障碍。

4. 维护产品需求池

产品需求池是所有用户故事的集合，由PO依据公司的战略和产品愿景进行的思考。PO按照产品实现的优先级顺序对产品需求池的所有用户故事进行排序，并形成产品待办事项列表，产品待办事项列表相当于产品研发的“路线图”，要想了解产品的脉络，产品待办事项是最好的参考依据。

我们每一天都面对着新的竞争者和用户新的诉求，这意味着PO必须不断地优化自己的产品设计，并对产品待办事项列表实现的优先顺序进行调整。

在这一过程中，PO应该与所有利益相关者和团队进行协商，以确保产品待办事项能够反映用户的真实诉求。