Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Requirements management tools

Посоветуйте tool, с помощью которого удобно управлять требованиями к проекту. Чтобы там хранить все требования, документы, диаграммы, желательно с версионированием, присвоением тегов требованиям, с возможностью разбить на важные и неважные, на «релиз 1» и «релиз 2» например. Поиск в google выдал кучу софта, половина из которого выглядит, как будто он из прошлого века.

Только это не должна быть Jira, потому что требования — это одно, а tasks — это другое. Tasks создаются из требований уже позже (можно чтобы этот tool ещё и связь отслеживал).

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

из более менее доступных и удобных (хотя и не без недостатков) рекомендую DevProm ALM. Пробовал в нем работать, знаю людей, которые уже всей командой на него переходят. Все остальное, что видел — стоит существенно дороже.
Как вариант можно еще Enterprise Architect попробовать для ваших целей. на ютубе есть доклад как в касперском для ведения требований использовали связку джиры и архитекта

Только не пинайте меня сильно.
А в MS Project случайно подобного не добавили? Я хз, работал с ним только лет 7 назад (и то в институте))), может он сильно изменился (как Nero;)

Только это не должна быть Jira, потому что требования — это одно, а tasks — это другое.

Вариант А: Два проекта в Jira с разными workflow. Для работы с требованиями я что-то такое видел уже готовое.

Вариант Б: Один проект в Jira, но для требований свои типы задач и свой (упрощенный) workflow. Достаточно совпадения начала и окончания workflow для успешного отслеживания прогресса.

Вариант В: Wiki — движков много, я бы рекомендовал Confluence, MediaWiki. Но разбивать на релизы и указывать важность прийдется вручную, каким-то велосипедным способом. Не очень поддерживаю этот вариант поскольку в wiki лучше хранить документы без статуса, и как можно более свежие, а старые удалять/прятать в архив.

Для начала определитесь, насколько сложная система управления требованиями Вам нужна?
Для сравнения поясню, что такое сложная система управления требованиями (например для медицинского проекта):
1) Размер команды от 50 человек (не только девелоперов, а «всех причастных»).
2) Продолжительность проекта от 3 лет.
3) Необходимость соответствия стандартам (ISO, FDA, etc.).
4) Необходимость полной прослеживаемости любого изменения: кто, когда, почему изменил требование, кто и где это изменение заимплементил, кто протестировал, где тестейс и тест репорт.
5) Необходимость актуальности и непротиворечивости требований в любой момент времени. А следовательно классификация и прослеживаемость зависимостей между требованиями.
6) Разные версии требования для разных версий приложения.
7) Возможность в любой момент времени извлечь срез требований для нужной версии приложения в виде документа «для подписи».
8) Серьезная система разграничения доступа и аудит всех операций. Возможно, цифровая подпись требований.
9) Сам тул должен быть сертифицирован.

Классно. Так а какой инструмент удовлетворяет большинству из изложенного? Что-то конкретных инструментов никто так и не отрекомендовал.

Мы использовали сильно кастомизированный TFS + Sharepoint. И только потому что такие навороченные системы управления требованиями стоят дорого и требуют времени на освоение, например:
Enterprise Architect
www.sparxsystems.com.au/...management.html
IBM Rational
www.ibm.com/...ownloads/r/rrc
Плюс готового решения что фактически покупаем четко формализованный процесс разработки и систему его автоматизации. Но нужно это только для действительно серьезных проектов без малейшего аджайла (медицина, системы управления, финансы).

Я сторонник Redmine и Jira.
По умолчанию выбираю Redmine потому, что он простой, гибкий и бесплатный.
Jira сама по себе тот же Redmine за кучу денег. Ценности есть придает плагин Greenhopper, в котором можно отлично визуализировать workflow.
Из преимуществ жиры: очень гибкая система управления правами и фильтрами
Из недостатков жиры: с наскока не разберешься, должен быть человек, который будет ею заниматься (повелитель жиры :) )
Для хранения артифактов должна быть отдельная DMS (document mgmt system). Хранить в тикетах TMS (task mgmt system) документы — плохая идея.
У Redmine есть встроенный модуль хранения файлов. У JIra — Confluence, но он стоит денег.

Соглашусь с одним из ораторов в том, что надо упрощать — не надо усложнять, это делает сложным понимание инстурмента командой — снижается производительность.

