Perché non distribuire il venerdì? [chiuso]

Joel ha menzionato nel podcast n. 24 di StackOverflow che è politica aziendale di FogCreek non distribuire software il venerdì. Tuttavia, non ha spiegato perché.

Sono d'accordo. Al mio datore di lavoro, ci schieriamo il giovedì sera. Quindi abbiamo venerdì per ripulire tutti i bug che hanno mancato la garanzia di qualità (QA).

Tuttavia, il mio manager ha suggerito di implementare il venerdì sera nel caso in cui il QA non avesse abbastanza tempo per testare il software prima del rilascio. Dico, che mi dici dei programmi del fine settimana delle persone? E se effettuiamo il deploy di venerdì sera, dovremmo lavorare sabato per ripulire eventuali bug persi, il che fa schifo.

Allora perché non spedire il software di venerdì?

* Potremmo (non sicuri) aver bisogno di fare questo presupposto: c'è un team di sviluppo software principale situato in un fuso orario che distribuisce l'applicazione web principale della loro azienda.

Non è solo una questione di insetti. Potrebbero esserci altri oneri correlati al supporto: spiegare nuove funzionalità agli utenti, monitorare che non ci siano problemi di prestazioni.

Una nuova versione generalmente significherà un breve picco di attività di supporto, quindi programmarlo quando ci sono meno persone disponibili (o quando c'è più risentimento per il tempo impiegato) è una cattiva idea.

Non distribuire mai venerdì perché:

1. È la fine della settimana, quindi le persone sono meno acute
2. È la fine della settimana, quindi le persone non sono disponibili per correggere i bug
3. È la fine della settimana, quindi le persone non sono disponibili per rispondere alle domande
4. È la fine della settimana, quindi perché dovresti schierarti?

Hai praticamente risposto alla tua stessa domanda. È un motivo breve e dolce: se spedisci di venerdì e un bug entra in produzione, generalmente non c'è nessuno in giro per risolverlo o parlare con i clienti fino al lunedì successivo. Sono potenzialmente diversi giorni di perdita di entrate nello scenario peggiore.

Evitiamo di rilasciare codice il giovedì o il venerdì: nessuno vuole passare il venerdì a scoprire bug critici per la missione e le probabilità sono che anche se produciamo una correzione in 1 giorno, ci vorrà almeno un altro giorno prima che possa essere rilasciata, il che significa che si lavora il fine settimana o non si risolve fino alla prossima settimana.

Dipende dal tuo gruppo target. Distribuiamo principalmente il venerdì. Il nostro prodotto basato su browser viene utilizzato a livello globale dai clienti, ma principalmente durante l'orario di ufficio. Ciò significa che in realtà non abbiamo altro tempo oltre alla domenica mattina se vogliamo essere sicuri di non influenzare alcun cliente (India e Medio Oriente non escono dal lavoro d'ufficio il sabato), ma generalmente "compromettiamo" e distribuire venerdì pomeriggio.

Se in precedenza si lavorava su un sito di dati in cui volevamo idealmente distribuire nuove cose intorno al martedì, poiché l'attività ha raggiunto il picco durante i fine settimana e stranamente, il lunedì intorno a pranzo.

Comunque, si tratta di 2 considerazioni. 1. Quando sarà il meno fastidioso per i tuoi clienti (se si tratta di un'applicazione web) e 2. Quando si adatterà meglio al team di sviluppo per la correzione rapida di bug critici.

Se sei preoccupato che i tuoi sviluppatori diventino sciatti verso la fine della settimana, la tua pipeline di QA potrebbe essere troppo breve.

Normalmente ci schieriamo il martedì, poi abbiamo il resto della settimana per risolvere qualsiasi problema. Dipende anche un po 'dall'industria, se non c'è lavoro nei fine settimana forse va bene distribuire venerdì sera, ma se funzionano, allora non è una buona idea.

Per questo le persone tendono ad essere un po 'più sciatte il venerdì (già pensando a quell'appuntamento caldo | birra fredda | entrambi) e giorni prima di partire per le vacanze ;-)

Dipende davvero dalla tua applicazione e da quanto è impegnata / critica nel fine settimana.

Di solito non distribuiamo il software il venerdì, ma spesso lo facciamo il sabato o la domenica. Abbiamo riscontrato che la domenica mattina è particolarmente utile per ridurre al minimo l'impatto di un rilascio.

