敏捷從零開始

1、敏捷培訓(xùn)從零開始 吳中華目錄敏捷知識淺嘗敏捷過程敏捷開發(fā)過程敏捷測試過程 敏捷知識淺嘗敏捷開發(fā)背景知識敏捷開發(fā)背景： 2001年，為了解決許多公司的軟件團(tuán)隊陷入不斷增加的過程泥潭，一批業(yè)界專家一起概括出了一些可以讓軟件開發(fā)團(tuán)隊具有快速工作，響應(yīng)變化能力的價值觀和原則。他們稱自己為敏捷聯(lián)盟。敏捷開發(fā)過程的方法很多，主要有:SCRUM（迭代增量開發(fā)）,Crystal,特征驅(qū)動開發(fā)（Feature Driven Development,簡稱FDD),以及最重要的極限編程（XP).極限編程是于1998年由Smalltalk社群中的大師級人物Kent Beck首先倡導(dǎo)的。Scrum和XP的區(qū)別SCRUM

2、和XP都是敏捷開發(fā)的方法論，都體現(xiàn)了快速反饋，強(qiáng)調(diào)交流，強(qiáng)調(diào)人的主觀能動性等基本原則，而且多數(shù)“最佳實踐活動”都互相適用。不同點：Scrum非常突出Self-Orgnization（管理）, XP注重強(qiáng)有力的工程實踐約束。在具體的應(yīng)用中可以將兩者結(jié)合，在管理模式上啟用Scrum， 而在實踐中，創(chuàng)造一個適合自己項目組的XP(“start with Scrum and then invent your own version of XP.”)Agile 方法的價值觀個人和交互高于過程和工具可運(yùn)行軟件高于詳盡的文檔與客戶協(xié)作高于合同（契約）談判對變更及時做出反應(yīng)高于遵循計劃個人和交互高于過程和工具

3、不是否定過程和工具的重要性，而是更強(qiáng)調(diào)軟件開發(fā)中人的作用和交流的作用。 軟件是由人組成的團(tuán)隊來開發(fā)的，與軟件項目相關(guān)的各類人員通過充分的交流和有效的合作，才能成功地開發(fā)出得到用戶滿意的軟件。 如果光有定義良好的過程和先進(jìn)的工具，而人員的技能很差，又不能很好地交流和協(xié)作，軟件是很難成功地開發(fā)的?？蛇\(yùn)行軟件高于詳盡的文檔 通過執(zhí)行一個可運(yùn)行的軟件來了解軟件做了什么，遠(yuǎn)比閱讀厚厚的文檔要容易得多。 敏捷軟件開發(fā)強(qiáng)調(diào)不斷地快速地向用戶提交可運(yùn)行的軟件（不一定是完整的軟件），以得到用戶的認(rèn)可。 好的必要的文檔仍是需要的，它能幫助我們理解軟件做什么，怎么做以及如何使用，但軟件開發(fā)的主要目標(biāo)是創(chuàng)建可運(yùn)行的軟

4、件與客戶協(xié)作高于合同（契約）談判 只有客戶才能明確說明需要什么樣的軟件，然而，大量的實踐表明，在開發(fā)的早期客戶常常不能完整地表達(dá)他們的全部需求，有些早期確定的需求，以后也可能會改變。 要想通過合同談判的方式，將需求固定下來常常是困難的。 敏捷軟件開發(fā)強(qiáng)調(diào)與客戶的協(xié)作，通過與客戶的交流和緊密合作來發(fā)現(xiàn)用戶的需求。對變更及時做出反應(yīng)高于遵循計劃 任何軟件項目的開發(fā)都應(yīng)該制訂一個項目計劃，以確定各開發(fā)任務(wù)的優(yōu)先順序和起止日期。然而，隨著項目的進(jìn)展，需求、業(yè)務(wù)環(huán)境、技術(shù)等都可能變化，任務(wù)的優(yōu)先順序和起止日期也可能因種種原因會改變。 因此，項目計劃應(yīng)具有可塑性，有變動的余地。當(dāng)出現(xiàn)變化時及時做出反應(yīng)，修

