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

理想和现实只一步之隔也可能是千里之遥。

唉，我们公司还在用瀑布方式，也没有单元测试。

TDD只是敏捷的一部分，要想全面引入敏捷，需要团队的学习，实践
，从TDD开始不失为常见的途径。只要能够快速上手，给我们的开发带来好处就好。
初次TDD都会觉得多写了代码，工作两增加了，其实不然！
以往的方式是直接部署然后测试，有问题再修改，再部署，再测试时，直到结束。部署花费运行花费的成本是很高的，只是由于把集成测试和单元测试粘合在一起，感觉不出来花费了多少成本。
可以用一个完整的实例开发过程来让大家意识到TDD的好，大家才会愉快的接受它。

觉得不是很好，我想 开发人员自己写测试用例也是帮助他自己了解需求，你写来的测试用例完全对开发人员了解需求没有任何帮助，所以我觉得这种方法不是很好

什么是敏捷?我个人认为,能够用最短的时间开发出质量高的产品,这样的方法就是敏捷?所以其实只要能够满足上面的要求就是敏捷的.敏捷应该是按照产品的需求来定的,而不是说用了TDD就敏捷,用了什么就敏捷.--以上都是我个人见解,不妥之处往大家批评指正.

先抛开空降兵，什么是敏捷等问题不说。
就说TDD在一个从未TDD过的团队中如何实施并开展吧，首先，你得让老板和程序员从心理上、观念上接受TDD，然后再想如何实施TDD。
即先做思想教育，再做实际工作，否则抵抗是难免的。

unit test应该是写被测试代码的人（或者pair）来写的，自己的代码自己测试。
否则，当测试出现错误的时候，到底是test case写错了还是被测试代码有错？谁去负责检查？谁对错误负责？