В теме 8 ответов, и 4 участника, последнее обновление сделано пользователем 
Igor Tkachenko 13 г, 6 мес. назад.
-
Сообщения
-
Есть желание попробовать вести требования на проекте с использованием wiki. Если у кого-то есть практический опыт использования какого-то конкретного движка (или даже нескольких), пожалуйста поделитесь, что хорошего и плохого вы можете сказать.
Что хотелось бы получить:
- Нормальное разделение между проектами
- Построение иерархии страниц в самом проекте
- Нормальный WYSIWIG редактор
- Нормальная обработка вставляемого rich-content (перевод в вики-формат)
- Поддержка экспорта всего проекта или его части в Word/PDFMicrosoft OneNoteА вообще имеется опыт ведения требований в MediaWiki. Очень неудобно вставлять картинки. Но если использовать вместе с публичной шарой — то нормально.
А вообще ОЧЕНЬ рекомендую поинтересоваться вышеуказанной тулзой. В неё кроме совместной, в том числе удаленной работы, еще включены средства по прототипированию, резервированию, возможности работать offline, вводу информации с камеры, микрофона и рисованию. Там мало глюков. Удобная интеграция с отулуком.
Один минус: если канал у вас меньше 8 мегабит — удаленная работу будет немного напряжной, если вы через нее будете шарить файлы. А это очень хочется делать, потому что очень удобно.
Если не любите использовать платный софт, или микруховские продукты, или продукты без веб морды — смотреть не рекомендую, она сломает ваши стереотипы и разобьет сердце.
Мы используем Wiki, мне нравится, вот немного о том как мы ведем требования viewtopic.php?f=8&t=1441&start=15Мы используем Wiki Confluence. Она поддерживает все ваши перечисленные требования.
Используем XWiki[/url]:1. Разделение между проектами организовано стандартными средствами страниц и разделов. Что называется, не мудрствуя лукаво.
2. Иерархия страниц внутри проекта достигается за счёт именования подстаниц вида: КодПроекта_ИмяПодстраницы. Пока ничего лучше не придумали (не было необходимости).
3. WYSIWIG, в принципе, неплохой, — богатая панель инструментов и возможность асинхронного перехода к исходнику.
4. С rich-content серьёзных проблем не возникало — за счёт всё того же WYSIWIG-редактора и достаточно гибкого синтаксиса.
5. Поддерживается экспорт в PDF, RTF и HTML.Здесь неплохая русскоязычная документация.
P. S. Меня всё не покидает навязчивая идея попытаться использовать семантический движок. Semantic MediaWiki, например. Надеюсь, удастся поэкспериментировать. По результатам отпишусь :-)
P. S. Меня всё не покидает навязчивая идея попытаться использовать семантический движок. [url=http://semantic-mediawiki.org/wiki/Semantic_MediaWiki]Semantic MediaWiki[/url], например. Надеюсь, удастся поэкспериментировать. По результатам отпишусь :-)
Какая именно цель? Или просто навязчиво хочется "поюзать"?
Какая именно цель? Или просто навязчиво хочется "поюзать"?
Цель — существенно ускорить доступ к информации и не менее существенно повысить этой информации структурированность и гибкость. Задача — обеспечить максимальную машинную обработку базы знаний.
Я вообще убеждён, что за этой концепцией — будущее. И слишком уж заманчива перспектива прикоснуться к этому будущему уже сегодня :-)
Так ты к будущему хочешь прикоснуться или сейчас скорость работы команды с материалами повысить?Так ты к будущему хочешь прикоснуться или сейчас скорость работы команды с материалами повысить?
А это так уж несовместимо? :-)
Просто не вижу того что первое надо чтобы получить второе.
Вы должны авторизироваться для ответа в этой теме.