5、訂計劃以適應(yīng)變化。Scrum角色Scrum 角色產(chǎn)品負(fù)責(zé)人 Product Owner 產(chǎn)品負(fù)責(zé)人是利益相關(guān)方的代表，他的工作重點是產(chǎn)品的業(yè)務(wù)方面。他負(fù)責(zé)給出一份明確的，可度量的產(chǎn)品Backlog,并從業(yè)務(wù)角度出發(fā)對Backlog中各項問題按優(yōu)先級排序。 Scrum開發(fā)團(tuán)隊總是優(yōu)先開發(fā)對客戶具有較高價值的需求。產(chǎn)品經(jīng)理產(chǎn)品負(fù)責(zé)人Scrum 角色Scrum Master Scrum Master 是整個團(tuán)隊的導(dǎo)師和組織者，他負(fù)責(zé)提高團(tuán)隊的開發(fā)效率。 明確把握開發(fā)速度. 保證Scrum團(tuán)隊中各個角色及職責(zé)的良好協(xié)作。解決團(tuán)隊開發(fā)中的障礙。 作為團(tuán)隊和外部的接口，屏蔽外界對團(tuán)隊成員的干擾。 保證開發(fā)

6、過程按計劃進(jìn)行，組織每日站立，Sprint計劃會議,Sprint評審會議和Sprint回顧會議 項目經(jīng)理Scrum MasterSCRUM 角色團(tuán)隊 負(fù)責(zé)交付產(chǎn)品的團(tuán)隊。一個團(tuán)隊通常由5至9名具有跨 職能技能的人（設(shè)計者，開發(fā)人員等）組成，承擔(dān)實際的開發(fā)工作。 敏捷過程名詞解釋優(yōu)先級故事故事是客戶想要系統(tǒng)做的事情，適合在一至兩個迭代內(nèi)完成，并且是可測試的，他不一定是商業(yè)價值的直接體現(xiàn)迭代迭代是一個周期在2-4周，能夠完成當(dāng)前團(tuán)隊所能實現(xiàn)的，最具商業(yè)價值的功能，并可以提供一個可工作的小版本供發(fā)布優(yōu)先級主要考慮商業(yè)價值，同時兼顧市場風(fēng)險，商業(yè)風(fēng)險，技術(shù)風(fēng)險等因素在內(nèi)的一個衡量數(shù)字，優(yōu)先級越高通常意

7、味著其商業(yè)價值越高Product backlogProduct backlog它是由Product Owner負(fù)責(zé)制定的一個按照重要性的級別排序了的故事列表。名詞解釋負(fù)載因子理想時間實際時間任 務(wù)負(fù)載因子是綜合項目成員的技術(shù)能力，技能集，精神狀態(tài)等等因素，對于團(tuán)隊成員的一個負(fù)載系數(shù)。理想時間 排除一切可能的外界干擾，同時排除自身的精神狀態(tài)，職業(yè)態(tài)度等等因素，完成此項工作所需要的時間。 實際時間 理想時間乘上負(fù)載因子任務(wù) 分配到項目成員，從故事切分的出來。通常任務(wù)時間不應(yīng)該超過10個實際工作日。過程會議迭代會議發(fā)布計劃會議Sprint啟動會議站立會議評審會議回顧會議發(fā)布計劃會議程序 產(chǎn)品負(fù)責(zé)人準(zhǔn)

