公共代码人员把设计完毕的数据结构交给业务开发组组长，组长来编写每个功能的数据增删改查操作文档。增加这部分文档到EXCEL中，成为第六个sheet。
我没有研究过测试驱动。我一直提倡的是全程测试，从需求到设计到代码到文档到打包，都要经过测试。只有每个环节都能保证正确，结果才会正确。如果到了代码编写完后才发现了不对，甚至是需求一开始就理解的不对或有矛盾流程，这就糟糕了。许多人喊需求总变，项目进度无法保证，不仅仅是没有配备需求调研人、业务开发组组长、测试人，更是研发流程方法上有问题，没有采取全程测试。
文档编写完毕一个整块(不是全部的一级功能编写完毕后)，我们就会交付给业务开发组去开发。具体开发人员任务安排，由业务开发组组长来决定。需要由公共开发人员来开发的，业务开发组组长都会根据自己的开发计划和公共开发人员的任务列表(我们用需求管理系统来安排每个人的开发任务)，告知公共开发人员预期的实现完毕时间。
这样，公共开发和业务开发在并行，设计编写和功能开发在并行，设计和设计测试在并行，代码和代码测试在并行(我们采取的是版本管理和每日构建)。这样的情形就跟流水线工作一样，颇有点像丰田的流水线生产，一旦发现某个环节出现问题，理解集中人力来解决，而不会让这个问题的这个人延期钻牛角尖，否则，所有的项目进度管理都成了一句空话。没有了实质的进度，也就没有了实质的项目预算管理。那到底能不能赚钱，真成了一个鬼才知道的问题。
很多朋友在开发当中没有写过文档，一旦有想法要正规化研发管理，就动辄要求全程文档，这文档，那文档，把开发人员累的，最后产品质量和产品进度都没有保证。一看试验失败，就全盘否定编写文档，再回归到一无所有的状况。真是走两个极端。
希望这篇文章能够给大家以平和的心态看待编写文档。我们并不是为了正规才编写文档，我们写的每一个文档都有作用。我们也在力求能少写就少写，根据团队的、客户的磨合理解共识程度，哪个文档或哪个环节不需要写，我们就砍掉。
我们并不在乎正规不正规，我们也并不在乎我们看上去很美，那没有用。我们只是商业开发，我们要的是可控，在有限的人力资源、合同额、合同周期内交付出客户认可的质量产品(不是高质量，是客户能接受的质量，我们从来不为没有利益回报的东西多付出)。
文章来源于领测软件测试网 https://www.ltesting.net/
