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