针对新增的流程性较强的功能，最好输出业务功能流程图/技术方案流程图
以便PO和技术更好沟通并理解功能，明确业务边界，验收标准，开发项优先级等，也可做为用户手册、项目对接培训、业务梳理等的知识沉淀储备。
拆特性方法：
-
明确业务闭环效果——原型设计展示，注意细节说明，同时以便测试人员进行业务链条整体测试和了解部分需要回归测试的内容——上级/PO
按照完整业务链条，按照业务链条进行拆分和整合（以便故事更好拆分）——事件节点
拆故事方法：
• 描述三要素——提供明确的验收标准细节。（作为一个用户角色，想要做什么，达到什么效果）
如：作为lowcode平台管理员/应用拥有者/应用开发者，点击数据源虚拟字段条件表达式，在条件表达式客户端内可自定义计算规则，支持常量（大小写字母/数字）和变量（当前数据源模型字段），规则支持基本四则运算和join函数，同时支持表达式规范的校验，以实现用户高效率且友好体验的录入表达式内容，支持复杂计算逻辑的定义。
注：权限相关的故事最好加上用户角色进行描述。
• 原则：独立的、可商谈的（有边界）、有价值的、可估算的（可量化）、较小的、可测试的——PO
1. 偏技术类故事
a. 问技术负责人可分为哪几部分，让他们补充最终的效果，po能理解即可，注意先后级联关系，确保控制优先级
2. 偏业务类故事
a. 业务功能链（有先后制约关系）——模型支持Oracle数据库
b. 所属模块划分（平级关系、跨层次配合）——模型独立/数据源API增删改查
c. 按操作/交互切分切分（步骤条等）——新建模型/数据源配置
d. 按不同界面划分——事件流节点属性面板
e. 按动态配置/级联控制项划分——数据类型级联控制（长度、默认组件、默认值、小数位数）
3. 针对优化任务，可合并同一模块相关的内容建立优化此模块的功能故事
故事拆多大合适
故事可以怎么拆
拆任务方法：
•对接联调——技术/PO
• XX任务前后端对接
• 按照功能实现要求，前后端功能任务分别对接（√）尽量避免如下拆分法：
○ 导出-前端
○ 导出-后端
如何评估故事拆分是否合理
按照一定模式拆分完还需考虑具体实现是否合理，可用以下判断法判断是否需要调整更换另外一种拆分方式。
