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

目前我所在的公司已经基本实施了敏捷开发，所以我个人对敏捷还是有一些心得体会的。我和其它team members都自觉的写测试，写代码，通过，再继续写测试...

最近我要换公司了。新公司里面我担任 {架构师 + 开发领导} 的职务。但是问题在于，新公司并没有实施敏捷模式，我未来的下属们还是继续着看文档写代码，然后再调试...这样的方式。

我很想在新公司引入敏捷的模式。然而谁都知道，多数人（上至管理层，下到程序员）一开始对 TDD 是会有抵触情绪的。管理层不愿意多给时间（因为他们想当然的以为 TDD 会多用时间），程序员不想多写东西。所以，我打算，在初期阶段，由我自己来写所有的 unit test，而由下属们写商业逻辑。让大家了解 TDD 的好处之后，再作进一步计划。

以前似乎没有看到过这样的模式（可能是我孤陋寡闻了）。请问各位，你们觉得这样可行吗？还有，可以长期这样下去呢，还是仅仅是权宜之计？希望有兴趣的来讨论讨论！

No problem.
In our team, most unittest were wroten by PM/TL.

感谢rtdb的经验共享！

再提出一些我关注的问题，大家来讨论：

1）Project Manager / Team Leader 和 team member (程序员) 之间是如何协调的？我猜想，是技术会议决定了（或者说宣布了）系统设计（细节到达 Class Diagram 这一层），然后大家分头写 unit test 和系统代码，是吗？
2）请问，这种情形下的测试用例，实际上由谁来运行？PM/TL，还是 team member？
3）PM/TL 有没有固定的周期性（比如说，每天5:30到6点）的实施 code review？

1, 所有业务逻辑的unit test都有你一个人来写, 这个工作量可曾估算过? 代码量可是跟业务代码量相差无几的阿.
2, 你的下属认同这种方式吗?
3, 你的领导认同吗? 没有他们的支持,做起来很难的.

活活，有这些困难的存在，所以要仔细计划嘛。

1，unit test 虽然量很大（通常1：1，1.5：1 甚至更高），但是逻辑相对简单，编写速度快于业务代码。当然，要完全由一个人应付，确实有难度。我可以想办法，再拉上某个资深的 team member 来和我共同完成。

2，下属的认同，需要我合理的管理。

3，领导的认同，是要我去争取的。

主要是还没有真正进入新公司，所以推测的成分比较大。

怎么听怎么就觉得是要开始结对编程了

这样的做法不容乐观。

unit test 的代码是先于 业务代码进行开发还是等业务代码开发完成之后再写？或者并行开发？

unit test 和业务代码之间的耦合应该是比较高的，有两个人来分别完成，除非这两个人有很好的默契，否则很难顺利进行。



呵呵，如果是这样，倒是能保证两个人会有好的默契

敏捷就是tdd吗？
tdd仅仅是敏捷的一小部分而已
单元测试仅仅是敏捷的开始

这种开发我见过
不过不是敏捷开发
测试用例是由测试组写的
程序组只写程序，

那家公司是一家对日外包企业，用的是瀑布开发。

哈哈，还是有差别的。

结对编程实在太猛了，我现在的公司都没有实施（当然，这么说来我现在的公司也许没有100%敏捷），更不指望新公司能做到了。我只希望它能 TDD 就行了。

我前面说的，再拉一个人来一起写 unit test，意思还是说的把 unit test 的工作量分配好，然后分头写。