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 算是用到賺到，幾乎立即可上手。

***

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