/ Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(一)

UserStoriesApplied

数年前Mike Cohn写了这本User Stories Applied: For Agile Software Development,而我从2007年才真正开始接触敏捷,没想到2009年我有机会能够参与翻译这本有关用户故事的经典著作,我感到十分的荣幸。

这次翻译我们一共四个人参与,我和石永超(Stone)主要负责翻译,滕振宇(Daniel)和李国彪(Bill)主要负责审核,大家都是兼职来做这次翻译的。多人翻译首先考虑的是两个问题:要有个Central repository,大家可以能在上面更新或拿到最新的版本;还要有公共的标记,谁要翻译哪一章就做一个标记,避免翻译重复。既然需要一个公共的Repository,上面放的都是Word文档,我们马上就想到了Google Doc。接下来是标记问题,就在Google Doc上加了个Spreadsheet,给每一个section做一个状态标记。

GoogleDocsForTranslation

环境准备好了,可以开始翻译了。可是翻译了一段时间以后,发现Google Doc不是那么好用:

  1. 没有History,不能查过往记录;
  2. 冲突(Conflict),没有Merge功能,互相修改有可能出现互相覆盖的问题;
  3. Word格式与Google Doc并不是非常兼容;
  4. 不能用Word的Tracking and Reviewing功能。
然后我们决定换用我们自己熟悉的版本控制工具:Subversion。同时我们约定,每一章由一个人(我或Stone)翻译完成后,必须有两个Reviewer(Daniel & Bill)来审核,最后翻译的人需要再根据审核的评论进行修改。

终于,一个月过后,还算顺利的翻完了1章。准备交付给出版社第一章,让专业的看看翻译的如何。得到的反馈还是不错的,貌似我们可以继续这样翻译下去了。可是我们回过头来想想,其实这个翻译过程是有问题的:

  1. 速率太低,一个月才翻一章,远不能完成5个月翻完的承诺(2009年10月~2010年2月);
  2. 可见性几乎没有,不知道现在项目处在什么样的一个状态,很难知道大家现在都在做什么;
  3. 沟通上只有区区的3到5封Email,并不像大家开始想的有什么问题,可以打电话,发邮件沟通。
那怎么解决这几个问题呢?我们做了一次回顾会议审视了这些问题。

首先是沟通问题。我们决定每个星期开一次周会,这是我们的checkpoint。在这个会议上,大家首先各自回答三个问题:

  1. 这个星期我做了什么?
  2. 下个星期我准备做什么?
  3. 有什么困难?
    然后大家可以一起讨论一些翻译的难点,统一术语表等。甚至有些句子实在难懂,我们会安排会后发邮件给Mike Cohn询问。
    最后大家在回顾一下我们的翻译过程,看看有什么可以改进的。
周会能帮我们定期沟通,但是还不够及时。比如周中我翻译完了一章,Reviewer得等到周会时才能知道。于是我们用CruiseControl.NET来通知大家每次checkin,这样Reviewer就可以及时知道,现在有哪些完成了,可以开始review。

image

从图上大家可以看出,我们每次完成一章,还要更新Burndown的Excel。这样我们就可以通过这个Excel看到项目状态。这是我们完成一项任务要填的表格:

image

以及反映项目进度的Burndown图:

image

如图所示,我们每个星期更新这个Burndown。横坐标为时间,每个点是我们周会的时间,间隔为一个星期;纵坐标为章节数。应此图上的每个点即反映了我们此时所剩的章节数。红色的线为理想的参考进度,从图上可以看出我们的进度落后理想进度很多了,很清楚的反映出我们现在的问题。现在大家都清楚现在项目的状态了,努力追赶进度吧。可是一个月后,得到的图是这样子的:

image

出了什么问题呢?我会在下一篇文章中继续分享,写了好长了哦,休息下,嘿嘿

Jackson Zhang

Jackson Zhang

Odd-e敏捷教练,主要涉及组织,团队,产品,技术,工程实践等,曾为多家知名企业提供教练与培训服务。译有《用户故事与敏捷方法》,《.NET单元测试的艺术》和《实例化需求说明》。擅长工程实践(如测试驱动开发,单元测试,重构,持续集成等),产品探索(Impact Mapping,Pretotyping,Lean Startup等)与团队协作。zbcjackson AT gmail.com

Read More