統(tǒng)一軟件工程流程框架（Unified Software Engineering Process Framework）

“凡治眾如治寡馍迄，分?jǐn)?shù)是也尿庐；斗眾如斗寡玩祟，形名是也靡馁；三軍之眾饲嗽，可使畢受敵而無敗者，奇正是也奈嘿∶蚕海”
——《孫子兵法-兵勢第五》

如果我們把Coding能力很強(qiáng)，能夠憑一己之力搞定一切的程序員比作小說中武功高強(qiáng)的劍客裙犹，那么一支由多人組成的工程團(tuán)隊(duì)就必定是一支軍隊(duì)尽狠。如果我們把只有一個(gè)人的隊(duì)伍也看成是“團(tuán)隊(duì)”的特殊情況，那么對于這樣的“團(tuán)隊(duì)”而言叶圃，要想完成不那么復(fù)雜的任務(wù)袄膏，他/她只要把自己的個(gè)人技藝訓(xùn)練到爐火純青即可；但對于復(fù)雜到一定程度掺冠，要處理的事情千頭萬緒沉馆，需要各種專業(yè)技能才能完成的任務(wù)來說，就必須通過多人團(tuán)隊(duì)的方式來完成德崭。人多就一定力量大嗎斥黑？未必！就算是一支人數(shù)眾多眉厨，由各種各樣專業(yè)人才組成的隊(duì)伍锌奴，如果沒有接受過一定的工程化訓(xùn)練，就不可能做到實(shí)戰(zhàn)中如臂使指憾股，就會有敗亡的危險(xiǎn)鹿蜀。反過來，一支實(shí)戰(zhàn)經(jīng)驗(yàn)暫時(shí)不那么豐富服球，個(gè)人技能稍微要弱一些的隊(duì)伍茴恰，如果接受了一定的工程化訓(xùn)練，能夠在實(shí)戰(zhàn)中通力合作斩熊，形成合力往枣，那么他們每個(gè)人的力量就會得到加成，他們的經(jīng)驗(yàn)就會在實(shí)踐中得到鍛煉和加強(qiáng)，失敗的可能性就會降低婉商。因此在這個(gè)世界上似忧，只要有需要人和人之間相互協(xié)作來做成的事情，就一定存在著“系統(tǒng)工程”的思維方式丈秩。

軟件工程是人類認(rèn)識世界和改造世界的一個(gè)具體的領(lǐng)域盯捌，具有一定的客觀規(guī)律，是“把系統(tǒng)的蘑秽，有序的饺著，可量化的方法應(yīng)用到軟件的開發(fā)，運(yùn)營和維護(hù)上的過程”肠牲，它具有復(fù)雜性幼衰，不可見性，易變性缀雳，服從性和非連續(xù)性等固有屬性渡嚣。IT從業(yè)者有必要認(rèn)識和把握這樣一些規(guī)律和屬性，以增進(jìn)技藝肥印，更好地進(jìn)行軟件工程實(shí)踐活動识椰。本文在鄒欣老師的《構(gòu)建之法：現(xiàn)代軟件工程》一書的基礎(chǔ)上進(jìn)行總結(jié)和提煉，基于“敏捷軟件工程”和“微軟解決方案框架（MSF）”構(gòu)思了一套統(tǒng)一軟件工程流程框架深碱，因此可以把它看作是這本書的讀書筆記腹鹉。但正如鄒老師說的：“知識體系是構(gòu)建出來的，而不是接收到的敷硅。與其灌輸知識功咒，不如自己構(gòu)建”，于是我在學(xué)習(xí)的過程中有意識地嘗試把書中介紹的各種流程和方法串成一根線绞蹦，正所謂“陣而后戰(zhàn)力奋，兵法之常；運(yùn)用之妙坦辟，存乎于心”刊侯，要想達(dá)到“運(yùn)用之妙，存乎于心”的境界锉走，還是要從軟件工程的基本思維和基礎(chǔ)方法開始修煉起。這也是這篇文章的目的所在藕届。在任何社會活動中挪蹭，人是最重要和最關(guān)鍵的影響因素，因此下面我們就先來聊聊軟件工程師的個(gè)人戰(zhàn)術(shù)素養(yǎng)休偶。

一. 軟件工程師的個(gè)人戰(zhàn)術(shù)素養(yǎng)

IT行業(yè)是知識密集型行業(yè)梁厉，軟件工程師最大的職業(yè)風(fēng)險(xiǎn)就是被不斷出現(xiàn)的新技術(shù)淘汰。一方面，要掌握一些方法和技巧词顾，提高自己的工作效率八秃，尤其是交付的作品的質(zhì)量；另一方面肉盹，把節(jié)約出來的時(shí)間用于學(xué)習(xí)新知識和鍛煉身體昔驱。拓展出來的新技能和強(qiáng)健的體魄又能促進(jìn)個(gè)人價(jià)值的最大化，形成增益的良性循環(huán)上忍。下面我們就來談?wù)動嘘P(guān)軟件工程師個(gè)人戰(zhàn)術(shù)素養(yǎng)的兩個(gè)主要方面：開發(fā)能力和職業(yè)成長骤肛。

1.1 培養(yǎng)開發(fā)能力的幾個(gè)要素

1.1.1 測試驅(qū)動開發(fā)

軟件工程師首先要做到的就是對自己的代碼負(fù)責(zé)，不管是維護(hù)自己的個(gè)人項(xiàng)目也好窍蓝，是完成具體的工作任務(wù)也好腋颠，交出來的東西要盡量保證質(zhì)量好，讓別人讀完文檔就能直接拿來用吓笙。怎么保證呢淑玫？當(dāng)然是通過測試的方法來保證——軟件工程師一定要寫單元測試代碼，并與功能代碼一起維護(hù)面睛。單元測試的主要目的是使模塊的質(zhì)量得到穩(wěn)定的絮蒿，量化的保證，它還有一個(gè)額外的好處侮穿，就是提供了代碼使用的示例歌径，單元測試如果寫的特別完善，別的開發(fā)者甚至可以通過閱讀單元測試代碼來學(xué)習(xí)和掌握模塊的使用亲茅。比如下面這段Go語言單元測試代碼就展示了怎樣在CouchDB中保存一個(gè)大的文檔數(shù)據(jù)：

func TestCreateLargeDoc(t *testing.T) {
    var buf bytes.Buffer
    // 10MB
    for i := 0; i < 110*1024; i++ {
        buf.WriteString("0123456789")
    }
    doc := map[string]interface{}{"data": buf.String()}
    if err := testsDB.Set("large", doc); err != nil {
        t.Error(`db set error`, err)
    }
    doc, err := testsDB.Get("large", nil)
    if err != nil {
        t.Error(`db get error`, err)
    }
    if doc["_id"].(string) != "large" {
        t.Errorf("doc[_id] = %s, want large", doc["_id"].(string))
    }
    err = testsDB.DeleteDoc(doc)
    if err != nil {
        t.Error(`db delete doc error`, err)
    }
}

編寫單元測試需要遵循一些基本的規(guī)范：

• 在最基本的功能/參數(shù)上驗(yàn)證程序正確性
• 必須由最熟悉代碼的人（程序作者）來寫
• 測試過后相關(guān)狀態(tài)保持不變
• 測試速度要快回铛，幾秒鐘內(nèi)完成
• 測試產(chǎn)生可重復(fù)，一致的結(jié)果
• 獨(dú)立性：不依賴于別的測試克锣，可人為構(gòu)造數(shù)據(jù)保持測試獨(dú)立性
• 覆蓋所有代碼路徑茵肃，但100%的覆蓋率并不代表100%正確性，代碼覆蓋率對本該實(shí)現(xiàn)但并沒有實(shí)現(xiàn)的功能無能為力
• 能夠集成到自動測試框架中
• 和產(chǎn)品代碼一起保存和維護(hù)

測試前袭祟，我們要做一些必要的準(zhǔn)備（setup）验残，比如插入一些用于測試的樣例數(shù)據(jù)；測試后我們要清理相關(guān)數(shù)據(jù)（teardown）巾乳，使測試過后相關(guān)狀態(tài)保持不變您没。值得注意的是，現(xiàn)代編程語言一般都集成了自己的測試框架胆绊。以Go語言為例氨鹏，我們可以在一個(gè)叫TestMain()的函數(shù)中編寫我們自己的setup()和teardown()函數(shù)，并在二者之間運(yùn)行所有的單元測試代碼：

func TestMain(m *testing.M) {
    setup()
    code := m.Run()
    teardown()
    os.Exit(code)
}

Go語言規(guī)定了凡是以“test”結(jié)尾的代碼文件都是測試文件压状，所有的單元測試函數(shù)都以Test開頭仆抵，只要在命令行運(yùn)行go test命令就能自動運(yùn)行所有的單元測試并輸出結(jié)果，除此之外Go語言還可以編寫Example示例函數(shù)來展示函數(shù)用法，Godoc工具會使用相關(guān)的示例函數(shù)自動生成文檔镣丑，例如下面這個(gè)函數(shù)展示了標(biāo)準(zhǔn)庫中stringutil.Reverse()函數(shù)的使用方法：

func ExampleReverse() {
    fmt.Println(stringutil.Reverse("hello"))
    // Output: olleh
}

隨著模塊功能的演進(jìn)舔糖，相關(guān)的測試用例也在不斷演進(jìn)，這些測試用例集就構(gòu)成了模塊功能的基準(zhǔn)線莺匠。作為回歸測試（Regression Test）的基礎(chǔ)金吗，如果有任何一個(gè)測試用例失敗了，就說明模塊的功能從正常工作的穩(wěn)定狀態(tài)“回歸”到了不正常的不穩(wěn)定狀態(tài)慨蛙。這樣一來辽聊，不管是增加新功能還是修復(fù)bug，回歸測試就能確保新的代碼實(shí)現(xiàn)了期望的功能或者修復(fù)了bug期贫，而沒有破壞模塊原有的功能跟匆。

1.1.2 效能分析工具

除了沒有bug，軟件工程師通常還希望自己的代碼運(yùn)行的又快又好通砍，效率較高玛臂，那么除了必要的單元測試技能外，還需要掌握一定的效能分析工具封孙，這些效能分析工具能夠分析代碼運(yùn)行的整理情況迹冤，模塊和函數(shù)之間的調(diào)用關(guān)系拓?fù)鋱D，以及每個(gè)函數(shù)耗費(fèi)的時(shí)間虎忌，通過對這些數(shù)據(jù)進(jìn)行分析泡徙，我們就可以定位代碼運(yùn)行效率較低的位置，進(jìn)行有的放矢的優(yōu)化工作膜蠢。

1.1.3 重視個(gè)人開發(fā)流程的訓(xùn)練

卡耐基梅隆大學(xué)（CMU)的能力成熟度模型（CMMI)是用來衡量一個(gè)團(tuán)隊(duì)能力的一套模型堪藐。CMU的專家們對軟件工程師也有一套模型逞盆，叫個(gè)人軟件流程（PSP）大咱，PSP2.1展示了一個(gè)軟件工程師在接到一個(gè)任務(wù)后應(yīng)該怎么做：

