昨。和一位同事，像敏捷的問題和需求文件，有一點爭議。我結結巴巴，未能充分表達我的觀點。回到他的想法整理，寫下來。

首先要說的是，敏捷與需求文檔的關系。

敏捷并不是排斥需求，它僅僅是給用戶一個舒適地表述需求的環境。其實，敏捷相對于古老的RUP模式，更是把需求和測試抬到了一個前所未有的高度。

傳統的軟件project模式，想讓程序猿介入，就要求先有明白清晰的需求規格書。經過多輪的評審確認，還要用戶簽字畫押。

且不說『簽字畫押』給人帶來的嚴重心理不適，就說這冷冰冰的需求規格書，就如冰封千年的雪山。橫亙在用戶與程序猿之間，上帝（用戶）與我們（程序猿）的距離變得如此遙遠，抱怨、指責、懷疑，不安，一切人類不好的情緒都會由此而引發……

并且。什么樣的需求描寫敘述是清晰明白的？每一個人都有不同的理解。

上帝： 我要個喝水的杯子。 程序員：高度為多少CM的杯子？口徑多少？什么材質？奧氏體304？僅僅是用于喝水嗎？水溫多少？是否須要支持盛放鹽酸？或者可樂？ 上帝： &%￥#…… 程序員：天啊？My God。

你連自己要個什么樣的杯子都說不清嗎？

敏捷過程要求用戶與程序猿在同一個團隊，共同工作（上帝與我們同在！從來沒有誰能讓我們如此接近上帝！

！

），上帝隨時提出需求，我們隨時給出響應。

上帝：我要杯子 ，于是就有了杯子； 上帝：杯子小了點。于是杯子變大了； 上帝：我要蓋子。于是有了蓋子。 上帝：杯子太素了，于是杯子壁上有了圖案； 上帝：我要水。于是杯子里就有了水。

敏捷用UserStory來取代需求規格書。用即時反饋來取代評審。用討論來取代簽字畫押。

敏捷是真正意義上以用戶為中心的開發模式。

其次，我想再說的是敏捷與設計的關系。

傳統的過程，我們在跋山涉水歷經九九八十一難之后，最終完畢需求規格書的確認，還有，概要設計書、具體設計書兩座大山橫在面前。

但是，你知道嗎？上帝已經等得有點不耐煩了。

敏捷也不排斥設計。但敏捷強調的戰略設計。總體的架構，而不是戰術戰法。

戰場情況瞬息萬變，戰術上的事情。交給現場指揮員臨機應變就好了。

《45個好習慣》中說『程序猿不是打字員』，我是很贊同。

我從來不認可『軟件藍領』這種職業，軟件行業，沒有白領藍領之分，僅僅有師傅徒弟。觀點見我曾經的博文：http://blog.csdn.net/sharetop/article/details/2145572

敏捷過程強調高速開發高速迭代。并不是拋棄了設計，而是將一個原本獨立的設計階段，揉碎了，填充到開發的全過程中，讓設計滋潤著代碼。讓代碼變得更有生機，設計也更接地氣。

讓設計浸潤著代碼。對每個程序猿都有更高的要求。所以，敏捷的流行催生了『全棧project師』的概念。

再分享《45個好習慣》中的觀點：好的設計，是正確的，而不是精確的。

回憶我曾經的痛苦的RUP經歷。用ROSE做具體設計，定義每個類，每個方法以及全部的參數……如此繁瑣仔細的工作，需求一點點的變化。都可能會將全部的工作努力化為烏有。

最后。要說的一句話是：敏捷也并不適用于全部場景，比方你要做一個操作系統。

版權聲明：本文博主原創文章。博客，未經同意不得轉載。

轉載于:https://www.cnblogs.com/bhlsheji/p/4854472.html

總結

以上是生活随笔為你收集整理的有些事关于敏捷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。