神聖不可侵犯的規格書
身為開發人員,我猜你也和我一樣曾有這種經驗… 你拿到一份規格書,依照內容進行開發,程式寫著寫著,過了一陣子之後,發現… 不對啊,這規格書本身很矛盾!? 如果依照前面說的XXX這樣做,那後面的OOO可能會做不下去,如果依照OOO的做法,那用戶顯然以後會很難用唷,反覆來回看了幾次,細細思考之後,你肯定了這份規格書確實有問題。 OK,這時候的你,會怎麼做? 一般我們會有底下三個選項: A: 管它的,依照規格書先做完再說。 B: 找客戶或PM/SA溝通。 C: 用自己的方式直接做出更好的版本。 如果規格書真的是錯的(當然開發人員也可能自己理解錯),那走A顯然是會造成浪費,你非常有可能做出一個看起來十分符合規格但實際上沒法用的軟體,這狀況我們都碰過,而且很常見,所以這邊暫且先不討論。 選C,則在大部份公司是不受歡迎的(你誰啊?竟敢動SA/客戶的規格? 你第一天來的唷?是剛來看不懂規格書嗎? 驗收是照規格書還是照你自己發明的寫法啊? ) 一般來說,你身為Developer擅自改規格是要讓SA/SD/PM怎麼拉下臉去承認自己的規格書有寫錯呢? 況且,規格書若經過了客戶的認可,那你這麼做就是一竿子打翻一條船上的所有人,要一票人去承認自己的思慮不周,而這不周還只有你一個人看的出來!? 如果你選的是B,其實是一件挺累人的事情,你可能會碰到很多挫折,過程中,發現沒甚麼人願意理你,並非所有人都跟你一樣在乎規格的正確性。你慢慢發現,似乎大家都各自幻想著一個完美的最終產出的成品,卻期待著這成品能透過一個千瘡百孔的設計圖來實現。 就算真的能夠開始溝通,你可能也會慢慢認知到,原來溝通一條規格的成本和時間比你想像的高很多很多(但又收不到錢),隨著時程越來越緊,你逐漸開始妥協,在規格書中『刻意保留模糊』,以作為日後驗收時各自表述、各自解讀的籌碼。(搞半天,原來先前規格書中的矛盾就是這麼來的…) 當然,如果規格書不出問題,那上面這些故事場景當然也都不成立,不過…我想你也做過專案,你來告訴我,碰到完美的規格書的機率有多少? 0% 不誇張,就是0%,我從來沒碰過沒寫錯的規格書。 既然規格書那麼不堪用,不如乾脆丟了吧。 所以,曾經有敏捷開發的支持者告訴你,如果想要建構出一個真的可用的軟體產品,與其讓開發人員 只看 規格書,不如多一些和客戶、需求單位之間的 直接頻繁的溝通 。 這就是你會在 敏捷開發價值觀 中看