Gli sviluppatori devono comprendere il dominio aziendale o la specifica dovrebbe essere sufficiente?

Le specifiche non sono praticamente mai sufficienti. Gli sviluppatori che non hanno conoscenze di dominio non possono indicare quando la specifica è in errore (un luogo frequente nella maggior parte dei casi) e fanno scelte di progettazione scadenti.

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

Il problema essenziale dipende dall'impedenza dello sviluppatore del client: vogliono qualcosa ma lo sapranno solo quando lo vedranno e vorrai risolvere il problema, ma non sempre potranno avere un'idea chiara di quale sia il problema. Più la conoscenza del dominio del settore (del cliente) che tu (lo sviluppatore) può portare, più facile è tradurre i "desideri" vaghi in "problemi" concreti e risolverli.

Come esempio aneddotico, il mio precedente lavoro era nell'industria chimica che coinvolge software di gestione degli impianti. Ho iniziato con una conoscenza a zero del dominio, ma sono riuscito a implementare il codice necessario per risolvere i problemi secondari presentati dallo sviluppatore senior e dai clienti. Col tempo, ho fatto lo sforzo di imparare l'industria, in modo che potessi comunicare più facilmente a livello del cliente. Mentre comprendevo la loro industria, 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 intendono, che è "abbiamo bisogno di tenere una registrazione storica di ogni valore generato da questo sensore, conservato per X giorni di conservazione, ma sempre valutata in base alla lettura più recente di quel sensore. " Molti problemi di dominio hanno regole nascoste (come i periodi di conservazione sui dati) che i client hanno internalizzato, ma è necessario renderle esplicite.

Quindi sì, qualcuno ha bisogno della conoscenza del dominio e preferibilmente uno sviluppatore perché i problemi del dominio non sono problemi di codice e la traduzione tra i due non è banale. Alla fine, tutti gli sviluppatori che valgono la pena di tenere il tuo team dovrebbero raccogliere 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 potrebbe essere o non essere lo sviluppatore.

Nei progetti Agile, il proprietario del progetto client è quella persona e lavorano in stretta collaborazione con il team. Nei progetti non Agile, qualcuno del team deve acquisire tale conoscenza, ma in genere non lo fa, il che è uno dei motivi per cui i progetti non Agile sono così soggetti a errori.

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

Se al team non vengono fornite sufficienti persone con competenze sufficienti per l'autorizzazione e il dominio, prima o poi gli errori inevitabilmente si insinueranno. Data la conoscenza del dominio, ci sono valori / risultati / relazioni non sensoriali o non sensoriali. Si potrebbe sperare che una specifica li punti 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 non essere un errore ma è abbastanza strano da essere degno di nota).

Questo è strongmente correlato alla comprensione delle ragioni delle scelte e, nei casi migliori, porta anche a un software migliore (perché se si conosce davvero la ragione di una richiesta, è in grado di pensarci, piuttosto che doverlo accettare come dato).

Ricorda che Einstein ha detto "Ma il pensiero e le idee, non le formule, sono l'inizio di ogni teoria fisica." , questo è quello che non si pensa 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 sarebbe in grado di tradurre dal giapponese all'inglese, nonostante siano esperti nelle loro rispettive lingue. Per lo stesso motivo, anche i programmatori esperti senza conoscenza di dominio sono incapaci di capire cosa devono costruire, anche quando hanno un accesso 24 ore su 24, 7 giorni su 7, al migliore esperto di domini che non sia anche un esperto nello sviluppo del software.

Una specifica è un tentativo di tradurre "giapponese" dei requisiti del 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 la conoscenza del dominio alcuni . Con una certa persistenza, 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 molto, quindi è una situazione win-win.

Senza alcuni aspetti della conoscenza del business si finisce con gli sviluppatori che non fanno domande e codificano senza scrupoli quello che dicono le specifiche. Credo che i "Pensatori" servano per fare del buon software, non solo delle persone che sanno suonare con la tastiera. Comprendere non solo "cosa" stai facendo ma "perché" e come si inserisce nell'immagine più grande aiuta a fornire una maggiore soddisfazione per il team di sviluppo.

Penso che dovresti cercare di ottenere la conoscenza del dominio. Le specifiche sono la lista di controllo che dice cosa dovrebbe 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 in quanto capirai quali sono le parti che cambiano (ad esempio il set di regole) e le metti separatamente. Non è necessario essere un maestro, ma sarebbe in grado di parlare con un utente finale nella loro lingua .

Puoi guidare un'auto con una conoscenza di base; ma nel caso tu voglia goderti il viaggio devi imparare di più su come usarlo esattamente. Come per altre operazioni, non è obbligatorio comprendere il dominio, ma è divertente quando lo fai .

Penso che uno sviluppatore che conosce il business valga il suo peso in oro.

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

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

2. Uno o tutti i titolari di attività, analisti aziendali o sviluppatori sono abbastanza nuovi per l'organizzazione da non riuscire a trovare gli elementi chiave a cui non penserebbero normalmente. Lo sviluppatore esperto che conosce bene l'attività può farlo aiuta a educare le persone in quegli altri ruoli a fare il prodotto più completo.

Ci sono quasi sempre dei compromessi tra il valore di ciascuna caratteristica nella specifica, la precisione con cui le specifiche devono essere implementate e il costo per soddisfare qualsiasi combinazione di caratteristiche specifiche. Spesso i buoni compromessi possono essere fatti solo quando la conoscenza di fare tutto quanto sopra esiste in una sola persona, o in un gruppo strettamente funzionante, incluso l'attuale architetto e / o programmatore del software.

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

