最近經濟不景氣，我之前服務的單位被解編，我則被編入一個新而年輕的團隊，也不怕讓大家知道，其實就是做大資料（Big Data）的。我想對資訊科技的人有接觸的人應該都知道，這是時下很夯的資訊主題之一，除非經濟再不景氣下去，或在大老闆對此一科技新名詞失去熱度前，我想我應該可以在這個變化多端的組織裡安穩好一陣子。

新團隊相當有活力，至少比起我以前那一個暮氣沉沉的舊單位不知道強幾百倍。我每天都有新的東西要學，包括新的管理作法，也就是接下來要談的主題 － SCRUM。

關於 SCRUM 的做法，其實我並不完全陌生，很早就對其相關的子議題，如：敏捷軟體開發，已有相當程度的了解，但我並沒有太多興趣更深入地去了解它。不是我覺得它不對，事實上，若你有一直不間斷地有親身實地地從事軟體開發並且常常思考如何提高開發效率的問題，一定都會被其所吸引，甚至會說：「我早就說過應該這樣子幹了！」

那麼問題在那裡？

一、我曾經長時間地在３人以下，甚至只有我單獨一人的開發團隊工作，許多團隊開發問題，如：文件與技術溝通等，對我來說是少見甚至是不需要的。就算曾經參加過大型的研發團隊，我也沒遇過專案失敗的經歷，所以感觸並不深。

二、就算我讀了也沒用，這東西不是我說了算。即便我當了個小主管，我也沒辦法說服一些老傢伙加入敏捷開發的實驗，他們就是缺乏改變的熱情。更別說，要去影響老主管、老ＱＡ等等了。

三、雖然與其說法有共識，我需要更堅實的論證，來建立理論基礎，如此就不會被一句簡單的「各地環境不同」就打回來了。

新主管借給我了這一本書：【SCRUM：用一半的時間做兩倍的事】，把第三個問題抹去了，書中作者豐富的專案經驗自不在話下，但他和我一樣，不會自滿於這些豐富實務經驗，更在意各種學術研究證明，不會讓其說法淪為一箱情願地的空談。因為除了商業單位外，作者也曾長時間在學術單位待過，對論文的價值有深刻的了解，可不是那種對論文感冒的三流學者。

而這本書是主管借給我的，我們的團隊也正在做SCRUM管理，而團隊的成員看來也是很信服這道理的。所以，這第二項問題，自然也消瀰了大半，至少一個最大的石頭已經自己搬開了。

而５年在一個大型公司，僵化的制度，失敗專案下工作的我，此時讀起這本書來，更有感觸。

我預備把許多經驗與讀這本書的心得合併起來，做一個論述。

...

嗯～但願我能完成。