1. 計(jì)劃：估計(jì)任務(wù)需要多少時(shí)間
2. 開發(fā)：分析需求，生成設(shè)計(jì)文檔靖苇，設(shè)計(jì)復(fù)審杉辙，代碼規(guī)范模捂，具體設(shè)計(jì)，具體編碼蜘矢，代碼復(fù)審狂男，測試
3. 報(bào)告：記錄用時(shí)，測試報(bào)告品腹，計(jì)算工作量并淋，事后總結(jié)并提出過程改進(jìn)計(jì)劃

有豐富經(jīng)驗(yàn)的工程師會在“需求分析”和“測試”這兩方面明顯地要花更多時(shí)間，但是在編碼上珍昨，要花更少的時(shí)間——花在寫代碼上的時(shí)間反而少了。從我維護(hù)個(gè)人開源項(xiàng)目的經(jīng)驗(yàn)上來看，分析需求镣典，生成文檔和測試花的時(shí)間是最多的兔毙。得先想清楚代碼編寫的思路，才能粗略估算完成這個(gè)任務(wù)需要多少時(shí)間兄春，特別是對于比較復(fù)雜的代碼澎剥，我會寫一篇文章詳細(xì)闡述關(guān)鍵代碼的設(shè)計(jì)思路，防止時(shí)間長了之后自己忘記當(dāng)初為什么要這樣寫了赶舆，然后我會將功能代碼和相關(guān)的測試代碼發(fā)布到Github上哑姚，并撰寫盡可能詳細(xì)的說明文檔。如果別的程序員對這個(gè)項(xiàng)目感興趣芜茵，他們就會通過各種方式和我交流叙量，個(gè)別極其認(rèn)真的還會提出代碼的設(shè)計(jì)缺陷和bug，這也就相當(dāng)于設(shè)計(jì)和代碼復(fù)審了九串，因此文檔作為一種交流工具非常重要绞佩。

1.1.4 二人戰(zhàn)斗小組

但如果是兩個(gè)開發(fā)人員組成一個(gè)小組的話，就可以做一些代碼復(fù)審的工作了猪钮。這在其他行業(yè)也經(jīng)常見到：

• 越野賽車（駕駛品山，領(lǐng)航員）
• 駕駛飛機(jī)（駕駛，副駕駛）
• 狙擊小組（狙擊手烤低，觀察手）

在軟件工程領(lǐng)域肘交，我們叫“結(jié)對編程”。在進(jìn)行結(jié)對編程前扑馁，兩位開發(fā)人員首先要達(dá)成共識——有關(guān)代碼風(fēng)格規(guī)范和設(shè)計(jì)規(guī)范的共識涯呻。風(fēng)格規(guī)范主要是文字上的一些規(guī)定，比如花括號的位置檐蚜，縮進(jìn)的大小或者函數(shù)的命名等等魄懂；設(shè)計(jì)規(guī)范牽涉程序設(shè)計(jì)，模塊間關(guān)系和設(shè)計(jì)模式等方方面面闯第。

達(dá)成共識后市栗，兩位開發(fā)人員就可以開始正式的結(jié)對編程活動了，他們分別扮演駕駛員和領(lǐng)航員的角色咳短，前者控制鍵盤輸入填帽，后者起領(lǐng)航和提醒作用。具體來說咙好，駕駛員寫設(shè)計(jì)文檔篡腌，進(jìn)行編碼和單元測試，而領(lǐng)航員審閱文檔和編碼勾效，考慮單元測試的覆蓋嘹悼，思考是否需要和如何重構(gòu)叛甫，幫助駕駛員解決具體技術(shù)問題。注意駕駛員和領(lǐng)航員要不斷地輪換角色杨伙，任何一個(gè)人不要扮演同樣角色超一個(gè)其监，每工作一小時(shí)休息15分，由領(lǐng)航員控制限匣。在結(jié)對編程的活動中抖苦，任何一個(gè)任務(wù)首先都是兩個(gè)人的責(zé)任，要主動參與——大家只有水平上的差距米死，沒有級別上的差異锌历，擁有平等決策權(quán)利。

結(jié)對編程有很多好處峦筒，首先兩人合作解決問題究西，能夠提更好的設(shè)計(jì)質(zhì)和代碼質(zhì)量，這會給大家?guī)硇判目碧欤哔|(zhì)量產(chǎn)出帶來更高滿足感怔揩。這也有利于促進(jìn)團(tuán)隊(duì)成員之間的更有效交流：相互學(xué)習(xí)和傳遞經(jīng)驗(yàn)，分享知識脯丝。最后商膊，結(jié)對編程還能帶來不間斷的復(fù)審——看代碼是否在“代碼規(guī)范”的框架內(nèi)正確地解決了問題，越早發(fā)現(xiàn)問題越好宠进，越是項(xiàng)目后期發(fā)現(xiàn)的問題晕拆，修復(fù)的代價(jià)越大。同伴復(fù)審可作為自我復(fù)審和團(tuán)隊(duì)復(fù)審的一個(gè)有效的補(bǔ)充形式材蹬。復(fù)審的目的在找出代碼錯(cuò)誤实幕，發(fā)現(xiàn)邏輯和算法錯(cuò)誤，發(fā)現(xiàn)潛在錯(cuò)誤和回歸性錯(cuò)誤堤器，發(fā)現(xiàn)可能需要改進(jìn)的地方昆庇，以及互相教育傳授經(jīng)驗(yàn)，促進(jìn)團(tuán)隊(duì)成員熟悉項(xiàng)目各部分代碼闸溃，熟悉應(yīng)用領(lǐng)域相關(guān)實(shí)際知識整吆。復(fù)審的一個(gè)標(biāo)準(zhǔn)流程如下：

1. 代碼必須采用最嚴(yán)格編譯警告等級成功編譯，必要時(shí)提供Debug/Retail版本辉川；
2. 程序員必須測試過并提供新的代碼表蝙；
3. 復(fù)審者選擇復(fù)審方式：面對面，獨(dú)立復(fù)審或者其他方式乓旗；
4. 開發(fā)者控制流程府蛇，講述修改的前因后果，復(fù)審者有權(quán)在任何時(shí)候打斷敘述屿愚，給出自己意見汇跨；
5. 復(fù)審者逐一提供反饋意見务荆，開發(fā)者有義務(wù)給出詳盡回答；
6. 開發(fā)者負(fù)責(zé)確保所有問題得到滿意的解釋或解答扰法，或確保這些問題得到處理蛹含；
7. 最后，達(dá)成復(fù)審結(jié)果一致意見：
   • 若發(fā)現(xiàn)致命問題塞颁，則打回，解決之前不能簽入吸耿；
   • 若發(fā)現(xiàn)一些小問題祠锣，可有條件同意（不需復(fù)審，修改后簽入）咽安；
   • 代碼可以不加新改動伴网，直接簽入；
8. 復(fù)審后整理記錄妆棒，更正明顯的錯(cuò)誤澡腾，對無法很快更正的錯(cuò)誤記錄下來形成bug report，開發(fā)把所有錯(cuò)誤記錄在“我常犯的錯(cuò)誤”表中糕珊，作為自我復(fù)審參考：
   • 癥狀：從用戶角度看动分，軟件出現(xiàn)了什么問題？
   • 程序錯(cuò)誤：從代碼的角度看红选，代碼的什么錯(cuò)誤導(dǎo)致了軟件問題澜公？
   • 根本原因：導(dǎo)致代碼錯(cuò)誤的根源是什么？

1.1.4.1 如何影響對方

影響對方的方式有四種：

1. 斷言（Assertion）：“就這樣吧喇肋，聽我的坟乾，沒錯(cuò)”，感情強(qiáng)烈蝶防，適用于有充分信任的同伴甚侣；
2. 橋梁（Bridge）：“能不能再給我講講你的理由……”，給雙方充分條件互相了解间学；
3. 說服（Persuasion）：“如果我們這樣做殷费，根據(jù)我的分析，我們會有這樣的好處……”菱鸥，有條理宗兼，建立在邏輯分析基礎(chǔ)上，即時(shí)不能完全說服氮采，對方也可能部分接受殷绍；
4. 吸引（Attraction）：“你想過舒適生活么？你想在家里發(fā)財(cái)么鹊漠？加入我們吧主到，幾個(gè)月后就能有上萬收入”茶行，有效地傳遞信息，但要注意信息準(zhǔn)確性登钥，夸大渲染會降低個(gè)人可信度畔师；

1.1.4.2 如何正確給予反饋

評論別人有三種層次：

1. 最外：評論別人的行為和結(jié)果，對方較容易接受：行為可以改正牧牢，后果可以彌補(bǔ)看锉，有挽回局面的機(jī)會；
2. 中間：評論別人的習(xí)慣和動機(jī)塔鳍，對方較難接受：比較難表白和澄清動機(jī)伯铣，容易引起誤會；
3. 最內(nèi)：評論別人的本質(zhì)和固有屬性轮纫，對方很難接受：無法回應(yīng)腔寡，容易引起沖突和矛盾；

因此如果我們要正確地給予同伴反饋掌唾，既要正確地反饋信息讓對方接受放前，又要避免對方造成誤會引起矛盾，可以采取“三明治方法“：

1. 做好鋪墊（面包）：強(qiáng)調(diào)雙方的共同點(diǎn)糯彬，從團(tuán)隊(duì)共同愿景講起凭语，讓對方覺得處于一個(gè)安全環(huán)境；
2. 建設(shè)性意見（肉）：少沉溺于過去情连，多展望將來叽粹，“過去你做的不夠，但我們以后可以做的更好”却舀；
3. 呼應(yīng)開頭虫几，鼓勵(lì)對方把工作做好（面包）；

當(dāng)然挽拔，也不是所有的情況下結(jié)對編程都適用辆脸。首先，處于探索階段的項(xiàng)目需要深入思考螃诅，不適合進(jìn)行結(jié)對編程啡氢；其次，后期維護(hù)時(shí)术裸，若技術(shù)含量不高倘是，只需要有效復(fù)審即可；另外袭艺，對于要運(yùn)行很長時(shí)間的驗(yàn)證測試搀崭，兩個(gè)人坐在那里等待結(jié)果也比較耽誤時(shí)間；然后如果團(tuán)隊(duì)成員在多個(gè)項(xiàng)目中工作猾编，也不能充分保證足夠的結(jié)對編程時(shí)間瘤睹；最后升敲，結(jié)對編程需要最大限度發(fā)揮領(lǐng)航員作用，若用處不大轰传，則無需結(jié)對驴党。

1.2 工程師的職業(yè)成長路徑

1.2.1 個(gè)人能力的培養(yǎng)

工程師個(gè)人能力的培養(yǎng)主要包含4個(gè)方面。首先是技術(shù)能力获茬，即軟件開發(fā)技能港庄，包括對具體技術(shù)的掌握（編程語言和開發(fā)平臺等），動手能力（能夠診斷/提高效能）以及軟件工程思想锦茁；其次是領(lǐng)域知識的積累攘轩，包括問題領(lǐng)域的知識和經(jīng)驗(yàn)，據(jù)說有些開發(fā)財(cái)務(wù)軟件的公司要求自己的開發(fā)人員通過注冊會計(jì)師考試码俩；然后是一定的職業(yè)技能，包括：

