為什么討論時間的碎片化 ？

 

產(chǎn)生有效成果的智力活動，總是需要連續(xù)的時間來保證。許多忘我思考的典故都證明了這一點。 軟件開發(fā)是一種智力活動，因此也遵循這一道理。 打斷某人的工作，不論是智力工作還是體力工作，對工作的效率和產(chǎn)出總會產(chǎn)生負面影響。 只不過與體力勞動不同， 智力勞動受到這方面的負面影響要大得多。 對一名建筑工人，如果他連續(xù)工作的60分鐘被打斷成3個不連續(xù)的20分鐘， 其產(chǎn)出與連續(xù)工作60分鐘相比，是基本一致的。而對一名軟件開發(fā)人員，3個不連續(xù)的20分鐘內(nèi)的工作成果，恐怕只能相當連續(xù)的40分鐘的成果。有20分鐘的時間被丟失了。 為什么會這樣？ 誰偷走了他的時間？下文試圖給出解釋。

 

時間如何破碎 ？

 

仔細觀察我們每天的工作時間花費就不難發(fā)現(xiàn)，存在天然的時間斷點把我們本來連續(xù)的工作時間碎片化。午休、倒咖啡、去洗手間等等。除此之外，一些偶發(fā)的事件也能打斷我們的思緒，比如一個電話，一個郵件提醒，或一個 MSN 消息。 我們不是古廟里的僧侶， 因此塵世中的干擾總是存在。 但這些不是本文討論的內(nèi)容。 我想討論的， 是在軟件開發(fā)管理中不合理的做法導致的時間碎片化。

我認為以下做法是不合理的。

 

一人多任務(wù)

過分強調(diào)面對面溝通

過多的全體會議

 

 

一人多任務(wù)

 

有些管理者喜歡讓開發(fā)人員同時在幾個任務(wù)上展開工作，而不是順序地完成它們。 這樣做可能基于以下理解：

 

1.任務(wù)越早展開，越能盡早暴露問題，從而便于及時解決，降低管理上的風險。

2.開發(fā)任務(wù)緊，多任務(wù)安排可以增大開發(fā)人員的負荷，防止他們偷懶。

3.多個任務(wù)具有相同的優(yōu)先級，而且彼此之間沒有依賴關(guān)系，因而應(yīng)該同時展開。

 

 

任務(wù)啟動的早，并不能消除問題，只是把問題提前了。從這個角度講，問題的總量并不會減少。既然這樣，過早地暴露出問題有什么好處呢？ 在項目的可用資源（人力、時間）一定的情況下， 我看不到這樣做的好處。 如果項目資源可以增加， 一人多任務(wù)的情況就不會出現(xiàn)，也就沒必要討論了。

 

通過多任務(wù)來提高開發(fā)人員的工作強度并防止他們偷懶的做法，我認為是幼稚的。管理者應(yīng)努力和開發(fā)人員建立起信任關(guān)系，并通過其他方式激發(fā)他們的干勁。 當他們像負重的駱駝一樣被對待時，作為會說話的智能生物，開發(fā)人員知道如何把超額的重物放在原地，而令管理者覺得他們在負重前行一樣。

 

一人多任務(wù)的安排的問題在于，人不是多核系統(tǒng)。 他只能采用交替工作的方式來“同時”展開多項任務(wù)。當他在不同任務(wù)間切換時，特定任務(wù)上的工作時間就不再連續(xù)了。就像單核CPU執(zhí)行多任務(wù)一樣，這是讓開發(fā)人員的大腦應(yīng)用 TDM 技術(shù)。不幸，人腦不是高效的 TDM 設(shè)備。

無論如何，一人多任務(wù)的安排都應(yīng)該努力避免。 如果僅僅因為優(yōu)先級相同，那這些任務(wù)可以隨機地順序安排。

*[TDM]: Time-division multiplexing，即時分多路復用。

 

過分強調(diào)面對面溝通

 

面對面溝通是敏捷開發(fā)實踐中強調(diào)的一個重點。許多管理者據(jù)此在整個組織內(nèi)鼓勵面對面的交流。我不認為這是一個好的做法。敏捷開發(fā)隊伍是由 自組織 （self-organized）的小團隊構(gòu)成。敏捷開發(fā)中面對面溝通是指自組織團隊內(nèi)部的溝通。這種內(nèi)部的溝通，被證明是高效的。 但是，把這種方式推廣到自組織團隊的邊界之外，則是糟糕的做法。外部的溝通以受控的、相對正式的方式進行，是對自組織的團隊的保護，使之免受干擾。自組織團隊就像封裝良好的軟件組件。它應(yīng)該是內(nèi)聚的，外部只能通過定義良好的接口與之交互。

 

很多時候，面對面交流，僅僅是提高了交流發(fā)起者的效率而已。（甚至這一點也值得懷疑，因為經(jīng)過仔細斟酌寫下的文字，通常要比現(xiàn)場發(fā)揮的言語表達的更清楚）。當你禮貌地找某人談話時，你已經(jīng)禮貌地打碎了他的時間。你在損害他的效率。

 

說到這里，請讀者不要誤解。我不是在鼓勵開發(fā)人員成為像患有自閉癥一樣的程序怪人。我只是想強調(diào)，過多的當面交流會導致時間的碎片化，從而影響整個團隊的效率。 有其他溝通方式（比如郵件），能把對他人的干擾降低。

 

過多的全體會議

 