8、備產(chǎn)品backlog. 召開發(fā)布計劃會議工具 產(chǎn)品backlog目的 建立Scrum團(tuán)隊以及組織內(nèi)的其他部門能夠理解和溝通的計劃和目標(biāo)。成員 所有干系人 SPRINT 啟動會議程序 召開Sprint計劃會議工具 紙牌游戲目的 確認(rèn)Sprint Backlog.在會議中，產(chǎn)品負(fù)責(zé)人告訴團(tuán)隊產(chǎn)品Backlog中優(yōu)先級較高的項，Scrum 團(tuán)隊共同討論產(chǎn)品Backlog,一起決定接下來的一個迭代中開發(fā)那些功能，形成Sprint Backlog,并估算出Sprint backlog中每一項的開發(fā)時間，并進(jìn)行任務(wù)認(rèn)領(lǐng)紙牌游戲發(fā)牌講解BACKLOG出牌亮牌PKPK繼續(xù)出牌達(dá)成共識項目進(jìn)度跟蹤及時貼的格式進(jìn)

9、度白版評審會議目標(biāo) 向客戶和管理者報告項目進(jìn)度，小版本發(fā)布會議 增強(qiáng)團(tuán)隊自信心時間 迭代最后一天（或中間有交付物的時候進(jìn)行）與會人員 客戶的負(fù)責(zé)人，客戶和項目經(jīng)理，公司任何其他成員回顧會目標(biāo)目標(biāo) 回顧得失回顧得失時間時間 發(fā)布會議結(jié)束后發(fā)布會議結(jié)束后與會人員與會人員 全體程序員和項目經(jīng)理全體程序員和項目經(jīng)理備注備注 收集該類信息。作為下個迭代的回顧會收集該類信息。作為下個迭代的回顧會的參考的參考36如何進(jìn)行項目回顧 敏捷開發(fā)過程敏捷開發(fā)過程敏捷開發(fā)軟件設(shè)計劃分 特性: 對最終用戶有意義的一個功能用例:由特性分解而來的一個可以用來做功能測試的小情節(jié)任務(wù):用例分解而來,有開發(fā)人員需要完成的一個最小

10、的工作單元統(tǒng)一編碼規(guī)范 編碼規(guī)范主要應(yīng)包含以下幾個方面： 一般規(guī)則和格式規(guī)范。例如代碼縮進(jìn)、程序塊規(guī)范、每行最大代碼長度等。 命名規(guī)則。例如包名、類名、變量、方法、接口、參數(shù)等命名規(guī)范 文檔規(guī)范。例如類文件頭聲明、類注釋、成員變量和方法注釋等規(guī)范。 編程規(guī)范。例如異常、并發(fā)、多線程等方面的處理方式。 其他規(guī)范。例如日志格式、屬性文件格式，返回值和消息格式。 靜態(tài)代碼分析 利用一些靜態(tài)分析工具來快速、直接地提高代碼質(zhì)量。靜態(tài)代碼分析工具并不需要運(yùn)行代碼，可以直接對 Java、C#等 主流開發(fā)語言進(jìn)行分析，通過一些檢查條件的設(shè)置，快速找到代碼中的錯誤和潛在缺陷?，F(xiàn)在的靜態(tài)分析工具很多，有 Find

11、Bugs、Checkstyle 、 PMD、IBM Rational Tool，F(xiàn)xcop等等。單元測試單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認(rèn)該值出現(xiàn)在list 的尾部?；蛘?，你可能會從字符串中刪除匹配某種模式的字符，然后確認(rèn)字符串確實不再包含這些字符了。單元測試用例對提供團(tuán)隊整理開發(fā)效率都有比較大的提升，同時還能提高代碼質(zhì)量、減少程序缺陷。如果我們對測試用例的編寫把握不好的話，也會給開發(fā)效率帶來

12、一定的影響單元測試原則（一）為主要的、關(guān)鍵的邏輯組件，關(guān)鍵的邏輯方法進(jìn)行測試驅(qū)動開發(fā)，這樣對設(shè)計、設(shè)計演化很有幫助。結(jié)對編程的方式測試用例讓另一個同事來完成。更好的發(fā)現(xiàn)程序設(shè)計及接口設(shè)計中的一些缺陷。邏輯類似的組件如果存在多個，優(yōu)先編寫其中一種邏輯組件的測試用例，實踐中可能會出現(xiàn)一些組件在邏輯上可能完成差不多的功能(例如類型轉(zhuǎn)換幫助類)，可以先只編寫其中一種組件的 測試用例以節(jié)省時間。發(fā)現(xiàn) BugBug 時一定先編寫測試用例進(jìn)行 Debug，在測試和調(diào)試之間眾說紛紜，最好是先編寫測試用例找出這個 Bug，越復(fù)雜的系統(tǒng)，測試越發(fā)雜，單元測試能更好的模擬參數(shù)邊界值。單元測試原則（二）關(guān)鍵util工

