敏捷開發(fā)基礎(chǔ)概念介紹

敏捷基礎(chǔ)概念介紹彭珂Date:July13,2012

敏捷的概念敏捷是一種強(qiáng)調(diào)輕量的過程方法論，它強(qiáng)調(diào)擁抱變化而不是與之對抗，通過有效的溝通發(fā)揮群體的智慧敏捷方法論采用迭代/增量開發(fā)的過程模型敏捷門派眾多，2001年，成立敏捷聯(lián)盟，并發(fā)布了宣言和原則敏捷宣言個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計(jì)劃

雖然右邊的也有價值，但是我們認(rèn)為左邊的具有更大的價值誰在使用敏捷？微軟大規(guī)模使用，敏捷列入新員工培訓(xùn)課程N(yùn)okiaSimens

超過40個產(chǎn)品使用敏捷流程，最大的項(xiàng)目約500名開發(fā)人員，跨地域、時差I(lǐng)BM項(xiàng)目經(jīng)理可以自主選用瀑布或者敏捷流程，將為華為提供敏捷顧問和工具Ericsson從第一代GSM基站開發(fā)就采用增量式迭代開發(fā)，使用敏捷的部分實(shí)踐Google大部分項(xiàng)目敏捷，部分采用傳統(tǒng)方法開發(fā)Wiki Wiki的發(fā)明人是敏捷宣言的發(fā)起人之一，Wiki的靈感來源于敏捷的“集體代碼所有權(quán)”思想神舟飛船軟件系統(tǒng)在敏捷宣言發(fā)表之前即采用敏捷的思想BT：HuaweitoproposehowwecanmeettheagilerequirementsofBT.

迭代的概念相對于傳統(tǒng)的瀑布式開發(fā)，迭代開發(fā)把軟件生命周期分成很多個小周期（一般不大于2個月，建議2周），每一次迭代都可以生成一個可運(yùn)行、可驗(yàn)證的版本，并確保軟件不斷的增加新的價值。什么是迭代開發(fā)？迭代的主要目的

1、驗(yàn)證關(guān)鍵設(shè)計(jì)方案，避免重大的設(shè)計(jì)風(fēng)險（主要設(shè)計(jì)點(diǎn)）

2、盡快確認(rèn)和澄清客戶需求（主要需求點(diǎn)）

3、縮短驗(yàn)證周期（只有在小粒度迭代上才可能實(shí)現(xiàn)），提供靈活的特性交付能力我們的版本開發(fā)是不是迭代？

1、宏觀上講，我們也是迭代開發(fā)，但顆粒度太大，存在問題

2、周期太長，驗(yàn)證反饋太慢，長周期要承擔(dān)更多的需求變更風(fēng)險，導(dǎo)致惡性循環(huán)

3、沒有真正識別主要需求點(diǎn)和主要設(shè)計(jì)點(diǎn)，無法盡快確認(rèn)需求和避免設(shè)計(jì)風(fēng)險4、不具備快速驗(yàn)證的能力5、對于大部分的產(chǎn)品，我們應(yīng)用迭代的主要訴求在2，3兩點(diǎn)

小批量交付特性集AA1A2A3=特性集BB1B2B3=B特性集CC1C2C3=CA傳統(tǒng)方法:“每件事都很重要！一次就要全部做好！”JanFebMarAprMayJunJulA1B1C1A2B2C2A3B3C3ABC迭代開發(fā):“優(yōu)先級&關(guān)注點(diǎn)!”JanFebMarAprMayJunJulA1B1C1A2B2C2A3B3C3ABC如何處理變化和延遲計(jì)劃Week1Week2Week3Week4CDAB傳統(tǒng)模式下的延遲方式Week1Week2Week3Week4Week5Week6Week7Week8CDAB迭代模式下的延遲方式Week1Week2Week3Week4Week5Week6Week7Week8ABEDAB敏捷與迭代的關(guān)系敏捷強(qiáng)調(diào)軟件的需求、設(shè)計(jì)、計(jì)劃都是復(fù)雜的，以至于不可能一次就精確的完成，所以要通過快速的反饋對需求、設(shè)計(jì)、計(jì)劃進(jìn)行修正迭代是敏捷建立持續(xù)的快速反饋機(jī)制的技術(shù)手段

