Gli sviluppatori devono comprendere il dominio aziendale o le specifiche dovrebbero essere sufficienti?

Lavoro per un'azienda per la quale il dominio è davvero difficile da capire perché è un'alta tecnologia in elettronica, ma questo è applicabile a qualsiasi sviluppo software in un dominio complesso.

L'applicazione su cui lavoro visualizza molte informazioni, grafici e metriche che sono difficili da capire senza esperienza nel dominio. Lo sviluppatore utilizza una specifica per descrivere cosa deve fare il software, come specificare che un particolare grafico deve visualizzare questo tipo di metriche e questa metrica è la seguente formula aritmetica.

In questo modo, lo sviluppatore non capisce veramente il business e cosa / perché sta facendo questo compito. Questo può essere OK se la specifica è veramente dettagliata ma quando non lo è o quando l'autore ha dimenticato un caso d'uso, è abbastanza difficile per lo sviluppatore trovare una soluzione.

D'altro canto, formare ogni sviluppatore su tutti gli aspetti aziendali può essere molto lungo e difficile.

Dovremmo dare maggiore importanza alle specifiche dettagliate (ma come sappiamo, non esistono specifiche perfette) o dovremmo addestrare tutti gli sviluppatori a comprendere il dominio aziendale?

EDIT: tieni presente nella tua risposta che la società potrebbe utilizzare sviluppatori esterni e che una formazione per tutto il dominio può durare circa 2 settimane

Le specifiche non sono praticamente mai sufficienti. Gli sviluppatori che non hanno una conoscenza del dominio non possono indicare quando le specifiche sono errate (una presenza frequente nella maggior parte dei luoghi) e fare scelte di progettazione inadeguate.

Nella mia esperienza, avendo lavorato in 3 settori molto diversi ora, puoi iniziare a non conoscere molto il dominio, ma alla fine dovrai impararlo e qualcuno dovrà capirlo in modo dettagliato.

Il problema essenziale è l'impedenza cliente-sviluppatore: vogliono qualcosa, ma lo sapranno solo quando lo vedono e vuoi risolverlo, ma non puoi sempre avere un'idea chiara di quale sia il problema. Maggiore è la conoscenza del dominio del settore (del cliente) che l'utente (lo sviluppatore) può offrire, più facile è possibile tradurre vaghi "desideri" in "problemi" concreti e risolverli.

Come esempio aneddotico, il mio lavoro precedente era nell'industria chimica con software di gestione degli impianti. Ho iniziato con una conoscenza del dominio effettivamente pari a zero, ma sono stato in grado di implementare il codice necessario per risolvere i problemi secondari presentati dallo sviluppatore senior e dai clienti. Nel corso del tempo, ho fatto lo sforzo di apprendere il settore, in modo da poter comunicare più facilmente a livello del cliente. Quando ho capito il loro settore, ho iniziato a capire quali fossero i problemi reali. Quando dicono cose come "dobbiamo tenere traccia di tutti i valori dei dati su questo modulo" posso tradurlo in ciò che realmente significano, che è "dobbiamo tenere un registro storico di ogni valore generato da questo sensore, memorizzato per X giorni di ritenzione, ma sempre valutata in base alla lettura più recente di quel sensore. "

Quindi sì, qualcuno ha bisogno di conoscenza del dominio, e preferibilmente uno sviluppatore perché i problemi di dominio non sono problemi di codice e la traduzione tra i due non è banale. Alla fine, qualsiasi sviluppatore che valga la pena di mantenere nel proprio team dovrebbe acquisire il dominio, in modo che possano fare scelte più informate sulle sfumature del loro codice.

QUALCUNO sul progetto deve avere una conoscenza del dominio abbastanza completa. Quella persona può o meno essere lo sviluppatore.

Nei progetti Agile, il proprietario del progetto client è quella persona e stanno collaborando e in stretta collaborazione con il team. Nei progetti non Agili, qualcuno nel team deve acquisire tali conoscenze, ma di solito non lo fanno, motivo per cui i progetti non Agili sono così inclini al fallimento.

Ci sono molte risposte eccellenti. Aggiungo il mio perché dopo averli letti e cercati ho scoperto che nessuno menziona un problema chiave: i bug .

