Come tenere traccia di regole aziendali complesse al di fuori del codice?

Sono interessato a vedere come fanno gli altri. Soprattutto nelle situazioni in cui più client diversi utilizzano la stessa base software con regole aziendali leggermente diverse. Che tipo di pratiche usi per documentare come tutto dovrebbe funzionare o regole aziendali.

Fondamentalmente, quindi, quando arriva un nuovo sviluppatore, il team ha un facile accesso per vedere come dovrebbero funzionare le cose perché c'è ovviamente una differenza tra rendere qualcosa privo di bug e far funzionare correttamente qualcosa.

Sarebbe davvero bello andare alla risorsa piuttosto che dover portare un architetto o BSA nella conversazione ogni volta che sorge una domanda su come qualcosa dovrebbe essere elaborato.

Questo è uno dei casi d'uso per i framework BDD, come Cucumber, che consente di acquisire i requisiti aziendali nel codice e testarli frequentemente rispetto a tali requisiti. Altri approcci che ho visto usati includono documenti di specifiche lunghi e complicati, grandi fogli di carta attaccati al muro, mazzi di diapositive e Joe, il ragazzo alla fine del tavolo che sa tutto.

Penserei, quanto meno, che questi sarebbero documentati e mantenuti nel documento dei requisiti.

Mi rendo conto che la maggior parte dei luoghi o non hanno requisiti scritti o non sono mantenuti, ma questo è un problema diverso. :-)

Abbiamo utilizzato BPMN per documentare e modellare i nostri flussi di lavoro aziendali se è questo che intendi.

Abbiamo anche cercato di utilizzare un motore del flusso di lavoro in un progetto per consentire agli utenti di partecipare alla modellazione, ma questo ha colpito un po 'di resistenza perché avevano troppa paura di rompere le cose, anche se la modellazione è stata eseguita insieme a uno specialista del flusso di lavoro del nostro Dipartimento IT.