Как определяются требования в проектах с открытым исходным кодом?

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

Под «определением требований» я имею в виду «выяснение того, какие функции и т. Д. Следует разрабатывать как часть определенного программного обеспечения».

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

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

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

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

Я следил за открытым исходным кодом с тех пор, как впервые услышал о Linux в 1995 году, и я не помню, чтобы когда-либо слышал слово «требования», используемое в этом контексте.

У Эрика Рэймонда есть хорошее эссе «Кафедральный собор и базар» , в котором он говорит о том, как «почесать свой собственный зуд». Если вы пытаетесь решить проблему, с которой сталкиваетесь лично, вам не нужно обращаться к документам с требованиями, чтобы выяснить, решили вы ее или нет.

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

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

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

• неформальное общение

• приоритетные требования / ошибки / проблемы / списки заявок (и это определенно не выдумка «гибкого» сообщества)

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

Если проблема является общей, например, при написании компилятора или браузера, требования в значительной степени приведены в форме языковых стандартов, целевых операционных систем и целевого оборудования и т. Д.

Для таких вещей, как GNU Emacs, для многих из которых помимо превосходного выполнения своей первоначальной цели - текстового редактора, я думаю, что требования имели смысл из-за огромных возможностей его расширения. Чаты, электронные письма, группы новостей, редактирование кода, контроль версий приходят на ум. Есть исследователь, работающий над Emacspeak. Я думаю, что подобные вещи можно сказать о браузерах и других вещах, которые допускают расширения.

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

РЕДАКТИРОВАТЬ:

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

В проекте, полностью основанном на исследованиях, таком как GNU Hurd, я думаю, что требования исходят из результатов исследований и работ.

Подводить итоги,

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

• для программного обеспечения, которое догоняет другое существующее программное обеспечение, требования, вероятно, будут заключаться в том, чтобы производить весь или большую часть набора функций существующего программного обеспечения и некоторые другие функции, которые разработчики / пользователи считают интересными иметь

• для исследовательских проектов, статей и других публикаций могут установить требования

• в техобслуживании ошибки, необходимость адаптации к новым средам могут быть основным источником требований

Я не знаю наверняка, но однажды предложено использовать Agile-подобную методологию, где требования поднимаются в виде билетов (или «карточек»), используя что-то вроде JIRA, где каждый билет представляет функцию или требование. Каждый билет затем может быть разложен на другие билеты, представляющие меньшие единицы работы.

Что касается фактического выяснения того, что должно делать приложение или часть программного обеспечения, то простой ответ - «поговорить с другими разработчиками». :) «Говорить» в этом случае может означать список рассылки электронной почты, форум или даже IRC, что угодно, что позволяет людям в разных часовых поясах и географических точках общаться.