如何實現假設驅動開發(二)

How to Implement Hypothesis-Driven Development

原文：https://www.thoughtworks.com/...

翻譯：祝坤榮(時序)

咱們相信<這個功能>

咱們須要開發什麼功能來測試咱們的假設？經過定義咱們要構建產品或服務的'測試'能力，咱們能夠識別出來要測試的功能和假設。

結果會有<這個輸出>

咱們實驗指望的輸出是？咱們指望構建的'測試'能力獲得的特定結果是？

當<咱們看見一個可度量的信號>咱們會知道咱們成功了

什麼樣的信號能指出咱們作的事生效了？ 咱們度量什麼樣的指標(定性或定量)能夠證實咱們的實驗成功了並們足夠的信心能夠進行到下個階段。

你統計信號的門檻取決於你對正操做的的業務和上下文的理解。不是全部公司都像亞馬遜或谷歌有那樣的用戶規模能夠在很短期內運行處統計樣本的實驗。須要基於你組織的限制來肯定信號證據的閾值什麼時候能夠走向下一步。

好比你想打造一艘火箭，你可能想要你的實驗有個很明顯的統計學特徵。而若是你須要決定在用戶註冊時如何幫助用戶增加則你可能很高興容忍一個很低的統計閾值。

最後一步是清楚可見的表述咱們假設的猜想，創建一個反饋閉環讓團隊提供以後的輸入，討論並理解咱們正在測試的狀況。它們從技術和業務視角是否是有用的？

當你要你的目標是對你的產品或服務願景提供一個可測試的機制時你要進行假設。它們能夠測試你產品或服務的大部分不肯定的地方，以便於提供信息和提高信心。

假設驅動開發的用戶故事例子是：

業務故事

咱們相信在預約頁加大旅館圖片的尺寸
結果會能夠改進用戶的預約和轉化
咱們知道咱們會成功當咱們看見看了旅館圖片的用戶在48小時內的預約會有5%的增加

當在軟件領域使用實驗方法時咱們須要有效的監控和評估工具來度量咱們的工做影響並提供一個反饋閉環給團隊。否則咱們在衡量努力結果時就是瞎的。

在敏捷軟件開發中咱們定義了可工做的軟件就是主要衡量進度的指標。

"經過整合持續交付和假設驅動開發咱們如今能夠定義可工做的軟件和經證明學到的業務知識是進度的主要衡量指標"

正常來說咱們在沒有衡量出交付物的價值時咱們不會說完工了 - 換個說法就是得到了能夠證明咱們假設有效的數據。

收集數據的一個例子就是用A/B測試來測試一個假設並度量用戶行爲的改變。另外一些測試方案也包括用戶調研，紙上原型，用戶和 /或 游擊隊測試。

使用假設驅動開發的公司的一個例子是lastminute.com(http://lastminute.com/)。 團隊造成了一個假設就是用戶有意願付最高價錢給旅館是基於他們預約的時間。 Tom Klein，CEO與Sabre基金的主席分享了一個他們如何在一週內提高了400%轉化的故事(https://www.youtube.com/watch...。

結論

將假設驅動開發與持續交付組合的實踐加速了實驗並加強了有效學習。這給了咱們機會在減小支出，甩開競爭對手時加速咱們的創新。理想狀況下咱們能夠獲得一個總體流程：原子更改可讓咱們肯定對產品和服務的變動與對核心指標產生結果的關係。

就像Kent Beck說的，「測試驅動開發是在考慮解決方案前先考慮問題的偉大實踐」。假設驅動開發提供機會讓你在想解決方案前先測試你想的問題。

---

本文來自祝坤榮(時序)的微信公衆號「麥芽麪包，id「darkjune_think」轉載請註明。

交流Email: zhukunrong@yeah.net