Форум Сообщества Аналитиков
Общий раздел => Методологии => RUP EUP AUP OpenUP => Тема начата: Denis Beskov от 11 Апреля 2007, 23:52:31
-
Свершилось-таки - господа из IBM прикрутили wiki к процессным сайтам, которые создаются из среды разработки процессов Eclipse Process Framework!
Теперь появилась возможность достаточно удобного перевода открытого процесса OpenUP/Basic, созданного Филиппом Крухтеном из RUP с целью минимизации формализма и привнесения принципов Agile.
Вот русскоязычный сайт процесса: http://www.epfwiki.net/wikis/openupru/
А это картина того, как организовано развитие и перевод содержимого процесса: http://www.epfwiki.net/images/epfwiki_infra_overview.jpg
Предлагаю присоединяться желающим!
-
Уточню, что нашему сообществу предлагаю взяться за дисциплины "Требования" и "Архитектура" (ранее "Анализ и Проектирование"). На другие дисциплины следует попробовать привлечь профильные сообщества.
-
Так, а в какой форме туда имеет смысл лепить перевод?
Править или как коментарий лучше вставлять?
-
Править. Но аккуратно, поглядывая на оригинал)
Комментарии - дял обсуждения содержания и перевода.
Пока правда не всё гладко - встроенный визуальный редактор похоже вырезает тэг AREA - поэтому главная картинка перестала быть навигабельной, пока откатился назад.
-
Вот русскоязычный сайт процесса: http://www.epfwiki.net/wikis/openupru/
Не смог зайти - ошибка обработки запроса. Захожу через Opera
-
Ну так зайди FF или хотя бы IE.
-
Попытался начать перевод. Как и сказано начал с требований.
Еле зашел, и причем так до сих пор не могу понять как на первую страницу дисциплины, кое-что поменял. Тормоза страшные. Хотел посмотреть результат - версию вижу, но как ее посмотреть не сумел понять.
Нужен ликбез :)
-
Нужен либез :)
Осторжнее с высказываниями :)
-
Осторжнее с высказываниями :)
А что, что-то криминальное? Я отвечаю за себя, а не за всех.....
-
да в слове ошибка, и получилось как-то не прилично :)
-
Какте-то косяки с логином - не могу зайти.
-
Какте-то косяки с логином - не могу зайти.
Однако зашел:-)) Просьба такие вопросы решать в разделе поговорить или лично обращаться к имярек! :)
-
Какте-то косяки с логином - не могу зайти.
Ой стоп, Саша я наверное Васч не так понял, вы на ресурс не можете зайти? Вы знаете у меня тоже не получилось чрез оперу, но в других браузерах захожу, но тормоза страшные - даже переводить не знаю как, и не очень понятно кто же окончательный русский вариант утверждать будет?
-
Да, пытаюсь зайти на ресурс с IE - все время пишет - неверное сочетание логина и пароля.
пароль высылает исправно, но зайти не могу все равно
-
Да, пытаюсь зайти на ресурс с IE - все время пишет - неверное сочетание логина и пароля.
пароль высылает исправно, но зайти не могу все равно
А через фаерфокс как у Вас, Саша? у меня вроде нормально. Только такие тормоза просто ужас, веротяно откажусь от перевода, не возможно работать...
-
Господа участники, хотелось бы определиться с переводом различных тербований
Stakeholder - я перевожу как заинтересованное лицо, можно участник
Work Items List - я перевожу как список работ (вариант список назначений, список элементов работ)
Capture - сильно зависит от контекста, но в целом включить в, создать, собрать-определить.
-
Ну и тяжела же софтина ..
Набросал перевод "Core Principles" если кто знает как сделать обновление всех линков просьба подсказать
p.s. Предлагаю потихоньку согласовывать перевод терминов Мои предложения:
development team - разработчики
quality assurance - инженеры по качеству
product stakeholders заинтересованные лица продукта
customers - Пользователи
-
Ну и тяжела же софтина ..
Не то слово
Набросал перевод "Core Principles" если кто знает как сделать обновление всех линков просьба подсказать
то же интересует эта проблема
p.s. Предлагаю потихоньку согласовывать перевод терминов
думаю, это надо сделать прежде всего
Мои предложения:
development team - разработчики
я перевожу как команда разработчиков
quality assurance - инженеры по качеству
вообще-тот дословно гарантия качества, но нужно смотреть по контексту
product stakeholders заинтересованные лица продукта
не совсем понятно, надо смотреть контекст
customers - Пользователи
лучше клиенты, или покупатель; заказчик; потребитель; субъект наконец
поскольку user - пользователь
-
development team - разработчики
я перевожу как команда разработчиков
development team - команда разработчиков
quality assurance - инженеры по качеству
вообще-тот дословно гарантия качества, но нужно смотреть по контексту
quality assurance - контроль качества,
QA engeneer - инженер (специалист) по качеству
product stakeholders заинтересованные лица продукта
не совсем понятно, надо смотреть контекст
stakeholders - заинтересованные лица
product stakeholders - заинтересованные лица в создании продукта
customers - Пользователи
лучше клиенты, или покупатель; заказчик; потребитель; субъект наконец
поскольку user - пользователь
customers - клиенты или заказчик
-
Братцы давайте действовать более серьезно.
На ресурсе берем глоссарий - и его переводим. Я уже пропустил через PROMT - надо сказать получилось в целом не плохо.
Ну и дальше просто правим его.
Может Bas поместим это в hydraproject?
-
Может Bas поместим это в hydraproject?
Давай
-
Здесь глоссарий, возможно не весь, либо не полный. Использовал свою локальную версию. Нуждается в доработке.
Предлагаю действовать так:
выдираем спорный или редактируемый термин(английский и русский варианты) и предоставляем вариант перевода для обсуждения.
Утвержденый перевод помещаем в репозиторий - т.е. в Excel-файл.
-
На счет "не плохо получилось", это была хорошая шутка. Чего только стоят такие перлы :
испытатель Роль, представляющая кого - то ответственного за основные действия испытательного усилия. tester
возможности{контекст} Описание широты поведения системы, определяя границы прикладного домена{области} или системы. scope
депозитарий спорного имущества Индивидуум, который является, кого существенно затрагивает результат процесса (то есть deliverables процесс, производит). stakeholder
система технического зрения Взгляд пользователя или клиента изделия{программы}, которое будет разработано, определил на уровне ключевых потребностей депозитария спорного имущества и особенностей системы. vision
ИМХО В этом файле Нужно править каждый термин или его определение нормальным литературным переводом с учетом сложившейся Русско-язычной правктики.
p.s. Почему нельзя для этого использовать Wiki ?
-
Ой, господа, PROMTы стразу - в топку. Мы же не на объём переводим, а на качество. ТАм не так много материал, но он должен быть вылизан.
-
Ну напали как коршуны на бедную овечку.
Вот всегда так, инициатива наказуема.
Я первод сделал - сделал, корректировал немного, привел в хорошее редактируемое состояние. Чего вам еще. Давайте работать, а не критику наводить.
Конечно все надо вылизать. Да текста не много, вот я его и скомпилировал. Теперь до ума доводить надо...
У меня и своих дел по горло... Берем делим глоссарий на участников и переводим, потом согласуем
Волки блин :)
-
Ну напали как коршуны на бедную овечку.
....
Во первых сам начал нападать ;-)
А во вторых я так и не поянл почему нельзя переводить Глоссарий в WiKi ? Зачем городить весь этот сыр бор с Excel?
-
Во первых сам начал нападать ;-)
А во вторых я так и не поянл почему нельзя переводить Глоссарий в WiKi ? Зачем городить весь этот сыр бор с Excel?
1 - получить четкое и однозначное понимание треминов
2 - попробуй
3 - я на тебя 1 не нападал, а просто поправил неграмотное написание слова профессор :)
-
1 - получить четкое и однозначное понимание треминов
2 - попробуй
3 - я на тебя 1 не нападал, а просто поправил неграмотное написание слова профессор :)
Не тем занимаемся :-)
1. Мечты но попробовать можно , за идею начать перевод с глоссария я двумя руками за :-)
2. Тупит но ехать можно.
3. Под нападением я понимал не профессора , а предложение сделать все по взрослому ,
А в проффесоре виноват один человек у которого был такой ник и его приходилось часто писать :-) Так что теперь пальцы иногда вворачивают выражение :-).
-
Не тем занимаемся :-)
1. Мечты но попробовать можно , за идею начать перевод с глоссария я двумя руками за :-)
2. Тупит но ехать можно.
3. Под нападением я понимал не профессора , а предложение сделать все по взрослому ,
А в проффесоре виноват один человек у которого был такой ник и его приходилось часто писать :-) Так что теперь пальцы иногда вворачивают выражение :-).
У меня почему-то этот ресурс совсем не работает через ИЕ еще кое-как захожу, через другие браузере уже не могу. Кривой ресурс и сильно кривой. Вот кстати это часто так бывает у больших умниц и умников от ИТ :)
-
Здравствуйте всем. Я студент Тюменского гос. университета и делаю щас курсовую как раз по вашей теме. Может кто нить может дать ссылку, где можно найти краткое, но емкое описание того, в чем собственно заключается методолгоия OpenUp/Basic и ее преимущества перед остальными.
-
Здравствуйте всем. Я студент Тюменского гос. университета и делаю щас курсовую как раз по вашей теме. Может кто нить может дать ссылку, где можно найти краткое, но емкое описание того, в чем собственно заключается методолгоия OpenUp/Basic и ее преимущества перед остальными.
Дык в первую очередь welcome to http://www.epfwiki.net/wikis/openupru/
-
Граждане переводчики, что у вас с переводом OpenUp? Угас трудовой энтузиазизм, разбежались по отпускам или каждый втихую сидит переводит Глоссарий? :)
Я случайно наткнулся на ваш форум в поисках информации об OpenUp. По-моему, дело вы затеяли архиважное и архинужное! Я сам попытался кое-что поредактировать на http://www.epfwiki.net/wikis/openupru и, естетственно, первый же вывод, к которому я пришёл независимо от все ;) : необходим однозначный русскоязычный перевод терминов.
Для этого я даже вставил специальную страничку по примеру наших испанских и португальских коллег, которая пока девственно чиста:
http://www.epfwiki.net/wikis/openupru/openup_basic/customcategories/english__russian_dictionary.html
Я понимаю, что уже существует более-менее устоявшаяся терминология, созданная переводчиками и консультантами по внедрению RUP. Но, во-первых, многие переведенные "в лоб" анлоязычные термины до сих пор не воспринимаются из-за своей корявости, а во-вторых, OpenUp - это ведь не RUP, а гораздо лучше, чем RUP? ;)
Не знаю, вернётся ли кто-нибудь когда-нибудь в эту ветку, но пока попробую здесь порезвиться, обсуждая основные термины сам с собой.
Итак...
-
activity - слово "деятельность" вряд ли подходит хотя бы по той причине, что в русском языке для него нет множественного числа (activities). То же относится к "активности". Может, "действие"? Тогда Activity Diagram получится "Диаграма действий" - коряво как-то. imho, наиболее точный из "прямых" переводов - "вид деятельности". Это, конечно, не очень хорошо делать при переводе из одного слова два, зато полученное сочетание довольно точно передаёт суть термина, легко склоняется и встраивается в другие словосочетания (диаграмма видов деятельности).
Может, "работа"? Или "вид работы"? Тогда роли будут характеризоваться выполняемыми видами работ, соответствующая диаграмма будет называться "диаграммой видов работ".
-
actor - Во многих переводах используется слово "актёр" или вообще нерусское "актор". Автор одной из статей пишет следующее:
В различных русскоязычных текстах автору приходилось видеть следующие переводы термина "actor": актор, актер, актант, агент, субъект, пользователь. Так как все они либо неблагозвучны, либо неточны, за неимением лучшего далее по тексту будем пользоваться переводом, наиболее близким к транскрипции.
http://www.intuit.ru/department/itmngt/analisis/8/analisis_8.html (http://www.intuit.ru/department/itmngt/analisis/8/analisis_8.html)
Лично мне всё-таки больше нравится "пользователь". По-моему, логично описывать "вариант использования" с точки зрения "пользователя", пусть даже это и не человек. Тем более что слово user в английском варианте глоссария не зарезервировано.
Ещё вариант - "потребитель".
-
Не знаю на счет того, а правильно ли обсуждать эти термины в это ветке, т.к. они относятся не только к OUP. Вообще термины у нас обсуждаются здесь:
http://www.uml2.ru/forum/index.php?board=24.0
На счет терминов:
1. activity - это действие, ничего зазорного в ДД нет:
http://www.uml2.ru/forum/index.php?topic=144.0
2. actor - действующее лицо
-
поддерживаю ... actor = действующее лицо.
-
Я даже не ожидал, здесь так много народу. :) Спасибо всем, кто откликнулся.
В настоящее время меня мучает вот такой вопрос: в чем различие между Work Product и Artifact применительно к модели OpenUp?
Слово "артефакт" в литературе встречается довольно часто, и, наверное, его так и можно использовать (хотя лично мне оно тоже не нравится). Это какой-то осязаемый результат целенаправленной деятельности. Но глоссарий OpenUp объявляет множество artifacts подмножеством work rpoducts, которые, в свою очередь, являются подмножеством content elements. При это глоссарий просто ссылается на нечто, обзываемое UMA.
Я сразу признаюсь: мой уровень теоретических знаний в области моделирования, наверное, чуть выше чем "профан", но пока ещё бесконечно далёк до "специалист". Я догадываюсь, что многоуровневая классификация нужна, скорее всего, для представления разных точек зрения на процесс разраработки, помимо практической технарской.
Трудность моя вот в чём: при попытке перевода фраз, включающих work products, я не могу найти более адекватного термина, чем "артефакты" (и я заметил, что это не только моя проблема).
Если work products это более широкое понятие, чем artifacts, то что ещё, помимо артефактов, входит в work products? Насколько существенна эта иерархия для OpenUp? И если не существенна, стоит ли тащить всё это многообразие терминов в перевод, или стоит махнуть разок бритвой Окамма и отсечь ненужные (в данной конкретной модели) сущности?
Или при этом пострадает расширяемость модели?
-
По сути Work Product и Artifact - это одно и тоже ИМХО.
Но есть неуловимое различие, как во многих англоязычных терминах:
Work Product - это некий результат деятельности, грубо - заполненный спек
Artifact - некая первоначальная сущность, грубо - шаблон
А нет разницы, п.ч. пишут:
Work Products:
* Supporting Requirements Specification
* Vision
* Use Case
* Glossary
* Use-Case Model
а потом:
Artifact: Supporting Requirements Specification
* This artifact captures system-wide requirements not captured in scenarios or use cases, including requirements on quality attributes and global functional requirements.
-
activity - слово "деятельность" вряд ли подходит хотя бы по той причине, что в русском языке для него нет множественного числа (activities). То же относится к "активности". Может, "действие"? Тогда Activity Diagram получится "Диаграма действий" - коряво как-то. imho, наиболее точный из "прямых" переводов - "вид деятельности". Это, конечно, не очень хорошо делать при переводе из одного слова два, зато полученное сочетание довольно точно передаёт суть термина, легко склоняется и встраивается в другие словосочетания (диаграмма видов деятельности).
Может, "работа"? Или "вид работы"? Тогда роли будут характеризоваться выполняемыми видами работ, соответствующая диаграмма будет называться "диаграммой видов работ".
Перевод activity как действие (action) плохо согласуется с некторыми важными значениями термина activity (да и action также). Словарь Merriam Webster для activity дает (в том числе) такие значения:
3a) a process (as digestion) that an organism carries on or participates in by virtue of being alive
3b) a similar process actually or potentially involving mental function; specifically : an educational procedure designed to stimulate learning by firsthand experience.
Т.е. важно, что понятие activity ассоциируется с проявлениями жизни (физиологии) и/или разумной деятельности человека.
Ср. с значениями action:
3a) the style of movement of the feet and legs (as of a horse)
3c) : a function of the body or one of its parts
7a) : an operating mechanism
7b) : the manner in which a mechanism or instrument operates.
Т.е. значения activity связаны с проявлениями субъектной, связанной с конкретным лицом (actor) практики. В русском языке термин "деятельность" имеет близкое значение (связанное с разумными проявлениями жизни человека), не в последнюю очередь благодаря теории деятельности, активно развивавшейся в отечественной школе психологии. А для action более логичным представляется оставить значение, асооцированное скорее с автоматическими (и/или бессознательными) движениями, и переводить как действие .
А множественное число activities вполне можно перевести как "виды деятельности" . Диаграмму Activity diagram можно перевести как "Диаграмму деятельности" (множественное число не потребуется).
-
.....
Трудность моя вот в чём: при попытке перевода фраз, включающих work products, я не могу найти более адекватного термина, чем "артефакты" (и я заметил, что это не только моя проблема).
Если work products это более широкое понятие, чем artifacts, то что ещё, помимо артефактов, входит в work products? Насколько существенна эта иерархия для OpenUp? И если не существенна, стоит ли тащить всё это многообразие терминов в перевод, или стоит махнуть разок бритвой Окамма и отсечь ненужные (в данной конкретной модели) сущности?
Или при этом пострадает расширяемость модели?
ИМХО "work products" можно перевести как "результат(ы) деятельности". Артефакт хотя и является результатом деятельности, но деятельности не обязательно рассматриваемой (проектируемой).
Например, в UML artifact- A physical piece of information that is used or produced by a development process etc. Т.е. артефакт может быть не только результатом деятельности, но и средством достижения этого результата.
-
Вообще-то слово "артефакт" мне, наверное, тоже придётся категорически отвергнуть.
Сейчас передо мной стоит конкретная задача. Есть команда разработчиков из шести человек, плюс два человека сэйлз+маркетинг, сидящие в соседней комнате. Мне нужно улучшить существующие процессы разработки, и за основу я бы взял OpenUp, потому что, судя по описанию, он как раз на такие команды и ориентирован (небольшие, с тесным и открытым внутрикомандным взаимодействием). И мне кажется, мой случай довольно массовый.
У программистов по пятнадцать-двадцать лет опыта работы. UML они не знают (в то время, когда они учились, такого слова ещё не было, а реальной необходимости его изучения не возникало). Со словами вроде RUP или XP не знакомы. Отправить всю команду скопом на обучение только для того, чтобы они поняли основные термины - дешевле самораспуститься.
Но базовые подходы всё-таки нужно внедрять, объясняя их людям постепенно, на простом русском языке, используя интуитивно понятные термины. Если я вдруг заговорю об "артефактах", мнение программистов будет однозначным: "Гриша опять начитался книжек о модных концепциях в программировании". :)
Поэтому слова "артефакт" при описании внутренних процедур я буду избегать, а вместо этого буду использовать что-то вроде "документ" (используется в настоящее время) или "продукт" (согласие есть продукт при полном непротивлении сторон).
Вопрос состоит в том, насколько перевод OpenUp должен быть приближен к реальной жизни - должна быть это "академическая" модель или готовое к внедрению "руководство к действию", простое и эффективное, как автомат Калашникова?
-
Поэтому слова "артефакт" при описании внутренних процедур я буду избегать, а вместо этого буду использовать что-то вроде "документ" (используется в настоящее время) или "продукт" (согласие есть продукт при полном непротивлении сторон).
Это не правильно. Артефакт - это не продукт как таковой, и не только документ.
-
Это не правильно. Артефакт - это не продукт как таковой, и не только документ.
Поэтому я и пытаюсь найти адекватный, интуитивно понятный русский термин. Слово "документ" в расширенном смысле, вроде бы, разработчиками сейчас воспринимается нормально (вот сказал и задумался: а действительно ли нормально?) По крайней мере, формулировки вроде "выходным документом является исходный код" не вызывает вопросов.
Кстати, в OpenUp я не нашёл явного перечня артефактов. Есть перечень Work Product Kinds, в котором описание некоторых объектов начинается со слов "This artifact...", а в описании некоторых других слово artifact отсутствует.
-
Работы по переводу OpenUP заморожены, т.к. в английской версии происходило слишком много изменений. Например, они отказались от постфикса Basic в названии, переименовали Analysis & Design в Architecture и т.д. Переводить стоит только тогда, когда более-менее утрясутся основные вещи.
А вот словарь вполне можно делать уже сейчас, т.к. он нужен в отрасли, а не только в рамках OpenUP.
greesha, рекомендую посмотреть книги по OpenUP на pdfchm.com
artifact или work product я бы перевёл как "результаты работ".
Предлагаю результаты перевода фиксировать в вики: http://chernoviki.ru/index.php/OpenUP_Dictionary
-
Работы по переводу OpenUP заморожены, т.к. в английской версии происходило слишком много изменений. Например, они отказались от постфикса Basic в названии, переименовали Analysis & Design в Architecture и т.д. Переводить стоит только тогда, когда более-менее утрясутся основные вещи.
А вот словарь вполне можно делать уже сейчас, т.к. он нужен в отрасли, а не только в рамках OpenUP.
Жаль. :( Дело в том, что я уже фактически предпринял попытку внедрить OpenUp в наших разработках. Так что для себя перевод я всё равно буду делать, потому что это лучший способ детально разобраться в каждом абзаце. Но то, что получится на выходе, наверное, уже не сможет называться OpenUp.
В любом случае, возможно, и мои Work Products кому-нибудь пригодятся, так что на chernoviki буду заглядывать. :)
greesha, рекомендую посмотреть книги по OpenUP на pdfchm.com
Спасибо. Сейчас у меня дома лежит стопка книг, а на компьютере целый каталог pdf-ников на русском языке, которые я не успеваю читать. Может, и до английских оригиналов когда-нибудь дело дойдёт.
-
Предлагаю результаты перевода фиксировать в вики: 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?
-
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 в контексте жизненного цикла можно перевести как:
- фаза
- этап
- стадия
Это типовые варианты, по словарю. Можно также придумать более-менее оригинальные: эпоха, эра, перегон и т. п.
В литературе встречаются все типовые варианты. Более того, в некоторых книгах сначала даётся определение фазы в модели жизненного цикла, а потом в каждой главе упорно используется слово стадия.
ГОСТ же разбивает жизненный цикл на этапы (по крайней мере, так отложилось у меня в памяти).
Для того, чтобы остановиться на каком-то варианте, нужно определиться, для кого предназначен перевод и как он будет использоваться (по крайней мере, такой вопрос должен задать себе настоящий аналитик ;D).
В "целевую аудиторию", как мне представляется, входят:
- команды разработчиков и менеджеры проектов, которые будут использовать OpenUp на практике;
- консультанты, специализирующиеся на внедрении технологий разработки программных проектов;
- наиболее прогрессивные преподаватели ВУЗов, стремящиеся дать своим студентам представление о современных методах разработки ;)
- кто-то ещё, о ком я забыл...
Для разных подгрупп аудитории могут быть по-разному определены приоритеты принципов перевода:
- соответствие русскоязычным стандартам (используем по возможности ГОСТовское определение "этап")
- близость перевода к английскому оригиналу (любой ребёнок скажет вам, что phase - это "фаза")
- интуитивная понятность термина ("этап" - это что-то монументальное, а "фаза" - это часть короткого периода)
- оригинальность перевода, отличающая данную методологию от десятков других (если мы разобьём жизненный цикл на "эпохи", это, возможно, запомнится).
Последний вариант может показаться надуманным, но у меня сложилось впечатление, что разработчики OpenUp ипользовали этот подход для некоторых терминов. Возможно, из каких-то маркетинговых соображений (как говорят некоторые консультанты, "SCRUM легче продать, потому что слово прикольное").
Чтобы продолжить работу над переводом, нужно, прежде всего, определиться с этими приоритетами.
-
Отличный анализ.
Однако давайте посмотрим на понятие фаза с другой стороны.
Ни для кого не является секретом, что современное представление о технологии разработки проекта основывается на его цикличности.
Для цикличности больше подходит понятие фаза. Вспомнив физику и различные фазы и фазовые превращения вещества, явно подразумевающие определенную цикличность.
Этап и стадия скроее подходят к некоторой восходящей последовательности. Хотя, конечно, вполне можно сказать фаза развития, стадия развития, этап развития - и смысл вряд ли теряется.
Однако поскольку так сложилось, что терминология ИТ изобретается в первую очередь англоговорящей частью мира, имеет смысл переводить термины наиболее близко к их звучанию и написанию везде, где это возможно. В конце концов и все русскоговорящие разработчики активно используют англоподобный сленг: фича, валью, юзкейс, юзабилити. Потому например фаза будет лучше восприниматься, так как она имеет точный аналог и в родном тексте.
Для трассировки можно давать переводы с пометкой ГОСТ или тому подобное
-
Слово phase я привёл только в качестве примера. В литературе по управлению проектами используются все типовые варианты, причём часто в одной и той же книге - и ничего, всё вполне понятно.
По моим ассоциациям, слово "этап" можно было бы применять ко всему жизненному циклу, а "фаза" - к соответствующим шагам внтури итерации.
Но дело не в этом. Чтобы продолжить перевод, надо определить приоритетность принципов, о которых я сказал ниже. Иначе придётся долго обсуждать каждый неоднозначный термин, выбирать варианты, скажем, голосованием, но в результате перевод может утратить целостность.
Очень важно определить эти принципы в самом начале, при формировании глоссария.
Поразмыслив немного, для этапа (фазы ;)) перевода глоссария я предлагую расстановку приоритетов:
1) Близость к англоязычному оригиналу - при условии, что соответствующее слово устойчиво используется в русском языке в данном контексте и не может считаться жаргонным (положительные примеры: фаза, роль; отрицательные примеры: чеклист, актор)
2) Склоняемость по правилам русского языка, не забываем о множественном числе (activities - "виды деятельности" уместнее, чем просто "деятельности")
3) Интуитивная понятность (milestone - "веха" лучше, чем дословное "верстовой столб", practice - "подход" обычно уместнее дословного "практика")
4) Соответствие принятым стандартам (если дословный перевод в данном контексте не применим, имеет смысл поискать аналогии в ГОСТах)
5) Оригинальность (имеет смысл, если английский вариант тоже оригинален)
Я думаю, допустимо использовать в переводе глоссария перечисление нескольких равноправных вариантов, которые могут использовться в зависимости от деталей контекста и построения фразы. Английский язык на русский однозначно не отображается.
Пример: phase - этап, фаза
В общем, вспоминаем классиков:
Cила писателя, на мой взгляд, не в том, чтобы уметь найти единственное верное слово, а в том, чтобы отбросить все заведомо неверные.
http://www.lib.ru/STRUGACKIE/hromaqsudx.txt
-
Согласен, хорошие приоритеты. Так и будем действовать.
Правда помимо слов из глоссария, неплохо бы найти нормальные штампы для некоторых английских слов и словосочетаний.
Например, capture - я переводил по-разному и остановился на переводе фиксировать.
Что-то типа вариант использования фиксирует функциональные требования к системе.
-
Текущее состояние перевода теперь можно посмотреть и без регистрации:
http://www.greesha.ru/openup/index.php?all_translations&none&none
-
Впал в ступор, уже несколько часов не могу найти адекватный русский перевод для слова guidance.
"В UMA guidance служит обобщающим понятием для всех видов контента, назначение которых состоит в разъяснении и толковании других элментов UMA. Поскольку guidance тоже является элементом контента, можно ассоциировать guidance с другим guidance."
Вот такая, понимаш, рекурсивная загогулина.
Проблема в том, что в Глоссарии через него определяется много других терминов, а именно guidance'ами являются:
- example (пример)
- guidline (руководство)
- practice (подход, практика)
- report (отчёт)
- reusable asset (повторно используемый актив)
- roadmap (теперь мне понятно, что за "дорожную карту" перетирают журналисты в новостях с Ближнего Востока)
- supporting material (это вообще прелесть - a guidance that is a catch-all for other types of guidance)
- template (шаблон)
- term definition (определение термина)
- tool mentor (руководство по использованию, наставление)
- white paper (публикация)
Как всё это объединить одним словом? Может, кто подскажет?
Или нужно искать пути полного отказа от ссылок на UMA - пусть сами разбираются со своими абстракциями и рекурсиями.
-
с технической точки зрения это слово переводится как наведение, во всех остальных случаях - это руководство.
Наверное не стоит заморачиваться и оставить именно как руководство с использованию (рекомендации по использованию)
-
Multilex
guideline ['gaIdlaIn] n
1. полит. директива, руководящее указание
2. установка, принцип
to lay down the guidelines — установить принципы; определить основное направление, курс
3. pl руководство; нормы
radiation protection guidelines — а) руководство по радиационной защите; б) нормы радиационной защиты
4. спец. контрольная линия, метка
фактический синоним, но скорее как инструкция а не как рекомендация, хотя корень один
guide I [gaId] n
1. проводник; гид; экскурсовод
museum guide — музейный гид, экскурсовод
trustworthy [experienced] guide — надёжный [опытный] проводник
to take [to hire /to engage/] a guide — брать [нанимать] проводника
to serve smb. as a guide — быть чьим-л. гидом /проводником/
2. руководящий принцип
to take reason as one's guide — руководствоваться соображениями рассудка
if this is any guide — если этим можно руководствоваться
instinct is not always a safe guide — не всегда можно руководствоваться инстинктом
whim and prejudice are poor guides — прихоти и предрассудки — плохие советчики
3. ориентир, указатель
it was a guide to the state of his feelings — поэтому (признаку) можно было судить о его чувствах /о его состоянии/
as a rough guide — грубо ориентировочно
4. 1) руководитель; советчик
to trust [to confide in, to obey] one's guide — верить [доверять, повиноваться] руководителю
2) образец, пример
I took him as my guide — я старался во всём подражать ему
let this be a guide to you — пусть это служит вам примером
3) редк. опекун
5. 1) путеводитель; руководство, учебник; инструкция
a Guide to the British Museum — путеводитель по Британскому музею
a Guide to English Grammar — учебник английской грамматики
guide to poultry keeping — руководство по птицеводству
radiation protection guide — руководство по радиационной защите
railway guide — железнодорожный указатель
guide to photography — справочник по фотографии, справочник фотографа
2) pl нормы
radioactivity concentration guides — нормы допустимой концентрации радиоактивных веществ
-
Предлагаю результаты перевода фиксировать в вики: http://chernoviki.ru/index.php/OpenUP_Dictionary
Объясните тупому, как в chernoviki создать новую страницу? Хотел поместить туда перевод "Введение в UMA" и прикрутить к нему ссылку со страницы OpenUP_Dictionary. Я пытался сделать это через "руководство", но оно незаметно перебросило меня на wikimedia.org, с которого моя страница была немедленно удалена модератором с пометкой offtopic.
-
Промежуточные итоги работы.
Повозившись с терминами глоссария, я понял, что отказаться от ссылок на UMA всё же не получится. Хоть эта модель ещё и не опубликована, OpenUp построен в полном соответствии с её идеологией. А работать c EPF без понимания ключевых моментов UMA вообще невозможно.
Поэтому я потратил несколько часов на перевод страницы "Введение в UMA".
http://www.epfwiki.net/wikis/openuppt/base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html
При этом мне очень пригодилась статья по RUP (сюрприз, да? :) ), из которой я нагло позаимствовал некоторые термины:
http://www.interface.ru/home.asp?artId=1524
Я бы с удовольствием разместил промежуточные результаты на chernoviki.ru, но не осилил движок. Всё, что я могу сделать - это изменение уже существующих страниц. Никаких ссылок на создание страниц я там не обнаружил (точнее, обнаружил одну, но она создаёт страницы на совсем другом сервере). Это так задумано, или я просто отстал от жизни и не врубаюсь в модные современные концепции пользовательского интерфейса? ;)
-
Я бы с удовольствием разместил промежуточные результаты на chernoviki.ru, но не осилил движок. Всё, что я могу сделать - это изменение уже существующих страниц. Никаких ссылок на создание страниц я там не обнаружил (точнее, обнаружил одну, но она создаёт страницы на совсем другом сервере). Это так задумано, или я просто отстал от жизни и не врубаюсь в модные современные концепции пользовательского интерфейса? ;)
Этот движок называется MediaWiki и на нём работает Википедия.
Создать новую страницу можно следующими способами:
1) Добавив в адресной строке в корневому узлу название статьи после index.php/
2) Вбив название статьи в поиск.
3) Создав ссылку на статью с таким названием, сохранив статью и щёлкнув для перехода по созданной ссылке.
Во всех случаях, если страница не существует, система предлагает её создать.
-
Этот движок называется MediaWiki и на нём работает Википедия.
Создать новую страницу можно следующими способами:
1) Добавив в адресной строке в корневому узлу название статьи после index.php/
2) Вбив название статьи в поиск.
3) Создав ссылку на статью с таким названием, сохранив статью и щёлкнув для перехода по созданной ссылке.
Во всех случаях, если страница не существует, система предлагает её создать.
А, точно! Я же с этим уже как-то бился, но найденный способ не отложился в моей дырявой памяти.
Спасибо за подсказку. Статью создал и ссылку на неё разместил.
-
Статья "OpenUp - это просто" на it4business. На русском языке.
http://it4business.ru/articles/1296/#more-1296
Сам ещё не читал, времени пока нет.
-
Прочитал статью "OpenUp - это просто".
Если судить только по этой статье, мы таки используем OpenUp. :)
Но надо бы разобраться поподробнее с Work Products и артефактами. Какие-то они расплывчатые.
Забыл, кстати, что в Опере EPF Wiki по-прежнему не открывается. Но всё-таки... трафик 320 килобайт только для того, чтобы отобразить пару строк о неопознанной ошибке? ИМХО, зажрались они там в своих америках! :)