团队的成员们都已经有相当丰富的sprint retrospective经验，如何保持大家的激情，以及保证回顾会议的效率和效果都是我感觉很重要也并不容易的任务。大家开始有些厌倦于差不多的流程，即使我们想方设法地换用各种不同的retrospective方式，情况依然如此，而不断更换方式所带来的副作用还包括大家需要花费时间熟悉，也有可能导致大家干脆置之不理。其实换在不同的地点进行回顾会议是个不错的点子，但可以这一定程度上涉及到经费问题，所以。。
 
这次比较凑巧的是，sprint中，我曾经将sprint backlog和burndown chart打印出来，贴在工作区域的白板上，督促大家每天更新。而我们的一些会议记录也都被我打印出来，粘贴在一起，所以，可以说将这些文档资料收集起来后就成为了我们非常宝贵的一些回忆。回顾会议开始前，我将这些文档粘贴在会议室的墙上，大致按照时间顺序排列。由于有几个新同事加入，所以花了点时间重复那些essential statements，然后我希望大家能够快速地回顾过去的这个sprint，然后用一个词语或者短语来描述自己的感受，此时此刻的感受。对于这些感受的稍加发掘，有助于放松情绪，拉近彼此的距离，使氛围能够引导大家畅所欲言。而这些感受也可以用于之后与那些action进行一定的对比，如果大家更多的是不满意，却没有太多用于改善现状的action，那么说明其中一定有什么问题，导致前后大家给出的信息不一致。
 
感受阶段结束后，我准备进行timeline，在此时，我向大家展示粘贴在墙上的这些文档，分配出2~5分钟来浏览这些文档，增强他们对于 sprint大致过程的记忆。这其中，还会有助于大家发现一些可能不容易想到的问题，比如在某一周的weekly review上有提到的下周工作计划，但在随后一周的weekly review记录中却发现此工作计划没有按预期的完成，那么这就是一个潜在的问题，或者可以提高的方面。之后就是给出一些时间让成员们回首，并将自己的看法记录下来，写在便签纸上。此时我已经准备好三张大的flip chart纸张，张贴在墙上，用于大家粘贴便签纸。
 
之后的mining阶段，我开始阅读这些便签纸，然后将它们就地记录在这些flip chart上面，用记号笔，并给这些条目编号。当然，这三张flip chart分别为start doing、stop doing、continue doing，条目会被写到对应的纸上。接着就是要探讨可行的解决办法了，但在此时有一点点的小状况。整个会议的气氛都是比较轻松的，有点点随意，但是从大家半开玩笑的话语中，我发现一种趋势，大家有些许的死气沉沉，觉得有些境况难以改变，有些困难是必然，我觉得这样的心态对于我们找寻SMART的 action有负面效果。快速地思考后想出一个办法。我们开会在26楼，公司的健身房也在这一层，我认同劳逸结合的观点，于是决定放大家15分钟的假，和他们一块去健身房运动片刻。于是大家嘻嘻哈哈地过去，打乒乓球，打台球，跑跑步，抬抬杠铃，挺活泼的。差不多15分钟后，回到会议室时，大家显得比之前更具有活力，就开始接着下面的brainstorming过程，来产生action。
 
以前的做法通常是先一个人想，再两个人交流，再两两配合交流，然后一起总结。有些scrum master喜欢主导整个过程，而我则非常喜欢将控制权交由团队的成员。曾经的一次是，最后形成分别是4人和3人的小组时，结束讨论，让他们展示自己的成果，一个同事负责讲解他们的action和理由，另一个同事则协助将这个action记录在flip chart上，这既满足了大家理解的需求，也有一定的visible的特点，又强调了团队成员间的充分沟通（如果不充分，那么记录的同事可能根本就不知道他的同伴在讲什么）。这次也差不多，我讲控制权交给成员，希望他们有自愿者可以出来记录action，并启发大家思考，而此时我又使用了两张额外的 flip chart，标题都是ACTIONS，放置在之前的三张flip chart的中间，彼此非常靠近，是希望可以在对应的问题和最后的action之间形成一个关联。效果还不错，在大家略带调侃的方式中，action被讨论出来，当然还有其负责人。而在这样更轻松些的氛围中，虽然有开玩笑式的推诿，但其实大家都默认的接受了必须有人来负责action，相比以前我们有很多 action都因为似乎只能有外部人员可以负责而付诸流水，我们给每一个action都找到了主人，而且大家都承诺会完成！
 
