“ 到底，什么是真正的敏捷開發？”

這大概是很多技術同學都想了解的問題，那么到底什么才是真正的敏捷開發呢？我們來聽聽鵝廠程序員們的看法：

1. 從敏捷宣言和原則出發

@Timo.

敏捷宣言有四項價值陳述：

• 個體和互動高于過程和工具。(Individuals and interactions over processes and tools.)
• 可工作的軟件高于詳盡的文檔。(Working software over comprehensive documentation.)
• 客戶合作高于合同談判。(Customer collaboration over contract negotiation.)
• 響應變化高于遵循計劃。(Responding to change over following a plan.)

敏捷開發宣言

但事實證明這四項都存在局限：

• 優先考慮個體和互動是一個很難推廣的概念。銷售過程和工具要容易得多；比起不切實際的計劃和堆積如山的文件，工作中的軟件更難生產；與客戶合作需要信任和脆弱性，而這在業務環境中并不總是如此；對于那些想要控制局面、同時又需要為自己的業務制定長期計劃的高管來說，應對變化往往顯得不夠重要。
• 從個人在前司的經歷來看：敏捷是個契約，需要參與其中的人不斷磨合、思考和迭代，一成不變的敏捷始終不能作為萬金油，但要使團隊運行在最合適的狀態下，需要所有參與者和你一樣努力思考和探索，迭代敏捷自身的過程，但這很難。
• 而不恰當地“敏捷”，便容易產生很多缺點，例如：很容易導致開發人員進度被干擾，縮短工作時間，增加壓力，并且要求“更快地開展工作”，產生“被剝削感”。最終使開發更不敏捷，且容易導致更多的缺陷和進展緩慢，最終企業效率甚至比敏捷推行之前還低。

最終便成為，所有人都希望自己“敏捷”，但敏捷的那些革命性思想與現實相差甚遠。

@Gallen.

認識敏捷要從敏捷宣言和它的12條基本原則理解，然后再看幾個主流的敏捷方法Scrum,SAFe,Less, SoS。

敏捷宣言遵循的原則

連基本定義和原則都沒看過就胡咧咧敏捷的大有人在。在我看來大多數團隊所謂的敏捷研發都是小瀑布。而且把敏捷方法理解成只需要開發參與也偏得太多。實際上敏捷方法支撐的是快速迭代交付產品。完整的產品團隊具備所有角色。所謂的沒產品由開發自己負責玩的比較轉的團隊，實際也承擔這產品的職責。

順便提幾個問題供大家思考：需求需要拆分嗎?拆分的意義是什么？怎么做好迭代規劃？響應變化和變更控制是矛盾的嗎？

用最終結果來描述敏捷帶來的變化：

• 敏捷團隊支撐的產品：細心的用戶會發現產品漸進式的變化;粗心的用戶看不到產品變化，但體驗感覺越來越好。但如果產品掌握不好節奏，用戶也會吐槽怎么總是變來變去。
• 瀑布式團隊支撐的產品：用戶明顯發現產品階梯式變化，如常說的改版，煥然一新;用戶有時候會失去耐心。

2. “敏捷”強調的是響應變化的能力

@Like.

敏捷本身是為了面對需求的不斷調整，幫助開發自己把握節奏，以給自己定迭代和mvp形式盡早呈現給用戶，讓用戶反饋能盡早get到，避免無用功。這是“開發”要的敏捷，不是需求要“敏捷”。

但是在國內，這事情搞反了，變成了產品搞出“敏捷產品”這概念，把需求搞成了隨時隨地都要調整修改，完全沒有規劃的形式，美其名曰“敏捷”，開發變為外包。

我個人很同意這點，無論是過去做產品還是現在負責工具，其實讓我感受到成就的不是某個功能被開發或者被我自己實現了，而是這個功能被用戶用起來，而且用戶反饋和我預期相符(得到了驗證)，這時候我才會覺得這個需求/功能完成了。

寫《人月神話》那本書作者后來又寫了本 The Design of Design 的書，里面提到一個思路很不錯。他說他最早也是跟著需求走，別人給什么需求他就怎么做，但是發現需求是做不完的。于是他停下來思考，認識到其實需求方真正的訴求并不是要他“完成需求”，而是要他幫助“驗證需求”。

《人月神話》作者新作：The Design of Design

