l

2012年1月18日 星期三

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 呢。
***
友藏內心獨白:我不當派大星,誰當派大星。

沒有留言:

張貼留言