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

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

1. 從敏捷宣言和原則出發(fā)

@Timo.

敏捷宣言有四項(xiàng)價值陳述：

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

敏捷開發(fā)宣言

但事實(shí)證明這四項(xiàng)都存在局限：

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

最終便成為，所有人都希望自己“敏捷”，但敏捷的那些革命性思想與現(xiàn)實(shí)相差甚遠(yuǎn)。

@Gallen.

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

敏捷宣言遵循的原則

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

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

用最終結(jié)果來描述敏捷帶來的變化：

• 敏捷團(tuán)隊支撐的產(chǎn)品：細(xì)心的用戶會發(fā)現(xiàn)產(chǎn)品漸進(jìn)式的變化;粗心的用戶看不到產(chǎn)品變化，但體驗(yàn)感覺越來越好。但如果產(chǎn)品掌握不好節(jié)奏，用戶也會吐槽怎么總是變來變?nèi)ァ?/li>
• 瀑布式團(tuán)隊支撐的產(chǎn)品：用戶明顯發(fā)現(xiàn)產(chǎn)品階梯式變化，如常說的改版，煥然一新;用戶有時候會失去耐心。

2. “敏捷”強(qiáng)調(diào)的是響應(yīng)變化的能力

@Like.

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

但是在國內(nèi)，這事情搞反了，變成了產(chǎn)品搞出“敏捷產(chǎn)品”這概念，把需求搞成了隨時隨地都要調(diào)整修改，完全沒有規(guī)劃的形式，美其名曰“敏捷”，開發(fā)變?yōu)橥獍?/p>

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

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

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

也就是說，實(shí)際上需求方/產(chǎn)品想做的東西一定是在不斷調(diào)整變化的，作為開發(fā)，實(shí)際上你要做的并不是去完成需求，而是幫對方實(shí)現(xiàn)后并驗(yàn)證對方的想法。

但要做到開發(fā)+產(chǎn)品=共同設(shè)計驗(yàn)證需求思路，開發(fā)要有足夠的(產(chǎn)品)結(jié)果導(dǎo)向意識，主動去改進(jìn)產(chǎn)品設(shè)計和實(shí)現(xiàn)，產(chǎn)品自己也要足夠open，認(rèn)識到自己的需求文檔并不是那么“天經(jīng)地義”，而是在開發(fā)過程中和開發(fā)同學(xué)一起調(diào)整改進(jìn)。

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

這事也可能和項(xiàng)目規(guī)劃有關(guān)，如果要總結(jié)的話，我認(rèn)為敏捷是個純粹開發(fā)者自己安排工作的事情，產(chǎn)品和pm都別摻合。需求走waterfall，任務(wù)走每周迭代?；蛘哒f對產(chǎn)品來說，考慮的是一個需求需要幾個sprint(迭代)來實(shí)現(xiàn)，而每個sprint做什么，開發(fā)自己把握。

@Ferry.

敏捷開發(fā)強(qiáng)調(diào)的是響應(yīng)變化的能力，在敏捷的模式里面我們提倡簡單開發(fā)，以最快的速度實(shí)現(xiàn)功能，投入給用戶使用并快速獲得反饋來進(jìn)行下一步的優(yōu)化改進(jìn)。

那么在快速實(shí)現(xiàn)的過程中必然會產(chǎn)生一些技術(shù)債務(wù)，因此在敏捷中另一個強(qiáng)調(diào)的點(diǎn)就是重構(gòu)，兩者相輔相成才能使速度與質(zhì)量同時得到保證。

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

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

@Willy.

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

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

有沒有以開發(fā)人員為主導(dǎo)的敏捷開發(fā)方法呢？有的。那就是極限編程(extreme programming)，該方法更偏重于工程實(shí)踐：簡單設(shè)計、結(jié)對、TDD、重構(gòu)。相對于Scrum和kanban，極限編程很難推廣，因?yàn)楣こ虒?shí)踐太硬核了，入門比較難。但是好處是入門之后，就是一片坦途。

極限編程(extreme programming)

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

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

@Zoker.

基礎(chǔ)設(shè)施決定上層建筑。

從個人經(jīng)驗(yàn)來看，敏捷的缺點(diǎn)就是包含了一個隱含條件：標(biāo)準(zhǔn)的 2pizza 團(tuán)隊中，每個成員都是有所積累的、積極主動的、富有愛心的、樂于成事的。

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

我一直認(rèn)為一個公司「最」驕傲的不應(yīng)該是他們有什么厲害的產(chǎn)品，而是他們培養(yǎng)出了一批富有戰(zhàn)斗力、創(chuàng)造力的團(tuán)隊，能夠凝聚團(tuán)隊的力量解決任何事情，產(chǎn)品只是過程目標(biāo)，優(yōu)秀的團(tuán)隊才是最終目標(biāo)。

@Chao.

真正敏捷的開發(fā)，很多時候恰恰建立在團(tuán)隊認(rèn)可的規(guī)范的基礎(chǔ)中，這個規(guī)范，不只是包括代碼規(guī)范，還有流程規(guī)范。

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

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