Спасибо за ссылку. Жаль, что она больше не поддерживается.

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

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

Ну или как вариант документация есть финальный результат работы, тут конечно лучше ее чем больше тем лучше :)

Когда-то пользовался разными тулзами, например Power Designer MetaModeler.
Потрачено было ой как много времени, а результат не сильно помогал реально проекту. Зато были все заняты и типа много документации было сделано.

Тулзы тут ни при чем. Их задача — автоматизировать процесс. Т.е. они помогут только если без них приходилось бы делать то же самое, но вручную.
Если формальный процесс не нужен — то и тулзы использовать только во вред. Ведь они заставляют делать то, что без них делать было бы не надо.
А вот процесс уже надо выбирать исходя из проекта. И от процесса напрямую зависит продолжительность и успех проекта. Любой проект можно успешно начать как «агильный» (без формального процесса, документации и менеджмента требований) — это правда. Но что будет через год — два? Напомню: «Individuals and interactions over processes and tools», «Working software over comprehensive documentation». За 2 года люди поменяются и останется только «working software» без понимания как оно работает и зачем. На этом моменте «Responding to change» заканчивается и начинается строительство «подпорок» и «надстроек» с придумываем обходный путей через Ж что бы не поломать никому не ведомую (но возможно нужную какому-то юзеру) функциональность.

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

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

Просто если подумать то ведение формальной документации достаточно осложняет жизнь на большинстве проектов именно на этапе поддержания. Причина простая — нужно поддерживать в актуальном состоянии не только код (реализацию) но и документацию. А обычно делаются изменения, в документации их отразить забывают (ну хоть иногда правда же такое бывает?), и ... начинается больше непоняток на уровне «где же правильно в документации или в коде». При том что реально правильно может быть именно в коде.

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

Просто если подумать то ведение формальной документации достаточно осложняет жизнь на большинстве проектов именно на этапе поддержания.
Формальный процесс заведомо дороже на любом этапе — это очевидно. Его цель в другом — поддерживать качество. И нужно это только на тех проектах, где «додумывание не задокументированных явно вещей» и «в документации их отразить забыли» обходятся намного дороже. Для примера представьте банковский софт. Или даже интернет-магазин с покупками на миллион долларов в минуту. Простая замена «банковского» округления на «математическое» (ru.wikipedia.org/...wiki/Округление ) в новой версии может стоить дороже, чем год работы людей, которые следят что бы все в коде и документации было правильно. А ведь округление — это такая мелочь, которую любой девелопер «подразумевает», сам не так давно узнал что их аж 4 вида.

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

Кстати Вы когда-нибудь писали банковский софт?
Лично я писал, и никакие версионированные требования никак не помогали реализации и дальнейшему поддержанию. Например, на Украине требования к банковской отчетности достаточно часто меняются, и очень часто приходится их оперативно реализовывать. Конечно есть исходные документы которые воспринимаются как требования, но они приходят сверху (в данном случае от НБУ). И практически нет никакого смысла их вести версионированно в своей системе, т.к. нужно опять таки поддерживать эту документацию и код отдельно.

Зависит от размера компании/проекта/процесса разработки. На средних размерах проекте с вроде-agile процессом довольно успешно используют Jira + Confluence (для ю-кейсов, мокапов, и документации).

только Exel ! только хардкор!

мне нравится даже больше чем TFS или Jira (правда, мы его сильно переписали/переделали)

почему вы так решили? в екселе все перечисленное вами есть.

Предложение — написать эту тулзу самостоятельно. Можно даже ничего не платить, поищите на форуме чуваков, готовых работать за еду. Если человек 5 наберется (3 dev + 2qа) и выделите бюджет на тестовый сервак и github репозиторий (300$/год) , то я готов возглавить сие безумное предприятие.
Успех не гарантируем, но оторвемся хорошо.

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

ютуб и инстаграмм запихать в эту тулзу?
Уже руки зачесались накодить что-то эдакое.

На ютубе не разрешат! Можно другой «тюб», с других букв начинающийся.
И шаблонные пункты — «выглядеть должна/ен так — слайды», «уметь должна/ен это -видео».
Звали бы меня Аполлоном, уже бы стартап мутил

Ох уж эти программисты, лишь бы что-нибудь написать самостоятельно :D
Подождите, может есть уже, research не закончен

