l

2011年7月28日 星期四

People over Process (1)

April 28 22:28~23:52

幾天前指導教授拿了一篇 IEEE Software 上面熱騰騰剛出爐的 paper 給 Teddy 看:

People over Process: Key Challenges in Agile Development, July/August, 2011, IEEE Software, pp. 48-57.

自從畢業之後很少有時間去看 IEEE Software 上面的 papers,以前還在念書的時候,每期的 IEEE Software 上面文章 Teddy 都會快速翻過一次,看看有沒有值得看而且看得懂的文章。工作之後『國事如麻』,專案嗷嗷待哺,鮮少有時間定期去找看看有沒有值得讀的 papers。還好有善心人士介紹,這次才有機緣讀到好 paper。這篇 paper 是作者訪問了 17 個採用 agile methods 的組織,整理出這些組織在實施 agile methods 時遇到關於『』的挑戰。這幾個受訪單位,採用的 agile methods 包含了 :
  • XP + Scrum:10 家
  • Lean:2 家
  • Crystal:1 家
  • XP:2 家
  • Scrum:2 家
由此看來 XP, Scrum 佔了大多數,給鄉民們參考一下。

接下來分幾天介紹一下 paper 中所提到的 『People challenges』,每一點 Teddy 都十分贊同。

Developer fear of skill-deficiency exposure 

第一個挑戰是『開發人員擔心自己能力不足之處被暴露出來』。Agile 團隊強調溝通與互相合作,一切講求透明化。套句古人所說的話:『知之為知之,不知為不知,是知也』。說來容易,做起來卻不簡單。試想一下,假設你到這間公司工作已經三年多了,某日你被要求與某個新進同事進行 pair programming,而且由你主筆。此時你可能心裡會想,糟了,讓同事知道我變數名稱取得很爛,我不太會寫 unit tests,或是我根本不會用 Eclipse 上面的 refactoring 功能....等等等。這種感覺,就好像是明天要期末考了,而你卻都還沒唸書。哇,agile 好可怕啊。

或是在每天 daily Scrum meeting 的時候,有一個實做 DAO(Data Access Object)的 task 你做了兩天還沒做完,此時你內心又會想,糟了,別人做類似的功能只花了五個小時,但是我寫了兩天居然還沒寫完,這樣別人不是發現我對於 database 不熟這件事了嗎!這豈不是又要動搖國本啊...XD。

又或者在跟團隊成員討論設計的時候,耶,怎麼別人開口就是『這邊可以套用 Observer pattern』,『把這個物件作成一個 Singleton』,不然就是『這裡要傳入一個 Collecting Parameter』,『這段程式要放在一個 blanket catch 裡面』。剛剛『花生』什麼事情,你們講的是中文嗎,我怎麼都聽不懂?

***

在傳統的軟體開發中,大家各作各的,雖然是同一個 team,但是在某些團隊中,其團隊成員的互動幾乎可以用『老死不相往來』來形容。既然別人不知到我在幹麼,這樣我的弱點就不會被發現。反正我每天也是都跟大家一樣加班到很晚啊,事情做不完我也沒辦法(Teddy 內心獨白:這個現象好像可以用濫竽充數來形容)。Developers 雖然付出加班的代價,但是獲得『保有自己能力不足不被發現』的安全感。受傷的是誰?一開始是專案進度,接著是公司,最後傷到自己。

所以要不要採用 agile methods?當然是寧死不從啊。為什麼?這樣我的缺點不是被大家看光光了,這和沒穿衣服上街有何不同,堅決反對啦。我們要爭取 司法人權 coding 人權

解法呢?Paper 建議 provide an environment where developers feel safe to expose their weaknesses。Teddy 知道鄉民們在想什麼,這句不是廢話,的確是廢話。不過 paper 厲害的地方就是可以講得讓鄉民們覺的這是一句『值得購買的廢話』:
  • 在受訪的 company C 中,開發人員每兩週將內心覺的不方便公開討論的議題寫在小紙上。但是關於這張小紙條要傳給誰 paper 居然沒交代...XD。
  • 在 company D 中,資淺的開發人員可以自行決定是否在 stand-up meetings 中說出自以遇到的問題。
  • 在 company B, D, M 中,資淺的開發人員另外還有一個特別為他們準備且時間較常的 stand-up meetings。在這個加長版的 stand-up meetings 中,有專門的 mentors 提供特別服務。
  • 至少有九間受訪公司在實施 pair programming 時,採用『能力較弱開發人員』搭配『有經驗開發人員』的方式來提昇能力較弱開發人員的能力。

***

以上幾項,Teddy 只實施過 pair programming 這一項,非常有用。另外對於新人 Teddy 也會親自施予若干小時的『特訓』。還有一點,找人的時候如果能找到接受 agile 精神的人,那就可以省了許多功夫。剛好這一陣子新進的幾位新人都學過 Scrum,所以 Teddy 算是用到賺到,幾乎立即可上手。

***

友藏內心獨白:絕大部分的問題,幾乎都是人的問題。

3 則留言:

  1. 雖然不是很formal的pair programming 但這幾年專案下來 每次(年)有新的人加入 pair programming確實可以讓新人快速進入狀況

    回覆刪除
  2. July/August, 2001?
    應該是July/August, 2011. ^_^

    回覆刪除
  3. To 賴小群:

    已修正,感謝。

    回覆刪除