至此，整个sprint retrospective结束，历时接近4个小时。

此文最初发表于博客。

---

作者介绍
徐毅目前在一家大型欧美电信企业工作，具有丰富的软件开发、软件测试及测试自动化经验，同时，具有丰富的Scrum开发模式经验，目前担任公司的Scrum Master。专注于如何使Scrum顺利地融入企业中，如何创建一个Scrum的生态系统，以及敏捷开发中的测试。

 

——2 days agile development project

Code Jam是ThoughtWorks特别的活动之一，在很短的时间内为客户交付可用的软件（或原型），团队经过短期高强度的锻炼，可以对开发过程和开发技巧都做一些反思。这次的Code Jam是为乡村教育基金会做一个网站，属于一次公益性质的活动。我们几个人从周五开始就忙碌了起来。

首先，作为BA，先期了解一些需求是必要的。在开发之前，必须要知道Scope和优先级。周五下午我和QQ俩人就和我们的Client，来自（伦敦、香港、墨尔本）的Steven，一起进行了简短的需求分析。由于项目不大，而且总共只有2天时间，我们重点关注于需求的优先级。在搞清楚流程的基础上，把优先级分了7级。听起来好像很多的样子，实际上，从需求完整性考虑的话，前1－3级的需求比较多，后面的都是很小的功能模块。我们保证每一级开发出来都必须是可用的软件。Steven非常聪明，对我们的方式适应极快，很快把握到排序的要点，到后面亲自操刀开始写Story，终于达到了”客户编写用户故事“的极境，令俺窃喜不已。

终于，4个多小时之后，全新的story list出炉了，1-3级story有卡，1-2级的卡背面写有A/C。总结下来，这次需求分析做的比较好的地方有：
   1. 要在很短时间内需要搞清楚足够开发的需求，因此我们确定了项目远期目标、用户交互流程、特性的优先级，取消了评估开发时间一项。在下午需求会议开始前，我们制定了：1 项目目标 2 功能范围 3 优先级 4 界面交互原型 5 用户故事 6 细节验收条件等会议步骤，在4个小时内准备好了可以开发的需求。
   2. BA、QA和客户坐在一起交流需求。这是非常理想的情况，很多项目由于种种条件限制使得BA/QA没法从一开始在一起。
   3. 需求和界面原型全部采用纸质管理，没有除了照片以外的任何电子存档。不管是开发人员还是BA/QA，都手持卡片和人交流，有任何问题和发现都记录在卡片后面，这节约了很多时间。（当然，由于QQ太过谨慎，怕卡片被打扫卫生的阿姨清走，特地锁在了她的宝箱里，结果晚上胃病第二天没法来……由此可见，项目风险总是不可能全部预测的）
   4. 在Story的上面标注了依赖关系。以往做Story经常忽视这点。这次特别标记出来，在开发过程中作为Dev开发的参考。
   5. 优先级的制定。没有采用传统的MoSCoW法，而是就用1-9的数字来表示。我们最终将1-3的大多数需求交付，客户很满意。
   6. Hight Level 系统结构图。通过整理此图，我们全面的了解了系统的蓝图，客户也在过程中重新反思了不少的特性。这图不完全是流程，其实更像是Information Architecture+Domain Model，结合了功能+界面两种不同的元素

做的不够好的地方也有：
   1. 由于对Rails开发的效率无法预估，我错误的假设了两种不同类型的文档在提交时候有很大部分功能可以复用，因此在写第二类的时候，简化了一些Story，最后证明这些还是得写上。此处犯了INVEST中I的错误
   2. 有些Story的A/C描述的不够。凡是有可能出错的地方都一定出错定律。。。例如，search结果的list中，通常都有link可以view detail，因此就没写在A/C，果然被遗漏了

