在新公司引入敏捷开发。我写unit test，下属写商业逻辑，可行吗？

1，我计划采取并行开发的模式。可能不算纯粹的 TDD。

2，耦合的问题我也想过。我觉得，其实写商业逻辑的人不用太考虑 unit test 这方面的东东，只要他严格按照设计好的接口，以及商业逻辑要求来做就行了。而我作为写 unit test 的开发领导，就需要付起更多的责任。

完全同意你的看法。我的本意就是，从 TDD 入手，引入敏捷方式。

如果不结对的话, 听上去不可行.
响应时间和沟通都是问题.

活活，没见过。我还是打算用快速迭代的敏捷模式，但是把 test case 和业务逻辑分开由不同人来写。

和你举的例子不同的是，我的方式还是像典型的敏捷那样，经常运行测试，及早发现问题。

测试代码和生产代码是紧耦合，测试、设计是同步进行的。
别人怎么理解测试代码，怎么理解设计？是一个问题。

严重打击积极性，创造性。

工作量很大，可能超大。

这可能不是敏捷，只是一个实践。

又当教练员又当运动员不好。

ms gigix说pair programming比较靠谱。

我觉得，其实写商业逻辑的人不用太考虑 unit test 这方面的东东，只要他严格按照设计好的接口，以及商业逻辑要求来做就行了。而我作为写 unit test 的开发领导，就需要付起更多的责任。

我倒是十分好奇lz对哪些类进行测试 哪些类不进行测试
业务逻辑都不测试了？ 难道还有比业务逻辑更重要的东西？

多谢指出问题。

〉测试代码和生产代码是紧耦合，测试、设计是同步进行的。别人怎么理解测试代码，怎么理解设计？是一个问题。

〉严重打击积极性，创造性。

在我打算实行的这种实践里面，我计划先固定某一个模块的设计，然后再分头进行测试代码和商业代码的编写。可能不是那么敏捷，但我相信会比这个公司目前的模式好。

〉工作量很大，可能超大。

请问，你指的是哪方面的工作量？写测试代码的？还是沟通交流的？

〉这可能不是敏捷，只是一个实践。

我承认，这确实不算合格的敏捷。可能称之为一个折衷比较合适把。

你误解我的意思了。业务逻辑当然要测试。

我计划的做法是，先在会议中固定某个业务逻辑模块的设计（精确到方法），然后再分头写 unit test 和业务逻辑。在这时候，写业务逻辑的下属就不太需要关注我的 test case 怎样写的，因为大家都是按照同一个设计来行事。而我作为team lead，就要负起责任，做好一切质量保障，以及协调沟通上的工作。

我觉的这是不现实的，精确到方法的设计实在太难把握，修改的频繁以及你和开发者之间的协调工作将浪费很多时间

扯的太多其实也没什么用处。
建议LZ先不要猜测。可以先跟头沟通一下，做一个计划出来。有兴趣的话大家可以讨论一下计划。

至于能否成功，只有实践能告诉我们。 也希望LZ能够实践后总结一下经验和教训，供后人借鉴。