Come ti adegui alle modifiche alle specifiche del prodotto durante lo sviluppo?

Il tuo approccio parser è sicuramente un passo nella giusta direzione. Per gestire ciò che descrivi, devi seguire due principi di ingegneria del software ben noti nel modo più rigido possibile:

1. Un'unica fonte di verità

Hai scritto

changes ... need to be propagated to multiple places in the product's source code

Questo è esattamente l'opposto di "unica fonte di verità": dovrebbe esserci idealmente solo una one posizione da cambiare nel codice sorgente, nel database, o nella descrizione dell'interfaccia, o qualunque cosa dipenda da il cambiamento. Cerca di ridurre il numero di luoghi in cui un pezzo di informazione è memorizzato nel tuo ambiente, quindi non devi mantenerlo due volte.

Ogni volta che ciò non è possibile o fattibile, assicurati che le informazioni siano memorizzate in formato leggibile dalla macchina, magari includendo qualche tipo di metadati, per rendere possibile l'implementazione del secondo principio

2. Automazione ovunque

Ad esempio, ogni volta che si dispone di un'interfaccia da implementare in più punti, fornire una specifica di interfaccia in una forma leggibile dalla macchina e un generatore di codice che generi almeno il codice di scheletro per implementare tale interfaccia. Una specifica leggibile da una macchina in un foglio di calcolo è una delle molte soluzioni possibili, altri approcci che ho visto erano formati di testo specifici, linguaggi specifici di dominio, metadati gerarchici in formato XML o JSON, descrizioni in forma di database, diagrammi UML leggibili dalla macchina o qualsiasi altra cosa risulta essere adeguato per rendere possibile quanto sopra.

Naturalmente, è molto più semplice implementare queste idee fin dall'inizio di un progetto. Cambiare un'organizzazione che si è trovata in una situazione in cui le stesse informazioni hanno troppe rappresentazioni ridondanti in diversi punti della base di codice, che devono essere tutte modificate manualmente, può essere difficile, se non addirittura impossibile. Il primo passo potrebbe essere quello di creare una lista di controllo "se il cambiamento di tipo X si verifica nel documento, dobbiamo apportare modifiche manuali Y1, Y2, ..., Yn nei seguenti luoghi". Questa checklist può già essere utile per alcune persone. Il prossimo passo è analizzare perché tutti i passaggi Y1, ..., Yn sono necessari, puoi ridurre il numero di passaggi eliminando le informazioni duplicate o puoi automatizzare almeno il passo o parti di esso?

In base alla mia esperienza, puoi spesso migliorare almeno le parti: se trovi modi per non mantenere manualmente 6 posizioni nel codice, ma solo 3 quando si verifica un tipo specifico di richiesta di modifica, è comunque un miglioramento.

Limiti

Ciò che ho scritto si applica principalmente alla tua base di codice. Quando si tratta di elementi come "altri documenti specifici" o "manuali multilingue / materiali di marketing" , specialmente quando "appartengono a persone diverse" , in genere è impossibile ridurre lo sforzo manuale a zero. Tuttavia, ho fatto l'esperienza che, tenendo presente i principi di cui sopra, spesso si può ottenere un miglioramento anche con chiare "interfacce" tra i team di sviluppo e / o le persone che scrivono i documenti, che fanno le traduzioni, chi scrive le cose di marketing ecc.

Ad esempio, per i nostri materiali pubblicitari, spesso avevamo bisogno di screenshot aggiornati di parti specifiche dell'interfaccia utente del nostro prodotto, quindi abbiamo reso questo passaggio almeno semi-automatico. Assemblare tutti gli screenshot in un nuovo opuscolo è ancora un processo manuale, naturalmente, ma la maggior parte di questo lavoro può essere fatto senza uno sviluppo ora, e ne abbiamo rimosso alcune parti noiose e noiose.

La risposta di Doc Brown è un ottimo punto di partenza, quindi aggiungerò qualche altro suggerimento alla fine della sua lista.

Timeboxing e User Story

