在《為什麼 Scrum 敏捷方法倡導「團隊成員專注在一個專案上」》一文中，我談到「每個人都應盡可能只專注在一個專案就好」這個乍看之下相當理想化，也跟大多數人的現況相左的觀念。今天這篇文章，我想繼續談談「如果敏捷團隊中有菜鳥，是不是時間就會估不準？進度就會被延誤？」這個也是課堂上常被提問的熱門議題。
這個問題通常會在課堂上的兩個時間點被提問。第一個時間點是在教授「用規劃撲克牌（Planning Poker）估算用戶故事點數（Point）」的時候，第二個時間點則是在教授「開發團隊成員認領用戶故事（User story）的任務（Tasks）」的時候。為什麼會是這兩個時間點呢？原因多半是提問者對「菜鳥是否有能力參與好這兩種活動」心存疑慮！現在我們就來看看，Scrum 敏捷式團隊合作方法有哪些設計可以解除或舒緩這種疑慮。
團隊集體共識決時間估算
Scrum 敏捷團隊在開始進行第一個衝刺（Sprint）之前，必須先對蒐集到的需求（多以用戶故事格式呈現）做快速的時間估算，以對整體專案時程有個概括的掌握，而所使用的工具就是規劃撲克牌！
當團隊對一個用戶故事估算時間的時候，每位開發團隊成員（Development
team）都需從撲克牌中選出一張牌，代表自己的估算值。此時，默契好的敏捷開發團隊可能所有人都選了同點數的牌，馬上就達成了對此用戶故事的時間估算共識。當然，更多時候大家出的牌會比較像一座山一樣的常態分布（Normal distribution），也就是說，多數人會落在山中央附近的小區間之內，落在偏遠山腳處的人會是少數。
這些偏遠山腳處的值，不是過大就是過小，是我們必須加以澄清或排除的極端值。因此，敏捷方法要求這些極端值的估算者，對整個開發團隊說明其如此估算的理由，讓大家充分討論，找出認知落差的地方。
接著，團隊照此步驟再重新估算，直到多數人（團隊可自定一個比例）或所有人達成一個共識為止，這個共識的點數就代表開發團隊對此用戶故事的時間估算值。
到這裡，我們大多數人應該都會以為，那些極端值的出牌者應該都是資淺的人員，其實並不盡然！實務上，我們常常可以看到資淺人員點出了資深人員盲點的例子，就像國王的新衣故事裡的那個小孩，直白地說出大家都不敢說出來的實話一樣，「國王沒穿衣服！」有誠實的小孩在，大家就比較不敢鄉愿，就會敢說出「你的緩衝時間放太多了」、「你的估算太樂觀，風險太高了」等實話！
不管是哪一種原因，導致了誰，出了這些極端值，這種集體共識決時間估算，都可以讓大家對此用戶故事的掌握度變高。
衝刺規劃細部設計討論
正式進入衝刺後，第一個活動就是衝刺規劃（Sprint
planning）。這個活動讓開發團隊深入討論衝刺待辦清單（Sprint backlog）內每個用戶故事的實做細節。這些討論利用團隊的集體智慧，補足個人的盲點與經驗的不足，將可能的設計缺漏給補齊，讓衝刺成果的可用程度更高。
上述的兩種活動，其實也正在為每一位開發團隊成員，包含菜鳥，實施實戰培訓（On-Job
Training），無形之中，也在橫向擴張每位成員的技能和視野，而每位成員的導師（Mentor）也正是所有其他的開發團隊成員！
因此，開發團隊的每個成員，對每個用戶故事的實做掌握度，就可以獲得大幅度的提升，在接下來的衝刺實做之時，每個開發團隊成員便都能有充足的信心去認領各用戶故事的任務（Tasks），工作被延誤的機會自然也就能被大幅地降低了。
團隊集體承擔衝刺成果責任
除此之外，敏捷式團隊合作方法還有另外一層防護罩，那就是，每個衝刺的目標和成果都是由整個團隊來一起扛責任的。因此，如果有某位開發團隊成員的任務出了狀況，那麼，整個團隊都會、也都該進來幫忙，協助排除狀況。
敏捷式團隊合作方法的「團隊集體共識決時間估算」、「衝刺規劃細部設計討論」，以及「團隊集體承擔衝刺成果責任」這三層設計，不僅可以大幅降低時程延誤的機會，更默默地將每個各具專長的開發團隊成員，變身為跨職能戰力的 T 型人才，以達相互備援之效。
當然，為了讓敏捷方法的這些設計發揮最大的綜效，資淺人員平時的系統化培訓也很重要，這樣才能有足夠良好的基礎，在各種敏捷活動當中快速地學習跟進！