Software Development Pearls
portes grátis
Software Development Pearls
Lessons from Fifty Years of Software Experience
Wiegers, Karl
Pearson Education (US)
10/2021
336
Mole
Inglês
9780137487776
15 a 20 dias
540
Descrição não disponível.
Foreword xix
Acknowledgments xxi
About the Author xxiii
Chapter 1: Learning from Painful Experience 1
My Perspective 1
About the Book 2
A Note on Terminology 4
Your Opportunity 5
Chapter 2: Lessons About Requirements 7
Introduction to Requirements 7
First Steps: Requirements 11
Lesson 1: Get the requirements right or the project will fail 12
Lesson 2: Requirements development delivers shared understanding 15
Lesson 3: Stakeholder interests intersect at the requirements 17
Lesson 4: Favor a usage-centric approach to requirements 21
Lesson 5: Requirements development demands iteration 25
Lesson 6: Agile requirements aren't different from other requirements 28
Lesson 7: Recording knowledge is cheaper than acquiring it 33
Lesson 8: Requirements are about clear communication 37
Lesson 9: Requirements quality is in the eye of the beholder 41
Lesson 10: Requirements must be good enough to reduce risk 44
Lesson 11: People don't simply gather requirements 46
Lesson 12: Elicitation brings the customer's voice to the developer 51
Lesson 13: Telepathy and clairvoyance don't work 55
Lesson 14: Large groups have difficulty agreeing on requirements 57
Lesson 15: Avoid decibel prioritization 61
Lesson 16: Define scope to know whether your scope is creeping 64
Next Steps: Requirements 69
Chapter 3: Lessons About Design 71
Introduction to Design 71
First Steps: Design 75
Lesson 17: Design demands iteration 76
Lesson 18: It's cheaper to iterate at higher levels of abstraction 79
Lesson 19: Make products easy to use correctly, hard to use incorrectly 84
Lesson 20: You can't optimize all desirable quality attributes 87
Lesson 21: An ounce of design is worth a pound of recoding 92
Lesson 22: Many system problems take place at interfaces 94
Next Steps: Design 100
Chapter 4: Lessons About Project Management 103
Introduction to Project Management 103
First Steps: Project Management 108
Lesson 23: Work plans must account for friction 109
Lesson 24: Don't give anyone an estimate off the top of your head 114
Lesson 25: Icebergs are always larger than they first appear 116
Lesson 26: Data strengthens your negotiating position 121
Lesson 27: Use historical data to improve estimates 124
Lesson 28: Don't change an estimate just to make someone happy 127
Lesson 29: Stay off the critical path 129
Lesson 30: Incomplete tasks get no partial credit 132
Lesson 31: A project team needs flexibility to adapt to change 136
Lesson 32: Uncontrolled project risks will control you 140
Lesson 33: The customer is not always right 145
Lesson 34: We do too much pretending in software 149
Next Steps: Project Management 151
Chapter 5: Lessons About Culture and Teamwork 153
Introduction to Culture and Teamwork 153
First Steps: Culture and Teamwork 158
Lesson 35: Knowledge is not zero-sum 159
Lesson 36: Don't make commitments you know you can't fulfill 163
Lesson 37: Higher productivity requires training and better practices 166
Lesson 38: The flip side of every right is a responsibility 171
Lesson 39: Surprisingly little separation can inhibit communication 173
Lesson 40: Small-team approaches don't scale to large projects 177
Lesson 41: Address culture change during a change initiative 180
Lesson 42: Engineering techniques don't work with unreasonable people 185
Next Steps: Culture and Teamwork 187
Chapter 6: Lessons About Quality 189
Introduction to Quality 189
First Steps: Quality 194
Lesson 43: Pay for quality now or pay more later 195
Lesson 44: High quality naturally leads to higher productivity 200
Lesson 45: Organizations somehow find time to fix bad software 205
Lesson 46: Beware the crap gap 207
Lesson 47: Never let anyone talk you into doing a bad job 209
Lesson 48: Strive to have peers find defects 213
Lesson 49: A fool with a tool is an amplified fool 217
Lesson 50: Rushed development leads to maintenance nightmares 221
Next Steps: Quality 224
Chapter 7: Lessons About Process Improvement 225
Introduction to Process Improvement 225
First Steps: Software Process Improvement 228
Lesson 51: Watch out for "Management by Businessweek" 229
Lesson 52: Ask not, "What's in it for me?" Ask, "What's in it for us?" 233
Lesson 53: The best motivation for changing how people work is pain 236
Lesson 54: Steer change with gentle pressure, relentlessly applied 238
Lesson 55: Don't make all the mistakes other people already have 241
Lesson 56: Good judgment and experience can trump a process 244
Lesson 57: Shrink templates to fit your project 247
Lesson 58: Learn and improve so the next project goes better 252
Lesson 59: Don't do ineffective things repeatedly 256
Next Steps: Software Process Improvement 259
Chapter 8: What to Do Next 261
Lesson 60: You can't change everything at once 262
Action Planning 266
Your Own Lessons 267
Appendix: Summary of Lessons 269
References 273
Index 285
Acknowledgments xxi
About the Author xxiii
Chapter 1: Learning from Painful Experience 1
My Perspective 1
About the Book 2
A Note on Terminology 4
Your Opportunity 5
Chapter 2: Lessons About Requirements 7
Introduction to Requirements 7
First Steps: Requirements 11
Lesson 1: Get the requirements right or the project will fail 12
Lesson 2: Requirements development delivers shared understanding 15
Lesson 3: Stakeholder interests intersect at the requirements 17
Lesson 4: Favor a usage-centric approach to requirements 21
Lesson 5: Requirements development demands iteration 25
Lesson 6: Agile requirements aren't different from other requirements 28
Lesson 7: Recording knowledge is cheaper than acquiring it 33
Lesson 8: Requirements are about clear communication 37
Lesson 9: Requirements quality is in the eye of the beholder 41
Lesson 10: Requirements must be good enough to reduce risk 44
Lesson 11: People don't simply gather requirements 46
Lesson 12: Elicitation brings the customer's voice to the developer 51
Lesson 13: Telepathy and clairvoyance don't work 55
Lesson 14: Large groups have difficulty agreeing on requirements 57
Lesson 15: Avoid decibel prioritization 61
Lesson 16: Define scope to know whether your scope is creeping 64
Next Steps: Requirements 69
Chapter 3: Lessons About Design 71
Introduction to Design 71
First Steps: Design 75
Lesson 17: Design demands iteration 76
Lesson 18: It's cheaper to iterate at higher levels of abstraction 79
Lesson 19: Make products easy to use correctly, hard to use incorrectly 84
Lesson 20: You can't optimize all desirable quality attributes 87
Lesson 21: An ounce of design is worth a pound of recoding 92
Lesson 22: Many system problems take place at interfaces 94
Next Steps: Design 100
Chapter 4: Lessons About Project Management 103
Introduction to Project Management 103
First Steps: Project Management 108
Lesson 23: Work plans must account for friction 109
Lesson 24: Don't give anyone an estimate off the top of your head 114
Lesson 25: Icebergs are always larger than they first appear 116
Lesson 26: Data strengthens your negotiating position 121
Lesson 27: Use historical data to improve estimates 124
Lesson 28: Don't change an estimate just to make someone happy 127
Lesson 29: Stay off the critical path 129
Lesson 30: Incomplete tasks get no partial credit 132
Lesson 31: A project team needs flexibility to adapt to change 136
Lesson 32: Uncontrolled project risks will control you 140
Lesson 33: The customer is not always right 145
Lesson 34: We do too much pretending in software 149
Next Steps: Project Management 151
Chapter 5: Lessons About Culture and Teamwork 153
Introduction to Culture and Teamwork 153
First Steps: Culture and Teamwork 158
Lesson 35: Knowledge is not zero-sum 159
Lesson 36: Don't make commitments you know you can't fulfill 163
Lesson 37: Higher productivity requires training and better practices 166
Lesson 38: The flip side of every right is a responsibility 171
Lesson 39: Surprisingly little separation can inhibit communication 173
Lesson 40: Small-team approaches don't scale to large projects 177
Lesson 41: Address culture change during a change initiative 180
Lesson 42: Engineering techniques don't work with unreasonable people 185
Next Steps: Culture and Teamwork 187
Chapter 6: Lessons About Quality 189
Introduction to Quality 189
First Steps: Quality 194
Lesson 43: Pay for quality now or pay more later 195
Lesson 44: High quality naturally leads to higher productivity 200
Lesson 45: Organizations somehow find time to fix bad software 205
Lesson 46: Beware the crap gap 207
Lesson 47: Never let anyone talk you into doing a bad job 209
Lesson 48: Strive to have peers find defects 213
Lesson 49: A fool with a tool is an amplified fool 217
Lesson 50: Rushed development leads to maintenance nightmares 221
Next Steps: Quality 224
Chapter 7: Lessons About Process Improvement 225
Introduction to Process Improvement 225
First Steps: Software Process Improvement 228
Lesson 51: Watch out for "Management by Businessweek" 229
Lesson 52: Ask not, "What's in it for me?" Ask, "What's in it for us?" 233
Lesson 53: The best motivation for changing how people work is pain 236
Lesson 54: Steer change with gentle pressure, relentlessly applied 238
Lesson 55: Don't make all the mistakes other people already have 241
Lesson 56: Good judgment and experience can trump a process 244
Lesson 57: Shrink templates to fit your project 247
Lesson 58: Learn and improve so the next project goes better 252
Lesson 59: Don't do ineffective things repeatedly 256
Next Steps: Software Process Improvement 259
Chapter 8: What to Do Next 261
Lesson 60: You can't change everything at once 262
Action Planning 266
Your Own Lessons 267
Appendix: Summary of Lessons 269
References 273
Index 285
Este título pertence ao(s) assunto(s) indicados(s). Para ver outros títulos clique no assunto desejado.
software development lessons; software engineering best practices; software project management; software process improvement; software quality; software + teamwork; software requirements; software product management; software design best practices; software development culture; better software development
Foreword xix
Acknowledgments xxi
About the Author xxiii
Chapter 1: Learning from Painful Experience 1
My Perspective 1
About the Book 2
A Note on Terminology 4
Your Opportunity 5
Chapter 2: Lessons About Requirements 7
Introduction to Requirements 7
First Steps: Requirements 11
Lesson 1: Get the requirements right or the project will fail 12
Lesson 2: Requirements development delivers shared understanding 15
Lesson 3: Stakeholder interests intersect at the requirements 17
Lesson 4: Favor a usage-centric approach to requirements 21
Lesson 5: Requirements development demands iteration 25
Lesson 6: Agile requirements aren't different from other requirements 28
Lesson 7: Recording knowledge is cheaper than acquiring it 33
Lesson 8: Requirements are about clear communication 37
Lesson 9: Requirements quality is in the eye of the beholder 41
Lesson 10: Requirements must be good enough to reduce risk 44
Lesson 11: People don't simply gather requirements 46
Lesson 12: Elicitation brings the customer's voice to the developer 51
Lesson 13: Telepathy and clairvoyance don't work 55
Lesson 14: Large groups have difficulty agreeing on requirements 57
Lesson 15: Avoid decibel prioritization 61
Lesson 16: Define scope to know whether your scope is creeping 64
Next Steps: Requirements 69
Chapter 3: Lessons About Design 71
Introduction to Design 71
First Steps: Design 75
Lesson 17: Design demands iteration 76
Lesson 18: It's cheaper to iterate at higher levels of abstraction 79
Lesson 19: Make products easy to use correctly, hard to use incorrectly 84
Lesson 20: You can't optimize all desirable quality attributes 87
Lesson 21: An ounce of design is worth a pound of recoding 92
Lesson 22: Many system problems take place at interfaces 94
Next Steps: Design 100
Chapter 4: Lessons About Project Management 103
Introduction to Project Management 103
First Steps: Project Management 108
Lesson 23: Work plans must account for friction 109
Lesson 24: Don't give anyone an estimate off the top of your head 114
Lesson 25: Icebergs are always larger than they first appear 116
Lesson 26: Data strengthens your negotiating position 121
Lesson 27: Use historical data to improve estimates 124
Lesson 28: Don't change an estimate just to make someone happy 127
Lesson 29: Stay off the critical path 129
Lesson 30: Incomplete tasks get no partial credit 132
Lesson 31: A project team needs flexibility to adapt to change 136
Lesson 32: Uncontrolled project risks will control you 140
Lesson 33: The customer is not always right 145
Lesson 34: We do too much pretending in software 149
Next Steps: Project Management 151
Chapter 5: Lessons About Culture and Teamwork 153
Introduction to Culture and Teamwork 153
First Steps: Culture and Teamwork 158
Lesson 35: Knowledge is not zero-sum 159
Lesson 36: Don't make commitments you know you can't fulfill 163
Lesson 37: Higher productivity requires training and better practices 166
Lesson 38: The flip side of every right is a responsibility 171
Lesson 39: Surprisingly little separation can inhibit communication 173
Lesson 40: Small-team approaches don't scale to large projects 177
Lesson 41: Address culture change during a change initiative 180
Lesson 42: Engineering techniques don't work with unreasonable people 185
Next Steps: Culture and Teamwork 187
Chapter 6: Lessons About Quality 189
Introduction to Quality 189
First Steps: Quality 194
Lesson 43: Pay for quality now or pay more later 195
Lesson 44: High quality naturally leads to higher productivity 200
Lesson 45: Organizations somehow find time to fix bad software 205
Lesson 46: Beware the crap gap 207
Lesson 47: Never let anyone talk you into doing a bad job 209
Lesson 48: Strive to have peers find defects 213
Lesson 49: A fool with a tool is an amplified fool 217
Lesson 50: Rushed development leads to maintenance nightmares 221
Next Steps: Quality 224
Chapter 7: Lessons About Process Improvement 225
Introduction to Process Improvement 225
First Steps: Software Process Improvement 228
Lesson 51: Watch out for "Management by Businessweek" 229
Lesson 52: Ask not, "What's in it for me?" Ask, "What's in it for us?" 233
Lesson 53: The best motivation for changing how people work is pain 236
Lesson 54: Steer change with gentle pressure, relentlessly applied 238
Lesson 55: Don't make all the mistakes other people already have 241
Lesson 56: Good judgment and experience can trump a process 244
Lesson 57: Shrink templates to fit your project 247
Lesson 58: Learn and improve so the next project goes better 252
Lesson 59: Don't do ineffective things repeatedly 256
Next Steps: Software Process Improvement 259
Chapter 8: What to Do Next 261
Lesson 60: You can't change everything at once 262
Action Planning 266
Your Own Lessons 267
Appendix: Summary of Lessons 269
References 273
Index 285
Acknowledgments xxi
About the Author xxiii
Chapter 1: Learning from Painful Experience 1
My Perspective 1
About the Book 2
A Note on Terminology 4
Your Opportunity 5
Chapter 2: Lessons About Requirements 7
Introduction to Requirements 7
First Steps: Requirements 11
Lesson 1: Get the requirements right or the project will fail 12
Lesson 2: Requirements development delivers shared understanding 15
Lesson 3: Stakeholder interests intersect at the requirements 17
Lesson 4: Favor a usage-centric approach to requirements 21
Lesson 5: Requirements development demands iteration 25
Lesson 6: Agile requirements aren't different from other requirements 28
Lesson 7: Recording knowledge is cheaper than acquiring it 33
Lesson 8: Requirements are about clear communication 37
Lesson 9: Requirements quality is in the eye of the beholder 41
Lesson 10: Requirements must be good enough to reduce risk 44
Lesson 11: People don't simply gather requirements 46
Lesson 12: Elicitation brings the customer's voice to the developer 51
Lesson 13: Telepathy and clairvoyance don't work 55
Lesson 14: Large groups have difficulty agreeing on requirements 57
Lesson 15: Avoid decibel prioritization 61
Lesson 16: Define scope to know whether your scope is creeping 64
Next Steps: Requirements 69
Chapter 3: Lessons About Design 71
Introduction to Design 71
First Steps: Design 75
Lesson 17: Design demands iteration 76
Lesson 18: It's cheaper to iterate at higher levels of abstraction 79
Lesson 19: Make products easy to use correctly, hard to use incorrectly 84
Lesson 20: You can't optimize all desirable quality attributes 87
Lesson 21: An ounce of design is worth a pound of recoding 92
Lesson 22: Many system problems take place at interfaces 94
Next Steps: Design 100
Chapter 4: Lessons About Project Management 103
Introduction to Project Management 103
First Steps: Project Management 108
Lesson 23: Work plans must account for friction 109
Lesson 24: Don't give anyone an estimate off the top of your head 114
Lesson 25: Icebergs are always larger than they first appear 116
Lesson 26: Data strengthens your negotiating position 121
Lesson 27: Use historical data to improve estimates 124
Lesson 28: Don't change an estimate just to make someone happy 127
Lesson 29: Stay off the critical path 129
Lesson 30: Incomplete tasks get no partial credit 132
Lesson 31: A project team needs flexibility to adapt to change 136
Lesson 32: Uncontrolled project risks will control you 140
Lesson 33: The customer is not always right 145
Lesson 34: We do too much pretending in software 149
Next Steps: Project Management 151
Chapter 5: Lessons About Culture and Teamwork 153
Introduction to Culture and Teamwork 153
First Steps: Culture and Teamwork 158
Lesson 35: Knowledge is not zero-sum 159
Lesson 36: Don't make commitments you know you can't fulfill 163
Lesson 37: Higher productivity requires training and better practices 166
Lesson 38: The flip side of every right is a responsibility 171
Lesson 39: Surprisingly little separation can inhibit communication 173
Lesson 40: Small-team approaches don't scale to large projects 177
Lesson 41: Address culture change during a change initiative 180
Lesson 42: Engineering techniques don't work with unreasonable people 185
Next Steps: Culture and Teamwork 187
Chapter 6: Lessons About Quality 189
Introduction to Quality 189
First Steps: Quality 194
Lesson 43: Pay for quality now or pay more later 195
Lesson 44: High quality naturally leads to higher productivity 200
Lesson 45: Organizations somehow find time to fix bad software 205
Lesson 46: Beware the crap gap 207
Lesson 47: Never let anyone talk you into doing a bad job 209
Lesson 48: Strive to have peers find defects 213
Lesson 49: A fool with a tool is an amplified fool 217
Lesson 50: Rushed development leads to maintenance nightmares 221
Next Steps: Quality 224
Chapter 7: Lessons About Process Improvement 225
Introduction to Process Improvement 225
First Steps: Software Process Improvement 228
Lesson 51: Watch out for "Management by Businessweek" 229
Lesson 52: Ask not, "What's in it for me?" Ask, "What's in it for us?" 233
Lesson 53: The best motivation for changing how people work is pain 236
Lesson 54: Steer change with gentle pressure, relentlessly applied 238
Lesson 55: Don't make all the mistakes other people already have 241
Lesson 56: Good judgment and experience can trump a process 244
Lesson 57: Shrink templates to fit your project 247
Lesson 58: Learn and improve so the next project goes better 252
Lesson 59: Don't do ineffective things repeatedly 256
Next Steps: Software Process Improvement 259
Chapter 8: What to Do Next 261
Lesson 60: You can't change everything at once 262
Action Planning 266
Your Own Lessons 267
Appendix: Summary of Lessons 269
References 273
Index 285
Este título pertence ao(s) assunto(s) indicados(s). Para ver outros títulos clique no assunto desejado.
software development lessons; software engineering best practices; software project management; software process improvement; software quality; software + teamwork; software requirements; software product management; software design best practices; software development culture; better software development