敏捷與迭代關(guān)系(續(xù))隨著軟件交付周期的日益加快，迭代化開發(fā)已經(jīng)成為大多數(shù)軟件開發(fā)團(tuán)隊(duì)的必選項(xiàng)。但是迭代對整個團(tuán)隊(duì)的需求、架構(gòu)、協(xié)同及測試能力都提出了更高的要求，現(xiàn)在許多開發(fā)團(tuán)隊(duì)都在試圖導(dǎo)入迭代化開發(fā)的過程中，敏捷可是被看成迭代化開發(fā)的一種導(dǎo)入方式，這不過敏捷的范圍其實(shí)比迭代化開發(fā)更大一些敏捷的三個要素是迭代開發(fā)、坦誠合作和自適應(yīng)性。坦誠合作其實(shí)才是敏捷的精髓，如Ivar所說，敏捷其實(shí)是有關(guān)SocialEngineering的。敏捷的主要貢獻(xiàn)在于他更多地思考了如何去激發(fā)開發(fā)人員的工作熱情，這是在軟件工程幾十年的發(fā)展過程中相對被忽略的領(lǐng)域敏捷宣言遵循的原則-迭代我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)敏捷宣言遵循的原則-團(tuán)隊(duì)運(yùn)作在團(tuán)隊(duì)內(nèi)部，最具有效果且富有效率的傳遞信息的方法，就是面對面的交談在整個項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作圍繞被激勵的個體來構(gòu)建項(xiàng)目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作敏捷過程提倡可持續(xù)的開發(fā)速度，責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會增強(qiáng)敏捷能力簡單---使未完成的工作最大化的藝術(shù)---是根本的敏捷宣言遵循的原則-自組織團(tuán)隊(duì)最好的構(gòu)架、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)每隔一定時間，團(tuán)隊(duì)會在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對自己的行為進(jìn)行調(diào)整敏捷-質(zhì)量管理每一次迭代結(jié)束，項(xiàng)目組坐在一起對迭代進(jìn)行回顧，回答兩個問題：

1、我們的成功經(jīng)驗(yàn)是什么？

2、有什么能改進(jìn)？針對項(xiàng)目組當(dāng)前的問題，自主決策改進(jìn)方案，并在下一個迭代中實(shí)施，即使改進(jìn)方案無效，也可以在下一個迭代回顧時發(fā)現(xiàn)，最多浪費(fèi)一個迭代周期自我決策改進(jìn)方案，以適應(yīng)復(fù)雜的需求、人員狀況，是敏捷團(tuán)隊(duì)的最大特點(diǎn)

敏捷實(shí)踐敏捷實(shí)踐(續(xù))敏捷是聰明的工作

敏捷是關(guān)于以下三件事情的：最重要的，敏捷是一門社會工程學(xué)。這是敏捷最大的特點(diǎn)。它關(guān)注的是，如何以一個團(tuán)隊(duì)的形式開展工作，如何激勵團(tuán)隊(duì)成員，如何相互合作等等敏捷是輕量級的。敏捷非常依賴隱性知識，敏捷認(rèn)為，只要有掌握足夠知識的人，才可以開發(fā)出優(yōu)秀的軟件敏捷提供技術(shù)實(shí)踐。這其實(shí)是敏捷中貢獻(xiàn)最微弱的部分敏捷的本質(zhì)是變得“聰明”，聰明就是做正好合適的事，不是找更廣的解決方案，而是正好。對敏捷常見的誤區(qū)敏捷不寫文檔敏捷不適合大型軟件開發(fā)，尤其是高質(zhì)量要求領(lǐng)域敏捷和CMM對立敏捷導(dǎo)致對人員的極度依賴敏捷導(dǎo)致管理者無法看到項(xiàng)目組的進(jìn)展，從而導(dǎo)致失控敏捷是銀彈??？敏捷=不寫文檔？只寫項(xiàng)目組認(rèn)為必須的文檔如果認(rèn)為項(xiàng)目組新員工比較多，可能就得寫比較多的文檔如果需要經(jīng)常和大量的客戶、眾多的項(xiàng)目組交流，可能就需要比較多的書面規(guī)格、接口文檔。因?yàn)槿硕嗟臅r候，面對面的溝通帶來N平方問題常見的文檔為：需求文檔，敏捷實(shí)際上要求對需求的闡述非常細(xì)致，并且可測（部分非功能性需求可能難以測試），現(xiàn)有產(chǎn)品文檔根本無法滿足要求。但是迭代開發(fā)中文檔是跟隨迭代過程不斷完善，而且很多公司是在測試完成后才開始寫規(guī)格文檔。文檔是結(jié)果記錄，而非開發(fā)過程中的溝通工具。代碼（代碼即設(shè)計(jì)文檔）：最好的代碼是自注釋代碼，應(yīng)當(dāng)盡量通過重構(gòu)讓代碼可以直接閱讀，盡可能減少需要注釋才能看懂的代碼。架構(gòu)文檔（通常是幾頁紙，參見附錄微軟對架構(gòu)的看法）

