誰能救救敏捷開發團隊裡的菜鳥?

誰能救救敏捷開發團隊裡的菜鳥?

《為什麼 Scrum 敏捷方法倡導「團隊成員專注在一個專案上」》一文中,我談到「每個人都應盡可能只專注在一個專案就好」這個乍看之下相當理想化,也跟大多數人的現況相左的觀念。今天這篇文章,我想繼續談談「如果敏捷團隊中有菜鳥,是不是時間就會估不準?進度就會被延誤?」這個也是課堂上常被提問的熱門議題。

這個問題通常會在課堂上的兩個時間點被提問。第一個時間點是在教授「用規劃撲克牌(Planning Poker)估算用戶故事點數(Point)」的時候,第二個時間點則是在教授「開發團隊成員認領用戶故事(User story)的任務(Tasks)」的時候。為什麼會是這兩個時間點呢?原因多半是提問者對「菜鳥是否有能力參與好這兩種活動」心存疑慮!現在我們就來看看,Scrum 敏捷式團隊合作方法有哪些設計可以解除或舒緩這種疑慮。

團隊集體共識決時間估算

Scrum 敏捷團隊在開始進行第一個衝刺(Sprint)之前,必須先對蒐集到的需求(多以用戶故事格式呈現)做快速的時間估算,以對整體專案時程有個概括的掌握,而所使用的工具就是規劃撲克牌!

當團隊對一個用戶故事估算時間的時候,每位開發團隊成員(Development team)都需從撲克牌中選出一張牌,代表自己的估算值。此時,默契好的敏捷開發團隊可能所有人都選了同點數的牌,馬上就達成了對此用戶故事的時間估算共識。當然,更多時候大家出的牌會比較像一座山一樣的常態分布(Normal distribution),也就是說,多數人會落在山中央附近的小區間之內,落在偏遠山腳處的人會是少數。

這些偏遠山腳處的值,不是過大就是過小,是我們必須加以澄清或排除的極端值。因此,敏捷方法要求這些極端值的估算者,對整個開發團隊說明其如此估算的理由,讓大家充分討論,找出認知落差的地方。

接著,團隊照此步驟再重新估算,直到多數人(團隊可自定一個比例)或所有人達成一個共識為止,這個共識的點數就代表開發團隊對此用戶故事的時間估算值。

到這裡,我們大多數人應該都會以為,那些極端值的出牌者應該都是資淺的人員,其實並不盡然!實務上,我們常常可以看到資淺人員點出了資深人員盲點的例子,就像國王的新衣故事裡的那個小孩,直白地說出大家都不敢說出來的實話一樣,「國王沒穿衣服!」有誠實的小孩在,大家就比較不敢鄉愿,就會敢說出「你的緩衝時間放太多了」、「你的估算太樂觀,風險太高了」等實話!

不管是哪一種原因,導致了誰,出了這些極端值,這種集體共識決時間估算,都可以讓大家對此用戶故事的掌握度變高。

衝刺規劃細部設計討論

正式進入衝刺後,第一個活動就是衝刺規劃(Sprint planning)。這個活動讓開發團隊深入討論衝刺待辦清單(Sprint backlog)內每個用戶故事的實做細節。這些討論利用團隊的集體智慧,補足個人的盲點與經驗的不足,將可能的設計缺漏給補齊,讓衝刺成果的可用程度更高。

上述的兩種活動,其實也正在為每一位開發團隊成員,包含菜鳥,實施實戰培訓(On-Job Training),無形之中,也在橫向擴張每位成員的技能和視野,而每位成員的導師(Mentor)也正是所有其他的開發團隊成員!

因此,開發團隊的每個成員,對每個用戶故事的實做掌握度,就可以獲得大幅度的提升,在接下來的衝刺實做之時,每個開發團隊成員便都能有充足的信心去認領各用戶故事的任務(Tasks),工作被延誤的機會自然也就能被大幅地降低了。

團隊集體承擔衝刺成果責任

除此之外,敏捷式團隊合作方法還有另外一層防護罩,那就是,每個衝刺的目標和成果都是由整個團隊來一起扛責任的。因此,如果有某位開發團隊成員的任務出了狀況,那麼,整個團隊都會、也都該進來幫忙,協助排除狀況。


敏捷式團隊合作方法的「團隊集體共識決時間估算」、「衝刺規劃細部設計討論」,以及「團隊集體承擔衝刺成果責任」這三層設計,不僅可以大幅降低時程延誤的機會,更默默地將每個各具專長的開發團隊成員,變身為跨職能戰力的 T 型人才,以達相互備援之效。

當然,為了讓敏捷方法的這些設計發揮最大的功效,資淺人員平時的系統化培訓也很重要,這樣才能有足夠良好的基礎,在各種敏捷活動當中快速地學習跟進!

 

原文出自威廉網紙   誰能救救 Scrum 敏捷開發團隊裡的菜鳥?

0 則讀友回應