| 0.09 | | Prefazione |
| 0.13 | | Introduzione |
| 0.15 | | Ringraziamenti |
| | | {titolo} |
| 1 | Capitolo 1. | Introduzione ad Agile |
| 2 | | La storia di Agile |
| 8 | | Snowbird |
| 10 | | Dopo Snowbird |
| 10 | | Panoramica su Agile |
| 11 | | Iron Cross |
| 11 | | Grafici sulla parete |
| 13 | | La prima cosa da sapere |
| 13 | | Il meeting |
| 14 | | La fase di analisi |
| 14 | | La fase di progettazione |
| 15 | | La fase di implementazione |
| 16 | | La fase della “marcia funebre |
| 16 | | Iperbole? |
| 16 | | Un modo migliore |
| 17 | | Iterazione zero |
| 18 | | Agile produce dati |
| 19 | | Fideismo contro gestione |
| 20 | | Gestire la Iron Cross |
| 22 | | L’ordine dei valori |
| 22 | | Qui termina la panoramica |
| 22 | | Il “Cerchio della vita” |
| 24 | | Conclusioni |
| 25 | Capitolo 2. | Le motivazioni di Agile |
| 26 | | Professionalità |
| 26 | | Il software è ovunque |
| 28 | | Controlliamo il mondo |
| 29 | | Il disastro |
| 29 | | Ragionevoli aspettative |
| 30 | | Non consegneremo mai “merda”! |
| 31 | | Prontezza tecnica continua |
| 31 | | Produttività stabile |
| 33 | | Adattabilità economica |
| 34 | | Miglioramento continuo |
| 34 | | Competenza senza paura |
| 35 | | La QA non dovrebbe trovare nulla |
| 35 | | Automazione dei test |
| 36 | | Ci “copriamo” l’un l’altro |
| 37 | | Stime oneste |
| 37 | | Occorre anche dire “No” |
| 38 | | Apprendimento continuo e aggressivo |
| 38 | | Condividere le conoscenze |
| 38 | | La Carta dei diritti |
| 38 | | Carta dei diritti del cliente |
| 38 | | Carta dei diritti dello sviluppatore |
| 39 | | Clienti |
| 40 | | Sviluppatori |
| 42 | | Conclusioni |
| 43 | Capitolo 3. | Pratiche rivolte all’azienda |
| 44 | | Pianificazione |
| 44 | | Analisi trivariata |
| 45 | | Storie e punti |
| 46 | | Storie per uno sportello automatico |
| 50 | | User story |
| 51 | | Stima delle storie |
| 53 | | Gestione dell’iterazione |
| 54 | | La demo |
| 54 | | Velocità |
| 56 | | Piccole release |
| 56 | | Una breve storia del controllo del codice sorgente |
| 57 | | Nastri magnetici |
| 58 | | Dischi e SCCS |
| 58 | | Subversion |
| 59 | | Git e i test |
| 59 | | Test di accettazione |
| 60 | | Strumenti e metodologie |
| 61 | | Behavior-Driven Development |
| 61 | | La pratica |
| 63 | | Intero team |
| 64 | | Co-locazione |
| 65 | | Conclusioni |
| 67 | Capitolo 4. | Pratiche rivolte al team |
| 68 | | Metafora |
| 69 | | Domain-Driven Design |
| 70 | | Passo sostenibile |
| 70 | | Straordinari |
| 71 | | Maratona |
| 71 | | Impegno |
| 72 | | Sonno |
| 72 | | Proprietà collettiva |
| 73 | | The X-Files |
| 74 | | Integrazione continua |
| 75 | | Poi vennero le build continue |
| 75 | | La disciplina delle build continue |
| 76 | | Standup meeting |
| 76 | | Parliamo di maiali e polli? |
| 77 | | Ringraziamenti |
| 77 | | Conclusioni |
| 79 | Capitolo 5. | Pratiche di natura tecnica |
| 80 | | Test-Driven Development |
| 80 | | Partita doppia |
| 81 | | Le tre regole del Test-Driven Development |
| 82 | | Debugging |
| 82 | | Documentazione |
| 83 | | Divertimento |
| 83 | | Completezza |
| 84 | | Progettazione |
| 85 | | Coraggio |
| 86 | | Refactoring |
| 86 | | Rosso/Verde/Refactoring |
| 87 | | Grandi rifattorizzazioni |
| 88 | | Simple Design |
| 88 | | Il “peso” di un progetto |
| 89 | | Pair Programming |
| 89 | | Che cosa significa “lavorare a coppie”? |
| 90 | | Perché proprio a coppie? |
| 90 | | In coppia per la revisione del codice |
| 90 | | E i costi? |
| 91 | | Solo due? |
| 91 | | Il management |
| 91 | | Conclusioni |
| 93 | Capitolo 6. | Diventare Agile |
| 94 | | Valori Agile |
| 94 | | Coraggio |
| 94 | | Comunicazione |
| 94 | | Feedback |
| 95 | | Semplicità |
| 95 | | Rigidità |
| 96 | | Trasformazione |
| 96 | | Il sotterfugio |
| 97 | | I cuccioli di leone |
| 97 | | Lacrime |
| 97 | | La morale |
| 97 | | Finzione |
| 98 | | Il successo nelle piccole organizzazioni |
| 98 | | Successo individuale e migrazione |
| 98 | | Creare organizzazioni Agile |
| 99 | | Coaching |
| 100 | | Scrum Master |
| 100 | | Certificazione |
| 100 | | Una vera certificazione |
| 100 | | Essere Agile “in grande” |
| 103 | | Strumenti Agile |
| 103 | | Strumenti software |
| 104 | | Che cosa rende efficace uno strumento? |
| 105 | | Strumenti fisici di Agile |
| 105 | | La pressione verso l’automazione |
| 106 | | Sistemi ALM: buoni, ma non per tutti |
| 108 | | Coaching: una visione alternativa |
| 108 | | I molti percorsi verso Agile |
| 109 | | Da esperto di processi a esperto di Agile |
| 109 | | La necessità di un coaching per Agile |
| 110 | | Peculiarità del coaching Agile |
| 110 | | Oltre ICP- ACC |
| 110 | | Strumenti di coaching |
| 111 | | Le competenze di coaching professionale non bastano |
| 111 | | Coaching in un ambiente multi-team |
| 112 | | Agile “in grande” |
| 112 | | Usare Agile e il coaching per diventare Agile |
| 113 | | Far crescere l’adozione Agile |
| 114 | | Puntare al grande, concentrandosi sul piccolo |
| 115 | | Il futuro del coaching Agile |
| 115 | | Conclusioni (di nuovo Bob) |
| 117 | Capitolo 7. | Artigianalità |
| 118 | | La sbornia da Agile |
| 120 | | Errate aspettative |
| 121 | | Come procedere |
| 121 | | Software Craftmanship |
| 122 | | Ideologia contro metodologia |
| 123 | | Software Craftmanship prevede delle pratiche? |
| 124 | | Concentrarsi sul valore, non sulla pratica |
| 124 | | Discutere delle pratiche |
| 124 | | L’impatto di Craftmanship sulle persone |
| 125 | | L’impatto di Craftmanship sul nostro settore |
| 126 | | L’impatto di Craftmanship sulle aziende |
| 127 | | Craftmanship e Agile |
| 128 | | Conclusioni |
| 129 | | Conclusioni |
| 131 | | Postfazione |
| 135 | | Indice analitico |
Domain-Driven Design []
(2 opere)