小需求总结

Hi，all：

        

                   最近完成了个小需求，有很多收获，小需求成员一起做了总结，与大家分享。

 

需求流程相关

                     ==========了解需求的背景============================

                     a）搞清需求来源，就是谁提的需求，了解需求的商业价值。

                     b）搞清需求涉及哪几条产品线。

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

                                     if(需求方不是产品线的PD) {

                                     a） 与需求方确认和哪些产品pd确认过，确认的内容，确认的时间。

                                     b） 引导他去确认好需求，必要的时候参与这样的确认会议。

                                               c） 收到需求方的反馈和产品线pd的反馈。

                                     }

                     d）搞清楚需求涉众，常被忽略的是运营或客服

                           

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

                     a）需求的功能点，需求的改动点，需求的影响点，需求的可行性，需求初步方案。

                     b）借助团队和一切需要的资源：产品线pd，开发，测试，PLA甚至架构

                     c）时间评估

                         参考产品线开发的评估时间，考虑自己处理小需求的时间，使用小需求时间评估模板。

                         重点元素：需求确认时间，设计时间，开发时间，自测时间，单元测试时间，review时间，与测试沟通时间，bug fix时间，联调时间，发布时间，是否满足需求方期望？

                                    

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

                     a）制定小需求计划，告知相关人。抄送老大。小需求跨度很长的话，定期告知需求进度。

                     b）设计

                            目的在于想清楚怎么做，必要时写出设计方案，找熟悉的开发，PLA review方案。

                            接口设计，需求的功能点，需求的改动点，需求的影响点（通知到相关人），表结构等，重要信息都应记录下来。

                     c）开发，自测，review，联调，对tc，功能预演，提交测试。

                            吃透需求，详细的设计，这次开发的时间反而比预期短，也比较顺利。达到事半功倍的效果。

                            功能预演：最好是能够召集小需求涉及的所有人进行功能预演，每个人关注的点不一样。

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

                     d）测试（bug处理，用户体验）

                            环境问题常占用很多时间，熟知依赖的环境是有利的。

                     e）发布

                            发布计划（发布内容，时间，顺序，负责人。发布前的准备，比如数据订正的方案和流程。），

                            发布当天上午，代码预合并。时间跨度大的，最好前一天就预合并下。

                            需求发布后邮件通知，需求归档，需求总结，jara平台关闭需求。

                  

                  

资源评估，时间管理

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

                              要思考如何降低沟通成本。

 

2. 每天投入的时间比

                             只有会议培训，正常能投入7h

           如果还有应用维护，能投入到6h，已经不错了。

           如果同时还在项目后期，能投入到4h吧。

 

        好的方面

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

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

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

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

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

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

                由此想到一个团队，每个人不仅是完成自己份内的事情，只要稍微向前多迈一小步，就能把事情做的更好，更顺，也会增加彼此的信任感和默契。（要赞下小红和云鹏，有很强owner感）

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

 

        产生的问题

                     1. 代码review问题

                                     1.1 svn问题，正确的ci代码原则？---小亮补充

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

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

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

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

 

                            1.2 枚举常量的使用问题,云鹏已经分享过了。

                                               public enum PriceReportPublicityType {

    // 不实价格

    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;

}

 

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

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

                                              

                     2. 测试环境问题，测试不显示正确结果，排查半天无结果，很有可能是环境配置错误--往往被遗忘这个原因。

 

                     3. 两个bug

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

充分自测

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

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

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

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

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

 

                     3. 信用档案问题被提到三次是否确认？

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

 

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

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

若果一定要改：

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

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

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

 

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

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

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

作为小需求负责人：

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

                                                     

         ===================over===============================

 

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