概述：软件定制开发由于工作任务和目标具有特殊性，怎么做好定制开发计划工作呢？具体步骤可以分为以下几点：
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的处理
1.3.1任务完成之后，QA在后续的稳定版本开始测试，测试中BUG级别定义如下：
Blocker：直接导致无法继续测试，或严重影响版本中的其他功能测试，需要开发人员立即着手解决。
Critical：自身功能无法继续完成测试，需要开发人员在下一个阶段版本发布前解决。
Major：自身的独立功能无法完成测试，可以在后续1-2个阶段版本中解决。
Minor：功能正常，但显示不合理或布局不合理、或文字性描述不合理等。
功能正常，页面也符合逻辑，但有更好的方案，可以提出improvement。
1.3.2 Bug的修复时间
Blocker：立即解决，发布临时版本
Critical /Major：2内天解决
Minor/ Trivial：4天内解决
Critical/Major的问题不跨周解决，必须当周内解决；
.测试工作规范
2.1版本的制定
2.1.1版本命名规则
2.1.2版本号修改规则
主版本号(0)：未正式提交给客户，作为内部测试版本，主版本号为0.提交给客户的版本主版本号为1.
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
临时版本号：发现致命或者严重问题，导致无法进行测试，需要发布临时版本。临时版本命名为原版本号的阶段版本后加T表示。如 V0.01.01T01
2.2软件版本进入测试组进行测试的前提条件：
送测试的软件经过了开发组内的单元测试，保证在测试时大体业务流程不会出现堵塞现象；
测试组得到配置管理员的通知，可以从静态配置库得到安装包或升级包，并确定包中的内容符合要求（包含Release Note:功能列表，变更清单）。
2.3如果测试组在实施测试阶段中，发生如下情况，测试组有权利拒测：
没有按照规定的格式进行提交；
一个版本在提交的时，存在明显的与需求不符的问题；
环境建立后无法正常的运行软件；
漏提交文件，导致无法测试；
基本功能无法正常运行；
重复性问题较多；
在软件测试过程中，出现的问题严重影响后续的测试。
Bug Fix 规格
2.4.1 Bug级别
致命(Blocker)：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
严重（Critical）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
一般（Major）： 界面、性能缺陷
较小（Minor）：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
建议（improvement）：建议性问题
2.4.2 Bug修改时间确定；
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.1项目Bug总体情况
2.6.2 超时未解决Bug详细情况
2.6.3 Reopen情况