Se al team non vengono fornite abbastanza persone con sufficiente autorità e competenza nel dominio, prima o poi si insinueranno inevitabilmente dei bug. Data la conoscenza del dominio, ci sono valori / risultati / relazioni impossibili o non sensati. Si potrebbe sperare che una specifica li evidenzi esplicitamente, ma in realtà il meglio che puoi raggiungere è quello di evitare quelli più ovvi (avvisami se i tassi di interesse diventano negativi, o cose del genere - questo potrebbe essere o potrebbe non essere un errore ma è abbastanza strano da essere degno di nota).

Ciò è fortemente correlato alla comprensione delle ragioni delle scelte e, nel migliore dei casi, porta anche a un software migliore (perché se si conosce effettivamente il motivo dietro una richiesta, è in grado di pensarci, piuttosto che accettarlo come un dato ).

Ricorda che Einstein disse "Ma il pensiero e le idee, non le formule, sono l'inizio di ogni teoria fisica" , cioè che si pensa non in termini di formule astratte ma di idee ...

Se metti una persona che conosce solo l'inglese e una persona che conosce solo il giapponese in una stanza, non sarebbero in grado di tradurre dal giapponese all'inglese, nonostante siano esperti delle rispettive lingue. Per lo stesso motivo, anche i programmatori esperti senza conoscenza del dominio non sono in grado di capire cosa devono costruire, anche quando hanno un accesso 24x7 al miglior esperto di dominio che non è anche un esperto nello sviluppo di software.

Una specifica è un tentativo di tradurre "giapponese" dei requisiti di dominio in "inglese" dei requisiti di programmazione. Quando ottieni una qualità di traduzione paragonabile a quella di Google Translate, è il tuo giorno fortunato; il più delle volte, la qualità non è proprio lì, quindi non hai modo di acquisire almeno alcune conoscenze del dominio. Con un po 'di perseveranza, ti rende un "traduttore" decente entro la fine del progetto, quindi il tuo valore per la tua azienda cresce in modo significativo. Il più delle volte, ti diverti anche molto nel processo, quindi è una situazione vantaggiosa per tutti.

Senza qualche aspetto della conoscenza del business finirai con gli sviluppatori che non fanno domande e codificano incautamente ciò che dicono le specifiche. Credo che ci voglia "Pensatori" per creare un buon software, non solo persone in grado di battere sulla tastiera. Comprendere non solo "Cosa" stai facendo, ma "Perché" e come si inserisce nel quadro generale, aiuta a fornire maggiore soddisfazione al team di sviluppo.

Penso che dovresti provare a ottenere la conoscenza del dominio. Le specifiche sono un elenco di controllo che indica cosa deve fare il prodotto finale ed è necessario per la convalida del prodotto. Come sviluppatore dovresti sempre cercare di capire qual è il vero problema che stai cercando di risolvere. Ottenere la conoscenza del dominio ti aiuterà a capirlo.

Ti aiuterà a progettare e codificare facilmente poiché capirai cosa stanno cambiando le parti (diciamo set di regole) e le metterai separatamente. Non è necessario essere un maestro in questo, ma sarebbe in grado di parlare con un utente finale nella loro lingua .

Puoi guidare un'auto con le sue conoscenze di base; ma nel caso in cui desideri goderti il ​​viaggio, devi imparare di più su come usarlo esattamente. Come con altre operazioni, non è obbligatorio comprendere il dominio, ma è divertente quando lo fai .

Penso che uno sviluppatore che conosce l'azienda valga il suo peso in oro.

In uno scenario "tradizionale" in cui l'azienda ha alcuni requisiti e alcuni analisti aziendali li traducono in requisiti tecnici, lo sviluppatore lavora su quelli che inevitabilmente hanno due cose che possono accadere:

1. Hai più punti di errore. L'analista aziendale potrebbe non aver tradotto perfettamente tutti i requisiti aziendali e / o lo sviluppatore potrebbe non tradurli perfettamente in una specifica tecnica. Una variante allo scenario "segreto intorno alla stanza". Solo le esigenze della comunicazione.

2. Uno o tutti i proprietari, analisti o sviluppatori sono abbastanza nuovi nell'organizzazione da perdere elementi chiave a cui non avrebbero pensato normalmente. Lo sviluppatore esperto che conosce bene il business può aiutare a educare le persone in quegli altri ruoli per rendere il prodotto più completo.

Ci sono quasi sempre dei compromessi da fare tra il valore di ciascuna funzionalità nella specifica, la precisione con cui la specifica deve essere implementata a valore e il costo per soddisfare qualsiasi combinazione di caratteristiche della specifica. Spesso buoni compromessi possono essere fatti solo quando la conoscenza per fare tutto quanto sopra esiste in una persona o in un team che lavora a stretto contatto, compreso l'architetto e / o il programmatore del software reale.