喜歡召開全體會議的團隊領(lǐng)導者，在召開全體會議前請思考，會議內(nèi)容是否是每個人都必須知道的？ 是否是必須口頭傳達給每個人的 ？ 如果是一場討論會，是否這些人都需要參與到討論中來？ 由于全體會議打斷了每個參與者的時間，時間碎片化效果擴展到了全體，因而影響更大。

 

時間碎片化的后果

 

時間碎片化有兩個主要后果，即有效工作時間的減少和發(fā)生缺陷的可能性增大。

 

有效工作時間的減少

 

軟件開發(fā)工作是劇烈的腦力活動。象引擎一樣，人的大腦在進入高速運轉(zhuǎn)前，需要一個預(yù)熱和啟動過程。讓我姑且稱這里消耗的時間為“思維引導時間”（ Mind Bootstrap Time ， MBT ）。這一時間的長短，取決于你面對問題的復雜性（和昨晚的睡眠質(zhì)量？）。 比如， 某人的談話如果被打斷后，他可能會問“我剛才講到哪里了？”。要繼續(xù)之前的談話，他就需要重新思考交談的內(nèi)容并從被打斷處開始。這里花費的時間，就是 MBT 。 對一段談話來講， MBT 可能只需幾秒鐘。對軟件開發(fā)活動，則可能需要好幾分鐘。

 

現(xiàn)在已經(jīng)不再是一個文本編輯器解決所有問題的軟件開發(fā)時代了。比如對一個典型的 JEE 開發(fā)項目，我們應(yīng)該很容易理解一個程序員早上寫下第一行代碼前所做的以下操作：

 

1.打開 Eclipse IDE 。在 Eclipse 歡迎界面下的滾動條努力向前的時候，

 

2.啟動開發(fā)用數(shù)據(jù)庫服務(wù)（比如 HSQLDB ）。在數(shù)據(jù)庫服務(wù)啟動日志還在 DOS 窗口翻滾的時候， 他

 

3.打開數(shù)據(jù)庫 GUI 客戶端。接著，

 

4.啟動 tomcat 。

 

5.在 Eclipse中打開昨天工作中的Java源文件，開始編寫今天的第一行代碼。

 

 

我把這一過程所花費的時間，稱作“環(huán)境準備時間”，即Environment Preparation Time（EPT） 。 如果連續(xù)的開發(fā)時間被打斷，開發(fā)人員可能需要重復這一過程。 EPT 會因開發(fā)環(huán)境的不同而長短不同，但這部分時間總是存在的。

 

讓我把 MBT 和 EPT 稱作斷點時間。 斷點時間不是有效的工作時間，因為它們不能帶來直接的產(chǎn)出。 這里想強調(diào)的是， 有效工作時間是必需的消耗，而斷點時間總是可以通過減少時間碎片來減少或避免的。如果時間連續(xù)性已經(jīng)被打斷， 斷點時間還能被消除嗎？ 我認為答案是否定的。

 

碎片化的時間， 就像被田埂分割的土地。分割的越多，實際可種植面積就越少，不論田埂修的多狹窄。

 

*[MBT]: 思維引導時間，即 Mind Bootstrap Time。
*[EPT]: 環(huán)境準備時間，即Environment Preparation Time。
*[JEE]: Java Enterprise Edition 。 Java開發(fā)企業(yè)應(yīng)用軟件的一套規(guī)范、工具、以及框架。
*[IDE]: Integrated Development Environment，即集成開發(fā)環(huán)境。
*[Eclipse]: 一款流行的 Java 集成開發(fā)工具。
*[tomcat]: 一款流行的java web（servlet）服務(wù)器。
*[HSQLDB]: 一款Java開發(fā)的輕量的關(guān)系數(shù)據(jù)庫系統(tǒng)。

 

發(fā)生缺陷的可能性增大

 

打碎的玻璃杯子被重新粘合后可恢復完整并繼續(xù)使用。但粘合的痕跡讓它不再美觀。更重要的是，重新粘合可能引入缺陷：接縫處未對齊的話會產(chǎn)生縫隙；粘合材料和杯子本身材質(zhì)的不同會使整個杯子的應(yīng)力不均，從而使它比以前更容易炸裂。

 

通過重新進入狀態(tài)并找到上次離開時的工作點，開發(fā)人員可以接續(xù)之前被打斷的工作。但就象重新粘合的杯子一樣，這里不僅有直接的有效工作時間損失，更有可能引入后續(xù)問題。 “我剛才寫到哪一行了？”，重新回到代碼前的程序員可能會這樣問自己。通過回想，他找到了離開時正在完成的switch結(jié)構(gòu)并繼續(xù)編寫下一個case子句。不幸的是，前一個case子句遺漏了本該有的break。一個bug就這樣產(chǎn)生了。修復此bug的時間可能是撰寫這部分代碼的數(shù)倍。

 

這個引入bug的例子很容易應(yīng)用到其他開發(fā)工作上，比如需求分析、系統(tǒng)設(shè)計、測試等。簡單講，時間的碎片化使得開發(fā)過程中發(fā)生缺陷的可能性增大。人腦雖然比電腦復雜的多，但在斷點管理方面，可比后者差很多。

 

結(jié)束語

 

時間碎片化是開發(fā)工作直接的危害之一。雖然很多時間斷點無法避免，但管理方式的改進能減輕這方面的危害。減少對開發(fā)人員的干擾，提高他們工作時間的連續(xù)性，是高效管理的必要手段之一。理解了這一點，把團隊拉到偏遠的酒店或關(guān)到一個單獨的房間進行所謂的“封閉式”開發(fā)，就顯得不是那么必要了。