1. 自我管理能力：時(shí)間管理和解決問題的思維能力
2. 學(xué)習(xí)能力：
   • π型人才：在哪幾個(gè)方面追求“專和精”歼捏，在哪幾個(gè)方面追求“知道就好”
   • 如何學(xué)習(xí)：知識是構(gòu)建出來的稿存，刻意練習(xí)構(gòu)建心智模型（mindset）
3. 表達(dá)和交流能力：能說會寫
4. 與人合作能力
5. 按時(shí)按質(zhì)量交付任務(wù)能力
   • 項(xiàng)目/任務(wù)有多大：代碼行數(shù)和功能點(diǎn)數(shù)
   • 花了多少時(shí)間：人數(shù) * 時(shí)間
   • 質(zhì)量如何：交付的代碼有多少缺陷？缺陷數(shù)量除以項(xiàng)目大小是多少瞳秽？
   • 是否按時(shí)交付：實(shí)際用時(shí)的平均值和標(biāo)準(zhǔn)差（推崇穩(wěn)定瓣履，一致的交付時(shí)間）

最后，工程師一定要重視自己的實(shí)際工作成果：

1. 參與的產(chǎn)品用戶評價(jià)如何练俐？
2. 市場占有率如何袖迎？
3. 對用戶有多大價(jià)值？
4. 你在其中起了什么作用腺晾？
5. 參與開源項(xiàng)目燕锥，為開源社區(qū)做貢獻(xiàn)？

平時(shí)要有意識地訓(xùn)練自己使用STAR原則描述自己的工作：

1. Situation（情景）：簡單項(xiàng)目背景悯蝉，比如規(guī)模归形，軟件功能和目標(biāo)用戶；
2. Task（任務(wù)）：自己完成的任務(wù)鼻由，要分清楚“參與”和“負(fù)責(zé)”暇榴；
3. Action（行動）：為了完成任務(wù)做了哪些工作，怎么做的蕉世；
4. Result（結(jié)果）：得到了什么成果蔼紧，滿足了什么需求，有什么貢獻(xiàn)狠轻；

1.2.2 工程師的職業(yè)發(fā)展

1.2.2.1 認(rèn)證考試

軟件工程師可以參加一些認(rèn)證考試來證明和提高自己的職業(yè)技能奸例。比如軟件工程師的職業(yè)資格考試——“全國計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格考試”，或者參加一些公司的職業(yè)認(rèn)證項(xiàng)目哈误，比如“紅帽認(rèn)證工程師（Red Hat Certified Engineer）”哩至。目前網(wǎng)上有大量的在線教育網(wǎng)站躏嚎，提供各種MOOC課程，比較有名的有Coursera和Udacity菩貌。還有“中國計(jì)算機(jī)協(xié)會計(jì)算機(jī)職業(yè)資格認(rèn)證考試”和“浙江大學(xué)計(jì)算機(jī)程序設(shè)計(jì)能力考試”卢佣。

1.2.2.2 職業(yè)成長

在一般的大公司中，軟件工程師的職業(yè)成長路徑如下所示：

1. SDE（初級軟件開發(fā)工程師）箭阶；
2. SDE II（中級軟件開發(fā)工程師）虚茶；
3. Senior SDE（高級軟件開發(fā)工程師）；
4. Principal SDE（高級軟件開發(fā)工程師）仇参；
5. Partner SDE嘹叫，Distinguished Engineer，Technical Fellow诈乒；

軟件工程師們平時(shí)要努力提高自己的單兵戰(zhàn)術(shù)素養(yǎng)罩扇，多學(xué)習(xí)，多實(shí)踐怕磨，練好基本功喂饥，打好扎實(shí)的基礎(chǔ)，才能在團(tuán)隊(duì)中發(fā)揮自己的作用肠鲫，創(chuàng)造獨(dú)一無二的價(jià)值员帮。有了良好的戰(zhàn)術(shù)素養(yǎng)作為基礎(chǔ)，才能有效地實(shí)施軟件工程的工作流程导饲，下面我們就正式展開對相關(guān)流程的敘述捞高。內(nèi)容分為兩個(gè)部分：戰(zhàn)略層和戰(zhàn)役層。戰(zhàn)略層主要介紹的是軟件工程的“構(gòu)思”和“計(jì)劃”渣锦，而戰(zhàn)役層面則主要介紹軟件工程的“開發(fā)”硝岗，“穩(wěn)定”和“部署”。

二. 軟件工程的實(shí)施（戰(zhàn)略層）

2.1 構(gòu)思階段（Envisioning Phase）

構(gòu)思階段要完成2個(gè)主要工作：根據(jù)項(xiàng)目實(shí)際情況組建開發(fā)團(tuán)隊(duì)泡挺，并編寫用戶故事辈讶，形成最初的產(chǎn)品待辦事項(xiàng)清單。

2.1.1 組建團(tuán)隊(duì)

一支完整的團(tuán)隊(duì)包括3個(gè)組成部分：產(chǎn)品負(fù)責(zé)人娄猫，開發(fā)團(tuán)隊(duì)和客戶（團(tuán)隊(duì)）贱除。開發(fā)團(tuán)隊(duì)由具有各種不同技術(shù)棧的開發(fā)人員組成，理想情況下媳溺，可根據(jù)項(xiàng)目的實(shí)際情況靈活組建月幌。

2.1.1.1 產(chǎn)品負(fù)責(zé)人

“過程創(chuàng)新可能超越產(chǎn)品創(chuàng)新，但兩個(gè)創(chuàng)新并駕齊驅(qū)則勝于任何一個(gè)悬蔽〕短桑” ——著名用戶體驗(yàn)專家比爾.巴克斯頓

產(chǎn)品管理是根據(jù)市場和用戶需求協(xié)調(diào)各部門資源（產(chǎn)品定位，市場發(fā)展，需求分析录语，運(yùn)營倍啥，營銷，市場推廣澎埠，商務(wù)合作）虽缕，正確把握產(chǎn)品定位和方向，確保團(tuán)隊(duì)理解商業(yè)目標(biāo)和客戶需求蒲稳，解決用戶痛點(diǎn)氮趋；溝通，計(jì)劃江耀，收集內(nèi)外用戶反饋剩胁，持續(xù)優(yōu)化產(chǎn)品的過程。項(xiàng)目管理則主要關(guān)注于如何領(lǐng)導(dǎo)軟件開發(fā)過程祥国，這需要和人以及管理流程打交道昵观，以調(diào)配各部門資源和時(shí)間，處理和應(yīng)對不確定性舌稀，正確地協(xié)調(diào)團(tuán)隊(duì)內(nèi)部外部索昂，形成團(tuán)隊(duì)風(fēng)格。此外扩借，按預(yù)算和計(jì)劃管理項(xiàng)目，有效進(jìn)行風(fēng)險(xiǎn)管理也是項(xiàng)目管理的一部分缤至，對項(xiàng)目開發(fā)而言潮罪，風(fēng)險(xiǎn)管理有四個(gè)層次：

1. 第一層次：沒有風(fēng)險(xiǎn)管理，突發(fā)事件沒有預(yù)案领斥，事后進(jìn)行危機(jī)管理嫉到；
2. 第二層次：緩和并防止，動員相關(guān)方面（團(tuán)隊(duì)成員月洛，管理層和合作伙伴）一起想辦法防止事故發(fā)生何恶，進(jìn)行風(fēng)險(xiǎn)流程管理：
   • 沖刺階段不允許修改任何需求
   • 快速迭代，增量改進(jìn)
   • 結(jié)對編程增加團(tuán)隊(duì)對代碼的了解
3. 第三層次：定量的準(zhǔn)備和預(yù)計(jì)嚼黔；
4. 第四層次：將問題變?yōu)闄C(jī)會细层；

要成為產(chǎn)品負(fù)責(zé)人，對能力有很高的要求唬涧。首先疫赎，他/她必須能夠觀察，理解和快速學(xué)習(xí)碎节，具有同理心和自省能力捧搞。其次還要有“理解和表達(dá)”的專業(yè)能力，要能理解不同人心理，需求和言外之意胎撇，要能借助文字介粘，圖表，草圖甚至代碼來清晰準(zhǔn)確表達(dá)自己想法晚树。然后要能夠滿懷希望向用戶兜售產(chǎn)品姻采，向團(tuán)隊(duì)兜售希望，要能玩轉(zhuǎn)各種工具题涨，有文字功底偎谁，平時(shí)有大量的閱讀。每天項(xiàng)目中發(fā)生的事情千頭萬緒纲堵，產(chǎn)品負(fù)責(zé)人要能分析并抓住重點(diǎn)巡雨，找到優(yōu)先級，根據(jù)重要+緊急四象限做判斷和決策席函。

作為產(chǎn)品負(fù)責(zé)人铐望，他/她的具體任務(wù)是帶領(lǐng)團(tuán)隊(duì)達(dá)成最重要的目標(biāo)/愿景，保持“功能好茂附，資源省正蛙，時(shí)間快”的合理平衡。然后把抽象的目標(biāo)轉(zhuǎn)化為可執(zhí)行的营曼，具體的和優(yōu)美的設(shè)計(jì)乒验。要代表客戶和用戶的利益，主動收集用戶反饋蒂阱，預(yù)期用戶新需求锻全，管理用戶需求的收集，分析和優(yōu)先級排序录煤。跟蹤項(xiàng)目的進(jìn)展鳄厌，管理軟件具體功能的生命周期，分析并帶領(lǐng)其他成員對缺陷/變更需求形成一致意見妈踊。收集團(tuán)隊(duì)項(xiàng)目管理和軟件工程的各項(xiàng)數(shù)據(jù)了嚎，客觀分析實(shí)施過程中的優(yōu)缺點(diǎn)，推動項(xiàng)目成員持續(xù)改進(jìn)廊营，并提振士氣歪泳，最后確保團(tuán)隊(duì)發(fā)布的是令客戶滿意的軟件。

2.1.1.2 開發(fā)團(tuán)隊(duì)

開發(fā)團(tuán)隊(duì)主要的組成人員就是軟件工程師赘风，但我們可以根據(jù)經(jīng)驗(yàn)的豐富程度和分工的不同分為以下幾種角色：系統(tǒng)架構(gòu)師夹囚，軟件工程師，測試工程師邀窃，運(yùn)維工程師和UI/UX設(shè)計(jì)師荸哟，若團(tuán)隊(duì)人數(shù)眾多假哎，則可根據(jù)實(shí)際情況拆分為角色小組。開發(fā)團(tuán)隊(duì)的價(jià)值在于持續(xù)交付滿足用戶商業(yè)價(jià)值的軟件鞍历，其具體任務(wù)為：