Senza una tale conoscenza estremamente localizzata e forse persino sentimenti di intestino, il risultato può facilmente finire come un prodotto molto costoso quasi inutile che soddisfa molto da vicino le specifiche scritte.

Il costo di creazione di una specifica che non presenta i problemi di cui sopra può spesso essere maggiore della formazione dell'architetto e / o dei programmatori per avere una conoscenza del dominio sufficiente per lavorare con una specifica meno imperscrutabilmente dettagliata (presupponendo che le legalità e i contratti aziendali lo consentano).

Sì, gli sviluppatori devono conoscere il business in una certa misura. Non devono conoscere ogni minimo dettaglio, ma dovrebbero avere una conoscenza di base per quale report X viene utilizzato e come viene utilizzato nel processo aziendale. Più i tuoi sviluppatori comprendono sul business, migliore è la soluzione che possono offrire.

Sulla base della mia esperienza *, un singolo individuo con una buona conoscenza del dominio del problema e una buona conoscenza dello sviluppo del software ha maggiori probabilità di trovare la soluzione ottimale a un problema rispetto a due individui, uno con una conoscenza eccellente del dominio del problema e uno con conoscenza eccellente di sviluppo software, lavorando insieme.

Penso che dipenda dal semplice fatto che la comunicazione che avviene nel cervello di un singolo individuo è molte volte più veloce e migliore della comunicazione tra individui.

* L'esperienza principale a cui sto attingendo per rispondere a questa domanda è di oltre 10 anni trascorsi nello sviluppo di un pacchetto software di contabilità (dall'avvio alla "modalità di manutenzione"). Sebbene la mia conoscenza dello sviluppo del software fosse piuttosto buona, rispetto ai miei colleghi, mi sentivo spesso handicappato dalla mancanza di comprensione del dominio del problema.

Vorrei rispondere come qualcuno proveniente dal lato aziendale, che lavora con sviluppatori che mostrano scarso interesse nell'apprendimento delle basi del commercio, a volte sembrano persino essere orgogliosi di non dover conoscere queste basi: Il problema è che il gli sviluppatori non saranno in grado di vedere gli errori nel risultato a prima vista (risultati inspiegabili, segni sbagliati e così via), che richiedono casi di test dettagliati (che non abbiamo sviluppato fino a poco tempo fa) o supervisione costante dei risultati. Nella misura in cui sono disposto a imparare le basi dello sviluppo del software per facilitare la comunicazione, vorrei esortare gli sviluppatori a fare lo stesso.

Non è necessario, ma perché non dovresti?

Sarei preoccupato per qualsiasi programmatore che fosse riluttante e soprattutto incapace di imparare il dominio in una certa misura. È importante uscire di tanto in tanto dalla "torre del codice d'avorio".

Scrivere codice senza avere idea di come venga utilizzato e per quale scopo sembra un lavoro terribile. Chi vuole rompere i mattoni quando potresti costruire cattedrali?

Quanto più uno sviluppatore diventa coinvolto e tanto più senior nel business tanto più diventa importante avere almeno una conoscenza di dominio di livello medio o le aree più sfumate di quel settore che possono essere critiche non saranno comprese dal team di sviluppatori.

Tuttavia, una specifica dovrebbe essere sufficiente per compiti di livello inferiore. In breve, è meglio addestrare la tua forza lavoro a un livello inferiore. Potrebbero essere i migliori programmatori poliglotta al mondo, ma se non riescono a comprendere il problema in modo abbastanza approfondito, sono sempre condannati al fallimento o alla programmazione della marcia della morte.

Dovrebbero esserci sempre delle specifiche: non puoi aspettarti che tutti gli sviluppatori diventino esperti di dominio. Allo stesso tempo, se gli sviluppatori seguono ciecamente una specifica senza capire veramente a cosa serve, il risultato potrebbe non essere quello che vogliono i clienti. Accade spesso che quando uno sviluppatore ha anche un livello di comprensione piuttosto decente (ma non esperto), può rilevare errori e omissioni nelle specifiche. Possono anche contribuire e fornire feedback al processo che può rendere il prodotto finale molto migliore.

Potrebbe valere la pena assumere alcuni esperti di dominio il cui compito è stabilire un legame tra i clienti e gli sviluppatori per aiutare gli sviluppatori a comprendere meglio e anche per scrivere le specifiche.

