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

為什么討論時(shí)間的碎片化 ？


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


時(shí)間如何破碎 ？


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


一人多任務(wù)
過分強(qiáng)調(diào)面對(duì)面溝通
過多的全體會(huì)議


一人多任務(wù)


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


任務(wù)越早展開，越能盡早暴露問題，從而便于及時(shí)解決，降低管理上的風(fēng)險(xiǎn)。
開發(fā)任務(wù)緊，多任務(wù)安排可以增大開發(fā)人員的負(fù)荷，防止他們偷懶。
多個(gè)任務(wù)具有相同的優(yōu)先級(jí)，而且彼此之間沒有依賴關(guān)系，因而應(yīng)該同時(shí)展開。


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


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


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


過分強(qiáng)調(diào)面對(duì)面溝通


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


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


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


過多的全體會(huì)議


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


時(shí)間碎片化的后果


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


有效工作時(shí)間的減少


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


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


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


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


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


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


*[MBT]: 思維引導(dǎo)時(shí)間，即 Mind Bootstrap Time。 
*[EPT]: 環(huán)境準(zhǔn)備時(shí)間，即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ā)生缺陷的可能性增大


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


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


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


結(jié)束語


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