Поделитесь, пожалуйста, результатами после окончания ресерча. Сам недавно интересовался, но по быстрому нашел только то же, что и вы — динозавров.
З.Ы. Ответы в теме удручают. Выглядит будто большинство разработчиков вообще не понимает о чем речь идет. И это печально.

IBM Rational Quality Manager или HP Quality Center (RQM лучше).

аплодирую стоя, особенно за второй.

p.s. Шоб ты всю жизнь его использовал, советчик.

Junior Tester в GlobalLogic
Что тут сказать... Человек даже не понимает кем работает и что такое «тестер» :D

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

Да вы можете «называть» что/кого угодно и как угодно. Это лишь показывает вашу грамотность. А тем кого знавали — посоветуйте не обижаться на дураков по пустякам! ;)

а что не так со словом?
или вы ведете к тому, что «тестер — это прибор, а человек — тестировщик»? если так, то, может, подскажете, почему тогда не «тестирователь»?

почему тогда не «тестирователь»?
Потому что нет такого слова в русском языке.

Предлагаю переименовать в «мультиметр» и на этом спор закончить!

честно говоря для меня Delivery Unit Manager бесмысленный набор слов :)

Если есть что по теме то пиши, а пытаться типа кого-то обидеть или показать свою «крутизну» (причем именно в кавычках), зачем?

честно говоря для меня Delivery Unit Manager бесмысленный набор слов :)
Я разберусь что мне писать без советов. По теме я высказался лайком ниже. Конечно называть себя «Owbner» — куда более пафосно :D И, кстати, я больше занимаю эту должность.
Почему сразу обидеть? — Наставить на путь истинный.

А как называется должность, на которой вы сейчас работаете?
Это название в должной мире отражает вашу выдающую уникальность и богатый внутренний мир?

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

Более того внутренний мир дошел до того чтобы наставлять других на путь истинный...

Whatever mr. Manager. Если это намек на то, что я не в курсе что такое мультиметр ака тестер, то мимо. А воообще Tester это моя официальная должность по мнению Глобала, так и на официальном сайте Глобала написано. А со стороны заказчика я QA Engineer. А на предыдущем проекте все тестировщики были то ли QD Engineer то ли QE Engineer, что бы это не означало.

На маркетинг буллшит строго по барабану — все заинтересоные стороны понимают что мы делаем. Внезапно, да?

Просто не все еще понимают существенные отличия между QC, QD и прочими великими абревиатурами.

Например, я не понимаю... но это чертовски важно...

Я прям проникся уважением к тяжелой профессии Тестера, раз они у сами знаете кого даже своим названием попоболь вызывают

Это привет с тех времен, когда его самого так называли. А он запомнил ...

Юзабилити у QC может и не очень (особенно текстовый редактор), но он работает и в нем можно делать все что нужно для проекта, включая то что написала ОР в топике. Я только не знаю насколько там удобные дашборды, не пользовался. Пока что «фатальных» недостатков у обоих систем я не видел.
Если есть варианты получше, то для этого эту тему и создали, писать варианты и обсуждать. Мне и самому интересно что бывает лучше, иначе я бы сюда не писал.

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

JIRA — мировой стандарт и позволит делать все, о чем вы пишете.
Стандарт — это значит, что почти все (кроме одиозных интернов) умеют в ней работать.
Не изобретайте велосипед основываясь на сомнительных требованиях (

Поиск в google выдал кучу софта, половина из которого выглядит, как будто он из прошлого века.
)

Confluence?
И не джира, и с джирой интегрируется, и могёт вроде бы всё, что вы описали.

Кроме версионирования.

есть как история изменения документов, так и история загрузок файлов

Есть. Но это очень ограниченное версионирование. Например, я начал обновление документа, но еще не закончил. Публиковать в том виде, что есть я не хочу для всеобщего обозрения, потому что много неточностей. Разве там есть возможность сохранить то, что я отредактировал в черновик, чтоб продолжить модификации завтра, но при этом оставить текущую версию документа для просмотра другими?

можна, воркфловами (draft > published)

Еле нагуглил о чем речь вообще идет. Это плагин такой Ad hoc Workflows. Выглядит как раз то, что надо. Возможно, если порыться во всех плагинах, можно склепать то, что нужно автору. Правда цена совершенно дурная на этот плагин для всего, что больше 10 пользователей.

+Blueprints, которых уже немало в Marketplace

Подписаться на комментарии