Come implementare un processo di sviluppo con studenti universitari


9

Nel mio primo lavoro come sviluppatore di software, il mio team ha utilizzato Agile / Scrum per gestire il flusso di lavoro del nostro progetto e ha funzionato abbastanza bene. Ho avuto dei mentori esperti che mi hanno messo sulla strada giusta - devo loro un grande debito di gratitudine. Ho lavorato lì per alcuni anni, poi sono passato a una nuova opportunità un paio di mesi fa.

Avanti veloce al mio attuale lavoro. Lavoro in un'università sotto la direzione di un professore. Dato che sono in un'università, quasi tutti i programmatori sono studenti (sono economici e abbondanti!) Il mio capo ha esperienza di gestione, ma non con lo sviluppo del software, e il team del software non è sempre in prima linea nella mente del mio capo . Queste condizioni hanno creato l'ambiente perfetto per la creazione di software di qualità molto scadente. I progetti software sembrano funzionare in modo un po 'disonesto, non hanno alcuna idea di progettare e hanno impiegato alcune pratiche davvero spaventose. So che le cose potrebbero andare meglio.

Voglio implementare un processo di sviluppo per aiutare tutti a seguire la strada, aumentare la qualità del codice e distribuire software più stabile. Non sono sicuro da dove cominciare.

Sto non cercando, per dire, per le risposte come "Usa Scrum", "istituito un consiglio Kanban", o "Date un'occhiata a agile!" (anche se le idee sono apprezzate). Più specificamente, spero di ottenere informazioni su come implementare un processo di sviluppo per questo ambiente di lavoro. I dipendenti di solito lavorano da 1 a 2 anni prima di passare, sono generalmente inesperti e le riunioni quotidiane di standup che includono tutti sono quasi impossibili da programmare.

In che modo si promuove la qualità, l'efficienza e la comunicazione in un simile ambiente di lavoro?

Aggiornamento: dopo aver letto alcune delle risposte e dei commenti, ho pensato di fornire qualche informazione aggiuntiva.

Io non mi considero un maestro nell'arte di sviluppo del software, ma io sono abbastanza esperienza per riconoscere cattiva programmazione quando lo vedo. Posso determinare se uno sviluppatore ha talento o no dopo aver trascorso solo un minuto o due a lavorare con loro. Sono a mio agio con le mie capacità di trovare un modo per risolvere in modo intelligente un problema , tuttavia, l'area in cui mi manca davvero l'esperienza è la gestione dei progetti in cui sono coinvolti altri sviluppatori (motivo per cui sono qui per chiedere a tutti voi meravigliose persone consigli).

L'ho fatto sembrare come se ogni studente che entra in questo ufficio sia un completo idiota. Ci sono state alcune uova cattive qui, ma la maggior parte degli studenti che ho incontrato sono intelligenti, vogliono imparare e appassionati del lavoro. Alcuni stanno appena iniziando, e non sanno cosa non sanno. E va bene. Quando ho iniziato a programmare, non stavo meglio!


Gli sviluppatori sono responsabili del proprio QA?
svidgen,

Quando viene presentato un progetto, gli sviluppatori ricevono una serie di requisiti e da quel momento tutto dipende da loro. Quindi, chiedere se gli sviluppatori sono responsabili per le proprie domande e risposte è un po 'come dare a un bambino una pistola e chiedere se il bambino è responsabile della gestione sicura dell'arma.
darksinge,

Quindi, presumo che stiamo parlando di un team di sviluppatori di studenti part-time? E tu? ... Qualche sviluppatore a tempo pieno o senior (> = 10 anni di esperienza) nel team ?
svidgen,

Ci sono un paio di sviluppatori a tempo pieno che lavorano in remoto, ma non li vediamo molto (o per niente). In ufficio, sì, i dipendenti sono tutti studenti part-time. Attualmente sto lavorando a tempo pieno, ma avvierò presto un programma di Master, quindi potrebbe cambiare;) Ho 5 anni di esperienza, non molta esperienza nella gestione di progetti.
darksinge,

