当Tasking作为知识管理手段的时候怎么玩？

我先来说说知识管理这个背景：

我最近有机会跟ThoughtWorks中国区CTO一起搞（学）事情（习），在做一个不一样的培训项目。培训针对的主要也是开发人员的培训，将自动化和知识管理来结合起来提升交付团队的工程效能。

从需求到代码，通过有效地知识管理在团队内部高效传递和共享知识（业务需求和技术架构），并结合自动化工程实践来保证软件的质量。

极限编程提倡的是通过有价值的工程实践来让一群普通的程序员在一起也能够创造出有价值的软件。所以掌握这些敏捷工程实践不应该只是一些高能人事要做的，而是每一个敏捷程序员要做到的，比如自动化测试，团队开发人员应该要熟练掌握的。还有其他的实践，比如TDD、重构、简单设计、结对编程等。

再往上走，Senior开发人员应当需要发挥杠杆作用，借助有效的知识管理手段，来牵引团队的Junior开发人员，使得他们能够快速消费知识，而作为一个团队的TL，掌握这些知识管理手段也是当务之急。

在这个上下文中，知识管理，是指通过高效的方式来创造知识并让这些知识能够被消费掉，从而产生实际价值。

在交付团队中，Tasking是一种有效的知识管理手段，团队的TL或者Senior掌握了较为全面的业务需求和技术架构知识，通过Tasking将这些知识做出合理的分解，分解出由多个容易被估算且能落地的任务组成的任务列表，然后传递给Junior，通过有效地沟通反馈来达成一致理解。随即Junior主要工作是在限定的时间内将这些任务逐个搞定，并引入自动化测试等工程实践达到质量内建。

CTO提出了一个针对Senior开发人员的Tasking二层划分法。当拿到业务需求，首先对业务需求做分解，分解出不同的需求场景，然后结合系统的技术架构和测试策略，分解出具体的技术任务。通过两次划分，将一个业务需求拆分成一个个可以落地执行技术任务，Junior在完成这些技术任务的时候，必须保证自动化测试的落地，TDD也是一种不错的方式。

Tasking二层划分法其实是结合了面向业务需求的Tasking和面向技术实现的Tasking。这两种Tasking视角我之前在一个问题中提到：如何区分Tasking的两种视角?

Tasking是TDD很难落地的一个关键点，Tasking门槛比写测试本身要高得多，而且体现的是一个人分析性思维，在ThoughtWorks，我们把这个能力归到为Senior的基本胜任力。

如果在团队里将Tasking作为知识管理手段有效的解决了TDD中的最难的环节，后面的Test-Driven Development还那么难吗？