背景：与美国某公司的一个离岸外包中的一个页面，最后交付物为，20来多存储过程，4000行左右的C#代码量，2000行左右的JS代码量，数个文件，7个jQuery plugins，参与人员及职责：
- BA一名（美国方），负责把握进度、控制风险、阐述需求、解答需求问题。
- Application Developer（美国方技术接口人），负责建议/帮忙解决开发中出现的技术疑问，负责C#及SQL Code review，审核代码质量、安全性和性能，负责性能测试。
- jQuery前端开发人员（美国方），是临时从另一个项目中调派过来的，负责所有前台的代码，包括jQuery及插件的使用和选择，与BA沟通确定方法接口，负责解决客户端有关的性能问题和BUG修复。初期稳定后，会撤离项目组。
- C#和数据库（我），负责所有的C#、WCF和数据库相关开发，BUG修复，稳定后的维护工作。
难点：
- 离岸协作，16小时时差，即美国上班时中国在睡觉，所以基本都是美国方在加班与我进行协作，通常都是他们晚上9~11点，我这儿中午12~1点。
- 代码交付问题，尤其是前后端的衔接非常紧密，所以若有一方因为代码交付问题，另一方则会完全被stuck住，风险较难控制。
- 由于使用典型的敏捷迭代，所以时间的要求上其实很急，规定上线时间根本没得商量，如果不能完成只能等下一次迭代。
- 各种新技术：采用全新jQuery dataTables展现grid，后期使用线上数据库才发现性能完全不行。性能测试不足，出现之前没有预料的问题。
- 沟通，我这边的老大曾经建议过直接onsite开发，不过美国方没有同意，这个页面因为需要无间的配合，所以对沟通的要求其实很高，我们后期是采用的每日~每两日一次会（会经常持续达半~1个半小时，有几次甚至达到了2小时，包括我和前端讲述头天已完成项，整理BUG完成情况，讲解新发现的BUG，指派新BUG的负责人，列出明日交付计划等等），每天必须使用邮件来更新开发进度并列出明天的计划和交付。倘若交付出问题（也确实出过），整体交付的日期会延迟。
- 整个过程使用英语沟通。
- 其它。
我们的协作方式：
- 由BA确定需求时，对方技术负责人告知前端与我的技术需求、扩展和重构，
我之前从来没用过WCF，我需要在这期间做出WCF POC，更新我的auto-complete控件使之支持WCF，
前端需要了解dataTables等相关技术。
（耗时一周左右） - 初步需求文档，列出主要web methods，当时一共只有15个，在这段过程中web methods的命名和需求往返超过不下于8次
前端给出后台需返回的JSON结构及request参数等。 - 任务分解。
- 前端进行页面代码的初步编写和插件研究；我同步进行数据库设计，后台代码框架等，并做出几个初步的web methods，准确代码合并。
- 第一次代码合并是比较痛苦的，因为前端会改我的后台代码，他本身也懂C#，这样我们经常会有代码冲突，于是此时美国的技术接口人提出了协作原则，洋洋洒洒一大篇，即双方不允许互相修改对方代码。我补充说，希望每天有一次进度汇报，包括change log、明日计划、needs等。
- 第一次合并后，发现问题很多，比如我写的web method对方不能使用或出错，第二次我就开始做unit testing，每个方法都使用Nunit进行过单元测试，这样大大提高了我每日后台代码的交付质量。
- 在开发阶段，每天会有一次这样的报告，发现BUG会及时汇报，每日back and forth不下于5次，好在美国方总在晚上8~11点能联系到（即中国时间早10点~中午1点），所以这期间能clarify很多疑点，总之每天计划都能完成，第二天另一方会收到相应的代码更新。
- 开发近一周半后，第一个版本发布到DEV服务器上，初步测试开始，BA生成简单的excel文档记录BUG清单，excel包含2个sheet，一个列出bug，一个列出尚未实现或打算实现的功能。每天会有一次电话会议，来确定这些BUG的负责人，并写上计划完成日期，每日有更新。每日会有一次构建，都会在DEV服务器上发布新版本以供BA测试和检验BUG修复情况。新BUG仍然会有层出。这个BUG清单最后有80来条，各种大大小小包括performance和页面布局问题等。
- 第二次成熟版本发布后，对方使用线上数据库（dune版）来做性能测试。性能测试的结果，比如：loading会有timeout的错误，正式发布前都有处理。
- 全部的回归测试。
- 发布上线。从协作开发到第一版本上线一共耗时一个月整。
关键词：
- 任务：任务分解、初期需求不必完美、过程控制、任务负责人清楚明确
- 沟通：每日进度汇报及计划、快速跟进修复BUG、积极响应、频繁会议、清晰沟通、无情绪沟通
- 测试：单元测试、性能测试、集成测试
- 交付：严格遵循不修改对方代码、bug tracking、遵行每日计划交付目标、后期每日构建、允许迭代
遇到的技术难点：
- 上线后，当即发现另一个性能问题，因为使用jQuery datatables我们当时并没有做服务器分页，所有filter和pagination全部客户端，即提交查询请求后，从数据库返回全部数据（比如5000行），形成庞大的json串会导致出现script无法响应强制终止脚本的提示。BA当即只能决定将先只返回800条查询数据，在第二次迭代中再想办法提升。
- 另一个性能问题就是左侧层级列表，数据量不少，页面载入后，分别有左侧4个及右侧3个widgets的数据需要异步载入，第一次访问页面的速度很慢。使用cache也不能很好解决这个问题，只能将左侧jstree做成服务器端异步提交显示。
- end-users的反馈很强烈，很多人使用得不习惯，很多抱怨和反馈纷至踏来。
- 很多东西都必须改，第二次迭代开发开始。
我们开始第二次迭代：
- 所有存储过程都需要分页，问题比较麻烦，因为存储过程和C#方法有27个之多，如果每个存储过程都必须加上7个参数（startFrom, limit, sortBy, totalCount, Archived totalCount, etc)，每个接口也必须如何加上7个参数，所有方法都需要动。后来使用一个struct、一个统一方法、一个存储过程来解决这个问题，以利于扩展。
- 左侧jstree需要改动。
- 更多performance tunning。
我们开始第三次迭代：
- 由于客户端已基本稳定，前端退出开发团队，我继续进行维护工作，并需要了解所有使用到的前端技术和jQuery插件等。客户反应渐好。
总结：
- 深刻感受到西方的敏捷开发模式和沟通方式，很受启发，很喜欢。
- 交付质量和承诺至关重要，否则一天的耽搁，可能会引起两到三天的延时，严重者会使进度失控。
- 一个小遗憾：我做出的WCF其实并没有体现WCF data contract的优势，仍然返回JSON串，可是时间太紧，一直没有去解决这个问题。也是后期想要解决的。