這是《落葉》文集里第?79?片落葉，希望你能喜歡，不為別的，只為這份堅持。
再敏捷的流程，也得以人為本，由此可見敏捷團隊有多重要，今天我們來聊聊在組建敏捷團隊時最容易犯的“十宗罪”吧。
“十宗罪”之一：害怕改變
Change is always hard. 因為人人都害怕改變，特別是從一種非常成熟、穩定，并且已經習慣成自然的方法或流程，轉而使用一種自己從未接觸過的，或者說只是有一些了解的新方法，肯定會有一種慣性抵觸。所以在團隊組建初期，實施 Scrum 流程的時候，阻力肯定會很大，因為主動性不夠，而導致效率和質量也會不高。
這時候，Scrum Master 不能一味地只是加強宣貫和培訓，而是需要多從一些利益點出發，讓團隊成員看到如果按照 Scrum 的流程去做，會帶來什么樣的好處，會產生什么樣的利益，這樣他們才能更好地認識到新流程的優點，會更愿意接受它，會更主動地去按照流程標準做事情。
這就像我們在其他方面做出改變一樣，只有當人們看到新的改變會給他帶來巨大利益的時候，人們才會越積極主動地去改變。
“十宗罪”之二：不完整的職能結構
敏捷理論中的確有提及，在 Scrum 團隊里，應該要淡化角色之分，不要區分什么開發或者測試，理想中的團隊應該是每個人都能勝任不同崗位上的工作，簡單來說，就是開發寫完代碼，也可以去測試，測試也可以去寫代碼。所以很多團隊在組建時，就開始參照這個說法，認為只要人數達到了 Scrum 的標準即可，在資源不足的情況下，就會模糊角色職能，我就見過一個全是開發組成的 Scrum Team，PO、SM、Dev和QA 都是開發人員組成的。
他們忽略了一個前提，就是理想的 Scrum Team 可以這么做，或者說這只是 Scrum Team 的一個理想目標，先不說最終能否實現吧，但至少我認為，在初期，沒有可能做到這一點。
在 Scrum Team 組建的初期，還是應該各司其職，每個崗位都有對應的人員擔當，當團隊磨合的相對成熟之后，再開始在某個 Sprint 里開始嘗試交叉角色去承接任務，或者類似角色輪崗的形式，而且這也應該是在某個或某些 User Story 里去小范圍的實踐，這個周期理論上不會短，因為這已經不是簡簡單單地模塊交叉開發或交叉測試那么簡單了，這是崗位交叉了，對團隊里每個成員的綜合能力要求非常高。
而且個人認為，現在很多公司的研發團隊，因為在初期招聘時，因為不同時期有不同的需求，開發和測試人員其實并沒有達到理想敏捷團隊里所要求的那樣，可以既做開發，又做測試。而且，大多數公司對于人員的訴求，其實還是偏專一型的，另外，從人力成本上來說，也不太可能有公司能同時供養很多全棧型的工程師。
所以，我其實還是傾向于，在一個 Scrum Team 里，角色不能模糊，崗位不能缺失，架構層面或管理層面的人力資源不能交叉使用，但可以多團隊共享，執行層面的人力資源可以交叉使用，但最好不要多團隊共享。
作者簡介：14 年測試經驗 + 11 年項目管理經驗 + 11 年團隊管理 = 一個測試老兵
