2018年3月25日 星期日

神聖不可侵犯的規格書

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

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

不對啊,這規格書本身很矛盾!? 如果依照前面說的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專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

沒有留言: