文章來(lái)源 – Martin Fowler 和 Neal Ford 在 Paris – USI 2010 的演講

　　有很多的書籍討論敏捷方法是怎樣工作的（How it works？），在這個(gè)主題演講中，Martin Fowler 和他的同事 Neal Ford 討論了敏捷方法能夠在軟件開(kāi)發(fā)項(xiàng)目中行之有效的原因（Why it works？）。作為敏捷方法的發(fā)起人和傳道者，Martin Fowler 和 ThoughtWorks 一直試圖從理論層面證明敏捷方法的可行性，同時(shí)不厭其煩地解答著客戶們的各種困惑，正如他們所說(shuō)，敏捷方法中的很多概念不是特別的直觀，除非人們真正實(shí)踐過(guò)一段時(shí)間，否則有些概念很難從字面上去完全理解。

　　Martin Fowler 談到一個(gè)有意思的現(xiàn)象，那就是今天許多人們口中談?wù)摰拿艚莘椒ǎ妥畛醯拿艚莘椒ù笙鄰酵ィ堰@種現(xiàn)象稱為“語(yǔ)義擴(kuò)散（Semantic Diffusion）”，大意是某種思想在傳播的過(guò)程中，在逐漸擴(kuò)散的同時(shí)，其語(yǔ)義也漸漸變得模糊。在敏捷開(kāi)發(fā)領(lǐng)域里，“語(yǔ)義擴(kuò)散”導(dǎo)致的一個(gè)問(wèn)題是，在一些使用敏捷方法的項(xiàng)目或者公司中，我們甚至無(wú)法辨別出敏捷方法的影子，原因是很多人沒(méi)有真正地理解敏捷方法，也就不能夠正確地運(yùn)用和實(shí)踐，從而也就無(wú)法真正了解自己是否能夠從敏捷方法中獲益。

　　以下是為什么敏捷方法行之有效的原因：

　　1. 敏捷方法和傳統(tǒng)的計(jì)劃驅(qū)動(dòng)方法的兩個(gè)主要區(qū)別

　　i. 預(yù)測(cè)性計(jì)劃（Predictive Planning）和自適應(yīng)計(jì)劃（Adaptive Planning）

　　計(jì)劃驅(qū)動(dòng)方法首先計(jì)劃要做的工作（plan your work），然后著手工作以完成計(jì)劃（work your plan）。這是一種帶有預(yù)測(cè)性質(zhì)的方法，其衡量項(xiàng)目成功的標(biāo)準(zhǔn)則是我們是否按計(jì)劃、按時(shí)、按預(yù)算完成了工作。這種方法在很多領(lǐng)域里是適用的。但是對(duì)于軟件開(kāi)發(fā)而言，如果我們的需求沒(méi)有辦法做到不變更的話，我們就無(wú)法保證我們的計(jì)劃以及其后的工作是不會(huì)變更的。Martin Fowler 向現(xiàn)場(chǎng)觀眾提出了一個(gè)問(wèn)題，大意是你們當(dāng)中有多少人的軟件開(kāi)發(fā)項(xiàng)目的需求是一成不變的，結(jié)果沒(méi)有一位觀眾舉手。因此，敏捷方法引入了自適應(yīng)計(jì)劃的概念，既然我們無(wú)法保證需求不變更，那么就讓我們隨時(shí)準(zhǔn)備接受變更，接受挑戰(zhàn)吧。自適應(yīng)計(jì)劃將計(jì)劃驅(qū)動(dòng)的流程縮短為以數(shù)周為單位的循環(huán)周期，在每一個(gè)周期中，我們根據(jù)當(dāng)前的情況不斷地調(diào)整計(jì)劃以及計(jì)劃的執(zhí)行過(guò)程，同時(shí)不斷地產(chǎn)生能夠工作的代碼，并且不斷地將代碼部署到應(yīng)用環(huán)境中去。當(dāng)然要實(shí)現(xiàn)這個(gè)目標(biāo)我們需要一些具體方法的支持，如：自測(cè)試代碼（Self-Testing Code），持續(xù)集成（Continuous Integration），重構(gòu)（Refactoring），和簡(jiǎn)潔設(shè)計(jì)（Simple Design）等等這些技術(shù)層面上的方法。Martin Fowler 指出，一些公司和項(xiàng)目之所以受困于敏捷方法，原因之一是他們忽略了這些技術(shù)層面的方法，而僅僅實(shí)施了項(xiàng)目管理層面的方法。

　　ii. 以流程為本（Process First）和以人為本（People First）

