Uno sviluppatore (junior) dovrebbe cercare di promuovere processi e pratiche migliori nel proprio team di sviluppo / IT?

Sono uno sviluppatore junior a cui viene data la possibilità di aiutare a modellare i processi del mio team se posso giustificare il cambiamento e se aiuta il team a svolgere il proprio lavoro. Questo è nuovo per me poiché le mie aziende passate avevano più o meno processi rigidamente definiti che provenivano dal management.

La mia squadra è piuttosto piccola e piuttosto nuova (<3 anni). Sono sprovvisti:

• un framework ben definito di sviluppo software / gestione del lavoro (come scrum)
• forte proprietà del prodotto
• ruoli ben definiti (ad es. il personale aziendale eseguirà test manuali)
• riunioni stand-up regolari
• un processo di tracciamento dei problemi consolidato (abbiamo uno strumento, il processo è ancora in fase di sviluppo)
• un'unità, un sistema, una regressione o una suite o un elenco di test manuali
• documentazione sulla logica e sui processi aziendali
• una base di conoscenza per documentare suggerimenti interni e rivolti al cliente

E la lista continua. La direzione è aperta all'implementazione di miglioramenti fintanto che il valore è giustificato e aiuta a svolgere il lavoro più importante (vale a dire lo sviluppo). L'ipotesi di base è tuttavia che devi assumere la proprietà nell'implementazione, poiché nessuno lo farà per te. E 'ovvio che alcuni dei progetti di cui sopra sono non banali, senza dubbio richiedono tempo e chiaramente non sono lavori di sviluppo.

Vale la pena lo sforzo di uno (junior) sviluppatore per cercare di spingere per quanto sopra col passare del tempo? Oppure è meglio "rimanere nella tua corsia" e concentrarsi sullo sviluppo e lasciare la maggior parte della definizione del processo e dell'ottimizzazione alla gestione?

Buone risposte finora, ma non coprono tutte le basi.

Nella mia esperienza, molte persone appena uscite dal college hanno una conoscenza teorica fantastica - molto meglio di me o di molti altri anziani con decenni che costruiscono software per vivere.

MA, e questo è un grande MA, che la conoscenza non è fondata su alcuno scenario pratico. Nel mondo reale, gran parte di questa teoria è piatta, o per lo meno deve essere presa con un enorme granello di sale in quanto si trova nella pratica per non funzionare così bene in uno scenario del mondo reale.

Caso in questione: un'applicazione a cui ho lavorato molto tempo fa è stata progettata da un geniale teorico OO, progettato per seguire i principi e la teoria OO sulla T, con molti modelli applicati ovunque.

È stato un fantastico pezzo di progettazione software.

