giovedì 26 giugno 2014

Energized Work by James Shore

Energized Work

Pubblico
Allenatori
Tutta la squadra
Noi lavoriamo a un ritmo che ci permette di fare il nostro lavoro migliore, più produttivo a tempo indeterminato.
Mi piace la programmazione. Mi piace risolvere i problemi, scrivere buon codice, a guardare i test che passano, e in particolare la rimozione di codice inutile mentre faccio "refactoring". Programmo nel mio tempo libero e talvolta anche pensare al lavoro sotto la doccia.
In altre parole, io amo il mio lavoro. Eppure mi ha messo su una squadra con obiettivi poco chiari, poca responsabilità collettiva, sostenendo, e lotte di pancia, e mi sveglio temendo di andare al lavoro. Passo le mie ore in ufficio, ma sarò tentato di spendere le mie mattinate a leggere e-mail e miei pomeriggi a studiare buon codice durante la navigazione attraverso i siti web tecnici marginalmente correlati.
Siamo stati tutti in questa situazione. Perché siamo professionisti, ci sforziamo di produrre un lavoro di qualità anche quando ci sentiamo demoralizzati. Consideriamo, però, i momenti di maggiore produttività nella vostra carriera. Hai notato una grande differenza quando ti svegli e senti benedetto per andare al lavoro? Non è molto più soddisfacente quando si lascia il lavoro a fine giornata, sapendo che avete compiuto qualcosa di solido e utile?
La pratica di XP di Energized Work riconosce che, sebbene i professionisti possono fare un buon lavoro in circostanze difficili, fanno del loro meglio, il lavoro più produttivo avviene quando sono pieno di energie e motivato.

Come essere Energized

Vai a casa in tempo.
Uno dei modi più semplici per essere alimentato è quello di prendersi cura di se stessi. Vai a casa in tempo ogni giorno.Trascorri del tempo con la famiglia e gli amici e impegnati in attività che richiedono la vostra mente fuori di lavoro. Mangia cibi sani, esercizio fisico, e ottieni l'abbondanza del sonno. Mentre sei impegnato con queste altre cose, il cervello si accende sugli eventi della giornata. Spesso avrete nuove intuizioni di mattina.
Se il tempo di qualità è lo yin dell' Energized Work, rimanere concentrato a lavoro è il yang. Durante il lavoro, dare la massima attenzione. Spegnere interruzioni come la posta elettronica e messaggistica istantanea ( skype, etc...) . Tacere i vostri telefonini. Chiedete al vostro project manager di difenderti dagli incontri inutili e di politica organizzativa.
Quando lo yin e lo yang incastrano perfettamente, ti svegli la mattina, ben riposati e desiderosi di iniziare la giornata. Alla fine della giornata, sarete stanchi, ma non esausti, e soddisfatti del lavoro che avete fatto.
Questo non è facile. Energized Work richiede un sostegno ai luoghi lavorativi e alla vita domestica. E', comunque, una scelta personale; non c'è alcun modo per obbligare qualcuno a essere Energized. Tuttavia, è possibile rimuovere gli ostacoli.

Sostenere Energized Work

Stare a casa quando si è malati. Per Il rischio di infettare troppe altre persone.
Una delle mie tecniche preferite come coach è quello di ricordare a tutti di tornare a casa in tempo. Gente stanca commette errori e prende scorciatoie. Gli errori risultanti possono finire per costare più di quanto vale il lavoro speso. Questo è particolarmente vero quando qualcuno è malato; oltre a fare un lavoro scarso, avrebbe potuto infettare altre persone.
Alleato
Pair programming
Pair programming è un altro modo per incoraggiare l'Energized Work. Essa incoraggia l'attenzione come nessun altra pratica. Dopo una giornata piena di pair programming, sarete stanchi ma soddisfatti. E' particolarmente utile quando non sei al tuo meglio: l'abbinamento con qualcuno sicuramente può aiutare a rimanere concentrati.
Può sembrare sciocco, ma avere cibo sano a disposizione sul posto di lavoro è un altro buon modo per sostenere l'Energized Work. La colazione è davvero il pasto più importante della giornata. Gli abbassamenti di metà pomeriggio sono anche comuni. Cereali, latte, verdure, ed energia spuntini sono una buona scelta. Snack e cibo spazzatura, anche se popolari, contribuiscono al crollo di metà pomeriggio.
Alleato
Visione
La natura del lavoro fa anche la differenza. [McConnell 1996] riporta che gli sviluppatori di software sono motivati ​​a fare bene, il lavoro intellettualmente stimolante. Non tutti i progetti saranno in grado di nutrire i poveri o risolvere problemi completamente, ma una chiara affermazione convincente del perché il prodotto è importante può avere un lungo cammino. Creare e comunicare questa visione è la responsabilità del manager di prodotto.
Alleato
Il Gioco di pianificazione

