前言

體外話：

從拿到書到現在，雖然看完了但還沒有時間認真的把它在重新看一遍（敏捷開發看似簡單但是很多細節還是需要花時間思考）。不過看了還是有些心得的。感謝點部落送的書，而我拖到這麼晚才開始把之前的記錄做整理髮出來，也感覺滿不好意思。

需要先說的是文章裡面很多都是我的感悟，或許有不成熟或者有錯誤，都歡迎批評指教。

學習一個新的東西最重要就是概念，如果概念正確了，如何去做就是日積月累的培養。因此這一篇我想記錄下我對於敏捷開發的概念。

什麼是敏捷開發

敏捷開發其實從滿早就開始了，而它是一種概念，一种放到任何事物都能使用的概念，只不過有人推動並且歸納出一些適合軟體開發的流程和方法。回歸原始，敏捷開發和任何開發流程一樣，最終目的是開發出一個客戶需要、滿意並且好用的軟體。

客戶會找我們來開發程式原因很簡單，因為市面上的程式不符合他們的需求，如果符合就直接用就好了，哪還需要在開發。而就因為市面上沒有他們需要的，所以有的時候客戶自己都不知道他要的是什麼。他們或許會「以為」他們要的是xxx，但實際上你做出來了，他才發覺這個不是他要的，他要的是yyy，這些其實都是開發軟體常遇到的問題之一。

剛剛提到的問題要如何解決？很簡單，我們對於看不到的東西很難去下判斷（例如假設要你估計一個工作會花多久），但是我們很擅長比較。例如，我要估計一個工作要做多久，最好和最準的方式就是從經驗裡面找一個做過的和他性質差不多的工作所花的時間以此為基準去做判斷。同理，當客戶要做一個軟件，他或許有個模糊概念要的是什麼，我們就先以那個為基準，把工作量切開，儘量在2-4個禮拜就有一個可以看到的東西，這樣當客戶看到實物，他才好判斷到底有沒有那裡做錯了。

這就是敏捷開發的精髓，每一個時段都有一個「東西」可以讓客戶看到，讓他知道進度和目前的情況，同時可以讓他看到是否朝著他要的方向前進。

之前在網路上看到一篇文章主要內容是在說新入職場的人常犯的一些錯。其中有一條提到不要把事情做到快好了再給上級看，寧願做50%讓他先看一下方向是否正確，好過花了很多時間做出100%在來給他看，然後在發現其實他要的不是這樣，你可能理解錯誤了。完全等於花了時間做白工。

生活例子瞭解敏捷開發的重要性

我這邊舉的例子不會完全和敏捷開發一樣，不過精神概念我覺的是差不多的。

之前不是才發生過颱風，而有部份地區淹水很嚴重但是停班停課的消息滿晚才發佈的，造成很多人的不便。如果我們思考一下就可以想出為什麼。（請勿把下面的例子和任何真實事件對應，因為我這邊只是要舉個流程的例子。）

在颱風前一天的氣象報告通常會依照當天的衛星雲圖來去推算明天是否需要停班停課。因此通常來說消息會在晚間就出爐。問題來了，判斷是否要停班停課是依照 當下的資料而做出判斷，你如何保證明天真的就是這樣走呢？只有在當天發生過的事情才能作出準確的判斷是否需要停班停課。因此，當隔天來臨的時候，依據實際的降雨量，各縣市可以作出是否要停班停課。

這和敏捷開發一樣，我們先依照客戶的需求（前天的衛星雲圖）做出一個判斷他要的軟件是什麼（是否要停班停課）。但是當我們實際在執行的時候，我們需要讓他持續的參與（觀察當下的下雨量）來確保這個是他要的（做出正確是否要停班停課的決定）。如果我們沒有讓他們持續參與，等到結果出來，可能是他們要的（和昨天天氣預報結果一致；當然皆大歡喜），也有可能不是他們要的（外面都下大雨了怎麼還不停班停課？怨聲載道）。

結論

敏捷開發的精神可以用在很多生活的事物上面。而其最終的本意：

1. 要讓客戶滿意
2. 而讓客戶滿意就要他們持續的參與專案
3. 參與專案就需要有能夠看到的雛形
4. 只有看到實物，嘗試使用，客戶才能夠知道這個是不是他們要的。
5. 也只有方向正確，最終結果客戶才會滿意。

最後，敏捷開發說簡單也簡單（概念就那些而已），但是說難也難，因為要真的跑敏捷需要的是大家都有這個共識。而這不只是開發者而已，只要和系統有關的人員都需要有這些共識。好處也是可以看見的，只有作出客戶要的，客戶才會滿意，客戶滿意了，公司才會賺錢，公司賺錢了，開發者才會有好的薪水。畢竟薪水就是公司能夠留下你的最低支出成本。只有公司賺錢了才有可能給你提升。