У меня есть команда, у которой нет единого общего языка среди всех членов команды. Команда разбита на две части (хотя география не является главной проблемой). Все члены команды в каждом месте говорят на одном языке, и в обоих местах есть участники, которые могут говорить на обоих языках. Я хотел бы представить scrum, но я борюсь с логистикой решения языковой проблемы.
Это не оффшорная команда. Все члены команды являются сотрудниками компании, но расположены в двух разных офисах в разных странах. К счастью, у нас нет проблем с часовыми поясами; язык является основным барьером. Хотя команду можно разделить на две команды, учитывая размер и квалификацию людей в каждой локации, а также другие внешние факторы, более желательно объединиться в единую команду.
Я думаю, что было бы предпочтительнее использовать видеоконференцсвязь, чтобы иметь более богатое общение и помочь объединить команду в возможности видеть друг друга и использовать настоящий подход к стойке. Тем не менее, я боюсь, что это будет трудно общаться между языками. Должны ли двуязычные члены команды переводить устно? С другой стороны, мы могли бы использовать мгновенные сообщения, как рекомендовано, из единственной ссылки, которую я мог найти на языковые проблемы в распределенной схватке. Я беспокоюсь о «плохом» общении и, возможно, это плохое введение в концепцию схватки.
От людей, которые имеют опыт работы с языковыми различиями в команде, как вы решили проблему и насколько хорошо она сработала для вас?
Ответы:
Команды, практикующие Agile , должны быть открыты для экспериментов, не так ли? Вы знаете, "люди над процессами" и тому подобное.
Попробуйте разделить на две команды по языкам и посмотреть, как это работает. Если это окажется проблематичным, вы можете попробовать подход с одной командой.
обновление на основе разъяснений, представленных в комментариях
Вы правильно поняли мою идею, и я думаю, что вы подходите к вопросу правильно.
Как они писали в «Прагматичном программисте» более десяти лет назад,
Можно сказать, что Agile укрепляет эту старую, но золотую философию, делая непрерывные корректировки явно желательной частью процесса разработки.
источник
Наиболее эффективный способ состоит в том, чтобы разделить на две разные команды с логически изолированными результатами для каждой команды - у них будут свои собственные мастера схватки.
Пожалуйста, прочитайте ссылку ниже, это имеет много хороших моментов, которые вы можете следовать. (хотя думаю, что не решает проблемы двух разных языков, это имеет много моментов, связанных с двумя географическими местоположениями). Мартин Фаулер написал эту статью после многих лет работы с оффшорными командами.
http://martinfowler.com/articles/agileOffshore.html
Некоторые из отрывков пули из статьи ниже.
1. Используйте непрерывную интеграцию, чтобы избежать головной боли от интеграции
2. Пусть каждый сайт отправит послов на другие сайты
3. Используйте посещение контактов, чтобы построить доверие
4. Не стоит недооценивать изменения культуры
5. Используйте вики, чтобы содержать общую информацию
6. Используйте тестовые сценарии, чтобы помочь понять требования
7. Используйте регулярные сборки для получения отзывов о функциональности
8. * Используйте регулярные короткие статусные встречи *
и т.д
источник
Какой официальный корпоративный язык? Я не знаю размер вашей компании, но в каждом месте, где я работал, был официальный язык.
Я советую использовать корпоративный язык по умолчанию, если только Scrum Team не хочет что-то другое и поддерживается руководством.
источник
Наша голландскоязычная команда тесно сотрудничает с нашим франкоязычным филиалом. Никто из франкоязычной команды не говорит по-голландски, и наш французский - это нормально.
Все говорят, по крайней мере, немного по-английски, но, безусловно, программисты, это Lingua Franca в Западной Европе. Итак, вся документация на английском языке, все комментарии к коду, все письма и встречи.
Время от времени мы также посещаем филиалы друг друга. Часто тот, кто часто посещает его, приносит с собой кого-то нового, чтобы каждый мог встретиться со всеми.
источник