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

Ответ 1

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

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

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

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

Способ заставить его работать, это применить некоторый процесс к проекту и использовать wiki в соответствии с этим процессом.

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

Ответ 2

"Каковы были бы плюсы и минусы использования такого инструмента, в отличие от инструмента управления требованиями?"

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

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

• Некоторые люди "дезорганизованы". На самом деле, запись слишком линейна, и они не думают линейно.

• Некоторые люди не получают "писать своей аудитории" и пишут что-то непонятное.

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

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

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

• Некоторые люди привыкли делать все, отдавая направление кому-то другому. Они либо не пишут сами за себя, либо заставляют людей стоять в офисе и слушать их, разговаривая и печатая.

• Некоторые люди, как правило, токсичны для любого проекта. Они spring новые требования в последнюю минуту. Их первый ответ - "это никогда не сработает". Они не проводят мозговой штурм. Когда они говорят, что это работа, и вы просите их об улучшении, у них их нет. Они просто знают, что это не сработает.

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

• N00bz не имеют достаточного опыта для сортировки требований от дизайна от слухов и путаницы управления.

• У N00bz не всегда есть навыки владения языком, чтобы писать четко. Они могут в конечном итоге, но один взгляд на их комментарии Javadoc указывает, что они борются с "ясностью" части письма.

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

Ответ 3

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

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

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

Ответ 4

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

• Вещи могут ползти и быстро выходить из строя.
• Связь может быть потеряна в среде

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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