Chi dovrebbe scrivere il documento di progettazione tecnica? Il BA o lo sviluppatore? [chiuso]

A meno che il BA sia anche un architetto tecnico, dovrebbero preoccuparsi del "cosa fa" e non di "come lo fa". Di conseguenza, il BA scrive i requisiti e l'architetto tecnico scrive la soluzione e lo sviluppatore scrive il codice.

A volte (o abbastanza spesso) questi ruoli sono condivisi da qualcuno, quindi uno sviluppatore potrebbe anche essere l'artefice del proprio codice, o potrebbe essere un esperto in un'area che sta scrivendo il Tdd per un junior da sviluppare. Occasionalmente il BA sarà anche l'AT, ma solo se provengono da un background tecnico e non commerciale.

Dove lavoro ora, abbiamo un'autorità di progettazione tecnica che prende i requisiti di base dagli uomini d'affari e li trasforma in requisiti tecnici (cioè li rende sensibili), gli sviluppatori senior scrivono un documento di soluzione che dice come intendono soddisfare requisiti che il TDA esamina, quindi gli sviluppatori codificano tutto. I requisiti tecnici vengono utilizzati anche dal team di test per scrivere i loro test di sistema.

Al mio attuale lavoro, abbiamo BA che sono più inclini alla tecnologia rispetto a dove ho lavorato prima, ma non ci siamo mai aspettati che scrivessero documenti tecnici di progettazione. Gli sviluppatori hanno sempre scritto quelli e poi gli architetti li hanno firmati.

A sostegno del commento di xmojmr, tuttavia, vorrei sottolineare che mentre eravamo molto diligenti sulla documentazione durante la nostra era di cascata, abbiamo notato alcuni punti deboli con esso:

1. La documentazione tecnica doveva essere completata prima dell'avvio dello sviluppo. In realtà, il meglio che potevamo fare era documentare una supposizione istruita sui dettagli tecnici, e rivederla frequentemente man mano che lo sviluppo procedeva.
2. Gran parte di ciò che è stato inserito nel documento è stato stereotipato, e quindi ha avuto poco o nessun significato reale per nessuno.
3. Il pubblico previsto per il documento tecnico erano gli sviluppatori (chiunque avrebbe mantenuto il codice lungo la strada). A questo proposito, era assolutamente inutile. Qualcuno che avesse bisogno di risolvere un problema o di modificare un output non avrebbe trovato nulla di valore nel documento tecnico. Il tipo di dettaglio richiesto dai manutentori vive nel codice stesso. Se provi a rinforzare i tuoi documenti tecnici per avvicinarti al livello di dettaglio presente nel codice, non ti limiterai a duplicare lo sforzo, ma il codice e il documento inevitabilmente non verranno sincronizzati (probabilmente prima ancora della versione 1).

Quando siamo passati a un flusso di lavoro agile, abbiamo deliberatamente abbandonato i documenti tecnici e nessuno li manca. Aderiamo all'idea di "documentazione appena sufficiente", il che significa che se ci sono delle decisioni che devono essere scritte, o dei punti che devono essere spiegati, abbiamo un wiki per quel tipo di cose. Alcuni processi hanno ancora diagrammi di flusso formali, perché sono utili al proprietario del prodotto. Ma spostare l'attenzione dalla documentazione e più per soddisfare le esigenze dei clienti ha reso più felici tutte le parti interessate, e il prodotto è in realtà più stabile che mai.

La risposta a questa domanda dipende in gran parte dall'organizzazione di ciascuna azienda. Come accennato, l'ideale è che i documenti tecnici siano scritti dal Software Analyst, dopo aver discusso con gli sviluppatori / ingegneri del software del progetto. Tuttavia, quando non ci sono Architetti nel gruppo, il carico di lavoro deve essere condiviso. In altre parole, perché non smetti di scrivere i documenti tecnici come un peso e inizia a considerarlo una perfetta opportunità per ottenere maggiori conoscenze tecniche?

Secondo me, non puoi scrivere questo documento da solo, perché ti manca un notevole background tecnico. Tuttavia, né lo sviluppatore è pienamente in grado di scrivere un documento tecnico ben strutturato, dato che gli mancano altre qualità. Anche se lo sviluppatore è veramente qualificato e può scrivere un documento tecnico perfetto, penso che perderà una quantità significativa di tempo, che può essere speso molto più efficientemente nella fase di implementazione.

Quindi, ti suggerisco di scrivere il documento tecnico, dopo aver avuto più discussioni con lo sviluppatore. In questo modo, ci saranno 2 vantaggi: - Acquisirai conoscenze tecniche significative, ad es. intorno a schemi di progettazione, protocolli, ecc. Questa conoscenza sarà una risorsa importante per il tuo futuro. - La durata del progetto sarà più breve, poiché lo sviluppatore avrà più tempo per l'implementazione. E ti apprezzerà anche di più;)