Queste due tecniche sono utilizzate insieme in diverse metodologie Agile. Il timeboxing (noto anche come sprint o iterazioni) è essenzialmente una garanzia sia per il business che per i lati di sviluppo che i requisiti fissati per un breve periodo verranno consegnati e possono quindi essere iterati. Questi diversi requisiti sono elencati nelle storie degli utenti che coprono l'intero ciclo di vita di un requisito dall'analisi allo sviluppo fino alla consegna.

Per i tuoi scopi, puoi impostare una finestra temporale (forse una settimana o due, forse un mese) in cui sono impostati i requisiti. Il vantaggio di questo è che, ad esempio, i quattro giorni in cui l'azienda va avanti e indietro su un particolare requisito sarebbero invisibili al team di sviluppo perché vedranno solo la modifica del requisito finale all'inizio della finestra temporale. Se l'azienda non ha raggiunto una decisione definitiva, attende fino alla prossima casella. Se l'azienda cambia idea a metà del tempo, quel cambiamento attende fino alla prossima volta, ma poiché le caselle del tempo sono brevi non è più di poche settimane.

Quando ricevi i requisiti per la casella del tempo, puoi utilizzare le storie degli utenti per tenere traccia di tutto ciò che deve essere fatto per un particolare requisito. La trama stessa delinea la caratteristica o il cambiamento desiderato, e le attività richieste per una storia utente possono essere scomposte sul retro della carta delle note (o nella descrizione della carta Trello, o come sottoattività JIRA, ecc.). Potresti anche essere in grado di generare una bozza di User story dai cambiamenti nel tuo foglio di lavoro. A seconda dei dati disponibili, potresti persino essere in grado di generare automaticamente alcune delle attività richieste (come i documenti da aggiornare) dal foglio di lavoro.

Modulare, SOLID Design

Quando si tratta del tuo codice, dovresti scriverlo in modo tale da non dover apportare modifiche ovunque cambino i requisiti. Realizzando parti piccole, focalizzate e intercambiabili, è possibile scrivere facilmente un nuovo codice e sostituirlo con le modifiche dei requisiti. Con il giusto tipo di design, puoi persino scambiare parti diverse in fase di esecuzione, il che significa che non devi sapere esattamente cosa sarà fino al momento in cui viene eseguito.

Avendo moduli piccoli e mirati, sarai anche in grado di organizzare la tua documentazione in parallelo. La documentazione per un particolare modulo deve essere modificata solo se sono state apportate modifiche a quel modulo. Ciò semplificherebbe tracciare ciò che deve essere aggiornato semplicemente facendo alcune domande sul software di controllo della versione. Le VC sono generalmente molto scriptable, quindi potresti persino essere in grado di racchiudere una piccola applicazione che può generare notifiche quando alcuni moduli cambiano. Dovresti già avere un sistema di notifica simile attorno ai tuoi test automatici per avvisarti quando il comportamento del sistema cambia.

Hai detto che hai a che fare con un sistema embedded, quindi questo potrebbe non essere applicabile a te in questa particolare istanza, ma man mano che il tuo codice diventa più modulare, potrebbe aver senso scomporlo completamente microservices che può essere sviluppato, gestito ed eseguito completamente separatamente. Se il carico diventa eccessivo, puoi trasferire quella piccola applicazione a un altro team da gestire.

Focus solo su documentazione preziosa

Sembra che ci sia molto di diversi documenti che devi conservare. Dovresti valutare quali di questi sono anche utili prima fai qualsiasi altra cosa. Non fa bene aggiornare in modo efficiente un documento che nessuno legge. I documenti che rigurgitano gli standard potrebbero non valere la pena se non aggiungono nulla al di sopra e al di là dei documenti standard.

Dovresti anche considerare come aggiornare i documenti nel modo più amichevole possibile. Ad esempio, Javadoc (se stavi usando Java) può essere convertito automaticamente da commenti di codice a documenti di sviluppo HTML. Gli sviluppatori hanno solo bisogno di commentare il loro codice in un particolare formato semplice, e si ottiene una vasta base di documentazione utile sull'altro lato. Per altri documenti, potrebbe non essere possibile essere completamente automatico, ma è possibile automatizzare la generazione di una serie di schermate per la documentazione per l'utente finale e i materiali di marketing. Eseguendo l'output di formati portatili e parsabili, è possibile che alcuni materiali possano essere riusabili in diversi contesti.