是的，你沒有聽錯，我說的確實是「慢」，但如果敏捷關注的是慢，我為什麼還要用敏捷呢？ 要解答這個問題，首先需要回答，為什麼你需要「快」。
客戶需要軟體，是因為要獲取某些價值或者利益，而這些價值當然是越早獲得越好，特別是在有競爭對手的情況下，「慢」就意味著價值的流失，甚至無法得到價值。正是因為這個原因，通常我們就會追求「快」，以便滿足客戶的要求。敏捷在某些方面確實迎合了這種需求，它比傳統方法能夠更快的提供可工作的軟體，從而為客戶更快的提供價值，並通過快速的反饋和有效的溝通提高開發效率。
但是，再經過了幾個專案的開發，以及在網上看到很多人的觀點之後，我發現有不少人認為這種「快」是通過專案進度快，或者寫**快而產生的。這就導致了客戶或者開發人員認為，敏捷應該能更快速的產生**，更快速的完成專案。因此在敏捷專案中，如果不能比傳統的方式更快的生產**和實現需求，客戶就會不滿意，專案經理就會坐立不安。在這種環境下，開發人員也很容易受到影響，想當然的認為敏捷就是不寫文件、快速的寫**、快速的交付。 事實上，這是完全不對的。
從敏捷實踐來看，tdd，重構，持續整合……都要消耗更多的時間，甚至迭代本身也比瀑布模型有更高的成本。pair programming是乙個非常好的例子，很多人一開始接觸時，不免都會有「這會浪費乙個人，降低一半生產效率」的想法。實際上不管我們如何說這不是浪費，但如果單單從寫**的速度來看，pair的生產率確實要比分開寫更低，雖然不會低到一半，但也絕對不會更快。種種跡象都表明，敏捷開發是要更慢的，但這種慢是值得的。
如果從乙個客戶的角度來看軟體，客戶對於軟體的投資可以分為開發成本、維護成本和執行成本。開發成本指的是專案開發過程中需要付出的成本，維護成本是指在軟體上線後，對其進行新增功能，修改功能的成本；執行成本則包括執行軟體所需要的軟硬體、環境以及人力成本。對於乙個長期執行的軟體系統來說，開發成本只會佔到很小的比例。比如乙個計畫使用十年的系統，開發時間可能只有一年，而維護確需要九年。正是這個原因，從中可以看出，如果能夠通過增加一些開發成本，來降低維護成本，從總體上來看是會降低成本的。因此，對於長期執行的系統來說，開發質量比開發速度更重要。
前面說到敏捷能比傳統方式更快的提供價值和可工作的軟體，這又是怎麼通過「慢」來實現的呢?
對於客戶來說，每一項需求所帶來的價值或者說回報，是不一樣的。有些需求的回報多一些，有些則少一些。如果我們能夠識別出這些價值高的東西，先實現出來，客戶就能更快的或者更高的回報。但是在現實中，客戶往往並不確切知道，哪些是價值高的，甚至不知道他們想要的究竟是什麼，因此我們需要通過迭代的方式，來獲取客戶的反饋，和客戶一起找出究竟應該做什麼才是正確的。如果忽略了價值，一味追求開發「快」，最後開發出價值比較低的需求，卻忽視了系統的核心價值，就得不償失了。
因此，敏捷的關注點應該是質量，而不是速度，通過提高軟體質量和識別核心價值，來降低成本。所有的敏捷實踐都是為了能夠用更有效率的辦法，用盡可能快的方式提高質量，消除浪費。最終結果的「快」是通過過程上的「慢」來實現的。
敏捷開發藝術 閱讀筆記
承諾 commitment 我們對團隊承擔的工作有了更大的掌控，更加堅定了對成功的承諾。專注 focus 我們將全部精力和技能都聚焦在所承諾的工作上，團隊同心協力來促使更快的交付。公開 openness 團隊通過自己的方式共同完成工作，每個成員都對進展和問題瞭如指掌。敬重 respect 團隊中的每...
提問是門藝術
不平靜的十一假期這麼快就結束了。前些天北方大降溫，目前在帝都的偶已穿上了秋褲。然而最近幾天晚上被凍醒數次，這是逼勞資換下喜洋洋的空調被，換上俺心愛的粉色棉被呀。這就膩害了，我的哥 俺當然非常樂意去回答那些 優質 的提問，因為這些問題更有意義。而且 好問題 是值得花時間去探索的，最終的收穫也是雙方面的...
程式設計是否是藝術
有的人說程式設計是一種藝術，有的人說程式設計不足以作為藝術，但這兩方似乎從未公開正式的當面辯論過。我只有乙個人，無法公平的分成兩邊來辯論，所以今天不講前人已有的各種理論，只嘗試從道理上分析一下 程式設計是否是藝術。為了分析程式設計是否是藝術，我們首先分析幾種被廣泛認可的藝術形式，尋找它們的共同特徵。...