Requirements, Specs, and Managing Up in an Agile E

问题:

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

My company has tried to adopt the scrum methodology with mixed success. Theses are some areas where we've had issues. How do you handle these?

1. Tracking requirements from Product Marketing through to product. We're trying out JIRA to track all requirements individually and assigning a release to each one as it is picked for implementation.
2. Who creates stories? Product Management who doesn't know enough to create effectively small stories, developers who may not have domain knowledge, an analyst in between?
3. Functional specs
   1. do you write them or just try to get them into a story definition?
   2. Do you write functional specs per story? Per feature?
   3. How do you see the relationship between functional specs and stories?
4. answering the question from people with VP in their title "what are we going to get by [8 months from now]?"

回答1:

Let's see if my take adds anything (not certain by any means...)

1. I'm not sure about the "assigning a release to each one" thing. I thought the idea was to put a "price" on each story/function point/unit of development and pick what goes into the current sprint. Everything else is backlog - you can offer some indication of remaining effort (see evidence based scheduling in FogBugz) but I don't think you should be allocating to specific sprints - you don't know what'll be in the backlog by the time you get there, for one thing. All you know is that it's going to change, so why waste time on it?

2. There should be a designated user representative. Or more than one, if domain knowledge can't be concentrated in one individual. But someone from the business domain should be in charge overall of deciding what goes into a sprint, subject to the effort available, of course. There can be a place for a Business Analyst type, but they need to be domain experts. If your user(s) can't write stories, even with your help (it's a co-operative thing, or should be) then you all need help. Consider getting a coach involved for a sprint or two.

3. You won't be writing functional specs in an Agile environment. You'll be writing code. Your user will be on hand at all times (or you're already exposed to significant risk) and they're your spec. The story tells you "what", and is going to be a small enough unit of work that you should be able to decide on "how" fairly quickly. And refactor. Always refactor. It's not an overhead, it's part of the process and your design won't evolve satisfactorily without it.

4. If you have VPs (hey, I'm a VP, we're not all bad!) who ask that sort of question, then parts of your company are not getting it yet. Choose someone (the person best able to deal with non-techies, perhaps, or maybe the person least able, since they clearly need the practice) to explain it to them. If what's built is important to them, perhaps their questions are an indication that someone's not as involved as they should be.

回答2:

Some information on how Atlassian (creators of JIRA) use their products to do agile development:

• How We Use JIRA and Confluence
• Atlassian Agile Process part 1
• Atlassian Agile Process part 2
• Atlassian Agile Process part 3
• Atlassian Agile Process part 4

回答3:

1. You should translate your requirements into a Product Backlog. This backlog is what you use to decide what Sprint Backlog items are chosen for each Sprint iteration. Management decides what is on the Product Backlog, but the team needs to agree to what they can produce in the Sprint (this is a negotiation that occurs at every sprint).

2. Your Product Owner (usually a product manager) drives the creation of the stories. The Stories are simple (as a system admin, I need to be able to add a user). If your product management does not understand your product, you are in trouble.

3. Agile is about designing as required. The design is never in the story. The spec can be per story, or per feature. You could design all your CRUD inside of one spec, which covers multiple stories.

4. The Product Owner gets a product demo at the end of every Sprint. So value is demonstrated at every cycle. So your VP would get reports on a monthly basis (ususally 3 weeks of dev + 1 week to prepare for the Sprint demo).

回答4:

With regard to Functional Specs - Scott Ambler's "Agile Modeling" site has some good samples. There's also a lot of concise, pragmatic advice on Agile requirements in general.

Worth a look!

回答5:

If you are going to do anything in regards writing or designing code, one of the things you should always do, is write a spec, irrespective of whatever methodology you are using, wether it is Scrum, XP, Agile or SDLC. Many people who say that writing specs is so unagile and a monument to wasteful bureaucratic paperwork. The simple fact is that they are misguided when they say that code is the spec.

The clear fact is that a spec allows you to formulate your ideas and designs beforehand, and its much easier to change a spec than it is to change a program, especially if you are working outside the confines of simple LOB application. Specs ensure you have a clearer understanding of what is required when you start coding.

Its been show time and time again that teams that use specs, design better software. In my opinion, if you hear anybody say the code is the spec, that is dogma, plain and simple, and is storing up huge maintainability problems for the future.

As an aside, I don't have anything against the Agile Manifesto or light management process centric methods like Scrum. I've used it in the past few years a number of times, and it delivers. I've also seen good software down the drain, where an agile focus would have saved it. But it is no panacea or silver bullet.