Як визначаються вимоги в програмних проектах з відкритим кодом?

У корпоративній розробці корпоративного програмного забезпечення прийнято визначати вимоги за допомогою формального процесу, що призводить до створення низки документів з вимогами. У розробці програмного забезпечення з відкритим кодом це, здається, часто відсутнє. Отже, моє запитання: як визначаються вимоги в проектах з відкритим кодом?

Під «визначенням вимог» я просто маю на увазі «з'ясування того, які функції тощо слід розробляти як частину конкретного програмного забезпечення».

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

Якщо у вашому проекті є 100 користувачів, ви, ймовірно, можете розробляти все, що найцікавіше кодувати.

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

За допомогою цього зворотного зв’язку ви можете написати необхідні документи для вашої основної команди, створити дорожні карти, щоб допомогти незалежним учасникам зрозуміти ваше бачення та сподіватися, що хтось із 100 тис. Користувачів відправить виправлення.

Я слідкую за відкритим кодом, оскільки я вперше почув про Linux приблизно в 1995 році, і не можу пригадати, щоб коли-небудь чули слово "вимоги", яке використовується в цьому контексті.

Ерік Реймонд має хороший нарис «Собор і базар» , в якому він говорить про «подряпини власного свербіння». Якщо ви намагаєтеся вирішити проблему, з якою ви стикаєтесь особисто, вам не доведеться посилатися на документи вимог, щоб з’ясувати, вирішили ви її чи ні.

Цей самий твір також говорить про прослуховування ваших користувачів, що є гарною порадою для всіх, а не лише проектів з відкритим кодом. Проекти з відкритим кодом, як правило, є меритократичними, тому "той, хто пише код, робить правила", більш-менш.

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

На мій досвід, це набагато частіше зустрічається при розробці контрактів, особливо коли зовнішня компанія займається розробкою для вашої компанії, і існує юридична потреба у контракті. Але багато інших компаній по-іншому контролюють розвиток своїх будинків власними людьми:

• неформальне спілкування

• пріоритетні вимоги / помилки / випуски / списки квитків (а це, безумовно, не є винаходом від "спритної" спільноти)

Це саме так, як працюють більшість проектів з відкритим кодом - оскільки немає необхідності в офіційному контракті, ніхто не намагається розробити великі, детальні, формальні документи з вимогами, лише невеликі, безболісні списки відсутніх функцій або квитки, зібрані у випуску трекер, який потрібно вирішити.

Якщо проблема є звичайною, наприклад, написанням компілятора чи браузера, вимоги в значній мірі задаються у вигляді мовних стандартів, цільових операційних систем та цільового обладнання тощо.

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

Якщо програмне забезпечення наздоганяє функцію, доступну лише в програмному забезпеченні без відкритого коду, ця вимога знову багато в чому задається.

Редагувати:

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

У проекті, заснованому на повністю дослідженні, як GNU Hurd, я думаю, що вимоги випливають з результатів дослідження та робіт.

Підсумовуючи,

• при запуску вимоги до програмного забезпечення, яке намагається вирішити загальні проблеми, можуть виходити з стандартних документів

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

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

• коли в обслуговуванні, помилки, необхідність адаптації до нових середовищ можуть стати головним джерелом вимог

Я точно не знаю, але колись пропонуються використовувати методологію Agile, де вимоги піднімаються як квитки (або "картки"), використовуючи щось на зразок JIRA, при цьому кожен квиток представляє особливість або вимогу. Кожен квиток можна потім розкласти на інші квитки, що представляють менші одиниці роботи.

Що стосується насправді з'ясування того, що має робити програма чи фрагмент програмного забезпечення, то проста відповідь - "розмова з іншими розробниками". :) "Розмова" в цьому випадку може означати список розповсюдження електронної пошти, форум або навіть IRC - все, що дозволяє людям у різних часових поясах та географічних місцях спілкуватися.