Коллеги разработчики, я уже видела где-то тему про это, но еще раз можно - как у вас реализован багтрекинг под Lotus? Можно заодно про систему контроля версий
А TeamStudio чем может помочь? А с гитом идея мне вообще не нравится - хранить совершенно внутреннюю информацию где-то вдали.... не айс, да и за платные аккаунты никто платить не будет.
Про JIRA у меня тягостные воспоминания. Стоит ли, помимо эклипса, еще одного монстра держать?
Про JIRA у меня тягостные воспоминания. Стоит ли, помимо эклипса, еще одного монстра держать?
- 27.08.2008
- 7 928
- 586
не понял - причем здесь гитхаб? git - программа, кот. никак не связана с хостингом
можете и весь список проверить
Ссылка скрыта от гостей
все зависит от требований, может оказаться что проще свою написать
- 27.08.2008
- 7 928
- 586
о... нашлася тема (в общих) https://codeby.net/threads/32734/
в вики
сведения там не актуальные, но понять масштаб выбора можно
в вики
Ссылка скрыта от гостей
сведения там не актуальные, но понять масштаб выбора можно
Последнее редактирование модератором:
да, точно, именно этот пост и искала. однако, три года прошло, ничего нового не изобрели?
1. VladSh обрисовывает отличную модель, однако, там, как мне кажется, проприетарное ПО пишется на лотусе и никто не станет делиться импортерами-экспортерами, и уж, тем более, вряд ли поможет адаптировать их по себе. Для команд типа "человек-оркестр" тоже не подойдет, а у нас примерно так - полтора землекопа.
2. Легко ли "выкусить" из dxl все лишнее, чтобы подпихивать svn? легко?
3. Не пытался ли кто-нибудь строить багтрекинг на самом лотусе - в принципе, все средства командной разработки есть, источник тасков и багов в нем уже есть..
4. И у меня крамольная мысль (я так шепотом скажу) - а никто не пытался на лотусе строить систему управления требованиями? а то понапишут разных ТЗ, сиди анализируй, что с чем стыкуется и откуда взялася воооон та кнопочка?
1. VladSh обрисовывает отличную модель, однако, там, как мне кажется, проприетарное ПО пишется на лотусе и никто не станет делиться импортерами-экспортерами, и уж, тем более, вряд ли поможет адаптировать их по себе. Для команд типа "человек-оркестр" тоже не подойдет, а у нас примерно так - полтора землекопа.
2. Легко ли "выкусить" из dxl все лишнее, чтобы подпихивать svn? легко?
3. Не пытался ли кто-нибудь строить багтрекинг на самом лотусе - в принципе, все средства командной разработки есть, источник тасков и багов в нем уже есть..
4. И у меня крамольная мысль (я так шепотом скажу) - а никто не пытался на лотусе строить систему управления требованиями? а то понапишут разных ТЗ, сиди анализируй, что с чем стыкуется и откуда взялася воооон та кнопочка?
Последнее редактирование:
- 27.08.2008
- 7 928
- 586
легко, только надо знать - что хчется на выходе
то что видел мне не нравилось
сотрудничал с 2-мя компаниями ведущими разработку под ЛДН - ни в одной не встречал ТЗ адаптированное под ЛДН
причина понятна - те кто ч-л хочет - не знает нотусни, а те кто знает - не обладает достаточным временем переписывать "этот бред"
выше указал полный стэк (правда платный) для все-и-сра, причем используется людьми в гетерогенных средах/платформах - чем не устраивает?
У нас нормальной не было, когда-то для облегчения разработки была бд с общими элементами и тимстудия (CIAO) на 6-7й версиях домино, потом был "самопал": бд с выгруженным dxl для общих элементов с поддержкой версионности (в основном либы и агенты)+ плагин для дизайнера коллеги делали, при сборке автоматическая раздача на рабочие бд и вручную компиляция, затем автоматизированное получение шаблонов - лучше, чем вообще ничего... мож, еще полгода-годик и дорастут до нормальных систем.
В компании, в которой Влад работал, насколько интересовалась, сейчас лотус-направление особо не развивается, там вроде свой какой-то конвертер или что-то подобное. Вот еще описание среды разработки от другого экс-коллеги:
Ссылка скрыта от гостей
Это к вопросу о велосипедах))) Чем так не устраивает jira, вроде ж она вполне расширяема? Писали такой в одной из компаний несколько лет назад, не сложно, в принципе, вполне можно использовать для небольших локальных и распределенных команд. Нашу систему использовали на протяжении нескольких лет, в целом неплохо - для меня интересный опыт, но лично я не вижу особых перспектив развития при таком разнообразии багтрекинговых систем (с учетом возможности "допиливания" большинства из них).
Если отдаете на аутсорс, могу взяться
если нет - ниже вот кусочек из опыта.Если бы сейчас писала подобное, то это были бы либо икспейджи+домино, либо джаваскрипт, джава(шарп) + реляционка.
Написали, так как надо было на заре развития компании при ограниченном кол-ве денежных ресурсов максимально быстро организовать работу небольшой команды (2-3 разработчика, 2 тестировщика, аналитик, ПМ+техпис, саппорт) и преемственность разработки продукта.
Из задач, требований и проблем, с которыми сталкивались в начале работы (6-10 пользователей):
- понять бизнес-процесс - первичный анализ текущего и желаемого процесса работы с проектами, ошибками и требованиями (была предоставлена схема+пояснения, проблем почти не было, одна из самых хорошо представленных задач для разработки),
- импорт текущих ошибок в систему на начальном этапе разработки (экспорт из предыдущего багтрекера ClearQuest),
- уникальная последовательная нумерация в распределенной среде, нотификация,
контроль версий, поддержка одновременной работы над несколькими проектами,
отчетность и экспорт, поиск и отбор.
- недостаточность существующей отчетности для специалистов техподдержки и менеджеров (доделывали отчетность, поиск, новые вьюхи).
В дальнейшем с масштабированием на десятки пользователей в распределенной среде (распределенная команда, 2-3 часовых пояса) проблемы вызывало отсутствие необходимых нотификаций и веб-интерфейса (писалось под 7й лотус, тогда не стали заморачиваться с вебом, нотификация изначально была, но потом то убирали, то добавляли), необходимость обучения пользователей (не было нормальной документации и сценариев (стандартов) работы с системой - например, в связи с увеличением кол-ва багов в системе из-за небрежного их оформления и лени тестировщиков началось массовое дублирование дефектов), иногда не хватало полной истории редактирования описаний ошибок. По необходимости в дальнейшем доделывалось связывание, настройки, поиск, отчетность (в т.ч. по трудозатратам), аналитика, меняли немного бизнес-процесс. Прикручивала позже ради обучения веб на икспейджах - пожалела, что в свое время описание вместо текстового поля по просьбе тест-аналитика сделали простым рт-полем (надо было хоть рт-лайт) - туда ушлые тестеры скриншоты тыкали, очень неудобно было отображать.
На текущий момент одна компания, использовавшая систему, вроде приостановила работу, другая, я думаю, рано или поздно окончательно перейдет на jira.
Написали, так как надо было на заре развития компании при ограниченном кол-ве денежных ресурсов максимально быстро организовать работу небольшой команды (2-3 разработчика, 2 тестировщика, аналитик, ПМ+техпис, саппорт) и преемственность разработки продукта.
Из задач, требований и проблем, с которыми сталкивались в начале работы (6-10 пользователей):
- понять бизнес-процесс - первичный анализ текущего и желаемого процесса работы с проектами, ошибками и требованиями (была предоставлена схема+пояснения, проблем почти не было, одна из самых хорошо представленных задач для разработки),
- импорт текущих ошибок в систему на начальном этапе разработки (экспорт из предыдущего багтрекера ClearQuest),
- уникальная последовательная нумерация в распределенной среде, нотификация,
контроль версий, поддержка одновременной работы над несколькими проектами,
отчетность и экспорт, поиск и отбор.
- недостаточность существующей отчетности для специалистов техподдержки и менеджеров (доделывали отчетность, поиск, новые вьюхи).
В дальнейшем с масштабированием на десятки пользователей в распределенной среде (распределенная команда, 2-3 часовых пояса) проблемы вызывало отсутствие необходимых нотификаций и веб-интерфейса (писалось под 7й лотус, тогда не стали заморачиваться с вебом, нотификация изначально была, но потом то убирали, то добавляли), необходимость обучения пользователей (не было нормальной документации и сценариев (стандартов) работы с системой - например, в связи с увеличением кол-ва багов в системе из-за небрежного их оформления и лени тестировщиков началось массовое дублирование дефектов), иногда не хватало полной истории редактирования описаний ошибок. По необходимости в дальнейшем доделывалось связывание, настройки, поиск, отчетность (в т.ч. по трудозатратам), аналитика, меняли немного бизнес-процесс. Прикручивала позже ради обучения веб на икспейджах - пожалела, что в свое время описание вместо текстового поля по просьбе тест-аналитика сделали простым рт-полем (надо было хоть рт-лайт) - туда ушлые тестеры скриншоты тыкали, очень неудобно было отображать.
На текущий момент одна компания, использовавшая систему, вроде приостановила работу, другая, я думаю, рано или поздно окончательно перейдет на jira.
А мне повезло больше - встречала вполне нормальные тз. Правда, такие задачи обычно ставили либо менеджеры, вышедшие из тех. спецов и знающие платформу, либо "специально обученные девочки-аналитики" после консультации опять же тех.специалистов-конструкторов - но это специфика разработки в довольно крупной софтверной компании. В общем, либо самому приходится что-то придумывать (создавать прототипы, изучать аналитику, напрямую общаться с заказчиком и уточнять требования), либо поднимать перед ответственными за проект данную проблему в том ракурсе, что некачественное тз создает проблемы и приводит к избыточным затратам (иногда помогает выделить одного ответственного за качество проектной документации, иногда вводить стандарты и образовывать "специально обученных" - самые вменяемые достигают хороших результатов через несколько месяцев, остальные максимум через год-два либо уходят, либо тоже уже вполне адекватные тз готовят).
Последнее редактирование:
- 27.08.2008
- 7 928
- 586
Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab
Похожие темы
