Предлагаю результаты перевода фиксировать в вики: http://chernoviki.ru/index.php/OpenUP_Dictionary

А почему бы это не делать на страничке перевода или на худой конец в wikipedia.org? Зачем изобретать велосипед?

А почему бы это не делать на страничке перевода или на худой конец в wikipedia.org? Зачем изобретать велосипед?

В чём велосипед? Попробуй сам "сделать на страничке перевода" - я на тебя посмотрю) На википедии лежат более-менее готовые, а не рабочие материалы. К тому же на википедии и http://wiktionary.org/ нет словарей на одну страницу, только отдельными статьями на каждое слово + там тебе в любой момент кто угодно его оттюнит в собственную сторону.

см. напр. http://ru.wiktionary.org/wiki/actor

Сейчас передо мной стоит конкретная задача. Есть команда разработчиков из шести человек, плюс два человека сэйлз+маркетинг, сидящие в соседней комнате. Мне нужно улучшить существующие процессы разработки, и за основу я бы взял OpenUp, потому что, судя по описанию, он как раз на такие команды и ориентирован (небольшие, с тесным и открытым внутрикомандным взаимодействием). И мне кажется, мой случай довольно массовый.
У программистов по пятнадцать-двадцать лет опыта работы. UML они не знают (в то время, когда они учились, такого слова ещё не было, а реальной необходимости его изучения не возникало). Со словами вроде RUP или XP не знакомы. Отправить всю команду скопом на обучение только для того, чтобы они поняли основные термины - дешевле самораспуститься.
Но базовые подходы всё-таки нужно внедрять, объясняя их людям постепенно, на простом русском языке, используя интуитивно понятные термины. Если я вдруг заговорю об "артефактах", мнение программистов будет однозначным: "Гриша опять начитался книжек о модных концепциях в программировании".
Вопрос состоит в том, насколько перевод OpenUp должен быть приближен к реальной жизни - должна быть это "академическая" модель или готовое к внедрению "руководство к действию", простое и эффективное, как автомат Калашникова?

Находясь в такой ситуации, я бы вообще не стал говорить про процессы и упаси Бог, RUP/OpenUP ... UML и т.п. Вы можете сказать что у вас уже сформировалась КОМАНДА?  ... Если да -- то внедряйте тот же Scrum, даже на говоря о том что это методология, что это agile все такое ... Просто внедряйте практики, которые были бы эффективны и их польза была бы осязаема для всех.

Гриша, я думаю вам уже ответили.

И по причине приостановке перевода: тут причины разные, в том числе и отпуск. Не забывайте, что мы каждый, кто переводит делает это сугубо благотворительно, т.е. даром, использую свое свободное время. Например, я активно переводил в мае-июне; половину взял "на дом", чтобы поработать в отпуск на досуге. В среднем на 1 статью уходит 3-4 часа, а в "дневом эквиваленте"  - огбычно пару дней не меньше. Перевод дело сложное. Особенно данного ресурса - много жаргонизмов, откровенных стилистических ошибок, "проглатывания" частей предложения, неустоявшаяся система перевода многих терминов и т.п.

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

Насчет терминологии, надеюсь тоже все понятно. Перевод многих терминов уже устоялся и во многом совершенно корректен.

Насчет артефакта. Перевод довольно ясен. Слово достаточно употребительное. В русском языке оно чаще всего относится к предметом материальной культуры древнего человека или что-то очень древнего самого по себе. Поэтому есть такое противодействие использованию термина. Однако изначальный смысл - это любой продут, сделанный человеком! то что не встречается в природе, отличается от природы. Хотите ли Вы привыкнуть к термину или Ваши программисты, дело Ваше, однако на месте Ваших программистов я бы почитывал бы книжечки и не хулил Гришу, за его старания. И то, что программисты типа старые (могу предположить им от 40, 45 лет - мне кстати тоже, и я увлеченно изучаю всякие разные разности - хотя знаете в 40 лет абсолютно не чувствуешь себя замшелым), во все не оправдывает их. А интересно они еще на фортране программируют? на dbase? клипперуют? В UML ведь ничего особо приницпиально нового нет. То что они чего-то не учили, не означает, что это невозможно применять...

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

