More on this book
Community
Kindle Notes & Highlights
Good requirements documents remain abstract. Where requirements are concerned, the simplest statement that accurately reflects the business need is best.
The key to managing growth of requirements is to point out each new feature's impact on the schedule to the project sponsors.
by tracking requirements you can get a clearer picture that "just one more feature" is really the fifteenth new feature added this month.
Use a Project Glossary It's very hard to succeed on a project where the users and developers refer to the same thing by different names or, even worse, refer to different things by the same name.
we want to identify the most restrictive constraints first, and fit the remaining constraints
Is there an easier way? Are you trying to solve the right problem, or have you been distracted by a peripheral technicality? Why is this thing a problem? What is it that's making it so hard to solve? Does it have to be done this way? Does it have to be done at all?
Distrust environments where requirements are gathered, specifications are written, and then coding starts, all in isolation. Instead, try to adopt a seamless approach: specification and implementation are simply different aspects of the same process—an attempt to capture and codify a requirement. Each should flow directly into the next, with no artificial boundaries.
Pragmatic Programmers look at methodologies critically, then extract the best from each and meld them into a set of working practices that gets better each month.
The single most important factor in making project-level activities work consistently and reliably is to automate your procedures.
The only thing that developers dislike more than testing is documentation.
The team must take responsibility for the quality of the product, supporting developers who understand the no broken windows philosophy
Make sure everyone actively monitors the environment for changes.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software.
3. Provide Options, Don't Make Lame Excuses 3 Instead of excuses, provide options. Don't say it can't be done; explain what can be done.