Un obiettivo raggiungibile va di pari passo con una visione convincente. Nulla distrugge il morale più velocemente di essere ritenuti responsabili per un obiettivo irraggiungibile. Il gioco pianificazione risolve questo problema unendo valore per il cliente con le stime degli sviluppatori di creare piani realizzabili.

Parlando di piani, ogni organizzazione ha una certa quantità di politiche. A volte, le politiche portano alla trattativa sana e compromettente. Altre volte, portano a richieste irragionevoli ed al cercare colpevoli. Il project manager dovrebbe occuparsi di queste politiche, lasciando che la squadra sappia cosa è importante e proteggendoli da ciò che non lo è.
Alleati
Workspace Informativa
Segnalazione

Il project manager può anche aiutare i membri del team nel soddisfare il lavoro spingendo indietro le riunioni inutili e le chiamate in conferenza. Fornire uno spazio di lavoro informativo e di reporting appropriato può eliminare la necessità di riunioni. In un ambiente con un sacco di distrazioni esterne, vengono spesso rese inutili ore centrali di sviluppo ogni giorno, sarebbe necessario isolare almeno una o due ore di inizio giornata. Durante il quale tutti sono d'accordo di non interrompere la squadra.
Infine, le squadre "inquadrate" hanno un sacco di energia. Sono molto soddisfatte, anche. È possibile riconoscere una squadra "inquadrata" da quanto i suoi membri amano trascorrere del tempo insieme. Vanno a pranzo insieme, condividono barzellette, e possono anche socializzare al di fuori del lavoro. Come Energized Work, non è possibile forzare l' "inquadrameto", ma si può incoraggiarla; molte delle pratiche di XP farlo. Il classico lavoro su questo argomento, [DeMarco e Lister 1999] 's Peopleware , vale la pena di leggerlo.

Prendere Pause

Fermarsi quando si sta facendo più errori del progresso.
Quando stai facendo più errori che progressi, è il momento di prendersi una pausa. Se siete come me, però, quello è il momento più difficile in cui fermarsi. Mi sento come se la soluzione fosse proprio dietro l'angolo, anche se è stata proprio dietro l'angolo per gli ultimi 45 minuti, e io non voglio smettere finché non la trovo. Ecco perché è utile per qualcun altro mi ricordi di smettere. Dopo una pausa o una buona dormita la notte, io di solito vedo il mio errore subito.
A volte uno spuntino o passeggiata intorno all'edificio è abbastanza buono. Per i programmatori, commutare le coppie può aiutare. Se è già la fine della giornata, però, andare casa è una buona idea.
Di solito è possibile dire quando qualcuno ha bisogno di una pausa. Arrabbiarsi, imprecando al computer, e bruschi movimenti sono tutti segni. In un ambiente altamente collaborativo, oscurarsi -non parlando- può anche essere un segno che qualcuno ha bisogno di una pausa. Quando ho noto un paio di programmatori che sussurrano gli uni agli altri, mi chiedo quanto tempo è passato dal loro ultimo passaggio dei test. Spesso ricevo una risposta imbarazzata, e ciò quando ricordo loro di prendere una pausa.
Suggerire una pausa richiede una certa quantità di delicatezza. Se qualcuno ti rispetta come un leader, allora dovresti essere in grado di dirgli semplicemente di smettere di lavorare. In caso contrario, lo allontanarsi dal problema per un minuto in modo che possa schiarirsi le idee. Provare a chiedergli di aiutarvi per un momento, o per fare una breve passeggiata con voi per discutere qualche problema che stai affrontando.

