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

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

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

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

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

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

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

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

敏捷過程要求用戶與程序猿在同一個團隊，共同工作（上帝與我們同在！從來沒有誰能讓我們?nèi)绱私咏系?#xff01;

！

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

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

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

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

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

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

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

敏捷也不排斥設計。但敏捷強調(diào)的戰(zhàn)略設計。總體的架構，而不是戰(zhàn)術戰(zhàn)法。

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

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

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

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

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

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

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

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

版權聲明：本文博主原創(chuàng)文章。博客，未經(jīng)同意不得轉載。

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。