Находясь в такой ситуации, я бы вообще не стал говорить про процессы и упаси Бог, RUP/OpenUP ... UML и т.п. Вы можете сказать что у вас уже сформировалась КОМАНДА?  ... Если да -- то внедряйте тот же Scrum, даже на говоря о том что это методология, что это agile все такое ... Просто внедряйте практики, которые были бы эффективны и их польза была бы осязаема для всех.

Мне кажется, моя ситуация типична для небольших команд разработчиков. Что такое SCRUM я, кстати, ещё не знаю.
Разумеется, я пытаюсь применять вновь приобретаемые знания в своей практике, но даже приобретение этих знаний - проблема (постоянная нехватка времени). Сейчас у меня пока складывается впечатление, что эти "процессы" и "практики" несколько оторваны от реальной жизни, и для их применения нужны некоторые вложения, которые, по предварительной оценке, в нашей компании не окупятся. Подозреваю, что не только в нашей.

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

И по причине приостановке перевода: тут причины разные, в том числе и отпуск. Не забывайте, что мы каждый, кто переводит делает это сугубо благотворительно, т.е. даром, использую свое свободное время. Например, я активно переводил в мае-июне; половину взял "на дом", чтобы поработать в отпуск на досуге. В среднем на 1 статью уходит 3-4 часа, а в "дневом эквиваленте"  - огбычно пару дней не меньше. Перевод дело сложное. Особенно данного ресурса - много жаргонизмов, откровенных стилистических ошибок, "проглатывания" частей предложения, неустоявшаяся система перевода многих терминов и т.п.

Это я, конечно, уже понял. Как я уже говорил, для себя я всё равно буду переводить основные положения OpenUp, потому что это лучший способ детально в нём разобраться. Если моя работа пригодится кому-то ещё - буду рад, но страницу в wiki портить пока не стану.

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

Прошу присоединить к рассмотрению еще такую идею: почему мы должны заниматься переводом чужой методики?
OpenUp молод и легок мы в состоянии создать собственное описание процесса путем отжимания тяжелых методологий и добавления своих знаний.

А наших знаний хватит?? Да и времени это оторвет не мало ... Думаю стоит рассмотреть предложение, но надо к нему подойти со всей ответственностью.

Мне кажется, моя ситуация типична для небольших команд разработчиков. Что такое SCRUM я, кстати, ещё не знаю.
Разумеется, я пытаюсь применять вновь приобретаемые знания в своей практике, но даже приобретение этих знаний - проблема (постоянная нехватка времени). Сейчас у меня пока складывается впечатление, что эти "процессы" и "практики" несколько оторваны от реальной жизни, и для их применения нужны некоторые вложения, которые, по предварительной оценке, в нашей компании не окупятся. Подозреваю, что не только в нашей.
... я пытаюсь найти методику, которая поможет улучшить работу над проектами в короткие сроки и с небольшими затратами "без отрыва от производства".

У вас маленькая команда, коммуникации налажены ...  Для начала сформулируйте ПОЧЕМУ вам нужны именно процессы, ПОЧЕМУ вы хотите вообще что-то улучшить ... что не устраивает в текущей практике работы? С какими проблемами вы сталкиваетесь? Что вы ожидаете от улучшения процессов. Какова ваша текущая практика. Какой софт вы разрабатываете (грубо -- это автоматизация бизнес-процессов или драйвера к "железу", это "одноразовые" проекты на заказ или разработка "коробки"?). Как вы разрабатываете и управляете требованиями, изменениями, конфигурациями ... есть ли у вас проблема с качеством ПО .... ?
Если мы поймем вашу ситуацию, то вполне возможно сможем подсказать вам что-то, что будет полезным.

У вас маленькая команда, коммуникации налажены ...  Для начала сформулируйте ПОЧЕМУ вам нужны именно процессы, ПОЧЕМУ вы хотите вообще что-то улучшить ... что не устраивает в текущей практике работы? С какими проблемами вы сталкиваетесь? Что вы ожидаете от улучшения процессов. Какова ваша текущая практика. Какой софт вы разрабатываете (грубо -- это автоматизация бизнес-процессов или драйвера к "железу", это "одноразовые" проекты на заказ или разработка "коробки"?). Как вы разрабатываете и управляете требованиями, изменениями, конфигурациями ... есть ли у вас проблема с качеством ПО .... ?
Если мы поймем вашу ситуацию, то вполне возможно сможем подсказать вам что-то, что будет полезным.

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

