獲取規格的技巧 - Rails 開發實踐

我們在工作的過程中大多是以需求（Requirement）當基準來進行開發的，然而要盡可能的接近規格（Specification）就需要多花一些力氣。大多數人其實下意識的都有實行這個動作，因為透過大量的溝通還是可以取得足夠的資訊，然而這樣做的效率跟成功率不一定足夠。

從確認開始

在開始之前，你會怎麼確認「會員制訂閱功能」這樣的需求應該如何實現呢？接下來我們會以這個還算常見的功能作為例子，一步步從獲取規格到實現來做為這系列的主軸。

大多數情況，我們會跟需求提供者進行確認，像是「訂閱的週期是什麼？」「需要動態的調整方案嗎？」等等，這些都可以取得一些情報，然而不一定是足夠精確的，我們可能會得到像是「未來可能會以年費方式收費」「以後可能會有新的方案」之類的回覆，但這並無法幫我們確定如何開發。

正因如此，我們通常會套用一些常見的設計來應用到這個功能，最後反而總是處於一種「好像沒問題，但又有點不好修改」的窘境之中。

關注當下

實際上，獲取規格的前提還是以關注現在的狀況為主。實際上我們對未來有再多的預測，也無法保證能夠適應所有問題，敏捷開發（Agile，也可翻譯為適應）就是為此存在的。

我們需要思考的是，當下這個需求如何在最少的調整符合需求，剩下的問題則是架構上的議題，因此如何在未來需求出現變化的時候，保有足夠的修改彈性，就需要搭建良好的架構，這部分以 Clean Architecture 最廣為人知，我們也會在後續的實作中放入一些這樣的觀念。

分級制度

確立規格的過程中不是一次性的，我們會反覆的進行確認跟篩選，因此我將這種技巧稱之為分級制度。

這是我在 2022 年為期一週的 LeSS in Action 工作坊所學到的技巧，我們將一個功能進行細化（Detaling）的過程，會分成概要（General）、範圍（Scope）、假設（Assumption）與關鍵案例（Key Examples）四個項目，雖然沒有限定要依序處理，然而我認為依序思考是個很不錯的方式。

General 其實就是這個功能的描述，其實就是需求本身，因此我們可能會用「提供訂閱會員特殊權限的功能」這樣的方式去描述，但這樣的資訊太過缺乏，我們需要更近一步的分析。

Scope 會開始嘗試限縮這些問題，他可能在未來被改變也可能當下無法訂出任何限制都有可能，因此我們可能會從需求提供者得到「只有每月扣款，每次延展 30 天」之類的資訊，至少我們可以在初期不考慮月份長度、年度訂閱之類的問題。

Assumption 是不確定的部分，如果被確認了就會變成 Scope 的一部分，這也是為什麼我們需要來回的確認，因為只有像這樣子不斷的限縮範圍，才能將需求提供者跟我們的認知對齊，得到一個接近的結果。

Key Examples 是相當重要的一步，我們可以想像他是一個 User Story（使用者故事）的片段，這些片段會「互相約束」來把規格明確的定義下來，當我們獲取必要資訊後，要能夠寫出像是「當蒼時在 2023-01-01 初次訂閱後，會看到 2023-01-30 過期的訊息」以及「假設蒼時在 2023-01-01 訂閱過期，自動續訂後會看到 2023-01-30 過期的訊息」這樣的舉例，這些例子剛好提示了延展 30 天的資訊，以及初次訂閱和自動續訂的情境。