Il design in una squadra, la codifica in un'altra

La mia opinione:

Se tutto ciò che darai alle persone in mare aperto sono documenti e diagrammi, avrai un sacco di incomunicabilità e delusione .

Il mio consiglio

• Non fornire loro così tanti documenti, ma piuttosto interfacce e classi astratte per per metterli a punto negli obiettivi di progettazione .

• Richiedili di utilizzare uno standard di denominazione conosciuto.

• Richiede che usino i test unitari.

• Invia uno dei tuoi designer / architetti offshore alle loro sedi per supervisionare il processo, sarà comunque più economico rispetto alla programmazione in-house, ma otterrai risultati migliori.

Si chiama Big Design Up Front, alias Waterfall. Non è ampiamente considerato come una metodologia di grande successo. Ma l'ho visto funzionare e, quando funziona, funziona molto bene. È molto costoso fare bene.

È anche ciò che i tuoi datori di lavoro ti hanno chiesto di fare.

I team offshore non funzionano come fanno i team di terra. Devi essere molto, molto specifico su esattamente ciò che vuoi, altrimenti non otterrai ciò che desideri.

L'ultimo progetto ero il progettista del software. Tutto lo sviluppo era al largo. Abbiamo avuto successo Quindi questo processo può funzionare.

Ho prodotto molta documentazione ma non è stato affatto esauriente e in nessun modo istruzioni passo passo o dettagliate fino ai nomi di classi, nomi di funzioni, ecc. Per esempio, ho prodotto diagrammi di sequenza, casi d'uso, flussi di lavoro, sistema e diragram di integrazione, oltre a una documentazione di progettazione più dettagliata secondo necessità.

Dipende davvero da quanto ti fidi dello sviluppo offshore. Mi fido del mio team offshore per essere sviluppatori competenti. Detto questo, ho fornito la direzione generale, ma ho dato loro la libertà di implementare che il team offshore ha trovato piacevolmente soddisfacente. In passato erano più micro-gestiti. In determinate situazioni li guiderei utilizzando gli schemi di progettazione necessari. Inoltre, ho eseguito regolarmente revisioni e analisi del codice sul codice che hanno scritto e consiglierei di rifattare o ripulire gli sforzi. Inoltre, dal momento che alcuni membri della squadra hanno avuto incidenti con veicoli ricreazionali, ho finito per codificare alcune delle storie durante l'implementazione dal momento che abbiamo finito per essere a corto di risorse.

Inoltre, penso che questo processo riesca davvero solo sulla forza dei tuoi lead tecnici sul progetto e sulla comunicazione tra business, designer, lead e sviluppatori. Abbiamo dedicato molto tempo a esaminare ciascuna funzionalità e storia e ci siamo assicurati che i lead / risorse offshore fossero ben informati su quali fossero i requisiti. Se non fanno domande durante la revisione della funzione / storia, si aspettano alcuni problemi. Inoltre, il lavoro non è stato considerato completo fino a quando non è stato firmato un accordo commerciale. Ciò ha reso tutti responsabili, dal momento che tutto è stato tracciato in uno strumento che ha gestito lo sviluppo agile.

Come già accennato in una delle altre risposte, il processo di sviluppo includeva standard di denominazione (regole di ricapitolazione incorporate), copertura del caso di test (usato TDD, Mocking, ecc.) quindi se c'è un buon processo di codifica e procedura in atto aumenterà le tue possibilità di successo di un progetto.

Il principale costo dello sviluppo offshore è la comunicazione. La documentazione è un modo di comunicare, tuttavia, i documenti non sono in grado di coprire tutti i dettagli e le potenziali modifiche di solito.

Non sei sicuro di quanto sia grande il tuo progetto. Suppongo che sia grande, altrimenti non è utile utilizzare il team di sviluppo offshore. Quindi, la mia esperienza è

1. Definisci il codice dello scheletro, l'interfaccia pubblica, l'interfaccia di servizio, ecc. e rivedi insieme
2. Definisci i test di accettazione con l'altro lato
3. Dividi il grande documento in piccole storie, lavora in base alle piccole storie. Il grande documento è solo una grande immagine dell'intero sistema
4. Imposta i punti di controllo delle storie, una settimana o due settimane

1 e 2 riguardano lo sviluppo, per assicurarsi che l'altro lato capisca bene il requisito, e entrambi i lati stanno usando lo stesso schema. 3 e 4 fa parte della metodologia di sviluppo agile, ma per lo sviluppo offshore, è difficile utilizzare il processo completo agile.

Penso che in qualche modo lavoriamo tutti così. Qualcuno da qualche parte progetta qualcosa e codifichiamo qualcosa che fa parte o funziona con il sistema. Alcuni esempi sono la creazione di app basate su un framework, ad esempio app non di gioco su dispositivi mobili. Gran parte della decisione dell'IU è stata presa dal team di progettazione delle persone che hanno costruito il framework. Hanno controllato tutto, dall'imparare a scrivere un'app alla vendita della tua app. Se vuoi capire perché questo modello ha avuto successo, dai un'occhiata alla quantità di documentazione e strumenti forniti da alcuni fornitori.

Un altro esempio sono le applicazioni web con molte di esse che cercano di implementare lo stile REST. Questo in realtà non dice come implementare qualcosa, anche se ci sono specifiche su come usare HTTP. Ad ogni modo, ci sono specifiche e principi guida da seguire. Se vedi la quantità di discussioni sull'implementazione di REST su stackexchange o sul posto di lavoro, è come se ci fosse un architetto che dice alle persone di implementare qualcosa in determinati modi. È ancora un modello di successo, penso, con così tante persone che seguono lo stile.

Da questi due esempi puoi vedere come vengono propagati i disegni, alcuni come specifiche della carta, altri come libri, strumenti ed esempi. Puoi vedere come le persone chiedono (in termini di volume), cercando di ottenere la comprensione giusta con gradi diversi a seconda degli standard / disegni che stanno cercando di seguire. Basta andare su StackOverflow e guardare;)

Se mi dai le tue specifiche, chiederò. Se mi dai un test unitario, eseguirò il codice e il test.