周六开始进入正式的开发阶段。由于时间短，我在周六早上主持了很短的kick-off，大致说明了项目情况，读了一遍优先级1的需求，就开始开发了。团队都是非常优秀的人，很容易就形成了自组织的团队。一开始所有的人都开始找BA问问题，有些手忙脚乱。好在过了启动这段后就好多了。

我和其他两位过来帮忙的BA一起，安装了只有ready, in dev, dev done, qa done四个状态的story wall在墙上。公司的推拉白板柜门很好用，需要用哪张墙就推过来，不用的就推走。一共占用了4张白板。Story Wall，流程Wall，界面流程Wall和Wiki Wall各一个。

因为大家采用Textmate，而并不是所有人都用过它，因此一开始team是用过的和没用过的pair，先熟悉工具。中午时候大家switch。

在开发阶段，我们整个团队做的比较好的地方有：
   1. 自组织的团队。真正实现了自组织。每个人都尽力将事情向好的方向推进。大家都尽职尽责的完成任务。
   2. 在开发优先级1需求的时候准备优先级3的A/C和优先级4-8的卡片，使我们不用在一开始就准备所有的功能。
   3. 采用活动墙壁做需求墙，team需要看什么就把那个移动过来近些。
   4. 开发团队频繁的轮换pair，可以收到很好的效果。从BA的角度可以很明显的感觉到哪个pair遇到了问题，从而协调team之间的取长补短。
   5. 和客户交流频繁，所有一开始由于时间关系无法确认的需求都交由现场客户Steven解答。中间根据进度，我们建议更改2和3级别优先级的顺序，客户也确认了这次更改的必要性，使得我们最终能够交付正确的产品。
   6. 一天两次的简短的standup。由于大家平时交流的充分，standup可退化成宣布值得大家知道、比较重要的事项的碰头会，如果没有事情说就不用说话。
   7. 简短的retrospective。自组织的团队不需要太多的反省。每一个人都是很好很有能力很有想法的成员，只要列出来我们发现的问题，大家会自觉的去解决。
   8. 从一开始就运行的test和build。很大程度上提高了团队的整合度。
   9. 8dev团队，一天95次的提交次数，一天18个migrate脚本，一天12张story卡的速度。

做的还不够好的地方或者改进的想法还有：
   1. 在开发之初的设立UI pair，在开发后期设立专门BUG pair的作用不可忽视
   2. 每天的switch pair还是做的不够多。我认为对于rails开发来说，理想情况2个小时就应该进行switch。更频繁的Switch能够使得知识传播的更快，尤其是在团队中不是所有人都对Rails开发熟悉的情况下。由于做的还不够好，出现了有的pair工作在一张卡上太多时间的情况，原因是俩人对这块都不够熟悉，如果早点switch就好了。
   3. 由于Rails开发中一些scaffold的存在，几个相关的CRUD的story可能一下子就全好了。这对写Story提出了更多的要求。要精确掌握粒度不太容易
   4. Rails和Textmate的中文支持还有待提高。看哪位神仙有空，给contribute一些plugin啦、月光宝盒什么的。

总之，如何更好的交流和协作是我们这次Code Jam学到的知识之一。Rails开发的效率极高，这对开发过程和开发团队就有了更多交流协作的要求。大家必须要通力协作：多提交和更新才能最快的把代码整合在一起；多交流才能保证不会有架构和数据迁移的冲突；多和BA/QA交流才能不走错路做错功能；多更换pair才能学到更多的技能技巧，保障对系统的了解程度；多和用户交流才能确保需求不会迷失方向。

周六晚上5点半showcase的时候，1优先级的功能差不多都出来了，可以大致预测到第二天的成果。可惜由于周日我下午又赶飞机，没能看到最后交付的场面，非常遗憾。

---