Il costo della creazione di una specifica che non ha i problemi di cui sopra può spesso essere maggiore della formazione dell'architetto e / o dei programmatori di avere una conoscenza del dominio sufficiente per lavorare con una specifica meno imperscrutabile (supponendo che gli aspetti legali e commerciali consentano questo ).

Più è coinvolto uno sviluppatore e più è senior nel business, più diventa importante avere almeno una conoscenza di dominio di medio livello o le aree più sfumate di quel settore che potrebbero essere critiche non saranno comprese dal team di sviluppo.

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

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

Ci dovrebbe sempre essere alcune 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 che cosa serve, il risultato potrebbe non essere quello che vogliono i clienti. Succede spesso che quando uno sviluppatore ha un livello di comprensione abbastanza decente (ma non esperto), può cogliere errori ed omissioni nelle specifiche. Possono anche contribuire e dare feedback al processo che può migliorare molto il prodotto finale.

Potrebbe valere la pena di assumere alcuni esperti di dominio il cui compito è quello di fare il collegamento tra i client e gli sviluppatori per aiutare gli sviluppatori a capire meglio e anche per aiutare a scrivere le specifiche.

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

È difficile vedere come, per esempio, uno sviluppatore freelance possa comprendere 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 di impresa d'altra parte, supponendo che siano stati nella stessa azienda per un po ', avrebbe dovuto davvero imparare come funziona l'azienda dopo alcuni mesi (o forse anni). In un team di grandi dimensioni potresti anche avere un architetto che comprende il business in modo più chiaro rispetto agli sviluppatori.

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

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

Lo sviluppo del software è l'unica professione che conosco che richiede che tu non solo sia competente nella tua professione ma abbia una conoscenza di base della professione in cui lavori. È importante avere una comprensione sufficiente del dominio per comunicare con i clienti e altri sviluppatori nella lingua del cliente. Come sviluppatore non puoi sempre contare sugli altri per allenarti. A volte devi farcela da solo con ricerche personali, spesso volte al di fuori delle ore di lavoro tipiche.

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 più probabilità di trovare la soluzione ottimale per un problema rispetto a due individui, uno con ottima conoscenza del dominio del problema e uno con un'eccellente conoscenza dello sviluppo del software, lavorando insieme.

Penso che dipenda semplicemente dal 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 lavorando per rispondere a questa domanda è di 10 anni spesi per lo sviluppo di un pacchetto software di contabilità (dall'inizio alla "modalità di manutenzione"). Sebbene la mia conoscenza dello sviluppo del software fosse piuttosto buona, rispetto ai miei colleghi, mi sentivo spesso ostacolato da una mancanza di comprensione del dominio del problema.

Mi piacerebbe rispondere come qualcuno che proviene dal lato degli affari, che lavora con sviluppatori che mostrano poco interesse nell'apprendere le basi del commercio, a volte sembra addirittura orgoglioso di non dover sapere di quelle basi: il problema è che gli sviluppatori non saranno in grado di vedere gli errori nel risultato a prima vista (risultati inspiegabili, segni sbagliati e così via), che richiede o casi di test dettagliati (che non abbiamo sviluppato fino a poco tempo fa), o una supervisione costante del risultati. Pertanto, per quanto io sia disposto a imparare le basi dello sviluppo del software per facilitare la comunicazione, vorrei invitare gli sviluppatori a fare lo stesso.

Non devi, ma perché non vuoi?

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

Scrivere il codice senza avere alcuna idea di come sia usato e per quale motivo sembra proprio un lavoro terribile. Chi vuole rompere i mattoni quando potresti costruire cattedrali?

Capisco davvero cosa intendi qui perché noi, come azienda in un settore del turismo, abbiamo affrontato lo stesso problema. Quando ero uno sviluppatore junior, stavo anche studiando turismo in un college. Quindi, puoi supporre che io non vengo da un passato di informatica, ma la mia conoscenza del turismo è alta.

All'epoca stavamo costruendo dei prodotti in relazione con altre società di software, ma la conoscenza specifica del dominio era carente. Come hai descritto, è davvero difficile farlo bene se stai costruendo un prodotto nell'industria del turismo perché ci sono molte preoccupazioni trasversali, ecc.

Quindi, questo movimento ha dato molti risultati negativi 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 prendere decisioni più velocemente poiché ho l'esperienza su entrambi i lati della medaglia.

Come risposta concreta alla tua domanda, è certamente sì nella mia opinione personale. Se il progetto su cui sta lavorando il tuo team è un progetto a lungo termine, allora prendi la strada difficile e istruisci il tuo staff su fondamentali e dettagli specifici del dominio.

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

Alcune aziende riconoscono e forniscono formazione nel "business". Le società finanziarie sono un buon esempio di questo.

Più apprendi l'attività, più diventa facile parlare ai tuoi utenti. Sentiranno più fiducia in te. Capirai più facilmente le stranezze su dove un sistema 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 hanno addirittura messo al di sopra delle effettive competenze tecniche. (Nessuna esperienza finanziaria, nessuna intervista è molto comune, certamente qui nel Regno Unito).

Per esperienza personale, le specifiche sono sufficienti a condizione che qualcuno con il team che lavora con te abbia conoscenza del dominio.

Lavoro in un settore molto specializzato: realizziamo software per i media di trasmissione. So a malapena una cosa della trasmissione, ma conosco il codice e conosco i dati, e ho una brava gente nel team di gestione del progetto che capisce le trasmissioni. Quella formula è stata abbastanza buona per gli ultimi anni per me per trovare una buona funzionalità che piacciono ai clienti.