開(kāi)發(fā)項(xiàng)流程（Development Item Process）
當(dāng)時(shí)的這個(gè)Scrum試點(diǎn)項(xiàng)目身負(fù)重任，其中之一就是要探索出在新型的敏捷模式下該使用何種的開(kāi) 發(fā)流程，負(fù)責(zé)人就是當(dāng)時(shí)的Linux部門(mén)經(jīng)理，而我則撈到了負(fù)責(zé)測(cè)試部分流程的機(jī)會(huì)。整個(gè)試點(diǎn)項(xiàng)目的人員擴(kuò)張速度不錯(cuò)，4個(gè)人的團(tuán)隊(duì)維持了好幾個(gè)迭代，陸續(xù)有人加入，新的測(cè)試人員在大概是第四個(gè)迭代的時(shí)候才補(bǔ)充進(jìn)來(lái)，而后逐漸擴(kuò)張到兩三個(gè)團(tuán)隊(duì)。這樣的擴(kuò)張速度對(duì)測(cè)試流程的確定來(lái)說(shuō)非常好，一開(kāi)始我可以只考慮自己的想法，不斷地嘗試摸索，可以很快地得到反饋然后改進(jìn)；等到想法大致成形的時(shí)候，又可以專注于幫助其他成員理解流程和使用，驗(yàn)證流程的易用性；等到人員更多的時(shí)候，就可以著重驗(yàn)證流程的推廣復(fù)用性。
試點(diǎn)項(xiàng)目并非是全權(quán)負(fù)責(zé)新產(chǎn)品的開(kāi)發(fā)，它其實(shí)是歸屬一個(gè)更大的項(xiàng)目、產(chǎn)品的，產(chǎn)品經(jīng)理在芬蘭，芬蘭也還有一些團(tuán)隊(duì)，兩地之間的團(tuán)隊(duì)必須要合作，雖然杭州的項(xiàng)目享有流程等各方面的自由，但也必須考慮和芬蘭團(tuán)隊(duì)現(xiàn)有模式流程協(xié)作的問(wèn)題。流程中也要把這些細(xì)節(jié)都考慮進(jìn)去。
我討厭浪費(fèi)，討厭重復(fù)的信息，也不喜歡把不同特點(diǎn)的信息混淆在一起，而且流程要為人服務(wù)，它需要根據(jù)人在工作中的行為、活動(dòng)特點(diǎn)來(lái)制定，而不是憑空想象，這是我在流程總結(jié)中所秉持的重要原則。因此，在流程中測(cè)試活動(dòng)開(kāi)展所需要的信息，每一份信息只應(yīng)該存在于一個(gè)位置，其他地方全部應(yīng)該通過(guò)鏈接或者引用使用這些信息，而且測(cè)試和開(kāi)發(fā)都會(huì)用到的信息也適用此原則。信息應(yīng)該分為長(zhǎng)期存在和短期存在兩種，可以看做是從讀、寫(xiě)的角度進(jìn)行區(qū)分：同一份信息和被測(cè)對(duì)象相關(guān)，且在可預(yù)見(jiàn)的未來(lái)還會(huì)繼續(xù)被讀寫(xiě)的話，看做是長(zhǎng)期的類型；同一份信息主要是階段性的，和特定的版本、時(shí)間點(diǎn)相關(guān)的，且在可預(yù)見(jiàn)的未來(lái)只會(huì)被讀取但不會(huì)被更新（寫(xiě)）的，看做是短期的類型。兩類信息或者以不同的文檔進(jìn)行維護(hù)，或者以不同的方式進(jìn)行維護(hù)。
如下簡(jiǎn)單表述一下當(dāng)時(shí)所設(shè)計(jì)出來(lái)的流程，這個(gè)流程因?yàn)榉N種原因在試點(diǎn)項(xiàng)目結(jié)束后沒(méi)有被延續(xù)使用，但是大概是三四年后我已經(jīng)成為敏捷教練的時(shí)候，意外得知它居然一直在別的產(chǎn)品線沿用至今（當(dāng)時(shí)），其生命力可見(jiàn)一斑。我將側(cè)重描述其變化、改進(jìn)之處，和以往流程相同的地方則不做介紹。
● 新流程的目標(biāo)包括：推動(dòng)開(kāi)發(fā)和測(cè)試專家們的密切合作以提高軟件的質(zhì)量；合理化以及簡(jiǎn)化相關(guān)文檔；減少文檔數(shù)量，加強(qiáng)維護(hù)，以提高文檔的質(zhì)量；促進(jìn)開(kāi)發(fā)和測(cè)試人員之間的互相學(xué)習(xí)，以增加項(xiàng)目資源的靈活性；等等。
● 開(kāi)發(fā)項(xiàng)是新提出的概念，將軟件的規(guī)格說(shuō)明書(shū)撰寫(xiě)、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試封裝在一起，作為最小的原子化產(chǎn)品組件（Component）。原子化的意思是保持開(kāi)發(fā)項(xiàng)之間的互相依賴在可以做到的最低水平；移除或重排任何開(kāi)發(fā)項(xiàng)的時(shí)候，對(duì)其他開(kāi)發(fā)項(xiàng)不產(chǎn)生（或產(chǎn)生最小的）影響。
● 在迭代開(kāi)始前，先有技術(shù)報(bào)告或者需求文檔，由此而產(chǎn)生出開(kāi)發(fā)項(xiàng)；然后是和以往的項(xiàng)目過(guò)程一樣的入口階段，確定項(xiàng)目日程并且生成相關(guān)的高階（High Level）文檔。包括集成計(jì)劃文檔、項(xiàng)目計(jì)劃文檔、模塊（Module）測(cè)試策略以及開(kāi)發(fā)項(xiàng)測(cè)試計(jì)劃文檔都在此時(shí)創(chuàng)建。
● 所有和開(kāi)發(fā)項(xiàng)相關(guān)的測(cè)試活動(dòng)都在Sprint內(nèi)完成，這些測(cè)試被稱之為DIT（開(kāi)發(fā)項(xiàng)測(cè)試），測(cè)試用例本身還是屬于以往的功能測(cè)試級(jí)別。但是開(kāi)發(fā)項(xiàng)的測(cè)試計(jì)劃、測(cè)試執(zhí)行、報(bào)告等一系列過(guò)程全部都要在一個(gè)Sprint中完成，測(cè)試用例的自動(dòng)化比例并未做硬性規(guī)定，但當(dāng)時(shí)我們的成果是100%自動(dòng)化。
● 項(xiàng)目成員主要分為開(kāi)發(fā)和測(cè)試兩類工程師，但是角色的定義并不是拿來(lái)當(dāng)做不可逾越的紅線使用，必要的情況下，開(kāi)發(fā)工程師也會(huì)承擔(dān)部分測(cè)試任務(wù)甚至整個(gè)人投入測(cè)試，或者測(cè)試工程師也會(huì)和開(kāi)發(fā)工程師一起，結(jié)對(duì)開(kāi)發(fā)代碼。
● 開(kāi)發(fā)人員的工作安排會(huì)受到測(cè)試工作的影響，每日站會(huì)或者平時(shí)工作中，可能會(huì)發(fā)現(xiàn)軟件不容易測(cè)試，就需要開(kāi)發(fā)人員協(xié)助檢查以及修改代碼提高軟件的可測(cè)性。或者是在開(kāi)始寫(xiě)測(cè)試腳本之前，就去跟開(kāi)發(fā)人員約定程序輸出的內(nèi)容和格式。
● 測(cè)試文檔根據(jù)信息的長(zhǎng)期性、短期性進(jìn)行了區(qū)分。
1、測(cè)試計(jì)劃與報(bào)告：將這兩個(gè)單獨(dú)的文檔合并到一起，在單獨(dú)的章節(jié)里展示各自的信息，每個(gè)軟件發(fā)布使用一份測(cè)試計(jì)劃和報(bào)告。總共四個(gè)章節(jié)：被測(cè)功能描述以及模塊列表（持續(xù)更新）、持續(xù)集成測(cè)試狀態(tài)（每個(gè)迭代的測(cè)試報(bào)告）、總結(jié)（質(zhì)量評(píng)估、經(jīng)驗(yàn)反饋、推薦和建議）、現(xiàn)存問(wèn)題（尚未解決或仍不明晰的問(wèn)題）。目的是在單個(gè)軟件發(fā)布周期內(nèi)持續(xù)記錄測(cè)試的狀態(tài)，縮減不必要的文檔量。
2、測(cè)試用例與缺陷：每一個(gè)模塊或技術(shù)領(lǐng)域使用一份測(cè)試用例及缺陷文檔。文檔內(nèi)容包括：該模塊或技術(shù)領(lǐng)域的整體描述，測(cè)試用例列表及狀態(tài)，缺陷列表，測(cè)試輔助程序，操作命令。目的是提供一份可以全面了解被測(cè)模塊或技術(shù)領(lǐng)域的文檔，包括當(dāng)前的所有功能、曾有的和現(xiàn)存的缺陷，以及如何使用操作命令和測(cè)試輔助程序進(jìn)行測(cè)試。
3、測(cè)試用例清單：用Excel記錄所有的測(cè)試用例即可，信息來(lái)自于現(xiàn)有的測(cè)試管理系統(tǒng)，包括測(cè)試用例的編號(hào)、已測(cè)過(guò)的最新軟件發(fā)布、已測(cè)過(guò)的最新版本信息、測(cè)試用例的版本、測(cè)試用例名稱、自動(dòng)化的狀態(tài)。
4、缺陷清單：用Excel記錄所有的缺陷即可，信息來(lái)自于現(xiàn)有的缺陷追蹤系統(tǒng)，包括缺陷的編號(hào)、標(biāo)題、嚴(yán)重程度、缺陷單狀態(tài)、相關(guān)的測(cè)試用例以及版本。目的是提供一目了然的缺陷清單，可以知曉其歷史及現(xiàn)狀。
5、Sprint缺陷清單：記錄在Sprint開(kāi)發(fā)過(guò)程中發(fā)現(xiàn)的軟件缺陷，相當(dāng)于輕量級(jí)的缺陷追蹤系統(tǒng)，無(wú)法當(dāng)天修復(fù)的問(wèn)題才會(huì)被記錄下來(lái)，而無(wú)法在當(dāng)前Sprint中解決的問(wèn)題則會(huì)被錄入缺陷追蹤系統(tǒng)，并且錄入前一個(gè)缺陷清單。
Linux編程培訓(xùn)
為了幫助新人快速地融入項(xiàng)目，我們還承擔(dān)著開(kāi)發(fā)一套培訓(xùn)課程的任務(wù)。在Linux環(huán)境下進(jìn)行開(kāi)發(fā)的同時(shí)，我們需要總結(jié)經(jīng)驗(yàn)，有針對(duì)性地記錄所需要掌握的各方面知識(shí)，并且做成培訓(xùn)材料，提供給加入團(tuán)隊(duì)、項(xiàng)目的新手。我也參與其中有少量的貢獻(xiàn)。
相關(guān)鏈接：
我的軟件測(cè)試之旅：（1）起點(diǎn)——作為軟件開(kāi)發(fā)人員
我的軟件測(cè)試之旅：（2）轉(zhuǎn)變——作為專職測(cè)試人員
我的軟件測(cè)試之旅：（3）同期——加入測(cè)試自動(dòng)化小組
我的軟件測(cè)試之旅：（4）并行——自動(dòng)化回歸測(cè)試
我的軟件測(cè)試之旅：（5）難點(diǎn)——功能改進(jìn)的測(cè)試
我的軟件測(cè)試之旅：（6）跳轉(zhuǎn)——追逐新鮮事物的探險(xiǎn)者
我的軟件測(cè)試之旅：（7）啟程——Scrum中的測(cè)試工作者
我的軟件測(cè)試之旅：（8）困難——沒(méi)有現(xiàn)成的測(cè)試工具
我的軟件測(cè)試之旅：（9）行動(dòng)——簡(jiǎn)化測(cè)試文檔和流程