1. 完成具體的開發(fā)工作
2. 負(fù)責(zé)軟件開發(fā)全階段與測試有關(guān)的數(shù)據(jù)收集
3. 設(shè)計(jì)舵抹，實(shí)現(xiàn)和維護(hù)測試環(huán)境
4. 計(jì)劃和管理產(chǎn)品部署解決方案

2.1.2 敏捷需求管理

與其它基于場景和用例的需求管理方法不同，敏捷開發(fā)的需求管理是以“用戶故事（User Story）”為中心的劣砍。用戶故事從用戶的角度出發(fā)惧蛹，描述了對用戶，系統(tǒng)或軟件購買者有價(jià)值的功能刑枝。它包含三個(gè)核心組成成分香嗓，簡稱3C：

1. 卡片（Card）：故事描述，用于做計(jì)劃和作為提示装畅；
2. 對話（Conversation）：用于具體化故事細(xì)節(jié)靠娱；
3. 確認(rèn)（Confirmation）：驗(yàn)收測試，用于表達(dá)和文檔化故事細(xì)節(jié)掠兄，并用于確認(rèn)完成像云；

卡片包含故事的文字描述，需求細(xì)節(jié)在“對話”中獲得蚂夕，并在“確認(rèn)”部分得以記錄迅诬。整個(gè)需求管理的過程從“用戶角色建模”開始婿牍，中間經(jīng)歷“搜集用戶故事”的過程侈贷，以“編寫用戶故事”結(jié)束，最后得到最初的產(chǎn)品待辦事項(xiàng)清單（Product Backlog）等脂。

2.1.2.1 用戶角色建模

為什么我們要對用戶角色進(jìn)行建模铐维？因?yàn)槭褂梦覀冘浖挠脩艨赡苡胁煌谋尘埃⒊钟胁煌哪繕?biāo)慎菲。要想搜集用戶的需求，我們要做的第一步工作就是先要弄清楚有哪些用戶會使用我們的系統(tǒng)锨并，把他們挖掘出來，然后以用戶角色為中心發(fā)散開來，根據(jù)不同的用戶角色搜集和編寫用戶故事蔫耽。在用戶角色建模的過程中放仗，我們首先要進(jìn)行頭腦風(fēng)暴會議，列出初始的用戶角色集合包警，會議的參與人員主要是客戶和開發(fā)人員（多多益善）撵摆，每個(gè)人盡量寫出自己想到的角色，然后大聲說出新角色的名字害晦，要注意的是一個(gè)用戶角色應(yīng)該是一個(gè)用戶的個(gè)體特铝，即個(gè)人暑中。我們要做的第二步工作是整理最初的角色集合：移動卡片位置以表明角色之間的關(guān)系，對于有重疊的角色鲫剿，把它們相應(yīng)的卡片也疊放在一起鳄逾，如果角色有一點(diǎn)點(diǎn)重疊，那么卡片也只重疊一點(diǎn)點(diǎn)灵莲；如果角色完全重疊雕凹，那么卡片也完全重疊。第三步工作是整個(gè)角色政冻，從重疊的卡片入手枚抵，合并等同的角色，丟棄對系統(tǒng)成功不太重要的角色明场，角色整合完成后汽摹，排列它們以展示角色之間的關(guān)系。最后一步榕堰，我們對角色進(jìn)行提煉竖慧，列舉所有可以區(qū)分這個(gè)角色的信息，包括用戶使用軟件的頻率逆屡，用戶在相關(guān)領(lǐng)域的知識水平圾旨，用戶使用計(jì)算機(jī)和軟件的總體水平，用戶對當(dāng)前正在開發(fā)的軟件的熟悉程度魏蔗，以及用戶使用該軟件的總體目標(biāo)砍的，有些用戶注重使用的便捷性，有些則關(guān)注豐富的用戶體驗(yàn)莺治。如果有需要的話廓鞠，我們還可以采取一些額外的技術(shù)，比如創(chuàng)建“虛構(gòu)人物”或者“極端人物”谣旁。

2.1.2.2 搜集用戶故事

在開始搜集用戶故事之前床佳，我們首先要對“用戶需求”有一個(gè)全面正確的認(rèn)識。我們要認(rèn)識到榄审，需求有多種類型：產(chǎn)品功能性需求砌们，產(chǎn)品開發(fā)過程需求，非功能性需求搁进，綜合需求等等浪感。用戶的需求并不是“引出”或“捕捉”到的，很多需求并不容易想到饼问，用戶也并不知道所有需求影兽，甚至用戶自己都不知道自己有這樣的需求。

一種比較好的比喻莱革，是將用戶需求比喻成“魚”——需要通過拖網(wǎng)捕撈（trawling）捕捉到峻堰。首先讹开，不同網(wǎng)眼的漁網(wǎng)能夠捕獲不同大小的需求（用商業(yè)價(jià)值高低或必要性程度衡量），第一遍捕撈獲得的是大需求茧妒，第二遍捕撈獲得的是中等大小的需求萧吠；其次，需求會像魚一樣不斷演進(jìn)桐筏，會成長纸型，也可能會死亡：有些需求會變得越來越重要，有些需求重要性會降低梅忌；第三狰腌，不可能捕捉到所有的需求，“廢棄的貨物”或“漂浮的殘骸”會使需求膨脹牧氮；最后琼腔，技能也是發(fā)現(xiàn)需求的一個(gè)要素，熟練的需求分析人員知道到哪去找需求踱葛，不熟練的需求分析人員只會用低效的方法或在錯(cuò)誤的地方浪費(fèi)時(shí)間丹莲。

搜集用戶需求的方法有很多種，常用的如下：

1. 焦點(diǎn)小組：找到一群目標(biāo)用戶的代表尸诽，加上項(xiàng)目的利益相關(guān)者來討論用戶想要什么甥材，用戶對軟件的評價(jià)等等；
2. 用戶訪談：通過開放式問題和背景無關(guān)問題性含，通過提問獲取用戶本質(zhì)需求洲赵；
3. 用戶調(diào)查問卷：向用戶提供事先規(guī)定好的問題，讓用戶回答商蕴；
4. 用戶日志研究：用戶記錄自己的日常工作或生活中與所用軟件相關(guān)的行為叠萍，供軟件團(tuán)隊(duì)分析；
5. 人類學(xué)調(diào)查：和目標(biāo)用戶生活在一起绪商，“同吃同住同勞動”苛谷；
6. 眼動跟蹤研究：跟蹤和研究用戶視覺的移動方向；
7. 快速原型調(diào)研：做一個(gè)產(chǎn)品原型格郁，快速獲取用戶反饋抄腔；
8. A/B測試：在5%-10%用戶上試驗(yàn)兩種不同產(chǎn)品（通常是原有產(chǎn)品和改進(jìn)型產(chǎn)品），收集數(shù)據(jù)并分析得到結(jié)論理张；
9. 用戶觀察：觀察用戶使用軟件的情況；
10. 故事編寫工作坊：開發(fā)人員绵患，用戶雾叭，產(chǎn)品客戶和其他對編寫故事有幫助的人共同參加的會議，編寫盡可能多的故事落蝙；

對于一個(gè)項(xiàng)目來說织狐，客戶團(tuán)隊(duì)里包含一個(gè)或多個(gè)真實(shí)用戶是極其重要的暂幼。遺憾的是在很多時(shí)候，我們很難有機(jī)會與實(shí)際用戶一起工作移迫，那么我們就需要求助于用戶代理旺嬉，他們自己可能不是用戶，但他們在項(xiàng)目里代表著用戶厨埋。最理想的用戶代理邪媳，是該軟件以前的用戶，以及能夠與用戶密切交流的客戶荡陷。選擇合適的用戶代理時(shí)我們要注意甄別對象雨效。用戶的經(jīng)理和開發(fā)經(jīng)理是不太理想的對象，較理想的對象還有以下幾種废赞，但他們作為用戶代理需要注意各自的一些問題：

1. 市場營銷團(tuán)隊(duì)：必須克服只關(guān)注軟件功能數(shù)量而不是質(zhì)量的問題徽龟；
2. 銷售人員：避免把重點(diǎn)放在贏回失去訂單的用戶故事上；
3. 領(lǐng)域?qū)＜遥罕苊鈱a(chǎn)品開發(fā)成只適合專家水平的人使用唉地；
4. 培訓(xùn)師和技術(shù)支持：避免只關(guān)注產(chǎn)品中那些他們每天關(guān)心的方面据悔；
5. 業(yè)務(wù)分析師和系統(tǒng)分析師：避免空想，以及在項(xiàng)目前期花太多時(shí)間耘沼；

那么在和用戶代理合作時(shí)能做些什么呢极颓？如果能夠接觸到用戶但訪問受限，我們可以請求準(zhǔn)許啟動一個(gè)用戶顧問團(tuán)隊(duì)耕拷，顧問團(tuán)隊(duì)可以提出意見和建議讼昆，而用戶代理依然是項(xiàng)目的最終決策者。如果實(shí)在接觸不到用戶骚烧，可以使用多個(gè)不同類型的用戶代理浸赫，或者盡早發(fā)布產(chǎn)品，及早將軟件交付到用戶手里赃绊，看看用戶的反應(yīng)既峡。或者碧查，做競品分析：大多數(shù)情況下市面上不會只有一款產(chǎn)品為用戶服務(wù)运敢，我們還可以對已有的產(chǎn)品進(jìn)行競品分析，有一種競品分析的方法被稱為“NABCD競爭性需求分析框架”：

1. Need：你的創(chuàng)意解決了用戶的什么需求忠售？
2. Approach：你有什么獨(dú)特的招數(shù)來解決用戶的痛苦传惠？
3. Benefit：這個(gè)產(chǎn)品/服務(wù)會給客戶/用戶帶來什么好處？
4. Competitors：這個(gè)市場有多大稻扬？目前有多少競爭者卦方？我方優(yōu)勢在哪里？我方劣勢在哪里泰佳？
5. Delivery：怎樣把你的創(chuàng)新產(chǎn)品交到用戶的手中盼砍？

應(yīng)該將客戶團(tuán)隊(duì)建立成一個(gè)優(yōu)勢互補(bǔ)的團(tuán)隊(duì)尘吗，一位成員的優(yōu)勢能平衡另一位成員的弱勢，建立客戶團(tuán)隊(duì)有三步：

1. 第一步：邀請不同類型的真實(shí)用戶加入浇坐；
2. 第二步：在客戶團(tuán)隊(duì)中確定一位“項(xiàng)目負(fù)責(zé)人”睬捶；
3. 第三步：確定項(xiàng)目成功必須的關(guān)鍵因素。

2.1.2.3 編寫用戶故事