Domande

Cosa succede se non sono pronto a testare il mio codice ed è tempo di tornare a casa?

Alleati
Test-Driven Development
Continuous Integration
Se stai praticando sviluppo test-driven e continuos integration, il codice dovrebbe essere pronto per il check-in ogni pochi minuti. Se siete alle prese con un problema e non è possibile il check-in, andate a casa comunque. Spesso la risposta sarà evidente al mattino.
Alcune squadre revertano (cancellano) il codice che non passa tutti i test alla fine della giornata. Questa suona dura, ma è una buona idea: se non si può fare facilmente check-in, siete andati fuori pista. Potrai fare meglio il lavoro al mattino. Se stai praticando bene continuos integration, la perdita del codice sarà il minimo e avrai ancora imparato dall'esperienza.

Io lavoro in una startup e 40 ore solo non sono sufficienti. Posso lavorare di più?

Se avete paura di andare a lavorare la mattina, non si è eccitato.
Un ambiente di startup ha spesso un sacco di emozioni e di cameratismo. Questo porta ad avere più energia e potrebbe significare che si può lavorare per molto tempo e dedicare ancora molta attenzione. D'altra parte,le start-up a volte confondono lunghe ore di lavoro con dedizione alla causa. Fare attenzione a non lasciare che la dedizione ignori il vostro buon giudizio in merito a quando si è troppo stanchi per fornire contributi utili.

Abbiamo una scadenza importante e non c'è modo di farlo senza tenere la testa bassa e spingere oltre. Abbiamo messo da parte Energized Work per ora?

Uno sprint verso il traguardo potrebbe aumentare la vostra energia. Non c'è niente come un Code Party a tarda notte, quando la squadra porta in pizza, ognuno lavora sodo, tutti i cilindri scottano, e il lavoro arriva tutto insieme all'ultimo momento. Un grande sprint può aiutare la quadratura del team, dando il senso di realizzare qualcosa di importante di fronte alle avversità. Tuttavia ...
Straordinari estesa non risolverà i vostri problemi di pianificazione.
Sprintare per il traguardo è una cosa; sprintare per chilometri è un'altra. Straordinari estesi non risolveranno i vostri problemi di pianificazione. In realtà, ciò ha gravi conseguenze negative. DeMarco chiama straordinari estesi "una tecnica di riduzione-produttività  importante," che conduce alla ridotta qualità, alienazione del personale, aumento del turnover del personale, e l'uso inefficace del tempo durante il normale orario [DeMarco 2002] (p. 64).
Se si lavora fuori orario una settimana (qualunque "straordinario" si intende nella tua situazione), non funzionerà più lo straordinario della prossima settimana. Se vedo una squadra sprint più di una volta o due volte a trimestre, cerco problemi più profondi.

Risultati

Quando la tua squadra è Energized, c'è un senso di eccitazione e di cameratismo. Come gruppo, presta attenzione ai dettagli e cerca nuove opportunità di migliorare le vostre abitudini di lavoro. Si fanno progressi costanti ogni settimana e si sentono in grado di mantenere il progresso all'infinito. Apprezzi la salute sul progresso a breve termine e il sentire produttivo e di successo.

Controindicazioni

Energized Work non è una scusa per bighellonare. Generiamo fiducia mettendoci in una giornata di fiera del lavoro.
Alcune organizzazioni possono rendere l'Energized Programming difficile. Se l'organizzazione utilizza il numero di ore lavorate come metro per giudicare la dedizione, potrebbe essere meglio sacrificare l'Energized Work e fare lunghe ore di lavoro. La scelta tra la qualità della vita e l'avanzamento di carriera è una scelta personale che solo voi e la vostra famiglia potete fare.

Alternative