13、具類要編寫測試用例，不要忽視了這些幫助類、基礎(chǔ)類的正確性和運(yùn)行效率。保持測試用例與邏輯代碼同步，這里說的”同步”主要包括了測試方法和實現(xiàn)方法的同步；測試用例注釋和邏輯代碼注釋的同步。 保證測試用例的獨(dú)立性，讓測試用例獨(dú)立的可執(zhí)行，盡量不要依賴其他其他的測試用例。這樣才能讓 TDD 與設(shè)計保持良好的協(xié)作。 測試過程中，適當(dāng)?shù)囊隡ock(模擬數(shù)據(jù)) 是必不可少的，最好還是提供一個集成測試用例。使用 Mock 可以讓接口的設(shè)計得到快速驗證與反饋，也對團(tuán)隊的平行開發(fā)提供便利。持續(xù)集成 持續(xù)集成（Continuous Integration）是利用一系列的工具，方法和規(guī)則，做到快速的構(gòu)建開發(fā)代碼，自動

14、的測試化，來提高開發(fā)代碼的效率和質(zhì)量。利用自動構(gòu)建工具，隨時都能把提交的代碼構(gòu)建出來，提供一個可以測試使用的版本，讓用戶和開發(fā)人員同時看到相同的功能，盡早的發(fā)現(xiàn)問題和錯誤，也可以盡快的得到測試人員和用戶的反饋。要做到持續(xù)集成，就要利用一系列工具，把開發(fā)過程中的重復(fù)工作自動化。搭建自動的構(gòu)建服務(wù)器，自動的進(jìn)行單元測試和發(fā)布新版本，一個集成的服務(wù)器可以提供構(gòu)建過程的結(jié)果報告，自動通知開發(fā)人員構(gòu)建結(jié)果，并且保存歷史數(shù)據(jù)。代碼評審和重構(gòu) 代碼評審（Code Review）是 項目開發(fā)過程中的一個重要步驟，代碼評審可以幫助發(fā)現(xiàn)靜態(tài)代碼分析過程中無法發(fā)現(xiàn)的一些問題，代碼評審主要包括兩種形式，同級評審（Pe

15、er Review）和小組評審（Group Review）。同級評審主要指項目成員間的互相評審，小組評審是指通過召開評審會議，項目成員一起對項目代碼進(jìn)行評審。通過代碼評審發(fā)現(xiàn)的問題要通過代碼重構(gòu)及時解決掉，較小的不涉及多人代碼的重構(gòu)可以由項目成員自己借助開發(fā)工具的重構(gòu)功能完成，不同項目成員寫的實現(xiàn)相同功能的不同代碼要通過討論整合成公共的類或者方法。比較復(fù)雜的或者比較高層次的重構(gòu)工作，例如整個項目層面的代碼組織形式的改變需要由整個項目組共同討論完成。 敏捷測試過程需求討論階段測試人員可以站在客戶角度上來闡述自己的觀點，和產(chǎn)品人員、開發(fā)人員等進(jìn)行充分的交流和討論，使自己在用戶體驗、業(yè)務(wù)邏輯等等方面的經(jīng)驗充分體現(xiàn)出來。任務(wù)分配確認(rèn)階段與開發(fā)人員一起編寫用戶故事的驗收測試用例，從測試和開發(fā)人員具體實現(xiàn)的角度對任務(wù)進(jìn)行細(xì)化，對可測試點和故事實現(xiàn)邊界進(jìn)行確認(rèn)。開發(fā)階段