La seguente metodologia Agile contraddice i programmatori dovrebbero avere condizioni di lavoro silenziose (uno dei test di Joel)?

Il rumore correlato al lavoro è comune negli ambienti Agili.

One might think that this would be a distracting environment. it would be easy to fear that you'd never get anything done, because of the constant noise and distraction. In fact, this doesn't turn out to be the case. Moreover, instead of interfering with productivity, a University of Michigan study suggested, working in a "war room" environment may increase productivity by a factor of 2.

Robert C. Martin - Agile Principles, Patterns, and Practices

D'altra parte, il rumore non correlato al lavoro dovrebbe essere evitato a tutti i costi.

Il Peopleware è la fonte spesso citata del perché i pensatori dovrebbero essere in grado di lavorare in relativa tranquillità. Ma anche Peopleware, dopo aver descritto un ambiente di lavoro in cui annunci regolari e quotidiani interrompono un intero ufficio pieno di persone per attirare l'attenzione di uno, continua a parlare di ambienti di lavoro perfetti in cui una squadra si riunisce in un ufficio, con il pieno controllo su dove le scrivanie e gli altri mobili sono posizionati.

Gli utenti suggeriscono che ogni pensatore dovrebbe ottenere molto più spazio di quello che la maggior parte di noi ottiene, ma non suggerisce ancora un completo isolamento. Infatti, spiega in modo dettagliato come una squadra svilupperà i propri cicli di rumore e silenzio. Le mie osservazioni in team isolati dal business, ma non l'un l'altro, sono stati gli stessi.

Direi che le condizioni rumorose del test di Joel sono cose come mettere i tuoi ingegneri nel bel mezzo di manager o di un call center. Quando il rumore è occasionale conversazioni di ingegneria, direi che questo non è ciò che Joel sta cercando di proteggere le persone contro.

Se queste conversazioni sono costanti e spesso non pertinenti per lo sviluppatore, l'ingegnere si trova in un raggruppamento scadente. Se sono rilevanti per lo sviluppatore e sono ancora costanti, allora qualcuno deve capire cosa c'è che non va nel processo che ci deve essere un dialogo costante con lo sviluppatore; chi non sa cosa stanno facendo o cosa non è chiaro a tutti? Questo è comunemente un evento quando i requisiti sono in costante flusso, che è un problema a sé stante.

Tuttavia, dovrebbe esserci sempre la possibilità di andare a testa bassa su qualcosa per entrare nella zona per uno sviluppatore, ma per la maggior parte di noi le cuffie offrono questa opportunità quando è necessario. Se un particolare ingegnere è così sensibile al suo ambiente che le cuffie non aiutano, o l'ambiente è troppo angusto perché possa essere aiutato, questo problema dovrebbe essere sollevato. Se pensi sarai troppo distratto che le cuffie non ti aiuteranno, prima fai l'empirista e provalo, ho conosciuto un minimo di ingegneri che non hanno trovato questo sufficiente.

Gli ambienti collaborativi significano canali di comunicazione aperti; non significano che le persone si siedono sopra a vicenda essendo limitati.

Se ritieni che la musica sia troppo distratta, ho conosciuto un ingegnere che avrebbe ascoltato la pioggia per tutto il giorno link

Tutto ciò detto, ho lavorato in posti che avevano uffici segreti 2 ingegneri per, ho trovato che i bravi ingegneri che collaborano comunicano bene in questi ambienti e sicuramente non hanno bisogno del bullpen layout di cubo di stile, anche se questi layout di cubo sono ancora preferibili ai layout di cubo alternativi che ho trovato, e sono vantaggiosi per i team che non sono tutti persone collaborative qualificate. Non otteniamo solo il meglio dai nostri team.

Agile sta rilasciando iterazioni frequenti e non dovrebbe essere correlato a dove ti sviluppi. Mi sembra che il tuo manager / staff dirigenziale abbia deciso che gli sviluppatori e il controllo qualità dovrebbero lavorare più da vicino per vedere cambiamenti e miglioramenti attraverso. (Forse perché ai loro occhi i progetti impiegano troppo tempo, o lo sviluppatore dice sempre "Sto aspettando il QA" e, analogamente, dal QA è "Sto aspettando lo sviluppatore"). Sembra che stiano cercando di assolvere una disconnessione dalla comunicazione (a costo della privacy).

Lavoro con uno staff di 4 persone; uno accanto a me e altri due in un'altra struttura. Utilizziamo l'approccio agile e sincronizziamo gli sforzi tramite e-mail, google talk e talvolta le note di check-in su TFS. Ma il fatto che non siamo a fianco [sopra] l'uno dell'altro non ostacola la nostra capacità di lanciare cambiamenti successivi [essere agili]. Siamo ancora in grado di andare avanti e indietro, vedere le correzioni dei bug e rilasciare nuove iterazioni quotidianamente, ma abbiamo anche la privacy dei nostri quartieri di lavoro.

Ho postato prima per evitare distrazioni sul posto di lavoro . È possibile essere sincronizzati senza essere uno accanto all'altro. Si tratta solo di gestire le comunicazioni e ottenere un campo di gioco uniforme che tutti rispettano e il risultato finale ha successo.

Penso che lo facciano. Joel pensa che programmare a un certo punto non sia uno sport di squadra e richiede un programmatore per risolvere i problemi difficili.

Non so se la codifica in isolamento, in coppia o in una stanza in cui tutti possano sentire cosa sta succedendo è la cosa migliore. Agile non sempre significa programmazione di coppie e stanze a concetto aperto. Uno sviluppatore solitario può fornire in modo agile. Ciò che è importante è avere l'ambiente coerente con ciò che ci si aspetta.

Se vuoi che i programmatori lavorino da soli, dai loro uno spazio privato. Non tutti possono concentrarsi con le cuffie per 8 ore al giorno. Ci sono probabilmente molti altri fattori che una società / manager fallirà se non ottimizzano le cose per i loro sviluppatori. È difficile essere produttivi quando non pensi che la tua azienda si interessi a te.