作者介绍
李默，ThoughtWorks公司咨询师、业务分析师，敏捷过程教练，BJUG(www.bjug.org)创始人之一。网名为“冰云”。目前主要专注于软件需求管理与市场营销的协作、产品交互设计、组织过程改进等方面的内容。

今天Craig Larman给大家讲了堂“User Story Splitting”主题的课，从什么是user story，与use case的区别，user story通常的描述形式，分割user story的常用方法等，直到使用公司内真实的案例来模拟splitting的过程。有收获，有证实，也有思维的触动。

其中有举到一个例子，比如用户需要DHCP的服务，那么可以分为fake的stub的DHCP功能，然后还有real internal的，还有real external的等等。但是，真正地管理这些child user story的时候，需要额外的小心，因为它们之间其实是有依赖关系的。不可能先去实现real internal的部分，然后再实现fake、stub的，一是浪费资源，二是可能也无法一次完成real internal，可能正是因为这样才会拆分成两个child user story。也不可能两个或多个团队同时分别实现某个child user story，彼此之间的依赖关系会给产品开发的管理工作带来麻烦。

另一个问题，这次workshop关于如何split user story讲得确实非常清楚，但是其并没有也不会覆盖到做出split选择的部分，也即，我们是否需要split，为什么需要，应该在split过程中使用怎样的策略和方法。split是否有价值，这是必须要思考的问题，我们不能为了split而去split。其中有一个例子，讲述用户需要upload以及download的功能，而download又可以划分为download as file或者as xxx structure方式，这可以作为两个child user story。但是，是否真的需要这样的划分，这样的划分是否真的有其现实意义呢？虽然从用户角度，下载到文件或是某种数据结构，确实是两个不同的 child user story，但是从开发的角度看，或许开发的最大开销在于download过程中客户端和服务器段的沟通，或者是设计download算法的部分，而以文件方式或数据结构方式保存反而是非常琐碎简单的任务。那么这样的情况下，你应该如何估计这两个user story的大小呢？如果说download本身是5个故事点，而保存的方式各为1个故事点，你会赋予文件方式6个故事点而数据结构6个，或者是文件1数据结构6，或者是各3.5个故事点，或是其他任何的方式？不论用何种方式，它都给实际的开发工作带来一些依赖关系的管理上的开销。那么，此时，也许反省我们分割user story的方法，或是分割user story的出发点会带来一些启发。

其中产生的另外一个重要思考是，在我们分析用户需求、分割user story的过程中，是否会出现信息失真，太过专注于产品的某些特性，而忽视甚至是根本就不知道用户的需求？比如说user story的描述是“作为<用户方某个角色>，我想要<某个功能，或工具、软件>，因为<原因或收益预期>”，然后我们可以通过介绍的那些方法将其分割成为若干个child user story，然后在实现各个child user story的过程中，我们会侧重于验证其功能，比如说这个功能需要能够创建某些资源、修改、删除等等，但是，在什么时候什么地方我们验证了这个功能是否能够满足用户要此功能的原因或收益预期的出发点呢？

    * 举例来说，用户需要一个工具能够舒服地，随时随地的可以供他记录下自己的思想片段。
    * 在公司的需求分析阶段，认为，一支“笔”应该是能够用来满足客户需求的。通过围绕笔的user story分析，并分割为若干的child user story，可能会在开发过程中，分别开发其书写、擦除、携带等各方面的功能。
    * 而团队在接手任务时，有可能已经丢失掉child user story最重要的成因，团队从自身出发决心要做出最好的“笔”，于是从设计和实现、验证等角度努力提高笔的质量等各方面品质。
    * 最后，我们得到了一支，重200克，使用高质量的墨水，外观精致，用钢琴烤漆制作的笔。

但是，符合用户的需求么？也许用户无非就是需要一支手的握感舒适、轻巧易携带、带有橡皮的铅笔而已。

