小需求总结

需求流程相关

c）确认产品线pd对该需求的了解情况：确认需求的时间点，需求内容等。

==========需求分析及时间评估============================???????????????

==========需求开发测试发布============================??????????

功能预演还是能够在测试环境（开发环境，接近测试环境）下进行，问题也能够及早暴露。

资源评估，时间管理

1. 没有RA，沟通时间比以前增加！

2. 每天投入的时间比

1. 充分理解需求，详细设计，需求附加值

刚接触这块业务，完全不熟悉，充分借助团队力量，除了pd，产品线的开发云鹏，肖蓉，小红都参与了需求分析和确认。并且我们也通读相关代码，从代码分析业务逻辑。

详细设计：设计方案（整体方案，代码结构等）多次与晓军，云鹏沟通。

需求附加值：向处罚中心迈进一步，也是得到晓军的点播。既要考虑小需求本身的价值，又要了解对产品发展有何作用（平时多关注个产品线的发展）。

2. 责任心，良好配合（默契）

需求比较大(修改了78个文件)，我和小亮还在兼顾阿凡达项目，能按期发布，与我们两个良好的配合和责任心是分不开的.

3. 对需求有整体计划和分工，对需求进度跟踪与把控，对需求问题及时跟进。

???????? 由于不良的开发习惯,改完一个文件就惯性的进行比对后提交.特别是用svn插件。

提交方式：命令先svn st svn diff 再svn ci。ci文件很多，可以选择插件，最好是多选后，一次性提交。

提交原则：等待开发完一个稳定可测的版本,比对没问题后,再一次性提交代码.减少svn服务器消耗.

提交频率：基于以上，频率应该超过小时每次。

??? // 不实价格

??? UNREASONPRICE("unreasonprice");

??? private String value;

??? private PriceReportPublicityType(String value){??????????????????????????????????????

??????? this.value = value;

??? }

??? public String getValue() {

??????? return value;

??? }

}

?

如果是UNREASONPRICE("1")，数据库的确需要存“1”，这样可以达到见名知意的效果。

?

public enum PublicityType {

??? // 物价局举报

??? PRICE_REPORT,

??? // 投诉

??? COMPLAINT;

}

?

代码简洁，参数传入枚举（类型检查），

误区：数据库没有规定只能用小写。

3.1 ?一个任务起不来，如果自测是可以避免的，从代码分析，认为不会有问题（没改逻辑）

充分自测

熟知应用的部署及依赖的外部环境（credit的web应用和daemon是分开部署的，web应用中的service是同过dubbo暴露的）

?3.2 ?发送消息的代码空指针异常.

由于同样逻辑的消息发送代码项目中已经存在,所以直接把这一行代码copy过来,且单元测试时用了mock,没有发现此问题.用Dzone做接口测试时以为是配置问题,

把此问题给忽略掉了.事实上原来的代码在注入该发送消息的bean的时候做了id的转换,所以导致我程序中这个bean没有注入进来.

改进方法:做测试时一定不能放过任何可疑的地方.

问题一定要有owner，确认问题内容，完成时间，结果（有时需要进度）反馈给相关人。

4. 发布前修改代码（最后修改出问题，产生紧急发布）？

pd，开发等小需求或项目成员集体评估，要不推迟发布，要不不修改。

若果一定要改：

明确改动点，测试分支。一定要测试。切忌不能改代码测试。

ci代码，一定要svn st，svn diff。

最好两个人一起完成（一个改，一个看着）

?5. 发布时候才知道有样式发布，且需要和应用同步发布。

?新的样式，可以提前发布。修改原有的样式，必须先发模板，后发样式。这个同步是靠人去控制的。要仔细评估时间差带来的影响。

跟ued沟通过，还没有规划，比如自动和网站应用一起发布。已反馈给ued架构。

作为小需求负责人：

信用档案改动点很小，没及时跟进这块的工作。发布计划也把这块忽略了，没有与开发，ued，测试等明确发布计划。这是一个失误。

很长，不过对大家总会有帮助的。。。。也欢迎大家分享心得。。。让我们做出高质量的需求！