从今年年初开始与Steven Zhang, Mike Li, Jackson Zhang一起翻译Roy Osherove的”The Art of Unit Test”一书。尽管是一个很小规模的项目，其实也是一个不断优化、不断提升的过程。

Jackson和我其实已经参与过清华大学出版社的《用户故事与敏捷开发》一书的翻译工作，而且我们曾经成功将一些敏捷工具和方法应用于那个项目中，取得了很好的效果，出版社的反馈特别好。具体可以参见我们去年在Scrum Gathering上海和QCon北京的分享。

 

 

在进行新的翻译项目时，我们又做一些新的尝试。

 

首先是项目管理工具

我自己其实一直是简单工具的支持者，只要有可能，我倾向于尽量使用简单的工具。在开始时期团队成员建议尝试一下在线的项目管理工具，因为有几个评论看下来还是相当不错。首先是PivotTracker，简单尝试下来首先是生成燃尽图比较痛苦，必须要添加Task，而且每个人的任务不够直观；因此团队很快又转而尝试Gravity，Gravity提供了一个支持拖拉拽的任务墙，从任务墙可以很方便地看到正在进行的任务以及已经完成的任务。但是这又给我们带来了新的问题，首先由于对每个章节我们都需要根据完成标准(Definition of Done)来确定任务，因此对每个章节和小节都需要添加很多的任务，这对我们来说是一个很大的工作量，如果能够方便地添加任务或者干脆把任务墙的列作为阶段就更加直观了。但是这就涉及到任何电子工具所共有的问题，很难去根据项目的不同去定制。最终，转来转去还是回到了Excel。

 

使用Excel管理翻译项目

燃尽图，显示我们目前翻译的进度情况

任务认领，每个人的任务完成以及认领情况

Excel的更新

日常会遇到几种更新Excel的情况：

• 认领任务 － 会到Excel的任务认领Sheet中认领下一个章节，做法是把自己的名字签上
• 提交审核 － 在任务认领Sheet中的”Ready for Review”栏填上Yes
• 审核 －审核完成后，在第一或者第二审核人那一列填上自己的名字
• 最终修订 － 由翻译人根据审核的结果去确认，完成后也是在相应栏填上自己的名字

一些简单原则

• 首要目标是完成更多地章节，而不是更多的工作。因此如果有章节可以审核，应该先去审核，而不是去翻译新的章节。
• 我是第一审核，第二审核人由Steven, Mike和Jackson中任意不是翻译者的人员担当。
• 翻译者负责最终修订。
• 小步快走策略，把任务粒度甚至划分到很小的章节。（更有成就感）

信息同步

• 每周例会，同样也是回答三个问题，然后有时候也会讨论我们的流程有哪些地方可以改进。
• 邮件，每次提交翻译，都会有持续集成给所有人发邮件，我们向所有人传递一些消息，比如“8.4.6/7/8/9/10/11 are ready for 1st review”。同时这也是一个相互压力。

我们的出版社对我们的信息透明感到特别满意，她的反馈是：

“因为一直都能收到各位的进展报告，深感欣慰。同时也很汗颜， 正是这种透明化的响应机制，让我把时间花在优先级更高的其他书上了。 现在，这个星期开始，就完全属于我们这本书的了。”

存储

为了建立持续集成，我们必须建立自己的文件服务器，同时也必须有版本控制。我们选择了CodaSet。可以方便地用Git与CodaSet。在加上基于TeamCity的持续集成，每个人随时都可以拿到最新版本的翻译文档。

 

脚本和工具

与上次翻译用户故事那本书不同，这一次使用了不少辅助脚本和工具。

• Git。利用Git可以方便地在本地签入完成的工作，而且自带Diff工具
• MarkDown。针对大小标题、代码、解释说明、小贴士、表格等各种不同的文本，使用标记进行区分，这就为以后的格式化打下了良好的基础，可以很方便地输出Html等。纯文本文件，比Word更容易Diff。
• 代码和图片与文本隔离。首先，把这几者分离有利于分别进行格式化；其次，代码隔离出来之后，更容易保证正确性，因为可以独立编译，而且以后哪怕有语言版本升级，也很方便。
• 脚本，一些方便的Ruby以及Bat，可以在无论是Mac还是Windows上，方便地把我们的文件转化为出版社编辑可以读的doc或者rtf文件。而且有了这些脚本，我们甚至有了每次提交工作，都可以发布新版本的能力。
• Pandoc，我们使用这个工具来把Markdown转成RTF