Используете Wiki для управления требованиями?[закрыто]

https://stackoverflow.com/questions/849840

21-08-2019
|

Вопрос

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

Попросите нескольких пользователей внести свой вклад в спецификацию.
Обеспечьте некоторую форму отслеживания, которую при необходимости можно выполнить вручную.
Предоставьте пользователям возможность добавлять комментарии и примечания.
Загрузка и отображение документов Visio
Загрузите и отобразите экраны макетов с помощью Balsamiq Mockup.

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

Ваш вклад очень ценен!

Решение

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

Я управлял вики по проекту Zend Framework, чтобы отслеживать предложения по компонентам. Они до сих пор его используют. Предложения отличаются от функциональных спецификаций, но их использование достаточно похоже на ваш вопрос, поэтому я думаю, что это актуально.

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

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

Чтобы заставить это работать, нужно применить к проекту какой-то процесс и использовать вики в соответствии с этим процессом.

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

Другие советы

«Каковы будут плюсы и минусы использования такого инструмента по сравнению с инструментом управления требованиями?»

Хотя это кажется отличной идеей, вы сталкиваетесь с людьми, которые не умеют и не хотят писать.

Люди, которые не умеют писать, ну, не умеют писать.Они не могут общаться с помощью электронной почты, вики или любого другого внешнего средства связи.

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

Некоторые люди не будут писать.

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

Мой опыт показывает, что только программисты могут успешно использовать Wiki.И только программисты старшего уровня.

У N00bz недостаточно опыта, чтобы отделить требования от дизайна от слухов и управленческой чепухи.
У N00bz не всегда есть языковые навыки, чтобы четко писать.В конце концов они могут это сделать, но один взгляд на их комментарии в Javadoc показывает, что у них проблемы с «ясностью» написания.

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

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

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

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

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

Все может быстро сбиться с пути
Связь может быть потеряна в среде

Посмотрите на такие вещи, как Basecamp.Их можно рассматривать как прикладную вики или инструмент для совместной работы.Универсальный инструмент для конкретных целей нуждается в доработке.Я не знаю, есть ли у MediaWiki или других разработчиков достаточная настройка, чтобы все было чисто и сфокусировано.

Возможно, соберите требования к вашему инструменту управления требованиями (я знаю, что он рекурсивный) и какие аспекты (коммуникационные аспекты) вы можете взять из вики-культуры и мышления открытого общения.Если ни инструменты управления требованиями, ни вики-сайты не подходят, подумайте о их создании.Возможно, это будет следующим большим событием.Это похоже на то, чтобы сказать Могу ли я использовать вики вместо Bugzilla?

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

В этом контексте мы использовали TWiki, а теперь и FosWiki.Есть много вещей, которые можно получить бесплатно (контроль версий, контроль доступа, доступ к веб-базе, поиск, удаленное управление, исправления безопасности, ...).За несколько минут можно определить:

таблица, определяющая атрибуты требований,
который создает интерактивные формы с выбором и проверкой полей (где вы также можете документировать обсуждения и обоснования, вставлять изображения, прикреплять документы, ссылаться на другие требования...),
а затем запрашивать эти «требования» и отображать их в виде таблиц, которые можно сортировать, фильтровать, распечатывать, составлять отчеты и т. д.(например., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).

Очевидно, что по пути можно легко использовать гиперссылки и ссылки Wiki.FosWiki также имеет функции, которые при необходимости можно использовать для реализации определенных рабочих процессов.Также легко поддерживать формы для вариантов использования и других парадигм (мы делали это раньше, и в целом это работает хорошо).

Wiki, такие как FosWiki, являются расширяемыми, и можно разработать дополнительные модули для устранения недостатков, связанных с управлением прослеживаемостью и анализом воздействия, модификациями требований на основе таблиц, общей упаковкой и т. д.

В качестве промежуточного варианта между вики свободной формы и инструментом управления требованиями рассмотрите возможность использования структурированная вики нравиться Фосвики.Я не занимался формальным управлением требованиями (с помощью вики или иным образом), но я использовал TWiki (предшественник Foswiki) для других задач, и он позволяет вам определять рабочий процесс, поля формы и т. д. по мере необходимости. их, сохраняя при этом гибкость вики, когда вам не нужна формальная структура.

Я согласен со всеми (большинством) вышеперечисленных людей - использование вики может звучать нормально, но вики предназначены для предоставления информации и обновления по мере необходимости, а не для использования в качестве интерактивного инструмента управления проектами.Я настоятельно рекомендую SmartSheet (я ярый сторонник этого продукта) - он предоставляет интерфейс, похожий на электронную таблицу, где вы можете хранить несколько файлов для каждой строки/задачи, рассылать автоматические обновления пользователям и поддерживать версии спецификаций...Другой подход может заключаться в использовании электронной почты, документов и календаря Google — бесплатного и дружественного способа командного взаимодействия… Я бы воздержался от инструментов отслеживания проблем/ошибок для управления проектами — они, как правило, имеют разную направленность:Инструменты PM для всего проекта/ресурса/временной шкалы и инструменты отслеживания проблем для конкретных введенных проблем....

Возможно, это уже немного устарело, но сейчас я использую Atlassian Confluence, и это здорово.В настоящее время я работаю UX-инженером и играю роль «владельца продукта» в рамках Agile-процесса.Я могу документировать требования к дискретным интерфейсам, учитывать отзывы и комментарии нескольких пользователей и переплетать каждый интерфейс с другими интерфейсами в более широком контексте (например,пользовательская история).Все очень динамично и основано на шаблонах.Это очень хорошо соответствует моим текущим потребностям.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow