- Cover Page
- Title Page
- Contents
- Table of Contents
- Foreword
- Acknowledgments
- About the Author
- Chapter 1. Learning from Painful Experience
- Chapter 2. Lessons About Requirements
- First Steps: Requirements
- Lesson #1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.
- Lesson #2. The key deliverables from requirements development are a shared vision and understanding.
- Lesson #3. Nowhere more than in the requirements do the interests of all the project stakeholders intersect.
- Lesson #4. A usage-centric approach to requirements will meet customer needs better than a feature-centric approach.
- Lesson #5. Requirements development demands iteration.
- Lesson #6. Agile requirements aren’t different from other requirements.
- Lesson #7. The cost of recording knowledge is small compared to the cost of acquiring knowledge.
- Lesson #8. The overarching objective of requirements development is clear and effective communication.
- Lesson #9. Requirements quality is in the eye of the beholder.
- Lesson #10. Requirements must be good enough to let construction proceed at an acceptable level of risk.
- Lesson #11. People don’t simply gather requirements.
- Lesson #12. Requirements elicitation must bring the customer’s voice close to the developer’s ear.
- Lesson #13. Two commonly used requirements elicitation practices are telepathy and clairvoyance. They don’t work.
- Lesson #14. A large group of people can’t agree to leave a burning room, let alone agree on exactly how to word some requirement.
- Lesson #15. Avoid decibel prioritization when deciding which features to include.
- Lesson #16. Without a documented and agreed-to project scope, how do you know whether your scope is creeping?
- Next Steps: Requirements
- Chapter 3. Lessons About Design
- First Steps: Design
- Lesson #17. Design demands iteration.
- Lesson #18. It’s cheaper to iterate at higher levels of abstraction.
- Lesson #19. Make products easy to use correctly and hard to use incorrectly.
- Lesson #20. You can’t optimize all desirable quality attributes.
- Lesson #21. An ounce of design is worth a pound of recoding.
- Lesson #22. Many system problems take place at interfaces.
- Chapter 4. Lessons About Project Management
- First Steps: Project Management
- Lesson #23. Work plans must account for friction.
- Lesson #24. Don’t give anyone an estimate off the top of your head.
- Lesson #25. Icebergs are always larger than they first appear.
- Lesson #26. You’re in a stronger negotiating position when you have data to build your case.
- Lesson #27. Unless you record estimates and compare them to what actually happened, you’ll forever be guessing, not estimating.
- Lesson #28. Don’t change an estimate based on what the recipient wants to hear.
- Lesson #29. Stay off the critical path.
- Lesson #30. A task is either entirely done or it is not done: no partial credit.
- Lesson #31. The project team needs flexibility around at least one of the five dimensions of scope, schedule, budget, staff, and quality.
- Lesson #32. If you don’t control your project’s risks, they will control you.
- Lesson #33. The customer is not always right.
- Lesson #34. We do too much pretending in software.
- Next Steps: Project Management
- Chapter 5. Lessons About Culture and Teamwork
- First Steps: Culture and Teamwork
- Lesson #35. Knowledge is not zero-sum.
- Lesson #36. No matter how much pressure others exert, never make a commitment you know you can’t fulfill.
- Lesson #37. Without training and better practices, don’t expect higher productivity to happen by magic.
- Lesson #38. People talk a lot about their rights, but the flip side of every right is a responsibility.
- Lesson #39. It takes little physical separation to inhibit communication and collaboration.
- Lesson #40. Informal approaches that work for a small colocated team don’t scale up well.
- Lesson #41. Don’t underestimate the challenge of changing an organization’s culture as it moves toward new ways of working.
- Lesson #42. No engineering or management technique will work if you’re dealing with unreasonable people.
- Next Steps: Culture and Teamwork
- Chapter 6. Lessons About Quality
- First Steps: Quality
- Lesson #43. When it comes to software quality, you can pay now or pay more later.
- Lesson #44. High quality naturally leads to higher productivity.
- Lesson #45. Organizations never have time to build software right, yet they find the resources to fix it later.
- Lesson #46. Beware the crap gap.
- Lesson #47. Never let your boss or your customer talk you into doing a bad job.
- Lesson #48. Strive to have a peer, rather than a customer, find a defect.
- Lesson #49. Software people love tools, but a fool with a tool is an amplified fool.
- Lesson #50. Today’s “gotta get it out right away” development project is tomorrow’s maintenance nightmare.
- Next Steps: Quality
- Chapter 7. Lessons About Process Improvement
- First Steps: Software Process Improvement
- Lesson #51. Watch out for “Management by Businessweek.”
- Lesson #52. Ask not, “What’s in it for me?” Ask, “What’s in it for us?”
- Lesson #53. The best motivation for changing how people work is pain.
- Lesson #54. When steering an organization toward new ways of working, use gentle pressure, relentlessly applied.
- Lesson #55. You don’t have time to make each mistake that every practitioner before you has already made.
- Lesson #56. Good judgment and experience sometimes trump a defined process.
- Lesson #57. Adopt a shrink-to-fit philosophy with document templates.
- Lesson #58. Unless you take the time to learn and improve, don’t expect the next project to go any better than the last one.
- Lesson #59. The most conspicuous repeatability the software industry has achieved is doing the same ineffective things over and over.
- Next Steps: Software Process Improvement
- Chapter 8. What To Do Next
- Appendix. Summary of Lessons
- References
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.