В компании работает 8 человек, из них двое занимаются продажами, остальные шестеро - собственно разработкой софта.

Софт - приложения для POS терминалов (не универсальных кассовых аппаратов, а специализированных терминалов для приёма банковских карт), включая как традиционные финансовые, так и нефинансовые top-up приложения, а также сопутствующие приложения для PC (сервера загрузки параметров, в том числе с обращением к базам данных, межпротокольные конвертеры, конфигураторы и т. п.)
Плюс собственное API для разработки терминальных приложений, которым мы пользуемся сами и которое поставляем своим партнёрам.

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

Проблемы, скорее всего, тоже традиционные: требования практически не документированы, концепция основных приложений существует только в голове программистов, тестирование выполнялось самими разработчиками. Это до некоторого времени не создавало проблем, поскольку почти все программисты "вылетели из одного гнезда" (работали раньше в одной компании, которая сейчас свернула разработку ПО в России) и представление о конечных продуктах практически не расходилось даже в мелочах. Да и софт был достаточно простым, пока работал только с картами с магнитной полосой.

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

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

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

Некоторые инструмены внедрялись постепенно, в хронологическом порядке:

- контроль версий (VSS) - с самого первого дня, без него работы я вообще не представляю;

- управление текущимим задачами (календарное планирование на ближайший месяц) - как только число программистов превысило три. Были перепробованы какие-то открытые средства, MS Project отвергнут по причине громоздкости и неудобства, в конце концов разработал свой движок с веб-интерфейсом, привязав его к базе данных проектов;

- учёт запросов клиентов (баг трекер и запросы на изменения) - изначально вёлся в виде отдельных таблиц Excel, по мере роста количества клиентов пробовали BugZilla (не смогли настроить ), MANTIS (слишком громоздкий), потом открыли в интернет трекер опять на основе собственного движка;

- управление тестированием - прошли несколько итераций в выработке шаблонов планов тестирования, сначала в MS Word (невозможно анализировать и собирать статистику, пока не просмотришь весь документ), потом в БД на основе MS Access (неудобный интерфейс, не совместим со стандартным SQL и глючит со страшной силой), вопрос пока остаётся открытым. Используем простые неформальные планы тестирования, а отчёты о результатах помещаем в баг-трекер и в истории проектов;

- учёт требований - что-то записывается в ту же базу данных проектов и периодически используется для подготовки тестов. Но это всё не автоматизировано, о какой-либо полноте требований пока не может быть и речи, никакой трассировки требований и тестов нет. Слова вроде UML и Use Case пока, похоже, знаю только я.

Требования меняются постоянно и иногда непредсказуемо. Одно только отслеживание требований основных платёжных систем (MasterCard, VISA и EMV) требует постоянного внимания и временных затрат.

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


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

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

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

Как мне представляется в настоящий момент, основные проблемы у нас накопились в следующих областях:

0) Нет чёткого долгосрочного планирования. Мы над этим работаем, но это зависит не только и не столько от меня.

1) Не систематизированы выявление и учёт требований. Это ведёт к расплывчатости концепций (приходится устранять частыми обсуждениями уже в процессе кодирования, нередко с переделкой уже готовых компонентов), к трудностям при выборе необходимых тестов и соотвествующим снижением качества продукта.

2) Нет какой-либо единой методологии выработки концепций и разработки архитектуры. Тут мы ходим по граблям: иногда получаем от сэйлзов так называемое "ТЗ", которое они получили от клиента, но забыли согласовать с нами, или когда бизнес-представление не учитывает или противоречит существующим наработкам.

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

3) Самая болезненная для меня проблема - нехватка ресурсов. Но, как мне кажется, их распределение можно ещё оптимизировать. Много времени тратится впустую именно из-за недостатков в предварительном планировании.


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

