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