Agile

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

厄…一不小心,这最后一部分拖了这么久才写,得先自我检讨检讨。这最后的部分其实是此次翻译中最重要的一部分。这篇我将分析为什么这次翻书会比较成功。当然,这个成功的定义来自于出版社的反馈,较高的质量以及如期的交付。 首先,我们是一个分布式的团队。曾经有段时间我在美国出差,Bill也经常在国外飞来飞去,而且我们都是兼职来做这个翻译,几乎不怎么见面。那么我们是怎么解决沟通协调的问题呢? 我们使用了看板,其实也就是一个Excel表格。但是就这么简单的一个东西提供了一些项目的可见性,更重要的是它帮助我们协调任务。我们可以很容易的避免两个人做重复的任务。 每周的同步会议。从中我们可以知道,现在项目的状况。同时,大家要对未来一个星期做出commitment,即下个星期要做什么。然后是提出遇到的困难,大家一起沟通商量解决方案。其实也就是Scrum中Daily Scrum每个人要回答的三个问题。最后就是Retrospective,回顾一下我们现在项目中有什么需要改进的。

Agile

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

上次说到在我们改变翻译方式后的一个月,我们的burndown chart上的线变成水平的线,离理想的进度线越来越远,到底出了什么问题呢? 来看看我们的电子白板Excel吧 从第3章到第9章,我们确实翻译完了,也做了两次review,但是我们没有基于这些review来做修改,这并不是真正的做完了。因为需要交付时,我们并不能直接这样交付,还是得做最后的修改的。于是,紧接着的一个星期,我们就完成这7章的扫尾工作。我们终于又朝着理想线逼近啦! 但是我们依然还落后一些进度,该怎么办呢?其实仔细想想,整个翻译团队并没有发挥最大的产出。当两个翻译在翻译章节的时候,reviewer是在等待翻译好的章节,此时他们是没有产出的,直到有可审核的章节时,才有产出。如何才能利用这段时间来提高产出呢?很简单,让reviewer也做翻译。同时每个章节还是要遵守之前的约定,一个人翻译,要有另两个人来做审核。

Agile

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

数年前Mike Cohn写了这本User Stories Applied: For Agile Software Development,而我从2007年才真正开始接触敏捷,没想到2009年我有机会能够参与翻译这本有关用户故事的经典著作,我感到十分的荣幸。 这次翻译我们一共四个人参与,我和石永超(Stone)主要负责翻译,滕振宇(Daniel)和李国彪(Bill)主要负责审核,大家都是兼职来做这次翻译的。多人翻译首先考虑的是两个问题:要有个Central repository,大家可以能在上面更新或拿到最新的版本;还要有公共的标记,谁要翻译哪一章就做一个标记,避免翻译重复。既然需要一个公共的Repository,上面放的都是Word文档,我们马上就想到了Google Doc。接下来是标记问题,