日前在為某企業進行敏捷式專案管理的導入輔導時，有位同仁這樣問我，「老師，敏捷開發團隊的成員，從頭到尾都不能換人嗎？譬如，臨時加人進來，或有人完成工作後就離開，去做其他專案的事？」
「你為什麼會想在要這樣做呢？」
「因為有的人比較熟悉這個衝刺要做的任務，有的人比較熟悉下個衝刺的任務，這樣安排不是可以讓他們工作得更有效率嗎？」
關於這個問題，我會說，方法沒有絕對正確或錯誤，只有「適合」與「不適合」，或是「有效」和「無效」。
因應異動的協同作業失效
相信大家都很熟悉，在傳統式專案管理模式下，團隊成員之間的合作是傾向於詳細分工的，也因此，多數人就會理所當然地認為，顧好自己的工作就好，不太有人會主動去了解他人的工作狀況。
如果說，專案工作真的能夠被 100% 地完整周延考量，也能被 100% 地切割得一清二楚分派給不同的人做，那麼，這樣的做法當然也不會有什麼問題。問題就在於，這種
100% 是不可能達得到的（至少我的經驗是這樣）。
正因如此，當某人的工作內容有異動時，他人的工作理應也會受到程度不一的影響，可是，在傳統式專案管理模式下，受到異動影響的雙方或多方當事人，他們自己卻不知道會有這種影響，因此也就不會去適當地因應這個異動。這種情況常常在最後整合測試階段，甚至是出貨以後，才會被暴露出來，而通常此刻已為時已晚。
上述這種團隊成員間欠缺及時有效溝通協調的現象，我稱之為「協同作業失效」，而這正是敏捷方法擅長解決的問題之一。
協同作業失效不僅會讓問題潛伏更久，造成更多、更嚴重的品質瑕疵，也會因此而造成團隊成員之間更多、更嚴重的無謂衝突。因為，大家在最後階段的緊迫時間壓力下，甚至是專案已開始延誤的情況下，加上長期加班趕工，身心俱疲，會更難以心平氣和地溝通協調合作。
解決上述問題的辦法其實也不難，透過團隊成員間的密集有效面對面溝通，把小問題及早曝光加以應對，這樣就能避免日積月累出眾多不良副作用，最後才一次大爆發。要做到這點，團隊成員就不能夠來來去去太頻繁，因為這樣就無法建立必要的團隊合作默契和良好情感。
分工與備援的兩難
團隊成員之間的過度詳細分工，還會衍生出另一個問題，那就是「工作無法獲得充足的備援人力。」
在傳統式專案管理模式下，我們經常會聽到這樣的說法，「某某某今天請假，所以沒人知道他的工作狀態…」、「因為人力吃緊，所以某某某的工作沒有其他人知道該怎麼做…」凡此種種，都在在凸顯出「工作缺乏充足備援人力」的問題。
在傳統式專案管理模式下，我們常常看到，一旦某位成員生病、請假，或離職，他／她的工作就會停擺（或至少停擺好一陣子），沒人能備援，其他相關合作夥伴的工作也會遭受阻礙，專案進度因此大受影響，這些都是因為，「平時」就沒人去適度了解該成員的工作內容所造成的。
敏捷方法鼓勵團隊成員多學習、了解其他夥伴們的工作和職能，盡可能地讓每一位成員都能有第二專長職能，這樣隊上的任何成員就都有人可以備援補位，成員異動所造成的諸多問題和衝擊也就能降到最低。
這樣做還有另外一個好處，那就是，任何工作都將不再受限於單一個人的智慧，而會有其他人可以共同設計，思慮將更為周延。這當然得付出點代價，那就是，每個人都得多花些時間在學習第二專長之上，而且，在專案人力上，組織也要給的充裕些。
建議
回到學員提問的問題，如果說，整個專案所需的團隊成員，平時就已經很熟絡，默契良好，其實這個團隊已經滿足了許多敏捷方法要求的施行要素，人員在衝刺（Sprint）的交替之際進出替換，個人認為並無不妥，只要新進到這個衝刺的人能真正落實「只專注在此一專案」。
然而，這種做法在「工作的備援人力」上依舊是個問題。因為臨時加入本衝刺的成員，可能下個衝刺就離開專案了，這麼一來，這個成員是不可能有動機去了解和學習其他夥伴們的專長的。
關於這一點，我的建議是，視專案特性與人員能力，開發團隊成員至少要在團隊內待滿 2-3 個月，中間不要有異動，這段時間大概可以讓每位成員培養出初級到中級的第二專長，或許這樣就可以稍解「工作備援人力」的問題。
敏捷方法的設計框架很簡單，簡單到很多組織在導入的時候會誤判形勢，過於輕敵，以為隨便自己試試就能成功對付既有的專案管理問題。然而，就我授課與輔導的經驗而言，一點也不然。
如果沒有掌握到敏捷方法的原始設計精神和理念，並結合組織的各種現況去正確調校，要把敏捷方法施行得宜，獲臻明顯成效，其實，一點也不容易。