Sustainable Pace

January 18 09:58~11:25

這幾天作息有點不正常，晚上睡不著，白天爬不起床。有點年紀了，作息不正常這件事對於「生產力」和「身體健康」都有很大的殺傷力。昨天晚上也是弄到凌晨2點多才睡著，但是今天下定決心要把「時差」調整回來，早上8點好不容易趕跑周公之後吃完早餐就準備開工了。

昨天晚上睡得晚，睡前拿起一本買了一年半但卻幾乎沒看的書想說能不能幫助睡眠，沒想到愈看精神越好...Orz。這本書叫做 Kanban: Successful Evolutionary Change for Your Technology Business，Teddy 今天想談一下書中提到的 Sustainable Pace （穩定的步伐，可持續的速度）這個觀念。

Sustainable Pace 是 agile community （敏捷社群）很早就提出來的一個觀念，講單的來講就是說：「每週工作40小時」。看過 Teddy 部落格的鄉民們應該知道 Teddy 是不相信每天加班可以提高生產力這種作法。Teddy 年輕的時候也是幾乎天天加班，睡在公司也是常有的事。現在回想起來，雖然偶爾靈感來了加一下班可以有「驚人的生產力」，但是很多時候加班其實只是因為東西一直做不完，或是遇到問題卡住了，但是公司或是團隊（有團隊嗎？）也沒有提供一個機制協助 Teddy 解決問題，而 Teddy 也沒有能力可以只依靠自己就可以有效率地解決所有的問題。再加上專案的時程都是業務或是老闆「跟著感覺走」而訂定出來的，身為小小工程師的 Teddy，「事情沒做完怎麼好意思下班」呢？（迷之音：如果老闆叫你去煮沸海水，那不是永遠都不用下班了？！）所以不管有沒有實際的進度，也只能「撐在那邊」，至少「沒有功勞也有苦勞」，老闆看你這麼「拼」，就算是時程到了結不了案也不好意思對 Teddy 過於苛責。

Teddy 很小的時候家裡開了一家小小的塑膠加工工廠，趕出貨的時候除了工廠員工要加班以外，連 Teddy 也被「動員」去幫忙。加班和增加人力對於生產力有沒有幫助？絕對有，因為這是一間「代工工廠」，工人只是做著重複性的工作。

***

一般江湖上預估專案開發時程的作法，不外乎：

• 分析需求：看看有多少個 use cases，function points，或是 stories。
• 分析人力：看看可以投入多少人到專案中。
• 分析風險：...誰那麼認真啊...XD。

假設有 100 個 stories，團隊有 5 個人，平均一人一個禮拜可以做完一個 story，所以這個專案需要二十週也就是大約五個月可以做完。

問題來了，「平均一人一個禮拜可以做完一個 story 這是怎麼估出來的」？這裡講得「一個人」是指怎樣的人？剛畢業的菜鳥，還是已經有5-6年以上工作經驗的工程師，還是寫得一嘴好程式的待退資深員工？這「一個人」的技術背景是什麼？對 Java 很熟？很抱歉，這個案子要用 VB.NET...XD。

如果今天問題換成「下個球季洋基隊打入季後賽的機率有多少」？請問鄉民們會如何去「估算」這個機率？當然是要看「洋基和大聯盟其他球隊的實力」。也許這個比喻並不是很洽當，因為開發軟體並不是打球，但是軟體畢竟是要靠「人（一群人，也就是團隊）」所開發出來的，如果預估專案時程的時候所思考的只是「一個個沒有面孔的派遣人力」，那麼用這種方式所組成的團隊其「生產力」與「品質」都是很難預估的。

***

扯了老半天這和 Sustainable Pace 有何關係？鄉民們應該都有打籃球的經驗，打球的時候最重要的就是要選對 team members，持續的訓練，加上有機會就去參加各種比賽以提高團隊的實力。同一批人馬在一起打球，合作久了之後團隊的「戰力」就變得可以預估。開發軟體也是一樣，敏捷方法強調「人（團隊）」與「溝通，合作」的重要性。一個團隊在導入 Scrum 或是 XP 這種敏捷方法之後，大概六個月左右這個團隊的 Pace （腳步，生產力）就可以慢慢地穩定下來。當一個團隊找到自己的 Sustainable Pace 之後，「預估時程」這件事就變得「不是那麼討厭」，而且可以越估越準。

「培養團隊」是一件費時、費力、又費心的工作，不見得每個公司或是組織的文化都支持這樣的作法。還是那句老話，畢竟「加班」對於公司與員工而言，是一種最不花腦筋（更棒的是又不花錢...因為責任制啊...Orz）又可以「保護」雙方的一種工作模式，幹麼花時間去建立團隊的 Sustainable Pace 呢。

***

友藏內心獨白：我不當派大星，誰當派大星。