也就是說，實際上需求方/產品想做的東西一定是在不斷調整變化的，作為開發，實際上你要做的并不是去完成需求，而是幫對方實現后并驗證對方的想法。

但要做到開發+產品=共同設計驗證需求思路，開發要有足夠的(產品)結果導向意識，主動去改進產品設計和實現，產品自己也要足夠open，認識到自己的需求文檔并不是那么“天經地義”，而是在開發過程中和開發同學一起調整改進。

在這個基礎上，才能去談產品迭代和敏捷開發，不然還是走waterfall形式靠譜些。

這事也可能和項目規劃有關，如果要總結的話，我認為敏捷是個純粹開發者自己安排工作的事情，產品和pm都別摻合。需求走waterfall，任務走每周迭代。或者說對產品來說，考慮的是一個需求需要幾個sprint(迭代)來實現，而每個sprint做什么，開發自己把握。

@Ferry.

敏捷開發強調的是響應變化的能力，在敏捷的模式里面我們提倡簡單開發，以最快的速度實現功能，投入給用戶使用并快速獲得反饋來進行下一步的優化改進。

那么在快速實現的過程中必然會產生一些技術債務，因此在敏捷中另一個強調的點就是重構，兩者相輔相成才能使速度與質量同時得到保證。

所以在一個迭代中除了業務需求之外也應該包含一定比例的技術需求，至于技術需求的占比可以與項目管理者進行協商，比如80%業務20%技術。否則當技術債務擠壓到一定程度的時候，勢必要付出更大的成本與代價。

3. “敏捷”需要多方共同努力

@Willy.

軟件開發的本質是對知識建模，把我們對知識的理解，在虛擬世界里建模。建模的核心角色是我們開發人員，敏捷開發最初也是由一群軟件開發人員提出來的。

但是我們現在提到敏捷開發，大家更多想到的是流程和會議，這會讓我們覺得離開發人員很遠。這主要是因為，在國內引入敏捷開發，更多的是由PM、QA這些角色主導的，他們更容易接受Scrum、kanban這些敏捷開發方法。Scrum和kanban入門比較容易，但是難以精通。所以很多情況下，給大家的印象只有流程和會議了。

有沒有以開發人員為主導的敏捷開發方法呢？有的。那就是極限編程(extreme programming)，該方法更偏重于工程實踐：簡單設計、結對、TDD、重構。相對于Scrum和kanban，極限編程很難推廣，因為工程實踐太硬核了，入門比較難。但是好處是入門之后，就是一片坦途。

極限編程(extreme programming)

簡單設計讓我們可以快速開始，有了TDD和重構可以保持代碼架構的整潔，結對讓知識傳遞更容易，知識保存在團隊中而不是個人的腦袋里。更有大家目前都號稱在用的持續集成，讓我們的代碼可以快速上線，獲得用戶反饋。

歡迎廣大程序員加入敏捷開發，從刻意練習極限編程的工程實踐開始。

@Zoker.

基礎設施決定上層建筑。

從個人經驗來看，敏捷的缺點就是包含了一個隱含條件：標準的 2pizza 團隊中，每個成員都是有所積累的、積極主動的、富有愛心的、樂于成事的。

縱觀那些成功和失敗的敏捷 case 中，除了外界因素的影響，很少有人提起團隊配置，我們看到的都是海賊王中的草帽團、LOL 中的 IG、FPX、EDG，這都是高配團隊，所以在考慮推進敏捷的時候，一定不要忽略了「人」這個最核心的因素。

我一直認為一個公司「最」驕傲的不應該是他們有什么厲害的產品，而是他們培養出了一批富有戰斗力、創造力的團隊，能夠凝聚團隊的力量解決任何事情，產品只是過程目標，優秀的團隊才是最終目標。

@Chao.

真正敏捷的開發，很多時候恰恰建立在團隊認可的規范的基礎中，這個規范，不只是包括代碼規范，還有流程規范。

舉一個簡單的例子，代碼規范中第一個約束的就是縮進和縮進的空格數以及用tab還是whitespace。如果連這個都沒有很好的約束的話，code review、code merge就會很成問題。更不用說其他的了。

目前公司內的一些開發流程也逐漸向一流的科技公司靠攏，而且公司內部也提供了非常好的代碼平臺，大家可以善用工具。