时间的碎片化是软件开发过程的危害之一。本文分析了时间碎片化的原因和结果，并试图给出修正此管理缺陷的方式方法。
为什么讨论时间的碎片化 ？
产生有效成果的智力活动，总是需要连续的时间来保证。许多忘我思考的典故都证明了这一点。 软件开发是一种智力活动，因此也遵循这一道理。 打断某人的工作，不论是智力工作还是体力工作，对工作的效率和产出总会产生负面影响。 只不过与体力劳动不同， 智力劳动受到这方面的负面影响要大得多。 对一名建筑工人，如果他连续工作的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的时间可能是撰写这部分代码的数倍。
这个引入bug的例子很容易应用到其他开发工作上，比如需求分析、系统设计、测试等。简单讲，时间的碎片化使得开发过程中发生缺陷的可能性增大。人脑虽然比电脑复杂的多，但在断点管理方面，可比后者差很多。
结束语
时间碎片化是开发工作直接的危害之一。虽然很多时间断点无法避免，但管理方式的改进能减轻这方面的危害。减少对开发人员的干扰，提高他们工作时间的连续性，是高效管理的必要手段之一。理解了这一点，把团队拉到偏远的酒店或关到一个单独的房间进行所谓的“封闭式”开发，就显得不是那么必要了。
