Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
1216
Насколько я понял, основное преимущество wiki - возможность удалённого участия в разработке требований, которые при этом автоматически документируются. Это замечательно, если заказчики и прочие заинтересованные лица готовы к такому сотрудничеству.

Для каскадной разработки, если есть длинный этап сбора требований, завершаемый выходом ТЗ "на скрижалях", всё просто замечательно.

Но даёт ли этот подход какие-то преимущества на этапах, следующих за сбором и уточнением требований? Что получается на выходе, кроме красиво отформатированного документа в пресловутой blue book? При итерационной разработке интересует, в первую очередь, распределение требований по этапам, отслеживание их статуса в процессе разработки, соответствие тестов требованиям (не обязательно матрица трассировки, но хотя бы лекго управляемые списки связей) и т. п.

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

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

Jira рулит.

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

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

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

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

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

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

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

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

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

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

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

1219
О Сайте и Форуме / Re: Анекдоты - в жизнь!
« : 16 Августа 2007, 11:54:10 »
Кстати, на одном из форумов, на котором я бываю часто, используется движок phorum одной из ранних версий. Количество сообщений там недавно перевалило за миллион. Правда, после этого начались глюки со страницей  списка последних тем.

При этом все темы, открытые ещё в 2002 году, ещё вполне доступны через Поиск.

Но там не поддерживаются картинки, аватары, расширенная информация о пользователе и прочие "красивости".

1220
О Сайте и Форуме / Re: Анекдоты - в жизнь!
« : 16 Августа 2007, 11:35:22 »
Полчаса пытался войти в эту ветку, чтобы прочитать ответ. Если заходить через Форум / Обсуждения / О сайте и форуме, эта тема отображается в списке первой, но все связанные с ней ссылки ведут в разные совершенно непредсказуемые места (например при нажатии на название темы я попадаю в окно, в котором предлагается сообщить модератору о чьих-то некорректных высказываниях).

В конце концов удалось зайти через список "Последние сообщения".

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

1221
О Сайте и Форуме / Анекдоты - в жизнь!
« : 15 Августа 2007, 19:40:46 »
Только что при попытке прочитать одну из тем, кликнув по ней из списка "Непрочитанные темы", увидел такое сообщение:

Ошибка!
Не удалось проверить сессию. Пожалуйста, выйдите из форума и зайдите снова.


Сразу вспомнился анекдот:
Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается.
Таксист говорит:
- Давайте мотор смотреть.
Бизнесмен:
- Да ладно, давай тачку поймаем.
Программист:
- А давайте все выйдем и снова войдем, может, она заработает?

:)

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

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

Мистика? ;)

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

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

В компании работает 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? Он, как мне всё ещё кажется, даёт модель, в рамках которой я, по крайней мере, более-менее представляю дальнейшие шаги по определению необходимых этапов и контрольных точек разработки. И эта модель может быть освоена в сравнительно короткий срок на моём уровне, для неё не нужно проходить дополнительное обучение или приглашать специальных консультантов.

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

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

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

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

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

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

1224
Работы по переводу OpenUP заморожены, т.к. в английской версии происходило слишком много изменений. Например, они отказались от постфикса Basic в названии, переименовали Analysis & Design в Architecture и т.д. Переводить стоит только тогда, когда более-менее утрясутся основные вещи.

А вот словарь вполне можно делать уже сейчас, т.к. он нужен в отрасли, а не только в рамках OpenUP.

Жаль. :( Дело в том, что я уже фактически предпринял попытку внедрить OpenUp в наших разработках. Так что для себя перевод я всё равно буду делать, потому что это лучший способ детально разобраться в каждом абзаце. Но то, что получится на выходе, наверное, уже не сможет называться OpenUp.

В любом случае, возможно, и мои Work Products кому-нибудь пригодятся, так что на chernoviki буду заглядывать. :)

greesha, рекомендую посмотреть книги по OpenUP на pdfchm.com

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

1225
Это не правильно. Артефакт - это не продукт как таковой, и не только документ.

Поэтому я и пытаюсь найти адекватный, интуитивно понятный русский термин. Слово "документ" в расширенном смысле, вроде бы, разработчиками сейчас воспринимается нормально (вот сказал и задумался: а действительно ли нормально?) По крайней мере, формулировки вроде "выходным документом является исходный код" не вызывает вопросов.