Alleati
Pair programming
Pianificazione di uscita
Se l'organizzazione rende l'Energized Work difficile, gli errori sono più probabili. Programmare in coppia potrebbe aiutare i programmatori stanchi a rimanere concentrati e catturare tutti gli altri errori. Ulteriori test potrebbero essere necessari per individuare i difetti extra. Se è possibile, aggiungete sempre un tempo di emergenza supplementare al vostro piano di rilascio per fixarlo.
La forma estrema di questo tipo di organizzazione è la "marcia della morte", tipo di organizzazione, che richiede (o "fortemente incoraggia") i dipendenti di lavorare per tante ore di straordinari settimana dopo settimana. Purtroppo, "progetti di marcia della morte sono la norma, non l'eccezione."[Yourdon] (p. ix).
Per aggiungere la beffa al danno, [DeMarco e Lister 2003] (p. 161) pesa: "Nella nostra esperienza, la caratteristica comune tra i progetti di "marcia della morte" è basso valore atteso. Sono progetti finalizzati a mettere fuori i prodotti di insignificanza monumentale. L'unica vera giustificazione per la marcia della morte è che con un valore così minuscolo, fare il progetto a costo normale sarebbe chiaramente comporterebbe costi che sono maggiori di benefici ... se il progetto è così essenziale, perché non può la società di trascorrere la tempo e denaro per farlo correttamente? "

Approfondimenti

Peopleware [DeMarco e Lister 1999] è un classico lavoro sulla motivazione del programmatore e la produttività. Dovrebbe essere in cima alla lista di lettura di ogni responsabile sviluppo software.
Sviluppo rapido [McConnell 1996] ha un capitolo su "Motivation" con un bel grafico di confronto motivazioni programmatore alle motivazioni dei dirigenti e la popolazione in generale.
Slack [DeMarco 2002] esamina gli effetti di straordinario estesa e troppi impegni.
Death March [Yourdon] descrive come sopravvivere ad un progetto di "marcia della morte".

mercoledì 2 aprile 2014

Principi di Continuous Delivery ( automatizzare i rilasci )

8 Principi di Continuous Delivery
1) Il processo per il rilascio / distribuzione del software DEVE essere ripetibile e affidabile . Questo porta al 2 ° principio ...

2) Automatizzare tutto! Una distribuzione manuale può mai essere descritta come ripetibile e affidabile (non se lo sto facendo!). Bisogna investire seriamente automatizzando tutte le mansioni che fate ripetitivamente, e questo tende ad accrescere la affidabilità.

3) Se qualcosa è difficile o faticosa, falla più spesso. Superficialmente questo suona stupido, ma in fondo questo significa che facendo qualcosa di difficoltoso, più spesso, vi porterà a migliorare, probabilmente automatizzando, e questo finirà per renderlo indolore e facile. Prendiamo ad esempio fare una distribuzione di uno schema di database. Se questo è difficile, si tende a non farlo molto spesso, ad evitarlo, facendolo forse una volta al mese. In realtà ciò che si dovrebbe fare è migliorare il processo di distribuzione delle implementazioni dello schema, diventando bravi a farlo, e farlo più spesso, ripetendolo anche una volta al giorno se necessario. Se fai qualcosa ogni giorno, troverai il modo di renderla migliore rispetto piuttosto che la si fa una volta al mese.

4) Tenere tutto codice sorgente versionato e sotto controllo - questo suona come un po strano oggi, ma parlo seriamente, chi tiene tutto il codice sorgente versionato? A quanto pare poche persone. Lo sapevate?

5) "Fatto" significa "Rilasciato". Ciò obbliga a lavorare su di un progetto fino a quando non è nelle mani degli utenti, e funziona correttamente. Non c'è, quindi, niente del tipo: "ho controllato nel mio codice quindi è fatto per quanto mi riguarda". Ho avuto la fortuna di lavorare con alcune squadre di software che con entusiasmo si assicuravano che le loro modifiche al codice stavano funzionando correttamente fino al momento in cui i loro cambiamenti erano in produzione, controllando, anche, il sistema live per assicurarsi che i loro cambiamenti erano avvenuti con successo. D'altra parte ho lavorato con squadre in cui la loro responsabilità finiva dopo aver controllato il loro codice per il VCS.

6) Costruire qualità! Prendete il tempo ed investite nelle metriche di qualità. Un progetto con buone metriche di qualità mirate (potremmo parlare di copertura di unit test, di code styling, di violazione delle regole, misure di complessità - o, preferibilmente, di tutto ) sarà sempre meglio di uno senza, e più facile da mantenere nel lungo termine.

