FDD Process #3: Plan by Feature

The third and last of the iteration-zero-style FDD processes involves constructing an initial schedule and assigning initial responsibilities. The planning team initially sequence the feature sets representing activities by relative business value. Feature sets are also assigned to a Chief Programmer who will be responsible for their development. At the end of this process, each Chief Programmer effectively has a subset of the features list assigned to them. For a Chief Programmer this is their backlog or ‘virtual inbox’ of features to implement.

The planning team may adjust the overall sequence of feature sets to take into account technical risk and dependencies where appropriate. In larger development efforts, the dependencies that have an impact on the sequence may be purely technical in nature but are just as likely to revolve around which feature sets are assigned to which Chief Programmers, and as we shall see, which classes are owned by which developers.

FDD also departs from traditional agile thinking, in that it chooses not to adopt collective ownership of source code. Instead, it assigns individual developers to be responsible for particular classes. The initial assignment of developers to classes takes place during this planning process.

The advantages of individual class ownership are many but include the following:

• There is someone responsible for the conceptual integrity of that class. As enhancements are made, the class owner ensures that the purpose and design of the class is not compromised.
• There is an expert available to explain how a specific class works. This is especially important for complex or business-critical classes.
• The class owner typically implements a required change faster than another developer that is not as familiar with the class.
• The class owner has something of his or her own that he or she can take personal pride in.
• In addition, it can become tricky to maintain true collective ownership of code as team sizes increase. In my experience, over time, the same developers naturally gravitate to working with the same parts of the code again and again and effectively take ownership of them.

Of course, there are issues with code ownership. eXtreme programming chose collective ownership to solve real problems. We do not want delivery of features held up because one developer is waiting a long time for other developers to make changes. However, instead of allowing any pair of developers to edit any source code files whenever they think they need to, FDD address the problem differently.

Firstly, in FDD, class ownership implies responsibility not exclusivity. A class owner may allow another developer to make a change to a class they own. The big difference is that the class owner is aware of, and approves of, the change and is responsible for checking that the change is made correctly.

The other strategy that FDD uses to enable effective feature-by-feature development with individual class ownership is the idea of dynamically formed feature teams but that is a topic best postponed to the next part of this article.

As with other agile approaches, planning in FDD is not a ‘chisel in stone’ activity. Indeed, the planning team reviews and modifies the assignment of feature sets to Chief Programmers and classes to developers as often as necessary throughout the project. In addition, the planning team does not always assign owners to all the domain classes at this time and more classes inevitably emerge as the project progresses. These will get owners later. Again it is a ‘just enough’ activity.    

Fonte: http://agile.dzone.com/articles/introduction-feature-driven