Як ви стежите за складними правилами бізнесу поза кодом?

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

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

Було б дуже приємно зайти на ресурс, а не приводити архітектора чи BSA до розмови щоразу, коли виникає питання про те, як щось слід обробити.

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

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

Я розумію, що більшість місць або не мають письмових вимог, або вони не підтримуються, але це інша проблема. :-)

Ми використовували BPMN для документування та моделювання наших бізнес-процесів, якщо це саме ви маєте на увазі.

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