優(yōu)秀的用戶故事具有6個(gè)特征近刘，我們統(tǒng)稱為“INVEST”擒贸。用戶故事是獨(dú)立的（Independent），我們要避免故事之間產(chǎn)生相互依賴跌宛，一種方法是將相互依賴的故事合并成一個(gè)大的酗宋，獨(dú)立的故事，或者用一個(gè)不同的方式去分割故事疆拘，假如你不想合并故事蜕猫，但又找不到好的方法來分割它，就還可以使用一個(gè)簡單的方法哎迄，對用戶故事進(jìn)行兩個(gè)估計(jì)：該故事早于另一個(gè)故事實(shí)現(xiàn)時(shí)回右，一個(gè)較高估計(jì)，該故事晚于另一個(gè)故事實(shí)現(xiàn)時(shí)漱挚，一個(gè)較低估計(jì)翔烁。用戶故事是可討論的（Negotiable），它是功能的簡短描述：一兩句短語旨涝，用來提醒開發(fā)人員和客戶進(jìn)行對話蹬屹，一些注釋，用以表明在對話中需要解決的問題白华。細(xì)節(jié)在客戶團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)的討論中產(chǎn)生慨默，討論中確定的細(xì)節(jié)將變成測試。用戶故事是對用戶或客戶有價(jià)值的（Valuable to Purchasers or Users）弧腥，要站在用戶或客戶的角度編寫故事厦取，避免出現(xiàn)技術(shù)的實(shí)現(xiàn)細(xì)節(jié)。用戶故事是可估計(jì)的（Estimatable）管搪，用戶故事難以估計(jì)是有各種原因的虾攻，一個(gè)原因是因?yàn)殚_發(fā)人員缺少領(lǐng)域知識——開發(fā)人員不理解故事，這個(gè)時(shí)候就需要和寫故事的客戶一起討論更鲁，爭取對故事有個(gè)大概的了解霎箍，但沒有必要理解所有細(xì)節(jié)，另一個(gè)原因是因?yàn)殚_發(fā)人員缺少技術(shù)知識——開發(fā)人員不掌握所涉及的技術(shù)澡为，這個(gè)時(shí)候可以采取“探針試驗(yàn)”的方法：將一個(gè)故事拆分為兩個(gè)部分漂坏，一個(gè)快速的探針故事，用來進(jìn)行技術(shù)預(yù)研獲取足夠的信息，另一個(gè)故事樊拓，用來真正實(shí)現(xiàn)功能。反過來塘慕，如果故事太大了筋夏，可以分解為多個(gè)更小的故事，或者留作史詩故事（Epic）：系統(tǒng)中有待討論的一大塊功能的占位符图呢。用戶故事是小的（Small）条篷，這里的小是指合理大小。一方面蛤织，太小的故事要做合并赴叹，另一方面，我們要對史詩故事進(jìn)行分割指蚜，對于多個(gè)小故事組成的復(fù)合故事乞巧，可以按動作（創(chuàng)建，編輯和刪除等等）分割摊鸡，也可以按數(shù)據(jù)邊界分割绽媒；對于本身很大不容易分解的復(fù)雜故事，則需要消除其不確定性免猾，將其分為調(diào)研故事和開發(fā)故事是辕，并放到不同迭代里。用戶故事是可測試的（Testable）猎提，要盡量實(shí)現(xiàn)測試自動化获三，成功通過測試可以證明開發(fā)人員正確地實(shí)現(xiàn)了故事。

編寫優(yōu)秀的用戶故事有一系列準(zhǔn)則锨苏。從目標(biāo)故事開始疙教，特別是對于有許多用戶角色的大型項(xiàng)目，要考慮每一個(gè)用戶角色蚓炬，從用戶使用軟件的目標(biāo)出發(fā)衍生出其他高層次故事松逊，進(jìn)一步衍生出新的故事。編寫用戶故事有一個(gè)被稱作切蛋糕的方法肯夏，即用端到端的方式分解/編寫故事经宏，每個(gè)故事提供某種程度的完整功能，這樣我們可以及早涉及軟件應(yīng)用程序架構(gòu)的每一層驯击，降低最后時(shí)刻才發(fā)現(xiàn)層次架構(gòu)方面問題的風(fēng)險(xiǎn)烁兰，且每輪迭代交付給用戶的是可用的功能。要編寫封閉的故事徊都，封閉的故事是指隨著一個(gè)有意義的目標(biāo)的實(shí)現(xiàn)而結(jié)束的故事沪斟，有始有終，讓用戶使用后覺得她完成了某個(gè)任務(wù)。對任何必須遵守而不需要直接實(shí)現(xiàn)的故事標(biāo)注“約束”形成卡片約束主之，我們就可以描述一些非功能性需求择吊。要根據(jù)實(shí)現(xiàn)時(shí)間來確定故事規(guī)模，對于即將實(shí)現(xiàn)的故事槽奕，規(guī)模更小几睛，精確度更高，對于更遠(yuǎn)的將來要實(shí)現(xiàn)的故事粤攒，規(guī)模更大所森，精確度更低。編寫故事時(shí)夯接，一定不要過早涉及用戶界面焕济，且要注意有些需求并不是故事，這個(gè)時(shí)候我們就可以用其他形式（文檔）來表達(dá)需求盔几，進(jìn)行補(bǔ)充晴弃，比如用戶界面參考和系統(tǒng)接口文檔。在故事里一定要包括用戶角色问欠，每個(gè)故事只為一個(gè)用戶編寫肝匆，并以用戶為第一人稱采用以主動語態(tài)編寫，最好是由客戶編寫用戶故事顺献，盡量不要給故事卡編號旗国，向故事卡編號說不，有必要的時(shí)候給故事卡取一個(gè)簡短容易記的名字注整。最后能曾，不要忘記意圖，故事卡片的作用是提醒開發(fā)人員和客戶團(tuán)隊(duì)對功能進(jìn)行討論肿轨，所以要保持簡潔性寿冕，加入需要的細(xì)節(jié)，以便聯(lián)想到繼續(xù)對話的切入點(diǎn)椒袍，但不要加入太多細(xì)節(jié)并以此取代對話驼唱。我們所編寫的用戶故事的集合，就形成了我們最初的產(chǎn)品待辦事項(xiàng)清單（Product Backlog）驹暑。

2.2 計(jì)劃階段（Planning Phase）

在計(jì)劃階段玫恳，我們從Product Backlog出發(fā)，對用戶故事進(jìn)行估算优俘，計(jì)算團(tuán)隊(duì)的初始速率京办，然后啟動發(fā)布計(jì)劃，形成產(chǎn)品開發(fā)路線圖帆焕。在每輪迭代開發(fā)的開始惭婿，將本輪迭代要完成的用戶故事進(jìn)一步分解為任務(wù)，啟動迭代計(jì)劃，進(jìn)入實(shí)際開發(fā)财饥，利用迭代燃盡圖來測量和監(jiān)控開發(fā)速率换吧。

2.2.1 估算用戶故事

估算用戶故事的最好方法有如下幾個(gè)特點(diǎn)：

• 無論什么時(shí)候獲得有關(guān)故事的新信息，都允許我們改變之前的想法
• 適用于史詩故事和小故事
• 不需要花很多時(shí)間
• 提供進(jìn)度和剩余工作的有用信息
• 不太精確的估算也不會有太大問題
• 可以用來制定發(fā)布計(jì)劃

“故事點(diǎn)”估算的方法可以滿足所有這些目標(biāo)钥星。故事點(diǎn)可以有很多定義方法式散，比如理想日，指沒有任何干擾打颤，沒有會議，沒有電子郵件漓滔，沒有電話的完美的一天编饺，或者理想周，復(fù)雜度測量什么的响驴。這里推薦將一個(gè)故事點(diǎn)的工作量看作是一個(gè)理想日的工作透且。有兩個(gè)好處，一是相較于用連續(xù)時(shí)間估算豁鲤，它更簡單秽誊；二是相較于用完全模糊單位，用理想日估算故事點(diǎn)可以使估算有更好的依據(jù)琳骡，方便換算成時(shí)間锅论。做用戶故事估算一定要以團(tuán)隊(duì)為單位，大概4-8個(gè)人楣号，估算的流程是：

1. 客戶隨機(jī)抽取一個(gè)故事讀給開發(fā)人員聽最易；
2. 開發(fā)人員根據(jù)需要盡可能多發(fā)問，客戶盡量解答炫狱，如果客戶不知道藻懒，就猜猜看或者推遲估算；
3. 如果對故事沒有疑問视译，每個(gè)開發(fā)人員寫下一個(gè)估算值嬉荆，先不要給其他人看；
4. 所有人同時(shí)展示自己的卡片酷含，出示估算值給大家看鄙早；
5. 如果估算值不同，估值高的和低的分別解釋估算依據(jù)第美，大家討論蝶锋；
6. 討論完后所有人再寫下修改后的估算值并展示給大家看；
7. 直到大家得到一個(gè)統(tǒng)一的估算值什往，這個(gè)過程很少超過3輪扳缕；

最后，對所有估算過的故事進(jìn)行一個(gè)“三角測量”：按故事點(diǎn)數(shù)分列每個(gè)用戶故事，這是為了幫助團(tuán)隊(duì)驗(yàn)證他們沒有逐漸改變一個(gè)故事點(diǎn)含義的有效方法躯舔。要注意驴剔，估算越大，對故事知道的就越少粥庄。

2.2.2 啟動發(fā)布計(jì)劃

啟動發(fā)布計(jì)劃前丧失，我們要問自己兩個(gè)問題：

1. 我們想在什么時(shí)候發(fā)布？
2. 希望在發(fā)布中包含哪些功能惜互？

首先布讹，我們對所有估算過的故事排列優(yōu)先級。排列優(yōu)先級的時(shí)候训堆，我們需要考慮一些技術(shù)要素和商業(yè)價(jià)值要素描验。技術(shù)方面，我們要評估故事不能如期完成的風(fēng)險(xiǎn)坑鱼，推遲實(shí)現(xiàn)一個(gè)故事對其他故事的影響膘流，以及一些與基礎(chǔ)性或非功能性需求有關(guān)的因素，比如架構(gòu)的需要鲁沥；商業(yè)價(jià)值方面呼股，要考慮故事對廣泛用戶或客戶的重要性，故事對于少部分重要用戶或客戶的重要性画恰，故事與其他故事的內(nèi)聚性彭谁，以及故事實(shí)現(xiàn)的成本，有時(shí)候成本會改變優(yōu)先級允扇。在確定一個(gè)故事優(yōu)先級時(shí)遇到問題马靠，我們就需要分割故事，然后對分割后的故事排不同優(yōu)先級蔼两。一種根據(jù)功能定位劃分優(yōu)先級的方法如下：從第一種維度甩鳄，我們可以將產(chǎn)品功能劃分為核心功能（Core）和外圍功能（Context）；從第二種維度额划，我們可以將產(chǎn)品需求劃分為必要需求（Critical）和輔助需求（Enabling）妙啃，這四種劃分結(jié)合起來，我們就能得到用戶故事優(yōu)先級的四個(gè)象限：

1. 第一象限：核心功能+必要需求俊戳，建議采取“差異化”方法揖赴，全力以赴投資這一領(lǐng)域；
2. 第二象限：外圍功能+必要需求抑胎，建議采取“抵消”策略燥滑，快速地達(dá)到“和別人差不多”，對大家都特別看重的功能阿逃，采取“優(yōu)化”的辦法達(dá)到行業(yè)最佳铭拧；
3. 第三象限：外圍功能+輔助需求赃蛛，建議采取“維持”策略，以最低代價(jià)維持此功能搀菩；
4. 第四象限：核心功能+輔助需求呕臂，要么維持，要么現(xiàn)在不做等待好時(shí)機(jī)肪跋，要么小規(guī)模實(shí)驗(yàn)歧蒋；