敏捷不適合大型軟件開發(fā)膠片前面已經(jīng)介紹過，眾多的電信廠商、微軟、IBM、美國軍方、神舟飛船系統(tǒng)，均采用或者部分采用敏捷的思想進(jìn)行開發(fā)敏捷認(rèn)為變化不可預(yù)測，如果小型項(xiàng)目的變化都不可預(yù)測，大型項(xiàng)目顯然更無法預(yù)測，所以認(rèn)為敏捷適用于小型項(xiàng)目，大型項(xiàng)目使用瀑布的說法是錯誤的。敏捷反CMM？CMM定義的是目標(biāo)，敏捷的實(shí)踐可以支撐CMM2、3級的KPA，Scrum的兩個掌門人，以及CMM1.1的項(xiàng)目經(jīng)理Paulk均持此種觀點(diǎn)，但是也有很多人不認(rèn)同此觀點(diǎn)。SEI的官方網(wǎng)站2008年11月也發(fā)表文章《CMMIorAgileWhyNotEmbraceBoth.pdf》http:///cn/news/2008/11/report-integrating-cmmi-agile，試圖融合。敏捷除了關(guān)注CMM關(guān)注的流程，更多的關(guān)注團(tuán)體智慧、發(fā)揮個人能力敏捷和IPD-CMM是截然相反的，一個基于瀑布模型，一個基于迭代模型敏捷導(dǎo)致項(xiàng)目管理失控敏捷雖然強(qiáng)調(diào)團(tuán)隊(duì)自組織，但是管理者可以通過持續(xù)集成和迭代測試結(jié)果知道項(xiàng)目組的實(shí)際進(jìn)展特性的完成沒有二義性，完成了50%的特性就有很大的把握知道項(xiàng)目組的進(jìn)展達(dá)到了50%。而文檔的完善度、正確性根本無法評價，這也是為什么普遍存在的現(xiàn)象：TR4前進(jìn)度總是可以完成的，TR4以后進(jìn)度總是拖后的。我們見過TR4以后瘋狂的加班，但是有誰見過開發(fā)人員加班到12點(diǎn)寫詳細(xì)設(shè)計(jì)文檔？敏捷導(dǎo)致對人員的極度依賴敏捷強(qiáng)調(diào)團(tuán)體的智慧，團(tuán)隊(duì)共同決策，實(shí)際上減少了人員的依賴結(jié)對編程保證了任何一行代碼都至少有兩個人懂持續(xù)集成保證了即使不了解系統(tǒng)也敢于修改系統(tǒng)。同時大量的測試用例是系統(tǒng)最準(zhǔn)確的文檔。對系統(tǒng)有疑問，而又沒人可以咨詢的時候，可以通過修改代碼、測試用例的方式去探索，而看不懂文檔就完全沒有辦法了IPD-CMM號稱可以不依賴于人，但是僅僅是目標(biāo)，從來都沒有做到代碼日益腐爛，完全無法看懂，沒有人敢改代碼。文檔糟糕透頂，絕大多數(shù)文檔是應(yīng)付流程的產(chǎn)物敏捷不能解決問題，只能讓問題暴露的更早敏捷方法是項(xiàng)目的救星嗎？不，我認(rèn)為它依然會失敗。敏捷開發(fā)可以帶給你的一件事情是：讓這些項(xiàng)目失敗的更快、損失的更少，因?yàn)槟憧梢詫r間和精力用于開始做下一件事情。

KentBeck總結(jié)軟件是復(fù)雜的，由此引發(fā)了一致性和可變性的問題。隨著軟件規(guī)模的日益膨脹，參與的人日益增加，軟件的本質(zhì)問題越來越突出復(fù)雜性：1、采用分而治之的思想，把一個大的軟件劃分為多個小特性，降低了每一輪迭代搜需面臨的復(fù)雜度一致性：1、按照特性組織團(tuán)隊(duì)，發(fā)揮群體智慧，團(tuán)隊(duì)共同擁有代碼，共同為需求、架構(gòu)、設(shè)計(jì)、測試負(fù)責(zé)。2、通過持續(xù)的反饋（迭代、面對面的溝通）消除不一致可變性1、變化難以預(yù)測，過早的應(yīng)對變化會導(dǎo)致浪費(fèi)。Keepitsimple。2、每一個項(xiàng)目都是不同的，每一個人也都是不同的。敏捷團(tuán)隊(duì)根據(jù)團(tuán)隊(duì)成員和項(xiàng)目需求的特性，自己決定流程、方法和工具參考書籍《敏捷軟件開發(fā)原則模式與實(shí)踐》《重構(gòu)》《人月神話》《編寫有效用例》《人件》《修改代碼的藝術(shù)