敏捷开发真正的重点不是 User Story 的拆分, 而是开发人员的能力

谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度大小的问题。

然而, 事实的真相是如何呢?

首先, 先从敏捷开发实践的本身说起：

敏捷开发之所以强调 “敏捷” , 主要是希望藉由 User Story 的划分 , 能帮助开发人员, 有效的管理版本开发上需求的复杂度, 而使开发人员能在最短的时间内 “发现自身的问题”, “发现自身的不足”, “发现因自身的问题、不足与外部的变化所造成的风险” 。

所以, 敏捷开发的核心基础, 最强调的便是: “User Story 必需要是可测的” 与 “User Story 间的持续集成” 。

接下来再谈一下, 人的思维、人的一念之间是如何严重的扭曲了敏捷开发?!

当一个开发人员, 他 (她) 只是在证明自己“没做错事” 时, 而不是在 “发现自身的问题” 时, 那在拆分User Story 上, 便会发生这些场景:

1.       将 User Story 拆的需 3 周甚至一个月以上才能完成; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “测试的” 。但, 却只是被 “测试人员可测试的” ; 也就是说, 有的开发人员希望将 User Story 要拆的 “够大”, 只是要掩饰自身无法做 “有效” 的 “开发者自动化测试” 罢了。

2.       将 User Story 拆的只需完成单一且极简单的 “功能点”; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “如期交付的” ; 也就是说, 有的开发人员希望要将 User Story 拆的 “够小”, 只是要掩饰自身无法理解与掌握 “完整的业务场景” 与 “软件架构” 罢了。

所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 而是应协助开发人员能诚实的发现与面对自身的不足与所面临的问题, 并给予开发人员适当且必要的赋能与协助。因为, 唯有如此, 开发人员的能力提升了, 则开发人员便自然能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度越高” 的User Story。

所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 我们应该真正专注的是: 如何能使开发人员能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度高” 的 User Story。