Before the Project

This chapter will focus on project management from an agile perspective (framework-free).

The Requirements Pit

Requirements gathering is more like requirements digging—nobody knows exactly what the want. Programmers help people understand what they want. The requirement (once expressed) should be seen an invitation to explore.

For example, the statement “Shipping should be free on all orders over $50.” should beget a bevy of questions about including tax, which shipping methods are included, internationalization, frequency of changing that $50 number, etc. The client (who has great domain knowledge, hopefully) has probably thought of some of these cases, but discussing them helps flesh out the actual requirements. A developer’s role is to interpret what the client says and feed back to them the implications.

Requirements are a process. They are learned in a feedback loop. Help your client understand the consequences of their stated requirements. Sometimes you won’t know the domain of knowledge well enough to provide salient feedback, so use “is this what you meant?” through mockups and feedback.

Walk in your client’s shoes. Work with a user to think like a user.

There’s a difference between requirements and policy. Policy should be metadata. Policy can be something like “Only an employee’s supervisor and the personnel department may view that employee’s record.” Taken literally as a requirement, it might be hard-coded. Taken as policy, you’d build / use an access control system that allowed authorized users to view a record—defining what is an authorized user would then be metadata (or configuration).

There’s also a difference between doing what the requirement asks, but not how the customer wants. Early prototypes and tracer code are key to nailing both.

Requirements are best recorded as user stories—describing a small portion of what the application does from the perspective of the user. Keep the stories small enough to fit on an index card (real or virtual), which encourages develpoers to ask clarifying questions (record the answers, for documentation).

Developers should maintain a project glossary that contains all domain-specific vocabulary for that project. It’s hard to succeed on a project if users and developers cal the same thing by different names.

Section Challenges

• [ ] Exercise 33 Which of the following are probably genuine requirements? Restate those that are not to make them more useful (if possible).

1. The response time must be less than ~500ms.
2. Modal windows will have a gray background.
3. The application will be organized as a number of front-end processes and a back-end server.
4. If a user enters non-numeric characters in a numeric field, the system will flash the field background and not accept them.
5. The code and data for this embedded application must fit within 32Mb.

• [ ] Can you use the software you are writing? Is it possible to have a good feel for requirements without being able to use the software yourself?
• [ ] Pick a non-computer-related problem you currently need to solve. Generate requirements for a non-computer solution.

Solving Impossible Puzzles

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution. Challenge any preconceived notions and evaluate whether or not they are real, hard-and-fast constraints. Categorize and prioritize your constraints.

You can help yourself solve puzzles by getting out of your own way. If you get stuck, do something else so that you let your subconscious (an amazing associative neural net) can process it. If you can’t do that, try to explain the problem to someone. And, like Hitchiker’s Guide to the Galaxy says, “DON’T PANIC”.

Section Challenges

• [ ] Take a hard look at whatever difficult problem you are embroiled in today. Can you cut the Gordian knot? Do you have to do it this way? Do you have to do it at all?
• [ ] Were you handed a set of constraints when you signed on to your current project? Are they all still applicable, and is the interpretation of them still valid?

Working Together

I’m a lover of pair programming, so this section really resonated. I love the resultant product that comes from the tensions of two people (or more) working out a solution together. I think two is almost always better than one.

• [ ] Have you tried pair programming? What was your experience?

The Essence of Agility

From the manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Any framework or method that pushes the right side over the left side should be abandoned. Agility is:

1. Work out where you are.
2. Make the smallest meaningful step towards where you want to be.
3. Evaluate where you end up, and fix anything you broke.

Section Challenges

• [ ] The simple feedback loop isn’t just for software. Think of other decisions you’ve made recently. Could any of them have been improved by thinking about how you might be able to undo them if things didn’t take you in the direction you were going? Can you think of ways you can improve what you do by gathering and acting on feedback?