文章來源 – Martin Fowler 和 Neal Ford 在 Paris – USI 2010 的演講

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

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

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

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

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

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

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

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

　　2. 溝通（Communication）

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

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

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

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

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