時間的碎片化是軟件開發過程的危害之一。本文分析了時間碎片化的原因和結果，并試圖給出修正此管理缺陷的方式方法。

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


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


時間如何破碎 ？


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


一人多任務
過分強調面對面溝通
過多的全體會議


一人多任務


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


任務越早展開，越能盡早暴露問題，從而便于及時解決，降低管理上的風險。
開發任務緊，多任務安排可以增大開發人員的負荷，防止他們偷懶。
多個任務具有相同的優先級，而且彼此之間沒有依賴關系，因而應該同時展開。


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


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


一人多任務的安排的問題在于，人不是多核系統。 他只能采用交替工作的方式來“同時”展開多項任務。當他在不同任務間切換時，特定任務上的工作時間就不再連續了。就像單核CPU執行多任務一樣，這是讓開發人員的大腦應用 TDM 技術。不幸，人腦不是高效的 TDM 設備。
無論如何，一人多任務的安排都應該努力避免。 如果僅僅因為優先級相同，那這些任務可以隨機地順序安排。
*[TDM]: Time-division multiplexing，即時分多路復用。


過分強調面對面溝通


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


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


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


過多的全體會議


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


時間碎片化的后果


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


有效工作時間的減少


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


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


打開 Eclipse IDE 。在 Eclipse 歡迎界面下的滾動條努力向前的時候，
啟動開發用數據庫服務（比如 HSQLDB ）。在數據庫服務啟動日志還在 DOS 窗口翻滾的時候， 他
打開數據庫 GUI 客戶端。接著，
啟動 tomcat 。
在 Eclipse中打開昨天工作中的Java源文件，開始編寫今天的第一行代碼。


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


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


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


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


發生缺陷的可能性增大


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


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


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


結束語


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