Использование Wiki для управления требованиями? [закрытый]
Вы можете попробовать это:
rand_sample <- DF[ sample( which(DF$Weight > 0.4 & DF$Weight < 1.1), round(0.2*length(which(DF$Weight > 0.4 & DF$Weight < 1.1)))), ]
6 ответов
Можно делать то, что вы описываете, разрабатывать требования совместно, несмотря на с помощью вики. Ничто в парадигме вики не помогает в этом процессе.
Я управлял вики по проекту Zend Framework, чтобы отслеживать предложения по компонентам. Они все еще используют его. Предложения отличаются от функциональных спецификаций, но их использование достаточно похоже на ваш вопрос, и я думаю, что это уместно.
Вики о себе не заботится. Если у вас нет кого-то, кто отвечает за управление и обеспечение определенной структуры и последовательности, это быстро превращается в беспорядок. В качестве аналогии из реальной жизни можно было бы передать каждому члену вашей команды чистый лист бумаги и попросить их написать свою часть требований. Проблемы с этим:
- Каждый участник должен создать свою собственную структуру документа и писать о разных вещах в разном порядке. Таким образом, невозможно сравнивать одну страницу с другой.
- Не существует «индексной страницы» для систематизации всех разрозненных материалов. Никто не хочет, чтобы страница «провалилась», но в вики это судьба по умолчанию любой страницы, как только она написана.
- Нет цикла обратной связи, чтобы убедиться, что написание действительно выполнено.
Чтобы заставить его работать, нужно применить какой-то процесс к проекту и использовать вики в соответствии с этим процессом.
- Дайте людям возможность создавать новую страницу в вики, но только через интерфейс, который автоматически связывает новую страницу с правильным индексом.
- Определите жизненный цикл для документов, чтобы они обязательно были составлены, рассмотрен и утвержден на соответствующих этапах.
- Предоставьте шаблон для новой страницы. Укажите заголовки разделов, которые вам нужны на каждой из этих страниц, и сделайте часть процесса проверки подтверждением того, что раздел заголовка был заполнен надлежащим образом.
Специальные инструменты помогают отслеживать работу и вводят фиксированный рабочий процесс. Это своего рода суть в том, чтобы держать вещи сфокусированными и функциональными. Использование общих инструментов, таких как Wiki, может быть отличным решением для группы программистов, но введение одного для работы в «смешанном режиме» может быть плохим:
- Вещи могут быстро сбиться с пути
- Связь может быть потеряна в среде.
Посмотрите на такие вещи, как Basecamp. Их можно рассматривать как прикладную вики или инструмент для совместной работы. Универсальный инструмент для конкретной цели требует доработки. Я не знаю, есть ли у MediaWiki или других достаточно настроек, чтобы держать вещи в чистоте и сфокусированности.
Может быть, собрать требования для вашего инструмента управления требованиями (рекурсивный, я знаю) и какие аспекты (аспекты коммуникации) вы можете взять из культуры вики и мышление открытого общения. Если ни инструменты управления требованиями, ни вики не подходят, подумайте о создании одного из них. Может быть следующим большим событием. Кажется, будто я говорю: Могу ли я использовать вики вместо Bugzilla?
Веб-приложение с фиксированным рабочим процессом для управления требованиями с акцентом на открытое общение, которое позволяет людям из многих ролей видеть и понимать, может быть хорошо!
«Какие плюсы и минусы использования такого инструмента, как этот, в отличие от инструмента управления требованиями?»
Хотя это кажется отличной идеей, вы сталкиваетесь с людьми которые не могут и не хотят писать.
Люди, которые не умеют писать - ну - не умеют писать. Они не могут общаться с помощью электронной почты, вики или любого другого внешнего голоса.
Некоторые люди «дезорганизованы». На самом деле письмо слишком линейно, и они не думают линейно.
Некоторые люди не получают «пишите для своей аудитории» и пишут вещи, которые непонятны.
Иногда вы даже не можете понять, что они » говорят о том, а тем более о чем пишут. Они говорят на жаргоне или коде. Они мало что знают, но настаивают на том, чтобы их услышали.
Некоторые люди не хотят писать.
Некоторые люди отказываются брать на себя обязательства. Даже в вики, где его можно отозвать. Они чувствуют, что должны все заранее обсудить.
Некоторые люди имеют обыкновение делать все, давая указания кому-то другому. Они либо не пишут для себя, либо заставляют людей стоять в своем офисе и слушать, как они говорят и печатают.
Некоторые люди, как правило, токсичны в любом проекте. Они выдвигают новые требования в последнюю минуту. Их первый ответ - «это никогда не сработает». Они плохо проводят мозговой штурм. Когда они говорят, что это работает, и вы умоляете их об улучшении, у них этого нет. Они просто знают, что это не сработает.
Мой опыт показывает, что только программисты могут успешно использовать Wiki. И только старшие программисты.
N00bz don ' У меня достаточно опыта, чтобы отделить требования от дизайна от слухов и управленческой ерунды.
N00bz не всегда обладает языковыми навыками, чтобы четко писать. Со временем они могут это сделать, но один взгляд на их комментарии Javadoc показывает, что они борются с «ясностью» в написании.
Это очень привлекательно. Я надеюсь, что люди научатся лучше использовать вики, потому что я думаю, что это может иметь много преимуществ по сравнению с более традиционными подходами, когда один человек опрашивает всех и записывает вещи. Но для этого требуется уровень уверенности и навыков общения, которыми, похоже, обладают немногие.
re борется с "ясностью" написания.Это очень привлекательно. Я надеюсь, что люди научатся лучше использовать вики, потому что я думаю, что это может иметь много преимуществ по сравнению с более традиционными подходами, когда один человек опрашивает всех и записывает вещи. Но для этого требуется уровень уверенности и навыков общения, которыми, похоже, обладают немногие.
re борется с "ясностью" написания.Это очень привлекательно. Я надеюсь, что люди научатся лучше использовать вики, потому что я думаю, что это может иметь много преимуществ по сравнению с более традиционными подходами, когда один человек опрашивает всех и записывает вещи. Но для этого требуется уровень уверенности и навыков общения, которыми, похоже, обладают немногие.
Попробуйте изучить Fog Bugz . Они рекламируют себя как лучшие из лучше всего подходит для управления проектами. Учитывая историю Джоэла, я бы дал им Преимущество сомнения. Они используют вики, как вы только что описали.
Я бы посоветовал подписаться на бесплатную пробную версию, если вы серьезно. В зависимости от размера вашего проекта его покупка может быть очень хорошей вариант.
По крайней мере, вы могли бы посмотреть, как они его структурировали, или прочитать форумы для идей о том, как создать собственную урезанную версию
В качестве промежуточного звена между вики свободной формы и инструментом управления требованиями рассмотрите возможность использования структурированной вики , например Foswiki . Я не занимался каким-либо формальным управлением требованиями (с помощью вики или каким-либо другим способом), но я использовал TWiki (предшественник Foswiki) для других задач, и он позволяет вам определять рабочий процесс, поля форм и т. Д. По мере необходимости. их, сохраняя при этом гибкость вики, когда вам не нужна формальная структура.
Я согласен со всеми (большинством) вышеупомянутых людей - использование вики-сайтов может показаться нормальным, но вики-сайты предназначены для предоставления информации и обновления по мере необходимости, а не для использования в качестве интерактивный инструмент управления проектами. Я настоятельно рекомендую SmartSheet (я убежденный сторонник этого продукта) - он предоставляет интерфейс, похожий на электронную таблицу, где вы можете хранить несколько файлов для каждой строки / задачи, отправлять автоматические обновления пользователям и поддерживать исправления спецификаций ... Другой подход может заключаться в использовании электронной почты, документов и календаря Google - бесплатный дружественный способ группового взаимодействия ... Я бы уклонялся от инструментов отслеживания проблем / ошибок для управления проектами - они, как правило, имеют разную направленность: инструменты PM по всему проекту / ресурсу / временной шкале и инструменты отслеживания проблем для определенных введенных проблем ....