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

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

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

@Timo.

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

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

敏捷開(kāi)發(fā)宣言

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

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

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

@Gallen.

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

敏捷宣言遵循的原則

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

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

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

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

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

@Like.

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

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

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

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

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

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

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

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

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

@Ferry.

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

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

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

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

@Willy.

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

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

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

極限編程(extreme programming)

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

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

@Zoker.

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

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

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

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

@Chao.

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

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

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