Aggiungo che ho letto da poco la regola di dhh di mantenere il rumore d'ufficio a livello di una biblioteca. Mi sembra un'ottima idea ma non l'ho mai vista in pratica.
On Thu, 13 Jun 2019, 14:26 Uberto Barbini, <[email protected]> wrote: > A volte però il pairing è anche cazzeggio e goldplating... > Sicuramente in fase di inception non c'è di meglio che essere faccia a > faccia. > Poi però trovo che lavorare in remoto (che di per sé non mi piace) > incoraggi la gente ad essere più focalizzata e disciplinata... > Invece che il ba o il dev che ha una vaga domanda in testa e ti interrompe > per un ora, se scrivono una email con il problema ben delineato e sanno che > dovranno aspettare qualche ora per la risposta di perde molto meno tempo > tutti. Sarà anche che agli inglesi piace parlare all' infinito... > > Impressione mia del tutto unscientific. > > > Uberto > > On Thu, 13 Jun 2019, 01:29 Matteo Vaccari [email protected] > [it-torino-java-jug], <[email protected]> wrote: > >> >> >> Hai ragione, le interruzioni possono essere un problema; d’altra parte è >> meglio essere interrotti da un collega che ha bisogno di un informazione e >> sbloccarlo, piuttosto che incoraggiare la gente a fare da soli il più >> possibile. Io mi sono rassegnato a pensare che il mio lavoro consiste >> principalmente nel farmi interrompere :) >> >> Lavorando in pair programming, però, noto che il danno prodotto da una >> interruzione a quello che stiamo facendo è minore, perché il contesto di >> quello che stiamo facendo non è solo in una testa ma in due. O anche perché >> il treno dei miei pensieri è più breve. Questo per me è un esempio di come >> le varie pratiche di xp si supportino l’un l’altra: team room e pair >> programming. >> >> Le interruzioni da parte di persone esterne al team sono un altro >> discorso, quelle vanno limitate e incanalate in momenti appositi e >> programmati. >> >> Il giorno mer 12 giu 2019 alle 12:19 Federico Fissore [email protected] >> [it-torino-java-jug] <[email protected]> ha scritto: >> >>> >>> >>> Non ho abbastanza esperienza per confrontare l'efficaca di un team da >>> remoto con uno co-locato. >>> >>> Ho però constatato che in un team co-locato le interruzioni sono la >>> norma, il che porta a continuo context switching, a un calo >>> dell'efficaca e a quella fastidiosa sensazione a fine giornata di non >>> sapere su cosa hai lavorato. >>> Da remoto invece lavoro per obiettivi, da solo o con un collega. Le >>> interruzioni sono asincrone, quindi mantenere la concentrazione è più >>> facile. Raramente a fine giornata non ho fatto quello che mi ero >>> programmato di fare. >>> >>> Come detto, avere una parte del team da remoto o "2 gg alla settimana da >>> remoto" è la cosa peggiore che si può fare/avere: come hai accennato, >>> per lavorare da remoto bisogna imparare a comunicare in modo diverso, e >>> avere "alcuni colleghi qui, altri là" ti costringe a un continuo >>> saltellare fra queste modalità, creando più problema che altro. >>> >>> federico >>> >>> Matteo Vaccari [email protected] [it-torino-java-jug] ha scritto >>> il 12/06/19 alle 11:25: >>> > >>> > >>> > Beh tutto vero, ma resta il fatto che per un team, lavorare in >>> presenza >>> > nella stessa stanza è parecchio più efficace che in remoto. Più >>> > efficace== riesci a fare di più e meglio in meno tempo. Tanto che in >>> XP >>> > e Scrum fa parte della definizione del processo lavorare tutti nello >>> > stesso spazio fisico. >>> > >>> > Poi se non si può si adottano contromisure per rendere la >>> comunicazione >>> > remota un po’ meno inefficace di quella in presenza. Dove lavoro io >>> > abbiamo una parte del team che lavora da remoto, e una parte >>> importante >>> > del processo è fare una inception tutti in loco con il cliente per 2-3 >>> > settimane. Questo ti permette di costruire rapporti personali con le >>> > persone, in modo che poi quando sei in remoto ti capisci meglio. Poi >>> > facciamo periodi a rotazione in cui un remoto va dal cliente o >>> viceversa >>> > (sono appena tornato da una settimana in India) >>> > >>> > Il nostro contesto è (1) sviluppo custom, siamo una azienda di servizi >>> > non di prodotto, e (2) lavoro in team; in tanti posti il lavoro non è >>> > veramente in team, ci sono solo individui che fanno la loro parte >>> > coordinati da qualcuno. In questo contesto la presenza in team room è >>> > cruciale IMO >>> > >>> > Il giorno gio 23 mag 2019 alle 10:24 Marco Bartolini >>> [email protected] >>> > <mailto:[email protected]> [it-torino-java-jug] >>> > <[email protected] >>> > <mailto:[email protected]>> ha scritto: >>> > >>> > __ >>> > >>> > Io ho la possibilita' di lavorare remoto dal 2016, in Italia e' >>> > sempre stata un eccezione, la maggior parte delle aziende per cui ho >>> > lavorato grandi/medie/piccole non sono mai state capaci di tracciare >>> > obiettivi/partecipazione/risultati in maniera efficiente, quindi >>> > l'unica parvenza di controllo era quella di averti in ufficio alla >>> > scrivania, che fa molto industria 1800... >>> > >>> > Qui in Workday c'e' una policy per il lavoro da casa tutta a carico >>> > del manager del team, puoi lavorare da casa 100% del tempo o solo >>> > quando ti serve, puoi lavorare da altre nazioni a patto che il >>> > reparto HR approvi la richiesta, diciamo che quando le dimensioni >>> > aumentano, avendo team distribuiti in diverse time zone il concetto >>> > di "lavoro da remoto" cambia, perche' praticamente e' sempre da >>> > remoto anche quando sei in ufficio e lavorando da casa >>> > oggettivamente non cambia nulla a quel punto. >>> > >>> > La differenza grossa va sulla parte di team bonding secondo me, >>> > quando lavori remoto full time e parte del team si vede tutti i >>> > giorni in ufficio, diventi un membro astratto del team e ti perdi >>> > tutte le conversazioni che non avvengono in chat/video, questo a >>> > lungo andare si riflette su produttivita' e incisivita' nelle scelte >>> > a mio parere. >>> > >>> > >>> > On Thu, 23 May 2019 at 07:59, Daniela Ruggeri [email protected] >>> > <mailto:[email protected]> [it-torino-java-jug] >>> > <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > __ >>> > >>> > Riguardo allo strumento di collaborazione, ho un amico che ha >>> > sviluppato un prodotto per la condivisione della conoscenza e >>> > affiancamento professionale per i dipendenti di un'azienda.... >>> > Ha dei clienti delle risorse umane molte interessati al prodotto. >>> > Potreste darmi un feedback, c'è la possibilità di provarlo >>> > >>> > http://www.itcoach.it/ >>> > >>> > Ciao :-) >>> > Daniela >>> > >>> > Key GPG ID: AA2DA887 -- >>> > Il miglior modo per predire il futuro è inventarlo >>> > Alan Key <https://it.wikiquote.org/wiki/Alan_Kay> >>> > >>> > >>> > Il giovedì 23 maggio 2019, 00:07:06 CEST, Carlo Bottiglieri >>> > [email protected] <mailto:[email protected]> >>> > [it-torino-java-jug] <[email protected] >>> > <mailto:[email protected]>> ha scritto: >>> >>> >>> > >>> > >>> > Eccomi, scusate il ritardo, pensavo di riuscire a rispondere dal >>> > treno ieri, ma avevo fatto over-commitment. >>> > >>> > La mia opinione sul lavoro remoto in generale è la seguente: >>> > Una società attrezzata e abituata, con le persone e le pratiche >>> > giuste, puo' permettersi persone remote anche al 100% e lavorare >>> > benissimo. >>> > >>> > Anche cosi' pero' la creatività e l'efficacia di team sono >>> > leggermente sub-ottimali : ad esempio, è stata menzionata la >>> > tendenza del remotista a prima esaurire le piste da solo e in >>> > fine chiedere; è verissimo e io personalmente lo adoro perché mi >>> > piace imparare da solo, ma ho dovuto riconoscere che non é >>> > sempre l'approccio piu' produttivo, se hai di fronte persone >>> > brave che sanno spiegare. >>> > Io trovo che un team dove chiunque chiede e offre aiuto >>> > costantemente, con creazione di binomi al volo per risolvere un >>> > problema, sia molto produttivo, ma soprattutto tende a una buona >>> > distribuzione del rispetto reciproco con poco sforzo; questo >>> > aiuta ad aumentare la fiducia e permette discussioni >>> > costruttive, una rarità. >>> > >>> > Inoltre non ho ancora trovato uno strumento di collaborazione >>> > remota pari a due persone e una lavagna (e includo anche un paio >>> > di surface-hub da 50'', che dovrebbero esserne il perfetto >>> > equivalente). >>> > >>> > Quindi la mia preferenza è creare un ambiente di lavoro bello e >>> > comodo, con tantissimi whiteboards, di facile accesso, con >>> > ottimi ingegneri che non vivano troppo lontano. >>> > A team stabile, con la giusta infrastruttura e abitudini, non ho >>> > nulla contro pescare un eccellente sviluppatore che vive lontano >>> > e averlo da remoto se non riesco a convincerlo a trasferirsi. >>> > >>> > Ho letto le altre opinioni e vorrei specificare che non sto >>> > parlando di relazioni cliente-fornitore, parlo della mia >>> > preferenza nel contesto di team R&D dentro una società che fa >>> > software come prodotto finito o per sè stessa, con i suoi >>> > dipendenti. Mi sembra ridicolo imporre la presenza fisica nel >>> > contesto di consulenze con dinamiche di team irrilevanti e in >>> > cui la contribuzione del singolo è la chiave del risultato. >>> > >>> > Nel caso specifico del mio nuovo lavoro c'è quasi tutto da >>> > costruire, a partire dai team, e sarà un'organizzazione in cui >>> > ogni team include tutti i ruoli, dal business agli sviluppatori, >>> > tutti allo stesso livello, a doppia guida, tecnica e stakeholder >>> > finale. All'inizio ci sarà troppo da perdere a non avere team >>> > fisici. >>> > >>> > >>> > On Wed, May 22, 2019 at 9:58 PM Alberto Lagna >>> >>> > [email protected] <mailto:[email protected]> >>> > [it-torino-java-jug] <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > __ >>> >>> >>> > >>> > Mah, io negli ultimi tre anni ho lavorato prima per >>> > un'azienda di Roma e poi per una di Pavia, tre giorni on >>> > site e due giorni offsite. >>> > Poichè erano grandi aziende, comunque quando dovevo parlare >>> > con una persona lo facevo sovente via chat o al telefono, >>> > anche se ero in ufficio. Poichè molti lavoravano nella mia >>> > modalità capitava sovente di fare riunioni con il 50% delle >>> > persone via skype... >>> > Mi sono sempre trovato bene con le persone che come me >>> > facevano smart working, perchè, come si diceva, il lavoro >>> > remoto deve essere un po' nelle corde delle persone. Se in >>> > una call parli piano, mostri dei disegni alle persone che >>> > sono vicino a te, ovviamente non faciliti la comunicazione >>> > remota.... >>> > Diciamo che forse proprio solo nelle call con persone non >>> > abituate al lavoro remoto ho fatto fatica. >>> > Noi eravamo avantaggiati perchè tutti nello stesso fuso >>> > orario, ma diciamo che comunque c'erano delle fasce di >>> > compresenza e anche se non fisicamente in ufficio, non mi è >>> > quasi mai capitato di non raggiungere un collega perchè era >>> > ai caraibi e lavorava in un fuso orario completamente >>> > diverso dal mio. >>> > >>> > (my eu cent) >>> > ciao e grazie >>> > Alberto >>> > >>> > Alberto Lagna - Software Architect >>> > cell. +39 333 3138664- skype alagna >>> > email: [email protected] >>> >>> > <mailto:[email protected]> >>> > pec: [email protected] >>> > <mailto:[email protected]> >>> > >>> > >>> > >>> > >>> > >>> >>> >> >