7) Ognuno ha la responsabilità del il processo di rilascio. Un programma in esecuzione su un computer portatile di uno sviluppatore non sta andando a fare i soldi per la società. Allo stesso modo, un progetto senza un piano per la distribuzione non sarà mai pubblicato, e quindi non fa fare soldi. Le aziende fanno i soldi, da sempre, solo con prodotti rilasciati ai clienti, quindi, questo processo dovrebbe essere nell'interesse di tutti. Gli sviluppatori dovrebbero sviluppare progetti tenendo a mente come distribuirli. I project manager devono pianificare progetti con attenzione alla distribuzione. Tester dovrebbero verificare i difetti di distribuzione con la stessa cura e attenzione che impiegano per i bug del codice (e questo dovrebbe essere automatizzato e integrato nella attività di distribuzione stesso).

8) Migliorare continuamente. Non sedersi e aspettare che il sistema diventi obsoleto o impossibile da mantenere. Miglioramento continuo significa che il sistema sarà sempre in evoluzione e quindi più facile da cambiare quando ce ne sarà bisogno.

 Per usare al meglio questi principi
ci sono anche: 4 Best Practise di Continuos Delivery

 1) Compilare i binari solo una volta. Rimarreste attontiti per il numero di volte che ho visto gente ricompilare il codice tra un ambiente e l'altro. I binari devono essere compilati una sola volta e una sola volta. Il binario deve quindi essere conservato in un posto che è accessibile solo per il meccanismo di distribuzione e il meccanismo di distribuzione dovrebbe schierare lo stesso binario per ogni ambiente successivo ...

 2) Utilizzare esattamente lo stesso meccanismo per distribuire in ogni ambiente.
Sembra ovvio, ma ho visto sinceramente casi in cui sono state automatizzate le distribuzioni di Test e solo per le distribuzioni di produzione applicare procedure manuali. Ho visto anche casi in cui sono stati entrambi automatizzati, distribuzioni di Test e di produzione, ma in due lingue completamente diverse. Questo è ovviamente un lavoro da pazzi.

 3) Smoke test di rilascio. E' necessario non lasciare al caso che il rilascio sia un successo strepitoso, scrivere un test di funzioni base (smoke test) e includerli nel processo di distribuzione. Mi piace anche includere un semplice test diagnostico, tutto quello che è possibile fare per controllare va fatto e tracciato - si confronta un elenco di file e quello che ci si aspetta è di vedere la vostra distribuzione in quello che realmente finisce sul server. Io lo chiamo un test di diagnostica perché è un buon primo porto di scalo quando c'è un problema.

 4) Se qualcosa va storto, ferma la linea! Butta via e ricomincia da capo il processo, non modificare, non fare hack. Se si verifica un problema, non importa dove, scarta la distribuzione (cioè fai rollback), risolvi il problema correttamente, controllare nella versione del codice sorgente e ripeti il processo di distribuzione. Un sacco di gente dice che questo è impossibile, soprattutto se hai una finestra di interruzione per distribuire le cose nel vostro sistema live limitata, o se le modifiche di produzione finiscono nel bel mezzo della notte, mentre nessun altro è in giro per fixare adeguatamente la issue. Direi, invece, che questi argomenti colgono il punto. In primo luogo, se si dispone solo di una piccola finestra di interruzione, hacking del sistema live dovrebbe essere l'ultima cosa che vorrei fare, perché questo farà decadere tutti gli altri ambienti a meno di hackerare similmente tutti gli ambienti. In secondo luogo, la prossima volta che fate un rilascio, si può riprodurre il problema originale. In terzo luogo, se si sta facendo il rilascio nel bel mezzo della notte con nessuno intorno per risolvere i problemi, allora non stai prestando sufficiente attenzione al 7 ° principio di Continuos Delivery - Ognuno ha la responsabilità per il processo di rilascio. Almeno che non sia indispensabile, non mi consiglia di fare rilasci quando c'è la minima quantità di supporto disponibile e di personale, va semplicemente contro il buonsenso.