要管理这些容易被遗漏的需求，以及child user story夹缝中的功能碎片，需要产品负责人或者项目的管理人员来协助做到。我们在现实中遇到的问题就包括，比如将数据包转发的功能按照数据类型分为CS （电路交换）和PS（数据交换）两种，但是偏偏就漏掉了CS和PS混合在一起的测试用例，以及在一种流量尚有部分资源剩余的情况下产生另一种流量的测试用例，导致我们在后期收到上层应用层测试的错误报告。团队对此一般是无能为力的，如果拿到手的product backlog item无需团队进行更多分析的话，情况会更加严重，就会完全仰仗分割user story到product backlog item的人的能力和细致程度，这恐怕是成熟的软件开发所无法接受的吧。

---

作者介绍
徐毅目前在一家大型欧美电信企业工作，具有丰富的软件开发、软件测试及测试自动化经验，同时，具有丰富的Scrum开发模式经验，目前担任公司的Scrum Master。专注于如何使Scrum顺利地融入企业中，如何创建一个Scrum的生态系统，以及敏捷开发中的测试。

很多人都觉得界面的事情是细枝末节，等功能做好了，找个时间一起清理一下就好，不会占用太多工夫。很多人也都是这样做的。

这里说的界面开发是指系统的交互设计和界面可用性及易用性设计，也包括CSS的界面布局、颜色、字体等基本的视觉元素。这些问题的重要性不用多谈。

我在项目中期加入过几个项目，这时候最令人头疼也最令人兴奋的莫过于在开发中期对于界面和UI进行变更了。一个项目在初期如果没有做良好的界面设计，想要在中间来进行大的变更简直是噩梦一般。在一个敏捷团队中，做这样的事情尤其困难。

敏捷开发中的一个实践，是需要客户的协作和参与，及时由客户认可做完的需求以及由客户决定下一步的开发。这种客户享有决定权能够使开发变得更顺畅，客户关系变得更融洽，是一个很好的实践。

但是，这种实践给界面的改进带来很大的麻烦：如果在项目中期打算进行界面的变更，自然要写出很多跟界面相关的需求，而客户按照需求的价值决定优先级，他们有时候不理解这样的界面改进如何带来价值，为什么改善一些文字描述和交互方法还要占用开发时间，他们更希望在有限的时间内增加更多的功能和修复更多的BUG。这时候，这些界面调整的优先级就被排的很低，在几个开发周期内都没有得到采纳。

我们先后尝试了几种方法来改进这个过程，例如给客户培训交互设计和可用性知识；将开发人员分为两组，其中一组专职负责界面改进；或者将界面改进需求单独分成一组，要求客户每个迭代从其中选择一部分等等。但这些办法都不是很理想，没有达到预期效果。

事后总结原因，觉得最大的原因还是在于：客户不是用户。他们虽然负责对项目功能验收，但他们并不最终使用系统。系统使用上的问题不是他们最关心的。他们需要得到投资回报，因此选择了回报更快的功能开发。从这方面看，客户的选择是无可厚非的。

理想的解决方案应当是在一开始就对界面及UI进行控制和把握，并进行持续的度量和改进，或者称为：界面重构。将界面重构和代码重构等同到同样地位，在开发过程中持续随时的进行改进。

我们都知道，代码重构是在不改变代码行为的基础上，改变其内部的结构。通过一系列小的步骤进行重新构造，系统不会因为这些小步骤的改变而停止运转，仍然会保持顺利正常的运行。重构的结果是一套良好可读的代码，它不仅能够对我们扩展功能有帮助，也是我们适应变化的基本手段之一。

我们将其类比到界面的开发过程中：我们需要在不改变界面功能的情况下，通过一系列细小的步骤，来改变界面的交互行为和可用性。最终结果，不仅仅是一套良好的界面，也是保证我们扩展新的功能和适应变化的基础。

重构的一个要点是测试。测试可以保证重构的正确。而界面开发的过程中，测试工具的缺乏导致我们不得不采用其他的方式来保证功能的正确。一种可行的办法是维护一个界面原型，纸质或电子形式均可。在不停地开发过程中，不断的维护这个原型，使之先于实际实现被用户感知和体验，提前获得用户的反馈和客户的认可，并将原型用于指导团队的开发。这种不断的用户体验和用户测试过程，可以在一定程度上保证界面重构的正确性。BA阐述需求或QA进行验收测试的时候，也不妨考虑使用界面原型作为一个验收条件来展现给开发者。

