l

2012年3月13日 星期二

免費的講座難道就不能問點簡單的問題嗎(下)

March 12 21:02~20:28

Team

回到昨天的問題,如果你被指派去組成一個Type D的團隊,你會怎麼作?做到了又可以有那些好處?。

先談要怎麼做,首先考慮Scrum的兩個主要影響工作分派的活動:

  • Sprint planning meeting:在此活動中,首先遇到的問題就是story點數估算以及task時數估算的問題。假設有一個手機App的story如下「As a user, I can open a downloaded pdf e-book on mobile phones running Android 4.0」。
    • 估算story point:三方人馬(UI、App、後台)一起估算這個story point,一開始每個人所估算的點數一定是差異很大,例如UI的人只知道這個story可能需要設計電子書閱讀器的使用者介面,還有翻頁等效果。而App的人腦袋想的可能是如何讀取並操作pdf格式的檔案,而後台的人可能對於這個story到底需要做些什麼完全沒有任何概念。第一輪出牌之後,Scrum Master發現大家所估算的點數差異太大,於是請各方人馬說明估算的依據,讓團隊成員可以更加了解這個需求的內容。此時Product Owner要適時地出來說明需求的內容。例如,UI的人可能把這個story估40點,因為他們認為要設計一個很好的書本翻頁效果需要花很多時間去設計。而App的人可能只估了13點,因為他們認為這個story的目的只是要能夠讓電子書閱讀器讀取pef格式的檔案就好了,至於翻頁或是其他閱讀輔助功能並不包含在這個story中。在討論的過程中,發現團隊成員對於需求的內涵各有不同的解讀,於是就需要Product Owner來說明。透過反覆地「集體出牌估算點數—>討論」這樣的過程,團隊對於這個需求越來越清楚,且對於估算這個需求的story point也有了共識。這將可大大減少日後實作此story可能衍生的不必要誤會。
    • 切割task並估算施工時間:經過討論之後團隊對於每個story要做什麼已經有了一定的了解,接下來要討論如何將每一個story細分為若干的可施工的tasks。以上述story為例(假設電子書已經存在本地端,因此該story不需要任何後台功能),可能的tasks有「設計使用者介面」、「撰寫讀取pdf檔案模組」、「實作使用者介面」、「撰寫顯示pdf檔案程式」、「撰寫自動化驗收測試」、「撰寫使用文件」、「在CI系統上執行自動化驗收測試」。假設團隊成員經過類似故算story過程的一番討論之後也可以估出每一個task的時數。
  • Daily Scrum:Stories與tasks都估算好之後,接下來的問題就是認領task的問題。當UI的人認領「設計使用者介面」,那麼其他人要做什麼?答案很簡單,該做什麼就去做什麼…XD。例如,App工程師可以跟UI工程師一起合作完成「設計使用者介面」,如此一來當這個task完成時,App工程師就可以比較無痛的去認領「實作使用者介面」這個task。那麼鄉民們一定會問,當App工程師跟UI工程師合作「設計使用者介面」時,其他們要幹嗎?就一樣啊,看看有那些事可以做就去認領過來做。例如,後台或是其他App工程師可以認領或是共同合作「撰寫讀取pdf檔案模組」、甚至是「撰寫自動化驗收測試」或「撰寫使用文件」。如果在這個story中真的都找不到任何可以做的工作,那退而求其次先做下一個story的工作。但是切記原則上還是要以重要性較高的story為優先施工的對象。

看到這邊一定有鄉民會說,那有那麼理想啊。就算App工程師或是後台工程師願意跟UI工程師一起完成「設計使用者介面」這一類的工作,但是UI工程師不見得就願意或是有能力可以跟App工程師或是後台工程師一起完成類似「撰寫讀取pdf檔案模組」或是「撰寫自動化驗收測試」等工作。實際的情況也許是如此,但這還是要看團隊中所謂的UI工程師的技術背景以及團隊是否真的一直都有那麼多所謂的「UI相關工作」可以做。如果真的有很多所謂的「UI相關工作」,那麼也就不太需要去擔心UI工程師沒事做。如果沒有那麼多的「UI相關工作」,那麼也不需要強求UI工程師去學會寫前台或是後台的程式,但是至少要能夠稍微了解前台與後台運作的模式。另外,要求UI工程師寫點測試案例(不管是不是自動化測試),使用手冊,或是做做人工測試,這應該也不為過吧。

***

Teddy曾經說過好幾次,Scrum施行到最後,除了要讓團隊達到自我管理的目標以外,最困難的當屬「派工」的問題了,也就是Teddy在上一集所講的如何讓不同專長的人一起很順的共同合作開發一個產品或是專案。這個問題真的很難,也有可能要經過6個月以上才可以看出一些成效。讓不同專長的人同屬一個團隊,真的很重要,因為這樣大家才會有種「共同承擔產品成敗」的歸屬感,而不是「我只是被指派去完成某些性質很接近的工作(例如UI設計),但我與這些工作所屬的產品成敗完全沒有任何關係」。

 

每個人都可以認領每項工作是「目標」而不是「規定」,依據團隊的特性自行決定要如何朝向這個目標邁進。人類是很強的,不要小看人的能力與潛能。

***

友藏內心獨白:寫到最後突然覺得這個問題好像談過好幾次了耶。

沒有留言:

張貼留言