Progetta in un team, codifica in un altro

Sarò coinvolto in un progetto in cui tutto il design del software è realizzato da un team locale e questi design vengono inviati a un team offshore per la codifica.

Questa è la prima volta che mi trovo ad affrontare un progetto con queste caratteristiche e per me sembra strano: i manager si aspettano che realizziamo documenti di progettazione molto dettagliati, quindi non c'è spazio per errori per il team offshore; dal mio punto di vista ci stanno facendo codificare su carta mentre possiamo farlo in un IDE.

Quindi, la mia domanda è: questo approccio è buono o dimostrato, giusto? Quali sono le principali considerazioni che il nostro processo software deve avere per avere successo nel nostro progetto?

La mia opinione:

Se tutto ciò che darai alle persone in mare aperto saranno documenti e diagrammi, avrai molte comunicazioni errate e delusioni .

La mia raccomandazione

• Non fornire loro così tanti documenti, ma piuttosto interfacce e classi astratte al fine di inserirle nei tuoi obiettivi di progettazione .

• Richiedere loro di utilizzare uno standard di denominazione noto.

• Richiedere loro di utilizzare i test unitari.

• Invia uno dei tuoi designer / architetti al largo delle loro sedi per supervisionare il processo, sarà ancora più economico della codifica interna, 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 quello che i tuoi datori di lavoro ti hanno chiesto di fare.

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

L'ultimo progetto sono stato il progettista del software. Tutto lo sviluppo era offshore. Abbiamo avuto successo. Quindi questo processo può funzionare.

Ho prodotto molta documentazione, ma non è stata affatto esaustiva e non è stata fornita istruzioni dettagliate o dettagliate fino ai nomi delle classi, ai nomi delle funzioni ecc. Ad esempio, ho prodotto diagrammi di sequenza, casi d'uso, flussi di lavoro, sistema e integrazione diragrammi, nonché una documentazione di progettazione più dettagliata in base alle esigenze.

Dipende davvero da quanto ti fidi dello sviluppo offshore. Confido che il mio team offshore sia sviluppatori competenti. Detto questo, ho fornito la direzione generale ma ho dato loro un margine di manovra per l'implementazione che il team offshore ha trovato piacevolmente soddisfacente. In passato erano più micro-gestiti. In alcune situazioni li guiderei usando gli schemi di progettazione secondo necessità. Ho anche eseguito periodicamente revisioni e analisi del codice sul codice che scrivevano e consiglierei il refactoring o ripulire gli sforzi. Inoltre, poiché alcuni membri del team hanno avuto incidenti con veicoli ricreativi, ho finito per scrivere alcune delle storie durante l'implementazione, dato che abbiamo finito per essere a corto di risorse.

Inoltre, penso che questo processo abbia davvero successo solo sulla base dei tuoi lead tecnici sul progetto e sulla comunicazione tra business, designer, lead e sviluppatori. Abbiamo passato molto tempo a esaminare ogni caratteristica e storia e ci siamo assicurati che i lead / risorse offshore fossero ben versati su quali fossero i requisiti. Se non stanno ponendo domande durante la revisione della funzione / storia, aspettatevi alcuni problemi. Inoltre, il lavoro non è stato considerato completo fino a quando non si è avuto un accordo commerciale. Ciò ha reso tutti responsabili in quanto tutto è stato monitorato in uno strumento che ha gestito lo sviluppo agile.

Come ha già accennato una delle altre risposte, il processo di sviluppo includeva standard di denominazione (regole del resharper integrate), copertura dei casi di test (ha usato TDD, Mocking, ecc.), Quindi se c'è un buon processo di codifica e procedure in atto aumenterà le tue possibilità per un progetto di successo.

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

Non sono 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. Definire il codice scheletro, l'interfaccia pubblica, l'interfaccia di servizio, ecc. E rivederli insieme
2. Definire 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 o due settimane

1 e 2 riguardano in realtà lo sviluppo, per assicurarsi che l'altra parte capisca bene il requisito e che entrambe le parti stiano usando lo stesso modello. 3 e 4 fanno parte della metodologia di sviluppo agile, ma per lo sviluppo offshore è difficile utilizzare l'intero processo agile.

Penso che tutti noi lavoriamo così. Qualcuno da qualche parte progetta qualcosa e noi programmiamo qualcosa che fa parte o che funziona con il sistema. Esempi sono la creazione di app basate su un framework, come le app non di gioco sui dispositivi mobili. Molte decisioni sull'interfaccia utente sono state prese dal team di progettazione delle persone che hanno creato 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 venditori.

Un altro esempio sono le applicazioni web con molti di loro che cercano di implementare lo stile REST. Questo non dice davvero 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 un architetto dicesse alla gente di implementare qualcosa in determinati modi. È ancora un modello di successo, credo, con così tante persone che seguono lo stile.

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

Se mi dai le tue specifiche, te lo chiederò. Se mi dai un test unitario, codificherò e testerò.