結果導向和測試驅動(轉)

原文轉自thoughtworks員工gigix：

[url]http://gigix.thoughtworkers.org/2012/5/8/result-oriented-and-test-driven[/url]

“結果導向”是個職場裡很流行的詞。六年前我跟 夏姐姐 去校園招聘，她說如果是招銷售的話就會更多要求結果導向。然而我現在發現，所謂結果導向，其實跟 測試驅動開發 是同一回事。是以像ThoughtWorks這樣很認同TDD的環境，即使不是銷售，做事同樣要強調結果導向。

類似的話題其實我 之前也講過 。我還可以再舉一個最近的例子，讀者們一起來做做思維練習：

[i]你是一個項目經理。你帶着另外兩個兄弟漂洋過海來到A國，客戶是A國數一數二的保險公司S。你要跟S公司的人一起工作一段時間，然後回到中國來形成離岸外包的局面繼續工作。可是事情沒那麼簡單。S公司這是第一次把核心系統研發工作離岸外包，公司上下沒人知道這事情該怎麼操作。倒是負責風險控制的部門知道哪些事情不能做，比如說把源代碼弄到中國這事就不能行，更不用說信用卡資料了，那是壓根就不能允許在中國的顯示器上出現。客戶的團隊對你們也持懷疑眼光，連自己公司在A國的同僚也有點搞不清你們到底需要什麼幫助。

現在，作為這個焦頭爛額的項目經理，顯然你有很多事要做。噢對了，你們的簽證隻有六周⋯⋯[/i]

你會做哪些事？你會首先做哪些事？

這時候我給這個團隊的建議就是：你們需要測試驅動。如果要為這六周的onsite工作寫一個驗收測試，這個測試應該是什麼？這個spec應該寫着“可以離岸外包”。如何測試可以離岸外包？你需要讓至少一個人盡早開始以離岸外包的方式工作。當你們在A國的時候，這個人從中國開始以離岸外包的方式工作了，客戶開始為他付錢了，這個測試就通過；反之，不管你在客戶現場做得再high、客戶對你再滿意，當你回國以後一定會出問題。

這一個驗收測試又會被細分為更多的功能測試，例如“可以通路源代碼”、“資料安全通過檢查”⋯⋯最終某些功能測試真的會被實作為自動化的測試代碼，另一些将會是人為的檢查點。重點在于，你在客戶現場要做什麼、要先做什麼，不是由你預先設計的，也不是拍腦袋拍出來的，而是由驗收測試驅動出來的。我應該動手解決資料安全問題嗎？我應該建議客戶增加一個疊代經理嗎？我應該給客戶做一個關于中國文化的session嗎？答案都在于：你目前“紅”的測試是什麼？你做這件事将以何種方式使哪個測試變“綠”？

傳統的管理者們會說這就叫“結果導向”。

類似的案例還有很多。比如說，如果你要為離岸外包傳遞這件事寫一個測試，你會怎麼測它呢？你應該很快發現，像“客戶滿意”這種虛無缥缈而又變幻莫測的東西，并不适合作為驗收測試。一個既簡單又明确的驗收測試應該是“客戶為我們的工作付錢”。那麼當你用這樣一個測試來驅動自己的工作，你就不那麼容易犯下填錯timesheet之類的低級錯誤，因為你會意識到：不管工作有多認真多高品質客戶有多happy，如果你的timesheet裡沒有填那麼客戶是不會為你的時間付錢的，那麼你的驗收測試就“紅”了。

是以，結論一：就像德魯克說的，一切績效都在企業之外。忘記什麼角色定義啦工作流程啦職位分工啦績效考核啦之類的bullshit吧，如果你用“客戶買單”這樣的外在成就來作為大多數事情的驗收測試，你會把工作這件事看得清晰得多。結論二：好的程式員幹别的事都比較有希望，因為我們會測試驅動。（潛台詞：糟糕的程式員能轉成好的項目經理這回事怎麼聽怎麼不靠譜⋯⋯）

原文轉自thoughtworks員工gigix：

[url]http://gigix.thoughtworkers.org/2012/5/8/result-oriented-and-test-driven[/url]