循序漸進的敏捷 交叉測試

由於各種原因，團隊人員換了一些人，新到的團隊成員，由於對業務不夠了解，對系統的**和架構，也不是很清楚，很多時候測試也不到位，導致了一系列問題和bug。很多問題在我們看來都是不應該發生，或是當時如果仔細測試，是完全可以避免的問題。

針對於這樣的情況。我們進行了總結和反思，決定嘗試加入交叉測試，來提高系統的質量。

迭代的功能完成之後，開發人員互相檢查別人的功能和**，並進行足夠的測試，測試和檢查的範圍包括系統資料庫設計、業務需求、解決方案、**（注釋、**風格）、資料表等。

開發人員在完成乙個功能之後，找到另乙個人員，進行交叉測試

1. 講解業務需求。

2. 講解解決方案。

3. 功能演示

4. **交叉測試

5. 功能測試

期間，交叉測試人員，隨時提出問題和看法，盡早發現開發者在業務和設計方面的問題。

1. 對模組的了解不只侷限在乙個開發人員身上，分擔了專案的維護風險；

2. 規範**，至少在注釋和**風格方面能保障；

3. 避免乙個人思考問題和對業務的理解存在的遺漏或盲點，多乙個人查漏補缺會避免不必要的bug；

4. 確保所有的功能至少核心功能，都有兩個以上的人測試到；

1. 交叉測試會占用開發時間，熟悉別人的功能和**都要花不少的時間，我估計測試時間是開發時間的1/4至1/3；

2. 隊員水平參差不齊，開發人員和交叉測試人員對業務和**同樣不了解，這樣就無法保證交叉測試的質量；

3. 儘管花了很多時間，有可能還是無法保證交叉測試做完之後，測試範圍覆蓋到全部模組的業務，無法確保需求或是業務的問題；

4. 交叉測試會導致開發者會不關心bug的責任問題。

1. 交叉測試者一定要理解開發人員的業務需求和解決方案，這樣才能達到了業務講解和理解的目的，才能提出問題；

2. 避免不講業務需求和解決方案就直接進行測試，這樣無法保證交叉測試的質量；

3. bug應該屬於團隊所有成員的，不應該由某個人來單獨負責，bug也作為一項任務；

4. 關鍵性模組才進行交叉測試，這樣既避免了交叉測試占用太多的開發時間，又避免了核心業務的不穩定；

5. 盡量避免不了解業務的人員去給其他開發人員做交叉測試；

循序漸進的敏捷 交叉測試

由於各種原因，團隊人員換了一些人，新到的團隊成員，由於對業務不夠了解，對系統的 和架構，也不是很清楚，很多時候測試也不到位，導致了一系列問題和bug。很多問題在我們看來都是不應該發生，或是當時如果仔細測試，是完全可以避免的問題。針對於這樣的情況。我們進行了總結和反思，決定嘗試加入交叉測試，來提高系統...

循序漸進的敏捷 每日例會

通過一段時間的推行，每日例會也取得了不錯的效果，大家也都明白各自需要做的 工作事項。敏捷開發中的每日例會，就是為了確定下一天所需執行的工作，以最大可能地履行其承諾。團隊的每個成員都應該描述自上次會議以來所做的工作。他們計畫在當天完成的工作，以及可能對其他團隊成員產生影響或需要獲得其他團隊成員幫助的任...

循序漸進的敏捷 每日例會

通過一段時間的推行，每日例會也取得了不錯的效果，大家也都明白各自需要做的 工作事項。敏捷開發中的每日例會，就是為了確定下一天所需執行的工作，以最大可能地履行其承諾。團隊的每個成員都應該描述自上次會議以來所做的工作。他們計畫在當天完成的工作，以及可能對其他團隊成員產生影響或需要獲得其他團隊成員幫助的任...