Drawing on 20+ years helping software teams succeed in nearly 150 organizations, Karl Wiegers presents 60 concise lessons and practical recommendations students can apply to all kinds of projects, regardless of application domain, technology, development lifecycle, or platform infrastructure. Embodying both wisdom for deeper understanding and guidance for practical use, this book represent an invaluable complement to the technical 'nuts and bolts' software developers usually study. Software Development Pearls covers multiple crucial domains of project success: requirements, design, project…mehr
Drawing on 20+ years helping software teams succeed in nearly 150 organizations, Karl Wiegers presents 60 concise lessons and practical recommendations students can apply to all kinds of projects, regardless of application domain, technology, development lifecycle, or platform infrastructure. Embodying both wisdom for deeper understanding and guidance for practical use, this book represent an invaluable complement to the technical 'nuts and bolts' software developers usually study. Software Development Pearls covers multiple crucial domains of project success: requirements, design, project management, culture and teamwork, quality, and process improvement. Each chapter suggests several 'first steps' and 'next steps' to help you begin immediately applying the author's hard-won lessonsGÇöand writing code that is more successful in every way that matters.
Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Happy Valley, Oregon. Previously, he spent eighteen years at Kodak, where he held positions as a photographic research scientist, software developer, software manager, and software process and quality improvement leader. Karl received a PhD in organic chemistry from the University of Illinois. Karl is the author of twelve previous books and has written many articles on software development, management, design, consulting, chemistry, and military history. Karl has served on the editorial board for IEEE Software magazine and as a contributing editor for Software Development magazine.
Inhaltsangabe
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
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
Es gelten unsere Allgemeinen Geschäftsbedingungen: www.buecher.de/agb
Impressum
www.buecher.de ist ein Shop der buecher.de GmbH & Co. KG Bürgermeister-Wegele-Str. 12, 86167 Augsburg Amtsgericht Augsburg HRA 13309
