Come affrontare le mentalità ad hoc?

Sono entrato a far parte di un team di sviluppo di sei mesi due mesi fa. Le persone sono gentili, va tutto bene. Ma sempre più osservo una mentalità ad hoc. Le cose vengono risolte rapidamente, a scapito della futura usabilità, ci sono pochi test e due persone ammettono felicemente, che a loro piace portare le conoscenze nella loro testa, piuttosto che scriverle.

Come gestirlo? Vorrei dare l'esempio, ma il tempo è limitato: mi piace progettare e implementare le cose. Ma temo che la mentalità ad hoc mi infetti e piuttosto che lottare per chiarezza e semplicità nel design e nel codice - che non è semplice da stabilire - Vengo abbattuto sul drenaggio di una spirale infinita di hack sugli hack - che no l'outsider può disaccoppiare - solo per motivi di pianificazione e gestione.

— Rotian
fonte

Suggerisco un calcio di rinvio per causare una mancanza di capacità di trattenere i ricordi. La documentazione è essenziale per qualsiasi sistema di lunga durata ... anche se non formale.

— Rig

Benvenuti nello sviluppo di software!

— yannis,

@YannisRizos, no no no! ;)

— Rotian,

@Rotian È quasi necessaria la lettura: joelonsoftware.com/articles/fog0000000332.html . Un po 'obsoleto, ma comunque una grande risorsa, e probabilmente vale da solo una risposta.

— K.Steff,

Più in generale, consiglio "Uncle Bob" / Clean Code / e / The Clean Coder /. Non sono d'accordo con tutto ciò che dice in quei libri, ma sono un ottimo spunto di riflessione. Certamente ha aperto i miei occhi un po '!

— Michael Scott Shappe,

Risposte:

Conosci già parte della risposta: devi dare l'esempio. Devi anche sentirti a tuo agio con il fatto che la tua "leadership" potrebbe essere ignorata, che i tuoi colleghi continueranno a fare le cose nel modo in cui le hanno sempre fatte - sia perché rende felice il capo o perché essi stessi apprezzano l'opportunità manutenibilità a lungo termine.

Alla fine, devi lasciare che i tuoi risultati parlino da soli. Hai perso una scadenza di tre giorni ma hai salvato il team di controllo qualità almeno per quei giorni programmati di test perché hai guidato il tuo sviluppo e funziona in gran parte come progettato? Questa è una vittoria.

Alla fine, tuttavia, se non hai almeno un certo grado di buy-in gestionale per quel tipo di compromesso, sei semplicemente in un ambiente sbagliato e devi trovare un altro che favorisca le buone pratiche. Le cattive pratiche stanno prendendo forma, quindi prima puoi trovare il modo di resistere o cambiare in un ambiente di lavoro con pratiche migliori, meglio è.

— Michael Scott Shappe
fonte

Apprezzo la tua risposta Immagino che tu conosca abbastanza bene il mio ambiente - cercherò di lavorare di più - e se non ottengo un risultato - cercherò qualcos'altro.

— Rotian,

+1. Sii il cambiamento che vuoi vedere nella tua squadra. Imposta lo standard.

— Scott C Wilson,

+1 per lasciare che i risultati parlino da soli. Quello combinato con l'esempio è il modo migliore per influenzare il cambiamento positivo. Le persone naturalmente vogliono fare un buon lavoro (la maggior parte, comunque), e se vedono qualcuno ottenere risultati migliori dei loro, è probabile che chiedano il segreto. E molto probabilmente ascolteranno quando chiederanno di propria volontà che se gli viene detto, non richiesto.

— Erik Dietrich,

@Rotian Non il tuo ambiente specifico, ovviamente, ma sì, ci sono stato e l'ho fatto. La parte peggiore era, all'epoca, non capivo nemmeno quanto fosse grave. Sapevo solo che qualcosa non andava bene a un livello profondo, e alla fine ho deciso che era abbastanza per uscire. È solo negli ultimi anni che sono stato in grado di indicare pratiche specifiche che avrebbero dovuto (o non avrebbero dovuto) fare.

— Michael Scott Shappe,

Niente?

Voglio dire, esistono vincoli di tempo aziendale. Il tuo potrebbe essere uno scenario in cui il time to market è più prezioso della futura facilità d'uso.

Se sei un programmatore di file e di rango, allora definire gli standard e interessarti dell'architettura del prodotto non è davvero il tuo lavoro (soprattutto dopo 2 mesi). Si dovrebbe cercare di migliorare il prodotto tuttavia è possibile (compreso il cambiamento di cultura), ma non a scapito di alienarsi la vostra squadra e / o capo. Essere il nuovo ragazzo che pensa di conoscere meglio è un modo semplice e veloce per farlo.

Vorrei chiedere perché stai facendo tutte queste correzioni rapide? È dovuto a correzioni rapide precedenti precedenti? È abbastanza facile quindi sottolineare che se le cose fossero state fatte "bene" in primo luogo ...

Alla fine, le cattive pratiche di programmazione portano a dolori concreti. Se la gente pensa di no, tutto ciò che devi fare è aspettare.

— Telastyn
fonte

Per quanto ho capito, il problema non è che queste persone apportano correzioni ad hoc a causa dei vincoli temporali. Il problema è che non lo vedono come un debito tecnico che dovrebbe essere rimborsato in futuro. È come saltare: puoi cavartela senza il supporto della Terra per un po 'di tempo, ma è meglio che tu sia pronto ad atterrare.

— 9000

@ 9000: l'OP dice che è per motivi di pianificazione e di gestione, quindi sto indovinando (sperando) che sia principalmente la pressione del tempo. Sottovalutare il lavoro effettivo coinvolto nello sviluppo del software non è esattamente raro.

— Telastyn,

Sono d'accordo che le cattive pratiche portano a dolori concreti; ma il dolore concreto non porta sempre ai cambiamenti che ti aspetteresti di vedere in un mondo razionale. Per esperienza, posso dirti che esistono manager che non impareranno da quel dolore e non verranno per incoraggiare le pratiche giuste. Continueranno a confondere, perché fare altrimenti richiederebbe di resistere ai LORO capi per difendere il tempo dedicato a farlo "bene", cosa che non sempre sono disposti a fare.

— Michael Scott Shappe,

@UncleMikey: certo. Ma se i tuoi manager sono troppo inefficaci per pianificare le cose in modo appropriato, c'è molto poco che puoi fare.

— Telastyn,

@ 9000 e Telastyn - sì, penso sia entrambi - una certa ignoranza sul fatto che una cosa come il debito tecnico esista davvero combinata con un ambiente che incoraggia soluzioni alternative per vari motivi diversi (che si tratti di tempo, abitudine, ecc.).

— Rotian,