重构的另一个要点是要经常不断的进行，每当写新代码之前，先进行一点重构，使旧的代码更好阅读。界面重构也应该是这样。对每一个开发完成的需求，提高界面验收的标准。不仅仅是完成功能就可以，还需要达到一定程度的可用性和可维护性要求。例如必须遵循提前制定的UI Guideline等等。避免因为界面开发的涣散导致的破窗户，这种疏于整理的小细节可能最终成为最头疼的问题。

比如，我们在开发的过程中，以前只以60分作为界面的验收标准，等积累一段时间后再批量修改界面一次，但可能这次修改只能达到80分。现在我们需要改为以80作为验收标准后，在开发的过程中多花点时间来重构一点点，一直保持80的水平。这样如果我们需要进行更大的改进，可能很容易就能改到90或 100分，从而达到我们最终的目标。

由于开发团队的人员多数不太擅长界面的知识，并且界面的测试和度量工具缺乏所致，界面的持续改进在项目中较难做的很好。这些实践又要求BA或QA能够有相应的交互设计能力和可用性工程的经验，也限制了其在项目中的实践。但这些确是在一个项目中长期被忽视地方，应当进行一些加强和发展。

总而言之，敏捷过程和界面设计并不是矛盾的，将敏捷的思想应用于界面开发和交互设计的过程中，我们可以获得更多更广泛的想法。

4月23日，和Erik谈了谈这个想法，他也认同这类做法，但觉得由于目前没有一个显然的Vision，或者说，不像Code Refactoring那样有良好的OO设计准则和可读性在前方可以到达，这样的UI重构的准则不是很明显。原因可能还是由于Developer大多缺乏这方面的Sense。路还很长。

---

作者介绍
李默，ThoughtWorks公司咨询师、业务分析师，敏捷过程教练，BJUG(www.bjug.org)创始人之一。网名为“冰云”。目前主要专注于软件需求管理与市场营销的协作、产品交互设计、组织过程改进等方面的内容。

    异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。
    异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。
    但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位置分为三类：on-shore（在岸，指在同一个国家或同一个时区内），near-Shore（近岸，在接近的国家和地区中）和off-Shore（离岸，通常在时差8小时以上）。如下表：

offsite	on shore	near shore	off shore
Distributed Development	北京办公室 - 西安办公室之间	印度分公司 - 中国分公司	硅谷总公司 - 中国或印度分公司
Outsourcing Development	北京某公司 – 广州另一公司	东京某公司 - 大连另一公司	欧洲某公司 - 中国另一公司

异地分布式开发的组织方式

    异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公司设定项目总负责人角色，负责两地的沟通与协调。

    有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。


    各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。

基本原则：极尽交流之能事

    异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。
    为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。


    每天的定时会议将成为很重要的一个很重要的交流方式。如果团队的人数较少，大家可以按照站立会议的方式在电话会议系统中说明自己的情况和遇到的问题。如果人数较多，一种可替代的方式是每个团队自己进行每日例会，并由个项目的项目经理和需求分析人员进行另外的会议以便协调工作。
    如果两个团队时差较大，例如中国北京时间和美国东部时间时差12-3小时，想要进行直接的电话会议交流很困难。如果遇到3个处于不同时区的团队，更是经常不可能找到一个合适的时间来进行任何的会议。在国际化的公司中，起早贪黑的进行几地的电话会议很常见，但这却不适用于整个开发团队。对这种情况，每日的开发状态邮件是很有用的。每日开发结束后由项目经理或成员来根据团队的情况来撰写一天的总结，并发送给远端的团队。
    交流的障碍经常发生在陌生人之中，如果两地的开发人员互不熟悉，可以考虑将双方人员的照片贴在墙上，以增加熟悉感。可行的话，进行可视会议和当面的会谈。尽量减少陌生感，使交流效果提升。
    任何交流方式都比不上面对面的交流。异地开发时，off-site一端很容易丢失on-site一端与客户交流的语义上下文和环境。如果情况允许，公司应该设立常规的出差和轮换制度。让一部分的团队成员到另一端，见一见一起工作的同事，了解一下客户的需求和感受一下不同的环境。

