研发效能 如何拆解任务

刘晓光 · 2020年03月25日 · 最后由 刘晓光 回复于 2020年03月25日 · 3920 次阅读

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

如何理解 “可测试”?

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

如何拆解?

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

这更适合测试只参与一个项目的情况。。。

并不是。适合研发自测承担起大部分质量工作的情况。QA 可以高度并行。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册