第13部分(第3/4 頁)

稱為“One　to　One　Meeting”，是經理跟員工一對一的會議。

阿捷自從接管TD這個團隊後，跟員工制定並討論MBO，已成了他每個季度的必修課。因為團隊正在實施Scrum，阿捷給阿朱設定的目標之一就是“如何做到測試的敏捷化”。

第10章　持續整合（2）

阿捷率先開頭：“我們之前也做過幾輪MBO的One　to　One了，你對這個會議本身有什麼建議嗎？”

“嗯”，阿朱略微沉思了一下，“Review要及時，目標設定要隨時調整。其實我對以年為跨度的Objective　Setting和Performance　Review的最大困惑就在於兩者的嚴重脫節。”

“哦？”阿捷示意阿朱繼續。

“實際上，這樣長跨度的目標設定，更傾向於一個Career　Plan而不是Objective　Plan。而拿一個Career　Plan作為年終Performance　Review的依據，似乎不怎麼合理。”

“嗯”，其實阿捷也有同感，之前幾年，都是袁朗跟阿捷One　to　One的，最終都淪為了形式，阿捷也準備做些改變。不過阿捷還是鼓勵阿朱說下去，“你覺得應該怎麼變化更好些？”

“我是這麼想的，我們實施敏捷開發有一段時間了，一個Sprint的週期基本是3個禮拜左右，那麼我們每人的短期目標完全可以跟每個Sprint結合起來。因為每個Sprint的目標都很明確，再落實到每個人頭上就會非常實際。但這樣，就得加強Review的頻率，以及時調整目標。”

“你的意思是說我們把每個季度一次的One　to　One，改成每個月一次？”

“對！”

“嗯，你說得非常有道理，我也有同感。可以把每年的Objective　Setting，作為員工個人的Development　Plan。怎麼樣？”

“不知道別的員工怎麼想，我覺得這樣做，會更有價值。只不過，你就得多花些時間在這上面了。”阿朱笑著說。

“這倒沒關係！關心並幫助每個員工向前發展，本來就是我的責任。我會再做一個調查，瞭解一下其他人的看法。你今天提出來，非常好！”阿捷抬頭看了一下牆上的表，還有半個小時的時間，得趕緊討論這次的主題了。“我們接下來看看我們上次提到的敏捷測試，你有什麼最新進展嗎？”

“我這幾天思考了一下，我覺得我們的專案有必要採用XP的持續整合。”阿朱針對自己的“敏捷測試”目標，提出了自己的想法。

“為什麼要持續整合？”阿捷問。

“你看，我們現在的開發模式是專案一開始就劃分模組，然後等所有的程式碼都開發完成之後再整合到一起進行測試，隨著軟體需求越來越複雜，軟體已經不能簡單地透過劃分模組的方式來開發，需要專案內部互相合作，劃分模組這種傳統的模式的弊端也越來越明顯，由於很多　Bug　在專案的早期就存在，到最後整合的時候才發現問題，我們測試人員需要在整合階段幫助開發人員花費大量的時間來尋找Bug　的根源，加上軟體的複雜性，問題的根源很難定位，甚至出現不得不調整底層架構的情況！”

“是啊，所以好多團隊在這個階段的除蟲會議（Bug　Meeting）特別多，會議的內容基本上都是討論Bug　是怎麼產生的，最後往往發展為不同模組的負責人互相推諉責任。”

“透過持續整合，可以有效地解決這個問題。”

“具體該怎麼做呢？”阿捷拿起筆，準備記錄。

“你看我們的開發、測試流程：當任何一個人修改程式碼後，首先執行單元測試；透過後，提交程式碼；構建產品；把它放在模擬的產品執行環境下，進行測試；遇到問題，進行修正並重覆上述過程。我們需要首先讓上述過程自動化。”

“嗯，這樣肯定可以大幅提高開發測試效率。”阿捷表示贊同，並示意她繼續講吓去。　txt小說上傳分享

第10章　持續整合（3）

“我覺得需要做這樣幾件事情：編譯自動化、單元測試自動化，再加上自動打安裝包、自動部署到測試環境，並進行功能測試、效能測試！”

“我覺得還有必要加上一條，自動統計測試結果，並透過郵件傳送給相關的人。有了這樣的一個框架，你們測試人員就可以從一些煩瑣的手工工作