本文目录导航：
前端先写页面还是一边写一边对接口
在前端开发中，理论先写页面还是一边写一边对接口是一个依据详细名目和团队开发流程来选择的疑问。
以下是两种经常出现的开发流程模式：1. 瀑布流式开发流程： - 首先，前端工程师会与UI设计师严密协作，依据需求和设计稿先编写完整的静态页面。
- 而后，前端工程师会经常使用模拟数据对页面启动调试和配置测试。
- 最后，前端工程师会与后端工程师协作，将前端页面与后端接口启动对接和联调。
2. 矫捷开发流程： - 在矫捷开发中，前端和后端的开发是同时启动的。
- 前端和后端工程师经常在每个迭代周期内启动短期的开发上班，并经过接口对接来成功沟通和协作。
- 这种模式下，前端工程师可以依据接口文档来启动前端开发，不用期待后端工程师成功一切接口。
无论是哪种开发流程，在实践开发中，前端工程师和后端工程师之间的亲密协作和及时沟通是十分关键的。
要依据实践状况来选择哪种模式更适宜你的名目和团队。
waterfall中文翻译
Waterfall的中文翻译为“瀑布流”，是一种软件开发模型，也常被称为“瀑布模型”。
一、Waterfall模型的原理和特点
1、分阶段开发：各个阶段区分启动开发，只要在上一阶段成功后能力启动下一阶段的开发。
2、顺序开发：各个阶段的开发必定依照必定的顺序启动。
3、阶段固定：各个开发阶段是固定的，理论包含需求剖析、设计、编码、测试、验收等阶段。
二、Waterfall模型的优缺陷
1、好处：开发环节明晰可控，便于治理和追踪开发进展；开发阶段之间有明白的界限和交付物，便于沟通和协作；实用于对需求变动较少的名目。
2、缺陷：不足灵敏性，不实用于需求变动频繁的名目；危险难以识别和处置，或许造成名目失败；开发期间较长，老本较高，不实用于紧急状况或暂时调整需求的名目。
三、Waterfall模型与其余开发模型的比拟
1、Waterfall模型与矫捷开发模型的比拟：Waterfall模型实用于大型名目，矫捷开发实用于小型名目；Waterfall模型器重方案和文档，矫捷开发器重交付结果和客户反应；Waterfall模型是线性、顺序的，矫捷开发是迭代、墨守成规的。
2、Waterfall模型与增量开发模型的比拟：Waterfall模型依照固定步骤启动开发，增量开发模型是屡次迭代的。
3、Waterfall模型开发期间较长，增量开发能够极速迭代并交付软件；Waterfall模型须要做好每个阶段的交付物，而增量开发只要关注以后迭代周期内的交付物。
如何经常使用矫捷方法启动产品布局？
面对瞬息万变的市场需求以及需求成功的不确定，相比于墨守成规的瀑布流开发方法，矫捷开发的方法更实用于范畴不确定和期间固定的产品背景之下启动产品研发。
从方案驱动到价值驱动，矫捷如何运行到产品布局的环节中呢？以下从团队和流程2个角度来诠释产品布局的矫捷。
1.产品立项会 2.愿景、指标用户探讨、商业模型探讨 3.创立用户画像、用户流程图 4.创立用户故事、探讨可行性 5.用户故事汇报会（若不经过前往到第3步） 6.配置和内容确定会全程介入 制订沟通方案 组织会议和优惠 整顿沟通结构，会集就消息，构成报告 制造原型并和相关部门探讨可行性 创立用户流程图 创立“大”用户故事部门介入（1、2、5、6） 介入关键会议，并在会议中行使否决权 对名目提供资金允许 协助名目团队失掉治理层的关注局部介入（1、2、4、5、6） 针对产品的配置提出倡导，并与产品经理探讨配置的可行性，提出更好的处置方案局部介入（1、2、4、5、6） 针对产品的配置和内容提出倡导，与产品经理探讨用户的体验流程，并针对产品的关键点给出体验提升方案局部介入（1、2、6） 须要时辰了解进展以及探讨论断用于提早制订经营战略明白不同部门之间的介入水平，一方面可以同步进展，另一方面浪费期间，提高效率。
明晰的流程将每个部门的权责理清，保障产品产品布局高效启动。
1.确定产品的范畴（什么该做，什么不做） 2.产出用户故事（做什么）业务角度：剖析产品的消息架构 1.用户钻研和剖析 2.消息分类 3.创立消息架构地图 4.创立消息架构标签 5.提取、创立元数据 6.数据建模用户角度： 1.哪些群体经常使用？他们是什么角色？他们会怎样用？ 2.先剖析用户群体的需求，而后剖析该群体中某角色的需求内容角度 产品的内容在必定水平上会反上来影响产品的配置 1.为什么要识别子系统 子系统是粗粒度的产品范畴的表现 名目干系人和名目小组了解子系统后，会对全体系统有上档次的意识 2.识别子系统的方法 经常使用配置结构图和流程图经常使用泳道图产出跨子系统的用户流程图，随后区分制造各子系统的用户流程图 泳道图可以极速得悉不同对象的配置以及配置之间的前后相关 触及到外部跳转的时刻，至少须要一个步骤（配置点） 当触及到转机点，或许消息形态出现变动，须要一个步骤（配置点） 依据干流程识别MVP，将配置做删减 驳回MoSCoW规律将配置点分类： •Must Have：指必定要有的配置 • Should Have：指应该有的配置 • Could Have：指可以有的配置 • Wont Have：指（此版本）不会有的配置 在实践运行中，Must Have比拟好识别，关于Should Have和Could Have可以驳回“价值和成功难度”矩阵识别和归类： 用户价值高，难度低，优先制造； 用户价值低，难度高，延后制造甚至不做； 用户价值高、难度高和用户价值低和难度低：延后制造； 留意：开发部门或许出于识别、规避危险的思考，会先做“难度高，价值高”的配置 制造线框图，并组合到MVP流程中，失掉“线框流程图” 线框流图的意义在于： • 既能够展现出用户经常使用流程； • 又能够将用户体验的元素展现进去； 依据MVP地图和线框图，产出“大”用户故事，随后组织会议探讨并达成分歧 拆分“大”用户故事为“可开发”的用户故事，并配合研发部门启动开发为什么要组织用户故事验收会议？ “大”用户故事将被拆分为数个小故事，在拆分以前，必定确认他们是必要的 验收会议能够确保不会有“大”用户故事被遗漏 谁掌管？谁加入？ • 产品经理掌管会议 • 名目团队、相关团队、名目干系人都须要加入 会议后的产出物是什么？ • 经过群体确认的“大”用户故事 • 名目干系人确定其必要性 • 相关团队确定其正当性 • 开发团队确定其可行性 • 会议后，产品团队行将其拆分为“可开发”、“小”的用户故事 方法一、依照流程启动拆分 方法二、从便捷到复杂的拆分 方法三、依照操作边界拆分 方法四、依照数据边界拆分 方法五、依照特性、特性拆分 特性的需求或许包含： • 安保处置 • 失误处置 • 日志处置