敏捷方法的精髓在于擁抱變化，反復(fù)完善系統(tǒng)州既，但當(dāng)這些變化影響到用戶界面時(shí)谜洽，后期的改進(jìn)是無法接受的，因?yàn)橛脩粢呀?jīng)學(xué)會和掌握了先前的用戶界面吴叶，這會產(chǎn)生嚴(yán)重的問題褥琐。那么一種敏捷版本的以使用為中心的設(shè)計(jì)（usage-centered design）認(rèn)為，我們可以采取如下的設(shè)計(jì)方法：

• 用戶角色建模
• 捕撈高層次的用戶故事
• 排列故事優(yōu)先級
• 精煉高優(yōu)先級和中等優(yōu)先級故事
• 對故事整理分組
• 建立書面的原型
• 精煉該原型
• 開始編程

所以在劃分優(yōu)先級后晤郑，我們要精煉高優(yōu)先級和中等優(yōu)先級故事，將它們精煉成更小的故事贸宏，然后把高優(yōu)先級和中等優(yōu)先級的故事整理為有望一起執(zhí)行的組造寝，給每組的故事畫出書面原型，展示給用戶或用戶代理看吭练，根據(jù)他們的意見改進(jìn)原型诫龙，這樣我們就把用戶界面給確定了下來。優(yōu)先級排列完畢后就可以開始選擇迭代長度了鲫咽，一般來說一輪迭代通常為1-4周签赃，如果不確定，就使用短迭代周期分尸。剩下的就是計(jì)算團(tuán)隊(duì)的初始速率锦聊，這個(gè)速率是以用戶故事點(diǎn)為單位的，代表一輪迭代能完成的故事點(diǎn)箩绍，如果團(tuán)隊(duì)做過類似項(xiàng)目孔庭，那么可以使用歷史值，否則的話就需要猜測速率了材蛛，一種方法是將一輪迭代三分之一到一半的開發(fā)日作為預(yù)計(jì)速率（開發(fā)日 = 團(tuán)隊(duì)人數(shù) × 迭代長度）圆到，當(dāng)然，隨著迭代的進(jìn)行可以不斷修正卑吭，完善估算芽淡。這樣我們就可以粗略估算需要多少輪迭代才能交付產(chǎn)品：迭代次數(shù) = 項(xiàng)目總故事點(diǎn) / 每輪迭代的故事點(diǎn)。我們先選取當(dāng)前優(yōu)先級最高的用戶故事（故事點(diǎn)數(shù)不超過一輪迭代的速率）放入第一輪迭代中豆赏，然后再將下一組次高優(yōu)先級的用戶故事放入第二輪迭代挣菲，如此進(jìn)行富稻，直到分配完所有故事。這樣就可以制作出產(chǎn)品開發(fā)路線圖己单。

2.2.3 啟動發(fā)布計(jì)劃后測試要做的任務(wù)

在這個(gè)階段唉窃，負(fù)責(zé)測試的開發(fā)人員需要完成初步的規(guī)劃，制定測試計(jì)劃（總綱）纹笼，包含以下內(nèi)容：

1. 產(chǎn)品是什么纹份？
2. 要做什么樣的測試？
3. 時(shí)間安排如何廷痘？
4. 誰負(fù)責(zé)什么方面蔓涧？
5. 各種資源在哪里？

2.2.4 啟動迭代計(jì)劃

每輪迭代都是以迭代計(jì)劃會議開始的笋额，參與人員為客戶和團(tuán)隊(duì)中的所有開發(fā)人員元暴。我們在會議中討論故事，客戶從最高優(yōu)先級故事開始兄猩，讀給開發(fā)人員聽茉盏，開發(fā)人員提問，直到充分理解故事枢冤，能從故事中分解出任務(wù)鸠姨。這么做的好處有兩個(gè)，首先實(shí)現(xiàn)故事的開發(fā)人員不止一個(gè)淹真，不同的任務(wù)需要由不同的開發(fā)人員來承擔(dān)讶迁；其次故事是對用戶或客戶有價(jià)值的功能描述，而分解后的任務(wù)成為開發(fā)人員的to-do list核蘸，這依靠所有人的集體智慧巍糯，所以不大可能出現(xiàn)遺漏。敏捷方法的一大特點(diǎn)就是用頻繁的短期設(shè)計(jì)來取代瀑布過程的前期設(shè)計(jì)階段客扎，一個(gè)故事的任務(wù)分解是即時(shí)設(shè)計(jì)中的一次短脈沖祟峦，分解任務(wù)的準(zhǔn)則：

1. 如果故事的某個(gè)任務(wù)特別難估算，就把那個(gè)任務(wù)從故事的其余任務(wù)中分離出來徙鱼；
2. 如果有些任務(wù)可以很容易安排給多名開發(fā)人員共同完成搀愧，就分割它們；
3. 如果有必要讓客戶了解故事某一部分完成情況疆偿，可以把那部分拿出來作為一個(gè)任務(wù)咱筛；

開發(fā)人員要主動認(rèn)領(lǐng)和承擔(dān)每個(gè)任務(wù)的職責(zé)，將自己的名字寫在認(rèn)領(lǐng)的任務(wù)旁邊并對任務(wù)負(fù)責(zé)：不管是從客戶那里獲得其他信息還是尋找結(jié)對編程對象杆故，都由他去負(fù)責(zé)迅箩。整個(gè)團(tuán)隊(duì)要有“同舟共濟(jì)”的心態(tài)，要主動分擔(dān)并勇于承擔(dān)处铛。認(rèn)領(lǐng)完任務(wù)后饲趋，開發(fā)人員要進(jìn)行最后的估算和確認(rèn)拐揭。每個(gè)開發(fā)人員以故事點(diǎn)為單位估算自己承擔(dān)的工作量，每個(gè)開發(fā)人員確認(rèn)自己的工作量奕塑，有沒有把握堂污？如果沒有，可以有三種處理策略：

1. 留著所有任務(wù)龄砰，寄希望于一切順利盟猖；
2. 請求團(tuán)隊(duì)中其他成員接手一些我的任務(wù)；
3. 與客戶討論换棚，要么放棄一個(gè)故事式镐，要么分割故事，放棄其中一部分固蚤；

如果其他開發(fā)人員評估完自己的工作量娘汞，覺得自己還能多主動分擔(dān)一些額外的工作量，就可以讓其他開發(fā)人員接手夕玩，如果大家都沒多余精力你弦，那就請客戶幫忙從迭代中移除一些工作，這樣可以保證大家最后能按自己的承諾交付產(chǎn)品燎孟。這樣開發(fā)團(tuán)隊(duì)在迭代計(jì)劃會議后就得到了本次迭代的沖刺待辦事項(xiàng)清單（Sprint Backlog）禽作。

2.2.5 啟動迭代計(jì)劃后測試要做的任務(wù)

測試需要同步跟進(jìn)，完成測試設(shè)計(jì)（TDS）的編寫缤弦。TDS首先描述功能是什么，需要測試哪些方面彻磁，特別是有沒有預(yù)期的bug比較多的地方碍沐；其次是如何測試：

1. 擬采用的具體方法；
2. 如何做測試自動化衷蜓；
3. 準(zhǔn)備什么樣的測試數(shù)據(jù)累提；

然后要考慮功能如何與系統(tǒng)集成，如何測試這方面磁浇？最后給出Exit Criteria：什么叫測試好了斋陪？

三. 軟件工程的實(shí)施（戰(zhàn)役層）

我們來回顧一下上面我們都完成了什么工作。首先，我們組建了一支各司其職的開發(fā)團(tuán)隊(duì)。其次紫新，進(jìn)行需求管理吞杭，得到Product Backlog，對用戶故事進(jìn)行估算都办，評估優(yōu)先級，估算團(tuán)隊(duì)開發(fā)速率，啟動發(fā)布計(jì)劃（測試工程師編寫測試計(jì)劃）度宦，得到產(chǎn)品開發(fā)路線圖踢匣。緊接著進(jìn)行迭代計(jì)劃會議，討論每個(gè)故事戈抄，從故事中分解任務(wù)离唬，開發(fā)人員主動認(rèn)領(lǐng)任務(wù)，估算并確認(rèn)任務(wù)工作量划鸽，形成本次迭代開發(fā)的Sprint Backlog（測試工程師編寫測試設(shè)計(jì)）输莺。有了前面的工作作為基礎(chǔ)，我們終于可以從戰(zhàn)略過渡到戰(zhàn)役漾稀，進(jìn)行實(shí)際的開發(fā)工作模闲，包括3個(gè)階段：開發(fā)，穩(wěn)定和部署崭捍。

3.1 開發(fā)階段（Developing Phase）

3.1.1 開發(fā)人員的標(biāo)準(zhǔn)工作流程

拿到開發(fā)任務(wù)后尸折，開發(fā)人員需要完成一系列的工作，寫quick-and-dirty的快速原型代碼殷蛇。對于復(fù)雜到一定程度实夹，開發(fā)者需要深思熟慮的開發(fā)任務(wù)，可以寫設(shè)計(jì)文檔（Technical Spec粒梦，Design Doc）亮航，用于描述開發(fā)者如何實(shí)現(xiàn)一組相互聯(lián)系的功能。編寫設(shè)計(jì)文檔需要體現(xiàn)軟件設(shè)計(jì)的一系列原則：

1. 抽象
2. 內(nèi)聚/耦合/模塊化
3. 信息隱藏和封裝
4. 界面和實(shí)現(xiàn)的分離
5. 如何處理錯(cuò)誤情況
6. 程序模塊對運(yùn)行環(huán)境匀们、相關(guān)模塊和輸入輸出參數(shù)有何假設(shè)缴淋？
7. 應(yīng)對變化的靈活性
8. 可擴(kuò)展性：應(yīng)對大量數(shù)據(jù)的處理能力

設(shè)計(jì)過程中可以選擇一些圖形化建模工具作為輔助，但不是必須的泄朴。對于軟件工程師而言常用的就是“統(tǒng)一建模語言（UML）”了重抖，但從我自己的實(shí)際經(jīng)驗(yàn)來看，我覺得“思維導(dǎo)圖”是一個(gè)非常好的整理思路的工具祖灰。不管是寫文章也好還是寫代碼也好钟沛，邊思考邊畫思維導(dǎo)圖，把知識之間的內(nèi)在聯(lián)系和框架結(jié)構(gòu)畫下來局扶，思路清晰之后再寫成代碼或者文章恨统，能極大的提高工作效率，特別是對于復(fù)雜對象的認(rèn)識會更全面詳細(xì)三妈，不會漏掉細(xì)節(jié)畜埋。例如圖3-1就是我在閱讀《構(gòu)建之法》和《用戶故事與敏捷方法》后畫的思維導(dǎo)圖，同時(shí)也是這篇文章的思維導(dǎo)圖畴蒲。

