談到敏捷開發, 許多人糾結的第一個問題便是: 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。