Per elaborare sono interessato a sapere cosa pensano le persone che devono essere messe in atto mentre sono ancora un progetto one man (controllo del team di origine, documentazione, build, ecc.) e quali cose non devono essere fatte fino a quel punto quando il la seconda persona entra nel progetto.
Chiunque abbia esperienza nel muoversi in questo scenario, le sue intuizioni saranno apprezzate.
Quello che ho imparato. (Ho provato un ordine diverso, ho sbagliato: questo è l'ordine in cui le cose diventano rilevanti.)
Metti tutto nel controllo del codice sorgente. Usa qualcosa a cui tutti hanno accesso e inizia subito . Nessuna eccezione. Nessun ritardo. Niente scuse.
Crea un'area QA / Test completamente separata dal tuo ambiente di "lavoro" o "sviluppo" personale. Almeno un id utente separato. Idealmente su una VM separata.
Completamente separato. Nessuna sovrapposizione possibile con il tuo ambiente di lavoro corrente.
Interrompi i test oltre il test unitario nel tuo ambiente di lavoro. Codice e test unitario che fai "come te stesso". Tutti gli altri test (integrazione, prestazioni, qualunque cosa) si fanno sulla VM separata. Non provare mai come te stesso. Provare sempre come utente QA separato. Idealmente su una VM separata.
"Funziona per me" è una brutta cosa da dire ai membri del tuo team. Molto brutto. Devi capire cosa stanno facendo di sbagliato. Più volte al giorno.
Pianifica di scrivere tutto. Utilizzare uno strumento di markup in testo semplice (RST o Markdown o qualcosa) in modo che tutta la documentazione sia in chiaro nel repository di controllo della versione. Uno strumento può creare pagine HTML (ad es., Docutils per RST) o PDF o qualsiasi altra cosa sembra la migliore. Non utilizzare formati di documenti proprietari (ad es. MS-Word). Potrebbero non funzionare bene con alcuni sistemi di controllo del codice sorgente.
Le prime cose che devi scrivere sono le seguenti.
Come creare un ambiente di sviluppo funzionante. In caso di dubbi, crea una macchina virtuale e fai l'intera operazione su quella macchina virtuale. Assicurati che i passaggi veramente funzionino e che la documentazione sia chiara . Righe effettive digitate al tipo di chiarezza della riga di comando effettiva.
Come eseguire la suite di test delle unità. Ancora. Assicurati che le istruzioni funzionino e non richiedano di pensare. "Digita questo:" "Conferma che:" tipo di cose. Non è che i membri del tuo team siano stupidi. È che non ricordi quello che stai assumendo a meno che non lo scrivi tutto.
Come eseguire la suite di test di integrazione.
Non perdere molto tempo a descrivere l'architettura oi principi di progettazione. Devi prima far funzionare qualcuno. Puoi spiegare cose più tardi.
Le prossime cose da documentare sono le user story. E i casi di test che supportano quelle storie. E i dati necessari per i casi di test che supportano tali storie utente.
Lo condividerai. Va sotto il controllo del codice sorgente.
Alla fine, puoi documentare le altre 4 viste.
La vista logica è roba utile da documentare. Le foto sono accettabili qui. Questo tende ad evolversi rapidamente, quindi non perdere tempo a catturare le informazioni legacy. Elabora un modo per collaborare con i membri del tuo team.
La visualizzazione del processo è spesso utile. Dipende dall'applicazione generale quanto sia importante.
La vista di sviluppo - moduli, librerie, framework, ecc. - è spesso descritta in modo informale. Un'immagine potrebbe essere d'aiuto, ma è notoriamente difficile renderlo abbastanza completo da permettere a qualcuno di prendere un documento e farne testa o croce. Persino progetti pubblici molto consolidati hanno una documentazione bibliografica semplicemente ignorata. (Conducendo a molte domande di Stack Overflow.)
Oltre ad essere accettabile per essere informale, questo tende a cambiare rapidamente.
Informazioni sulla distribuzione. I server. Indirizzi IP Credenziali del database. Tutto ciò che deve deve essere annotato. Alla fine.
Che cosa è necessario per collaborare con successo ed essere produttivi?
... o qualsiasi altra cosa a livello interpersonale
Elencherò alcuni dei libri comunemente menzionati che ho effettivamente letto e penso valga la pena di leggerli, per una descrizione più dettagliata o per altri libri che potresti voler controllare alcuni dei le domande su SO che richiedono esattamente questo, come questo o questa domanda.
Vale veramente la pena di leggere quei libri in relazione a team, organizzazioni e progetti di programmazione:
Nessuno di questi è una guida pratica su come implementare la metodologia X (eccetto la stima del software, questo libro ti aiuta a scegliere un processo di stima appropriato). Naturalmente, i libri più incentrati sulla programmazione stessa come Code Complete sono anche molto arricchenti.
Parlerò dell'esperienza, ma tieni presente che ognuno è diverso. Queste cose non sono universali.
Una cosa è lasciarlo andare personalmente. Questo progetto è qualcosa con cui hai vissuto e vissuto per 18 mesi: vorresti naturalmente che ogni cambiamento fosse come lo faresti tu. Dare un buffer per un collega per fare errori, per imparare. Crea una stanza perché possano essere utili. E ricorda che potrebbe non accadere subito. Inoltre sarebbe bello se ci fosse qualcosa, una parte del codice che possono percepire che riescono a migliorare o creare, che sembra un successo in un breve periodo di tempo. La pazienza e la tolleranza hanno una buona retribuzione qui. Non provare a microgestire, e se vuoi criticare, dire "hai torto", assicurati di avere un merito, puoi dimostrarlo, non è una lotta "religiosa".
Un altro problema chiave è trovare la persona giusta per te. Idealmente è meglio trovare qualcuno più intelligente di te. È soggettivo e relativo, ma se senti che una persona ha delle conoscenze e abilità che non hai, è per il meglio. Sarà una collaborazione reciprocamente gratificante.
Ci sono due modi in cui può andare: il collega sarà un drag, e finirai per rifare quello che ha fatto, o le abilità di due di voi si moltiplicheranno, non solo sommando, e apprezzerete davvero lavorare insieme.
Su un argomento di "codice pulito, veloce e riutilizzabile" - suggerisco in un'intervista, chiedo di scrivere un piccolo micro-kernel / gestore del servizio e / o esecutore del lavoro. Scopri come i componenti collegabili sono specificati e configurati. Non deve essere finito, è un pensiero che conta. E anche imparerai rapidamente le persone che sanno bene come farlo vorranno soldi decenti ;-) Buona fortuna!
La mia opinione: iniziare a documentare l'architettura del progetto interno per qualcuno ... che non ne è a conoscenza. Cerca di spiegare quali ipotesi sono in atto e quando / dove ti sei distolto dalle pratiche comuni e perché.
Automazione delle build: ottima idea, posso aggiungere l'automazione della configurazione per una macchina di sviluppo. Più facile è costruire più sarà (quindi più / più veloce test di implementazione).
Un'altra idea (mi è stata di grande aiuto una volta): chiedi al nuovo sviluppatore di eseguire alcune operazioni di pulizia su piccola scala in diverse aree del tuo codice base, in modo che si abitui agli strumenti di layout, ecc. Una buona idea è rimuovere aree oscure che potrebbero aggiungere confusione in seguito (esempio: se hai usato emmm python per due righe di uno script di shell da qualche parte e il tuo progetto è basato su java, chiedi a quelle due linee di essere riscritte in java in modo che lo sviluppatore n. avremo bisogno di sapere di meno per poter funzionare)
Vorrei concentrarmi sull'automazione di tutto ciò che richiede un lavoro manuale, quindi può essere rovinato da una persona inesperta . Che, in base al tuo breve commento sopra, include quanto segue:
Se non riesci a fare ciò, o sarai incatenato a fare queste attività per sempre, o (alcuni) il / i ragazzo / i inevitabilmente rovinerà qualcosa prima o poi.
L'altro compito importante è, come ha notato @dimitris, la documentazione. @S. Lott ha aggiunto molti più dettagli su questo, quindi basta un +1 a lui piuttosto che ripetere: -)
Ecco alcuni pensieri, in parte basati sull'esperienza personale:
Documento il tuo progetto. Le specifiche di progettazione, i diagrammi, i manuali e i commenti aiuteranno il nuovo dipendente a diventare subito operativo. Spiegare un sistema complesso solo verbalmente può risultare lento e frustrante. La documentazione è spesso trascurata nei progetti one-man. Assicurati che la tua sia un'eccezione.
In un primo momento, concentrati sul codice API / core, mentre offri al nuovo dipendente alcuni "livelli applicativi" che risolvono problemi con familiarizzandoli con il codice. Generalmente, iniziare con più facile , ancora significativo e quindi gratificante attività .
La comunicazione è importante. Sii reattivo alle domande, ai commenti e alle idee del nuovo impiegato. Spiega perché pensi che un'idea non sia buona se lo fai. Un paio di occhi nuovi possono individuare sorprendentemente bene lo spazio per il miglioramento. Se il tuo nuovo dipendente è decente, può rivedere il tuo codice e partecipare alle decisioni di architettura. Discutere, rimbalzare le idee a vicenda. Questo è uno dei maggiori vantaggi di avere un collaboratore nel progetto.
Definisci chiaramente le responsabilità , una volta che sai quale tipo di attività il tuo nuovo membro del team sta facendo. Stabilisci pratiche di documentazione e convenzioni di codifica per mantenere le cose a posto.
Utilizza un sistema di controllo di revisione . Mantieni un file di sorgenti logiche e crea disciplina .
Per quanto riguarda l'intervista - Non sono un grande fan dei test di codifica artificiale o delle domande sui trucchi, a meno che tu non voglia provare la capacità di resistenza allo stress del candidato. Anche il più intelligente dei risolutori di problemi può bloccarsi in una situazione del genere. Le qualità che cercherete tra le altre sono: onestà , capacità professionale , conoscenza tecnologica / insight , entusiasmo e compatibilità reciproca . L'atmosfera lavorativa può significare molto; è sconsigliabile scegliere un compagno di squadra che non ti piace. Fai le tue domande e fai qualche discussione informale per avere una buona immagine del tuo candidato. Buona fortuna!
Tecnologia
Se stai introducendo qualcun altro come sviluppatore, ci sono tre cose fondamentali che consiglierei di avere installato e funzionante prima di iniziare.
Se queste tre cose sono funzionanti correttamente, eliminerai circa il 75% del problema comune che si verifica quando porti un nuovo membro del team. Il punto di questi pezzi di tecnologia è quello di prendere molto di ciò che sta accadendo solo nella tua testa e portarlo fuori dove il membro del tuo team può interagire con esso.
Il controllo del codice sorgente fa in modo che entrambi stiate lavorando sulla stessa cosa. Il rilevamento dei problemi ti aiuta a tenere traccia di ciò che deve essere fatto e ti renderà più facile sapere a cosa sta lavorando e cosa sta facendo. L'integrazione e il testing continui contribuiranno a garantire un processo di generazione ripetibile e che i nuovi miglioramenti non compromettano altre parti del codice.
Il programmatore pragmatico ha alcuni bei libri su questo. Ecco alcuni che consiglierei. Hanno altri titoli simili basati sul linguaggio di programmazione che si sta utilizzando o sul controllo di versione che si desidera utilizzare:
Personali
Spesso le difficoltà che affronterai sono meno sul lato tecnico delle cose e più sull'apprendimento di lasciarti andare. Può essere difficile dare a qualcun altro il controllo sugli aspetti del progetto, in particolare se si è soliti fare tutto da soli e prendere ogni singola decisione. Potrai risparmiare un po 'di dolore se riesci a trovare un'area in cui puoi far lavorare la nuova persona con una ragionevole quantità di libertà all'inizio in modo da poter sviluppare un fondamento di fiducia. Se assumi una brava persona, la cosa principale che probabilmente imparerai è come fidarti dell'altra persona a fare un buon lavoro anche se tutte le sue decisioni individuali non sono le stesse di quelle che avresti fatto.
Vuoi dare al tuo nuovo noleggio la libertà di risolvere i problemi nel modo in cui funziona per loro, mantenendo al contempo le misure di sicurezza in modo da poter individuare i problemi nella fase iniziale.
Questi punti sono i più importanti a mio parere:
E ultimo ma non meno importante: ottenere un sistema di controllo della versione. Subversion va bene. Ma assicurati di non aggiungere quei file di Eclipse (o qualsiasi altra cosa) che sono specifici per l'utente e quindi costantemente in evoluzione. Ti fanno perdere ore. Non esitare a chiedere su Stackoverflow se hai problemi con esso.
Leggi altre domande sui tag version-control project-management development-process builds documentation