這一章。我們要談談，有了確定的方向後，如何高速執行。
之前我在剛變成程序員時，對於一個網路產品怎麼樣建構出來。我是完全一無所知的。
當時一般比較大的網路公司是這樣做的。所以假設一個產品需要六個月，以下是最常出現的時間線：
- 花了 3 - 4 個月的訪談需求
- 花了 1 個月請美術設計視覺與介面，以及反覆修改
- 最後剩下不到 兩週再請 RD 進場寫程式。
這種開發方式被稱之爲是瀑布式開發。
手段是先蒐集完備規格再開工。
固定每週會開產品會議。項目經理 就會召集開發小組，與程序員在會議室開會，"BrainStorming"。看看 項目經理 整理的到的需求，到底能不能做。
程序員往往對參加這樣的會議會感到很痛苦。因爲現場老是會出現這樣的衝突：
- 項目經理可能這功能覺得很容易，不太費勁。但是程序員覺得這明明很複雜，於是被激怒了
- 項目經理覺得理所當然的功能，但程序員身爲互聯網重度使用者，一看就知道不可行，雙方吵起來
- 程序員一直槍掉項目經理提出的功能的功能，項目經理 覺得程序員不尊重業務專業與創意
瀑布式開發型的項目，整個開發週期當中 80%的時間。往往花在這些會議上，確保產出「完備的規格」。等到規格寫完之後，纔會再把這些規格交給視覺設計師設計介面。
而設計師在設計介面又需要花上幾周，這期間反覆跟項目經理 確認介面流程沒有理解錯誤。而到了開發週期尾聲，才輪到程序員開始接手實做，這時距離上線日剩下兩週時間。
這就是什麼爲什麼多數的網絡產品服務，剛上線時網站都是破破爛爛的。因爲瀑布式開發型項目所有的時間，都被花在策劃跟畫圖。沒有空間讓程序員「好好把功能寫完」。
程序員面對這樣的狀況往往是很崩潰的。
因爲程序員不是不想打造好產品，但是往往這麼龐大的產品架構，卻老是隻留給程序員這麼少的實做時間。
死線已經老早被設定在那裏了，不要說根本沒有時間「寫好」，光是「寫完」都是奢望。就算刪掉一些沒必要在第一版的功能與特效，其實也寫不完。
更何況在跳著寫的情況下，甚至「核心功能」也會不小心「被跳掉」。所以大家很常在看到互聯網上剛上線的服務，一進去就踩到一堆 BUG。不僅團隊自己不滿意，使用者也每天都在抱怨。
這種事當然不是大家樂意見到的。改善的方式，當然是立刻抓緊時間每日加班改善。但是，當把 bug 修得差不多之後，當初來嚐鮮的使用者卻已經走的差不多了。
此時團隊開會檢討原因，檢討歸咎出：第一版缺乏許多市面上的核心功能是最大的問題。
於是再度規劃改版。後續團隊繼續努力了三個月，又奮力推出第二版。但是還不見起色，於是項目宣告 GG。其實這樣的輪迴在網路創業公司，一天到晚都在上演。
然而，這就是絕大多公司內部所謂的開發方式。
這樣的開發方式，其實很像是在豪賭。也是一種 ALL IN 的方式，中間沒辦法轉向。只能將賭注壓在一開始的決定上。
我知道在大陸有些公司，甚至確保要賭贏。變通的方式是：是直接準備了三個團隊一起開跑做同樣一個新產品，哪個隊先寫好就用哪隊的。
大的互聯網公司財大器粗，有本錢可以玩這種拼命式開發的遊戲。
但是創業公司真沒辦法沒辦法，人就那麼多。是不是有什麼改進的方式呢？
我在參與了用瀑布式開發的兩個產品後，開始隱隱約約覺得這件事不太對勁，難道流程就沒辦法變通嗎？
一個項目真的是得收集完所有規格才能寫嗎？不能一邊規劃一邊開發嗎？
於是我找到一個新型態的協做方式：敏捷 Agile。有別於瀑布式開發的作法，敏捷強調適應真實需求的快速變化。
2001年2月，Martin Fowler，Jim Highsmith等17位著名的軟件開發專家齊聚在美國猶他州雪鳥滑雪聖地，舉行了一次敏捷方法發起者和實踐者的聚會。在這次會議上面，他們正式提出了Agile(敏捷開發)這個概念，並共同簽署了《敏捷宣言》。
藉着親自並協助他人進行軟體開發， 我們正致力於發掘更優良的軟體開發方法。 透過這樣的努力，我們已建立以下價值觀：
個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 迴應變化 重於 遵循計劃
也就是說，雖然右側項目有其價值， 但我們更重視左側項目。
我們遵守這些原則：
我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。
竭誠歡迎改變需求，甚至已處開發後期亦然。 敏捷流程掌控變更，以維護客戶的競爭優勢。
經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔爲佳。
業務人員與開發者必須在專案全程中天天一起工作。
以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。
面對面的溝通，是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
可用的軟體是最主要的進度量測方法。
敏捷程序提倡可持續的開發。
贊助者，開發者及使用者應當能不斷地維持穩定的步調。
持續追求優越的技術與優良的設計，以強化敏捷性。
精簡──或最大化未完成工作量之技藝──是不可或缺的。
最佳的架構，需求與設計皆來自於能自我組織的團隊。
團隊定期自省如何更有效率，並據之適當地調整與修正自己的行爲。
敏捷式開發的項目有幾個特點：
- 將軟件切分爲不同版本，逐步開發。而非一次性討論與開發終局版本。
- 捨棄厚重的規格，每個開發循環版本里面，只實在當版本能夠對客戶有價值的功能
- 保持對計畫的靈活性，若發現原始方向不對，立刻擁抱變化。
- 每日溝通與測試修正，讓非開發人員也高度參與開發過程，確保交付出正確的軟件
- 利用流程與代碼，記載軟件需求，而非撰寫厚厚文件。
聽起來很模糊。我在這裏白話翻譯一下。敏捷開發不寫規格，作法是圍繞著項目的核心價值開發功能。每週檢討實做結果，並且調整方向。採用版本釋出的方式，逐漸完善整個產品。
特別適合小團隊採用。
當然，一般人聽到「不寫規格」這件事。會覺得很恐怖。不寫規格，我們要怎麼樣協作呢？這樣不是會出溝通上的差錯嗎？
其實，敏捷開發並非不寫規格。只是規劃項目的角度，與實做方式，跟傳統的很不一樣？
在敏捷開發中，是用另外一種方式「User Story」用戶故事。去溝通協作一個項目裏面應該被實做的細項。
瀑布式開發典型的流程是 項目經理 花上很多的時間進行訪談寫成規格，程序員再根據規格開發「轉換」成功能。不過在這段過程當中，卻容易出現相當大的溝通落差與實做風險。
這當中的差距在於所謂「規格」，往往強調於「畫面的細節」或者是「功能的實現」，有時候疊著疊著，雙方都忘記原本爲什麼這個功能要出現。很可能功能寫出來了，卻沒有幫忙使用者完成任何有價值的工作。或者是功能根本就寫錯方向。
軟件開發的目的應該是讓「使用者能夠在系統上完成有價值的事」。
既然如此，我們應該回歸本質。
User Story 就是一種新的敘述文版，強調透過簡單的語境，具體的描述出軟體在「使用者」的手上，是怎麼樣被「操作」的。透過一個一個使用場景，整理出會在這個系統裏面出現的「角色」以及「會完成的工作與價值」。
舉例來說，User Story 的範本如下：
作爲一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。
這裏是一些 User Stories 的範例
- 使用者可以在網站上張貼履歷，以達到履歷曝光的效果
- 使用者可以搜尋有哪些工作，以提升檢索效率
- 公司可以張貼新工作，以曝光職缺
- 使用者可以限制誰可以看到他的履歷，以避免被前東家發現要跳槽
有一些剛開始使用「用戶故事」的朋友，可能會懷疑這樣的規劃「太過簡陋」。
其實不然，一個網站的實做價值與「主要功能」，大概用 10-20 條用戶故事就可以敘述完畢了。
我認爲敏捷開發與瀑布開發，兩者最大的不同，是敏捷式開發體悟到世界上的項目是活的，且是不斷演化的。而產品開發的重點在於必須產出真正有價值有意義的結果。
User Story 撰寫是以角色作爲劃分：身爲「什麼角色」，我要「做什麼事情」。
在瀑布式開發流程中，很多時後代碼會寫不完是因爲「裏面有隱藏的角色」，比如說
假設我們這個項目，是一個博客平臺。而規格有個需求是博客應該「要有後臺管理介面」。
讓我們拆解一下這個需求：
「這個後臺管理介面」，背後就隱藏著「一個後臺管理員的角色」，加入這個角色所需要做的動作開發量幾乎就是 2 倍！（因爲後臺管理員可以在後臺管理編輯所有文章，幾乎等於要重寫類似文章發表編輯的功能，只是在另外一個「管理後臺」）
假設我們這個項目，是一個網路電商平臺。而規格有個需求是電商平臺應該要有「對帳後臺」
讓我們拆解一下這個需求：
「對帳後臺」，背後就隱藏著「一個會計角色」，而加入這個角色所需要的額外開發量幾乎是難以估計。因爲對帳需求真是千奇百怪。
爲什麼多數的瀑布式開發，項目爲什麼做不完。很大的原因就是因爲，都是做到最後，才臨時在某個畫面或者工程細節裏面，發現竟然隱藏超大量的技術細節要實現。所以工作量才暴增。
透過先寫 User Story 的方式，我們可以提早把這個項目裏面「有多少角色」以及「有多少要完成的事」在紙上迭代，先估算出來。甚至把暫時把「不重要角色」要做的事先屏蔽掉。
完全可以光用幾張 A4紙，就能將第一版工作量的粗估出來。後續再依項目時程人力，工作量與優先權刪減迭代。
- 哪些是在頭幾個禮拜就要先實做的，否則會阻擋後面開發
- 有哪些功能是可以在上線前再添加。甚至是上線後再做也不遲。
- 哪些功能是完全沒必要存在
這些功能將在一個一個迭代循環之中，被實做或被捨棄
我開始改用 User Story 這個方式規劃軟件項目後。項目的平均工時，幾乎減少了 2/3。從六個月降到兩個月。
User Story 的核心規劃有幾個重點：
- 在紙上預先迭代工作量
- 每個版本都是「相對性的完整版」
- 實際的細節份量，可以針對版本的不同以及人力的分配去遞增。
以下我以 OTCBTC 作爲例子，示範怎麼拆 User Story
（第一版的 User Story 可以不用很複雜）
- 使用者可以在網站上張貼廣告賣幣
- 使用者可以在網站上張貼廣告買幣
- 使用者可以在網站上看到廣告下單買幣
- 使用者可以在網站上看到廣告下單賣幣
（我們發現其實這兩個流程是重複的，爲了避免前期開發太過複雜，因此決定先做發廣告賣幣，下單買幣）
- 身爲一個商家，我要能夠在後臺上架賣幣廣告，並且設定上架販賣
- 身爲一個消費者，我要能夠在前臺看到廣告，並且下單購買
（這時候明確引入角色）
（把隱藏的前期細節加入）
- 身爲一個商家，我要能夠在後臺上架賣幣廣告，並且設定上架販賣
- 使用者必須要充值數字幣進來，有足夠的餘額，才能夠上架廣告
- 身爲一個消費者，我要能夠在前臺看到廣告，並且下單購買
- 使用者必須經過身分認證，才能使用下單購買功能
（將隱藏的功能梳理出來，變成主要大功能）
- 身爲一個商家，我要能夠在後臺上架賣幣廣告，並且設定上架販賣
- 身爲一個消費者，我要能夠在前臺看到廣告，並且下單購買
- 身爲一個使用者，必須在站上擁有數字貨幣錢包，進行充值 / 提幣
- 身爲一個使用者，必須經過身份驗證功能，才能使用完整功能
- 身爲一個使用者，爲了確保資產安全，必須綁定聯繫方式
（這個時候，把主要的 Must Have 找出來）
（展開主要大功能，繼續展開 Must Have 裏面的細節）
- 身爲一個商家，我要能夠在後臺上架賣幣廣告，並且設定上架販賣
- 身爲一個賣家，可以在管理後臺上架廣告
- 身爲一個賣家，可以在發佈廣告時調整價格
- 身爲一個賣家，廣告錨定的應該是全球 BTC 行情均價
- 身爲一個賣家，可以在買幣者下單後，與賣家溝通進行交易
- 身爲一個賣家，可以在買幣者付完錢打款後，釋放數字貨幣給對方
- 身爲一個賣家，可以在買幣者下單後，收到通知後，立即處理訂單
- 身爲一個消費者，我要能夠在前臺看到廣告，並且下單購買
- 身爲一個消費者，可以在前臺看到下單廣告列表
- 身爲一個消費者，可以在前臺看到廣告內容詳情
- 身爲一個消費者，可以在下單後，與賣家溝通進行交易
- 身爲一個消費者，下單之後，賣家數字幣必須進行鎖定，確保交易安全
- 身爲一個使用者，必須在站上擁有數字貨幣錢包，進行充值 / 提幣
- 身爲一個使用者，可以申請一個錢包 (BTC/ETH)
- 身爲一個使用者，申請錢包後，可以拿到一個數字錢包地址
- 身爲一個使用者，可以充值到錢包地址（6個確認後到帳）
- 身爲一個使用者，可以發起提幣
- 身爲一個使用者，必須經過身份驗證功能，才能使用完整功能
- 身爲一個使用者，必須通過 email 驗證
- 身爲一個使用者，必須通過 實名 驗證（身份證）
- 身爲一個使用者，必須通過 進階 驗證（銀行卡）
- 身爲一個使用者，爲了確保資產安全，必須綁定聯繫方式
- 身爲一個使用者，必須通過 email 驗證
- 身爲一個使用者，必須綁定二步驗證
一般來說。User Story 寫到第五版。大致上的骨架就會出來。
- 大骨架在完稿時大概會是 20 條上下的主要框架
- 中骨架是在大骨架下繼續展開的 Must Have 功能，展開後大概會有 100 條。
- 這 100 條裏面有更小的細節，最後擴展會最終會達到大至上 1000 條左右的規模。
我們會在大骨架完稿後，先做一版流程圖，確定業務邏輯方向不會被這些細節衝散。
主動現確立後。團隊的主程，在開發時，並不會優先實做各個畫面的細節。
而是會直接把每一個大的 User Story 的畫面骨幹，先開發出來，串成一個完整的 Workflow。然後團隊再以"重構"的方式，去補完每個畫面的細節。
重構式開發的好處。
在於在第一週動工時，就有一個非常粗糙的 1.0 版本。能讓整個團隊成員知道目前系統有多少條確定的「閉環功能主線」，骨架非常明確，有了明確的工作方向以及工作量預估。
接著整個團隊就能夠以「重構每個功能畫面」爲目標去前進。
- 程序員可以專注完善該功能的細節
- 美術設計可以專注設計該功能的畫面
達到平行開發的目的，兩者可以各自完工後再整合，加速整個開發流程的速度
當時決定做 OTCBTC 時，就已經決定要打閃電式戰爭。
目標是得在 11/01 前上線 OTCBTC。我們是在 9/22 立項。也就是剩下不到 40 天的時間。
但是雖說如此。我們還是很樂觀。畢竟此前我們做 ico 平臺時，就有了區塊鏈錢包系統的積累。所以覺得這個項目開發難度並沒有想像中的大。
但第一週開始開始寫主架構時，我們才發現糟了。。。。。爲什麼呢？因爲 OTCBTC 本質上是在做區塊鏈版的淘寶（市集） + 阿里旺旺（買賣家即時溝通工具）。
如果真的要完整上線，必須要做的功能有
- 賣家可以在上面發廣告，買家可以在上面下單購買
- 買家可以在上面發廣告，賣家可以在上面下單收購
- 必須支持 BTC / ETH 雙幣種
- 必須支持簡體與繁體語系
我們當場就蒙逼了。
我們原本以爲只要蓋一個平臺，讓賣家刊登賣幣的廣告，讓人家來買幣就行了。
但是經過使用者訪談後，它們不這麼認爲，強調完整版一定要有雙向廣告。
要知道，這樣系統裏面就有兩種角色。
- 發廣告的賣方
- 發廣告的買方
而系統每多一個角色，工作量就多一倍。多加一個幣種也是多一倍工作量，這當中的架構線圖，甚至是在第一版複雜到搭不出來的。同事都崩潰了不知道如何動工。
到最後怎麼解決的？
「騙」字訣！
我哄著大家，這樣吧！我們上線第一版求上線就行。有事我擔。第一版，只做：
- 只做賣家廣告
- 只支持 BTC
- 只支持簡體版
大家聽了覺得這個進度應該勉強做的完，而且架構圖也蓋的出來（一樣也是用重構式開發），就衝刺看看。
真的兩週就把這個架構寫得差不多了....
於是我厚臉皮的說，既然賣家廣告線已經做完了。那我們反過來加買家廣告要花多久時間？
同事說三天。於是我們花了三天把這個功能疊上去了。
寫完之後測了一兩天，確認主流程都差不多了。我繼續厚著臉皮問，既然 BTC 都做完了，那支持 ETH 要花多久時間？
得到大概只是加一個下拉選單，以及修正部分顯示的功夫，兩天差不多。於是這時候確定上線時會有雙幣種了。（業界當時只有 BTC 場外工具）
時間還剩下兩週多。我繼續厚臉皮的問，我們可以支持繁體版嗎？....
雖然我又收到很大的白眼。但是我們發現做繁體版在當時已經沒有想像中的難了。
因爲當時我們系統裏面絕大多數流程與顯示字串，幾乎已經完全固定下來了。繁體與簡體的轉換也不難。更何況，也不是每一頁每一個字都需要在上線前搞齊繁體翻譯。
於是我們就用這種「詭異的迭代法」，在短短二十幾天，嘩啦嘩啦的把第一版 OTCBTC 「逼」出來了。
這種開發速度，在業界看起來是不可能的任務。
但卻不是我們團隊第一次挑戰這類型的難題，我們前一個項目 ico.info，開發的時間略久一些，大概 45 天（第一次做區塊鏈服務，花了比較久的時間）。用的也是類似的工法。
這當中的祕訣就在於：
- 控制難度，控制角色複雜度
- 非常早期找出真正有價值的功能，其餘儘量捨棄或變通
- 點出地圖上的終點，讓團隊第一時間都知道最終要蓋出什麼
- 平行開發，沒有誰擋誰的進度
我們在開發時用的方法，都不是特別複雜的方法，只是特別耐煩的一再一再迭代重構。
各位讀者如果眼睛比較細，會注意到本章當中略掉了一些細節。這麼複雜的系統，不可能就是寫完 15 條用戶故事然後自由開打吧？如果真是這樣，開發現場會亂得沒法形容。
是的。我們在開發過程當中，還用了其他工具加速團隊協做。第一版的 OTCBTC，完成的小故事/功能，高達 600 條。
在後面的章節，我們會繼續分享，我們是藉助怎麼樣的工具和流程，展開以及收斂用戶故事，達到快速上線的效果的。