Non ho ancora avuto tempo per una risposta completa. Ma, qualcosa da considerare: scrivo codice da circa 20 anni. Almeno 10 anni in contesti professionali, tra cui persone di livello piuttosto senior. La varietà di ciò che gli sviluppatori di software esperti chiamano il codice "buono" e "cattivo" è vasta . Un buon primo passo potrebbe essere quello di articolare ciò che rende il codice "buono" o "cattivo" in un modo che possa fornire confini in cui la sperimentazione è incoraggiata, la creatività e l'innovazione sono premiate e la tua esperienza e opinioni sono riconosciute come preziose, ma alla fine limitate .
svidgen,

Risposte:


4

Ci vuole più tempo per ripulire un errore di quanto non faccia per verificarlo. Se hai a che fare con sviluppatori che sono (possibilmente) non qualificati o ignari delle buone pratiche, ciò significa che non dovrebbero essere in grado di modificare la base di codice (principale) fino a quando il loro codice non è stato esaminato da qualcuno con esperienza.

Non volevi una spiegazione delle metodologie, quindi lasciami sfuggire a quella parte: usa attività agili per impostare diverse funzionalità che possono essere sviluppate in modo indipendente.

Inizia a utilizzare i rami delle caratteristiche, in modo che tutti lavorino su un ramo separato. Al termine di un'attività, lo sviluppatore non è in grado di unire il proprio codice al ramo principale. Se stai usando Git, possono comunque avviare una richiesta pull. Altrimenti, usa qualsiasi metodo di tracciamento delle attività finite (/ rami) che ti piace.

Quindi arriviamo al processo di revisione . Ciò su cui ti poni è un po 'vago se ci sono anche sviluppatori esperti il ​​cui giudizio può essere considerato più attendibile di quello degli studenti. Quindi lasciami elaborare in entrambi i modi:

Se ci sono sviluppatori esperti, affidali alla revisione del codice delle attività completate. Se va bene, possono unirlo nel ramo principale. In caso contrario, possono rifattorizzarli da soli o fornire feedback allo sviluppatore su ciò che deve essere migliorato.

