哈哈，标题党了。其实是我求细节操作。
以前也有看过一些TDD的资料，但一直没有在实际的项目中实践过。最近可能有一个新的项目，不是特别大，想采用Scrum和TDD小试身手。先介绍一下我们以前项目的开发流程：
1.拿下项目，需求调研分析，编写需求用例（如果客户没有要求，需求规格说明书都不写）
基本上需求用例就是说明什么人，做什么事情，怎么做，达到什么目的，有什么要求这些。
2.然后分析领域对象，分析业务流程和场景。并最终生成数据库物理模型。
3.概要设计，其实也没什么，就是数据库结构，还有用例描述加一些时序图。
4.根据需求用例，编写测试用例。
5.开发人员进行开发，有时项目紧的时候，单元测试都不写（这个项目没有明文要求），主要靠开发人员个人意愿。
6.根据周期定期进行打包测试。我一般会每周build两次，亲自操作一下业务流程，有问题提出修改。这个过程测试人员未参与。
7.测试人员进入，按模块完成的先后顺序，持续的测试修改。
以前的项目基本上是采用领域驱动的方式进行一步步开发的。现在打算采用TDD方式，现有一些细节疑问，打算请教一下实施了TDD的各种牛。
1.TDD方式是不是不用写需求说明书了？
2.分析领域对象，分析业务流程和场景。并最终生成数据库物理模型。这一步是不是在TDD之前完成？
3.不写概要设计，由需求用例直接跳入TDD开发？
4.测试用例是不是需求用例的细化和规范？
5.TDD中的test是基于单元测试，还是基于需求测试？
6.如果是单元测试，自然由开发人员完成。如果TDD是基于需求测试，那么开发人员是否需要测试人员配合？
最后一个问题是：大家有结对编程的习惯吗？在实践过程中结对是否高效？反正我是觉得结对不会太高效的，主要是基于项目人员的配置本来就有成本在那里，而且人员水平也不一样。我的观点是一个经验丰富的带一两个新手共同开发一个模块，但并不需要结对的方式。
ok,问题完了。等大家拍砖。
问题补充
1. 首先明确unit test和功能测试不一样，参与的人也不一样。
2. 设计完了再入TDD阶段，写UT的过程其实也是校验测试的过程，如果测试不好写，就需要review设计。这里插播一下，既然考虑采用DDD，应该先出来CDM，然后java OO与CDM对应，剩下才是设计物理模型和持久层
3. 传统意义上的TDD指的是unit test。背后很重要的一个思想是先写测试有助于写出clean code that works, 或者说是just enough的代码，实践上需要权衡。对程序员的编程技巧要求高，在我的团队成员中，从零到真的能写出“单元”测试，需要每天抽一小时1 on 1 code review一个月以上。
需要程序员有逻辑拆分以及一些coding技巧，看implementation patterns / clean code 这两本书会有帮助，但关键还是每天的code review给及时反馈。
4. 100%覆盖是不切实际的东西，尤其是初次尝试TDD，可以采用以点带面的方式，让部分成员先尝试到TDD带来的好处，然后在团队中传播；
5. 成员水平不一样可以采取结对方式提升人员水平，但成本回收周期长，基本不会对本项目（3月内的项目）产生benefit，但遇到有好苗子要坚决培养，否则日后还是会死，留不留得住人，就是另外一个管理topic了。
仅供参考。
1.unit test和功能测试肯定是不一样的。我问的是xp和tdd需不需要写需求规格说明书。
2.我要说的是TDD，不是DDD.你的意思是不是先DDD完了，再进入TDD?
3.但我好像看以前某些牛说TDD中的Test Driver不是unit test driver,而是需求test driver.当然如果要tdd,unit test肯定是必需的了，测试-->重构-->设计，然后反复。
4.这个基本上同意。
5.成员水平不一样可以采取结对方式提升人员水平，对于你这个观点，我不同意。我记得几年前，有人讨论过水平不一样，结对更加容易流产。
