Come consegnare sistematicamente un progetto?

Question

Abbiamo un progetto di consegna dalla squadra di terra al nostro team (off shore) non molto tempo fa. Tuttavia abbiamo avuto difficoltà per il processo di consegna.

1. Non siamo riusciti a pensare a tutte le domande da porre durante il loro design walk-through, perché siamo stati travolti dalla enorme quantità di informazioni. Volevamo chiedere, ma non sapevamo cosa chiedere. Dal momento che non ci hanno fatto domande, il management pensa che il processo di consegna sia stato fatto con successo.

2. Avevamo provato a esaminare tutta la documentazione dalla nostra pagina wiki aziendale prima di partecipare alla presentazione del passaggio di consegne, ma ci sono troppi documenti, non sappiamo nemmeno da dove iniziare.

Mi chiedo, ci sono regole o le migliori pratiche che possiamo seguire, al fine di garantire il successo del progetto hand-over, sia da noi, o per noi.

Grazie.

Answer 1

Come prima cosa, definire i criteri di uscita per la consegna. Questo dovrebbe essere discusso, negoziato e concordato con entrambe le parti e assicurarsi che il management superiore lo sappia. Quindi scrivi una lista di controllo di tutte le cose necessarie per raggiungere i criteri di uscita e inseguirla.

Answer 2

mio processo di base per ricevere un passaggio potrebbe essere:

1. Ottenere una panoramica generale della app, documento
2. Ottenere un elenco di tutti i futuri lavori che il cliente si aspetta
3. ... tutti i problemi noti
4. ... qualsiasi specifiche di implementazione
5. tanto up-to-date di documentazione hanno
6. Se possibile, li hanno scrivere alcuni test per i componenti critici del sistema (o almeno farli accuratamente documentate)

Se c'è troppa documentazione (possibile) solo confermare che è tutto fino ad oggi, e assicuratevi di sapere da loro da dove cominciare, se non è chiaro.

Chiedere quante più domande possibile; qualsiasi cosa ti venga in mente, perché potresti non avere più la possibilità.

Answer 3

In termini di lettura della documentazione, personalmente mi piacerebbe andare per questo ordine:

1. riceve un breve riepilogo delle funzioni di base dell'applicazione - che cosa è destinato a raggiungere. Il business case è probabilmente il miglior documento che esisterà già.

2. Quindi la specifica funzionale. A questo punto non stai cercando di capire alcun tipo di come o tecnologia, solo ciò che l'app è destinata a fare. Se è enorme, chiedigli quali sono i processi aziendali chiave e concentrati su quelli.

3. Quindi la panoramica tecnica di alto livello. Questo dovrebbe includere un diagramma di architettura, le piattaforme richieste, le versioni, la configurazione e così via. Elenca tutte le domande che hai.

4. Quindi sfoglia qualsiasi altro documento tecnico dall'aspetto utile - sicuramente una FAQ se ce n'è una, gli script di test possono essere utili anche perché descrivono dettagliati scenari di tipo "come". Forse sono solo io, ma trovo di leggere documenti tecnici prima di aver visto il sistema come un rifiuto - è troppo accademico e di solito sono scritti in modo sconvolgente. È certamente un'area in cui limiterò il tempo trascorso se non avessi avuto la sensazione di ottenere un rendimento ragionevole per il tempo che stavo spendendo.

Se ci sono molti di voi arrage recensioni strutturati tra voi e discutere i documenti che avete letto, facendo in modo di avere quello che serve per fuori di esso. Se il sistema è grande, ognuno prende un'area e lo presenta agli altri su di esso - datevi una ragione per imparare il più possibile e sapere di essere interrogati è un buon motivatore. Fai una lista di domande dove non capisci qualcosa. Avere delle revisioni strutturate tra di voi focalizzerà le tue menti e renderà più un compito interattivo, piuttosto che semplicemente trascinerà pagina dopo pagina su un noioso documento.

volta che si arriva faccia a faccia con loro:

1. Inizia con una demo completa del sistema. Poni domande mentre escono, non lasciarti coinvolgere da risposte poco chiare - se non possono rispondere a qualcosa lo hanno annotato e le incarica di ottenere la risposta.

2. Ora ottenere il codice estratto e in esecuzione sulle macchine. Fatelo su almeno due macchine: una che guidano, una che guidate. Documenta l'intero processo: questo è il passo più importante. Se non riesci a far funzionare il codice, sei fregato.

3. Passare attraverso il processo di costruzione. Assicurati di poter costruire l'app (compresi eventuali test di build e unità automatizzati che potrebbero avere). Nota che tutti i test unitari devono passare - se non lo fanno o se dicono "oh, quello fallisce sempre", allora devono correggerlo prima dell'accettazione finale.

4. Passare attraverso il processo di installazione. Fatelo almeno due volte, uno di loro, una volta che guidate. Assicurati che sia documentato.

5. Ora è disponibile una serie di funzioni aziendali comuni eseguite con l'applicazione. Usalo per percorrere il codice con loro. Il codice base sarà troppo grande per coprire l'intera faccenda, ma assicurati di coprire un campione rappresentativo.

6. Se c'è un database o un'API fare un esercizio simile. Fornisci alcuni dati standard che potresti aver bisogno di estrarre o alcune attività di base che potresti dover eseguire utilizzando l'API e dedica loro del tempo a risolverle.

7. Chiedi loro se c'è qualcosa che pensano che dovresti sapere.

8. Assicurati che tutte le domande che hai scritto da un'altra parte abbiano una risposta.

9. Si può considerare che valga la pena di passare attraverso l'elenco di bug (aperto e chiuso) - iniziare con quelli ad alta priorità e parlare di qualcosa di particolarmente preoccupante. Anche se lo hanno risolto, potrebbe indicare un po 'di codice che è problematico.

10. E infine se l'opportunità esiste - se ci sono bug o modifiche in sospeso, vedere se è possibile accoppiare un paio di programmi.

Non infine accettare l'applicazione a meno che non si è sicuri al 100% è possibile:

1. Crea il codice per compilare
2. ottenere il codice per costruire (incluso il database)
3. Get l'applicazione installata

Non accettare il passaggio di consegne è completo fino a quando:

1. documentato tutto quello che è venuto il che non era coperto per la vostra soddisfazione
2. risposto a tutte le vostre domande - una domanda che non risponderà dopo essere stato chiesto ripetutamente urla di qualche cosa stanno nascondendo

E prendi i loro indirizzi e-mail e numeri di telefono. Anche se è solo informale, probabilmente saranno disposti a dare una mano se la merda colpisce davvero la ventola ...

Buona fortuna.

Answer 4

Check out "Software Requirements" e Software Requirement Patterns per idee su domande da porre quando si raccolgono informazioni su un progetto. Penso che, proprio come avrebbero funzionato per un nuovo sviluppo, ti aiuterebbero anche a fare i conti con un progetto esistente.

Answer 5

La maggior parte dei passaggi, forse tutti, causerà la perdita di molte informazioni. L'unico modo efficace per eseguire un passaggio di consegne che ho visto è farlo gradualmente. Un modo per farlo è consentire ad alcune persone chiave della fase 1 di rimanere nel progetto fino alla Fase Due.

La soluzione estrema è liberarsi di tutti i passaggi e iniziare a utilizzare una mentalità Agile.