圖3-1 思維導(dǎo)圖

有了設(shè)計(jì)文文檔之后可以按照設(shè)計(jì)文檔寫代碼由捎。對照設(shè)計(jì)文檔和代碼指南進(jìn)行自我復(fù)審，重構(gòu)代碼饿凛，并創(chuàng)建或更新單元測試狞玛。之后運(yùn)行單元測試软驰，既要通過自己編寫的測試，也要通過整個(gè)模塊/系統(tǒng)的單元測試并保證代碼覆蓋率心肪。最后得到一個(gè)可測試版本交付給測試人員锭亏。如果出現(xiàn)了bug，那么開發(fā)人員就需要修復(fù)測試人員或用戶發(fā)現(xiàn)的問題硬鞍，請同事進(jìn)行代碼復(fù)審慧瘤。然后進(jìn)一步根據(jù)代碼復(fù)審意見修改代碼，完善單元測試和相關(guān)文檔固该，進(jìn)行伙伴測試（可選）锅减，最后把代碼簽入代碼庫中，這一系列步驟完成之后就得到了一系列完整的伐坏，驗(yàn)證過的功能怔匣。

伙伴測試的步驟如下：

1. 開發(fā)人員找一個(gè)測試人員作為伙伴
2. 開發(fā)人員做一個(gè)包含新模塊的私人構(gòu)建
3. 測試人員在本地做必要的回歸/功能/集成/探索測試
4. 發(fā)現(xiàn)問題直接與開發(fā)人員溝通

項(xiàng)目進(jìn)入開發(fā)階段后需要進(jìn)行嚴(yán)格的日常管理以保障代碼質(zhì)量。對于開發(fā)人員桦沉，要采用“閉門造車”模式——不要隨便打斷開發(fā)人員每瞒，盡量減少非開發(fā)時(shí)間，不要動不動全體會議纯露。對于項(xiàng)目剿骨，要進(jìn)行每日構(gòu)建（Daily Build），因?yàn)榧词怪皇且粋€(gè)簡單的系統(tǒng)埠褪，團(tuán)隊(duì)的積極性也會上升浓利，同時(shí)也能保證測試組能及時(shí)拿到最新版本進(jìn)行測試。若開發(fā)人員手里的bug超過一定數(shù)量钞速，那么就將他/她打入bug地獄贷掖，專心修bug。最后玉工，根據(jù)燃盡圖進(jìn)行每周進(jìn)度報(bào)告羽资。

3.1.2 開發(fā)階段的測試工作

到了這一階段淘菩，測試小組需要開發(fā)一系列的測試用例對已完成的功能進(jìn)行測試遵班。對于每個(gè)測試用例，要寫清楚：

1. 如何設(shè)置測試前的環(huán)境潮改；
2. 如何操作狭郑；
3. 預(yù)期的結(jié)果；

所有的測試用例集合形成一個(gè)測試套件（Test Suite）汇在，那么測試用例如何設(shè)計(jì)呢翰萨？有很多種方法，這些方法相互補(bǔ)充糕殉，幫助測試人員有效地生成測試用例：

1. 等價(jià)類劃分：每種劃分要觸發(fā)不同的處理邏輯或者錯(cuò)誤亩鬼，有效覆蓋程序的各種可能出現(xiàn)問題的地方殖告；
2. 邊界值分析：產(chǎn)生測試數(shù)據(jù)觸發(fā)各種邊界條件，能有效地驗(yàn)證程序在這些地方是否正確雳锋；
3. 常見錯(cuò)誤：根據(jù)經(jīng)驗(yàn)推測程序通常容易出錯(cuò)的地方黄绩，更有效地設(shè)計(jì)測試用例，例如空文件名玷过，在期望數(shù)字的字段填入文字等等爽丹；

針對每日構(gòu)建得到的版本，要進(jìn)行構(gòu)建驗(yàn)證測試（Build Verification Test）辛蚊，BVT特指構(gòu)建完成后自動運(yùn)行的一套測試粤蝎，用于驗(yàn)證系統(tǒng)基本功能。BVT有時(shí)候需要手工進(jìn)行袋马，但我們要努力讓BVT自動運(yùn)行初澎，通過BVT的構(gòu)建被稱為可測的（Testable），意思是說團(tuán)隊(duì)可以用這一版本進(jìn)行各種測試飞蛹，因?yàn)樗幕竟δ苁强捎玫陌啤y試小組拿到一個(gè)可測的構(gòu)建以后，就會按照計(jì)劃測試各自負(fù)責(zé)的模塊和功能卧檐。這個(gè)過程叫做驗(yàn)收測試墓懂。測試小組還可以進(jìn)行一定的探索式測試，測試一些一般人不會想到的場景霉囚，某些測試可以抽象出來捕仔，囊括到以后的測試計(jì)劃中，作為補(bǔ)充完善的一種手段盈罐。

測試過程中榜跌，如果發(fā)現(xiàn)了問題，就得提交錯(cuò)誤報(bào)告（bug report）:

1. bug的標(biāo)題：簡要說明問題和嚴(yán)重程度盅粪；
2. bug的內(nèi)容：測試的環(huán)境和準(zhǔn)備工作钓葫，測試的每一步步驟，實(shí)際發(fā)生的結(jié)果票顾，期望發(fā)生的結(jié)果
3. 其他補(bǔ)充材料：相關(guān)聯(lián)的bug础浮，輸出文件，日志文件奠骄，調(diào)用堆棧的列表豆同，截屏

3.2 穩(wěn)定階段（Stabilizing Phase）

3.2.1 基本流程

每個(gè)Sprint開發(fā)周期的開發(fā)任務(wù)完成后，項(xiàng)目就進(jìn)入了這輪迭代的穩(wěn)定階段含鳞，穩(wěn)定階段是從開發(fā)階段到發(fā)布階段的一個(gè)過渡影锈，起到承上啟下的作用。一般來說從代碼完成（Code Complete）到最終發(fā)布軟件，有一套基本的工作流程（同時(shí)也是版本演進(jìn)的一般方式）：

1. Alpha版本發(fā)布（集成主要功能的第一個(gè)試用版）
   • 代碼完成（Code Complete鸭廷，CC）
   • 集成測試枣抱，bug修復(fù)
   • 收集反饋
2. Beta版本發(fā)布
   • DCR，Bug修復(fù)
   • 代碼完成
   • 集成測試辆床，bug修復(fù)
   • 收集反饋
3. Release Candidate候選版本發(fā)布（一系列發(fā)布候選版沃但，版本間隔時(shí)間較短，RC1佛吓，RC2……）
   • DCR宵晚，Bug修復(fù)
   • 代碼完成
   • 集成測試，bug修復(fù)
   • 收集反饋
4. 最終版本發(fā)布(RC足夠好了)
   • 發(fā)布到應(yīng)用市場（Release To Market维雇，RTM）
   • 發(fā)布到Web（Release To Web淤刃，RTW）
   • 發(fā)布到運(yùn)營團(tuán)隊(duì)（Release To Operation，RTO）

3.2.2 解決影響產(chǎn)品發(fā)布的問題

3.2.2.1 會診小組

會診小組由各角色代表組成吱型，處理每一個(gè)影響產(chǎn)品發(fā)布的問題逸贾。對于每一個(gè)bug，會診小組要決定采取下面哪一種行動：

1. 修復(fù)津滞；
2. 設(shè)計(jì)本來如此（As Designed）铝侵，用戶或測試人員可能對功能有誤解，或者功能的解釋不完備触徐；
3. 不修復(fù)咪鲜，這是個(gè)問題，但這個(gè)版本不打算修復(fù)撞鹉；
4. 推遲疟丙，如果我們的軟件是真正解決用戶問題的，有價(jià)值的鸟雏，那它一定會有下一個(gè)版本享郊；

對于大型的復(fù)雜項(xiàng)目，會進(jìn)行更復(fù)雜的會診工作孝鹊。要按照版本發(fā)布的不同階段采取不同的修復(fù)bug的方式炊琉，總體說來是門檻越來越高。在Alpha版本階段又活，有bug可以馬上修復(fù)苔咪，簽入代碼后再通知大家，但是在Beta版本階段皇钞，新代碼簽入前必須告知會診小組潛在風(fēng)險(xiǎn)是什么悼泌？如何應(yīng)對松捉？到了RC版本階段夹界，修復(fù)bug之前開發(fā)人員必須和會診小組溝通，按照如下的標(biāo)準(zhǔn)流程進(jìn)行。

1. 開發(fā)者提交參加會診的bug和修改方案
   • bug是什么
   • 危害是什么可柿，如果不修復(fù)什么后果
   • 用戶會有什么變通做法
   • 是否經(jīng)過代碼復(fù)審鸠踪，是否經(jīng)過伙伴測試
2. 會議決定是否同意修改方案
   • Must：必須修復(fù)，缺陷很嚴(yán)重复斥，修復(fù)方案可行营密，相關(guān)測試都通過
   • More Info：需要更多信息才能做決定（缺陷的影響不明確/相關(guān)測試不完備/解決方案有缺陷）
   • No：不能接受，推到下一個(gè)里程碑或解決方案不合要求
   • Like：可能目锭，不一定必須修復(fù)评汰，解決方案相對安全，可以和Must級別的修復(fù)一并集成到代碼庫中
3. 執(zhí)行

3.2.2.2 其他招數(shù)

1. 設(shè)計(jì)變更（DCR）
   • 提交申請
     • 問題在哪里痢虹，問題的影響
     • 如果不修改被去，有何后果
     • 幾種修改方案，各種方案優(yōu)缺點(diǎn)和成本
   • 執(zhí)行次序
     • 會診所有DCR
     • 按影響和成本排序奖唯，得到一個(gè)自上而下的名單惨缆，根據(jù)現(xiàn)有資源按名單執(zhí)行
2. 零Bug構(gòu)建（Zero Bug Build），某天的版本把在之前（48小時(shí)）記錄的bug都解決掉
3. 最后回歸測試丰捷，所有人員回歸測試所有bug
4. 砍掉功能
5. 逐步凍結(jié)坯墨，從用戶界面開始逐步凍結(jié)，不再隨意修改

3.2.3 穩(wěn)定階段的測試工作

這一階段的測試工作主要有兩方面病往，一是進(jìn)行綜合的驗(yàn)收/集成/系統(tǒng)測試捣染，二是非功能性特性測試。

3.2.3.1 驗(yàn)收/集成/系統(tǒng)測試

在敏捷開發(fā)的穩(wěn)定階段停巷，我們要對軟件進(jìn)行全面和系統(tǒng)的測試液斜，以保證軟件的各個(gè)模塊都能共同工作，各方面都能滿足用戶需求叠穆。我們把計(jì)劃階段（Planning Phase）分析得到的所有用戶故事都列出來少漆，然后按功能做驗(yàn)收測試，如果成功則標(biāo)明“成功”硼被，否則就記錄一個(gè)或幾個(gè)bug ID示损。然后將迄今為止發(fā)現(xiàn)的所有bug全部重測一遍，確保沒有出現(xiàn)回歸嚷硫。若所有的場景都通過检访，那么這個(gè)構(gòu)建的質(zhì)量就是“可用的”，可以發(fā)布成技術(shù)預(yù)覽版仔掸。

