Passando da un progetto maschile a un progetto di gruppo in futuro. Cosa dovrei fare ora in preparazione e cosa posso aspettare?

Per approfondire, sono interessato a sapere cosa la gente pensa di dover mettere in atto mentre è ancora un progetto individuale (controllo del team, documentazione, build, ecc.) E quali cose non devono essere fatte fino a quel momento in cui arriva la seconda persona sul progetto.

Chiunque abbia esperienza di muoversi in questo scenario, le loro intuizioni saranno apprezzate.

Quello che ho imparato (Ho provato un ordine diverso. Ho sbagliato. Questo è l'ordine in cui le cose diventano rilevanti.)

1. Metti tutto nel controllo del codice sorgente. Usa qualcosa a cui tutti hanno accesso e inizia subito . Nessuna eccezione. Nessun ritardo. Niente scuse.

2. Crea un'area QA / Test totalmente separata dal tuo ambiente "lavorativo" o di "sviluppo" personale. Almeno un ID utente separato. Idealmente su una VM separata.
   Completamente separato. Nessuna possibile sovrapposizione con l'ambiente di lavoro attuale.

3. Interrompere i test oltre i test unitari nel proprio ambiente di lavoro. Codice e unit test che fai "come te stesso". Tutti gli altri test (integrazione, prestazioni, qualunque cosa) tu faccia sulla VM separata. Non provare mai come te stesso. Testare 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.

4. Pianifica di scrivere tutto. Utilizzare uno strumento di markup in testo semplice (RST o Markdown o qualcosa del genere) in modo che tutta la documentazione sia in testo semplice nel repository di controllo versione. Uno strumento può creare pagine HTML (ovvero Docutils per RST) o PDF o qualsiasi altra cosa sembri la migliore. Non utilizzare formati di documenti proprietari (ad es. MS-Word). Potrebbero non funzionare bene con alcuni sistemi di controllo del codice sorgente.

5. Le prime cose che devi annotare sono le seguenti.

   • Come creare un ambiente di sviluppo funzionante. In caso di dubbio, creare una macchina virtuale ed eseguire l'intera operazione su quella macchina virtuale. Assicurati che i passaggi funzionino davvero e che la documentazione sia chiara . Righe effettive digitate nell'attuale tipo di riga di comando di chiarezza.

   • Come eseguire la suite di test unitari. Ancora. Assicurati che le istruzioni funzionino e non richiedano riflessioni. "Digita questo:" "Conferma che:" tipo di cose. Non è che i membri del tuo team siano stupidi. È che non ricordi cosa stai assumendo se non lo annoti tutto.

   • Come eseguire la suite di test di integrazione.

   Non perdere molto tempo a descrivere l'architettura o i principi di progettazione. Per prima cosa devi far funzionare qualcuno. Puoi spiegare cose in seguito.

6. Le prossime cose da documentare sono le storie degli utenti. E i casi di test che supportano quelle storie. E i dispositivi di dati necessari per i casi di test a supporto di tali user story.

   Lo condividerai. Va sotto il controllo del codice sorgente.

7. Alla fine, puoi documentare le altre 4 viste.

   • La vista logica è utile per documentare. Le foto sono accettabili qui. Questo tende ad evolversi rapidamente, quindi non perdere tempo a catturare le informazioni legacy. Elaborare un modo per collaborare con i membri del proprio team.

   • La vista di processo è spesso utile. Dipende dall'applicazione complessiva di quanto sia importante.

   • La vista di sviluppo - moduli, librerie, framework, ecc. - viene spesso descritta in modo informale. Un'immagine potrebbe essere d'aiuto, ma è notoriamente difficile renderlo abbastanza completo da consentire a qualcuno di raccogliere un documento e ricavarne la testa o la coda. Persino i progetti consolidati e molto pubblici hanno documentazione di biblioteca che viene semplicemente ignorata. (Portando a molte domande Stack Overflow.)

     Oltre ad essere accettabile per essere informale, questo tende a cambiare rapidamente.

   • Informazioni sulla distribuzione. I server. Indirizzi IP. Credenziali del database. Tutta quella roba deve essere scritta. Infine.

Strumenti e metodologia

Cosa è necessario per collaborare con successo ed essere produttivi?

• Identificare parti / componenti del progetto: distinguere chiaramente tra parti diverse (database, livello di accesso ai dati, sito Web, servizio, API, progetti di test, script di compilazione, ...) e ambienti (sviluppo, gestione temporanea, produzione) e denominarli ha costantemente un impatto sulla comunicazione orale e scritta (documentazione, nomi dei progetti, ...)
• Utilizza un sistema di gestione del codice sorgente (nel caso in cui non lo avessi ancora fatto). Pensa a come utilizzare la ramificazione con il tuo progetto e la tua configurazione.
• Automatizza le tue build : rendi il più semplice possibile impostare un ambiente dal tuo repository di origine.
• I progetti di test sono un must per i grandi progetti, almeno per i progetti più complessi.
• Utilizzare gli ambienti di gestione temporanea in cui il progetto è pronto per essere utilizzato. Inoltre, creare e gestire i dati di esempio per un'impostazione di gestione temporanea automatizzata.
• Utilizzare un sistema di tracciamento dei bug che può aiutare a stabilire le priorità e pianificare lo sviluppo e che funge anche da memoria per i bug passati e come sono stati risolti.
• Documenta ogni parte del tuo progetto, alcune più di altre. Personalmente mi piace: Panoramica - Architettura - Dipendenze - Configurazione - Problemi comuni (da qui ). A volte di meno è di più: per evitare che la documentazione diventi obsoleta, è meglio essere concisi e lasciare che la documentazione diventi parte dell'attività quotidiana.

Gestione / lavoro di squadra

... o qualsiasi altra cosa a livello interpersonale

• Definisci le tue aspettative sull'altro sviluppatore. Sii ragionevole, è probabile che nessuno porti lo stesso coinvolgimento e la stessa passione di te, almeno non fin dall'inizio. Comunicare ciò che ti aspetti e cosa no, definisci le tue e le altre responsabilità. Non tutti sono ingegnere, architetto, sviluppatore, dba e amministratore di sistema, ma se è quello che stai cercando, scegli la persona giusta o rimarrai deluso.
• Inizialmente , definire le attività con precisione e rivedere e discutere i risultati. A poco a poco, inizia sempre meno micro-gestione. L'idea è quella di costruire la fiducia e aumentare la responsabilità.
• Pianifica il tuo progetto , fissa gli obiettivi per il tuo progetto e per il tuo team per il prossimo anno. Scrivilo e controllalo più tardi, questo darà prospettiva . Tali obiettivi possono o meno essere comunicati ad altri (purché siano obiettivi che devi raggiungere, non altri), può semplicemente essere la tua lista di controllo.
• Prenditi un giorno per preparare e pianificare il primo mese (o due / tre mesi) del tuo nuovo sviluppatore. Lo trovo estremamente motivante quando si lavora con persone ben preparate. Nessuno dovrebbe avere l'impressione che il suo tempo sia sprecato.
• Lascia andare . È il tuo bambino, dovrebbe diventare anche quello di qualcun altro. Consenti all'altro di diventare un esperto migliore di te, almeno in alcune parti del progetto. Questo significa che in realtà ci sei riuscito.
• Ascolta , se l'hai assunta, ha qualcosa da dire. Sii pronto per imparare.
• Sii pronto a condividere le tue conoscenze ed esperienze (e quindi il tempo - sii paziente).
• Verranno fatti degli errori , è come vengono gestiti e ciò che tutti stanno imparando su di loro ciò che conta.
• Concedi il tempo per imparare e sperimentare

Riferimenti del libro

Elencherò alcuni dei libri di cui ho effettivamente letto e penso che valga la pena leggere, per una descrizione più dettagliata o per più libri potresti voler dare un'occhiata ad alcune delle domande su SO che chiedono esattamente questo, come questa o questa domanda.

Vale davvero la pena leggere quei libri riguardo a team, organizzazioni e progetti di programmazione:

• Peopleware
• Mese dell'uomo mitico
• Stima del software, demistificando l'arte nera

Nessuna di queste sono guide pratiche su come implementare la metodologia X (ad eccezione della stima del software, questo libro ti aiuta a scegliere un processo di stima appropriato). Naturalmente, anche i libri più incentrati sulla programmazione stessa come Code Complete sono molto arricchenti.

Parlerò dall'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. Dai un buffer a un collega per fare errori, per imparare. Crea una stanza affinché possano essere utili. E tieni presente che potrebbe non succedere subito. Sarebbe anche bello se ci fosse qualcosa, una parte del codice che sentono di riuscire a migliorare o creare, che sembra un successo in un breve periodo di tempo. La pazienza e la tolleranza hanno un buon tasso di pagamento qui. Non cercare di micromanage e, se vuoi criticare, dire "ti sbagli", 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 ritieni che una persona abbia qualche conoscenza 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 freno e finirai per ripetere ciò che ha fatto, o le abilità di due di voi si moltiplicheranno, non solo si sommeranno, e apprezzerete davvero lavorare insieme.

Su un argomento di "codice pulito, veloce e riutilizzabile" - suggerisco in un'intervista di chiedere di scrivere un piccolo gestore di servizi / micro-kernel e / o un esecutore di lavoro. Scopri come vengono specificati e configurati i componenti collegabili. Non deve essere finito, è un pensiero che conta. Inoltre imparerai rapidamente persone che sanno bene come farlo vorranno soldi decenti ;-) Buona fortuna!

La mia opinione: inizia con il documento l'architettura del tuo progetto interno per qualcuno ... che non ne è consapevole. Prova a spiegare quali ipotesi sono in atto e quando / dove ti sei allontanato dalle pratiche comuni e perché.

Build automation: Ottima idea, posso aggiungere l'automazione della configurazione per una macchina di sviluppo. Il più facile è costruire più sarà (quindi più / più veloce implementazione di test).

Un'altra idea (mi ha aiutato molto una volta): chiedi al nuovo sviluppatore di svolgere alcune attività di pulizia su piccola scala in diverse aree della tua base di codice, in modo che si abitui agli strumenti di layout ecc. Una buona idea è quella di rimuovere aree oscure che potrebbero aggiungere confusione in seguito (esempio: se hai usato emmm python per due righe di uno script shell da qualche parte e il tuo progetto è basato su Java, chiedi a quelle due righe di essere riscritte in Java così che lo sviluppatore # 3 dovrà sapere di meno per lavorare)

Mi concentrerei 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:

• installare il controllo versione e sostituire i backup manuali con quelli automatici,
• impostare la distribuzione automatica il più possibile (come minimo, scrivere uno script da distribuire via FTP anziché farlo manualmente.

Se non riesci a fare questi, o verrai incatenato a svolgere questi compiti per sempre, o (alcuni) i nuovi ragazzi inevitabilmente rovineranno qualcosa prima o poi.

L'altro compito importante è, come notato da @dimitris, la documentazione. @S. Lott ha aggiunto molti più dettagli su questo, quindi solo +1 per lui invece di ripetere :-)

Ecco alcuni pensieri, in parte basati sull'esperienza personale:

• Documenta il tuo progetto. Specifiche di progettazione, diagrammi, manuali e commenti aiuteranno il nuovo dipendente ad aggiornarsi. Spiegare un sistema complesso solo verbalmente può rivelarsi lento e frustrante. La documentazione viene spesso trascurata nei progetti personali. Assicurati che la tua sia un'eccezione.

• In un primo momento, concentrati sul codice API / di base, dando al nuovo dipendente un po 'di lavoro a "livello di applicazione" o correzione di bug per familiarizzare gradualmente con il codice. In genere, iniziare con più facili , ma significativi e quindi gratificante attività .

• La comunicazione è importante Rispondi alle domande, ai commenti e alle idee del nuovo dipendente. Spiega perché pensi che un'idea non sia buona se lo fai. Un nuovo paio di occhi può individuare sorprendentemente bene margini di miglioramento. Se il tuo nuovo dipendente è dignitoso, può rivedere il tuo codice e infine prendere parte alle decisioni sull'architettura. Discutere, rimbalzare le idee l'un l'altro. Questo è uno dei maggiori vantaggi di avere un collega nel tuo progetto.

• Definisci chiaramente le responsabilità , una volta che conosci il tipo di compiti che il tuo nuovo membro del team sta facendo Stabilire pratiche di documentazione e convenzioni di codifica per mantenere le cose lisce.

• Utilizzare un sistema di controllo di revisione . Mantenere un layout logico dei file di origine e creare disciplina .

Per quanto riguarda l'intervista, non sono un grande fan dei test di codifica artificiale o delle domande a trabocchetto, a meno che tu non voglia provare l'abilità di sopportare lo stress del candidato. Anche il più intelligente dei risolutori di problemi può chiudersi in una situazione del genere. Le qualità che cercherete, tra le altre, sono: onestà , capacità professionale , conoscenza / intuizione tecnologica , entusiasmo e compatibilità reciproca . L'atmosfera lavorativa può significare molto; non è consigliabile scegliere un compagno di squadra che non ti piace. Poni le domande giuste e fai qualche discussione informale per avere una buona immagine del tuo candidato. In bocca al lupo!

Tecnologia

Se stai inserendo qualcun altro come sviluppatore, ci sono tre cose chiave che consiglierei di avere prima di iniziare.

1. Controllo della fonte
2. Tracciamento dei problemi
3. Integrazione continua

Se queste tre cose sono attive e funzionanti, eliminerai circa il 75% del problema comune che si verifica quando porti un nuovo membro del team. Il punto di questa tecnologia è prendere molto di ciò che sta accadendo solo nella tua testa e farlo uscire dove il tuo membro del team può interagire con esso.

Il controllo del codice sorgente assicura che entrambi lavoriate sulla stessa cosa. Il monitoraggio dei problemi ti aiuta a tenere traccia di ciò che deve essere fatto e ti renderà più facile sapere su cosa stanno lavorando e realizzando. L'integrazione e i test continui ti aiuteranno ad avere un processo di compilazione ripetibile e che i nuovi miglioramenti non stanno rompendo altre parti del codice.

Pragmatic Programmer ha alcuni libri abbastanza buoni su questo. Eccone alcuni che consiglierei. Hanno altri titoli simili in base al linguaggio di programmazione che stai utilizzando o al controllo di versione che desideri utilizzare:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / titoli / auto / pragmatico-progetto di automazione

Personale

Spesso le difficoltà che dovrai affrontare sono meno dal punto di vista tecnico delle cose e più dall'imparare a lasciarsi andare. Può essere difficile dare a qualcun altro il controllo sugli aspetti del progetto, in particolare se sei abituato a fare tutto da solo e prendere ogni singola decisione. Ti risparmierai 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 una base di fiducia. Se assumi una brava persona, la cosa principale che probabilmente imparerai è come fidarti dell'altra persona per fare un buon lavoro anche se tutte le loro decisioni individuali non sono le stesse di quelle che avresti fatto.

Volete dare al vostro nuovo assunto la libertà di risolvere i problemi nel modo in cui funziona per loro, mantenendo al contempo le misure di sicurezza in modo da poter rilevare i problemi in anticipo.

Questi punti sono molto importanti secondo me:

1. Leggi le parti cruciali del tuo codice e assicurati che siano facili da capire. Usa commenti o funzioni intuitive e nomi di variabili.
2. Semplifica l'invio del codice da parte della nuova persona.
3. Se non è banale, crea un file README che spiega tutti i passaggi necessari per il nuovo sviluppatore su come impostare l'ambiente di sviluppo. In alternativa, assisti da vicino nella creazione di questo ambiente.
4. Assegna al nuovo sviluppatore compiti ben definiti quando lavora su questo nuovo progetto. A mio avviso, questi compiti dovrebbero comportare funzionalità nuove ma semplici. Le attività di pulizia non hanno molto senso secondo me poiché il nuovo sviluppatore deve prima abituarsi al tuo stile di codifica e alle sue abitudini, anche se sono cattive. La pulizia o il refactoring sono lavori che devono essere eseguiti da persone che conoscono il codice.
5. Chiarisci qual è la procedura per l'invio del codice. (Ad esempio, invia solo materiale che viene compilato.) Ma non essere troppo severo, questo può essere frustrante all'inizio.
6. Preparare un documento con convenzioni di codifica. Può essere davvero frustrante indovinare quali sono le altre convenzioni di codifica.
7. Se l'app è complessa, tieni pronto un po 'di documentazione che spieghi l'architettura. Oppure spiega l'architettura alla nuova persona usando i diagrammi di flusso o qualcosa di simile. Non vuoi far perdere troppo tempo al nuovo sviluppatore nel retroingegnerizzare il tuo progetto.
8. Se si suppone che il nuovo sviluppatore debba eseguire le implementazioni da solo, disporre di un elenco di controllo ordinato pronto che spieghi tutti i passaggi necessari necessari per l'implementazione.

E ultimo ma non meno importante: ottenere un sistema di controllo della versione. Subversion va bene. Ma assicurati di non aggiungere quei file Eclipse (o qualsiasi altra cosa) che sono specifici dell'utente e quindi cambiano costantemente. Ti fanno perdere ore. Non esitate a chiedere su StackOverflow se avete problemi con esso.