---
title: "獲取規格的技巧 - Rails 開發實踐"
date: 2023-07-21T00:00:00+08:00
publishDate: 2023-07-21T00:00:00+08:00
lastmod: 2023-09-03T17:33:12+08:00
tags: ["規格","經驗","心得","Rails","Rails 開發實踐"]
series: "rails-in-practice"
toc: true
permalink: "https://blog.aotoki.me/posts/2023/07/21/rails-in-practice-acquire-specification/"
language: "zh-tw"
---


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

<!--more-->

## 從確認開始{#start-with-confirm}

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

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

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

## 關注當下{#live-in-the-moment}

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

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

## 分級制度{#ranking}

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

這是我在 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 天的資訊，以及初次訂閱和自動續訂的情境。