自2001年《敏捷软件开发宣言》发表以来，许多全球软件公司两者都采用迭代和增量方法，并欢迎它们提供的质量、速度和市场转换。

尽管如此，尽管软件开发和工程团队在很大程度上受益于敏捷模型，但仍然有太多的本地化团队落后。

该报告的理由各不相同:一些公司已经发现从瀑布到迭代开发的过渡已经足够困难，而不是将其应用到本地化。内部本地化经理发现自己被推到了后座，支持Scrum团队的“更重要的参与者”。此外，一些本地化供应商一直忙于在定价中关注“项目最小化”，而不是满足对敏捷培训、工具和流程的承诺。

我们可以承认这是从目前的数字来看的。公司本地化产品的范式转换。传统的“瀑布式”本地化流程负担沉重，字数庞大，内容变化难以忍受，文件格式真正自负，人员投入巨大，尤其是项目管理。

然而，那些接受敏捷软件开发的人公司敏捷本地化可以忽略吗？不要！这太危险了，即:

正确考虑自身利益的国外市场客户，应优先考虑国内买家；

市场份额取决于行业竞争对手向目标区域交付的速度；和

自动化的工具，管理良好的团队，更少的文字，更短的发布周期，让成本和生产力成为可能。

你准备好了吗公司本地化项目走上敏捷之路了吗？

你可以变瘦。

语言学家翻译公司为您提供解决方案:敏捷本地化包(Agile Localization Package)，在敏捷环境下优化内外部本地化团队的解决方案，从而赢得模式的承诺——即更高质量的可交付成果、更快的市场周转时间、精益生产，以满足全球消费者的需求。

敏捷本地化包关注昂贵的公司本地化团队、流程和目标。这是关于编写代码字符串、网站内容、用户文档和测试计划，同时减少本地化相关的缺陷、交付延迟和成本超支。

精益发展的6个步骤

毫不奇怪，一开始你公司我们的“新健康计划”必须从可靠的风险评估开始。也就是说，通过首先仔细研究本地化项目的当前状态，您可以避免常见的陷阱并享受敏捷本地化饮食的成功:

本地化是否已经成为团队生产重点的一部分？

您的软件是否符合文本和非文本组件(例如，文档、图标、声音)、区域格式(例如，时间、日期、货币)、文化期望(例如，姓名、头衔、敬语)等等的国际化标准？

您的本地化经理是否有权立即做出关键决策，以满足项目的本地化需求？

现在让我们开始吧。

第一步:建立正确的团队

敏捷本地化包要求翻译经理和团队在Scrum中有发言权。正如生产和工程流程必须由Scrum成员拥有以确保成功一样，必须有本地化的工作流。谁能更好地确保切换、处理、质量保证和存储任务与生产周期的速度相匹配？

第二步:合适的时间

尽管之前本地化处于漫长开发周期的最后阶段，功能和编码通常已经完成，但敏捷本地化将内容创建和翻译带到了前台。在过程的早期转移这些任务可以提高产品文档的准确性，优化自动化带来的本地化过程的好处，并减少与单次迭代的错误相关的风险。

第三步:使用合适的设备。

正如每个厨师都需要一把好刀一样，每个敏捷团队都需要合适的工具。虽然我们是在家翻译。公司它与工具无关，但是在敏捷本地化环境中可以满足一些标准:自动化软件应该能够容易地切换到本地化团队。截图和元数据(XML或XLIFF文件格式)应该提供上下文，以便翻译人员可以快速完成工作。文档模板应该利用基于主题的创造性实践。

第四步:烧掉。

邀请您的本地化经理加入团队，但不将本地化工作纳入sprint的燃烧图表，就像邀请素食者参加猪肉烧烤一样。确保产品待办、sprint待办、刻录中包含内容创作和翻译任务。

第五步:停止思考每一个单词。

不要再和供应商争最少字数和每次冲刺报价。敏捷本地化包要求减少延迟工作的过程以支持简单性。协商你的敏捷团队每小时或每年可以完成的字数。

第六步:关注结果

在SQL Server敏捷本地化的案例研究中，微软报告本地化错误总数减少了41%，外包成本节省了两位数，并快速模拟出满意的客户。换句话说，敏捷本地化包为世界上一些最大的内容生产者创造了奇迹。它可以为你的团队做同样的事情。

虽然这种迭代模式不是一刀切的，但敏捷丰富的本地化为全球企业提供了生产速度、效率和成本节约。抛开关于敏捷的神话——敏捷更贵，或者说敏捷太没有计划性不可靠——迎接真正的机会，等待敏捷本地化过程的实施，更好地应对当今动态的市场。

如果你认为本地化是一种功能而不是负担，我们语言学家翻译。公司相信两个团队——客户和供应商——都会宣称敏捷承诺的成功，也就是以客户为中心的、响应式的软件开发，既高质量又“完整”。