Кстати, в OpenUp я не нашёл явного перечня артефактов. Есть перечень Work Product Kinds, в котором описание некоторых объектов начинается со слов "This artifact...", а в описании некоторых других слово artifact отсутствует.

1226
Вообще-то слово "артефакт" мне, наверное, тоже придётся категорически отвергнуть.

Сейчас передо мной стоит конкретная задача. Есть команда разработчиков из шести человек, плюс два человека сэйлз+маркетинг, сидящие в соседней комнате. Мне нужно улучшить существующие процессы разработки, и за основу я бы взял OpenUp, потому что, судя по описанию, он как раз на такие команды и ориентирован (небольшие, с тесным и открытым внутрикомандным взаимодействием). И мне кажется, мой случай довольно массовый.

У программистов по пятнадцать-двадцать лет опыта работы. UML они не знают (в то время, когда они учились, такого слова ещё не было, а реальной необходимости его изучения не возникало). Со словами вроде RUP или XP не знакомы. Отправить всю команду скопом на обучение только для того, чтобы они поняли основные термины - дешевле самораспуститься.

Но базовые подходы всё-таки нужно внедрять, объясняя их людям постепенно, на простом русском языке, используя интуитивно понятные термины. Если я вдруг заговорю об "артефактах", мнение программистов будет однозначным: "Гриша опять начитался книжек о модных концепциях в программировании". :)

Поэтому слова "артефакт" при описании внутренних процедур я буду избегать, а вместо этого буду использовать что-то вроде "документ" (используется в настоящее время) или "продукт" (согласие есть продукт при полном непротивлении сторон).

Вопрос состоит в том, насколько перевод OpenUp должен быть приближен к реальной жизни - должна быть это "академическая" модель или готовое к внедрению "руководство к действию", простое и эффективное, как автомат Калашникова?

1227
Я даже не ожидал, здесь так много народу. :) Спасибо всем, кто откликнулся.

В настоящее время меня мучает вот такой вопрос: в чем различие между Work Product и Artifact применительно к модели OpenUp?

Слово "артефакт" в литературе встречается довольно часто, и, наверное, его так и можно использовать (хотя лично мне оно тоже не нравится). Это какой-то осязаемый результат целенаправленной деятельности. Но глоссарий OpenUp объявляет множество artifacts подмножеством work rpoducts, которые, в свою очередь, являются подмножеством content elements. При это глоссарий просто ссылается на нечто, обзываемое UMA.

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

Трудность моя вот в чём: при попытке перевода фраз, включающих work products, я не могу найти более адекватного термина, чем "артефакты" (и я заметил, что это не только моя проблема).

Если work products это более широкое понятие, чем artifacts, то что ещё, помимо артефактов, входит в work products? Насколько существенна эта иерархия для OpenUp? И если не существенна, стоит ли тащить всё это многообразие терминов в перевод, или стоит махнуть разок бритвой Окамма и отсечь ненужные (в данной конкретной модели) сущности?
Или при этом пострадает расширяемость модели?

1228
actor - Во многих переводах используется слово "актёр" или вообще нерусское "актор". Автор одной из статей пишет следующее:

В различных русскоязычных текстах автору приходилось видеть следующие переводы термина "actor": актор, актер, актант, агент, субъект, пользователь. Так как все они либо неблагозвучны, либо неточны, за неимением лучшего далее по тексту будем пользоваться переводом, наиболее близким к транскрипции.
http://www.intuit.ru/department/itmngt/analisis/8/analisis_8.html

Лично мне всё-таки больше нравится "пользователь". По-моему, логично описывать "вариант использования" с точки зрения "пользователя", пусть даже это и не человек. Тем более что слово user в английском варианте глоссария не зарезервировано.

Ещё вариант - "потребитель".

1229
activity - слово "деятельность" вряд ли подходит хотя бы по той причине, что в русском языке для него нет множественного числа (activities). То же относится к "активности". Может, "действие"? Тогда Activity Diagram получится "Диаграма действий" - коряво как-то. imho, наиболее точный из "прямых" переводов - "вид деятельности". Это, конечно, не очень хорошо делать при переводе из одного слова два, зато полученное сочетание довольно точно передаёт суть термина, легко склоняется и встраивается в другие словосочетания (диаграмма видов деятельности).
Может, "работа"? Или "вид работы"? Тогда роли будут характеризоваться выполняемыми видами работ, соответствующая диаграмма будет называться "диаграммой видов работ".

1230
Граждане переводчики, что у вас с переводом 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? ;)


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

Итак...


Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82