Purtroppo, ciò ha provocato un incubo di produzione e manutenzione. La base di codice era così ampia e complessa che i posti erano impossibili da cambiare; Non perché fosse particolarmente fragile, ma perché era così complesso, nessuno osava toccarlo per paura di ciò che sarebbe accaduto (l'architetto / designer originale era stato un appaltatore che era partito da molto tempo).

Ha anche funzionato in modo molto scadente, proprio a causa della struttura a più livelli dei modelli e delle librerie di classi richieste dal design. Ad esempio, facendo clic su un pulsante su uno schermo per effettuare una singola chiamata al database si otterrebbero diverse centinaia di istanze di oggetti e chiamate di metodi, il tutto in nome di un accoppiamento libero e cose del genere.

Questo architetto era stato un professore universitario con diversi libri sull'argomento a suo nome. Non aveva mai lavorato un giorno come programmatore in un progetto commerciale.

Le persone con esperienza pratica nella creazione di software si sarebbero rese conto di quale mostruosità quella progettazione avrebbe inevitabilmente portato e adottato un approccio più pragmatico, portando a un sistema che è più facile da mantenere e funziona anche meglio.

La stessa cosa può valere per molte altre cose che incontri come neolaureato o addirittura come nuovo impiegato in qualsiasi azienda. Non dare per scontato che, poiché la tua base teorica ti dice che qualcosa non va o non è ottimale, non c'è una buona ragione per farlo in quel modo.

Anche ora, con oltre 20 anni di esperienza nel settore, sono cauto nel criticare il modo in cui le cose vengono fatte nelle aziende con cui vado a lavorare. Menzionerò di sfuggita che ho notato che le cose sono diverse rispetto alla mia esperienza essendo la più ottimale, ma non in modo bellicoso. Ciò porta spesso a conversazioni interessanti sul perché queste cose sono come sono. Forse accadranno cambiamenti e forse no, a seconda che il valore di cambiare le cose sia inferiore al costo.

Non aver paura di suggerire che le cose possono essere fatte meglio, ma assicurati sempre di non imbatterti in un bambino dal naso snot ma piuttosto come un collega che sta provando e disposto a non solo imparare ma anche contribuire a migliorare i processi per il miglioramento dell'azienda, non solo la correttezza teorica.

Sì, ma con molta cura!

Vorrei chiarirlo.

Dovresti cercare di migliorare l'abitabilità del software. Se guardi il codice / team / business / progetto / gestione e la tua prima risposta è fare la doccia, allora non è abitabile. Se la tua prima risposta è gridare sì! ... e poi lamentarti quando sei stato tolto dall'ufficio, allora devi rendere la tua casa più abitabile. È una sensazione, e lo saprai.

Detto questo, stai lavorando in una complicata sinergia . Qualunque cosa tu faccia, probabilmente andrà storto e probabilmente peggiorerà le cose almeno a breve termine, perché un semplice cambiamento ha delle increspature. Quindi prima di tutto diventa umile, non intendo diventare una spinta o accettare che le cose debbano andare male, intendo venire a patti con il fatto che le tue buone intenzioni ti accenderanno brutalmente.

Il problema

Con le migliori intenzioni potresti pensare che debba avvenire un cambiamento radicale e non sono in disaccordo sul fatto che queste situazioni esistano, ma prenditi un momento per pensarci. Il sistema attuale funziona, tu e il tuo team producete codice, forse è lento, forse è doloroso, ma funziona e tutti voi avete esperienza su come farlo. Sai più o meno cosa aspettarti, insomma sei un professionista praticato in questo sistema.

Dopo il cambiamento radicale, però nessuno, tranne forse l'implementatore, sa cosa aspettarsi. In breve, ognuno è stato riportato a un livello di neofita in questa parte del sistema. Questo non è buono. I neofiti devono imparare le nuove regole che richiedono tempo. A quel tempo i neofiti stanno commettendo errori perché non sono praticati. Questi errori diventano parte del sistema, con cui ora devi convivere e non è neanche così vicino.

Una via da seguire

Ci sono momenti in cui tagliare, bruciare e ricostruire è di gran lunga il meglio che puoi fare. È particolarmente attraente se nessuno è praticato nel vecchio sistema, perché l'unica cosa che si perde è la conoscenza codificata. Se questa conoscenza è completamente incomprensibile, allora è già persa e ricominciare è l'unica scelta. Al contrario, se il metodo di codificazione o il modo in cui è stato usato è problematico ma funzionante, tale conoscenza è ancora accessibile e forse vale la pena conservarla, forse non lo è - Basta non prendere la decisione alla leggera.

L'altra scelta è quella di lavorare con il sistema in modo che tutti abbiano un quadro di riferimento, ma cambiare piccole parti del sistema in modo che tutti i membri del team siano a conoscenza, o se non sono a conoscenza del cambiamento, è facile notare e facile da imparare. Questa è la base per le pratiche chiamate Kaizen . Una presentazione più orientata agli sviluppatori è presentata nella presentazione Shaving the Golden Yak, consiglio vivamente di guardarlo e di pensarci su.

Quindi trova una piccola cosa che può essere cambiata che migliorerà la tua vita e, si spera, quella di pochi altri. Risolvi o migliora la situazione. Questo ti darà pratica ed esperienza su come mettere in pratica i cambiamenti. Assicurati di ricevere un feedback: avresti potuto discuterne meglio, se fosse stato effettivamente utile, ha sconvolto un'altra parte del sistema? Sviluppa la tua sensibilità per ciò che può essere fatto e come farlo.

Ora sono successe tre cose:

• hai migliorato il sistema,
• hai acquisito esperienza su come cambiare il sistema
• il team ti ha visto cambiare con successo il sistema.

Ora scegli un'altra cosa da migliorare, man mano che la tua esperienza cresce e mentre elimini i problemi di sospensione, inizierai a confrontarti con i problemi più difficili nel sistema, ma almeno ora quando dici che dobbiamo cambiare X:

• Sai come la modifica influirà sul sistema
• Sai quali problemi genererà (quali regole devono essere riapprese)
• Conosci alcuni modi immediati per risolvere o migliorare i problemi che la modifica introdurrà
• le persone intorno a te sono consapevoli di essere a conoscenza del sistema e in grado di cambiarlo con successo

Si, puoi. MA...

Devi essere attento.

All'inizio della mia carriera (molto tempo fa) sono stato fortunato / sfortunato ad entrare in un progetto di pochi mesi come "Junior".

Come prima cosa che ho notato, non c'era (OMG) nessun repository di codice! Tutte le fusioni di codice sono state eseguite manualmente inviando i file zip l'un l'altro per posta.

Quindi sono andato dal mio (anche nuovo) manager e ho suggerito di avere un repository. La risposta è stata: Ok, organizzala ....

Quindi organizzare un repository di codice, senza aiuto, è stato nuovo nell'azienda, ora è stata un'esperienza umiliante.

Quando ho impostato tutto, (shock) nessuno voleva usarlo. Quindi ho cercato di far avanzare le cose e per fortuna il mio manager ha capito che è importante, quindi ho avuto supporto.

Ciò ha comportato che non mi piaceva molto e sfortunatamente ho ottenuto un soprannome derivato dal sistema di controllo del codice sorgente.

Quindi la mia opinione su questo è, prima di tutto, sentire i membri del tuo team, cosa pensano che sia importante impostare dopo.

Forse hanno anche un elenco come il tuo. Forse hanno pensato a tutto e volevano fare quella "cosa" sulla lista. Forse loro .... (qualunque cosa) ....

L'intero team deve essere allineato.

Ma se non lo sono, puoi comunque lavorare in modo professionale. E trova persone affini e lavora insieme come pensi che dovrebbe essere fatto. Se questo porta buoni risultati, più persone lavoreranno con te, alla fine diventerà il "processo".

Proprio come con il codice, lo stesso per i processi di sviluppo: è necessario un miglioramento continuo.

Quindi sì, dovresti sempre cercare di migliorare, ciò che è possibile migliorare.

Ma ricorda anche che molte persone con cui lavori potrebbero già essere professionisti e sanno cosa è sbagliato e cosa è necessario.

Vale la pena lo sforzo di uno (junior) sviluppatore per cercare di spingere per quanto sopra col passare del tempo?

Sì, vale sempre la pena cercare di migliorare le cose. Sai bene quali problemi hai di fronte.

Ma come hai detto, ci sono molti problemi da risolvere e molti di questi problemi non sono terribilmente preziosi. E in molti posti, ci saranno barriere insormontabili per il tuo successo o altre persone che sono molto meglio posizionate per difenderle. Quindi dovresti sempre cercare di migliorare le cose, anche se ciò significa scegliere quali cose trascorri il tuo tempo cercando di migliorare.

Perché alla fine, se non fai parte della soluzione, fai parte del problema.

Sì. Ma il cambiamento organizzativo è difficile anche per un senior, quindi se vuoi davvero fare la differenza fallo nel modo giusto:

• Non durante le prime settimane: utilizzare questa volta per:

  • Crea una buona prima impressione. Dimostra che ti adatti alla squadra.
  • Comprendi la cultura e la politica o la tua azienda. È sicuro richiedere modifiche?
  • Costruisci un buon rapporto con i colleghi
  • Scopri il processo, le regole e le esigenze del tuo team
  • Impara il tuo lavoro e fallo nel miglior modo possibile. Sarai sicuramente abbastanza occupato.

• Scegli le tue battaglie. Ottieni alcune vittorie iniziali : potresti arrivare con energia per cambiare tutto ma questo non è realistico. Concentrati su un po 'di frutta e mostra che le tue idee funzionano. Volete che siano ricettivi a miglioramenti più complessi. E ricorda che le cose sono più facili nei libri.

• Considera le implicazioni per gli altri : faccio refactor che influenzano molti file. Anche se migliorano il codice, devo stare molto attento a evitare di trasformare le fusioni in un dolore nel culo. Prova anche a capire i motivi per cui continuano a lavorare così. Può essere che non possano usare Scrum perché mancano dei test e, comprensibilmente, hanno paura di inviare frequentemente il codice non testato alla produzione. Scrivere un test affidabile non è un compito facile. Il codice attuale potrebbe essere davvero difficile da testare. Inoltre, il team non può utilizzare né per scrivere test o codice testabile. L'attuale base di codice potrebbe essere particolarmente difficile da testare e deve essere riformattata. Potrebbero essere necessari anni per cambiare questo problema, ma almeno puoi concentrarti sulla causa principale.

• Non giudicare. Non chiedere. Chiedilo e ascolta attentamente: questo è un momento in cui la comunicazione è fondamentale e noi programmatori di solito non siamo molto bravi con sfumature sottili. Ci sono tecniche per aiutare . È facile continuare a spingere per la nostra idea invece di concentrarsi sulla risposta. Per prima cosa assicurati che sentano di avere i loro punti. Comprendi che i sentimenti sono importanti. Cosa fa sentire questo cambiamento? paura? insuficiency? rabbia? frustrazione? speranza? Pigro? Stupido? (Non far mai sentire le persone stupide). Naturalmente avresti fatto molte domande prima e questo impedirà molti passi falsi.

• Diamo l'esempio : lamentarsi è facile, creare il cambiamento è difficile. Mostra i risultati e le persone ti crederanno. Se non usano il test è possibile scrivere i test unitari. Se le persone non documentano, puoi condividere alcuni documenti di Google con il team. Tieni presente che "Ok, fallo" è uno dei migliori scenari possibili e quindi devi consegnarlo. In questo caso devi aver pensato a quali risorse ti serviranno . Esempio: dammi una piccola istanza di Amazon e due ore dagli amministratori per un server Jenkins

• Keep It Small and Simple (and Cheap): non vuoi aspettare un'approvazione formale del budget o far pensare ai tuoi capi che stai perdendo tempo prezioso da costosi programmatori. Sarebbe bello avere questo codice per rivedere il software o valutare diversi strumenti open source, ma per il momento utilizzeremo semplicemente il repository.

• Ottieni massa critica: raduna il gruppo di persone concentrato sul miglioramento della qualità. Puoi persino andare con loro a conferenze e chiedere aiuto o tutoraggio. Peopleware descrive il "risveglio del fenomeno gigante" con la base della squadra che si ribella letteralmente contro alcune pratiche stupide che rallentano la produttività. Questo individualmente sarebbe stato davvero pericoloso e non lo avrei raccomandato. Ma se tutto il gruppo è d'accordo, il cambiamento è più facile.

• Dagli un po 'di tempo. Successivamente vota con i tuoi piedi: potresti voler provarlo per alcuni mesi fino a due anni. Ma alcune aziende non hanno soluzioni facili. Alcune squadre non vogliono cambiare e non hanno incentivi. E alcune basi di codice sono puro horror. Se ritieni di essere tu contro il mondo, ricorda che ci sono molte offerte nel pool di lavoro. Volete imparare le buone pratiche e nel lungo periodo starete meglio in una situazione di pace con un salario leggermente inferiore ma acquisendo esperienza che vi renderà più preziosi.

Bonus: se riesci a scriverlo per il tuo CV / interviste. Come Junior di solito hai poco da dire e creare un cambiamento per il meglio è sempre un grande segno. Volete avere una visione molto chiara e realistica di ciò che avete fatto personalmente e del lavoro svolto dagli altri. Immagina la seguente domanda di intervista.

• Raccontami di un momento in cui hai fatto la differenza nella squadra.
• Beh, ero in un posto dove avevano pratiche molto vecchie. Molte persone non ne erano contente e la produttività aveva un grande spazio per migliorare. Così ho proposto di fare un rapido esperimento con retrospettive, abbiamo fatto X e Y e di conseguenza abbiamo ottenuto questo meraviglioso risultato misurabile ".

Sì. Ma non le cose che suggerisci.

Fuori dal tuo elenco I test di unità / integrazione sono l'unico elemento su cui puoi fare progressi.

Puoi iniziare ad aggiungerli da solo con un investimento di tempo minimo e mostrare un valore istantaneo. È un problema tecnico con benefici ampiamente accettati e non influirà sulle altre pratiche lavorative. Pur acquisendo anche maggiore conoscenza della base di codice anche se i risultati non sono stati accettati. Una vendita facile.

Gli altri sono generalmente processi aziendali che coinvolgono l'intero team o anche altri team. Potresti suggerire miglioramenti, ma saranno difficili da cambiare per un dipendente junior e il processo di modifica è generalmente non tecnico e probabilmente non correlato al tuo normale lavoro.

Vorrei anche suggerire cose come, impostare pipeline CI, implementazioni automatizzate, versioning, librerie di packaging come roba buona da attaccare

Dipende da:

• quanto ti aspetti di ottenere dalle migliori pratiche
• quanti sforzi dovrai fare per arrivarci
• quali sono le possibilità di successo e rischi - dal semplice fallimento dell'adozione alle nuove pratiche sono in realtà terribili, la qualità del codice diminuisce, le persone chiave se ne vanno, tutti ti odiano e devi trovare un altro lavoro in una città diversa dove nessuno conosce il tuo nome

Fondamentalmente: è nelle tue responsabilità passare un po 'di tempo ragionevole a sostenere ciò che pensi sia meglio, ma la decisione dovrebbe essere una responsabilità di team o di gestione. Tieni presente che raramente vale la pena alienare le persone, anche se finisci con pratiche migliori.

Non iniziare con le cose più complicate come Scrum. Inizia con i passaggi più semplici possibili.

Non hai menzionato la gestione del codice sorgente. Hai un repository di codice sorgente (git, svn, cvs, ...)? Una strategia per la codifica e la ramificazione? Questi sono semplici passaggi che un principiante può fare. Leggi quali problemi risolvono questi passaggi (cerca di) e in che modo aiuta la tua azienda a ridurre i costi (questo è ciò a cui la direzione è interessata).

Il prossimo passo potrebbe essere la compilazione automatizzata, di notte o direttamente dopo ogni check-in, ad esempio con Jenkins. Puoi anche eseguire i test automaticamente. E aggiungi alcuni strumenti per misurare la qualità del codice (oh sì: anche definire alcuni standard di codifica è un buon passo).

Per quanto riguarda la mischia, leggi meglio su "Extreme Programming" (XP). Scrum si basa su molte idee di XP e aggiunge un processo formalizzato intorno a loro - i concetti di XP possono ancora essere usati senza quel processo.

Suggerisci cose, fornisci informazioni sul terreno, cerca di convincere gli altri a provarlo, analizza i risultati, ... ma non aspettarti molta cooperazione dagli altri: la maggior parte delle persone preferisce attenersi alle loro vecchie cattive abitudini. Ma quando non ci provi, nulla migliorerà.

Hai detto che il team è abbastanza nuovo (3 anni), quindi se non puoi introdurre alcuni buoni principi ora, sarà più difficile farlo 10 anni dopo. Alcune delle cose che hai citato come il sistema di test e versioning sono tra quelle che potresti già suggerire, ma non gettare il suggerimento in questo modo senza enfatizzare i loro ovvi benefici e scegliere gli strumenti richiesti dallo stack di sviluppo.

All'inizio, fai delle domande

Leggendo la tua lista, suggerirei le seguenti domande (fai riferimento alla tua lista per vedere come si adattano):

• Come posso vedere quale lavoro richiedono gli imprenditori?
• Hai provato [Scrum]?
• Chi è il product owner per questo?
• Che ruoli ci sono?
• Cosa fa [questo ruolo]?
• Quale ruolo è responsabile di [questa attività]?
• Hai provato uno standup quotidiano?
• Come comunico i miei impedimenti al resto della squadra?
• Come faccio a sapere quali altri membri del team stanno lavorando?
• Dovremmo inserire [questo] nello strumento di monitoraggio dei problemi?
• Come dovremmo scrivere [questo] nello strumento di monitoraggio dei problemi?
• Quando [questo] accade, dovremmo inserirlo nello strumento di monitoraggio dei problemi come [quello]?
• Come facciamo i test?
• Come registriamo i nostri test affinché gli altri possano riutilizzarli?
• Hai provato [JUnit]?
• Dove è [questo] documentato?
• Hai provato [MediaWiki]?

Sostituisci le cose tra [parentesi] come appropriato per dare un senso alle domande o adattarle alle tue priorità. Considera la riformulazione se la mia formulazione non corrisponde al tuo stile.

Potresti aver già iniziato a farlo. Favorire conversazioni individuali su conversazioni di gruppo. Perché uno a uno, puoi ottenere una lettura migliore di ciò che pensa l'altra persona. Quella persona è per questo cambiamento? Contro di esso? Debolmente? Rabidly?

Quando sei nuovo, porre domande è praticamente gratuito. Le persone dovrebbero aspettarsi che tu faccia domande. Anche se le tue domande implicitamente sostengono una posizione a cui si oppongono, non dovrebbero arrabbiarsi. Dovrebbero spiegare perché si oppongono a quella posizione. Consiglio di non discutere con loro. Discutere tende a indurire le posizioni più di quanto convince. Nota chi ha quale posizione e vai avanti.

Più tardi, fai dei passi

Cerca i modi in cui tu e possibilmente altri (cioè quelli che hai notato concordando con te in precedenza) puoi avviare le modifiche che desideri. Non tutti vogliono uno standup? Perchè no? Forse quelli di voi che ne vogliono uno possono avere il proprio standup. Non efficace come con tutto il team, ma più di quello che hai ora.

Quando hai un impedimento (e supponendo che non puoi condividere in stand-up), invia un'email al team per chiedere aiuto.

Identifica quali dovrebbero essere i ruoli, possibilmente con il supporto di altri che sono d'accordo con te. Inizia ad andare costantemente dalle persone quando il lavoro coinvolge il ruolo che tu (possibilmente un gruppo tu) pensi che dovrebbero avere. Se respingono, chiedi loro di identificare chi dovrebbe possedere quel ruolo.

Chiedi ai proprietari dei prodotti (che hai identificato) di scrivere le descrizioni di come pensano che il loro prodotto dovrebbe funzionare ora e in futuro.

Installa un framework di test (se altri lo preferiscono, prendi una decisione congiunta su quale framework) e usalo per i tuoi progetti. Quando correggi i bug, scrivi dei test. Documentalo nella segnalazione dei bug sul tracker dei problemi (scritto test dimostrativo del bug, memorizzato in [location]). Incoraggia gli altri a eseguire i test quando apportano modifiche. In caso contrario, esegui tu stesso i test e invia i problemi al tracker, se necessario.

Se riesci a ottenere supporto di gestione, installa il software wiki o simile e inizia a documentare i tuoi contenuti. Se le persone ti fanno domande che mostrano di non aver letto la documentazione, indirizzale alle pagine pertinenti. Incoraggiali a porre più domande se non comprendono la documentazione. Se continuano a porre domande trattate nella documentazione, fare riferimento alla documentazione quando si risponde. Prendi in considerazione l'idea di incoraggiarli ad aggiornare il wiki se ritieni che il problema fosse strutturale piuttosto che non leggessero.

Vorrei suggerire di concentrarsi solo su un compito alla volta. E certamente spingerne solo uno alla volta. Non spingere forte. Vedi questo esempio di spingere più forte di quanto il gruppo desiderasse. Concentrati più sul cambiare il tuo comportamento che sul loro. Se la tua strada è quella giusta, dovrebbe essere ovvio per le persone che ti osservano. Le azioni parlano più forte delle parole. Cerca di non ripetere te stesso con la stessa persona quando fai una gomitata. Una volta che hai condotto il cavallo all'acqua, lascia la scelta di quando o se bere all'altro.

Alla fine, sarai più anziano

Nel tempo, il tuo team assumerà nuove persone. Smetterai di essere il nuovo assunto e sarai in grado di sostenere le tue posizioni con nuove persone. Lavora con loro per apportare modifiche. E potresti scoprire che stai facendo progressi anche con i tuoi compagni di squadra esistenti. O se non funziona, cerca un nuovo lavoro in cui abbiano pratiche migliori. Non c'è fretta. Hai un lavoro. Puoi aspettare un po 'per avere un lavoro migliore, migliorandolo o trovandone uno migliore.

Risposta breve : No, per tutti i motivi indicati nelle altre risposte. Anche quando si tratta di uno sviluppatore di livello intermedio o senior, di solito è meglio cercare prima di capire quando si entra in una nuova squadra.

Una soluzione proposta :

1) ogni volta che vedi qualcosa che ritieni debba essere migliorato, prendine nota! (in un taccuino, in una nota digitale ...)

