软件定制开发工作安排规范
本文来源：www.sunseam.com 发布日期：2014-11-29
概述：软件定制开发由于工作任务和目标具有特殊性，怎么做好定制开发计划工作呢？具体步骤可以分为以下几点：
1 .开发工作规范
2.1.1版本命名规则
2.1.2版本号修改规则
2.6.2 超时未解决Bug详细情况
2.6.3 Reopen情况
1 .开发工作规范
- 任务安排和质量保证
- 所有的任务安排以JIRA的形式进行发布，非JIRA拒绝接受（开发工作开始后进行）
- 任务安排应当事先与接受人进行沟通，沟通后在JIRA中填写Task。
- 任务应当有明确的边界、可交付的成果、可被测试、明确的人员和时限。
- 相关开发人员在任务有疑问时应立即与发布人沟通。
- 相关开发人员及时与Leader或PM沟通自己的设计思路，降低设计风险。
- 每天下班前更新任务的状态和完成进度（COMMENT），便于PC的统计和QA的跟踪。
- 一个Task的完成不仅包括代码的开发，还包括UNITTEST代码的编写和交叉测试的BUG修改，UNITTEST测试的代码覆盖率要达到90%以上，才能被认为是符合代码质量要求
- 在修改Bug的同时完成新的Task，无限恐怖www.nnhaier.com
- 万科自动化测试执行
- 自动化流程每1小时执行一次，如出现问题，请引起问题的人员邮件回复大家原因和处理时间；
- 所有自动化过程中出现的编译问题必须在30分钟内解决，并给予邮件回复，并告诉问题原因；
-
所有自动化过程中出现的单元测试问题必须在2小时内解决，并给予邮件回复，并告诉问题原因；
- 版本的发布
- 版本命名规则：软件版本号由三部分组成，第一个0为主版本号，第二个1为子版本号，第三个1为阶段版本号，例如：V0.01.02。
- 版本号修改规则
- 主版本号(0)：未正式提交给客户，作为内部测试版本，主版本号为0.提交给客户的版本主版本号为1。
- 子版本号(01)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能，此版本号由项目决定是否修改，发布周期为1-2周。
- 阶段版本号(02)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔1-2天，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
-
临时版本号：发现致命或者严重问题，导致无法进行测试，需要发布临时版本。临时版本命名为原版本号的阶段版本后加T表示。如 V0.01.01T01。
- Bug的处理
- Blocker：直接导致无法继续测试，或严重影响版本中的其他功能测试，需要开发人员立即着手解决。
- Critical：自身功能无法继续完成测试，需要开发人员在下一个阶段版本发布前解决。
- Major：自身的独立功能无法完成测试，可以在后续1-2个阶段版本中解决。
- Minor：功能正常，但显示不合理或布局不合理、或文字性描述不合理等。
- 功能正常，页面也符合逻辑，但有更好的方案，可以提出improvement。
- Blocker：立即解决，发布临时版本
- Critical /Major：2内天解决
- Minor/ Trivial：4天内解决
-
Critical/Major的问题不跨周解决，必须当周内解决；
- .测试工作规范
2.1.1版本命名规则
2.1.2版本号修改规则
- 主版本号(0)：未正式提交给客户，作为内部测试版本，主版本号为0.提交给客户的版本主版本号为1.
- 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
- 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
- 临时版本号：发现致命或者严重问题，导致无法进行测试，需要发布临时版本。临时版本命名为原版本号的阶段版本后加T表示。如 V0.01.01T01
- 送测试的软件经过了开发组内的单元测试，保证在测试时大体业务流程不会出现堵塞现象；
- 测试组得到配置管理员的通知，可以从静态配置库得到安装包或升级包，并确定包中的内容符合要求（包含Release Note:功能列表，变更清单）。
- 没有按照规定的格式进行提交；
- 一个版本在提交的时，存在明显的与需求不符的问题；
- 环境建立后无法正常的运行软件；
- 漏提交文件，导致无法测试；
- 基本功能无法正常运行；
- 重复性问题较多；
-
在软件测试过程中，出现的问题严重影响后续的测试。
- Bug Fix 规格
- 致命(Blocker)：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
- 严重（Critical）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
- 一般（Major）： 界面、性能缺陷
- 较小（Minor）：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
- 建议（improvement）：建议性问题
- Blocker：立即解决，发布临时版本
- Critical /Major：2内天解决
- Minor/ Trivial：4天内解决
-
Critical/Major的问题不跨周解决，必须当周内解决；
- test case的执行
- test case 的设计，执行，更新：QA执行。每当有需求变更，及时更新test case。
- test case review制度：QA提交的test case由QA leader以及DEV leader共同review。重点：体现业务逻辑的审核，功能点的缺失。异世邪君www.nnmidea.com
-
跟踪 case的执行：每天提交test case report。Test items:“通过”标示P，“未通过”标示红色F，并注明Bug id。“无法测试”标示Block。
- QA的报告规格
2.6.2 超时未解决Bug详细情况
2.6.3 Reopen情况