　　在傳統(tǒng)的方法論中，我們總是需要事先定義好工作的方法和流程，然后“工人們”被要求遵照這些方法和流程來(lái)工作。在軟件開(kāi)發(fā)領(lǐng)域，很多人把軟件開(kāi)發(fā)過(guò)程等同于軟件本身，也就是說(shuō)，軟件開(kāi)發(fā)的過(guò)程也如同軟件程序般象機(jī)器一樣運(yùn)行，組件之間環(huán)環(huán)相扣，嚴(yán)密地協(xié)同工作。問(wèn)題是軟件開(kāi)發(fā)的核心是人，人相對(duì)于機(jī)器零件和流水線而言，是相對(duì)不可預(yù)測(cè)的和不那么精密的。所以敏捷方法反其道而行之，提倡將“首先定義流程，然后要求軟件開(kāi)發(fā)人員遵照流程工作”變?yōu)?ldquo;讓參與軟件開(kāi)發(fā)的人員自己來(lái)定義和選擇適合他們的流程”。簡(jiǎn)單來(lái)說(shuō)就是以人為本，不把人當(dāng)螺絲釘，發(fā)揮人的主觀能動(dòng)性，當(dāng)然前提是需要團(tuán)隊(duì)成員有較高的平均素質(zhì)。

　　2. 溝通（Communication）

　　Neal Ford 讓我們回顧或想象一下失敗的軟件開(kāi)發(fā)項(xiàng)目，它們的失敗是由于技術(shù)因素還是人的因素呢？《人件》的作者認(rèn)為都是人的因素。人類的社會(huì)性決定了溝通的重要。Neal 舉了幾個(gè)有趣的例子，如：監(jiān)獄里的犯人寧愿和其他人渣待在一起也不愿被關(guān)禁閉。很多國(guó)家禁止駕駛員駕駛時(shí)打移動(dòng)電話，那為什么和乘客聊天就沒(méi)有問(wèn)題呢？原因是直接對(duì)話是最為有效和便捷的溝通方式，信息的傳遞在對(duì)話過(guò)程中非常順暢和完整。雖然現(xiàn)在的移動(dòng)通訊已經(jīng)非常先進(jìn)，信號(hào)質(zhì)量也很高，但是我們的通話過(guò)程仍然是有損的，我們的大腦這個(gè)時(shí)候就需要努力地試圖將通話信息拼湊得更完整以便能夠理解對(duì)方的意思，因此才會(huì)分散駕駛的注意力。隨后，Martin Fowler 舉了另一個(gè)例子，拿他做水果蛋糕的方法和他在酒店的浴室中沖涼的方法來(lái)進(jìn)行比較。因?yàn)樽鏊案獾恼麄€(gè)流程和配料都是非常固定的，所以他只需要按步照搬地烹飪即可做出味道非常一致（地好或者差）的水果蛋糕。而在酒店中沖涼就有些不同，因?yàn)槊恳粋€(gè)酒店浴室的開(kāi)關(guān)設(shè)計(jì)幾乎都是不一樣的，所以他需要不斷地調(diào)整開(kāi)關(guān)來(lái)獲得一個(gè)理想的水溫，也就是需要不斷地重復(fù)“調(diào)整開(kāi)關(guān)”（輸入），“用手試溫”（輸出）這個(gè)過(guò)程。相對(duì)于做水果蛋糕，在酒店浴室沖涼更好地反應(yīng)了軟件開(kāi)發(fā)的特征，這就是在軟件開(kāi)發(fā)領(lǐng)域中，如果我們善于根據(jù)用戶反饋的信息來(lái)做出新的判斷和調(diào)整，就有可能提高產(chǎn)品的質(zhì)量和用戶的滿意度。

　　溝通的確是一個(gè)非常重要的環(huán)節(jié)，它是敏捷方法的核心。在敏捷方法中，單元測(cè)試是程序員和代碼組件的溝通，功能測(cè)試是程序員以及QA和系統(tǒng)的溝通，故事墻（Story Wall）和回顧（Retrospective）是團(tuán)隊(duì)和成員之間的溝通，功能演示（Showcase 或者 Demo）是團(tuán)隊(duì)通過(guò)產(chǎn)品和最終用戶的溝通，持續(xù)集成（Continuous Integration）是產(chǎn)品和企業(yè)計(jì)算環(huán)境的溝通。溝通好了，什么事情都可以妥善解決，溝通得不好，好事也會(huì)變壞事。和廣大技術(shù)愛(ài)好者交流溝通也是酷殼存在的目的和意義。

　　整個(gè)演講時(shí)長(zhǎng)一個(gè)小時(shí)，本文只是節(jié)選了我認(rèn)為比較有意思的觀點(diǎn)加上本人的理解寫成，如有錯(cuò)誤之處歡迎指正，不同看法歡迎交流。

it知識(shí)庫(kù)：為什么敏捷方法能在軟件開(kāi)發(fā)中行之有效？，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。