对日软件开发体会之一

以前从事对日软件外包工作，觉得很多日本企业的开发流程过于死板，开发框架也过于老套，对开发人员的技术要求极低。但他们的文档要求却不是一般的高了。在文档这一点上我们是不是可以参考一下他们的做法。

 

日本人的需求文档的作者一般是项目负责人，这类人需要有很强的代码功力，因为需求文档上需要写下详细的逻辑设计，细到一个判断语句，细到一条SQL语句。可能你认为这样很BT，因为我们总是认为设计归设计，SQL之类的都是开发人员的事情不需要在文档上写明，但这样做的好处是只要开发人员一拿到需求文档只要完全按照文档上的思路来实现代码，原则上只要文档的思路没有错误就不允许修改逻辑（有时需求上的逻辑判断很冗余，比如a>b并且a>c的情况下去判断b大于c，其实这样的判断逻辑开发人员觉得可以改为(a>b)&&(b>c)看起来更清晰更优化，但这是不允许的）。因为一旦实现的代码和文档上的需求逻辑对不上就不利于维护，以后需求有变更的时候文档的修改和代码得不到统一，这样容易产生风险；同时也不利于测试人员的用例设计(对日软件的测试倾向于白盒测试)，测试人员是根据需求文档的逻辑来写case的，一旦代码的实现和需求上的逻辑不统一，用例就不能完全覆盖代码，这样也容易产生风险。

 

在这一年的对日软件开发中，我体会到日本人主要把精力放在了前期的需求文档上，文档包含了代码的实现逻辑，SQL语句的编写等等，使得在开发上花很少很少的时间就可以实现程序，产生的bug率会很低。

 

当然我们的UC不可能像日本人那样连代码的逻辑思路也写完整，但UC需求是不是应该由开发人员来写我这里有个疑问。首先，开发对需求了解的度应该不是百分之百的，由他他来写UC是不是会容易遗漏细节(很多遗漏的细节在UC评审中可能会被忽略)；其次，开发写UC容易根据自己主观上的代码实现的难易程度来适当的调整需求(他们总是有理由说如果不这样做会代码的难度会增加多少倍，但换位思考一下，要知道用户并不会因为实现技术有多难而体谅我们，用户只关心结果)。

 

我觉得UC的编写是不是可以让PD或者项目经理来完成呢？由他们编写出来的需求文档我想后期需要改动的地方会很少，实现的页面用户体验也高，相对来说可以很好的减少测试人员和开发人员的沟通成本。

 

   以上只是我个人的一些见解，其中肯定有很多不当之处，敬请达人不吝赐教！