1. Я бы не сказал, что переводить на их ресурсе проблематично. Скорее всего это дело привычки.
2. Как быть с переводом EPF Composer?

1. Я не сказал что проблематично, я сказал тяжело. Я переводил примерно по странице в день-два, иногда дольше. Приходилось внимательно следить за ссылками и прочее. Я даже такю технологию использую. Открываю страницы, перехожу в HTML просмотр, копирую, сохраняю у себя, а потом редактирую в Notepad++. Это оказалось самое быстрое, ресурсоненапряжное. Тяжело в том, что пришла новая версия, старая неакутальна стала. Следовательно нужно начинать переводить новую. Опять трата времени и сил. Измениться версия релиза пока переводим старую, и опять вся работа коту под хвост....

2. И его переводить? А его то зачем? Вы имеете в виду локализацию фреймворка?

я бы как раз и перевел бы фреймворк - было бы более полезно.

я бы как раз и перевел бы фреймворк - было бы более полезно.

Почему?

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

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

Странная у вас логика. Сколько реально людей, которые хотят и готовы заниматься настройкой процессов, и сколько реально людей, нуждающихся в руководстве к действию?

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

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

Давайте предметнее - вы про обучение в стенах вуза или как?

Если как - то вот скажем есть коллектив из 10 программистов - кто будет фреймворк настраивать и зачем?

Ок. Есть коллектив из 10 программистов, у этого коллектива есть руководитель. Вот этот самый руководитель и будет настраивать, дабы не терять драгоценное время на планирование подобных задач, снова и снова. А уж если одновременно ведется работа над несколькими проектами (да хоть над одним), то коллектив обязан знать, в каком проекте и за что он отвечает. Свои обязанности и последовательность действий.

Или Вы полагаете, что коллектив в 10 человек не нуждается в планировании работы?

Поскольку я успел внести мизерный вклад в перевод, меня "посчитали", и неделю назад я получил письмо из IBM, содержащее такие строки:

As you know, we want to leverage your knowledge and experience by harvesting the comments and content added to this Wiki so we can enhance the processes available in EPF. In order to do this, we need to perform two activities:

1- Migrate the EPF Wiki from its current location to Eclipse organization infrastructure.
2- Move the content from the current Wiki to the new Wiki located on Eclipse infrastructure

Честно говоря, не совсем понял, чем это грозит. Как и когда они будут переносить страницы - непонятно.
При этом я вижу, что испанская и португальская версии продолжают активно развиваться.


При переводе я упёрся, в первую очередь, в терминологию. Ниже в этой ветке было небольшое обсуждение по этому поводу. Как мне сейчас видится, единой терминологии как не было, так и нет. Приверженцы Agile, похоже, вообще не озабочены переводом и говорят на жаргоне, в котором большинство слов представляют собой англоязычные термины, склоняемые по правилам русского языка. Среди "процессников" идут вялотекущие споры о терминах, но каждый, как мне кажется, остаётся при своём мнении.

Поэтому, если браться за перевод, я бы в первую очередь определился с терминами. Неплохо было бы создать единый и непротиворечивый глоссарий. OpenUp в этом смысле хорош тем, что даёт минимально необходимый набор понятий.

На сайте http://www.epfwiki.net/ я не нашёл раздела, содержащего все термины (может, плохо искал)? И поэтому создал страницу "Англо-русский словарь по OpenUp". Предполагая при этом, что переводчики сами будут добавлять в него термины по мере перевода страниц.

Но в EPF есть раздел Term Definitions! И мне кажется логичным начать с перевода этого раздела.

Ок. Есть коллектив из 10 программистов, у этого коллектива есть руководитель. Вот этот самый руководитель и будет настраивать, дабы не терять драгоценное время на планирование подобных задач, снова и снова. А уж если одновременно ведется работа над несколькими проектами (да хоть над одним), то коллектив обязан знать, в каком проекте и за что он отвечает. Свои обязанности и последовательность действий.

Ха-ха, руководителю просто делать нечего, ковыряться с какой-то глюкавой софтиной ) Нормальный руководитель сделает что: 1) расскажет и объяснит всё словами; 2) когда это перестанет работать - будет по необходимости писать регламенты тех или иных процессов, используя Word, Visio или Wiki (и поглядывая на ГОСТ, PMBOK, SWEBOK, RUP, MSF или Agile). Если только он не бывший Java-разработчик, которых в общей массе немного.

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

Или Вы полагаете, что коллектив в 10 человек не нуждается в планировании работы?

Планирование в каждом новом проекте делается заново, в итерационных - в рамках итерации. Если для планирования нужна некая эталонная модель процесса (процессов), то как её получить - я описал выше.

