神聖不可侵犯的規格書

身為開發人員，我猜你也和我一樣曾有這種經驗…

你拿到一份規格書，依照內容進行開發，程式寫著寫著，過了一陣子之後，發現…

不對啊，這規格書本身很矛盾!? 如果依照前面說的XXX這樣做，那後面的OOO可能會做不下去，如果依照OOO的做法，那用戶顯然以後會很難用唷，反覆來回看了幾次，細細思考之後，你肯定了這份規格書確實有問題。

OK，這時候的你，會怎麼做? 一般我們會有底下三個選項:

A: 管它的，依照規格書先做完再說。
B: 找客戶或PM/SA溝通。
C: 用自己的方式直接做出更好的版本。

如果規格書真的是錯的(當然開發人員也可能自己理解錯)，那走A顯然是會造成浪費，你非常有可能做出一個看起來十分符合規格但實際上沒法用的軟體，這狀況我們都碰過，而且很常見，所以這邊暫且先不討論。

選C，則在大部份公司是不受歡迎的(你誰啊?竟敢動SA/客戶的規格? 你第一天來的唷?是剛來看不懂規格書嗎? 驗收是照規格書還是照你自己發明的寫法啊? )

一般來說，你身為Developer擅自改規格是要讓SA/SD/PM怎麼拉下臉去承認自己的規格書有寫錯呢? 況且，規格書若經過了客戶的認可，那你這麼做就是一竿子打翻一條船上的所有人，要一票人去承認自己的思慮不周，而這不周還只有你一個人看的出來!?

如果你選的是B，其實是一件挺累人的事情，你可能會碰到很多挫折，過程中，發現沒甚麼人願意理你，並非所有人都跟你一樣在乎規格的正確性。你慢慢發現，似乎大家都各自幻想著一個完美的最終產出的成品，卻期待著這成品能透過一個千瘡百孔的設計圖來實現。

就算真的能夠開始溝通，你可能也會慢慢認知到，原來溝通一條規格的成本和時間比你想像的高很多很多(但又收不到錢)，隨著時程越來越緊，你逐漸開始妥協，在規格書中『刻意保留模糊』，以作為日後驗收時各自表述、各自解讀的籌碼。(搞半天，原來先前規格書中的矛盾就是這麼來的…)

當然，如果規格書不出問題，那上面這些故事場景當然也都不成立，不過…我想你也做過專案，你來告訴我，碰到完美的規格書的機率有多少?

0%

不誇張，就是0%，我從來沒碰過沒寫錯的規格書。

既然規格書那麼不堪用，不如乾脆丟了吧。

所以，曾經有敏捷開發的支持者告訴你，如果想要建構出一個真的可用的軟體產品，與其讓開發人員只看規格書，不如多一些和客戶、需求單位之間的直接頻繁的溝通。

這就是你會在敏捷開發價值觀中看到底下這四條的原因:

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
 回應變化 重於 遵循計劃  

但，溝通容易嗎? 難啊。

大部分的開發人員以宅宅的身分進入0與1的數位世界，就是為了避開煩悶瑣碎的人際談判和所謂的溝通協調，把全然沒有經過溝通訓練的Developer直接拉回客戶的會議室真的是一件好事嗎? 我也不這麼認為。

所以，不可信任的規格書在這個需求變化萬千和迅速迭代的時代，有沒有被淘汰? 很抱歉，沒有，它萬壽無疆的很。

常常有對敏捷很好奇的企業或團體，請我們去介紹敏捷開發時，我偶而玩心一起，會問問學員，你覺得規格書值得信任嗎? 底下坐著SA/PM/Developer和老闆，這問題很難回答。

如果它無法被信任，你為何總是照著規格書寫程式呢? 如果它這麼值得信任，那為何照著規格書做的軟體還是常常無法順利結案呢?

Trade Off ，是你在導入敏捷時可能需要常常放在心裡的字眼，事事無絕對，Guidelines不是聖旨。

彼得杜拉克講過一句很殺的話：『管理是一種實踐，其本質不在於“知”而在於“行”；其驗證不在於邏輯，而在於成果…』

敏捷也是。

-----------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM
若這篇文章對您有所幫助，請點選這裡加入FaceBook專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。