Отличный материал в Открытых системах:

Wiki в коллективной разработке требований

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

Я бы не спешил с восторженными оценками применимости Wiki в разработке требований.
Это удобно, если аналитики требований удалены друг от друга.

Но при этом на пвервое место вылазит вопрос безопасности...
Если разворачивать wiki локально - то смысл ее теряется в значительной мере - специалистам проще собраться и поговорить.
Кроме того, в малых и средних фирмах будут ли специалисты, обесчивающие поддержку wiki  внутри сети, решать все проблемы с ней.
Крупной фирме проще будет купить doors, caliberRm, requisitePro - в которых также есть коллективные обсуждения требований, но при этом они лишены обозначенных в статье недостатков.
Мне кажется, что проблема инструментария - вторична, по сравнению с опытом и компетенцией аналитика, его работой с заказчиком. Я бы не стал повсеместно пропагандировать wiki к применению. wiki, на мой взгляд, будет востребована при разработке ПО с открытым кодом, когда сроки не стоят жестко.

Но при этом на пвервое место вылазит вопрос безопасности...

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

Если разворачивать wiki локально - то смысл ее теряется в значительной мере - специалистам проще собраться и поговорить.

Ты не прав. Собраться и поговорить - это одно. Создавать проектную дкоументцаию - это постоянный процесс.

Кроме того, в малых и средних фирмах будут ли специалисты, обесчивающие поддержку wiki  внутри сети, решать все проблемы с ней.

А какие с ней проблемы? Поставил и пользуйся. И то, я не вижу смысла ставить локально вики в малых компаниях, если нет задачи интеграции и модификации. Во-вторых, плох тот аналитик, который не может поставить вики

Крупной фирме проще будет купить doors, caliberRm, requisitePro - в которых также есть коллективные обсуждения требований, но при этом они лишены обозначенных в статье недостатков.

Саша, ты в крупной фирме работаешь? Почему тебя вообще крупные фирмы волнуют?

Посчитай, какое количество проектов, связанных с требованиями делается в мире/России, и какую долю из них составляют проекты больших компаний. У НИХ И ТАК ВСЁ НОРМАЛЬНО. ИЛИ НЕНОРМАЛЬНО, НО НИКОМУ ДО ЭТОГО НЕТ ДЕЛА.

Вот я сейчас вроде как в крупной, и ПО мы себе КАЗАЛОСЬ БЫ купить/поставить можем, и регламенты написаны - а процесс не внедрён, ан нет - если пересчитать потребное кол-во лицензий, получается немалая сумма, каждого надо обучать программе и т.д. и т.п. И на реальном проекте я использовал MediaWiki, и для локальных нужд мы купили и поставили Confluence (а не имеющийся SharePoint) - но уже не для УТ, а в качестве основы системы накопления знания. Потому что это - работает.

Мне кажется, что проблема инструментария - вторична, по сравнению с опытом и компетенцией аналитика, его работой с заказчиком.

Инструментарий влияет на качество процесса. К тому же такого процесса, как коммуникация, которая очень важна для УТ.

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

Саша, я использовал и использовую wiki на реальных проектах. Мне 50-летний бизнес-аналитик сказал, что это удобно - что он смог сесть на выходных и вне этих корпоративных будничных запар спокойно и тихо расписать всё в онлайне. Причём тут сроки?

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

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

Ты не прав. Собраться и поговорить - это одно. Создавать проектную дкоументцаию - это постоянный процесс.

Достаточно спорно. Все от команды зависит. Кому то комфортно общаться через интернет, кому-то удобнее общаться в реале.

А какие с ней проблемы? Поставил и пользуйся.
И то, я не вижу смысла ставить локально вики в малых компаниях, если нет задачи интеграции и модификации. Во-вторых, плох тот аналитик, который не может поставить вики

Я - плохой аналитик. Я не умею ставить wiki. CaliberRM, RequsitePro - поставлю . Я не уверен, что ясмогу обеспечить безопасность документации. Можно ли запретить на wiki просмотр незарегистрированным пользователям и централизовать регистрацию? Или это делается другими способами. Как делал ты в своих проектах?

Саша, ты в крупной фирме работаешь? Почему тебя вообще крупные фирмы волнуют?
Посчитай, какое количество проектов, связанных с требованиями делается в мире/России, и какую долю из них составляют проекты больших компаний. У НИХ И ТАК ВСЁ НОРМАЛЬНО. ИЛИ НЕНОРМАЛЬНО, НО НИКОМУ ДО ЭТОГО НЕТ ДЕЛА.
Вот я сейчас вроде как в крупной, и ПО мы себе КАЗАЛОСЬ БЫ купить/поставить можем, и регламенты написаны - а процесс не внедрён, ан нет - если пересчитать потребное кол-во лицензий, получается немалая сумма, каждого надо обучать программе и т.д. и т.п. И на реальном проекте я использовал MediaWiki, и для локальных нужд мы купили и поставили Confluence (а не имеющийся SharePoint) - но уже не для УТ, а в качестве основы системы накопления знания. Потому что это - работает.

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

Инструментарий влияет на качество процесса. К тому же такого процесса, как коммуникация, которая очень важна для УТ.

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