мы в состоянии создать собственное описание процесса путем отжимания тяжелых методологий и добавления своих знаний.

Я в беседе с Денисом высказывал такую мысль. Действительно не интереснее ли делать что-то свое? Однако заимствование неизбежно - как быть с авторскими правами? И еще обычно методика сначал реализуется в реальном проекте, а потом просто формализуется и стандартизируется.
Есть ли у нас подобная возможность?

На самом деле, это примерно то, чем я собираюсь заняться на основе наших проектов. Собрать воедино общие представления о ведении проектов разработки ПО, определить фазы, вехи, роли, описать шаблоны основных документов... ну, пусть будут Work Products и пошаговые процедуры.

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

Но я осознаю, что прежде чем я готов буду сгенрировать что-то полезное, ещё очень много информации нужно воспринять и переработать. Я и с шаблонами OpenUp ещё толком не разобрался.

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

Софт - приложения для POS терминалов (не универсальных кассовых аппаратов, а специализированных терминалов для приёма банковских карт), включая как традиционные финансовые, так и нефинансовые top-up приложения, а также сопутствующие приложения для PC (сервера загрузки параметров, в том числе с обращением к базам данных, межпротокольные конвертеры, конфигураторы и т. п.)
Плюс собственное API для разработки терминальных приложений, которым мы пользуемся сами и которое поставляем своим партнёрам.

Пока не понял, нужны ли вам те же юзкейсы, о которых вы упоминаете ниже ... думаю вам вполне подойдет отмодифицированные user stories, или просто неформализированные сценарии. Но боюсь, что управлять ими придется с использованием инструментария RDM или как минимум wiki.

Проблемы, скорее всего, тоже традиционные: требования практически не документированы, концепция основных приложений существует только в голове программистов, тестирование выполнялось самими разработчиками. Это до некоторого времени не создавало проблем, поскольку почти все программисты "вылетели из одного гнезда" (работали раньше в одной компании, которая сейчас свернула разработку ПО в России) и представление о конечных продуктах практически не расходилось даже в мелочах. Да и софт был достаточно простым, пока работал только с картами с магнитной полосой.

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

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

Управление конфигурациями и изменениями .... самое оно. Иметь CCB  и регламент внесения изменений.

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

Нужно уделять время на синхронизацию виденья архитектуры всеми "петрящими" в этом членами команды .. .т.е. как минимум разработчиками. Управляемые коммуникации это ваше ВСЕ ... :-).

Некоторые инструмены внедрялись постепенно, в хронологическом порядке:
- контроль версий (VSS) - с самого первого дня, без него работы я вообще не представляю;

Можно использовать бесплатный SVN ... 

- управление текущимим задачами (календарное планирование на ближайший месяц) - как только число программистов превысило три. Были перепробованы какие-то открытые средства, MS Project отвергнут по причине громоздкости и неудобства, в конце концов разработал свой движок с веб-интерфейсом, привязав его к базе данных проектов;

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

- учёт запросов клиентов (баг трекер и запросы на изменения) - изначально вёлся в виде отдельных таблиц Excel, по мере роста количества клиентов пробовали BugZilla (не смогли настроить ), MANTIS (слишком громоздкий), потом открыли в интернет трекер опять на основе собственного движка;

Jira рулит.

- управление тестированием - прошли несколько итераций в выработке шаблонов планов тестирования, сначала в MS Word (невозможно анализировать и собирать статистику, пока не просмотришь весь документ), потом в БД на основе MS Access (неудобный интерфейс, не совместим со стандартным SQL и глючит со страшной силой), вопрос пока остаётся открытым. Используем простые неформальные планы тестирования, а отчёты о результатах помещаем в баг-трекер и в истории проектов;

можно хранить тест-кейсы в wiki или  в инструментарии RDM.

- учёт требований - что-то записывается в ту же базу данных проектов и периодически используется для подготовки тестов. Но это всё не автоматизировано, о какой-либо полноте требований пока не может быть и речи, никакой трассировки требований и тестов нет. Слова вроде UML и Use Case пока, похоже, знаю только я.

Как я говорил выше, не факт что UC вам нужны ... а вот инструментарий для работы с требованиями пригодился бы.

