Software Development Pearls: Lessons from Fifty Years of Software Experience, 1st edition
BRAND: PEARSON
eBook edition. 1 Year Subscription. Dành cho Cá nhân | Trường ĐH, Nhóm, Thư Viện: Gọi 0915920514 để báo giá Pearson, Vital Source eBook hoặc mua Sách In
Tổng quan sách
Với hơn 20 năm giúp đỡ các nhóm phần mềm thành công trong gần 150 tổ chức, Karl Wiegers trình bày 60 bài học ngắn gọn và khuyến nghị thực tế mà sinh viên có thể áp dụng cho tất cả các loại dự án, bất kể miền ứng dụng, công nghệ, vòng đời phát triển hay cơ sở hạ tầng nền tảng.Thể hiện cả trí tuệ để hiểu sâu hơn và hướng dẫn sử dụng thực tế, cuốn sách này là sự bổ sung vô giá cho những kỹ thuật "chi tiết" mà các nhà phát triển phần mềm thường nghiên cứu.Ngọc trai phát triển phần mềm đề cập đến nhiều lĩnh vực quan trọng dẫn đến thành công của dự án: yêu cầu, thiết kế, quản lý dự án, văn hóa và làm việc nhóm, chất lượng và cải tiến quy trình. Mỗi chương gợi ý một số "bước đầu tiên" và "bước tiếp theo" để giúp bạn bắt đầu áp dụng ngay các bài học khó có được của tác giả—và viết mã thành công hơn về mọi mặt quan trọng.
- Foreword xixAcknowledgments xxiAbout the Author xxiii
- Chapter 1: Learning from Painful Experience 1My Perspective 1About the Book 2A Note on Terminology 4Your Opportunity 5
- Chapter 2: Lessons About Requirements 7Introduction to Requirements 7First Steps: Requirements 11Lesson 1: Get the requirements right or the project will fail 12Lesson 2: Requirements development delivers shared understanding 15Lesson 3: Stakeholder interests intersect at the requirements 17Lesson 4: Favor a usage-centric approach to requirements 21Lesson 5: Requirements development demands iteration 25Lesson 6: Agile requirements aren't different from other requirements 28Lesson 7: Recording knowledge is cheaper than acquiring it 33Lesson 8: Requirements are about clear communication 37Lesson 9: Requirements quality is in the eye of the beholder 41Lesson 10: Requirements must be good enough to reduce risk 44Lesson 11: People don't simply gather requirements 46Lesson 12: Elicitation brings the customer's voice to the developer 51Lesson 13: Telepathy and clairvoyance don't work 55Lesson 14: Large groups have difficulty agreeing on requirements 57Lesson 15: Avoid decibel prioritization 61Lesson 16: Define scope to know whether your scope is creeping 64Next Steps: Requirements 69
- Chapter 3: Lessons About Design 71Introduction to Design 71First Steps: Design 75Lesson 17: Design demands iteration 76Lesson 18: It's cheaper to iterate at higher levels of abstraction 79Lesson 19: Make products easy to use correctly, hard to use incorrectly 84Lesson 20: You can't optimize all desirable quality attributes 87Lesson 21: An ounce of design is worth a pound of recoding 92Lesson 22: Many system problems take place at interfaces 94Next Steps: Design 100
- Chapter 4: Lessons About Project Management 103Introduction to Project Management 103First Steps: Project Management 108Lesson 23: Work plans must account for friction 109Lesson 24: Don't give anyone an estimate off the top of your head 114Lesson 25: Icebergs are always larger than they first appear 116Lesson 26: Data strengthens your negotiating position 121Lesson 27: Use historical data to improve estimates 124Lesson 28: Don't change an estimate just to make someone happy 127Lesson 29: Stay off the critical path 129Lesson 30: Incomplete tasks get no partial credit 132Lesson 31: A project team needs flexibility to adapt to change 136Lesson 32: Uncontrolled project risks will control you 140Lesson 33: The customer is not always right 145Lesson 34: We do too much pretending in software 149Next Steps: Project Management 151
- Chapter 5: Lessons About Culture and Teamwork 153Introduction to Culture and Teamwork 153First Steps: Culture and Teamwork 158Lesson 35: Knowledge is not zero-sum 159Lesson 36: Don't make commitments you know you can't fulfill 163Lesson 37: Higher productivity requires training and better practices 166Lesson 38: The flip side of every right is a responsibility 171Lesson 39: Surprisingly little separation can inhibit communication 173Lesson 40: Small-team approaches don't scale to large projects 177Lesson 41: Address culture change during a change initiative 180Lesson 42: Engineering techniques don't work with unreasonable people 185Next Steps: Culture and Teamwork 187
- Chapter 6: Lessons About Quality 189Introduction to Quality 189First Steps: Quality 194Lesson 43: Pay for quality now or pay more later 195Lesson 44: High quality naturally leads to higher productivity 200Lesson 45: Organizations somehow find time to fix bad software 205Lesson 46: Beware the crap gap 207Lesson 47: Never let anyone talk you into doing a bad job 209Lesson 48: Strive to have peers find defects 213Lesson 49: A fool with a tool is an amplified fool 217Lesson 50: Rushed development leads to maintenance nightmares 221Next Steps: Quality 224
- Chapter 7: Lessons About Process Improvement 225Introduction to Process Improvement 225First Steps: Software Process Improvement 228Lesson 51: Watch out for "Management by Businessweek" 229Lesson 52: Ask not, "What's in it for me?" Ask, "What's in it for us?" 233Lesson 53: The best motivation for changing how people work is pain 236Lesson 54: Steer change with gentle pressure, relentlessly applied 238Lesson 55: Don't make all the mistakes other people already have 241Lesson 56: Good judgment and experience can trump a process 244Lesson 57: Shrink templates to fit your project 247Lesson 58: Learn and improve so the next project goes better 252Lesson 59: Don't do ineffective things repeatedly 256Next Steps: Software Process Improvement 259
- Chapter 8: What to Do Next 261Lesson 60: You can't change everything at once 262Action Planning 266Your Own Lessons 267Appendix: Summary of Lessons 269References 273Index 285
.svg)