用 6 個思考脈絡 I.N.V.E.S.T,更好有條理地撰寫和檢視文件
前文有提到好的文件是非常重要的
這裡介紹用 I.N.V.E.S.T 這六個點來檢視一份文件的撰寫,是否涵蓋夠多的資訊
Independent 獨立
一個需求文件,當它可以越獨立時,它可以越容易被評估和執行。一個很好的檢視方式是,這些不同需求文件的順序是否是可以被調換的。一個夠獨立的需求文件,應該是可以有彈性被動態調整實作時間和順序。
Negotiable… and Negotiated 保持協調彈性並已協調
一個好的需求文件,應該是可以保持協調彈性的。在文件中詳細描述客戶/用戶對需求的描述( 專注在 What ),並保留空間給後續討論要如果達到這些需求 ( 討論 How 的空間 )
Valuable 有價值的
一個需求文件開出來,它必須是有價值的,這裡並不要求每個人都覺得有價值。它必須對客戶有價值,有時工程師會有提出必要且合理,但也應考量是否對客戶的價值也是一樣重要。
除了從客戶認為有價值來看,還可以從幾個維度來思考:
1. Strategic 有策略價值:如果不做這件事情,我們將隨著時間失去市場優勢。
2. Compliance 合規需要:如果不做這件事情,我們將有可能違反法律。
3. Revenue Generation 可產生獲利:如果不做這件事情,我們將錯失賺取市場利潤的機會。
4. Cost avoidance 避免提高未來成本:如果不做這件事情,我們未來將會付出更多錢。
5. System stability 系統穩定:如果不做這件事情,我們將會曝露在系統不穩定或無法正常提供服務的風險。
Estimatable 可估計的
一個好的文件應該是「可被估計的」,這裡不是要精準的估出幾個人做幾個禮拜,是需要可以拿來和其它需求文件比較和排序的。越大的需求文件,或是越不獨立的需求文件,都將讓估計和衡量變的很困難。
Small 夠小
好的文件應該盡量夠小。通常會用可被完成的時間來衡量,至少是一個人一週內能做完 (甚至更嚴格會是一個人幾天內能做完 )。超過這個範圍,會讓一張需求文件變的很難清楚地完成和測試。例如一個一次需要用一個月來實作的功能。
Testable 可測試的
當開始撰寫一個文件,代表一個承諾:「我非常清楚對於我想提出來的功能或改變,我知道它該被如何檢驗」
多數的團隊都認同,當我在實作之前,就知道一個功能/修改會怎麼樣被測試,團隊可以更精準的交付功能。
“可測試性” 一直以來都是最能衡量一個需求描述好與壞的關鍵。事實上,越早就規劃好如何測試,可以幫助團隊認知這個功能到底有沒有解決問題。
找到更多我的資訊可以到這 mhtsai