Nella mia esperienza, il design tecnico è reso più difficile quando è separato dall'implementazione, in particolare assegnando i ruoli a persone diverse, perché è facile per il progettista trascurare una miriade di dettagli di implementazione / trucchi. In teoria, mi piace l'idea. Quindi la mia domanda è, dovremmo sforzarci per questa separazione?
No, la separazione non è una vittoria netta. In effetti, separare le decisioni di progettazione dall'atto di scrivere il codice probabilmente causerà più dolore per un progetto.
Mi sembra che tu stia usando "implementazione" per riferirsi all'atto di scrivere codice. In un processo sequenziale, come una cascata tradizionale, la fine del "design" è un insieme di artefatti che descrivono completamente il software che deve essere implementato. In questo ambiente, potresti avere un team di progettazione e un team di implementazione. Se le persone sono diverse, sarei d'accordo sul fatto che tu abbia ragione: è facile trascurare i problemi di "implementazione" (codice, generazione, implementazione) quando si fa il design. A meno che tu non conosca appieno l'ambiente - l'hardware, il sistema operativo e i pacchetti di terze parti disponibili, il linguaggio di programmazione utilizzato - è quasi impossibile trovare un progetto "definitivo" da parte di un team di progettazione disgiunto.
Se guardi allo sviluppo del software attraverso l'obiettivo di Lean Software Development , ci sono problemi con questa visione disgiunta del design e implementazione. Innanzitutto, è uno spreco. Il movimento (lo spostamento delle informazioni tra i team), l'attesa (i programmatori in attesa che i progettisti finiscano) e le attività di gestione (necessarie per coordinare queste due squadre) sono tutti considerati rifiuti. In secondo luogo, impedisce l'apprendimento, soprattutto se i programmatori non sono in grado di modificare e aggiornare gli elementi di progettazione e devono tornare al team di progettazione. In terzo luogo, impedisce di decidere in ritardo. In quarto luogo, impedisce di vedere il tutto come elementi del design può essere ideale sulla carta ma non realistico conoscere i dettagli dell'ambiente.
Questo è il motivo principale per cui i metodi agili enfatizzano i team interfunzionali.
Tuttavia, esiste un altro metodo per esaminare le cose.
Definisco "ingegneria dei requisiti" (o un termine simile, come "sviluppo dei requisiti") come le attività associate alla comprensione degli utenti, dell'ambiente e di ciò che il sistema o il software devono eseguire, insieme agli attributi di qualità obbligatori o desiderati. Definisco "design" le attività che portano alla creazione di qualcosa che soddisfa i requisiti. Mi associo alla convinzione che il codice sia design . "Implementazione" è ciò che viene fatto dai computer - utilizzando vari strumenti e script per compilare (se necessario), pacchetto e distribuire software in un modulo accessibile all'utente.
Questa visualizzazione si adatta molto meglio alla visualizzazione del metodo Lean Software Development e al metodo agile del mondo. Inoltre, rende effettivamente lo sviluppo del software più vicino ad altre discipline ingegneristiche.
Non esiste un taglio chiaro tra la progettazione tecnica e l'implementazione.
Pensa alle seguenti attività e prova a decidere se si tratta del lavoro di un designer:
e così via ...
Indipendentemente da dove lo taglierai, l''implementazione' includerà comunque 'design tecnico'.
Alcuni [esperti] persone possono affrontare meglio le "grandi" domande di architettura, mentre altri [esperti] possono affrontare meglio questioni più dettagliate. Tuttavia, nessuno si limita a "implementare".
A meno che tu non stia lavorando su sistemi mission-critical in sistemi di controllo di volo, rover Mars o sistemi di supporto alla vita umana, probabilmente farai molto più lavoro per te stesso cercando di separare completamente questi ruoli.
Qualsiasi cosa faccia il lavoro in modo ragionevolmente verificabile e gestibile, non renderla troppo dura a se stessa. Qualcosa che funziona "abbastanza bene" è generalmente molto meglio della soluzione perfetta mai completata.
Leggi altre domande sui tag design development-process