Cosa dovrei chiedere al team di sviluppo precedente durante la mia unica riunione (1-3 ore)?

Question

C'è il progetto Ruby on Rails (1.8, 2.3.2). La prima versione del progetto è stata fatta da alcune organizzazioni. Implementerò le prossime versioni di questo progetto senza l'aiuto di questa organizzazione. Sarò in grado di parlare con gli sviluppatori del precedente team di sviluppo durante la riunione (1-3 ore).

statistiche del progetto: ~ 10k LOC, 1.0/0.6 codice per verificare il rapporto, RSpec

Quali domande sul progetto si può raccomandare di chiedere?

Answer 1

Prima recensione l'intero progetto e per capire il più possibile in modo da avere un contesto e in realtà può capire quello che dicono.

Chiedi

• Se è possibile registrare la conversazione
• Per una panoramica architettonica
• perché hanno fatto certe decisioni architetturali rispetto ad un altro
• Un elenco completo delle dipendenze (se non riesco a capire
• Quali sono i maggiori problemi
• Quali parti dei progetti sono sempre/Non essendo fissato
• Che il tallone d'Achille del progetto è
• Cosa farà sì che i più grandi mal di testa
• questioni di quale sicurezza ci sono e ciò che il vincolo è quello di fissaggio
• Cosa faresti successivo se tu eri me?
• Cosa si dovrebbe sapere che non ha chiesto (domanda più importante)

Inoltre, non essere di giudizio, si desidera loro di rivelare eventuali problemi che conoscono. Ci sono probabilmente un sacco di cose che non vanno bene con l'app di cui sono imbarazzate, cosa che devi sapere prima piuttosto che dopo. Non ti apriranno se non si fidano di te.

Answer 2

Vorrei chiedere una procedura dettagliata del codice. Non riga per riga, ma più per la struttura generale del progetto, le relazioni tra i singoli moduli, ecc.

Answer 3

Scopri il perché. Come è facile vedere nella base di codice, ma il perché è talvolta impossibile da capire e ti morderà nel culo.

Per esempio ...

Quali parti della domanda sono stati i problemi più grandi di prestazioni? Quale di questi problemi è stato risolto? Quali sono ancora problemi?

Perché hai scelto pattern/strumento/libreria x? Quali altre cose hai preso in considerazione? Perché?

Questo si spera. (Colpisci un po 'di legna). Aiutaci a non dover affrontare la stessa curva di apprendimento e gli stessi errori che la prima squadra ha dovuto affrontare, e dovresti darti una buona comprensione di dove la prima squadra ha effettivamente fatto una scelta sbagliata, invece di fare una scelta basata su fattori non ancora contabilizzati.

Answer 4

Chiedere se le nuove funzionalità causeranno modifiche importanti al codice esistente (architettonicamente) e quale sarà l'implicazione di ciò con altre parti dipendenti dell'applicazione.

Anche ottenere le loro e-mail, come avrete più domande.

Answer 5

Una delle cose più importanti, a mio parere, è ottenere la documentazione tecnica possibile prima di incontrarli. Dovresti cercare di andare all'incontro il più informato possibile, in modo che tu non solo sappia quali aree devi focalizzare maggiormente, ma anche di avere una conoscenza preesistente di come alcuni dei sottosistemi siano in relazione tra loro.

Inoltre, non abbiate paura di chiedere cosa avrebbero fatto in modo diverso, se data la possibilità. Alcune delle idee migliori arrivano troppo tardi nel processo di sviluppo da implementare - dalla disponibilità delle biblioteche, dai cambiamenti ai requisiti, dal cambio di squadra, ecc.

Answer 6

Portare i biscotti (o pizza, birra o vino a seconda dei casi); vorrete che abbiano ricordi positivi di voi per quando chiamate con domande.

Modifica: per mettere la mia risposta sotto forma di una domanda: "Posso offrirvi un biscotto fatto in casa?"

Answer 7

Forse avete fatto questo già, ma vorrei fare in modo è possibile:

• Acquista la versione più recente
• Eseguire tutte le migrazioni
• eseguire tutti i test
• Deploy (anche se a un server di gestione temporanea)
• Eseguire l'applicazione a livello locale

Prima di andare alla riunione, in modo da poter essere sicuro che è possibile per il momento in cui è finita.

Answer 8

Altre cose che potrebbero essere utili

• modello di dati
• wireframe UI
• dati Bug Tracker/emissione dati inseguitore
• Chi sono i clienti/persone che rappresentano i clienti
• configurazione dell'ambiente di sviluppo
• posizioni di controllo della sorgente, ecc.
• spiegazione delle impostazioni di configurazione speciali

Answer 9

Wow! Tutte ottime risposte, fino ai cookie.

mio contributo presuppone che questa è la tua unica e sola possibilità di accedere al vecchio team di sviluppo, pertanto è necessario dare dei calci su una tacca:

1. Agenda. Split la riunione in più parti, per esempio:

   • Una rapida (15 min) introduzione e arco panoramica
   • Uno contro uno con i membri del team.
   • progetto Esame come un gruppo, ecc

2. Positive Energy. Soprattutto se la relazione è intrinsecamente difficile, mantenere un focus positivo postulando: quali miglioramenti introdurrai nella prossima versione (riscrittura non è un'opzione, giusto Joel) - catturare ogni sfumatura, e scavare oltre il loro livello di comfort solo più vicino al fine.

3. Facilitatore. Utilizzare un facilitatore esperto di riunioni di design. Possono aiutare a preparare la riunione, condurre interviste pre-incontro, progettare l'agenda. Durante l'incontro possono guidare l'intensità e mantenere l'attenzione. Possono anche suggerire forme di acquisizione di ciò che può essere una buona quantità di informazioni.

Inoltre, proverei a id tutti gli artefatti di progettazione oltre il codice, se ce ne sono, e capisco quanto sia accurato. Ciò potrebbe includere la revisione del design degli elementi chiave di questi documenti rispetto al sistema as-built.

Don