小需求总结
需求流程相关
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，测试等明确发布计划。这是一个失误。
很长，不过对大家总会有帮助的。。。。也欢迎大家分享心得。。。让我们做出高质量的需求！