Требования меняются постоянно и иногда непредсказуемо. Одно только отслеживание требований основных платёжных систем (MasterCard, VISA и EMV) требует постоянного внимания и временных затрат.

Jira + RDM tools рулят (плюс регламент ессесно ... )...

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

Product Manager и Project Manager должны быть как класс ... роли я имею ввиду. Которые и должны отстаивать договоренности по приоритетам .... критерий можно взять один -- "кто больше платит того и тапки" :-)

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

Ну пока хаос только кажущийся ...

Как мне представляется в настоящий момент, основные проблемы у нас накопились в следующих областях:

0) Нет чёткого долгосрочного планирования. Мы над этим работаем, но это зависит не только и не столько от меня.

Долгосрочное планирование в вашей ситуации бесконечных и непредсказуемых изменений ... хм ... только если "внутренние" проекты, по переходу например на другие библиотеки, средства разработки, изменение архитектуры и т.п.

1) Не систематизированы выявление и учёт требований. Это ведёт к расплывчатости концепций (приходится устранять частыми обсуждениями уже в процессе кодирования, нередко с переделкой уже готовых компонентов), к трудностям при выборе необходимых тестов и соотвествующим снижением качества продукта.

Работайте над этим ... вобщем все больше убеждаюсь что вам нужно смотреть в сторону Scrum а не на UP.

2) Нет какой-либо единой методологии выработки концепций и разработки архитектуры. Тут мы ходим по граблям: иногда получаем от сэйлзов так называемое "ТЗ", которое они получили от клиента, но забыли согласовать с нами, или когда бизнес-представление не учитывает или противоречит существующим наработкам.

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

3) Самая болезненная для меня проблема - нехватка ресурсов. Но, как мне кажется, их распределение можно ещё оптимизировать. Много времени тратится впустую именно из-за недостатков в предварительном планировании.

Сбрасываете простую рутину на студентов, если есть простая рутина и студенты, и время их ввести в курс дела :-).

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

Scrum для вас самое оно ... а консультанта по нему лучше таки пригласить -- дешевле выйдет, если консультант толковый. Но приглашать только когда сами поймете что такое Scrum .... если что - могу подсобить с консультантом :-).

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

Jira рулит.

Один из наших партнёров использует Jira, тоже присматривались. Но те функции, которые были нужны, уже реализованы в нашем собственном трекере. Простой инструмент, созданый под "себя", пока предпочитительней. Там всё сделано для удобства вечно занятых программистов, для которых каждый лишний клик - повод "забыть" выполнить необходимое действие.

Долгосрочное планирование в вашей ситуации бесконечных и непредсказуемых изменений ... хм ... только если "внутренние" проекты, по переходу например на другие библиотеки, средства разработки, изменение архитектуры и т.п.

Забыл упомянуть ещё одну особенность. Исходный код приложений для терминалов сейчас должен работать минимум на пяти аппаратных платформах и компилиться семью разными компиляторами. Вероятно появление новых платформ в ближайшее время. И это работает.
Правда, из-за этого нам пришлось отказаться от объектно-ориентированных языков и вернуться к старому доброму ANSI C. А некоторые компании в этой отрасли вообще до сих пор не могут избавиться от груза старых ассемблерных наработок.

Сбрасываете простую рутину на студентов, если есть простая рутина и студенты, и время их ввести в курс дела :-).

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

Scrum для вас самое оно ... а консультанта по нему лучше таки пригласить -- дешевле выйдет, если консультант толковый. Но приглашать только когда сами поймете что такое Scrum .... если что - могу подсобить с консультантом :-).

Спасибо, как только вернусь из отпуска - буду посмотреть. Если только это не такая же громоздкая и закрытая вещь, как RUP.

У меня такие же мотивы к изучению и переводу OpenUP, как и у Greesha. Переводить я тоже буду по любому, но скорее всего перевод будет в EPF Composer. Есть ли какие либо варианты, выложить на всеобщее обозрение файлы *.xmi. Для обмена и собирания не только описания методологии OpenUP на русском языке, а практик. Уверен, что данный подход был бы гораздо интереснее. Заодно можно и поделиться опытом использования EPF Composer.

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

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