Agile-подход к локализации

Проекты локализации программного обеспечения традиционно основаны на «модели водопада»: сперва определяются требования и объем работы, затем происходит планирование проекта, реализация, интеграция локали в продукт и тестирование. Такая схема подразумевает начало работы над локализацией на позднем этапе разработки продукта или даже после релиза – тогда, когда все локализуемые элементы уже написаны и готовы к переводу.

Если разработчику нужно выпустить локализованную версию одновременно с основной, поздний старт локализации добавит ему головной боли. Самый напряженный этап разработки последние дни перед релизом, когда все силы брошены на финальное тестирование и починку багов. Если вся работа над локализациями также проходит на этом этапе, в офисе может стать жарко.

Чтобы смягчить эту нагрузку, несколько лет назад в компании F-Secure придумали и внедрили модель «agile localization» («гибкая локализация»). В этой модели продукт локализуется в процессе его разработки – как только в ходе разработки появляется какой-то элемент, который нужно локализовать, он сразу же отправляется переводчикам.

Помимо упомянутой разгрузки предрелизных дней, преимуществом гибкой локализации является возможность раннего тестирования продукта иностранными пользователями. Конечные пользователи и заказчики-иностранцы смогут дать обратную связь после каждой итерации разработки. Основной недостаток метода – это, конечно же, увеличение затрат. Далеко не все строки и тексты, которые возникают в процессе разработки, входят в окончательный продукт; таким образом, часть переводов останутся невостребованными.

Как определить, нужно ли вам внедрять agile-локализацию? Выясните временные рамки, которыми будет ограничена локализация продукта, если начинать ее на заключительном этапе разработки. И подсчитайте, успеете ли вы полностью локализовать всё, что нужно, в эти сроки. Если нет, возможно, вам стоит разбить локализационный процесс на итерации и синхронизировать его с разработкой.



2 комментария к “Agile-подход к локализации”

  1. Nik says:

    >Проекты локализации программного обеспечения
    >традиционно основаны на «модели водопада

    По какому принципу определялась “традиционность” описанной методики? Традиционные в смысле “применяется в большинстве случаев в настоящее время” или в прошлом? Большинство в данном случае определяется размерами локализуемых продуктов (в словах?) или объемом продаж локализованных продуктов или чем-то еще?

    По какой причине не упомянут вариант, когда локализуемость продукта проверяется по мере разработки, а перевод начинается после завершения разработки или на поздних этапах проекта разработки? Этот вариант считается экзотическим? Или предполагаются какие-то причины, по которым он значительно хуже двух упомянутых?

    Среди увеличенных затрат не упоминается обработка отзывов от иностранных пользователей и обратная связь с ними (реакция на отзывы). Считается, что эти затраты малы по сравнению с прочими дополнительными затратами, или есть какая-то другая причина?

    Не упомянут размер программных продуктов, о локализации которых идет речь. Этот пост относится к локализационным проектам любого размера и любого количества языков или только к определеному диапазону?

    С уважением,
    Николай

    • Егор Заикин says:

      Николай, спасибо за такой развернутый отзыв.

      В первом абзаце я имел в виду, что “в настоящее время большинство программных продуктов локализуются по модели водопада”. При этом я не учитывал количество слов и объем продаж, только сам факт существования продукта и его локализации.

      К сожалению, никакой достоверной статистики по этому вопросу не существует, поэтому я исходил из собственного опыта работы – как на стороне заказчика локализации, так и на стороне исполнителя.

      Вообще, чтобы подробно осветить все аспекты agile-локализации, нужна брошюра страниц на 20, а это всего лишь ознакомительный пост в блоге. Если Вы не против, я с удовольствием отвечу на остальные вопросы личным сообщением.

      С уважением,
      Егор

Оставить комментарий