2) Dopo 6 mesi, torna alle note e controllale. Quante idee ora sembrano inutili e inadeguate? Molto probabilmente, ti sei risparmiato un po 'di imbarazzo. Se alcune idee rimangono valide, ora sarebbe un buon momento per presentarle, se possibile provandole prima tu.

Risposta in ritardo e concordare un sacco di buoni contenuti nelle altre risposte.

Penso che sia necessario precisare che qui un problema chiave non sono le pratiche specifiche, ma la cultura generale del team.

• Creare un cambiamento culturale è difficile .
• Ancora di più se hai visto come "junior"

Tutto il resto può seguire se esiste un modo per ottenere un miglioramento continuo .

Il mio approccio per raggiungere questo è:

• Processi e procedure documentati
• Retrospettive con il team le cui azioni sono modifiche alla documentazione del processo.

Immagino che se non hai sprint non hai ancora retro regolari. Tutto ciò di cui hai bisogno è una conversazione con il team e poi agire.

Puoi facilmente iniziare i processi di documentazione. "Sono il nuovo ragazzo, ho capito bene? Lasciami scrivere." È quindi importante seguire personalmente il processo o provare a chiamare il nostro punto di interruzione.

Forse inizi con conversazioni del genere ad hoc e poi suggerisci rituali regolari.

Adottare questo approccio consente un approccio graduale, dolcemente. Puoi evitare di apparire come un junior a cui le cose sanno tutto e invece cercare di essere un facilitatore per il team che sta cambiando.

Alcune considerazioni:

• Alcuni team hanno un processo scadente, ma in realtà lo sanno già. Vogliono cambiare e hanno solo bisogno di qualcosa per catalizzarlo. Altre squadre hanno davvero bloccato i loro modi e molto più difficile da cambiare.
• Lo stesso vale per gli individui.
• Devi essere sensibile a ciò e capire chi nella squadra è aperto al cambiamento e chi no. Comprendi perché.
• Trova vittorie facili.
• Rendi i cambiamenti benvenuti nel team: trova i loro punti deboli individuali e cerca di aiutarli a risolverli.