《軟體工程與 VSTS》的第九章是在討論專案開發時經常碰到的疑難雜症,以及如何利用 VSTS 的統計報告來發現、診斷這些問題。其中談到一個挺有意思的術語:「時程膽小雞」(schedule chicken),它指的是開發人員因為無法承受時程的壓力,而做出一些敷衍、耍小手段等扭曲的行為,好讓自己的工作看起來已經達到預定進度了。
參與過團隊開發的讀者也許也曾碰過「時程膽小雞」的情形。比如說,在開專案進度會議的時候,可能每個人都說自己的進度沒有落後,其實大家都在等別人承認進度落後。更誇張的,可能還有人會故作姿態:「如果你那邊還要再一兩個星期才能完成,我這邊可以等,我沒問題啦!」如果你回答兩天內就可以完成,他可能就開始緊張了。
參與過團隊開發的讀者也許也曾碰過「時程膽小雞」的情形。比如說,在開專案進度會議的時候,可能每個人都說自己的進度沒有落後,其實大家都在等別人承認進度落後。更誇張的,可能還有人會故作姿態:「如果你那邊還要再一兩個星期才能完成,我這邊可以等,我沒問題啦!」如果你回答兩天內就可以完成,他可能就開始緊張了。
再舉一個從別處看到的「時程膽小雞」例子。假設程式經理宣佈某一天必須實施「程式碼凍結」(code freezing),從那天開始不能再增加新的程式,只允許修改有問題的程式碼。於是程式設計師們基於畏懼時程的心理,就算到時候無法如期完成預定進度,還是會在程式碼凍結日的前一天簽入(check-in)所有的程式碼,但這些程式碼可能都沒經過測試、甚至無法執行或建置(管它的,先簽入再說,反正凍結之後是允許修改的)。
個人以為,如果程式設計師沒有勇氣抵抗時程的壓力,而採用敷衍了事或吹噓進度的作法,最後吃虧的還是自己,當然團隊也是。不過話說回來,如果我上班時偷雞摸魚,四處上網看"風景圖"、聊八卦,等到工作時程快要到 deadline 時才開始處理正事,這種情況可就不能說自己是在發揮抵抗時程壓力的勇氣了。
p.s. 以上的例子取自這篇部落格文章:Schedule Game #1: Schedule Chicken
hi 版主所提的時程膽小雞例子 我認為有些微不合適,
回覆刪除假設程式經理宣佈某一天必須實施「程式碼凍結」,
從那天開始不能再增加新的程式,只允許修改有問題的程式碼。
很明顯的版主所說的情況,
程式碼沒經過測試、甚至無法執行或建置就直接被上傳了,
就一定會發生。
反過來說就是意謂著程式經理默許,甚至是允許這種錯誤發生。
在下就曾有過在開發時程過短的專案中擔任過PM,
也就是版主所提的類似程式經理的角色。
這裡就不去討論時程過短的原因,(大多數也是客戶本身的問題)
但就剩下有限的時程當中,
在下必須以些微的政治手段達成以空間換取時間的目的。
以當時來說當時該專案有238個模組需要開發,
約略有20個子系統要完成,
誇張的是還有部份的SCOPE還沒談妥,
開發時程只有三個月。
原本的時程要達成專案100%的完成度,
那是絕對不可能的事,
我所謂的以空間換取時間的目的,
就是將專案目標切割成數段,
20個子系統分段拆開交付,
再將談成或未談成的模組也拆開,
分段驗收,分段交付。
按照正常作法,最後專案一定會時程爆炸,
客戶翻臉,老闆氣炸,自己賠了專案也沒賺到錢。
但我這樣子作,最後專案卻完善的驗收結案了。
我記得再當時我還指示我的MEMBER,作版主所提的事情,
這些程式碼也是都沒經過測試、甚至無法執行或建置,
為什麼因為我允許再這個時間點必須如此作。
而在當時如此作的MEMBER,我卻完全不認同他門是時程膽小機。
如果是 PM 或 leader 明白指示開發團隊成員:無論程式能不能執行或建置,都要在某天以前簽入。那麼我認為這的確不是團隊成員的問題。前面的例子是團隊成員由於恐懼的心理,而做出 PM 不知道的危險動作。若此動作是 PM 允許或明白指示的,相信必有其當時考量的必要原因,而成員也只是依上頭的指示行事,就沒有膽小不膽小的問題了。
回覆刪除只是有一點好奇,您提到「這些程式碼也是都沒經過測試、甚至無法執行或建置」的意思,是連無法建置的 code 也簽入到版本儲存庫嗎?這在我的團隊裡是絕對不允許發生的。