Se non ci sono sviluppatori esperti, allora incontrerai sempre dei problemi. Se non è possibile individuare codice valido da codice errato, è impossibile mantenere la qualità del codice.
Il meglio che puoi fare è tenere riunioni di revisione, in cui gli sviluppatori presentano e spiegano la loro implementazione di fronte agli altri sviluppatori. Sebbene ciò non possa garantire la prevenzione di ogni problema (ad es. Se tutti gli sviluppatori hanno lo stesso malinteso riguardo alle buone pratiche, impedirà comunque la maggior parte dei problemi (ad es. Se almeno uno sviluppatore ha l'idea giusta e può articolarla; o quando il problema si pone dagli sviluppatori che comprendono il problema in modo diverso l'uno dall'altro)

In che modo si promuove la qualità, l'efficienza e la comunicazione in un simile ambiente di lavoro?

  • Qualità : rivedere il codice da sviluppatori esperti. In assenza di sviluppatori esperti, trasformalo in una recensione di gruppo per coprire almeno le tue basi nel miglior modo possibile.
  • Efficienza : se imposti correttamente le attività indipendenti, riduci al minimo le persone che devono attendere l'una sull'altra. In un ambiente in cui non tutti sono disponibili contemporaneamente, suppongo che tu abbia a che fare con molti ritardi di "attesa della persona A". Seguire gli sviluppatori che non stanno facendo progressi, solo per verificare se hanno bisogno di aiuto o anche solo per consentire loro di sfogare le loro frustrazioni (tali frustrazioni possono rivelare idee sbagliate su problemi evitabili).
  • Comunicazione : imposta una politica a porte aperte affinché gli sviluppatori possano chiedere aiuto, feedback o ispirazione a qualcuno. In assenza di un mentore qualificato, cerca di facilitare l'interazione di gruppo (puoi ovviamente farlo anche se hai un mentore disponibile, ma l'importanza di farlo aumenta in assenza di un mentore). Soprattutto in una situazione in cui le persone lavorano in remoto e in orari diversi, gli sviluppatori spesso non sono vicini ai loro colleghi e tendono a non comunicare tra loro. Anche una manciata di incontri sociali può fare miracoli per migliorare la comunicazione legata al lavoro in altre occasioni.

Ci sono state delle buone risposte, ma questa è stata la più completa e diretta, grazie!
darksinge,

1
Questo è vicino ma non del tutto lì. Sono d'accordo con le revisioni del codice, ma non sono d'accordo con lo sviluppatore esperto che fa le correzioni, questo crea un circuito di feedback estremamente negativo in cui i programmatori più sciatti invadono il programmatore esperto con il lavoro più veloce di quanto possano ripulirlo. È molto meglio rimandare le recensioni al programmatore originale e farle fare il lavoro. Ciò raggiunge l'obiettivo di insegnare loro come programmare meglio, ma ha anche il vantaggio di rallentare i programmatori sciatti impantanandoli in rilavorazioni fino a quando non producono software a uno standard accettabile.
mcottle

@mcottle Stai contrastando un punto che non ho mai sollevato. Il refactoring non è uguale al fissaggio. Se il codice non funziona, deve essere rispedito, come hai detto. Se il problema è un piccolo argomento stilistico, è comunque importante tornare allo sviluppatore, ma a volte è più facile correggerlo invece di doverlo spiegare in dettaglio. Ha il vantaggio che puoi mostrare al deceloper il codice migliorato in modo che capiscano cosa intendi.
Flater,

8

La cosa più importante per quel tipo di ambiente in cui le persone sono nuove e che probabilmente lasceranno è la revisione obbligatoria del codice.

Aiutano a diffondere la conoscenza di ciò che dovrebbe essere fatto. Aiutano a impedire che il codice peggiore entri nella base di codice. Promuovono la coerenza nell'attuazione.

Perché con così tanto turnover e inesperienza, la comunicazione è più importante del solito.


2
In realtà sono un po 'scettico di questo. Non sono d'accordo sul fatto che dovrebbero essere richieste revisioni del codice ... Ma stai parlando di un gruppo di sviluppatori senza informazioni che chiedono feedback da altri sviluppatori senza informazioni - a meno che tu non pensi che l'OP abbia il tempo di rivedere e lasciare commenti su tutto . .. Intendo. Forse non è così inverosimile. Dipende dall'afflusso. Ma le "recensioni di codice" non sembrano (per me) più di un quarto della soluzione. Voglio dire, nella migliore delle ipotesi.
svidgen,

@svidgen: non credo che stesse sostenendo recensioni di altri sviluppatori senza idea. Non ha mai specificato esplicitamente (quindi potrebbe andare in entrambi i modi), ma nella mia esperienza, le recensioni avvengono più comunemente da colleghi esperti o persone nella catena (lead dev), specialmente nei casi in cui alcune attitudini degli sviluppatori sono imprevedibili o non provato.
Flater,

1
@svidgen - all'inizio potrebbero dover essere eseguiti dal lead, ma il problema è avere un carico in barca o sviluppatori senza idea. Non lo risolvi senza renderlo non-clueless. Idealmente, ci saranno alcuni sviluppatori che lo ottengono e quindi possono aiutare a eseguire revisioni del codice su elementi meno critici.
Telastyn,

2

Più di un'idea che di una soluzione, ma trova una sezione critica della base di codice che contiene caratteristiche ed elementi simili ai progetti che i tuoi studenti studenti potrebbero fare e ripulirla MOLTO bene. Un grosso problema con i nuovi sviluppatori è che non conoscono le norme e le convenzioni della base di codice e cercheranno altro codice per farsi un'idea di come impostare la propria. Avere un sacco di sviluppatori newish che lavorano in una base di codice disordinata significa che vedranno il pasticcio e penseranno che sia accettabile o il modo migliore per fare le cose. Le cattive pratiche si perpetuano quindi anche in un ambiente con rigiri elevati.

Avendo almeno una sezione di codice incontaminata e ben scritta (o anche solo un file), puoi dire ai tuoi sviluppatori studenti di usarlo come esempio di buone pratiche. Di 'loro che sarai entusiasta se sapranno scrivere codice simile a quello, e che gran parte dell'altro codice potrebbe non essere un buon esempio del modo giusto di fare le cose.

L'aggiunta di commenti o altra documentazione con una spiegazione del perché le cose vengano fatte in un certo modo aiuteranno anche i nuovi sviluppatori ad accelerare più rapidamente con le migliori pratiche di codice.


2

Integrazione continua -

Questo è un quadro pratico e concettuale per l'implementazione incrementale e flessibile di strumenti, abilità e processi del team.

CI è l'idea di un flusso di lavoro dalla scrittura del codice alla distribuzione. Questi compiti sono concettualmente e effettivamente indipendenti.

CI è l'automazione, in particolare. Ciò ha profonde implicazioni per la qualità e la produttività, a partire dal punto in cui il codice viene digitato sullo schermo.

  • L'implementazione dell'attività CI può essere affrontata in modo indipendente, dettagliato e simultaneo. L'attenzione può spostarsi secondo necessità.
  • Non introdurre uno strumento CI da minestra ai dadi
    • Tutti voi sarete distratti dal processo e tenderete a imbiancare le abilità incapsulate.
  • Introduci le cose in grande stile
  • Aspettati di essere l'agente di cambiamento a tempo pieno. Diventa il leader; non solo un manager, non solo il programmatore senior.

  • Sii strategico

    • Il Santo Graal di CI è un manuale, compilato per l'automazione della distribuzione. Non possono FUBAR se non riescono a toccarlo.
    • Materiale per la formazione e la formazione.
      • Processi documentali.
      • Crea un Manuale del programmatore , lascia che si evolva organicamente.
      • Obbligatorio.
      • Schemi di esplorazione rivolti a competenze specifiche e alla base di codice stessa.
    • Installa i valori del programmatore professionista, come:
      • TDD crea assolutamente qualità
      • Le revisioni del codice includono tutti gli artefatti: commenti, codice commentato, unit test, ecc.
      • "Sono imbarazzato dal numero di bug trovati"
      • L'obiettività non è soffocata dal senso di proprietà del codice personale e dalla paura di "offendere" il proprietario.
  • Sii tattico

    • Le attività CI discrete possono esse stesse essere automatizzate, ad esempio un commit di controllo versione che avvia la compilazione e i test unitari.
    • Regole applicate dall'automazione, come la formattazione del codice.
      • Fai attenzione a troppe minuzie pedanti. Lo strumento inizierà a essere ignorato. Modula l'applicazione delle regole in modo che non sia travolgente.
    • Implementare subito Test Driven Development
    • Dare la priorità e sottolineare ogni cambiamento
      • Non dare per scontato che le conoscenze chiave e i salti di abilità avvengano semplicemente.
    • Non consentire l'urgenza di sovvertire l'implementazione corretta
    • Guida il cambiamento e prosegui
      • È necessario un nuovo orientamento per i ragazzi e una formazione minima.
      • Formazione esplicita e guida inequivocabile per cose nuove
      • Addestrare almeno ad alcuni standard minimi, teorici. Non deve essere molto formale, ma una passeggiata casuale su YouTube non si sta allenando. Verifica personalmente - ancora una volta evita la formalità.
    • Sii il revisore del codice, rivedi tutto il codice.
      • Guida esplicitamente alla correzione di bug e condividi esperienze di apprendimento notevoli.
    • Flessibilità rigida. Scusa, ho dovuto dirlo. Ma è vero.
  • Crea cultura
    • Hanno aspettative professionali
    • Standardizzare gli strumenti
    • Enfatizzare l'apprendimento rispetto alle metriche di produzione
    • Sii un mentore
    • Quando si introduce il cambiamento, semplicemente dipendendo dall'iniziativa degli individui "per renderlo così" sovvertisce sottilmente lo sviluppo del team. L'identità di un team coeso include i suoi comuni: strumenti, conoscenza e livello di abilità. Il rispetto reciproco cresce nella misura in cui ogni membro abbraccia le tesi come valori meritevoli. Il capo squadra è il modello, è inevitabile; non modellare un atteggiamento e un'aspettativa "qualunque".

La strada per la qualità

  • Test unitari

    • chiave per Test Driven Development
      • Non è necessario leggere interi libri a riguardo
      • Questo dovrebbe diventare il paradigma della codifica
      • Come leader devi continuare fino a quando tutti fanno il "salto di fede nella prova unitaria". Quel paradigma cambia da "Sto scrivendo il doppio del codice!" ad abbracciare la sua straordinaria produttività.
    • Il test unitario era obbligatorio nel nostro negozio. Ma molti non l'hanno fatto perché non volevano. La mancanza di convinzione della direzione ha inviato il messaggio secondo cui i test unitari non funzionano davvero.
  • Controllo della versione

    • Lo metterei per primo, ma è più facile iniziare con i test unitari
    • non ritardare altre iniziative perché il controllo della versione non è così semplice
    • Crea un piano di controllo della versione.
      • Devi scriverlo.
      • Fallo anche se è semplice come "gettare tutto nel bagagliaio e non ramificarsi".
  • Recensioni di codice

    • Questo ha il massimo potenziale per migliorare la qualità del codice in dettaglio.
    • Utilizzare un processo di revisione 2.
      • Sono rimasto molto sorpreso da quanti bug cattura una seconda recensione.
      • Fidarsi ma verificare. Esegui il codice Perché dovresti anche dirlo? Vedi immediatamente sopra.
      • Inizialmente sarai l'unico recensore. Chiedi al team di vederti commentare "dal vivo". Non impareranno mai a pensare diversamente.
      • Presto sarai solo il secondo recensore. Come garanzia delle competenze individuali, farli rivedere; alla fine entrambi i revisori. Ovviamente guarderai sempre il codice, senza eccezioni.
  • refactoring

    • Questa è una disciplina distinta e formale.
    • Refactoring: migliorare la progettazione del codice esistente di Martin Fowler
      • Ricette di refactoring codificate che assicurano la modifica del codice senza errori indotti.
      • Inizia una biblioteca professionale con questo libro.
    • A parte la formalità, introducila ad hoc attraverso revisioni del codice
  • Cattura il tuo ambiente

    • Configurazioni dello strumento di base: controllo versione, IDE, strumento CI, sistema operativo, ecc.
    • Il codice sorgente, la documentazione e le configurazioni devono essere sincronizzati nel controllo versione.

Una parola sul processo

Agile (e i suoi sottogeneri come Scrum): Dimenticalo. "Sei agile, non agile." Guarda questi di Dave Thomas, uno dei firmatari originali del Manifesto Agile .

Dato piccoli team inesperti, il mio senso dell'umorismo si spegne quando vedo strumenti di integrazione di team come Visual Studio Team Services. La mia esperienza qui è limitata ma sento l'imposizione di processi rigidi, superflui e rigidi. So che molti usano queste cose con grande efficacia ma attenzione potenzialmente all'acquisto di una soluzione in cerca di un problema.


Una parola sugli strumenti

Solo io. Non da quei "migliori strumenti software adesso ..." vasi da miele a scatto.

Jenkins

Uno strumento di integrazione CI. Basato sul Web, ampiamente utilizzato. In sostanza, tramite una GUI Web, è possibile configurare e automatizzare in modo personalizzato le varie attività e l'ordine di esecuzione come la compilazione, l'esecuzione di unit test, l'aggiornamento del controllo versione. È molto A-La Carte, quindi è adatto al tuo nascente ambiente CI.

Controllo versione

Preferisco Mercurial rispetto a Git. Questo post sul blog è il motivo per cui ho originariamente scelto Mercurial: Git è MacGyver, Mercurial è James Bond

Subversion è buono. Mercurial & Git hanno un'architettura diversa che è superiore a quella di Subversion.

Ambiente di sviluppo integrato

Ecco una grande considerazione se tutti usano strumenti di codifica diversi: Non esiste una cosa come il testo normale


Una parola su una biblioteca professionale

Internet è ampio, superficiale e disorganizzato.

  • Codice completo di Steve McConnell
    • Fai leggere a tutti il ​​terzo medio.
    • Ha un'appendice di libri professionali suggeriti.
  • Refactoring: migliorare la progettazione del codice esistente
    • Ricette di refactoring codificate che assicurano la modifica del codice senza errori indotti.
  • Errori del software. Nessuna raccomandazione specifica, ma dovrebbero essere storie di fronte a un trattato.

0

Propongo di utilizzare un'altra metodologia per gestire il tuo processo, poiché come dici tu è impossibile programmare riunioni (che è assolutamente importante per la mischia!). Non c'è ancora niente di male a fare un buon concetto, quindi tutti sanno cosa sta succedendo (probabilmente usando anche un prototipo vert) e usando il modello a cascata. In entrambi i casi, la comunicazione è la parte più importante del lavoro.


1
che cos'è un prototipo vert; potresti considerare di espandere la tua risposta in modo che sia piuttosto concisa.
esoterik,

Mi dispiace, ho avuto poco tempo stamattina. In primo luogo, un [prototipo verticale] (tutorialspoint.com/sdlc/sdlc_software_prototyping.htm) è un tipo di prototipazione che significa che costruisci completamente il tuo software senza implementare alcuna funzionalità. I vantaggi sono che in primo luogo il cliente presunto può vedere come potrebbe apparire il prodotto, in secondo luogo dà allo sviluppatore una buona sensazione su quale sia la "necessità" di funzionalità / quali dati deve fornire.
gkhaos,

cosa intendi con "piuttosto conciso"? Il tipo di gestione del progetto è piuttosto difficile da determinare perché dipende da varie cose, come ad esempio il tuo progetto? Quanto è grande la tua squadra? Ad esempio, nella mischia hai bisogno di uno scrum-master che dovrebbe avere una profonda conoscenza della mischia. Ho appena provato a considerare che la mischia non è l'unica risposta alla gestione del progetto.
gkhaos,

0

Ti incoraggio a utilizzare il controllo del codice sorgente se non lo sei già. Ciò ti consente di vedere cosa è stato archiviato da ogni sviluppatore e consente di regredire dove è stato introdotto un bug.

Avrei creato una specie di suite di test. Potrebbe essere test-driven-development in cui si scrivono test per ogni funzione che si sta eseguendo, oppure potrebbe essere un modo automatizzato per eseguire le applicazioni e far sì che i risultati vengano stampati in un file che può essere confrontato con quello desiderato produzione. Se questo viene eseguito dopo ogni commit o eseguito almeno una volta a notte, troverai rapidamente le regressioni.

L'ultima cosa che vorrei fare è implementare 2 criteri: 1) tutte le build devono avere avvisi impostati su errori e tutti gli errori attivati ​​2) Tutto il codice deve passare attraverso l'analizzatore statico senza produrre errori o avvisi prima che venga eseguito il commit. Lo farei persino un'azione pre-commit. Queste 2 cose impediranno al codice di diventare rapidamente orribile in molti modi comuni. (Non catturano tutto, ma catturano molto.)

Questo preparerà anche i tuoi studenti a come sarà il lavoro nel "mondo reale" e instillerà in loro delle abitudini ragionevolmente buone.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.