敏捷开发过程的改进

    一般的敏捷过程中，都会有一个初始阶段，在这个阶段了解开发需求和制定发布计划。要进行这样的活动，最理想的办法是让所有人都出差到on-site一端，一起了解需求和建立共识。这将会对后面的开发有很大帮助。如果由于人数或成本不可行，至少要派遣所有的需求分析师和项目经理、协调人以及部分测试人员到场参与。对于迭代一级的计划，应该由两地的项目经理和需求分析师提前进行计划会议并做出决定。
    日常的项目管理工作中，采用卡片墙的方式只适用in-house的开发。在异地开发中，为了使得每个团队都可以了解到团队任务，至少需要在两边开发室都设立卡片墙，并保持同步。可以采用在线工具帮助进行项目跟踪，例如Mingle或Trac，都是适用的在线工具，同时也是在线Wiki或共享知识库。
    项目协调人，应当制定完善的交流计划和交流机制。例如前文提到的每日的例会和每日开发状态邮件，每周的需求交流计划，问题的提出和反应机制等等。这些应当制定成为团队守则来遵循，并随着实际情况的变化修订。交流不怕多，只怕不充分。
    一个共享的代码版本控制系统是必须的。例如在公司内网建立一个SVN并通过VPN来使用。On-site和off-site团队可建立自己单独的持续集成环境，但需要保持系统环境的一致。两方的开发人员都应该保证每日离开办公室前的提交通过集成。这样可以避免异地团队开始开发不至于被失败的集成所耽搁。
    基本的敏捷时间必不可缺，例如测试，尤其是功能测试。On-site的QA应当在需求确定的时候制定好验收条件。一个描写良好的验收条件会对开发人员有所帮助。尤其是在On-site一端不能及时解答问题的时候，会起到很大的作用。
    每个迭代结束时，应尽量安排一个两地同步的演示会议。让所有人都在电话会议上看到这个迭代的成果。迭代后的总结与回顾也应当两地一起进行，如果人数和条件不允许，可以分别进行，并互相通报回顾结果和改进方法。

离岸团队的参与度

    多团队中，处于on-site的成员由于可以接触到客户，他们的话语权可能会被放大，使得on-site一边的人倾向于命令式的消息传递，直接指派需求和开发进度，而忽视了对需求背景情况和上下文进行介绍。这种情况可能造成off-site一端团队产生抵触心里，从而导致项目的失败。
    解决方法是提高off-site团队的参与度。如制度性的进行人员轮换，让两端的团队成员有所接触，并互相熟识。定期组织两个团队的共同活动。如果都处于一个时区，可以考虑进行每周的Learning Lunch，大家在互相能看到视频的情况下一起吃饭和听讲座。讲座内容可以是任何话题，例如一些项目相关的技术决策等等。
    不要忽视off-site团队的任何意见和建议，他们在很多时候能从另一个侧面对项目提出见解。鼓励off-site团队决策和发起讨论，这样可以提高他们的参与度。
    实施异地开发的最初目的是为了降低人力成本和运营成本，一些跨时区的异地开发还可以提高时间利用效率，实现全球24小时开发。然而，异地开发带来了高昂的交流和管理成本，如果处理不当将直接导致项目或产品的失败。
    近年来随着国内软件公司业务的发展，异地开发项目将会越来越多。全球化的进程也会使得外国公司开展更多类似的开发。异地开发项目将会逐渐发展和普遍。可以想像，多年以后，如果一个公司没有异地开发的团队，将会是多么的令人诧异。

---

作者介绍
李默，ThoughtWorks公司咨询师、业务分析师，敏捷过程教练，BJUG(www.bjug.org)创始人之一。网名为“冰云”。目前主要专注于软件需求管理与市场营销的协作、产品交互设计、组织过程改进等方面的内容。