目标： 把研发任务拆解为 “可测试” 的交付物。

如何理解 “可测试”？

• 摒弃 “可以做端到端的测试才叫可测试” 的观念。
  • 接口可以测试
  • 方法/函数可以测试
  • 业务需求逻辑可以测试
  • 拆分后，尽量提供可端到端测试的测试物。
    • 这一点和上一点并不矛盾，因为早晚要做端到端的测试。

如何拆解？

• 做好排期
  • 做好排期，是做好拆解的基础。
  • 双周的排期是一个非常合适的排期工作的周期。
  • 对自己团队的交付能力有比较清晰的认识（可以通过过去的迭代总结不断看清楚）
  • 所有干系人参与排期（项目经理，需求，开发，测试，运营），不然对不齐。
  • 留出一定的富余量。
  • 在排期会上，对排期内的任务进行分解，测试和开发人员均应该在场，对任务进行评估。
• 做好可测性分析
  • 一定要达成一个 “可测” 的协议。
• 尽可能的按照业务功能去拆解，而不是按照技术层次去拆解。
  • 如果采用了"用户故事"的方法，按照用户故事去拆分
  • 最好对应一个完整的功能。例如增、删、改、读功能同时具备。
  • 基于功能的垂直式开发模式优先。
  • 拆解的粒度：能够每天交付被测物，是非常理想的状态，如果做不到，可以先从拆解到 2~3 天做起。只要愿意花心思拆解，过一段时间以后，你就会发现，根本不难。
  • 如果功能仍旧过大，不能拆成 2~3 天交付，可以拆解成 “半成品”，如一些接口，一些方法。
• 考虑架构和设计对任务拆分的影响
  • 好的解耦设计才能拆开。反模式：大面积违反迪米特原则。正向案例：面向接口编程
  • 如果联调的成本高，提前考虑 mock。mock 是基础设施，要投入精力建设。
  • 如果可以低成本不 mock，则可以考虑不 mock，这项能力也应该投入精力建设。
  • 架构应该是面向服务的（现代架构基本如此，不要乱搞就行）。