Я не отрицаю полезность получения нужного описания процесса (скорее наоборот), я оспариваю полезность применения таких инструментов, как EPF и RMC. Т.е. вы конечно можете это делать (локализацию инструмента), но ваши надежды на общую полезность имхо завышены, т.к. если уж такой крутой менеджер найдётся, то ему не станет препятствием английский язык интерфейса инструмента (разового применения!), в отличие от английского языка в контенте описания процесса дял разработчиков.

Я не отрицаю полезность получения нужного описания процесса (скорее наоборот), я оспариваю полезность применения таких инструментов, как EPF и RMC. Т.е. вы конечно можете это делать (локализацию инструмента), но ваши надежды на общую полезность имхо завышены, т.к. если уж такой крутой менеджер найдётся, то ему не станет препятствием английский язык интерфейса инструмента (разового применения!), в отличие от английского языка в контенте описания процесса дял разработчиков.

Вы наверно недооцениваете возможности планирования, возможно потому, что этим никогда не занимались. Но возможно и по другой причине. Использовать Word, Visio, Wiki - замечательная идея. У меня другая точка зрения. Команда разработчиков не всегда состоит из высококвалифицированных кадров, иногда приходится иметь дело и с новичками. Существует множество вариантов. Как один из вариантов использования EPF я уже называл - повторное использование проектов, например проект по инсталяции системы - подобные итерации. Любой проект проходит какой-то путь с повторением предыдущего опыта.

Как я и грозился, я приступаю к очередной попытке перевода глоссария OpenUp/Basic.

Мои соображения изложены здесь: http://www.greesha.ru/openup

Если кого заинтересовало - присоединяйтесь.

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

Глобальные мысли по переводу буду публиковать в этой ветке.

Ссылки на UMA в Глоссарии, как мне кажется, не имеют смысла. Эта модель, похоже, до сих пор не опубликована в интернет. Я не нашёл даже английской версии, не говоря уж о русском переводе:

The initial version of this meta-model has been derived from IBM's Unified Method Architecture (UMA, reference to UMA specification download to be added soon).

http://www.eclipse.org/proposals/beacon

При переводе глоссария возник глобальный вопрос: на кого ориентирован перевод?

Попробую объяснить на примере, почему этот вопрос возник.

Есть набор общих терминов, которые можно перевести разными способами именно из-за их глобальности (activity, work product, phase, task и т. д.). Например, phase в контексте жизненного цикла можно перевести как:
- фаза
- этап
- стадия
Это типовые варианты, по словарю. Можно также придумать более-менее оригинальные: эпоха, эра, перегон и т. п.

В литературе встречаются все типовые варианты. Более того, в некоторых книгах сначала даётся определение фазы в модели жизненного цикла, а потом в каждой главе упорно используется слово стадия.
ГОСТ же разбивает жизненный цикл на этапы (по крайней мере, так отложилось у меня в памяти).

Для того, чтобы остановиться на каком-то варианте, нужно определиться, для кого предназначен перевод и как он будет использоваться (по крайней мере, такой вопрос должен задать себе настоящий аналитик ).

В "целевую аудиторию", как мне представляется, входят:
- команды разработчиков и менеджеры проектов, которые будут использовать OpenUp на практике;
- консультанты, специализирующиеся на внедрении технологий разработки программных проектов;
- наиболее прогрессивные преподаватели ВУЗов, стремящиеся дать своим студентам представление о современных методах разработки 
- кто-то ещё, о ком я забыл...

Для разных подгрупп аудитории могут быть по-разному определены приоритеты принципов перевода:
- соответствие русскоязычным стандартам (используем по возможности ГОСТовское определение "этап")
- близость перевода к английскому оригиналу (любой ребёнок скажет вам, что phase - это "фаза")
- интуитивная понятность термина ("этап" - это что-то монументальное, а "фаза" - это часть короткого периода)
- оригинальность перевода, отличающая данную методологию от десятков других (если мы разобьём жизненный цикл на "эпохи", это, возможно, запомнится).

Последний вариант может показаться надуманным, но у меня сложилось впечатление, что разработчики OpenUp ипользовали этот подход для некоторых терминов. Возможно, из каких-то маркетинговых соображений (как говорят некоторые консультанты, "SCRUM легче продать, потому что слово прикольное").


Чтобы продолжить работу над переводом, нужно, прежде всего, определиться с этими приоритетами.

Отличный анализ.

Однако давайте посмотрим на понятие фаза с другой стороны.

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

Этап и стадия скроее подходят к некоторой восходящей последовательности. Хотя, конечно, вполне можно сказать фаза развития, стадия развития, этап развития - и смысл вряд ли теряется.

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

Для трассировки можно давать переводы с пометкой ГОСТ или тому подобное