用戶故事驗(yàn)收測試報(bào)告模板

1. ID
2. 故事名
3. 測試結(jié)果
4. bug ID

3.2.3.2 非功能性特性測試

軟件產(chǎn)品除了基本功能以外脆贵，還有很多功能之外的特性，叫非功能需求/服務(wù)質(zhì)量需求起暮，這些特性雖然沒有體現(xiàn)為具體的需求卖氨，但它們對系統(tǒng)的穩(wěn)定運(yùn)行同樣重要，尤其是效能測試和壓力測試。主要的非功能性特性測試有：

1. 壓力測試筒捺，測試軟件在負(fù)載情況下能否正常工作柏腻；
2. 效能測試，測試軟件的效能系吭；
3. 可訪問性測試五嫂，測試軟件是否向殘疾用戶提供了足夠的輔助功能；
4. 國際化/本地化測試肯尺；
5. 兼容性測試沃缘；
6. 配置測試，測試軟件在各種配置下能否正常工作
7. 易用性測試则吟，測試軟件是否好用
8. 安全性測試

3.2.3.2.1 效能測試

效能測試用于驗(yàn)證設(shè)計(jì)負(fù)載內(nèi)能否提供令用戶滿意的服務(wù)質(zhì)量孩灯，這里的兩個(gè)關(guān)鍵概念為“設(shè)計(jì)負(fù)載”和“令用戶滿意的服務(wù)質(zhì)量”。從需求說明出發(fā)可以得到系統(tǒng)的正常設(shè)計(jì)負(fù)載逾滥，例如一個(gè)購物網(wǎng)站正常的設(shè)計(jì)負(fù)載是每分鐘承受20次客戶請求峰档。而對于同樣的購物網(wǎng)站，用戶滿意的服務(wù)質(zhì)量可以定義為：每個(gè)用戶的請求都能在2秒鐘內(nèi)返回結(jié)果寨昙。設(shè)計(jì)負(fù)載可以進(jìn)一步按請求發(fā)生頻率分類：

1. 用戶登錄10%
2. 用戶查看某商品詳情50%
3. 用戶比較兩種商品10%
4. 用戶查看關(guān)于商品的反饋20%
5. 用戶購買商品讥巡，訂單操作5%
6. 所有其他請求5%

令用戶滿意的服務(wù)質(zhì)量也可以細(xì)化為“請求”和“模塊”兩類。寫操作可以適當(dāng)放寬要求舔哪，比如5秒鐘甚至更長欢顷。對于模塊，需要用測試工具測試各種效能指標(biāo)捉蚤。和別的測試不同抬驴，效能測試要求控制變量，必須保證相同的機(jī)器和環(huán)境±虑桑現(xiàn)實(shí)環(huán)境分為靜態(tài)數(shù)據(jù)和動態(tài)數(shù)據(jù)兩類布持。靜態(tài)數(shù)據(jù)包括用戶記錄，商品記錄和運(yùn)行一段時(shí)間后的交易記錄陕悬。動態(tài)數(shù)據(jù)就是負(fù)載题暖，可以分負(fù)載等級進(jìn)行測試。效能測試還要回答用戶這樣一個(gè)問題：“如果系統(tǒng)變慢了捉超，我是增加機(jī)器數(shù)量還是提高單個(gè)機(jī)器處理能力”胧卤，因此效能測試的結(jié)果應(yīng)該成為“用戶發(fā)布指南”的一部分，為用戶發(fā)布和改進(jìn)系統(tǒng)提供參考拼岳。

3.2.3.2.2 壓力測試

壓力測試的目的是驗(yàn)證超過設(shè)計(jì)負(fù)載的情況下是否仍能返回正常結(jié)果枝誊，有沒有產(chǎn)生嚴(yán)重的副作用或崩潰。增加負(fù)載的方法有3種：沿著用戶軸延長惜纸，沿著時(shí)間軸延長（模擬48小時(shí)高負(fù)載）和減少系統(tǒng)可用資源叶撒。一些平時(shí)不容易暴露的問題此時(shí)就暴露出來了绝骚，比如內(nèi)存/資源泄露，平時(shí)被認(rèn)為“足夠好”的算法實(shí)現(xiàn)出現(xiàn)問題痊乾，以及進(jìn)程/線程的同步死鎖問題。

3.2.3.3 編寫測試報(bào)告

測試工作的最后一步是編寫測試報(bào)告椭更，這里不需要寫很多內(nèi)容哪审，只需簡單的列舉一些數(shù)字即可。對于每一個(gè)功能虑瀑，收集下列數(shù)據(jù)：

1. 有多少測試用例通過
2. 有多少測試用例失敗
3. 有多少測試用例未完成
4. 發(fā)現(xiàn)多少測試用例之外的bug

最后湿滓，把盡可能多的測試用例自動化，為下一個(gè)里程碑開發(fā)工作做好準(zhǔn)備舌狗。

3.3 部署階段（Deploying Phase）

終于叽奥，我們進(jìn)入了迭代開發(fā)的部署階段，在穩(wěn)定階段解決掉所有問題痛侍，成功發(fā)布產(chǎn)品之后我們要做的就是總結(jié)和回顧朝氓。要認(rèn)真思考和反思項(xiàng)目中出現(xiàn)過的各種各樣的問題，這就是下面要說的“事后諸葛亮?xí)h”主届。

3.3.1 發(fā)布之后：事后諸葛亮?xí)h

進(jìn)行項(xiàng)目開發(fā)的復(fù)盤赵哲，把問題的根源暴露出來。如果你可以重新來過君丁，什么方面可以做的更好枫夺？

1. 為什么軟件發(fā)布后用戶報(bào)告了一個(gè)大問題？
2. 為什么在測試階段沒有測出來绘闷？
3. 為什么不通知PM/Test橡庞？
4. 為什么不通知別人？

要一直追問到問題的根源和源頭為止印蔗。

3.3.2 質(zhì)量保障工作

如何衡量軟件的質(zhì)量扒最？有三個(gè)要點(diǎn)可以考慮：

1. 研發(fā)出符合用戶需求的軟件
2. 通過一定的軟件流程，在預(yù)計(jì)時(shí)間內(nèi)發(fā)布“足夠好”的軟件
3. 通過數(shù)據(jù)和其他方式展現(xiàn)所開發(fā)的軟件是可維護(hù)和繼續(xù)發(fā)展的

測試工程師可以從以下幾個(gè)方面來量化分析上面提到的要點(diǎn)：

1. 軟件CC后DCR數(shù)量
2. 用戶的好評/差評
3. CC后發(fā)現(xiàn)的bug數(shù)量
4. 修復(fù)bug所需的平均時(shí)間
5. 單位開發(fā)量（人*月）出現(xiàn)的重大bug的數(shù)量
6. 測試用例的覆蓋率
7. 模塊的復(fù)雜程度（工具檢測并有量化結(jié)果）
8. 代碼的行數(shù)
9. 文檔的完備性和準(zhǔn)確性百分率
10. 文檔的數(shù)量和復(fù)雜程度
11. 有多少代碼被重用
12. 平均每天構(gòu)建失敗的次數(shù)
13. 軟件實(shí)現(xiàn)了多少功能點(diǎn)
14. 軟件能運(yùn)行多久华嘹？平均初次錯(cuò)誤時(shí)間和平均無故障時(shí)間

四. 總結(jié)

在軟件開發(fā)的活動中扼倘，人是最關(guān)鍵的因素。因此軟件工程流程的根基在于人的基本戰(zhàn)術(shù)素養(yǎng)除呵，本文首先總結(jié)了作為工程師必須具備的一些個(gè)人戰(zhàn)術(shù)素養(yǎng)和技術(shù)成長的路徑再菊。然后，總結(jié)了《構(gòu)建之法》這本書中講到的各種流程颜曾，方法和行為模式纠拔。分為戰(zhàn)略層和戰(zhàn)役層兩大部分。在戰(zhàn)略層泛豪，我們要完成構(gòu)思和計(jì)劃兩個(gè)階段的任務(wù)稠诲。在構(gòu)思階段侦鹏，我們要組建團(tuán)隊(duì)，研究和分析用戶需求臀叙，產(chǎn)出團(tuán)隊(duì)+需求規(guī)格說明書+產(chǎn)品開發(fā)路線圖略水。在計(jì)劃階段，我們要根據(jù)需求和路線圖劝萤，整理Epic和用戶故事渊涝，創(chuàng)建Product Backlog產(chǎn)品待辦事項(xiàng)清單，測試人員需要撰寫測試計(jì)劃文檔床嫌。然后創(chuàng)建Sprint Backlog沖刺開發(fā)待辦事項(xiàng)清單跨释，并根據(jù)用戶故事做交互式系統(tǒng)需求設(shè)計(jì)，形成軟件功能說明書厌处，做系統(tǒng)概要設(shè)計(jì)鳖谈，構(gòu)造總體模型，功能列表阔涉，制定開發(fā)計(jì)劃缆娃，進(jìn)行功能設(shè)計(jì)，得到這次里程碑要發(fā)布的功能文檔及其相關(guān)文檔瑰排，各業(yè)務(wù)活動對應(yīng)的時(shí)序圖龄恋，更新的實(shí)體模型，類/方法/屬性和功能實(shí)現(xiàn)計(jì)劃凶伙，測試人員要撰寫測試設(shè)計(jì)說明書郭毕。在戰(zhàn)役層，我們要實(shí)施三個(gè)階段的工作任務(wù)：開發(fā)函荣，穩(wěn)定和部署显押。開發(fā)人員拿到任務(wù)后，編寫設(shè)計(jì)文檔傻挂，然后開始編寫功能代碼和單元測試代碼乘碑，測試人員要編寫測試用例對代碼進(jìn)行測試。功能需求開發(fā)完畢后進(jìn)入穩(wěn)定階段金拒，進(jìn)行迭代發(fā)布并解決影響發(fā)布的工作兽肤。測試人員需要進(jìn)行場景/集成/系統(tǒng)測試，非功能性特性測試绪抛，編寫測試報(bào)告资铡。部署成功后，團(tuán)隊(duì)成員召開事后諸葛亮?xí)h幢码，進(jìn)行總結(jié)復(fù)盤笤休，測試人員進(jìn)行質(zhì)量保障工作的數(shù)據(jù)整理和總結(jié)。

以上症副，就是我對32萬字《構(gòu)建之法》和35萬字《用戶故事與敏捷方法》的總結(jié)和整理店雅，只提煉和抽取了精華部分政基，感興趣的一定要去讀原著。

五. 參考文獻(xiàn)

1. 構(gòu)建之法：現(xiàn)代軟件工程
2. 用戶故事與敏捷方法
3. The product backlog: your ultimate to-do list