Penso che sia difficile dare una risposta in entrambi i modi.

È difficile vedere come, per esempio, uno sviluppatore freelance possa capire il business (o la scienza) dietro ogni singola applicazione che sviluppano. In questa situazione, penso che sia più importante che lo sviluppatore sappia porre le domande giuste sulle specifiche o sul modello di business piuttosto che capire veramente il business stesso.

Uno sviluppatore d'impresa, d'altra parte, supponendo che siano stati nella stessa attività per un po ', avrebbe davvero dovuto imparare come funziona l'azienda dopo alcuni mesi (o forse anni). In team di grandi dimensioni potresti anche avere un architetto che capisce il business più chiaramente degli sviluppatori.

Nelle PMI con sviluppatori solitari è importante che lo sviluppatore abbia frequenti discussioni con i proprietari / gestori per evitare di uscire e implementare la cosa sbagliata.

Quindi ci sono molti modi possibili di pensare a questo, ma la chiave è la stessa in tutti i casi: la comunicazione .

Lo sviluppo del software è l'unica professione che conosco che richiede non solo di essere esperto nella propria professione, ma di avere una conoscenza di base della professione in cui si sta lavorando. È importante avere una comprensione sufficiente del dominio per comunicare con i clienti e altri sviluppatori nella lingua del client. Come sviluppatore non puoi sempre fare affidamento su altri per allenarti. A volte devi accelerare da solo con la ricerca personale, spesso volte al di fuori del normale orario di lavoro.

Capisco davvero cosa intendi qui perché noi, in quanto azienda del settore turistico, abbiamo affrontato lo stesso problema. Quando ero uno sviluppatore junior, studiavo anche turismo in un college. Quindi, puoi immaginare che non vengo da un background informatico ma le mie conoscenze turistiche sono alte.

All'epoca stavamo costruendo prodotti in relazione con altre società di software, ma mancava molto la conoscenza specifica del dominio. Come hai descritto, è davvero difficile farlo bene se stai costruendo un prodotto nel settore turistico poiché ci sono molte preoccupazioni trasversali, ecc.

Quindi, questo movimento ha dato molti cattivi risultati a lungo termine. Quindi, abbiamo fatto un enorme passo avanti e ho iniziato a concentrarmi solo sullo sviluppo piuttosto che sulla parte commerciale del progetto. Poiché ho le conoscenze industriali e le conoscenze di programmazione, il progetto diventa più efficiente che mai. Per non parlare, possiamo quindi prendere le decisioni più velocemente dato che ho l'esperienza su entrambi i lati della medaglia.

Come risposta concreta alla tua domanda, è certamente sì a mio parere personale. Se il progetto a cui il tuo team sta lavorando è un progetto a lungo termine, prendi la strada giusta e addestra il tuo personale su fondamenti e dettagli specifici del dominio.

Se uno sviluppatore rimane in un'azienda / settore per un lungo periodo di tempo, imparerà lentamente ma sicuramente "il business".

Alcune aziende riconoscono e forniscono formazione in "the business". Le società finanziarie ne sono un buon esempio.

Più impari il business, più facile diventerà parlare con i tuoi utenti. Sentiranno più fiducia in te. Capirai più facilmente le stranezze di un sistema che potrebbe andare storto se non funziona come previsto per l'utente.

Per rispondere alla tua domanda, la specifica non è MAI sufficiente nella mia esperienza. Il problema comune è che spesso non contengono informazioni sufficienti e si aggiornano rapidamente.

L'esperienza del dominio aziendale può essere obbligatoria per alcune aziende. Cercano sviluppatori con esperienza nel dominio durante l'assunzione. Alcune aziende lo mettono persino più in alto rispetto alle effettive competenze tecnologiche. (Nessuna esperienza finanziaria, nessuna intervista è molto comune, sicuramente qui nel Regno Unito).

Per esperienza personale, le specifiche sono sufficienti fintanto che hai qualcuno nel team che lavora con te che abbia le conoscenze del dominio.

Lavoro in un settore molto specializzato: realizziamo software per la trasmissione multimediale. So a malapena qualcosa sulla trasmissione, ma conosco il codice e conosco i dati, e ho una buona squadra nel team di gestione del progetto che capisce la trasmissione. Quella formula è stata abbastanza buona negli ultimi anni per me inventare una buona funzionalità che piace ai clienti.