Costringendo gli sviluppatori a riparare alle 3 del mattino, la build che hanno rotto ha indebolito la motivazione? [chiuso]

Question

Costringendo gli sviluppatori a riparare alle 3 del mattino, la build che hanno rotto ha indebolito la motivazione? [chiuso]

#1 da (7 voti)
#2 da (6 voti)

1

Rompere la costruzione è una brutta cosa. Diversi team adottano diverse misure per incoraggiare i propri membri a evitare di rompere la build a tutti i costi.

Alcune misure sono moderate. Ad esempio, Joel Spolsky dice che il suo team di Excel aveva una regola secondo cui "chiunque avesse rotto la build doveva fare da babysitter alle build fino a quando qualcuno non l'ha rotto." (Joel Spolsky. Joel on Software , pagina 20).
Gli altri sono più drastici. Ad esempio, Steve McConnell riferisce che "alcuni progetti hanno sviluppatori che usano i beep e richiedono loro di riparare il giorno o la notte della costruzione se sono responsabili della violazione." (Steve McConnell. Rapid Development , pagina 384)

Costringere gli sviluppatori a svegliarsi e venire a lavorare nel cuore della notte per sistemare la build che hanno interrotto sembra un'eccellente opportunità per focalizzare la loro attenzione sull'affidabilità del codice che commettono e incoraggiarli a controllarlo due volte.

Allo stesso tempo, gli analisti programmatori di solito preferiscono la vita personale (quarta motivazione prioritaria secondo la Tabella 11-1 in Rapid Development pagina 252, quindicesima per manager e popolazione generale) e non può apprezzare il rischio di sentire il telefono squillare alle 3 del mattino .

Personalmente, non mi infastidisce andare a correggere i miei errori alle 3 del mattino, ma solo se lavoro per un'azienda con orari di lavoro flessibili. La maggior parte dei colleghi che conosco si rifiuteranno di venire a lavorare alle 3 del mattino, indipendentemente dal motivo e dall'importanza della loro presenza per l'azienda.

Qual è il modo di impostare misure severe come i beeper diurni e notturni mantenendo alta la motivazione? O tali misure drastiche dovrebbero essere evitate a tutti i costi e utilizzate solo quando non ci sono altre scelte, a scapito della motivazione dei membri del team?

builds motivation

posta Arseni Mourzenko 24.10.2014 - 05:52

fonte

2 risposte

7

Sospetto che questa possa essere una domanda soggettiva, ma è improbabile che costringendo le persone a riparare build a tarda notte / prima mattina farebbe qualsiasi cosa per migliorare il morale o la motivazione.

Inoltre, è probabile che il lavoro svolto alle 3 del mattino non abbia la stessa qualità del lavoro svolto durante le ore normali, anche considerando i programmi dispari dei programmatori. Ci saranno anche meno persone (se ce ne sono) in giro per fare revisioni del codice, o qualsiasi altra cosa sia parte del processo di correzione dei bug.

Infine, sembra una soluzione a un problema che non dovresti incontrare, con una corretta configurazione dell'ambiente. Usiamo Git insieme a un sistema di elementi di configurazione che consente la generazione di rami, in modo che gli sviluppatori eseguano una build su un agente CI ogni volta che eseguono un commit sul loro ramo (inclusi i test di unità). Ciò garantisce che quando un ramo di funzionalità viene unito nel trunk, il codice sia già stato unito (trunk - > feature branch), creato e testato su un sistema agnostico. In questo caso ci sono pochissime ragioni per cui una build su trunk fallire.

Quindi, alla fine, lavora in modo più intelligente, non più difficile.

risposta data 24.10.2014 - 06:07

fonte

Leggi altre domande sui tag builds motivation

Perché dovrei usare le tabelle di ricerca? Il mio standard di aggiornamento automatico è ragionevole?

score 6 · Accepted Answer

Le costruzioni rotte accadono. È impossibile evitarli completamente. Gli sviluppatori possono essere distratti mentre uniscono le modifiche o semplicemente non hanno eseguito tutti i test in un sistema molto grande in cui un test completo può richiedere molto tempo. Qualunque sia la ragione, è importante rendersi conto che non si può sempre garantire che non accadano mai.

Gli sviluppatori non vogliono essere richiamati al di fuori degli orari di ufficio. Penso che questo sia praticamente un dato di fatto. Abbastanza da ogni effetto sul morale, è probabile che facciano tutto il possibile per evitare che ciò accada. Dato che non è davvero possibile garantire al 100% che non interrompano mai la build, sospetto che l'effetto che questo tipo di sistema avrà sarà di rendere almeno alcuni di loro riluttanti a controllare le modifiche abbastanza vicino alla fine del normale ore che rischiano di essere richiamati. Se la tua suite di test di integrazione completa richiede un'ora di funzionamento, significa che le persone saranno riluttanti a fare il check-in dopo le 16:00, il che significa che c'è un ottavo giorno in cui non effettuano il check-in. Ciò comporterà molti check-in di grandi dimensioni nelle prime ore del mattino, con un rischio aumentato di rottura del build (perché il rischio è approssimativamente proporzionale alla dimensione del check-in).

Quindi, no, non penso che questa sia una buona strategia. Sospetto che in realtà avrà l'effetto opposto a quello previsto. Il suggerimento di Joel che citi nella tua domanda è un'idea molto migliore.