[Agile/scrum] 擁抱改變
真害羞，動不動就擁抱。 但是在做軟體的時候，很難不改變的。先來說說傳統瀑布式開發的做法。 Waterfall 在傳統的瀑布式開發法，一個專案會被切成需求分析、設計、開發、測試，有時候 前面還會加個cooking，後面測試又還有phase 1、phase 2等等，假設一開始，kickoff的時候，專案被估計是一年，可是最後總是會、常常會發現專案delay了，為什麼？大家指來指去，都怪他他他，所以delay了。 面對delay這件事，PMP會教："抓buffer"，於是一個stage就抓一個buffer，怎麼抓？怎麼決定buffer要抓多久？ "猜" 多感傷阿，一群受了這麼多教育的人，面對問題還是在猜。 Root cause 抓Buffer是一個消極的解法，真的的解法是找出問題，去解決、或至少面對真正的root cause。而真正的root cause是：需求改變了。 承認吧！在開發時程中，需求總是會改變，不知道為什麼，反正他就是會變，假如有公司有軟體專案開始到結案，需求都沒有改，那這間公司已經倒了。 Deal with it !!! 面對需求的改變，通常有兩種做法： 1. 用合約、spec來不讓改變發生 需求改變的時候，會發生三種現象： 業務端會去跟客戶吵，"大家把合約攤開來看阿" QA/RD/designer/architecturer也會去吵，"大家把spec拿出來看阿" PM會被狗幹 整個團隊陷入一種不和諧的狀態，與客戶的關係也不會太好，在這樣的情況下，基本上，所有人都是抗拒的、不愉快的，要在這樣的情況下做出好的軟體無異是緣木求魚。 於 是，有人會說，一開始就要想得好一點、想得透徹一點，一切都想好，把所有變數都考慮進去，就妥當了。但這不是火鳳燎原，這種八奇是不存在的，就算有，他也 在google、facebook等等大公司上班了，不會龜在你的公司。相信我，假如在軟體專案裡面有人說，所有的事情我之前都想到了， ...