Подтвердить что ты не робот

Какое хорошее решение для сбора документации по бизнес-правилам?

Я столкнулся с ситуацией, я уверен, где моя документация по бизнес-правилам распространяется по электронной почте, документации (теперь устаревшей) и IM. Это воняет.

Я могу думать о двух альтернативах: Sharepoint (ненавижу, функция поиска ужасна) или вики.

Некоторые вещи, которые я хотел бы увидеть в идеальном решении:

  • Легко обновляемый: не заставляйте меня вытягивать Word для обновления документов
  • Diff view. Иногда вам нужно только увидеть, что нового
  • Подписываемый: уведомление о новых изменениях на странице за страницей
  • Ролевая структура. Редактирование и просмотр страниц можно привязать к ролям.
  • Вложения: простое включение макетов, файлов и т.д.
  • Поиск. Это пост-мир google, я хочу, чтобы иметь возможность искать и находить мгновенно - Sharepoint проигрывает в этой категории, если только тот, который мы используем, не настроен неправильно
  • Ограничение вложений. В идеале это решение не позволит загружать кучу документов Word, которые мы тогда будем называть нашей документацией. Я хочу, чтобы документация имела согласованный (и простой) формат. Применение вложений в формате PDF, txt и т.д.

Следуя за моим комментарием wiki, похоже, что как минимум 3 вики, которые делают то, что я хочу (Incentive, SharePoint-Wiki-Plus, ThoughtFarmer). ThoughtFarmer, любите это имя.

4b9b3361

ОТВЕТЫ

Ответ 1

+ 10⁶ для Wiki, это лучшее решение, которое я нашел до сих пор для документации, особенно технической документации. IMO, преимущества "хороших" движков Wiki над документами Office в VCS (но вы уже знаете об этом, так как список этих функций очень близок вашим требованиям):

  • они просто быстрее и проще в использовании, чем документы Office в VCS (нет необходимости открывать клиент VCS, проверять последнюю версию, дополнительно блокировать ее, открывать слово, сохранять, регистрировать, освобождать блокировку)
  • они основаны на тексте, поэтому вы делаете diff (в отличие от слова), и это просто должно быть
  • они предлагают механизмы уведомления (например, почту, RSS), и поэтому информация передается вам (в отличие от VCS, где вам нужно вытягивать документ, когда они устарели)
  • нет "документа, заблокированного другой проблемой пользователя", потому что кто-то забыл его освободить (если вы используете эксклюзивную блокировку, которая часто применяется к документам, которые вы не можете объединить)
  • страницы могут быть легко реорганизованы, реорганизованы, собраны в больших документах.
  • они действительно совместимы
  • они обеспечивают гораздо лучшую поддержку кода (например, вы можете прямо указывать исходный код в VCS с гораздо лучшим форматированием, чем на слово)
  • они могут индексировать содержимое страниц и прилагаемых документов (pdf, офисные документы и т.д.) и сделать их доступными для поиска.

Единственная проблема, с которой я столкнулся при использовании Wiki для документации, - это то, что вам сложнее выполнить версию документации одновременно с вашим кодом (т.е. вы доставляете версию x.y.z и хотите "заблокировать" документацию этой версии). Я использовал экспорт, чтобы решить эту проблему, но это не идеально.

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

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

Ответ 2

Более сложная идея - заглянуть в FitNesse. Это вики, в первую очередь предназначенные для описания бизнес-правил (или требований приемки) в качестве тестов.

Ответ 3

Я разрабатываю один.

Примерно год назад я искал программное обеспечение для управления требованиями в сети и нашел не менее 30 из них примерно в 3 категориях:

  • Бесценный (и продаваемый, например, в аэрокосмических компаниях)

  • Дорого (например, 1000 долларов за место), которые мои работодатели никогда не выбрали для использования

  • Дешевые или бесплатные, но недостающие функции, которые мне кажутся важными

Существуют также инструменты общего назначения (например, Wiki, электронные письма и документы Word и/или таблицы), в которых также отсутствуют функции, которые мне кажутся важными.

Я думаю, вы должны уточнить: "Отсутствуют функции, которые мне кажутся важными".

Есть вещи, которые вы можете сделать с помощью универсальной Wiki:

  • Создайте список функций
  • Опишите каждую функцию (возможно, отдельную страницу/раздел для каждой функции)
  • Сделайте это совместно (контроль версий, уведомления об обновлениях, страницы обсуждения)

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

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

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

  • Поддержка структурированной информации, т.е. подразделов, а не только разделов верхнего уровня.

Даже просто редактирование не так хорошо, как должно быть. Деловые люди могут предпочесть использовать интерфейс MS Word для редактирования: но MS Word создает документы, то есть "информационные силосы"; но если вы не используете MS Word, то вы используете что? WYSIWYG в браузере? Или синтаксис уценки?

Ответ 4

Мне нравится использовать функцию Wiki, встроенную в FogBugz для этого, предполагая, что вы уже используете ее для отслеживания характеристик/ошибок. Удобно иметь эту информацию в одном и том же инструменте.

Ответ 6

Мы использовали JIRA в предыдущем проекте для хранения около 750 различных бизнес-правил. JIRA в основном/kinda-инструмент отслеживания ошибок, но он настолько мощный и настраиваемый, что вы можете использовать его для всех видов рабочих процессов/процессов/баз данных. (BTW - я не работаю для компании, которая ее производит).

  • Легко обновляется: да
  • Diff view: доступна полная история изменений
  • Подписываемое: да, есть идея "контрольных списков"
  • Роль: да, многофункциональная модель безопасности
  • Вложения: да, каждое правило может иметь собственные вложения
  • Поиск: есть полнотекстовый поиск
  • Ограничение вложений: hmm - не уверен в этом и точно, что вы пытаетесь сделать.

Некоторые советы, если вы решите пойти по этому пути...

  • Использовать индивидуальный идентификатор JIRA в другом месте для ссылки на правило, например. MYPRJ-334
  • У вас есть четкие рекомендации относительно того, какие состояния, которые вы планируете использовать, означают, предлагать, утверждать, реализовывать, проверять, удалять.
  • Единственное определение правила в описании - все комментарии - это просто комментарии
  • Вы можете связать Правило, чтобы использовать случаи, компоненты как бы

Это отличный подход, и я действительно рекомендую его.