# Workflow **Repository Path**: hzerica/Workflow ## Basic Information - **Project Name**: Workflow - **Description**: No description available - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 1 - **Forks**: 3 - **Created**: 2016-07-07 - **Last Updated**: 2024-05-14 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README App研发流程 ============ 需求分析 ----- *阶段描述：* 产品经理进行需求分析，产出需求分析说明和系统功能表 *重要度：* 任何项目必做 *系统功能表：* 以文字列表形式列出本项目涉及的功能点，大致包含所需要的页面内容。作用：用于精确报价和进度评估，并会列入合同。 *系统功能表范例：* ``` 1: 闪屏页面（含多页广告滚动） 2: 商城功能 1: 商城首页，商品详情，商品搜索 2: 商品下单，购物车，结算 3: 微信、支付宝支付 3: 聊天功能 4: 分享 1: 微信，QQ，微博分享 2: 可分享商品、文章 ``` 可行性调研 ----- *阶段描述：* 研发经理根据系统功能表以及产品经理的沟通，明确项目中的技术难点，并依次进行调研，最后汇报调研结论，产品经理和项目经理根据调研结论调整系统功能表或寻求技术支持。 *重要度：* 对于小型项目可以从简，以简会代替。 *调研结论：* 1. *可做：* 确定该单项需求可以满足，不会带来明显的成本提升。 2. *需评估成本：* 该单项需求可以满足，但会带来明显的成本提升，需与项目经理共同评估时间和金钱两方面成本。 3. *第三方提供：* 该单项需求有第三方方案可以满足。研发经理应评估可选第三方方案的信誉度、稳定性、已知缺陷、以往合作案例、价格成本等因素。注意：需对接第三方SDK，但无额外成本的不在此列（如微信登录分享等）。 4. *高不确定性：* 该单项需求可以尝试完成，但具有高不确定性。产品经理应考虑备选方案。 5. *不可做：* 现有技术条件不成熟、没有对应技术力量或技术提供方、需求理论上不可行。 时间计划 ---- *阶段描述：* 项目经理根据系统功能表和可行性调研结论，进行人力分配和时间评估。 *重要度：* 除非项目内容不确定性极高，否则必做。 *时间计划表：* 针对系统功能表进行人力分配，评估工作量和工作人数，计划项目阶段性目标。对于中小型项目，阶段性目标应以周为单位。对于大型项目，应以月或双月为单位计划阶段性目标，并针对第一阶段以周为单位进行详细评估。在项目结束阶段，应分配不少于项目20%开发时间且不少于2周的时间，用于项目测试和版本回归。 *成本预估表：*根据系统功能表评估项目成本。应包含：所有系统的前后端开发人员人力成本；产品经理、项目经理的人力成本；预备测试反馈修改期的测试人员和开发人员人力成本；需要外协、第三方提供的成本；服务器，运维人员成本； 原型设计 ----- *阶段描述：* 产品经理根据明确后的系统功能表，设计产品原型，以明确产品页面切换流程、展示细节、和大致布局。 *重要度：* 除移植型项目，均为必做。 *可用工具：* Balsamiq，墨刀，Axure，或其它便于团队进行预览的原型工具 *原型演示：* 交付可直接在浏览器或移动端预览的界面原型，不必考虑配色和细节的尺寸比例，但应考虑完整布局、所有的界面跳转逻辑。对于工具难以表达的特殊逻辑和操作手势，应以备注文字的形式体现。 *备注：*部分项目产品经理与设计师交流紧密的，可以以口头沟通的形式先出具视觉设计稿，然后直接采用视觉设计稿制作原型演示以节约时间。 代码库创建 ---- *阶段描述：* 创建代码库，项目经理和研发经理具备管理员权限，开发人员具备开发者权限，自动化集成工具和代码审核人员具备观察者权限，产品经理及测试人员具备报告者权限。 *重要度：* 必做。 *分支管理：* 1. master分支是主开发分支。对于日常的小型功能迭代，直接在此分支上进行开发。大型的功能迭代合并到此分支上。 2. stable分支是测试版本分支。发布测试版本时可合并代码到此分支。 3. 对于大型功能开发、可能会影响其他人开发的功能或页面改动或重构，应创建分支进行开发，并最终合并到master。 4. 对于已发布版本，每个minor版本号发布前创建一个分支。之后仅在重要BUG修复时更新此分支（通过从主线cherry pick） *自动化集成：* 根据项目属性的不同，选择以天为单位构建master，或者在合并代码到stable的时候进行自动化集成构建，发布测试版本。 注册内测分发平台 ---- *阶段描述：* 注册内测分发平台，如[fir.im][http://fir.im/] 注册自动构建平台 ---- *阶段描述：* 注册并设置自动构建平台，如[bitrise.io](http://bitrise.io/)，需完成： 1. 自动代码检查 2. 自动构建iOS应用（如有） 3. 自动构建Android应用（如有） 原型开发 --- *阶段描述：* 工程师仅根据原型演示进行界面开发，以App常用的视觉风格和组件进行页面组装 *重要度：* 仅不确定性较高的项目有必要做。 *产出结果：* 可在手机上直接运行和操作的界面流程体现，不含实际业务逻辑。 视觉风格设计 ---- *阶段描述：* 设计师根据原型演示，挑选5%-10%的主要页面（通常为首页、表单页、弹出框），进行风格设计。 *重要度：* 对于产品经理和设计师沟通紧密的项目不必单独做。移植型项目可以省略。 *产出结果：* PNG格式的演示图。确保视觉风格良好，信息展示清晰。 视觉设计 ---- *阶段描述：* 设计师根据原型演示进行所有页面的精细设计。 *重要度：* 除移植型项目，均为必做。 *规格标准：* 以iPhone5分辨率（640*1130，PixelRatio：2）为标准进行设计。但所有图素应为矢量或更高精度的位图，以便于切出放大1.5倍的图素。 *产出结果方案1：* 产出PSD格式的视觉设计稿；设计的元素分层和命名应当足够表达元素之间的关系；可以通过层的隐藏和显示查看界面状态变化、弹出框等。不同的界面体现在不同的PSD文件中。 *产出结果方案2：* 产出PNG格式的视觉设计稿；每个界面体现为一个或多个PNG文件，多个PNG文件时则包含界面状态变化、弹出框的效果；不同的大块功能可以体现在不同文件夹中。另外对于界面中的图素（如图标、背景图等），提供原图0.5倍、1倍、1.5倍的切图。用在相同或类似位置的图素（如TabBar上的Icon）应附加合理的留白以确保不同图标的规格一致。 组件划分与UI开发 ---- *阶段描述：* 前端工程师根据设计师提供的风格设计图及精细设计图，按项目进度进行主题组件的抽离和UI开发。 *重要度：* 必做。 *组件划分标准：* 一个组件如在多个页面均出现，或在一个界面中出现多次（ListView列表项可不属于此情况），均应抽离成组件。一个组件如果包含较多内容，并与页面中其它部分没有大量交互，也应抽离成组件。 *UI开发标准：* 应精确符合设计师的设计，包括配色、间距或尺寸、字体大小等。对于设计师设计中雷同组件样式存在细微不一致的情况，应先与设计师沟通，确定是否要微调至一致。 *完成验收：* 应展示假数据的页面展示，并完成页面间的跳转。 *理想情况：* 应实现UI自动化测试，与设计图进行比对。 后端设计 ---- *阶段描述：* 后端工程师根据系统功能表以及原型设计图，进行准备工作。 *数据库设计：* 设计数据库的实体关系、表、字段、索引、关系。最终产出一个SQL导出文件，其默认编码必须为utf-8，包含每个表和每个字段的COMMENT。涉及后端项目必做。 *交互协议设计：* 设计服务端与客户端的通用交互模式，并提供文本描述（推荐markdown格式），包含：请求参数的传递方法、响应错误码及提示信息传递方法、长连接基础协议等。涉及后短信项目必做。 *服务器架构图：* 涉及服务器模块之间的架构。涉及分布式、多个服务器模块的项目必做。 后端开发 ---- *阶段描述：* 后端工程师根据系统功能表以及原型设计图，设计具体接口并进行开发。 *开发服务器部署：* 部署用于给工程师开发和内部黑盒测试用的测试服务器。 *接口描述方案1：* 采用postman工具的collection功能描述所有接口，将至少domain和accessToken/session设置为Environment参数，以便于在不同服务器进行测试。每一个请求中应包含：请求的url示例；query string或post请求的所有字段；每一个请求的Description中应包含：url中所含参数的规则（如GET /article/:articleId）；需要特别描述的字段含义；可能的错误码。 *接口描述方案2：* 采用文本形式描述所有接口，必须包含：请求的url及其中所含参数的规则；query string或post请求中所包含的所有字段；可能的错误码及响应格式。 *单元测试用例：* 可采用postman制作，也可采用mocha等js框架制作自动化测试用例。 *理想情况：* 应采用mock数据库配合自动化测试，完成100%代码覆盖率。 业务对接 ---- *阶段描述：* 前端工程师在已实现的UI基础上，实现前端业务逻辑以及与后台的业务对接，最终完成App的功能开发。 *理想情况：* 应完成最终的自动化测试。 功能测试 ---- *阶段描述：* 测试工程师根据项目进度，对于每个阶段性版本测试已开发完成的功能。对于发现的问题，记录到bug系统并予以分类，指派解决人。 *Bug优先级与标签*： 1. 十分严重：阻塞大部分测试的进行，必须立即解决并重新发布版本 2. 严重：阻塞一部分测试的进行，应尽快解决并重新发布版本 3. 重要：影响功能正常运行或存在闪退，必须在版本发布前予以解决 4. 性能：画面卡顿或仅在少量低端手机上出现闪退。应尽可能予以修复 5. 优化：小的体验改善。时间允许的情况下应考虑改善。 BUG修复 --- *阶段描述：* 开发者在平台上接收到BUG，予以修复。应在代码提交记录中包含BUG ID。在代码提交到主线后再调整BUG状态。 回归测试 ----- *阶段描述：* 开发者修复BUG后，测试工程师根据版本记录重新检查相应功能，确认BUG是否已修复，然后打回、补充描述、或验收该BUG记录。 冒烟测试 ---- *阶段描述：* 项目中大部分功能均正常后，进行冒烟测试。通过随机测试、反复尝试、边界情况尝试发掘隐藏的BUG。