Topic 45 - 47

tags: The Pragmatic Programmer

Topic 45. The Requirements Pit 需求坑

Perfection is achieved, not when there is nothing left to add but when there is nothing left to take away…

這章節的工作內容看起來不是開發者．．．是ＵＩＵＸ跟ＰＭ

• requirements gathering(需求收集) :
  • Gathering implies that the requirements are already there.
  • Requirements are buried deep beneath layers of assumptions, misconceptions, and politics or they even don’t really exist at all.

No One Knows Exactly What They Want

Our job is to help people understand what they want.

Programmers Help People Understand What They Want

REQUIREMENTS ARE A PROCESS

• The typical client comes to us with a need.
• The mistake new developers often make is to take this statement of need and implement a solution for it.

this initial statement of need is not an absolute requirement.

Example : You work for a publisher of paper and electronic books. You’re given a new requirement:

• Shipping should be free on all orders costing $50 or more.
  • Does the $50 include tax?
  • Does the $50 include current shipping charges?
  • Does the $50 have to be for paper books, or can the order also include ebooks?
  • What kind of shipping is offered? Priority? Ground?
  • What about international orders?
  • How often will the $50 limit change in the future?

That’s what we do. When given something that seems simple, we annoy people by looking for edge cases and asking about them.

This is both an intellectual process and a creative one: you’re thinking on your feet and you’re contributing to a solution that is likely to be better than one that either you or the client would have produced alone.

Requirements Are Learned in a Feedback Loop

• Your job is to help the client understand the consequences of their stated requirements. You do that by generating feedback, and letting them use that feedback to refine their thinking.
• Pragmatic Programmers rely on the “is this what you meant?” school of feedback.

Work with a User to Think Like a User

• There’s a simple technique for getting inside your clients’ heads that isn’t used often enough: become a client.

DOCUMENTING REQUIREMENTS

The requirements document is written for developers.

• We believe that the best requirements documentation, perhaps the only requirements documentation, is working code.
• But that doesn’t mean that you can get away without documenting your understanding of what the client wants.
• Requirements Documents Are Not for Clients

Requirements Documents Are for Planning

• user stories : 以日常語言或商務用語撰寫句子，是一段簡單的功能表述。
• By keeping this statement of requirements short, you’re encouraging developers to ask clarifying questions.

OVERSPECIFICATION 過度指定規格

Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need.

• A big danger in producing a requirements document is being too specific. Good requirements are abstract.
• the simplest statement that accurately reflects the business need is best.

JUST ONE MORE WAFER-THIN MINT…

• Many project failures are blamed on an increase in scope—also known as feature bloat(功能膨脹), creeping featurism(特徵蔓延), or requirements creep(範圍蔓延). => Stone Soup and Boiled Frogs
• Q : prevent? The answer (again) is feedback.

Use a Project Glossary 專案術語表

• All participants in the project, from end users to support staff, should use the glossary to ensure consistency.

Topic 46. Solving Impossible Puzzles

Gordius, the King of Phrygia, once tied a knot that no one could untie. It was said that whoever solved the riddle of the Gordian Knot would rule all of Asia. So along comes Alexander the Great, who chops the knot to bits with his sword. Just a little different interpretation of the requirements, that’s all… And he did end up ruling most of Asia.

DEGREES OF FREEDOM

thinking outside the box – this phrase isn’t entirely accurate

• Q: Can you connect all of the dots in the following puzzle and return to the starting point with just three straight lines—without lifting your pen from the paper or retracing your steps?
  

It’s not whether you think inside the box or outside the box. The problem lies in finding the box—identifying the real constraints.

Don’t Think Outside the Box—Find the Box

• When faced with an intractable problem, enumerate all the possible avenues you have before you. Don’t dismiss anything, no matter how unusable or stupid it sounds.
• Categorize and prioritize your constraints.
• Sometimes you will find yourself working on a problem that seems much harder than you thought it should be.
  • This is an ideal time to do something else for a while. ex: Go walk the dog or sleep.
  • Finding someone to explain it to.

People who were distracted did better on a complex problem-solving task than people who put in conscious effort –– Psychology Todayreports

FORTUNE FAVORS THE PREPARED MIND

When it comes to observation, fortune favors the prepared mind. – Louis Pasteur

• In order to have those eureka! moments, your nonconscious brain needs to have plenty of raw material; prior experiences that can contribute to an answer.
• A great way to feed your brain: Engineering Daybook – A great way to feed your brain is to give it feedback on what works and what doesn’t work as you do your daily job.

Topic 47. Working Together

I’ve never met a human being who would want to read 17,000 pages of documentation, and if there was, I’d kill him to get him out of the gene pool.

• working with: not just asking questions, having discussions, and taking notes, but asking questions and having discussions while you’re actually coding.

PAIR PROGRAMMING 成對程式設計

• one developer operates the keyboard, and the other does not. Both work on the problem together, and can switch typing duties as needed.
• The developer acting as typist must focus on the low-level details of syntax and coding style, while the other developer is free to consider higher-level issues and scope
• The inherent peer-pressure of a second person helps against moments of weakness and bad habits of naming variables foo and such.

MOB PROGRAMMING 暴民程式設計 (tight collaboration with live coding)

• It’s an extension of pair programming that involves more than just two developers.(including users, project sponsors, and testers)
• for one of us to be typing while the other discussed the issue with our business expert. It was a small mob of three.

WHAT SHOULD I DO?

• Build the code, not your ego. It’s not about who’s brightest; we all have our moments, good and bad.
• Start small.
• Criticize the code, not the person. “Let’s look at this block” sounds much better than “you’re wrong.”
• Listen and try to understand others’ viewpoints. Different isn’t wrong.
• Conduct frequent retros pectives to try and improve for next time.

Don’t Go into the Code Alone