Саша, я использовал и использовую wiki на реальных проектах. Мне 50-летний бизнес-аналитик сказал, что это удобно - что он смог сесть на выходных и вне этих корпоративных будничных запар спокойно и тихо расписать всё в онлайне. Причём тут сроки?

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

Если честно - очень хочу попробовать.
Денис, если не трудно, расскажи, как технически все организовали?

Я - плохой аналитик. Я не умею ставить wiki. CaliberRM, RequsitePro - поставлю .

Хм, значит я хороший аналитик? Я умею ставить wiki, да чего его не поставить? Ставим Apache 2.x, PHP 5.x.x, mysql 4.x, качаем дистриб mediawiki и ставим его по инструкции. Или можно обойтись например dokuwiki там запросы скромнее и даже mysql ненужно.

А вот CaliberRM ставить не умею, ну не ставится он у меня, зараза! А вот DOORS поставился с полпинка.

Другой вопрос - как настроить все это хозяйство? Какая должна быть структура? И т.п.

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

Я думаю - можно в отдельной ветке.
"Техническая организация управления требованиями"
Создадим?

Я думаю - можно в отдельной ветке.
"Техническая организация управления требованиями"
Создадим?

why not?

Достаточно спорно. Все от команды зависит. Кому то комфортно общаться через интернет, кому-то удобнее общаться в реале.

Саша, если у людей есть возможность общаться в реале и они общаются в реале, например в режиме "парного анализа", то какая нафиг разница, что у них там на экране открыто в режиме редактирования - MS Word/OpenOffice или браузер? Просто большинство вики лишено избыточного синтаксиса и автоматически поддерживает версионность.

Я - плохой аналитик. Я не умею ставить wiki.

Я сказал - "не может", а не "не умеет" ) Ты попробуй.

Можно ли запретить на wiki просмотр незарегистрированным пользователям и централизовать регистрацию? Или это делается другими способами. Как делал ты в своих проектах?

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

Если ты будешь пользоваться готовыми hosted-сервисами, такими, как, например, Zoho Wiki, то там разграничение доступа - естественная и удобная функция системы.

Подобрать вики-систему для установки у себя можно на WikiMatrix.org

Заставить работать можно все что угодно. Для этого необходима воля руководства и желание сотрудников.

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

Не стоит под инструменты пытаться подстраивать бизнес-процессы.

А кто пытался?

Но с клиентами тоже удалось в выходные пообщаться?

Смотря какими. Представителям крупного бизнеса всё до фени. Мелкий и средний вполне общается, если система для них критична и время есть.

А вы в своей работе какую Wiki используете? Я так понимаю в основном используют MediaWiki.

Мы то же начали использовать в своей работе Wiki. Перед тем как его применять общался с Юрием Булуй и поняли, что можно использовать, но с ограничениями. Кстати, Luxoft на основе Confluence (Wiki) и Jira (issue tracker) сделали свое решение по управлению требованиями (RMS) и задачами.

В принципе инструмент подходящий, но имеет ряд недостатков по сравнению с традиционными инструментами управления требованиями (кроме тех, которые есть в статье):
1. Не возможность добавления атрибут к страницам, если отдельную страницу считать за требовние.
Частично решается за счет создания шаблона, в котором будут определены внутри страницы строчки, отвечающие за эти параметры.
2. Не возможность генерации цельного документа на основе написанных требований в ВИКИ
Возможно решить за счет написания плагина
3. Слабая структурированность требований. Например, если мы добавляем некое требование и оно должно быть вставлено, как номер 5 среди уже неаписаных 10 требований, то автоматическаянумерация не произойдет
Пока не понял как решить, кроме переименования всех страниц в ручную.
4. Нет возможно сказать, что это финальная версия требования или подтвержденная руководством.
Частично решается с помощью добавления в заголовок слова approved или добавления соответсвующей строчки в страничку

Мы пробовали использовать две Wiki - Confluence и TWiki. Остановились на TWiki, т.к. не договрились о цене с Confluence на 100 пользователей (на 50 было мыло, а на 500 много и дорого). TWiki мне понравилась меньше по юзебилити: сложно создавать странички и привязывать их к родительской, не возможнсть просмотра заголовков страниц в виде иерархий, убогие комментарии и т.д.

В понедельник выложу иерархию требований, которые я (с одобрением Юрия) создал в Confluence.

кстати, тоже тема для семинара или статьи

3. Слабая структурированность требований. Например, если мы добавляем некое требование и оно должно быть вставлено, как номер 5 среди уже написаных 10 требований, то автоматическая нумерация не произойдет
Пока не понял как решить, кроме переименования всех страниц в ручную.

Не понял, ты номера требованиям вручную что-ли задаёшь? Зачем?

Не понял, ты номера требованиям вручную что-ли задаёшь? Зачем?

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

Кстати, а смотрели TrackStudio (http://www.trackstudio.ru) для целей управления требованиями (хотя вообще-то это навернутый issue tracker) ? С доп. атрибутами и структурированностью проблем нет, никакой интеграцией заниматься не надо, цена более чем демократичная.