![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2019-08-05T14:03:58+08:00","default:Admin","Admin") 開発手法 产品迭代开发上线流程 产品需求确定 †首先是产品将需求确定，产品、研发、运营对需求的理解一致。 开完“需求确认会”后，交互设计师出交互稿，然后是“交互确认会”，最后是“视觉稿"出炉，"视觉稿确认会"后，开发就正式接手。 一般是：需求原型确定之后服务端开发就会接入，等交互稿和视觉稿确定之后，客户端开发就会接入。 PRD、BRD和MRD，一起被认为是从市场到产品需要建立的文档规范。 商业需求描述(BRD)Business Requirement Document:决定了项目的商业价值 市场需求文档(MRD)Market Requirement Document:侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化。 产品需求文档(PRD)Product Requirement Document:要把MRD中的“产品需求”的内容独立出来加以详细的说明，而产品需求本身是在MRD中有所体现的 开发周期评审确定 †确定一下的时间节点：
开发在接手需求后，会对整个迭代进行开发排期，并确定交付验收时间，发布验收时间，上线时间。 交互UI稿评审确定 †UI终稿包括：UI图、所有icon的切图 交互稿和UI稿也是非常重要的，我们常遇到交互和UI终稿给的不及时，造成研发延期。 测试用例评审确定 †全局测试用例，冒烟用例确定 测试人员召开测试用例评审会，告诉开发们，在后期测试的时候会进行那些用户路径测试，确定全局测试用例，冒烟用例是什么 冒烟测试：对此次需求的基本功能进行大致的测试，不要求覆盖面有多广，但至少要保证覆盖待测产品的绝大部分功能；不要求每个功能都测的很详细，但至少要保证此次需求主流程功能都是可用的。 开发 †确定了开发周期的各个时间点后，研发就会开始做一些技术调研，代码设计，开始码代码！ 交付验收通过 †测试人员确定完成交付验收 测试人员首先会对产品进行冒烟测试，当冒烟通过率为100%时，就开始全面测试。 交付验收提交的版本，功能成功率不得低于80%。同阶段，交互设计师和视觉设计师会对产品进行走查。 走查：检查产品实现与当初自己的设计是否有出入。 发布验收通过 †产品和设计确定完成发布验收通过 当测试经过交付验收之后，开发会修复所有的bug，此时发布验收提交的版本，功能成功率不得低于98%。 预发布通过 †测试代码+正式数据，产品确定没有问题 发布验收之后，开发会将数据库从测试环境换为线上环境的数据库，但代码还是测试的代码，也就是大家口中的预发布。 完成提审 †完成提交到 AppStore 或者应用市场进行审核 这是移动端的专属名词，特指要将APP提交到APP Store或者应用市场审核，等那边的人员审核通过后才能真正上线。 完成上线 †App Web 端上线，App内测试安装报和的地址无误以及关联产品 测试没有问题后，将代码整合到线上，在线上测试没有问题后，App相关的Web端，App内测安装包和地址无误（内测阶段），关联产品（官网、管理后台等）进行上线。 回滚策略确定 †App Web 端，App内测安装报和地址以及关联产品 web端如果在上线后发现有重大问题，研发需要马上让代码回滚，将更新后的代码换回到原来的代码中。App端主要就是需要把内测安装包地址对应的安装包进行回滚。 Hotfix方案确定 †程序补丁紧急联系人 当产品上线后发现有一些小问题，就会采用Hotfix方案进行修复。所谓方案确定就是需要确保实行Hotfix方案的人员，包括研发和做回归测试的人员。 发版 †移动端审核通过 移动端在App Store或者应用市场完成审核，即新版本发版成功。 セシウム137を97.7％吸着 
コメント： |
