Features are things that should be (in the opinion of the submitter) added to the product. You can break down features further into two types. First, there are the features added by the product manager as a way to assign tasks to developers. These features will normally be developed from the product's spec, as you learned in Chapter 1. Developers don't usually have a choice about these features; they must be implemented.

The second type of feature comes from testers, users, managers, and other stakeholders who think they know what the product needs to make it more useful. These features have not been through the winnowing process of spec writing, and may or may not be realistic. New features from outside of the spec should first be assigned to the product manager, who can make the call as to whether they fit in this release, need to be postponed, or should never be implemented.

â– Caution Sometimes you'll find developers who enter features and then assign those features to themselves as a way to remember things that they intend to work on. You should discourage this practice if you see it happening. The problem with this scenario is that one person is responsible for entering, resolving, and closing the entire feature, so the rest of the team has no visibility. Encourage developers to submit their features through program management like everyone else. The exception to this rule is in tracking tasks that don't need to be visible to anyone else; for example, developers might choose to maintain their own to-do lists in FogBugz rather than by putting TODO comments in code. When in doubt, err on the side of making bugs visible to more than one person.

0 0

Post a comment