l

2014年2月4日 星期二

第八梯次Scrum敏捷方法實作班之Q&A(下)

Jan. 28 17:00~17:30

螢幕快照 2014-01-28 下午5.29.47

 

這系列最後一集,繼續看一下「第八梯次Scrum敏捷方法實作班」學員所問的問題。

學員:工作分配不平均,每個人專長不同,story拆出來有人過多,有人過少,該如何處理?

Teddy:這也是Scrum團隊很常遇到的一個問題,這個問題比較棘手一些。先講「理想」的解法,團隊成員應該培養「多能工」的能力,打破專長的藩籬,這樣一來便可有彈性的認領不同的工作項目。「實際上」,可能不容易辦到,或是在朝向「培養多能工」的路上,會遇到許多障礙。例如,要求程式設計師(JavaScript、Java/C#、SQL)彼此熟悉工作技能也許可以推廣到一定的程度,假設讓Java程式設計師擁有30%的JavaScrip能力、50%的SQL能力,這是有可能做到的。但是,如果要求UX設計師要會寫Java,或是反過來要求Java程式設計師要會化漂亮的icon,可能就變得不切實際。

但話又說回來,讓UX設計師具備寫寫CSS/HTML還有使用JavaScript以及協助測試的能力,這並非是不可能的,而且還可以拓展UX設計師的工作能力,對他而言學習這些技術也是加分。同樣的,程式設計師也不是不能涉獵UX設計的領域,很多傳統上HCI/UI/UX領域的觀念,像是persona、task analysis、designing for error、usability test等,對程式設計師而言也是很有幫助的知識。

有些人對於「多能工」有些誤解,以為搞到最後要讓UX設計師變成程式設計師,讓程式設計師變成UX設計師,這不是整人嗎?當然不可能是以這樣的目標為出發點。在團隊尚未達到具備彈性認領工作的情況下,可以讓「工作過少」的人與其他人一起pairing「結隊開發」,這是一種方法。也有可能在挑選story的時候,考慮到工作分派的問題,儘量不要讓同一個sprint裡面團隊成員可認領的工作勞逸不均。但是,這麼做其實違反了「依據使用者價值來挑選story的原則」。在過渡時期,也許可以接受,但同時要想辦法讓團隊成員可以真正的「分工且合作」,而不是只有分工,沒有合作。

***

學員:Scrum與CMMI的拉鋸…

Teddy:拉鋸?沒什麼好拉鋸的,如果你想死得快一點,就選擇CMMI。嗯嗯,我的意思是說,如果你正在開發軍方專案、要發射衛星,或是軟體預算有幾十億以上規模的專案,也許你可以參考CMMI對於專案控管的要求。另外,國外也有一些案例是採用敏捷方法獲得CMMI Level 2/Level 3認證,想不開 有興趣的朋友們可以自行參考一下。

***

學員:如何讓剛學會Scrum的人改變之前功能部門的工作方式與心態?

Teddy:這一題是送分題,很簡單,來上Teddy的課就對了。

***

友藏內心獨白:明天就要上班了。

沒有留言:

張貼留言