[b]四、團隊協作[/b]

提到團隊協作，聽到最多的就是團隊責任制。在一個小團隊裡，形成對外的團隊責任制是很容易的（因為集體榮譽感），這也是Scrum鼓勵小團隊的原因之一。但在團隊內部，使每個人都能做到團隊責任制卻並不容易。

找到反例似乎很容易。在一個分特性到人的專案裡，產品出現bug，幾乎總有程式設計師說，恩，這塊不是我開發的，你要找某某某。在另一個專案裡，業務分析師越過業內的最佳實踐，忽略程式設計師的意見，一定要在地圖上一次性顯示所有地點，而不是延遲分批載入，結果導致這一功能的數次返工，程式設計師們抱怨不已。

在團隊內部做到團隊責任制，最重要的就是要鼓勵所有人都參與團隊的任何事情。參與不一定是去做，最起碼是一定要了解。試想一個模組從頭到尾我都不瞭解，這個模組的任何決定我都不知道，要我承擔責任這可能嗎？就好像很多工廠門口貼出的大標語：工廠是我家，我是主人翁一樣，只是一句空話。為了廣泛參與，我們需要做到程式碼集體所有權；為了廣泛參與，我們需要頻繁切換結對物件；為了廣泛參與；我們需要業務分析師、程式設計師、測試坐到一起共同分析討論故事，當然這樣做的另外一個好處是避免知識交接產生的浪費；為了廣泛參與，我們有意弱化專家的角色，並在團隊裡做到知識分享；為了廣泛參與，我們設立一個想起來就激動人心的專案前景。

這些就夠了嗎？不夠。在微軟專案求生法則裡，軟體的需求階層被劃分成了5塊，從下到上依次是：生存需求，專案沒有被取消的壓力，工作條件合理；安全需求，滿足個人對時間和功能的承諾，不安排不可能完成的任務；歸屬感與愛，健全的團隊動力；自尊，感到團隊生產力，相信專案重要性；自我實現，持續發展。

關於自尊，我們強調對事不對人，原則如此，操作困難。一個例子是當一個設計違背了設計原則時，直接對程式設計師進行了批評，認為其不負責任，導致了該程式設計師的離職。另外一個例子是在回顧會議上批評了不願重構只想趕進度的行為，某程式設計師認為這就是在批評自己。在具體到某個人和某件事的時候，需要的是瞭解團隊中的每個人，每個人的性格特點，週期性私下溝通是每個迭代經理的職責。什麼事情拿一個大的原則來框，反而會忽略了人本身。一個極端的例子是，有觀點把敏捷之所以推行不了全部歸結到人的問題上，但他顯然忽略了一點，敏捷本來就是來解決人的問題的，一個解決人問題的方案不能實施是因為人的問題，這莫不是一種反諷。

[b]五、全功能團隊[/b]

Scrum提倡全功能團隊。有一種觀點認為追求卓越的團隊，就得所有人會做所有事，不認可分工。從我個人的角度說，我並不認可這種觀點，我的觀點是追求卓越的團隊，就得所有人專注自己的事同時思考所有的事。即我是贊同分工的，為什麼分工，分工才能專業。正如路邊小診所包治百病一樣，專家只存在於特定領域。

一個反例是當一個專案遇到嚴重的效能問題時，開發人員使用selenium來進行效能測試，他們耗費了好幾個月，其中很多時間用來搭建環境，最後起的效果卻並不大。這時需要的是測試人員的專業技能。

另外一個反例是在一個專案後期引入專門的測試人員後，bug被源源不斷的發現出來，一個功能是在列表頁面彈出編輯框，在列表達到20條資料頁面需要滾動時，編輯框沒有跟著滾動，造成最後幾條資料使用者看不見編輯框而不知所措，程式設計師都沒有發現這個bug，但測試人員卻幾乎是立刻發現。這時需要的是測試人員不同的思考問題的角度。

那麼，為什麼我們又要強調全功能團隊，強調從其他人的角度思考問題呢？

首先也是最重要的是避免浪費。軟體開發是腦力活動，業務分析、開發、測試之間存在工作的交接，這種交接其實表現為知識的交接，知識的交接讓分工變得模糊。業務分析更多站在客戶的角度分析問題，程式設計師更多站在技術的角度分析問題，測試人員更多站在客戶使用（易用性、各種邊界）的角度分析問題，最後故事的實現必然是三者協調後的結果，因此每個人都需要從其他人的角度進行思考，越早越頻繁的非正式交流越好，能減少返工。在上面提到的例子裡，由於業務分析師沒有注意到技術的約束，而程式設計師沒有堅持自己的意見（其實是沒有更多的深入思考），導致地圖的實現反覆折騰，產生浪費。

剩下的就都是附帶作用了，比如由於廣泛參與帶來團隊責任感，某個測試人員對寫程式碼非常感興趣偶爾嘗試由此帶來的激勵，以及當測試人員偶爾不夠而程式設計師進行暫時替代從而平衡生產。對於平衡生產，我想說的是偶爾為之是沒有問題的，但一個團隊如果頻繁需要程式設計師代勞測試，那麼問題顯然是測試人員不夠，合適的解決方案應該是增加測試人員而不是要求程式設計師測試。