我经常在TDD训练营中被问到Tasking的粒度如何把控？
首先，如果是面向问题域的Tasking，即对业务需求的拆解，标准答案当然是：将所有的需求场景都考虑到。你没看错，是要将所有的需求场景都分析到。你可能会有新的问题：“我怎么知道我涵盖了所有的需求场景。” 这就需要你去跟业务人员沟通确认......等等，好像跑题了！
回到Tasking要拆到什么粒度？这个问题，也还是一个How层面的问题，同样还是需要去思考你做Tasking的目的是什么？今天一起来聊聊以下几个目的：
- 梳理业务需求，理解问题
- 拆分解决方案， 便于估算
- 发展新人，尽早反馈
梳理业务需求，理解问题
此时你是为了让自己看清楚需求，当然要将所有你能识别出的场景列出来，这里面要特别留意一些边界的场景，比如以下需求：
1. 商品的价值永远不会小于0，也永远不会超过50
2. 后台门票（Backstage pass）和陈年干酪（Aged Brie）有相似之处：
- 越接近演出日，商品的价值反而上升
- 在演出前10天，价值每天上升2点
- 演出前5天，价值每天上升3点
- 一旦过了演出日，价值就马上变成0
上述需求的后台门票，注意有几个边界条件（不同场景的分界线），保质期是10，5，0，另外价值0，50，这几个边界场景，所以组合下来，会有：
- 保质期是10以上，价值0< quality <50以内
- 保质期是10以上，价值quality = 50
- 保质期是5 ~ 10，价值0 < quality < 49
- 保质期是5 ~ 10，价值quality = 49
- 保质期是1 ~ 5，价值0 < quality < 48
- 保质期是1 ~ 5，价值48
- 保质期是0，价值0< quality <50
当有多种边界值的，基本上是业务需求的边界值组合下来的结果。不管是复杂的还是简单的业务需求，只要是明确的业务需求，都会有它的边界条件，识别边界条件是一个很好的切入口。
以上是场景归类描述法，作为初学者，我建议你进一步对每种场景做一些实例化，比如代表该场景的具体数值，如果你能够针对每种场景给出不同的具体实例，代表你已经理解了这种场景，但反过来就不一定了。这就好比，一些面试者，可以将敏捷是什么以及业界已经存在的敏捷实践说得条条是道，而当你问他Clean Code会议和Spike是不是敏捷实践的时候，他不一定能回答出来，这需要对敏捷的价值观和原则有深刻的理解。
拆分解决方案， 便于估算
通过对业务需求的拆分，当然推荐进行一轮沟通确认。搞清楚了问题，你可能还不知道实现第一个场景大概需要多少工作量。此时，你可能要提前去思考实现第一个场景要做哪些事情了，把过程拆小，这样有助于你评估每一步的工作量。
比如，你要用乐高拼一栋四合院，你不知道要用多久，你可以进行拆分，东、南、西、北四个小院，如果还是不清楚，继续往细粒度拆解，拆到什么程度呢？也不是越细越好，拆到你能够自信的估算出工作量就好。
发展新人，尽早反馈
团队来了新人给你带，但你又不能做到事无巨细的去跟进，怎么办？教会新人做Tasking是一种有效地方式，让新人锻炼以上两种思维习惯和工作习惯，在方向上给出明确的指引，在前期提出反馈，避免其偏离大方向。解放自己的同时，也给新人更多的空间。而一旦彼此熟练了这种方式，沟通效率也会倍增。当然，前期要投入必要的时间去辅导。
要做一个靠谱的程序员，清楚定义问题 + 有效地估算 + 有信誉的承诺，这些是值得去追求的。
155-2731-8020