Dipende davvero se stai cercando di ridurre al minimo l'impatto dei tempi di inattività necessari per realizzare il tuo rilascio, OPPURE mitigare eventuali bug potenziali.

Non vedrai alcun bug fino a quando i clienti non useranno effettivamente il sistema (nella maggior parte dei casi), quindi distribuire il venerdì equivale a distribuire il lunedì mattina, se il fine settimana è a basso utilizzo.

D'altra parte, cose come lo shopping online tendono ad avere più utilizzo nei fine settimana, quindi ti sconsigliamo sicuramente di distribuirne uno di venerdì.

Dipende anche dalla tua politica di supporto fuori orario. Se hai qualcuno di guardia che può ripristinare il software, è meno rischioso. Tuttavia, preferisco farlo durante la settimana lavorativa.

Di solito distribuiamo roba dal martedì al giovedì, preferendo evitare il lunedì (il nostro giorno più impegnativo) e il fine settimana (quando un bug potrebbe rimanere inosservato causando problemi)

Si consiglia di distribuire il Venerdì in modo da avere tutto il fine settimana per ripulirlo e bug fix prima che il resto della vostra squadra nota i tuoi sviste il Lunedi.

Non pianificherei mai una distribuzione il venerdì a meno che non avessi anche intenzione di essere in ufficio il sabato per verificare che funzioni correttamente, se finisci per distribuire il venerdì a causa dello slittamento sei in grave pericolo di affrettare le cose, molto meglio aspettare , lascia che tutti si calmino durante il fine settimana, quindi spedisci lunedì dopo una revisione mattutina.

Se la distribuzione viene eseguita durante il fine settimana, iniziare venerdì sera può darti un buon vantaggio poiché spesso l'ufficio si libererà un po 'prima, quindi il carico complessivo del sistema sarà inferiore rispetto a lunedì mattina.

Ho lavorato con un'azienda che aveva una politica di distribuzione il venerdì; erano in Israele e il sabato di solito è l'ultimo giorno della settimana lavorativa. Comunque...

Nella mia ultima azienda la politica era quella di fornire a Ops il pacchetto di distribuzione entro e non oltre l'ora di pranzo il martedì e il giovedì. Ciò significa che hanno mezza giornata per tirarlo fuori e richiedere piccoli aggiustamenti se qualcosa va storto con l'ultima fase del QA pre-live. (Qualsiasi altro QA può avvenire in qualsiasi momento della settimana perché non è in diretta.)

Il rilascio in qualsiasi ambiente tranne che dal vivo va bene in qualsiasi momento, se Ops ha il tempo di farlo (ovviamente, dovrebbe essere prenotato in anticipo comunque) ma non rilasciarlo mai per continuare a vivere:

Lunedì - Male, sei appena tornato da un fine settimana (si spera non lavorativo) e non avrai tutto quello che hai fatto la scorsa settimana nella tua mente. Mercoledì - Di solito è il giorno meno produttivo della settimana e si svolge come il giorno "centrale del lavoro". Se il tuo slot era martedì e l'hai perso a causa di bug, mercoledì è probabilmente una cattiva scelta poiché non stai fornendo abbastanza tempo per correggere e testare quei bug. Venerdì, andiamo. Sul serio? È venerdì. Se questo ha davvero bisogno di spiegazioni, allora non sei abbastanza esperto per ricoprire il tipo di posizione manageriale in cui ti trovi. Ma seriamente, è perché schierare il venerdì significa offrire volontariamente ai tuoi clienti di venire nel fine settimana per testare il tuo lavoro in un live ambiente. Per me, questo batte ogni idiozia per cui potresti metterti in fila.

Abbiamo la fortuna di fare buon uso del fuso orario, abbiamo uffici sparsi in tutto il mondo. Pertanto, quando si effettuano aggiornamenti ai clienti, lo organizziamo in modo che vengano eseguiti durante la notte per il cliente in modo da ridurre al minimo l'impatto su di essi.

questo funziona bene quando controlli l'implementazione e la distribuzione del tuo software, ma il rilascio su un sito web è un altro animale. Come altri hanno già sottolineato, assicurati di concedere il tempo per:

1. Supporto di stranezze e bug che possono verificarsi
2. Supportare gli utenti nelle transizioni
3. Correzioni rapide dell'ultimo minuto